Dati/Variabili (e HomePage di ControlHUB)
 
Il primo dei 3 mattoncini di base di ControlHUB sono i dati/variabili. Da una singola trasmissione o lettura dati (che essa arrivi da un canale 433Mhz, WiFi/HTTP/Internet, da un topic MQTT oppure da un'Azione di tipo Lettura) possono essere estratte una o più variabili; inoltre una variabile nuova può essere anche "creata" come mix di altre tramite una speciale Condizione espressione. 
 
Tutte le variabili che definisci sono elencate nella Home page, che indica anche brevemente la fonte (tra quelle appena nominate), e il tempo in cui la variabile è mostrata sul display (per le versioni con display; per NX e NY senza display questa impostazione non ha effetti). 
Una variabile può anche non essere mostrata a display, tranne la variabile predefinita Time (l'ora) che è sempre mostrata (ma si può scegliere per esempio 0.2s per mostrarla per un tempo brevissimo). 
Le variabili possono essere poi usate nelle condizioni e nelle azioni
 
Control HUB dati 
 
Per editare/modificare una variabile esistente basta far clic sul suo nome, per aggiungere variabili basta fare clic sui ++ posizionati proprio sopra l'elenco. Per cancellare c'è la crocetta rossa. 
 
Fonte / canale / provenienza dei dati da cui estrarre la variabile 
Nella pagina che compare quando aggiungiamo una nuova variabile, per prima cosa si può scegliere il nome della variabile. Scegliete un nome significativo: ogni variabile, oltre che essere visualizzata a schermo, può essere usata in una espressione/condizione, e/o anche nel corpo/comando di un'azione; per distinguerla il suo nome andrà scritto tutto in minuscolo e tra $, esempio Temper1 diventa $temper1$.  
 
Subito più sotto si sceglie il tempo in cui è mostrata su display e eventualmente anche se mostrare il suo nome e per quanto tempo. 
 
Ma la cosa più interessante è la fonte ovvero il canale di provenienza dei dati da cui andiamo ad estrarre la variabile
 
wifi MQTT ModBus ingressi 
 
Puoi scegliere una fonte tra cinque tipi: 
  • Canale RF/433: scegliendo questa opzione si possono ricevere dati senza fili via 433MHz da TXdata, TXtemp e TXsoil: è una particolare opzione che consente un consumo di batterie bassissimo (più basso di HTTP/MQTT) e la copertura di una distanza maggiore rispetto al WiFi; l'abbiamo inventata noi perché volevamo poter piazzare dei sensori di temperatura e umidità del terreno che consumassero poche pile; Ricordiamo che alcune versioni di ControlHUB non includono questa funzionalità (versioni "no RF"). 
  • Canale WiFi: scegliendo questa opzione si possono ricevere dati via WiFi e in realtà anche via Web/Internet (quindi anche GSM; se ControlHUB è affacciato su Web per esempio con un DYN dns), da qualunque dispositivo che li passi usando il comune standard HTTP GET/POST, con parametri di cui potete leggere la documentazione con un clic qui...; per esempio i nostri TXdata, TXtemp e TXsoil supportano questa modalità sia in versione WiFi che GSM. Si possono collegare i dispositivi al WiFi interno di ControlHUB (anche senza Internet) oppure si può collegare ControlHUB a un WiFi esterno / Internet; 
  • Ch/MQTT Topic: scegliendo questa opzione ControlHUB ascolterà il "topic" MQTT il cui nome inserite nella casella: non appena c'è una trasmissione di quel topic, andrà a vedere il messaggio; ovviamente sia i sensori che Control HUB in questo caso dovranno essere configurati per puntare al medesimo Broker MQTT (eventualmente scegliendo il broker Interno di ControlHUB per piccole automazioni e se non ci si vuole appoggiare a soluzioni esterne); 
  • Ch/Azione/Lettura (A): scegliendo questa opzione ControlHUB andrà a prendere l'output di una Azione di tipo Lettura; per prima cosa un'Azione/Lettura (da definire prima) può essere una chiamata a un sito Web (vero o virtuale), e quindi in questo caso l'output sarà la risposta del server Web (una pagina Web o quant'altro), questo vuol dire che possiamo leggere dati/variabili da server Web reali o virtuali; 
  • Ch/Azione/Lettura (B): una Azione di tipo Lettura può anche essere una stringa di comando ModBus, per cui con questa opzione (definendo sempre prima l'Azione) si può leggere qualsiasi apparecchiatura che funzioni su bus ModBus (sarà collegata via filo alla morsettiera ModBus di Control HUB, su cui è disponibile oltre A B anche l'alimentazione +/-; stiamo parlando di qualsiasi dispositivo ModBus; misuratori di tensione, corrente, potenza, temperatura, umidità, condizioni del terreno, illuminazione, vento, pioggia, misuratori di energia, anemometri, contatori acqua, ecc.). Ricordiamo che in alternativa si può anche usare TXdata per leggere un'apparecchiatura ModBus remota, ovunque sia; 
  • Espressione/Condizione: scegliere questa ultima opzione (che visualizza nel menù a tendina solo le Condizioni/Espressioni abilitate con la scelta "ON / Variabile") è un modo veloce e pratico per visualizzare su display delle variabili aggiuntive definite come combinazione matematica di altre variabili - per dar loro un nome sintetico, le abbiamo chiamate espressioni; es. si può creare e mostrare $watt1$ definito come ($volt1$ * $ampere1$) 
  •  
    Nota che da un canale (o meglio dal gruppo di dati ricevuto sul canale) si possono "estrarre" se necessario anche *diverse* variabili (una per volta, basta creare nuove Variabili a piacere, finché serve, e puntarle ognuna sul canale da cui si vuole estrarre). 
    Dopo aver scelto da che sorgente/canale provengono i dati da cui vogliamo estrarre la variabile, rimangono solo due cose fondamentali da definire: il tipo del dato (la sua natura e come mostrarlo a video), e bisogna anche dire cosa va estratto insomma come sono i dati...che sarebbe... ora lo spieghiamo. 
     
    Tipo/Show 
    Col menù a tendina Tipo/Show si dice a ControlHUB di che tipo è la variabile in ingresso, e anche come mostrarla: per esempio se è una temperatura sarà utile scegliere il tipo "Temperature" così che invece di mostrare per es. 25.12 sarà mostrato 25.1° - se il display ha poche cifre/lettere l'HUB vi permette anche di "affettare" un numero e di mostrarne solo una sezione che sapete essere particolarmente significativa. 
    Qui non c'è molto da dire in più, è autoesplicativo e nel dubbio potete fare delle prove guardando cosa si vede a display. 
    Ci sono anche dei tipi speciali come TXtemp e altri: scegliendo questi ControlHUB capisce cosa prendere e come, e sa come mostrarlo: è un modo veloce per mettere in opera i nostri dispositivi (abbiamo approfittato per inserirlo). 
     
    Come ControlHUB necessita gli arrivino i dati, cosa estrarre (JSON e HexAscii) 
    Come appena visto, i dati possono arrivare o essere presi da un numero molto vario di sorgenti. 
    I "formati" dei dati immaginabili e usati nel mondo sono tantissimi e sarebbe fantastico ma... sarebbe utopia supportarli tutti! 
    Per mantenere una certa uniformità abbiamo previsto un numero limitato di formati che i dati in ingresso a ControlHUB possono avere, scegliendo i più "facili" e diffusi, così che chi voglia dialogare con altri sistemi o farli dialogare con ControlHUB farà la minore fatica possibile. 
    Per prima cosa tutto dev'essere in ASCII (o ISO8859-1); quello che non sarebbe di sua natura in ASCII come le risposte ModBus viene tradotto automaticamente in HexAscii da ControlHub o da chi invia. 
    Ecco i formati di dato supportati al momento: 
    1. un testo che continene una sola variabile, da prendere tutto. Es. 23.4  oppure Qualcosa 
    2. un testo nel formato JSON, in cui compaiono più variabili con separatori standard. Es. {Qualcosa:ON} oppure {"Variab1":20,"Variab2":abcd,"Temperatura":23.40,"Time":"2020-06-09 15:22.55","H":"08F9"} oppure variazioni del tema; 
    3. una serie di bytes HexAscii, eventualmente separati da spazi. Es. 01 04 0007 0001 800B 
    4. una serie di bytes HexAscii, eventualmente separati da spazi, dentro a un JSON. Es. {"Pippo":"08F9"} 
    5. dei dati provenienti da TXtemp TXsoil ecc. - come accennato sopra c'è un Tipo/Show speciale per questi, così che ControlHUB li decifri automaticamente 
     
    In generale i tipi 1 e 2 sono usati molto comunemente da messaggi/topic MQTT, e possono essere generati senza fatica da siti Web oppure da apparecchiature che fanno finta di essere un sito Web. 
    I dati del tipo 3, ovvero in HexAscii, sono quelli che solitamente ControlHUB riceve da un TXdata collegato a uno strumento ModBus, oppure quelli che Control HUB stesso memorizzerà come risultato di un'Azione/Lettura che dia un comando a un apparecchio ModBus e riceva una risposta. Infatti lo standard ModBus prevede sia per i comandi che per la risposte delle sequenze di bytes che è agevole rappresentare in HexAscii (es. comando "voglio la misura della tensione" magari per un certo strumento ModBus è 01 04 0000 0001 31CA; e la risposta è molto simile). 
     
    Se il dispositivo che vuoi "ascoltare" è acceso e trasmette, appena crei una variabile e punti il corretto canale/sorgente ControlHUB fa già vedere i dati grezzi che arrivano (in alternativa, se non è un dispositivo ma è un'Azione/Lettura, se dopo averla creata l'hai "testata" almeno una volta con il pulsante di test, vedrai anche qui i dati grezzi, perché la lettura/risposta del test è memorizzata e viene mostrata se/quando crei una variabile avente come sorgente il Ch/Azione relativo). 
     
    Ma vediamo qualche esempio... se non ti interessano tutti puoi passare subito a quanto ti interessa di più ma la panoramica è già davvero ridotta al minimo indispensabile: 
  • Sensore TXtemp che trasmette temperatura su Canale433 
  • TXdata (o potrebbe ess. un sensore generico) che trasmette numero di galline su Canale WiFi, in formato HexAscii 
  • Sensore che trasmette temperatura tramite un Topic MQTT, in formato JSON 
  • Informazione di Potenza (Watt) estratta da dispositivo ModBus collegato direttamente (tramite Ch/Azione) 
  • Informazione estratta da server Web, che manda dati in testo o in JSON 
  • Altre cose, altre fonti... 
  •  
    Sensore TXtemp che trasmette temperatura su Canale433 
    O potrebbe essere un TXSoil; è uno dei casi più semplici. 
    Ricordiamo che questo funzionerà sulle versioni di ControlHUB che includono la sezione RF/433. 
    Creiamo una nuova variabile, le diamo un nome, Tfin, e scegliamo il canale di ricezione, in questo esempio abbiamo posizionato un dispositivo TXtemp sulla finestra, e l'abbiamo impostato per trasmettere via 433MHz sul Canale 1, quindi scegliamo su ControlHUB il canale 1 (433): 
    ricevere temperatura 433mhz 
     
    come già detto TXtemp ha il privilegio di avere un suo Tipo/Show personalizzato, lo scegliamo. 
    Estrai JSON è da lasciare vuoto.  
    ControlHUB automaticamente sceglierà HexAscii perché TXtemp trasmette in HEX, lasciatelo così. 
    Visto che TXtemp era già acceso e stava già trasmettendo, abbiamo cliccato il "pulsante" di aggiornamento/ricaricamento ovvero  e c'è già una temperatura, 17.36: eh sì, fa freschino stamattina fuori dalla finestra. 
    Da adesso in avanti la variabile Tfin conterrà il valore della temperatura mandata dal TXtemp appoggiato fuori dalla finestra, e potremo usare questa variabile dentro delle condizioni, magari per pilotare delle azioni (e volendo usarla anche nel corpo/comando di un'azione; sempre da scrivere $tfin$). 
     
    TXdata (o potrebbe ess. un sensore generico) che trasmette su Canale WiFi, in formato HexAscii 
    Questo esempio lo facciamo con un TXdata, quindi con uno dei nostri dispositivi... ma potrebbe essere un qualsiasi altro sensore remoto che sceglie di trasmettere tramite HTTP usando lo stesso standard di TXdata, che è pubblico ed è lo standard Web GET/POST che esiste da quasi 30 anni. Questo dispositivo che trasmette può essere collegato sia via WiFi locale oppure anche da una rete remota o via GSM se ControlHUB ha IP fisso o ha un DynDNS
    Nella nostra installazione di prova, abbiamo un TXdata che è collegato a un misuratore ModBUS (questo misuratore è parecchio distante così che veniva scomodo collegarlo direttamente a Control HUB - sarebbe anche possibile, vedi esempio successivo). TXdata è impostato per accendersi ogni 15 minuti, richiedere una misura, e inviare a ControlHUB tutta la stringa ModBus ottenuta. 
    Per la cronaca questa stringa di misura contiene in realtà diverse misure, e da questi dati potremmo ottenere diverse variabili... ma per non farla troppo lunga facciamo vedere come si fa a prenderne una, che è il numero di galline che passano davanti a un sensore ottico (dal manuale dell'apparecchio ModBus sappiamo quali bytes contengono questa informazione). 
    Nella nostra prova abbiamo collegato il TXdata al wifi interno di ControlHUB e abbiamo scelto il Canale wifi 2 (questa configurazione non richiede nemmeno la presenza di Internet e di un router; in alternativa, avendo un router e un Wifi di casa/laboratorio/ecc ci si poteva collegare tutti a quel Wifi, e si poteva specificare dentro TXdata l'IP di ControlHUB; oppure con ControlHUB affacciato su Internet si poteva anche usare un TXdata versione GSM...). 
    Allora, creiamo una nuova variabile, la battezziamo Galline, scegliamo il Canale WiFi numero 2, scegliamo come visualizzazione (Tipo/Show) quella che vedete in figura: 
    TXdata ModBus via Wifi 
     
    Estrai JSON è da lasciare vuoto, e la modalità HexAscii è da selezionare (TXdata è attaccato a uno strumento ModBus quindi manderà dei dati HexAscii). 
    ControlHUB dice che l'ultima ricezione non è disponibile, ma dice sempre così, proviamo a premere il "pulsante" di aggiornamento/ricaricamento ovvero  perché avevamo fatto un test di trasmissione da TXdata (appena l'abbiamo installato) e dunque deve aver già trasmesso. Erano anche già passate un sacco di galline davanti al sensore ModBus! 
    Sì il test era stato OK e una ricezione è già disponibile: 
    rx dati ModBus remota wifi 
     
    solo rimane da individuare i giusti bytes che danno il numero di galline; il numero di galline (lo sappiamo dal manuale del contagalline ModBus) è rappresentato da due bytes che formano un intero a 16 bit; bytes 5 e 6, li selezioniamo a video con la funzione Scegli bytes e premiamo di nuovo il pulsante di aggiornamento, ed abbiamo: 
    da ModBus a Wifi MQTT 
     
    Da adesso in avanti la variabile $galline$ conterrà il numero di galline mandato dal TXdata, sarà aggiornato ogni volta che il TXdata invierà dati nuovi, e potremo usare questa variabile dentro delle condizioni - queste condizioni saranno "valutate" ogni volta che arrivano dati nuovi e potranno magari richiamare delle azioni. Volendo si potrà anche usare questa variabile, come tutte le variabili, anche nel corpo/comando di un'azione. 
     
    Sensore che trasmette temperatura tramite un Topic MQTT, in formato JSON 
    In questo esempio vogliamo usare un sensore MQTT che abbiamo messo sul balcone, che trasmette la temperatura ogni 5 minuti. Nel suo manuale abbiamo letto che trasmette la temperatura pubblicando sul topic MQTT di nome tx-o-orig (o potrebbe essere abc/feeds/tx-o-orig o qualsiasi altra cosa). 
    Ovviamente perché tutto funzioni regolarmente occorre che sia questo sensore, sia ControlHUB puntino allo stesso Broker MQTT (vedere configurazione WiFi / MQTT / ModBus) oppure occorre che il Broker Interno di ControlHUB sia attivato e che il sensore punti all'IP o al nome di dominio Internet di ControlHUB. 
    Chiameremo questa nuova variabile Tbalcone
    ricevi sensore MQTT topic 
     
    come si può vedere in figura, per dire a ControlHUB che la fonte da cui captare questa nuova variabile è un topic MQTT andiamo a scrivere il nome del topic MQTT (l'abbiamo avuto dal manuale del sensore) che è tx-o-orig dentro la casella Ch/MQTT topic
    Scegliamo il Tipo/Show Temperature. Togliamo HexAscii perché raramente i messaggi MQTT sono HexAscii. 
    Ora possiamo salvare e poi (se il sensore lo permette) fare una trasmissione di test. Oppure aspettare qualche minuto che arrivi una trasmissione. O leggere il manuale del sensore per capire cosa trasmette...! 
    Abbiamo provato un test e quindi fatto aggiornamento/ricaricamento ovvero  . 
    estrai da MQTT variabile JSON 
     
    da qui si può vedere che il sensore sul balcone trasmette diverse informazioni interessanti; a noi interessa la temperatura. Come si può vedere la mette nel campo "Temperature". Ebbene è sufficiente scrivere Temperature nella casella Estrai variabile JSON (liscio, senza grafe o altro), e il valore della temperatura andrà in $tbalcone$. Proviamo a farlo e poi aggiornamento/ricaricamento ovvero  . 
    Ecco qui: 
    leggere sensore MQTT temperatura 
     
    Da adesso in avanti la variabile Tbalcone conterrà il valore della temperatura mandata dal sensore MQTT che abbiamo messo sul balcone, e potremo usare questa variabile dentro delle condizioni, magari per pilotare delle azioni (e volendo usarla anche nel corpo/comando di un'azione; sempre da scrivere $tbalcone$). 
    Ovviamente con un'altra variabile potremmo estrarre "Time" oppure "B" oppure uno deglli altri valori disponibili. 
     
    Informazione estratta da dispositivo ModBus collegato direttamente (tramite Ch/Azione) 
    Abbiamo collegato a ControlHUB via filo (A e B) un piccolo dispositivo ModBus che è in grado di misurare tensione, corrente, potenza assorbita e altre grandezze. Lo si può attaccare che so a una lampadina o a un frigo per vedere se è acceso, quanto assorbe, ecc. 
    Ci piacerebbe mettere la potenza assorbita in una variabile, che so Pfrigo ovvero $pfrigo$
    Per prima cosa bisogna aver creato un'Azione/Lettura che faccia, per esempio periodicamente (ma si potrebbero fare anche altre scelte), la chiamata ModBus o parlando meglio mandi il comando ModBus che richiede al misuratore il dato della potenza. 
    Adesso supponiamo di aver già creato questa Azione (se non hai ancora visto come si fa, lo facciamo negli esempi alla pagina che descrive le Azioni/Letture - dai un'occhiata...) e di avergli dato nome Energi.  
    La cosa che dobbiamo fare è creare una nuova variabile (come già illustrato sopra) e tra i canali disponibili andare a scegliere come sorgente il Ch/Azione Energi (dal menù a tendina), come in figura sotto: 
    da azione/lettura modbus 
     
    Abbiamo già scelto anche [1234],5 come tipo di dato perché dal manuale del dispositivo vediamo che i bytes che rappresentano la potenza esprimono un numero in decimi di Watt, e visto che sullo schermo del ControlHUB che stiamo usando ci stanno solo 4 cifre, scegliamo di trascurare il decimale e di prendere solo i Watt (a display - nella variabile $pfrigo$ ci sarà cmq. il numero in decimi). 
    Ovviamente qui Estrai JSON non va usato, e la opzione HexAscii va settata. 
    In prima battuta, Control HUB dice "Ultima ricezione/lettura non disponibile", però, se quando abbiamo creato l'azione/lettura abbiamo fatto almeno un test con il pulsante di Test, la ricezione in realtà c'è. Proviamo a premere il "pulsante" di aggiornamento/ricaricamento ovvero  e vediamo se va a prenderla. 
    Sì avevamo fatto il test e una ricezione è già disponibile: 
    estrarre var ModBus, HexAscii 
     
    dal manuale del dispositivo sappiamo quali sono i 2 bytes che danno l'informazione della potenza in decimi di Watt, e andiamo a prenderli scegliendoli in modo visuale, quindi usiamo il pulsante di ricarica 
    estrazione bytes ModBus 
     
    ok, sono 30 decimi di Watt ovvero 3.0 Watt, e va bene, ci avete beccati, per fare la prova non abbiamo attaccato lo strumento di misura a un frigo, ma solo a una lampadina a basso consumo... Comunque sia possiamo ancora fare il cambio. 
    Da ora in avanti ControlHUB è configurato e metterà dentro $pfrigo$ quella misura di potenza, ogni volta che l'azione Energi è eseguita ed arrivano "dati nuovi". Ci sono molte altre cose in quei dati e potremmo aggiungere altre variabili... ma magari non qui adesso o questa pagina di manuale diventa troppo lunga... 
    Rimane solo da far notare che nei ControlHUB CX/CY ovvero con schermo LCD a 16+ caratteri non esisterà il tipo [1234],5 per mostrare dati espressi in decimi; ci sarà solo UInt16 o Int16 per prendere interi senza segno o con segno a 16 bit. Volendo mostrare a schermo i Watt e avendo decimi di watt, potremmo però creare l'espressione PfrigoW definiendola come $pfrigo$/10 (prima si crea la condizione speciale ovvero la condizione/espressione, poi la variabile - forse varrebbe la pena di aggiungerlo come esempio??). 
     
    Informazione estratta da server Web, che manda dati in testo o in JSON 
    Supponiamo di avere un server Web che, chiamando una certa URL, mandi come risposta una variabile. Oppure potrebbe inviare diverse informazioni in formato JSON. 
    Per prima cosa bisogna aver creato un'Azione/Lettura che faccia la chiamata alla URL desiderata, per esempio periodicamente. 
    Anche se è un esempio un po' sciocco (perché ControlHUB ha già la variabile speciale $ip$, vedi info) negli esempi che abbiamo fatto nella sezione Azioni/Letture abbiamo creato un'azione di nome LeggiIP, che chiama un sito Web per sapere il nostro IP. 
     
    In questo esempio pescheremo una variabile da questa fonte; chiamiamo la variabile LeggiWeb (tanto per essere originali) e sceglieremo come canale il Ch/Azione/Lettura che si chiama LeggiIP 
    lettura dati da Web 
     
    ControlHUB non mostra qui una ricezione, ma abbiamo fatto una prova quando abbiamo creato l'azione LeggiIP (premendo il pulsante Test! nella pagina di definizione Azioni) proviamo a vedere che succede se premiamo il "pulsante" di aggiornamento/ricaricamento ovvero  . 
    lettura da sito Web 
     
    Da adesso in avanti la variabile LeggiWeb conterrà quanto letto dal sito Web con l'azione LeggiIP 
    Come per gli altri esempi e come per tutte le variabili potremo usare questa variabile ovunque; al momento visto che come tipo è String ovvero una stringa, sarà valutata solo approssimatamente dentro delle condizioni (per questo esempio sarà valutata 2.39); però sarà ricopiata fedelmente per l'uso dentro al corpo/comando di un'Azione. 
     
    Altre cose, altre fonti 
    Quelli fatti qui, ce ne rendiamo conto, sono solo esempi molto parziali delle cose che si possono fare e delle variabili che si possono prendere, ma diventeremmo matti ad inserirne altri... Guardandoli, per analogia, dovreste capire come fare tutto quello che si può fare. 
    Come sempre, se servisse, per qualsiasi domanda ed aiuto, c'è il forum utenti... 
     
    Variabili predefinite / di sistema 
    Oltre alle variabili definibili dall'utente, esistono alcune variabili create automaticamente da ControlHUB, per esempio per accedere all'IP in caso di impostazione con un DynDNS (è possibile definire la URL da cui richiedere l'IP dentro il menù WiFi/MQTT accessibile da HomePage), poi c'è data, ora, temperatura (ove prevista), stato degli ingressi F1 e F1 (ove presenti), stato dei relè (ove presenti), la descrizione ora è nella pagina variabili predefinite / di sistema... 
     
     
     
    Mattoncini: Dati/variabili (SEI QUI) - Azioni/letture... - Condizioni/espressioni... 
     
     
    Manuale veloce... 
     
     
    [ Variabili/dati - Variabili predefinite - Azioni/letture - Condizioni/espressioni
     
    ControlHUB Home - il controller smart per automazione e domotica programmabile anche da smartphone, il modo facile per leggere sensori e comandare relè e dispositivi MQTT ModBus HTTP RS232 Web DoorSwitch DoorOpen SuperClock Smart Switch impostare timer, azioni anche periodiche, condizioni... 
     
    Soluzioni Semplici - Home - L'hardware di VisualVision 
    (C) 2024 VisualVision