Esempio Temperature Alarm

Esempio Temperature Alarm

Questo esempio mostra una semplice rulechain che genera un allarme non appena un valore di temperatura supera un valore limite di 5 °C. Quando il valore scende nuovamente a 5 °C o meno, l'allarme viene eliminato di nuovo.

L'esempio è quindi adatto a comprendere la struttura di base di una rulechain:

• i messaggi entrano nella catena
• più nodi verificano le condizioni in sequenza
• a seconda del risultato viene generato o eliminato un allarme

Panoramica complessiva della regola di esempio

La rulechain completa è composta da più nodi collegati in sequenza.

Il flusso è il seguente:

1. Un messaggio entra nella rulechain tramite l'Input.
2. Il nodo Filter Devices verifica se il messaggio proviene da uno dei dispositivi desiderati.
3. Il nodo Filter Message verifica se il canale di temperatura desiderato è contenuto nel messaggio.
4. Il nodo Temperature Threshold valuta il valore limite.
5. Con True viene generato un allarme.
6. Con False un allarme esistente viene eliminato.

Passaggio 1: filtrare i dispositivi

Il primo nodo con funzione logica è il filtro dei dispositivi.

A questo nodo vengono assegnati:

• un nome
• la selezione dei dispositivi per i quali la regola deve valere

In questo esempio sono stati selezionati due dispositivi demo. Solo i messaggi di questi dispositivi possono proseguire nella rulechain. I messaggi di altri dispositivi vengono bloccati in questo punto.

In questo modo la regola viene limitata in modo mirato a un ambito di dispositivi definito.

Passaggio 2: verificare il contenuto del messaggio

Nel passaggio successivo si verifica se il messaggio in ingresso contiene il canale di temperatura da controllare.

Qui vengono:

• assegnato un nome al nodo
• selezionato oppure inserito manualmente, in Message Data, il canale da controllare

informazioni

Per inserire manualmente il canale è sufficiente digitarlo e confermarlo con Invio. L'inserimento manuale del canale da controllare è case-sensitive

Con l'opzione Check that all selected keys are present si garantisce che vengano inoltrati solo i messaggi che contengono effettivamente la chiave selezionata.

Se il canale manca nel messaggio, l'elaborazione termina in questo punto.

Passaggio 3: verificare il valore limite con uno script

Segue quindi un nodo script che verifica la vera e propria soglia.

In questo esempio la logica è volutamente semplice:

return msg.temperature > 5;

L'affermazione dello script è:

• True, se il valore di temperatura è maggiore di 5
• False, se il valore è minore o uguale a 5

Il nodo dispone di conseguenza di due uscite:

• True
• False

In questo modo la rulechain viene suddivisa esattamente in questo punto in due percorsi funzionali.

note

Il nome esatto della variabile all'interno di un nodo script può variare a seconda del tipo di nodo o del contesto. Per la logica funzionale dell'esempio è determinante che il valore di temperatura venga letto e confrontato con il valore limite.

Passaggio 4: generare l'allarme

Se la condizione è soddisfatta, il messaggio passa attraverso il percorso True nel nodo di allarme.

Qui si stabilisce:

• quale tipo di allarme deve essere generato
• quale livello di gravità ha l'allarme

Nell'esempio viene generato un allarme di tipo Temperature Alarm con livello di gravità Critical.

Facoltativamente, in questo punto potrebbero essere aggiunti ulteriori dettagli, ad esempio:

• il valore di temperatura attuale
• informazioni aggiuntive calcolate
• metadati dell'allarme aggiornati

Per l'esempio di base il nodo resta volutamente semplice.

Passaggio 5: eliminare l'allarme

Se la condizione non è più soddisfatta, il messaggio passa attraverso il percorso False nel nodo per l'eliminazione dell'allarme.

Qui si indica quale tipo di allarme deve essere rimosso. In questo esempio si tratta dello stesso tipo:

• Temperature Alarm

In questo modo un allarme attivo viene chiuso di nuovo non appena la temperatura non supera più il valore limite.

Passaggio 6: integrare nella Root Rule Chain

Affinché la nuova regola venga effettivamente eseguita, deve essere collegata a una catena di elaborazione attiva, ovvero la Root Rule.

Nell'esempio mostrato, la rulechain creata viene integrata nella Root Rule Chain dopo il percorso Save Time Series. In questo caso ciò è necessario perché la temperatura viene inviata dal dispositivo come canale di dati di telemetria e giunge quindi nella Rule Engine tramite il percorso Telemetry. Viene integrata dopo il nodo Save Timeseries per non interrompere la normale elaborazione di base. Vale quindi ora quanto segue:

Il dispositivo invia "Temperature" -> "Temperature" viene elaborata normalmente e salvata nel database -> Dopo il salvataggio nel database, "Temperature" viene inoltrata alla regola di valutazione dell'allarme.

Solo mediante questa integrazione la logica creata diventa efficace nel sistema in esercizio.

Risultato

Dopo il salvataggio e l'attivazione, la regola funziona come previsto:

• una temperatura superiore a 5 °C genera un allarme
• una temperatura pari o inferiore a 5 °C elimina nuovamente l'allarme

Inquadramento

Questo esempio mostra una rulechain volutamente semplice, ma contiene già i principali schemi di base:

• filtro in ingresso
• verifica dei dati
• logica condizionale
• percorsi diversi per True e False
• azione in base al risultato

Su questa base è possibile costruire anche rulechain più complesse, ad esempio per:

• segnalazione di allarme a più livelli
• notifiche via e-mail o altri canali
• collegamento di API esterne
• combinazione di più condizioni relative a dispositivi o dati

Tornare all'introduzione generale:

• Fondamenti delle rulechain