OpenHab ricezione eventi
Fulvio Spelta
Fulvio Spelta
Di Maio, Dario
Se ho capito, vorresti utilizzare XML su UDP, realizzando una sorta di comunicazione ad eventi. Giusto?
Quello che non mi convince é che questa strada richiede una configurazione complessa lato opemHAB. Tentare ovviamente non nuoce.
Nelle prossime settimane sarò fermo, ma credo che la strada di LASTIN sia valida. Bisogna lavorarci per farlo funzionare, poi lato openHAB al massimo si prende il plugin esistente e si tagliano i log per connessione chiusa.
In questo modo la configurazione openHAB dovrebbe rusultare identica a quella attuale, giusto?
Il massimo a mio avviso sarebbe applicare LASTIN su UDP.
Dario.
From Mobile.
--
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Di Maio, Dario
Alessandro in JAVA é un maestro :)
From Mobile.
Sono sempre più convinto che un binding nativo non dovrebbe essere proibitivo... Alessandro (che ho capito mastichi bene java) non hai voglia di cimentarti ? :-)
--
Fulvio Spelta
Di Maio, Dario
Credo sia complesso manutenere il codice nel tempo, openHAB evolve velocemente e SoulissApp ha diversi aspetti di sviluppo aperti.
Dobbiamo cercare un modo valido per usare i plugin esistenti (o lievemente modificati) in modo efficace.
A me farebbe piacere vedere un plugin per Souliss, ma ci vuole una persona dedicata, il lavoro su SoulissApp già oggi tende ad essere incompatibile con il tempo che il buon Alessandro ha a disposizione.
Dario.
From Mobile.
Fulvio Spelta
al massimo si prende il plugin esistente e si tagliano i log per connessione chiusa.
In questo modo la configurazione openHAB dovrebbe rusultare identica a quella attuale, giusto?
- mantenere la configurazione attuale per mandare i comandi e (volendo) ricevere con polling a bassa ferquenza un allineamento e lo stato inziale
- aggiungere l'item stringa di ascolto
- aggiungere una rules che al varire dell'item di ascolto analizzi la stringa ricevuta per identificare l'item da aggiornare lo stato da impostare e quindi fare una "postupdate"
Di Maio, Dario
Allora anche io non sto capendo un granché.
Ma l'idea di fare un polling a frequenza alta, con chiusura della connessione se non ci sono nuovi dati ed uso di una sola GET senza specificare l'id, dovrebbe funzionare no? Log a parte.
Dario.
From Mobile.
Fulvio Spelta
Per riassumere oggi sappiamo che per comunicare ad eventi vs OH, al netto di plugin specializzati, abbiamo trovato 3 strade
1 - chiamate REST o URL con parametri
2 - plugin seriale
3 - plugin UDP
I metodi 2 e 3 possono richiedere configurazioni complesse ovvero la scrittura di rules o script per analizzare i dati ricevuti e trasformarli in danni di stato degli item. Questo è conoscenza sempre utile.
Ora rimane da capire se queste strade possono contribuire allans idea di efficientare la connessione souliss-OH e se si come. Nel post precedente a blocchi una possibile idea, complessa concordo, però magari in casi particolari potrebbe essere utile (non necessariamente per souliss o magari per una implementazione custom dove pochi specifici slot hanno necessità particolari di aggiornamento).
L'altra idea, che dobbiamo verificarne la fattibilità lato OH è il polling frequente ma efficientato dove se non c'è stato un cambio stato il GW souliss invece di inviare dati chiude la connessione.
Su questo fronte stiamo al punto:
- alpha implementazione in A5.2 non ancora funzionante
- da verificare lato OH
Ho riassunto tutto a beneficio dei NS appassionati lettori :-)
Prossimi passi
- per mia testardaggine proseguito a analizzare un po' il canale UDP.
- occorre validare l'ipotesi 'chiusura connessione', come procediamo? attendo alpha r3 o provo con ambiente simulato ad hoc?
ciao
f
Di Maio, Dario
Se riesci a fare delle simulazioni é meglio, perché la r3 richiederà un po di tempo.
Per UDP, quale struttura dati conti di utilizzare?
Dario.
From Mobile.
Fulvio Spelta
Per UDP no in ho ancora studiato nulla troppo presto non ho ancora chiaro la soluzione completa.
Domanda: in riferimento alla A5.1 attuale in modalità con persistenza, dove posso intercettare nel codice il punto in cui il GW riceve/gestisce il cambio di stato di uno slot?
L'obiettivo è eventualmente iniettare un pezzetto di codice ah hoc per notificare via UDP le variazioni e testare l'idea.
Comunque ti confermo che non mi convince come metodo generalizzato sto solo cercando di approfondire un pochino per eventuali casi speciali.
THX
f
Di Maio, Dario
In MaCaco.cpp cerchi il nome del functional code 0x15, i commenti dovrebbero aiutarti per il resto.
Dario.
From Mobile.
Fulvio Spelta
mport java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.IOException;
import java.io.PrintWriter;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.Date;
/**
* A TCP server that runs on port 9090. When a client connects, it
* sends the client the current date and time, then closes the
* connection with that client. Arguably just about the simplest
* server you can write.
*/
public class Server {
static int i = 0;
/**
* Runs the server.
*/
public static void main(String[] args) throws IOException {
ServerSocket listener = new ServerSocket(9090);
try {
while (true) {
Socket socket = listener.accept();
try {
BufferedReader in = new BufferedReader(
new InputStreamReader(socket.getInputStream()));
PrintWriter out = new PrintWriter(socket.getOutputStream(), true);
System.out.println("RECEIVED: " + in.readLine());
i = i + 1;
if (i < 5) {
out.println("HTTP/1.1 200 OK");
out.println("Content-Type: text/plain");
out.println("");
out.println(i);
System.out.println("Inviato response");
}
else {
System.out.println("No response" + i);
}
} finally {
socket.close();
}
}
}
finally {
listener.close();
}
}
}
String sTest "Test [%s]" { http="<[oatesttruncate:10000:REGEX((.*))]" }
http:oatesttruncate.url=http://192.168.10.110:9090/pippo.htm
http:oatesttruncate.updateInterval=10000
Risultato
Di Maio, Dario
Il comportamento é analogo se la disconnessione avviene dopo aver inviato un HTTP Hello?
Grazie,
Dario.
From Mobile.
Fulvio Spelta
Di Maio, Dario
Vero, intendevo HTTP 200.
Dario.
From Mobile.
Scusa cosa è un http hello ? :-(
Di Maio, Dario
Prova per favore a spostare quel if(i<5) in basso di tre righe, in modo che la connessione venga semplicemente chiusa inviando HTTP200.
Il fatto che riprovi 4 volte non é buono per il nostro scopo.
Un'altra domanda, visto che non potrà piú essere sottointeso l'id del nodo, creare una regola che individui due elementi id e slot é complicato?
Con questo approccio la chiata sarebbe del tipo GET /status senza specificare alcun id. Poi opeHAB dovrebbe discriminare id e slot per aggiornare il suo stato corrente.
Inoltre l'utilizzo della cache diventerebbe l'unico possibile.
Cerco di inviare per domani il codice Souliss corretto.
Grazie,
Dario.
From Mobile.
Fulvio Spelta
mi spiego, se il binding lo metto a livello di item la risposta deve essere per quel item.
il trucco della cache consiste nel fatto che lamirl viene chiamata una volta sola ed il risultato passato a tutti gli item che fanno riferimento a quella URL in cache che comunque elaborano il risultato ognuno secondo la propria regola (regex in questo caso)per estrarre il valore dello mstato aggiornato.
questo implica che nella stringa ricevuta ebbe sempre essere presente la coppia nodo-slot per permettere una identificazione certa del tipico/item cui quello stato deve essere assegnato.
la logica di funzionamento pero sarà che quanto restituito alla URL sara dato in pasto a tutti gli item che tramite regex o xslt devono capire se lo stato ritornato è o meno di loro interesse.
a più tardi con esito della prova
Di Maio, Dario
Provo cosí
GET /status
>HTTP 200
GET /status
>HTTP 200 + <id3>...</id3>
GET /status
>HTTP 200
GET /status
>HTTP 200
GET /status
>HTTP 200
GET /status
>HTTP 200 + <id1>...</id1>
GET /status
>HTTP 200
Quindi adesso non sai piú quale id riceverai, la risposta andrà messa in cache e poi analizzata con una REGX per tirarne fuori i valori ed associarli agli item relativi.
Si può fare?
Dario.
From Mobile.
Fulvio Spelta
2014-03-23 14:20:54 - sTest state updated to 1
2014-03-23 14:20:56 - sTest state updated to 2
2014-03-23 14:20:58 - sTest state updated to 3
2014-03-23 14:21:00 - sTest state updated to 4
2014-03-23 14:21:02 - sTest state updated to
2014-03-23 14:21:04 - sTest state updated to
2014-03-23 14:21:06 - sTest state updated to
GET /status
>HTTP 200 + <id1><s2>xxx</s2></id1><id0><s1>xxx</s1></id0>
GET /status
>chiusura connessione
In parole: se non ci sono dati la connessione viene abbattuta
Se ci sono dati gli slot vengono passati nella response ed ognuno è chiaramente identificabile dalla coppia id-slot (come oggi)
Lato OH ho comunque dubbi. Sono certo che funzionerebbe nella configurazione:
1 solo item viene legato al binding e ad ogni cambio stato (quindi dati ricevuti) viene attivatra una rule che analizza i dati e poi imposta lo stato sull'item corretto che però è legato al binding http solo per l'imvio comandi e non per la ricezione dello stato che aviene solo tramite l'item "buffer" e il codice della rule.
(stessa tecnica di analisi necessaria se ricevessimo i dati realmente ad evento attraverso il binding udp - scenario dal quale siamo partiti)
Non sono affatto certo che possa funzionare se gli item sono legati ognuno al binding http per la ricezione dei dati sarebbe tutto da provare
Mi manca come si acquisisce lo stato "inziale" a fronte dell'avvio di OH.
ciao
Di Maio, Dario
Per ogni GET si possono ottenere solo dati relativi ad un unico nodo, non ad altri. Questo semplica la sintassi della REGX?
Associare l'id ad ogni slot é fattibile, ma richiede un buffer in RAM sensibilmente maggiore.
Data la sintassi, si può anche pensare di costruire il buffer dati direttamente nel W5x00, soluzione non particolarmente complessa, si può realizzare con una struttura dati apposita. Ma lascio questo passo alle finiture successive.
All'inzio i dati verranno ottenuti in ordine sparso. Si può realizzare una chiamata del tipo GET /refresh da pollare una tantum, che vada ad azzerare tutti i contatori delle sottoscrizioni. Questo genererebbe il traffico che andrebbe ad alimentare LASTIN.
Dario.
From Mobile.
--
Fulvio Spelta
Per ogni GET si possono ottenere solo dati relativi ad un unico nodo, non ad altri. Questo semplica la sintassi della REGX?
Associare l'id ad ogni slot é fattibile, ma richiede un buffer in RAM sensibilmente maggiore.
Data la sintassi, si può anche pensare di costruire il buffer dati direttamente nel W5x00, soluzione non particolarmente complessa, si può realizzare con una struttura dati apposita. Ma lascio questo passo alle finiture successive.
All'inzio i dati verranno ottenuti in ordine sparso. Si può realizzare una chiamata del tipo GET /refresh da pollare una tantum, che vada ad azzerare tutti i contatori delle sottoscrizioni. Questo genererebbe il traffico che andrebbe ad alimentare LASTIN.
Di Maio, Dario
Nella mia idea la sintassi resta la stessa, già ora c'é un id in testa alla stringa. L'id c'é ma solo in testa alla stringa, ma non so se sia analizzabile con le regx, perché ora non usi quel dato.
La sintassi la possiamo modificare ovviamente, e cercherò l'occasione per spostare tutto lato wiznet e ridurre l'uso di RAM.
Credo di aver capito che sia necessaria una configurazione piú complessa. Per ora non preoccuparti della fase iniziale.
Dario.
From Mobile.
--
Fulvio Spelta
Nella mia idea la sintassi resta la stessa, già ora c'é un id in testa alla stringa. L'id c'é ma solo in testa alla stringa, ma non so se sia analizzabile con le regx, perché ora non usi quel dato.
xml: <id1><s0>10</s0><s1>20</s1></id1>
regex: .*<id1>.*<s1>(.*)</s1>.*</id1>
valore estratto: 20
xml: <id1><s1>20</s1></id1>
regex: <id1><s1>(.*)</s1></id1>
valore estratto: 20La sintassi la possiamo modificare ovviamente, e cercherò l'occasione per spostare tutto lato wiznet e ridurre l'uso di RAM.
Credo di aver capito che sia necessaria una configurazione piú complessa. Per ora non preoccuparti della fase iniziale.
Fulvio Spelta
Di Maio, Dario
Ok, quindi la sintassi rimane quella attuale. Per la configurazione di OA non saprei dirti, sta a te trovare la strada giusta.
Parti dal presupposto che ci sia già il primo stato disponibile, poi quel punto andrà a posto da solo usando alcuni accorgimenti lato scheda.
Tanto MaCaco é dinamico e può essere forzato temporaneamente in una sorta di polling, quindi si recuperano tutte le informazioni che servono.
Dario.
From Mobile.
--
Di Maio, Dario
Domani ci guardo, il numero viene ricavato confrontando l'indirizzo vNet con la posizione in ADDRESSES.
Dario.
From Mobile.
Fulvio Spelta
Ok, quindi la sintassi rimane quella attuale. Per la configurazione di OA non saprei dirti, sta a te trovare la strada giusta.
- Abbiamo una interfaccia funzionante in modalità http/polling (serve un gw con un po di ram se vuoi usarlo altrimenti puoi attivare l'interfaccia su ogni nodo). E' integrata in OH secondo lo "standard" con binding a livello di item. Direi che è una buona interfaccia.
- Stiamo provando a inserire sul punto 1 la restituzione dei dati solo se variati... da verificare la fattibilità e gli impatti sulla configurazione OH. Il vantaggio è confinato al risparmio della RAM su gw
- Sto provando la ricezione di eventi su canale UDP. Da valutare impatto su GW, percorso ancora immaturo per essere valutato seriamente, il vantaggio è avere una ricezione reale di eventi. L'impatto su configurazione OH può essere importante, magari sarà solo da documentare ed inserire ad hoc in alcuni sketch dove la necessità di rilevare un evento in tempo reale è davvero indispensabile.
- Realizzare il binding nativo.... lo so ci torno sempre, ma sono convinto che non sia difficile. Proposta: non potremmo creare un gdl finalizzato alla creazione, poi una volta "creato" posso prenderlo in carico.
Di Maio, Dario
Concordo, ma l'attuale HTTP ha anche un problema di scalabilità su un numero elevato di nodi.
La nuova versione potrebbe portare a tempi di risposta veloci quanto su SoulissApp.
La RAM é un non problema, nel senso che si può lavorare per creare il buffer dinamicamente nel wiznet.
L'idea di usare UDP o un binding nativo sono interessanti, mi muovo in base ai tuoi riscontri.
Cosa intendi per gdl?
Dario.
From Mobile.
Fulvio Spelta
import java.io.BufferedReader; out.println("HTTP/1.1 200 OK"); out.println("Content-Type: text/plain"); out.println(""); if (i < 5) { out.println("<s1>10</s1><s2>20</s2>"); // out.println(i); System.out.println("Inviato response"); } else { out.println("<s2>20</s2>"); System.out.println("No response" + i); } } finally { socket.close(); } } } finally { listener.close(); } }}String LEDR "T1 [%d]" { http="<[http://192.168.10.110:9090/pippo.htm:2000:REGEX(.*<s1>(.*)</s1>.*)]" }String LEDG "T2 [%d]" { http="<[http://192.168.10.110:9090/pippo.htm:2000:REGEX(.*<s2>(.*)</s2>.*)]" }Esito
01:29:20.214 INFO runtime.busevents[:26] - LEDG state updated to 2001:29:20.236 INFO runtime.busevents[:26] - LEDR state updated to 1001:29:22.253 INFO runtime.busevents[:26] - LEDG state updated to 2001:29:22.278 INFO runtime.busevents[:26] - LEDR state updated to null01:29:24.291 INFO runtime.busevents[:26] - LEDG state updated to 2001:29:24.320 INFO runtime.busevents[:26] - LEDR state updated to null01:29:26.334 INFO runtime.busevents[:26] - LEDG state updated to 2001:29:26.363 INFO runtime.busevents[:26] - LEDR state updated to null01:29:28.377 INFO runtime.busevents[:26] - LEDG state updated to 2001:29:28.400 INFO runtime.busevents[:26] - LEDR state updated to nullIn sintesi quando vengono restituiti entrambi i valori s1 e s2 tutti ok se viene restuito uno solo dei due valori l'altro item finisce per essere impostato a null
Di Maio, Dario
Alla luce di questo risultato, vale la pena continuare su questa strada per HTTP?
Creare un gruppo di lavoro é difficile, perché intorno a Souliss siamo sempre gli stessi.
L'unico ad avere competenze é Alessandro, ma non lavora piú in modo costante al progetto (almeno per ora) e piú di una volta gli ho chiesto di interessarsi ad openHAB.
Con l'attuale gruppo di persone abbiamo dei limiti nello sviluppo e nella manutenzione.
Servirebbe portare nuove persone e competenze, suggerimenti?
Dario.
From Mobile.
Test restituzione valori parziali - negativoVisti risultati dei test precedenti me lo aspettavo, purtroppo la configurazione attuale non è compatibile con una restituzione parziale dei dati.Codice utilizzato
Items
Esito
In sintesi quando vengono restituiti entrambi i valori s1 e s2 tutti ok se viene restuito uno solo dei due valori l'altro item finisce per essere impostato a nullA questo punto questa strada porta a una configurazione complessa la OH perché si dovrebbe ricorrere ad un item di appoggio ed a una regola di analisi.
gdl = gruppo di lavoro. La mia idea è che le persone che hanno le competenze contribuiscano realizzando una prima implementazione del binding (spero che dalla app o da zozzariello si riesca ad estrarre una serie di classi per la gestione del protocollo.Potremmo aprire un post af hoc per progettare insieme la struttura del binding (io potrei proporre la struttura delle impostazioni ovvero come fare la configurazione in OH) e realizzare un prima versione collaborando tutti insieme, successivamente, una volta impostato, potrei prenderlo in carico per la manutenzione liberando i contributori e non caricandoli così a dismisura.ciao
f
Fulvio Spelta
Alla luce di questo risultato, vale la pena continuare su questa strada per HTTP?
Creare un gruppo di lavoro é difficile, perché intorno a Souliss siamo sempre gli stessi.
L'unico ad avere competenze é Alessandro, ma non lavora piú in modo costante al progetto (almeno per ora) e piú di una volta gli ho chiesto di interessarsi ad openHAB.Con l'attuale gruppo di persone abbiamo dei limiti nello sviluppo e nella manutenzione.
Servirebbe portare nuove persone e competenze, suggerimenti?
Di Maio, Dario
Dopo ci guardo.
Alessandro legge il forum, se vorrà si farà avanti.
Dario.
From Mobile.
Fulvio Spelta
Fulvio Spelta
Di Maio, Dario
Conoscendolo non gli dispiace essere citato :) ma ultimamente trova modi migliori di impegnare le serate :D ...e fa bene! :D
Dario.
From Mobile.
E con questo post prometto ad Alessandro di non citarlo più :-) e mi scuso se ho esagerato.f
Di Maio, Dario
Fulvio Spelta
Se le prove avranno successo, potremmo provare a realizzarne un'implementazione basata su LASTIN, creando un'interfaccia come per l'attuale HTTP/XML.
Una domanda, l'unica soluzione possibile è quella di utilizzare una struttura dati ASCII come XML? Lato openHAB riusciresti a fare il parsing di una struttura binaria come quella di MaCaco?
Di Maio, Dario
Hai ragione é stata colpa della fretta, riesci comunque a fare le prove con questo codice?
I valori iniziali non sono un problema, fai conto che al primo avvio dell'interfaccia openHAB tutti i valori siano disponibili.
Per farti capire, SoulissApp non fa polling e nel gateway non c'é memoria degli altri nodi. Sono cose curate dal protocollo, ci pensa lui a chiedere per tuo conto i dati.
Dietro deve esserci un unico meccanismo ad eventi ed asincrono, poi ci saranno dei meccanismi d'innesco per casi particolari.
Lato openHAB ci vogliono solo le regole per catturare il frame e farne il parsing, queste devono essere assolutamente asincrone dal resto, altrimenti non é un meccanismo ad eventi.
Dario.
From Mobile.
Fulvio Spelta
Il giorno lunedì 24 marzo 2014 17:41:33 UTC+1, Dario Di Maio ha scritto:
Hai ragione é stata colpa della fretta, riesci comunque a fare le prove con questo codice?
I valori iniziali non sono un problema, fai conto che al primo avvio dell'interfaccia openHAB tutti i valori siano disponibili.
Per farti capire, SoulissApp non fa polling e nel gateway non c'é memoria degli altri nodi. Sono cose curate dal protocollo, ci pensa lui a chiedere per tuo conto i dati.
Di Maio, Dario
Si hai colto in pieno. É quello che fa SoulissApp. Si deve capire se vale la pena realizzarlo seguendo questa strada.
La modalità persistance serve solo come buffer di polling, se ogni richiesta di polling venisse trasformata in un evento, la comunicazione diventerebbe in polling e non piú ad eventi.
Dario.
From Mobile.
Fulvio Spelta
Di Maio, Dario
Guarda al codice dell'interfaccia é li dentro, lo riconosci.
Se mi dai l'ok, scrivo un interfaccia completa come ci siamo detti.
Dario.
From Mobile.
Fulvio Spelta
// Typicals in group Souliss_T5n need convertion from half-precision float to string if((memory_map[MaCaco_G_TYP_s+(id_for*MaCaco_TYPLENGHT)+slot] & 0xF0 ) == Souliss_T5n) { float f_val; float32((U16*)(memory_map+(MaCaco_G_OUT_s+(id_for*MaCaco_OUTLENGHT)+slot)), &f_val); ASCII_float2str((float)f_val, 2, &buf[bufferlen], HTTP_BUFBYTES); bufferlen = strlen(buf); } else // All others values are stored as unsigned byte { // Print "val" value *(unsigned long*)(buf+bufferlen) = (unsigned long)memory_map[MaCaco_G_OUT_s+(id_for*MaCaco_OUTLENGHT)+slot]; ASCII_num2str((uint8_t*)(buf+bufferlen), DEC, &bufferlen); }// Print "val" value*(unsigned long*)(buf+bufferlen) = (unsigned long)memory_map[MaCaco_P_OUT_s+(nodeindex*MaCaco_OUTLENGHT)+sslot];ASCII_num2str((uint8_t*)(buf+bufferlen), DEC, &bufferlen); thx
Di Maio, Dario
?
From Mobile.
Di Maio, Dario
Ti serve una mano ad integrarlo? O l'hai riportato solo per informazione?
From Mobile.
Fulvio Spelta
Fulvio Spelta
Fulvio Spelta
<id1><s0>16</s0><s1>8</s1><s2>25.25</s2><s3>78</s3><s4>0</s4><s5>0</s5><s6>0</s6><s7>0</s7><s8>0</s8><s9>0</s9></id1>
<id0><s0>1</s0><s1>0</s1><s2>0</s2><s3>0</s3><s4>0</s4></id0><id1><s0>16</s0><s1>8</s1><s2>25.44</s2><s3>78</s3></id1>Di Maio, Dario
Non é sbagliato, quella porzione di codice funziona solo per i nodi remoti.
Spero sia sufficiente per effettuare una valutazione, poi le prove le facciamo sul codice reale dell'interfaccia.
Fammi sapere,
Dario
From Mobile.
Fatto !!!!! Sono andato per analogia, sei stato congruente !! sta andando a stanotte per le prove di acquisizione lato OH (se resisto)
Fulvio Spelta
Fulvio Spelta
String sUDP50 "sUDP50" { udp="<[*:*:REGEX((.*))]" }
String sTest "Test [%s]"
import org.openhab.core.library.types.*import org.openhab.model.script.actions.*import java.util.regex.Matcherimport java.util.regex.Pattern
var String sExpr = "<id1>.*<s2>(.*)</s2>.*"
rule "Extract status from broadcasted data"when Item sUDP50 changedthen var String sAppo = "" sAppo = sUDP50.state.toString logInfo( "FILE", sExpr ) logInfo( "FILE", sAppo )
var Pattern pattern = Pattern::compile(sExpr) var Matcher matcher = pattern.matcher(sAppo) matcher.find() logInfo( "FILE", matcher.group(1) ) postUpdate(sTest, matcher.group(1) )endAlla ricezione dell'xml a fronte dell'evento viene eseguita la regola, estratto il valore dello slot 2 (temperatura) e impostato come stato all'item sTest.
Di Maio, Dario
Complicato :)
Devi impostare una regola per ogni item? C'é un modo per creare delle regole di template?
Come stai lavorando su UDP (broadcast/unicast, porta, ip).?
Dario
From Mobile.
--
Fulvio Spelta
Il giorno mercoledì 26 marzo 2014 00:12:55 UTC+1, Dario Di Maio ha scritto:
Complicato :)
Devi impostare una regola per ogni item? C'é un modo per creare delle regole di template?
Come stai lavorando su UDP (broadcast/unicast, porta, ip).?
Di Maio, Dario
Verifica se funziona anche in unicast pur su una porta fissa.
Dario.
From Mobile.
--
Fulvio Spelta
String sUDP50 "sUDP50" { udp="<[*:*:REGEX((.*))]" }
Number SOULISS_SL_1 "Light 1 [MAP(f_bin2switch.map):%d]" <switch> { http="<[soulissnode90gw:2000:REGEX(.*<s4>(.*)</s4>.*)] >[1:GET:http://192.168.10.90/force?id=0&slot=4&val=2] >[0:GET:http://192.168.10.90/force?id=0&slot=4&val=4]", autoupdate="false" }
Switch SOULISS_SL_2 "Light 2 " <switch> { http="<[soulissnode90gw:2000:REGEX(.*<s4>(.*)</s4>.*)] >[ON:GET:http://192.168.10.90/force?id=0&slot=4&val=2] >[OFF:GET:http://192.168.10.90/force?id=0&slot=4&val=4]", autoupdate="false" }
Number Weather_Temperature "Temperature [%.1f °C]" <temperature> (Weather_Chart, Weather_Temperature_Single)import org.openhab.core.library.types.*import org.openhab.model.script.actions.*import java.util.regex.Matcherimport java.util.regex.Pattern
var String sRegxSOULISS_T1_tx = "<id1>.*<s0>(.*)</s0>.*"var String sRegxSOULISS_T2_tx = "<id1>.*<s1>(.*)</s1>.*"var String sRegxWeather_Temperature = "<id1>.*<s2>(.*)</s2>.*"
rule "Extract status from broadcasted data"when Item sUDP50 changedthen var String sAppo = "" sAppo = sUDP50.state.toString
var Pattern pattern = Pattern::compile(sRegxSOULISS_T1_tx) var Matcher matcher = pattern.matcher(sAppo) matcher.find() postUpdate(SOULISS_T1_tx, matcher.group(1))
pattern = Pattern::compile(sRegxSOULISS_T2_tx) matcher = pattern.matcher(sAppo) matcher.find() postUpdate(SOULISS_T2_tx, matcher.group(1))
pattern = Pattern::compile(sRegxWeather_Temperature) matcher = pattern.matcher(sAppo) matcher.find() postUpdate(Weather_Temperature, Float::parseFloat(matcher.group(1)))endIl tutto funziona egregiamente e il cambio stato dell'item a fronte dell'invio di un comando è veramente immediato. Non semplicissimo ma molto bello funzionalmente.
Marco Fabbri
Di Maio, Dario
scusa ma così lo stato non lo legge attraverso http?
{ http="<[soulissnode90gw:2000:REGEX(.*<s4>(.*)</s4>.*)]
Fulvio Spelta
Di Maio, Dario
Ciao Fulvio,
Intervenire su quel file é un po complesso ma non impossibile. Se sei sufficientemente assestato in questa modalità, ti chiederei di passare ad usare la A5.2 che ti ho inviato qualche settimana fa.
Dovrebbe inviare anche i dati relativi al nodo locale.
In questo modo valutiamo il comportamento del codice che verrà effettivamente rilasciato.
Fammi sapere,
Dario.
From Mobile.
--
Fulvio Spelta
Di Maio, Dario
Devo apportare modifiche alla 5.2 o la devo utilizzare così come me la hai inviata ?
Di Maio, Dario
A memoria, il tuo nodo gateway non usa solo il tipico di indicazione On/Off senza comandi?
Se si, il comportamento é corretto perché la logica non processa i comandi e quindi non vengono generati eventi.
Dario.
From Mobile.
Intanto provo ciao f2014-04-14 17:06 GMT+02:00 Di Maio, Dario <dario....@souliss.net>:
Riusciresti a mandarmi un file?2014-04-14 13:43 GMT+02:00 Fulvio Spelta <fulvio...@gmail.com>:
Fatto ti ho messo un caso semplice nella nota (start/status/gw on)ciaof2014-04-14 13:32 GMT+02:00 Di Maio, Dario <dario....@souliss.net>:
Nel fare le prove, attiva il debug su MaCaco/vNet così vediamo come il comando viene tradotto e se c'è qualcosa che non torna.
Dario.2014-04-14 13:27 GMT+02:00 Fulvio Spelta <fulvio...@gmail.com>:Forse trovate un buchino: sembra non ricevere i comandi per id=0, vedi la nota l'ho aggiornata. ciao f2014-04-14 13:18 GMT+02:00 Fulvio Spelta <fulvio...@gmail.com>:
Ciaoho fatto qualche prova preliminare e sembra molto ok, vedi al linkDomani cercherò di fissare la configurazione OH.Diventa importante il tema della conversione dei valori analogici: è affrontabile ?P.S.Posto anche un feedback positivo per tenere su il morale. :-)ciaof2014-04-14 11:28 GMT+02:00 Di Maio, Dario <dario....@souliss.net>:
Non l'avevo resa pubblica :(Trovi al link la RC0
Dario.2014-04-14 10:59 GMT+02:00 Fulvio Spelta <fulvio...@gmail.com>:
Sono imbranato non trovo la R4... help2014-04-13 18:47 GMT+02:00 Di Maio, Dario <dario....@souliss.net>:
Nel topic dedicato ho pubblicato la versione n4 che risolve il problema di cui parlavi.
Adesso per ogni GET /status avviene il reset di tutti i canali di sottoscrizione, quindi in sequenza arrivano dati da tutti i nodi.
Da openHAB devi fare un polling lento della /status (molto lento) e considerare che viene presa traccia dell'ultimo ip da cui si riceve una /status, /force o /typ.
Se hai tempo, prova a modificare il codice per produrre un frame per ogni slot. Se i tempi di risposta sono accettabili (per 50 slot) possiamo procedere in quel modo.
Lato openHAB la configurazione é complessa?
Dario.
From Mobile.
Fulvio Spelta
Di Maio, Dario
Devi comunque usare la modalità per mantenere memoria dell'ultima stringa ricevuta?
Come al solito di chiederò di documentare sul wiki la configurazione. Inoltre c'é da pensare se dismettere l'interfaccia HTTP per l'uso con openHAB e lasciarla come generica.
Dario.
From Mobile.
Marco Fabbri
Fulvio Spelta
- trascodifica degli analogici - Dario
- Stress & Type tests - Fulvio: considerato la "novità" della interfaccia (a beneficio di tutti resa possibile in questa forma dal rilascio 1.4 di OH che ha completamente ricostruito in termini funzionali il tcp/udp binding) propongo di procedere ad un test estensivo della configurazione realizzando e provando le configurazioni di riferimento per i tipici "fondamentali" o almeno che io consoco :-) (tapparelle, luci on/off, led strip, temnperatura)
- Analisi con revisione o conferma dei messaggi utilizzati (es: la sintassi /status, /force... può essere modificata a beneficio sia della semplifictà di configurazione OH e di un alleggerimento del codice? ) - Dario/Fulvio
- Analisi e decisione su finalità della interfaccia http
Fulvio Spelta
Devi comunque usare la modalità per mantenere memoria dell'ultima stringa ricevuta?
Di Maio, Dario
Di Maio, Dario
--
Fulvio Spelta
Vediamo se ho capito, dalla versione 1.4 hanno migliorato il binding TCP/UDP e quindi adesso è molto semplice riuscire ad effettuare l'integrazione. E' così?
Di Maio, Dario
Dario.
--
Fulvio Spelta
L'importante è che la struttura stia in piedi e che si ricevano i dati, poi se c'è da affinare qualcosa ci lavoriamo.
Di Maio, Dario
C'é un altro problema, questa modalità operativa richiede meno RAM ma ne richiede comunque troppa per i miei gusti.
Considerando i valori standard di 45 nodi e 24 slot introdotti con la A5 i consumi statici di RAM sono:
- PESISTANCE INTERFACE (polling) 2046 bytes
- LASTIN INTERFACE (event driven) 623 bytes
Nel secondo caso uno sketch richiede complessivamente l'82% di RAM con W5100/W5200 su Atmega328 (Arduino Uno) e non riuscirebbe a rientrarci con ENC28J60 per via dello stack IP in software.
Dei 623 byte, 358 sono usati per creare il frame XML da spedire e sono oggettivamente tanti. Dobbiamo cercare una formattazione piú leggera o una soluzione diversa (dividere in piú frame).
Sono ben accetti suggerimenti.
Dario.
From Mobile.
--
Di Maio, Dario
Un'altra considerazione, openHAB ha un binding Modbus.
Modbus é un protocollo in polling, come lo era quello realizzato con il binding HTTP, ma é binario e non ASCII.
Se riuscissimo a fare un mix per passare ad una formattazione binaria (libera e non legata a MaCaco) riusciremmo a chiudere il giro.
Dario.
From Mobile.
Fulvio Spelta
- "peso": sono d'accordo e credo ci sia spazio per una ottimizzazione del formato del dialogo. Su questo tema credo che sarebbe utile un confronto aperto per analizzare come ri-formulare il protocollo in funzione anche delle caratteristiche del binding UDP che ho scoperto ha qualche "caratteristica" non propriamente comoda per il ns contesto. Proverò a postare una richiesta di commenti su forum OH (anche se vedo che sull'argomento non piovono proprio risposte, forse sono io che non so scrivere in maniera interessante).
- utilizzo del modbus: non conosco e quindi non voglio addentrarmi, unico commento è che se è in polling rischiamo di trovarci con i "limiti" dell'http, quali sarebbero i vantaggi,a parte,se ho capito bene il minor peso ?
Fulvio Spelta
- proseguire l'analisi del binding UDP sperando anche in qualche feedback dalla community OH
- provare a predisporre un protocollo che utilizzando le caratteristiche del binding renda possibile l'aggancio
- modbus ?
- partire dal sorgente del binding (ed ho visto che ne hanno pubblicato un altro chiamato "simpletcp") per realizzare il binding nativo souliss
Di Maio, Dario
Dario.
Fulvio Spelta
Fulvio Spelta
Marco Fabbri
Stai ancora usando un mega come gateway e una dino2 come per? Adesso riuscirei a replicare la tua configurazione.
Il gateway ancora deve essere un mega sia con UDP?
Sicuramente la configurazione con openhab e meno userfriendly rispetto a Soulissapp. Con un po di materiale, magari si rende più semplice effettuare alcune prove e magari darti qualche suggerimento su come aggirare l'ostacolo
Fulvio Spelta
Fulvio vorrei provare a replicare qualche tua prova, ma ti chiedo se riesci a postare in uno zip gli scketch dei nodi e la cartella configuration di openhab.
Stai ancora usando un mega come gateway e una dino2 come per? Adesso riuscirei a replicare la tua configurazione.
Il gateway ancora deve essere un mega sia con UDP?
Sicuramente la configurazione con openhab e meno userfriendly rispetto a Soulissapp. Con un po di materiale, magari si rende più semplice effettuare alcune prove e magari darti qualche suggerimento su come aggirare l'ostacolo
Fulvio Spelta
Di Maio, Dario
--
Fulvio Spelta
Di Maio, Dario
Dario.
Fulvio Spelta
| porta openhab | porta souliss | |
| xxxx | ---> | 290 |
| 2900 | <--- | 290 |
mentre dopo la modifica le gestisce così:
| porta openhab | porta souliss | |
| xxxx | ---> | 290 |
| 2900 | <--- | 291 |
Purtroppo comunque non è stato risolutivo, il binding tcp/udp ha comportamenti strani e vedo che purtroppo non giungono risposte dal forum OH :-((
Di Maio, Dario
Capisco, la porta sorgente lato Souliss non credo abbia importanza ma nel caso lo si potrebbe gestire senza usare una nuova socket.
Credo che vada cercato l'autore del binding per arrivare ad una risposta.
Dario.
From Mobile.
Fulvio Spelta
- Identificazione di una configurazione semplice del binding tcp/udp: brancolo nel buoi, anzi il sentore è che non ci sia; ho postato più volte domande ed esempi di comportamenti non proprio lineari del binding sui forum OH ma nessuna risposta. Sono un pelo basito, perchè il binding è, a mio avviso, strutturalmente molto interessante e di potenziale però ha comportamenti che non capisco se siano bug o by design che lo rendono un po' ingessato. Se siete curiosi guardate i forum OH e troverete 3 miei msg di cui uno con 3 esempi di quello che io ritengo un comportamento non lineare o perlomeno migliorabile. E' graditissimo qualsiasi contributo o riflessione: a me ormai si sta annodando il cervello :-)
- configurazione alternativa: ho parallelamente messo a punto, sempre con lo stesso binding, una configurazione che sembra funzionare (è attiva nel lab da circa 12h ed ho dato una prima analisi hai log) molto bene nel senso che manda correttamente i comandi a souliss e riceve gli aggiornamenti ad evento. Solo che la configurazione non è lineare ovveronon è semplicissima e non si risolve tutta in una definizione degli item ma richiede l'uso di item e rules.
Di Maio, Dario
Dario.
Fulvio Spelta
Ho letto i tuoi post e credo che sia un bug dovuto al fatto che non vengano separati i dati in ingresso da quelli in uscita, non credo sia voluto.
Di Maio, Dario
Nel topic di openHAB ha risposto una persona, ho dato qualche dettaglio ma é meglio che specifichi tu.
Dario
From Mobile.
--
