Automazione dei dispositivi IoT senza codice backend personalizzato

Ogni prodotto connesso ha prima o poi bisogno di logica event-driven che giri automaticamente: invia un alert quando la temperatura supera una soglia, aggrega le letture prima di caricarle per risparmiare banda, attiva una notifica quando un dispositivo non viene visto da 30 minuti, esegui un report energetico giornaliero, abilita un output locale quando una condizione del sensore si verifica offline.

Connhex fornisce due motori di regole IoT che gestiscono l'automazione in modo dichiarativo, senza sviluppo backend personalizzato: uno nel cloud, uno all'edge.

La sfida dell'automazione IoT​

La logica di automazione nei prodotti IoT tende a essere distribuita su più layer e diventa un onere di manutenzione:

• Alert su soglie hardcoded nel firmware: cambiare la soglia richiede una release firmware e una campagna OTA, anche se si tratta di una regola di business e non di un problema firmware.
• Servizi backend personalizzati per il rilevamento degli eventi: un microservizio dedicato che monitora un flusso di dati e invia webhook quando le condizioni si verificano diventa un servizio da deployare, monitorare e mantenere.
• Nessuna storicizzazione: quando scatta un alert, spesso non c'è traccia delle condizioni che lo hanno innescato, rendendo difficili debug e audit.
• Sprechi di banda da dati ridondanti: i dispositivi che riportano ogni lettura, anche quando non è cambiato nulla, generano costi di trasferimento e storage. Filtrare alla sorgente richiede logica firmware personalizzata.
• Comportamento offline: un dispositivo che perde la connettività cloud dovrebbe continuare a reagire alle condizioni locali, abilitare un output, attivare un allarme locale, senza che questa logica sia hardcoded nel firmware o richieda un round-trip al cloud.

Due motori di regole, due layer​

Connhex affronta l'automazione in due punti distinti del flusso dati:

Cloud Rules Engine: agisce sui dati che hanno raggiunto Connhex Cloud​

Connhex Rules Engine gira nel cloud e opera sui dati del dispositivo già ingestiti. È composto da tre elementi:

• Regole: definiscono cosa monitorare, le condizioni che devono essere soddisfatte e le azioni da intraprendere.
• Condizioni: valutano la telemetria in arrivo rispetto a soglie configurate, trend di metriche o pattern di variazione. Più condizioni possono essere combinate.
• Eventi: ogni esecuzione di una regola viene registrata come evento storicizzato, creando un audit trail completo di quando ogni condizione è stata innescata e quale azione è stata intrapresa.

Usa il Cloud Rules Engine per:

• Notifiche su soglie: "se la temperatura di questo dispositivo supera 85°C, invia una push notification all'installatore assegnato e crea un evento di manutenzione."
• Alert su trend e variazioni: rileva che una metrica sta derivando lentamente o che il suo tasso di cambiamento è anomalo, senza aspettare che una soglia fissa venga superata. Le regole possono essere definite su trend e variazioni senza un valore assoluto predefinito.
• Azioni pianificate: esegui un riepilogo giornaliero dell'attività dei dispositivi su una flotta, o genera un report settimanale del consumo energetico.
• Condizioni cross-dispositivo: attiva un'azione in base allo stato combinato di più dispositivi (non ancora possibile all'edge).
• Trigger di integrazione: invia un webhook a un sistema esterno (ticketing, ERP, CRM) quando si verifica uno specifico evento sul dispositivo.

Le regole vengono create e modificate tramite API o Connhex Control, senza deployment backend. Cambiare una soglia significa aggiornare una configurazione, non una release del codice.

Edge Rules Engine: agisce sui dati prima che lascino il dispositivo​

L'addon Edge Rule Engine di Connhex gira localmente sul dispositivo ed elabora i flussi di dati prima che vengano inviati al cloud. Le regole sono espresse come query SQL (compatibili con il linguaggio di query di eKuiper) e operano su soggetti dati locali.

Usa l'Edge Rules Engine per:

• Decimazione dei dati: invece di inviare ogni lettura del sensore, invia solo valori aggregati su una finestra temporale — "umidità media negli ultimi 5 secondi" — riducendo i costi di trasferimento dati e storage nel cloud.
• Upload condizionale: invia i dati al cloud solo quando accade qualcosa di significativo — "carica solo quando la temperatura supera 30°C." Elimina il rumore e risparmia banda su connessioni metered.
• Flussi condizionali offline: controlla output locali in base allo stato del sensore, abilita un relay, attiva un allarme locale, senza un round-trip al cloud e senza che questa logica viva nel firmware. L'edge continua a funzionare correttamente anche quando la connettività è persa.
• Pre-elaborazione per servizi downstream: trasforma o filtra i dati grezzi del sensore prima che raggiungano il Mapper o la pipeline di ingestione cloud.

Poiché l'Edge Rules Engine gira sul dispositivo, continua a operare durante le disconnessioni dal cloud. Questo lo rende il layer giusto per reazioni critiche per la sicurezza o sensibili alla latenza.

Scegliere il layer giusto​

Cosa significa per il tuo team​

L'implicazione pratica è che la logica di business (soglie di alerting, routing delle notifiche, finestre di aggregazione dei dati, regole di upload condizionale) può essere gestita senza coinvolgere il team tecnico dopo la configurazione iniziale. Un product manager può modificare una soglia di alert o aggiungere un destinatario di notifica tramite una modifica di configurazione. Un team operativo può aggiornare le regole a livello di flotta tramite API.

Questo conta soprattutto in due situazioni: durante la fase di iterazione del prodotto, quando le regole cambiano frequentemente mentre si capisce cosa vogliono davvero i clienti dagli alert; e nei deployment specifici per cliente, dove account enterprise diversi hanno bisogno di configurazioni di soglia diverse senza branch di codice separati per ognuno.

Per i team di prodotto connesso, il vantaggio pratico è un'iterazione più rapida sulla logica di alerting e automazione, meno deployment per cambiamenti alle regole di business e la capacità di offrire ai clienti comportamenti di alert configurabili — una funzionalità premium — senza lavoro di ingegneria per ogni cliente.

Settori rilevanti​

Le regole di automazione dei dispositivi sono usate in tutti i settori in cui Connhex è presente. Alcuni esempi:

• HVAC: alert all'installatore quando un termostato non risponde da 30 minuti; aggregazione delle letture energetiche ogni ora prima del caricamento → Connhex per HVAC
• Distributori automatici: notifica di rifornimento quando le scorte scendono sotto soglia; caricamento della telemetria solo al cambio di stato → Connhex per i distributori automatici
• Lavaggio industriale: alert di manutenzione su anomalia di vibrazione; disattivazione di sicurezza locale senza round-trip al cloud → Connhex per le lavatrici industriali

Leggi la documentazione tecnica​

• Cloud Rules Engine, Introduzione
• Cloud Rules Engine, Regole
• Cloud Rules Engine, Condizioni
• Edge Rule Engine addon