Dai, prendo io la parte di chi pianta il seme del dubbio.
Tra reti, sottoreti, cluster e broadcasting temo si vadano a cercare complicazioni che, probabilmente, si possono evitare se sono certe e definite le esigenze dell'applicazione.
Ma ... per esempio, contemplando le implicazioni dei timeout e dei retry (magari è già stato fatto) si riesce a tenere sotto controllo la gestione della comunicazione di quell'architettura "multiforme" ?
Saluti
Far comunicare più schede elettroniche mediante zigbee
Moderatori:
carloc,
g.schgor,
BrunoValente,
IsidoroKZ
32 messaggi
• Pagina 3 di 4 • 1, 2, 3, 4
0
voti
WALTERmwp nessuno ha detto che è un lavoro semplice.
L'architettura a cluster con sottoreti separate dovrebbe aiutare a gestire più facilmente i malfunzionamenti, gli intoppi, i timeout. Eventualmente si blocca un settore non tutta la rete.
C'è anche un altro aspetto da considerare poiché si tratta di una rete geografica che può estendersi anche per chilometri c'è una buona probabilità che il canale radio a 2.4GHz in alcuni punti risulti occupato o più disturbato.
Quanto ai timeout e i retry la rete è CSMA-CA quindi prima di trasmettere ogni nodo verifica che il canale sia libero. La soglia di decisione libero/occupato sulle radio della digi che utilizza bios85 è programmabile . La procedura di rasmissione prevede 5 tentativi, separati da tempo random crescente, per verificare se il canale è libero prima di abortire la trasmissione. L'insieme di 5 tentativi viene ripetuto per quattro volte. Quindi in totale la radio effettua 20 tentativi prima di dichiarare fallita la trasmissione. Il tutto richiede un tempo max attorno ai 40/50ms. Sulle radio digi il numero di retry volendo si può anche aumentare. Per maggiore robustezza del tutto, ma con maggiore traffico, chi riceve può anche inviare un ACK come risposta di messaggio consegnato. Requisito fondamentale perché il tutto stia in piedi è che i messaggi siano brevi. Nella mia applicazione i messaggi hanno tempo max 2.1ms con un payload di circa 40bytes.
Il firmware della radio digi ha un'altra comoda funzione: Il coordinatore della rete può precaricare fino a 5 messaggi da trasmettere e lasciarli in attesa per un certo tempo. I nodi destinatari a loro piacimento (entro un tempo max) lanceranno una richiesta al coordinatore "c'è qualcosa per me?" e solo in quel momento il messaggio sarà trasmesso. Quindi non è necessaria una sincronizzazione stretta.
L'architettura a cluster con sottoreti separate dovrebbe aiutare a gestire più facilmente i malfunzionamenti, gli intoppi, i timeout. Eventualmente si blocca un settore non tutta la rete.
C'è anche un altro aspetto da considerare poiché si tratta di una rete geografica che può estendersi anche per chilometri c'è una buona probabilità che il canale radio a 2.4GHz in alcuni punti risulti occupato o più disturbato.
Quanto ai timeout e i retry la rete è CSMA-CA quindi prima di trasmettere ogni nodo verifica che il canale sia libero. La soglia di decisione libero/occupato sulle radio della digi che utilizza bios85 è programmabile . La procedura di rasmissione prevede 5 tentativi, separati da tempo random crescente, per verificare se il canale è libero prima di abortire la trasmissione. L'insieme di 5 tentativi viene ripetuto per quattro volte. Quindi in totale la radio effettua 20 tentativi prima di dichiarare fallita la trasmissione. Il tutto richiede un tempo max attorno ai 40/50ms. Sulle radio digi il numero di retry volendo si può anche aumentare. Per maggiore robustezza del tutto, ma con maggiore traffico, chi riceve può anche inviare un ACK come risposta di messaggio consegnato. Requisito fondamentale perché il tutto stia in piedi è che i messaggi siano brevi. Nella mia applicazione i messaggi hanno tempo max 2.1ms con un payload di circa 40bytes.
Il firmware della radio digi ha un'altra comoda funzione: Il coordinatore della rete può precaricare fino a 5 messaggi da trasmettere e lasciarli in attesa per un certo tempo. I nodi destinatari a loro piacimento (entro un tempo max) lanceranno una richiesta al coordinatore "c'è qualcosa per me?" e solo in quel momento il messaggio sarà trasmesso. Quindi non è necessaria una sincronizzazione stretta.
-

luxinterior
4.311 3 4 9 - Master EY

- Messaggi: 2690
- Iscritto il: 6 gen 2016, 17:48
0
voti
Grande, vedo che il protocollo lo conosci molto bene!!! Io lo devo ancora approfondire, non so come si crea la rete a cluster nel caso di firmware zigbee. La cosa molto interessante è che se i nodi sono tutti router tutti possono fare da ponte e quindi la rete è molto potente... però non so come si comporta con le tempiste di trasmissione di un dato!!!
Comunque man mano che sviluppo il progetto se avrò dei dubbi saprò a chi rivolgermi! Vero?
Ritornando al problema del topic, quindi non conviene in questo caso utilizzare altri protocolli oltre lo zigbee, anche perché appesentirei la comunicazione senza avere dei vantaggi.... probabilmente opterò per una struttura a stringa tipo COMANDO/VALORE.
Il fatto è che, nel mio caso, devo suddividere l'intera rete il delle più piccole sotto aree, le quali vengono controllate da alcune telecamere, ma comunque tutte queste sottoaree fanno parte dello dello stesso coordinatore. Mi spiego meglio, supponiamo di avere una zona servita da uno stesso quadro di alimentazione (stesso contatore per interderci) e che questo alimenta una strada con delle traverse. Ora, mediante un concentratore da quadro che fa da coordinatore creo la rete zigbee che chiamo Street1, e tutte le altre schede installate su ogni lampione della strada + traverse si devono collegare alla stessa rete Street1. A questo punto vengono installate delle telecamere, facciamo, per esempio, due per ogni tratto di strada (una inizio e una fine) che vogliamo gestire in modo indipendente ma comunque sempre connesse alla stessa rete zigbee Street1.
Quindi ogni tratto di strada si dovrà illuminare seguendo le direttive delle rispettive telecamere. Spero di essermi spiegato più o meno...
Ora, secondo voi, si riesce a gestire il tutto con una struttura del dati COMANDO/VALORE? Oppure ci vuole un pacchetto con un header che offra più potenzialità tipo ID, Mittente ecc? Ho dimenticato di dire che, il concentratore, fa da interfaccia anche con un server remoto dal quale si potranno inviare dei comandi come ad esempio spegnere un determinato lampione, oppure inibire le telecamere di una tratta ecc.
Grazie ancora per tutti i consigli
Comunque man mano che sviluppo il progetto se avrò dei dubbi saprò a chi rivolgermi! Vero?
Ritornando al problema del topic, quindi non conviene in questo caso utilizzare altri protocolli oltre lo zigbee, anche perché appesentirei la comunicazione senza avere dei vantaggi.... probabilmente opterò per una struttura a stringa tipo COMANDO/VALORE.
Il fatto è che, nel mio caso, devo suddividere l'intera rete il delle più piccole sotto aree, le quali vengono controllate da alcune telecamere, ma comunque tutte queste sottoaree fanno parte dello dello stesso coordinatore. Mi spiego meglio, supponiamo di avere una zona servita da uno stesso quadro di alimentazione (stesso contatore per interderci) e che questo alimenta una strada con delle traverse. Ora, mediante un concentratore da quadro che fa da coordinatore creo la rete zigbee che chiamo Street1, e tutte le altre schede installate su ogni lampione della strada + traverse si devono collegare alla stessa rete Street1. A questo punto vengono installate delle telecamere, facciamo, per esempio, due per ogni tratto di strada (una inizio e una fine) che vogliamo gestire in modo indipendente ma comunque sempre connesse alla stessa rete zigbee Street1.
Quindi ogni tratto di strada si dovrà illuminare seguendo le direttive delle rispettive telecamere. Spero di essermi spiegato più o meno...
Ora, secondo voi, si riesce a gestire il tutto con una struttura del dati COMANDO/VALORE? Oppure ci vuole un pacchetto con un header che offra più potenzialità tipo ID, Mittente ecc? Ho dimenticato di dire che, il concentratore, fa da interfaccia anche con un server remoto dal quale si potranno inviare dei comandi come ad esempio spegnere un determinato lampione, oppure inibire le telecamere di una tratta ecc.
Grazie ancora per tutti i consigli
0
voti
Solo un breve commento in questo interessante thread.
Secondo come la vedo io si, molto utile aggiungere un timestamp, un livello di priorità del comando, e poi il resto. Un CRC di protezione a livello applicazione?
Per esperienza diretta il pacchetto a lunghezza fissa toglie molti grattacapi e semplifica il codice che dovrai implementare.
EOT
Ora, secondo voi, si riesce a gestire il tutto con una struttura del dati COMANDO/VALORE? Oppure ci vuole un pacchetto con un header che offra più potenzialità tipo ID, Mittente
Secondo come la vedo io si, molto utile aggiungere un timestamp, un livello di priorità del comando, e poi il resto. Un CRC di protezione a livello applicazione?
Per esperienza diretta il pacchetto a lunghezza fissa toglie molti grattacapi e semplifica il codice che dovrai implementare.
EOT
Da soli conosciamo alcune cose.
In molti ne conosceremo molte di più.
In molti ne conosceremo molte di più.
0
voti
non metto in discussione l'utilizzo dei prodotti per tale scopo: se l'applicazione è in assoluto difficile o complicata la si affronta per quel è.luxinterior ha scritto:WALTERmwp nessuno ha detto che è un lavoro semplice.(...)
Ma a me pare che l'OP sia andato in una direzione senza sapere se effettivamente è quella più adeguata.
Ad esempio, questa domanda
che risposte potrebbe ricevere ?bios85 ha scritto:(...) Ora, secondo voi, si riesce a gestire il tutto con una struttura del dati COMANDO/VALORE? (...)
Posso anche dare libertà alla fantasia, ma le necessità dovrebbero fare da guida quindi le informazioni da veicolare dovrebbero essere declinate dall'esigenza applicativa, non, ad esempio, condizionate dalle potenzialità dei prodotti.
Stabilito cosa effettivamente deve essere "detto" verifichi se il prodotto in causa offre il supporto necessario.
In tal caso gli Xbee, molto probabilmente, offrono anche più di quel che serve ma bisogna sapere cosa occorre.
Io esorterei a una maggiore cautela, che non significa cambiare idea o materiali o avere timore, ma ad inquadrare bene la situazione.
Facile ch'io sia in errore ma l'analisi dell'OP mi pare sia stata incompleta.
Comunque scrivo una banalità: compatibilmente con le difficoltà del progetto punterei a realizzare un sistema di controllo il più semplice possibile.
Ma questo in generale.
Saluti
W - U.H.F.
-

WALTERmwp
30,2k 4 8 13 - G.Master EY

- Messaggi: 8981
- Iscritto il: 17 lug 2010, 18:42
- Località: le 4 del mattino
0
voti
WALTERmwp ha ragione, bios58 rileggi con attenzione il suo ultimo intervento.
Purtroppo WALTERmwp al giorno d'oggi è difficile capire se un qualcosa può andare bene o meno per il proprio lavoro. Lo capisci solo quando ci sbatti le corna contro ma allora è troppo tardi.
Io per esempio cerecavo un modulo wifi a bassissimo consumo, pensavo di averne trovato uno, ho chiesto info precise al venditore, fortuna ha voluto che trovassi un interlocutore competente, e ho scoperto che l'hw poteva arrivare a consumi ridicoli ma il firmware non gestiva tutte le possibili opzioni di basso consumo. Per trovare da solo una simile limitazione o lo provi sulla tua pelle o leggi a fondo le Nmila pagine di documentazione.
Bios85
Quando mi parli di telecamere mi vengono i peli dritti perché la velocità della rete zigbee è infinitamente bassa. Non potrai mai veicolare informazioni da telecamera su una rete zigbee.
Come già detto non ho esperienza su zigbee, spulciando qua e là ho letto che inviare broadcast su rete zigbee sarebbe da evitare Non so perché ma probabilmente per i tempi eterni che il messaggio impiegherebbe a raggiungere ogni nodo della rete. Qundi ha ragione WALTERmwp occhio! si rischiano cantonate pesanti!
Quanto alla struttura del messaggio se usi le API hai già quelle informazioni nelle frame checksum compresa quindi, come dice il manuale, meglio pensare alla modailtà api.
Purtroppo WALTERmwp al giorno d'oggi è difficile capire se un qualcosa può andare bene o meno per il proprio lavoro. Lo capisci solo quando ci sbatti le corna contro ma allora è troppo tardi.
Io per esempio cerecavo un modulo wifi a bassissimo consumo, pensavo di averne trovato uno, ho chiesto info precise al venditore, fortuna ha voluto che trovassi un interlocutore competente, e ho scoperto che l'hw poteva arrivare a consumi ridicoli ma il firmware non gestiva tutte le possibili opzioni di basso consumo. Per trovare da solo una simile limitazione o lo provi sulla tua pelle o leggi a fondo le Nmila pagine di documentazione.
Bios85
Quando mi parli di telecamere mi vengono i peli dritti perché la velocità della rete zigbee è infinitamente bassa. Non potrai mai veicolare informazioni da telecamera su una rete zigbee.
Come già detto non ho esperienza su zigbee, spulciando qua e là ho letto che inviare broadcast su rete zigbee sarebbe da evitare Non so perché ma probabilmente per i tempi eterni che il messaggio impiegherebbe a raggiungere ogni nodo della rete. Qundi ha ragione WALTERmwp occhio! si rischiano cantonate pesanti!
Quanto alla struttura del messaggio se usi le API hai già quelle informazioni nelle frame checksum compresa quindi, come dice il manuale, meglio pensare alla modailtà api.
-

luxinterior
4.311 3 4 9 - Master EY

- Messaggi: 2690
- Iscritto il: 6 gen 2016, 17:48
0
voti
Si è vero, sembra che è tutto una confusione ma pulroppo, come ho già detto, siamo in ambito "universitario" e l'esperienza lavorativa, mia e chi mi dovrebbe indirizzare, non è da grande azienda che lavora nel settore da chissà quando!!! Questo per dire che, ho cominciato con il primo prototipo durante la tesi e ora stiamo cercando di fare il secondo, quindi l'esperienza lavorativa che ho , come ingegnere elettronico, è questa..... A mio malgrado devo dire che in questi ambienti non si cresce per nulla, basta il fatto che per avere un confronto con delle persone competenti mi devo rivolgere ai forum!!!
Comunque, sfogo a parte, sulla rete zigbee non devono passare informazioni come flusso video o altro, ovviamente non sarebbe possibile! In prativa le telecamere, hanno dell'elettronica a bordo (al momento un DSP) che esegue degli algoritmi in real-time sul flusso video in modo da riconoscere veicoli e persone, in funzione di ciò prende decisione se aumentare il flusso luminoso oppure no. A questo punto, se l'intensità delle lampade deve aumentare, invia un comando su rete zigbee per il gruppo di lampade che quella telecamera gestisce, stessa cosa se l'intensità deve diminuire! Poi sulla telecamera si cercherà di non inviare messaggi ridondanti.
Probabilmente avete, ansi sicuramente, l'utilizzo del broadcast è da evitare specialmente su una rete con 100 nodi!!! Quindi ora cercherò di approfondire e vedere come creare dei sottogruppi sulla stessa rete zigbee senza usare il broadcast, non so nemmeno se si possa fare, altrimenti cercherò una soluzione a livello applicazione che invierà i dati solo ai mac coinvolti!
Comunque, sfogo a parte, sulla rete zigbee non devono passare informazioni come flusso video o altro, ovviamente non sarebbe possibile! In prativa le telecamere, hanno dell'elettronica a bordo (al momento un DSP) che esegue degli algoritmi in real-time sul flusso video in modo da riconoscere veicoli e persone, in funzione di ciò prende decisione se aumentare il flusso luminoso oppure no. A questo punto, se l'intensità delle lampade deve aumentare, invia un comando su rete zigbee per il gruppo di lampade che quella telecamera gestisce, stessa cosa se l'intensità deve diminuire! Poi sulla telecamera si cercherà di non inviare messaggi ridondanti.
Probabilmente avete, ansi sicuramente, l'utilizzo del broadcast è da evitare specialmente su una rete con 100 nodi!!! Quindi ora cercherò di approfondire e vedere come creare dei sottogruppi sulla stessa rete zigbee senza usare il broadcast, non so nemmeno se si possa fare, altrimenti cercherò una soluzione a livello applicazione che invierà i dati solo ai mac coinvolti!
0
voti
Definiamola una sessione di brainstorming...(ho cercato con google...)
Se WALTERmwp ha voglia e tempo sarebbe bello avere anche da lui spunti su possibili soluzioni da discutere.
Stimolato dalla discussione ho iniziato a leggere qualcosina di zigbee ma nei forum che ne parlano ho trovato spesso zigbee accostato al termine nightmare.
Butto sul tavolo cose che leggo
Esistono i moduli LoRa che hanno range di km potrebbero servire per creare le sottostazioni e poi in short range utilizzare zigbee o qualcosa di analogo.
perché non pensare a Wifi se il sistema non ha batterie e non ci sono problemi di consumi potresti creare un'infrastruttura wifi. Nel settore c'è di tutto e di più, standard acqusitabile al supermercato pronto all'uso.
Per contro avresti il problema della saturazione delle bande (parzialmente risolvibile passando a 5Ghz)
Il wifi ti faciliterebbe anche la gestione delle telecamere.
Se WALTERmwp ha voglia e tempo sarebbe bello avere anche da lui spunti su possibili soluzioni da discutere.
Stimolato dalla discussione ho iniziato a leggere qualcosina di zigbee ma nei forum che ne parlano ho trovato spesso zigbee accostato al termine nightmare.
Butto sul tavolo cose che leggo
Esistono i moduli LoRa che hanno range di km potrebbero servire per creare le sottostazioni e poi in short range utilizzare zigbee o qualcosa di analogo.
perché non pensare a Wifi se il sistema non ha batterie e non ci sono problemi di consumi potresti creare un'infrastruttura wifi. Nel settore c'è di tutto e di più, standard acqusitabile al supermercato pronto all'uso.
Per contro avresti il problema della saturazione delle bande (parzialmente risolvibile passando a 5Ghz)
Il wifi ti faciliterebbe anche la gestione delle telecamere.
-

luxinterior
4.311 3 4 9 - Master EY

- Messaggi: 2690
- Iscritto il: 6 gen 2016, 17:48
0
voti
Dando per scontato che l'OP avesse(ha) stabilizzato la scelta dei prodotti mi sono permesso d'esternare qualche perplessità sul criterio d'utilizzo, quindi non sul dispositivo in sè, ma oggi giorno c'è n'è di materiale su cui ragionare.
Al netto dei prodotti che si intende impiegare insisto sulla "cautela": farsi trasportare dall'entusiasmo è bello ma poi le cose devono essere funzionanti, affidabili e agevolmente manutenibili (ma questa è un'altra questione ancora).
Su questo, anche tu @luxinterior, avevi acceso un faro per illuminare la questione.
@bios85, per l'ambiente non saprei, penso che come in tutte le circostanze della vita dipende anche da chi s'incontra.
Dipende appunto dalle necessità, da ciò che ti serve in una circostanza piuttosto che un'altra (... analisi).
Il broadcasting di per sè può rispondere ad una generica esigenza, ma magari in uno dei casi che contempli ti occorre un feedback immediato (ma allora non vai in broadcasting ...), oppure è adatto ma va limitato solo a una parte dei lampioni, oppure ...
Saluti
Al netto dei prodotti che si intende impiegare insisto sulla "cautela": farsi trasportare dall'entusiasmo è bello ma poi le cose devono essere funzionanti, affidabili e agevolmente manutenibili (ma questa è un'altra questione ancora).
Su questo, anche tu @luxinterior, avevi acceso un faro per illuminare la questione.
@bios85, per l'ambiente non saprei, penso che come in tutte le circostanze della vita dipende anche da chi s'incontra.
questo è infatti solo un esempio.bios85 ha scritto:(...) Probabilmente avete, ansi sicuramente, l'utilizzo del broadcast è da evitare specialmente su una rete con 100 nodi!!! (...)
Dipende appunto dalle necessità, da ciò che ti serve in una circostanza piuttosto che un'altra (... analisi).
Il broadcasting di per sè può rispondere ad una generica esigenza, ma magari in uno dei casi che contempli ti occorre un feedback immediato (ma allora non vai in broadcasting ...), oppure è adatto ma va limitato solo a una parte dei lampioni, oppure ...
Saluti
W - U.H.F.
-

WALTERmwp
30,2k 4 8 13 - G.Master EY

- Messaggi: 8981
- Iscritto il: 17 lug 2010, 18:42
- Località: le 4 del mattino
0
voti
Salve a tutti, in questi giorni sto cercando di approfondire il funzionamento del lo stack zigbee, ma più leggo e più vado in confusione!!! Ho letto che si possono creare profili, cluster, endpoint, ma di come si usano non ci ho capito nulla. Ci vorrebbe qualcuno che ci ha già lavorato per darci qualche spiegazione.... comunque DIGI nella comunicazione dei suoi dispositivi usa un determinato profilo privato e un cluster! Lo si può notare quando si crea un pacchetto in modalità api....
Quello che vi chiedo è, visto le necessità nel mio progetto, è possibile creare dei gruppi nella stessa rete zigbee?
Per esempio, ho una rete con PANID 5 dove 15 dispositivi si connettono ma nello stesso tempo si dovrebbero creare tre gruppi da virtuali da 5. A questo punto vorrei inviare messaggi ad un specifico gruppo senza che i restanti gruppi lo ricevano, è possibile fare questa cosa secondo voi?
Oppure i gruppi li devo creare nella mia applicazione e lasciare la rete zigbee con le sole funzioni mesh? In questo caso però, se devo inviare lo stesso messaggio a cinque dispositivi, devo fare cinque invi uno per ogni dispositivo giusto?
Quello che vi chiedo è, visto le necessità nel mio progetto, è possibile creare dei gruppi nella stessa rete zigbee?
Per esempio, ho una rete con PANID 5 dove 15 dispositivi si connettono ma nello stesso tempo si dovrebbero creare tre gruppi da virtuali da 5. A questo punto vorrei inviare messaggi ad un specifico gruppo senza che i restanti gruppi lo ricevano, è possibile fare questa cosa secondo voi?
Oppure i gruppi li devo creare nella mia applicazione e lasciare la rete zigbee con le sole funzioni mesh? In questo caso però, se devo inviare lo stesso messaggio a cinque dispositivi, devo fare cinque invi uno per ogni dispositivo giusto?
32 messaggi
• Pagina 3 di 4 • 1, 2, 3, 4
Chi c’è in linea
Visitano il forum: Majestic-12 [Bot] e 49 ospiti

Elettrotecnica e non solo (admin)
Un gatto tra gli elettroni (IsidoroKZ)
Esperienza e simulazioni (g.schgor)
Moleskine di un idraulico (RenzoDF)
Il Blog di ElectroYou (webmaster)
Idee microcontrollate (TardoFreak)
PICcoli grandi PICMicro (Paolino)
Il blog elettrico di carloc (carloc)
DirtEYblooog (dirtydeeds)
Di tutto... un po' (jordan20)
AK47 (lillo)
Esperienze elettroniche (marco438)
Telecomunicazioni musicali (clavicordo)
Automazione ed Elettronica (gustavo)
Direttive per la sicurezza (ErnestoCappelletti)
EYnfo dall'Alaska (mir)
Apriamo il quadro! (attilio)
H7-25 (asdf)
Passione Elettrica (massimob)
Elettroni a spasso (guidob)
Bloguerra (guerra)


