smoothhands Inserito: 6 gennaio 2016 Segnala Inserito: 6 gennaio 2016 (modificato) Buonasera a tutti,leggendo alcuni post mi è caduto l'occhio su frasi del tipo..."non mi piace la domotica gestita ad eventi"... o qualcosa di simile.Vorrei capire perchè questo non venga visto come un vantaggio mapiù come un difetto o, forse per qualcuno, come una cosa penalizzante. Modificato: 6 gennaio 2016 da smoothhands
EtaPhi Inserita: 6 gennaio 2016 Segnala Inserita: 6 gennaio 2016 Bisogna distinguere tra protocollo di comunicazione e logica di programmazione.In un protocollo di comunicazione basato sugli eventi, come KNX, ogni dispositivo invia un messaggio (telegramma nel gergo KNX) ogni volta che cambia il suo stato o rivela una variazione degli ingressi.In una logica di programmazione basata sugli eventi (praticamente tutte le logiche di programmazione dei sistemi domotici) ogni volta che si verifica un evento, cioè una variazione di un ingresso o l'attivazione di un timer, il sistema domotico esegue un'azione come attivare un'uscita o inviare un messaggio.Un protocollo di comunicazione basato sugli eventi è per me uno svantaggio perché:ha il problema della sincronizzazione tra dispositivinon è adatto alla raccolta dei dati e dello stato dei dispositivi durante il funzionamentoi tipi di messaggio sono numerosi e poco espandibiliIl primo svantaggio si verifica quando un dispositivo si scollega dal bus (es. quando si "addormenta" per ridurre i consumi) e successivamente si ricollega al bus per inviare uno o più messaggi. Durante la sua "assenza", i messaggi a lui destinati vanno persi (es. le notifiche che lo stato degli altri dispositivi è cambiato) e pertanto deve "risincronizzarsi" prima di inviare un messaggio.Volendo implementare una logica del tipo "se premono il pulsante del campanello ed è buio, attiva la luce dell'ingresso per 30 secondi", il dispositivo che invia il messaggio alla luce di accendersi deve sapere se è premuto il pulsante ed è buio. Se questa logica è implementata nel modulo a cui è collegato il pulsante del campanello, esso deve sapere se è buio, deve cioè inviare un messaggio al modulo che gestisce il sensore di luminosità prima di inviare un messaggio al modulo che accende la luce. Ciò determina un aumento del traffico che porta al decadimento delle prestazioni.Esistono vari modi per mitigare questo inconveniente, come impedire ad un dispositivo di "addormentarsi" e di conservare una copia dello stato degli altri dispositivi, ma è sempre possibile un guasto momentaneo che vanifica ogni tentativo di mitigazione.L'impossibilità di "addormentarsi" impedisce l'integrazione diretta di dispositivi wireless che invece ne hanno bisogno per fare durare più a lungo le batterie. Un apposito gateway è l'unica soluzione a questo problema che però aumenta i costi e i consumi.Lo svantaggio 2 è particolarmente evidente quando bisogna integrare un sistema domotico con uno SCADA. A causa del problema precedente, esso deve continuamente inviare messaggi per avere lo stato dei dispositivi. Ciò aumenta la congestione del bus e degrada le prestazioni.Lo svantaggio 3 dipende dalla varietà di dispositivi che sono stati prodotti e che saranno introdotti nel futuro.Poiché ogni dispositivo deve essere istruito su come interpretare i messaggi a lui inviati, si ricorre ad un data-base che i produttori continuamente aggiornano.Per evitare di dover riconfigurare i moduli già installati, un dispositivo con funzionalità aggiuntive probabilmente invierà almeno due messaggi: uno nel vecchio formato per compatibilità con il passato ed uno nel nuovo formato per rendere disponibili le funzionalità aggiuntive.Un protocollo di comunicazione "tipo PLC" ha invece pochi semplici messaggi: uno per la lettura degli ingressi, uno per la scrittura delle uscite e pochi altri per le funzioni ausiliarie (es. aggiornamento del firmware). Nota la velocità di comunicazione e il numero di I/O è anche nota la velocità massima del loro aggiornamento. Ciò garantisce che le prestazioni del sistema saranno sempre le stesse.I sistemi "tipo PLC" sono anche facilmente integrabili con un sistema SCADA e offrono a "costo zero" prestazioni quali il datalogging.
Livio Orsini Inserita: 6 gennaio 2016 Segnala Inserita: 6 gennaio 2016 Concordo con la tua analisi EtaPhi
smoothhands Inserita: 6 gennaio 2016 Autore Segnala Inserita: 6 gennaio 2016 Grazie EtaPhi, questa...Bisogna distinguere tra protocollo di comunicazione e logica di programmazione....era la distinzione che mi serviva per capire le affermazioni che avevo letto.La tua analisi è stata molto chiara però vorrei porre altre domande su alcuni concetti.Il primo svantaggio si verifica quando un dispositivo si scollega dal bus (es. quando si "addormenta" per ridurre i consumi) Non conosco bene i protocolli KNX e SCS (per prendere i due sistemi "maggiori" che mi avevano proposto) ma sono previsti dispositivi che "si addormentano" per ridurre i consumi? Mi immaginavo che rimanessero semprealimentati.L'impossibilità di "addormentarsi" impedisce l'integrazione diretta di dispositivi wireless che invece ne hanno bisogno per fare durare più a lungo le batterie. Un apposito gateway è l'unica soluzione a questo problema che però aumenta i costi e i consumi.Penso sia sempre una questione di costi/benefici. Quando necessario potrei voler utilizzare dispositivi alimentati a batteria e che quindirichiedono opportune tecniche di risparmio energetico: non ha senso un sensore al quale devo sostituire la batteria ogni settimana (se va bene). In questo caso il protocollo di comunicazione potrebbe non essere quello del sistema domotico principale e quindila necessità del gateway opportuno è dato anche dall'integrazione tra i due protocolli. E viene "gratis" anche il modulo chemantiene l'ultimo stato valido dei sensori a lui connessi. Lo svantaggio 2 è particolarmente evidente quando bisogna integrare un sistema domotico con uno SCADAAnche con gli SCADA non ho esperienza diretta. Lo SCADA sarebbe in questo caso il sistema che supervisiona quello domotico? O intendevi il contrario?Ad ogni modo non potrebbe essere utilizzato lo stesso concetto di gateway precedente?Lo SCADA (o viceversa il sistema domotico) deve andare a prendere direttamente le informazioni fino aidispositivi più remoti e quindi generare tanto traffico sulle connessioni?Se si fermasse ad un ipotetico gateway del sistema domotico che mantiene lo stato del sistemail traffico si fermerebbe li... ma forse questo non è possibile. Non ho esperienza a riguardo.
smoothhands Inserita: 6 gennaio 2016 Autore Segnala Inserita: 6 gennaio 2016 (modificato) O intendevi il contrario?Ho riguardato qualcosa in rete su SCADA... penso tu intendessi proprio domotica supervisionata da SCADA.ogni dispositivo deve essere istruito su come interpretare i messaggi a lui inviati, si ricorre ad un data-base che i produttori continuamente aggiornano.Adesso ho compreso l'enorme documentazione sui Data Point Types di KNX.E l'OpenWebNet non è poi tanto diverso: WHO,WHAT,WHERE,DIMENSION,VALUE ele rispettive tabelle. Modificato: 6 gennaio 2016 da smoothhands
EtaPhi Inserita: 6 gennaio 2016 Segnala Inserita: 6 gennaio 2016 Non conosco bene i protocolli KNX e SCS (per prendere i due sistemi "maggiori" che mi avevano proposto) ma sono previsti dispositivi che "si addormentano" per ridurre i consumi? Mi immaginavo che rimanessero semprealimentati.I protocolli KNX e SCS sono nati negli anni '90 e sono stati pensati per dispositivi collegati a un bus che fornisce loro un canale di comunicazione e l'alimentazione.Solo successivamente sono emersi i dispositivi domotici wireless e i loro protocolli i più noti dei quali sono ZigBee e ZWave.Indipendentemente dal tipo di comunicazione, sta diventando sempre più importante la riduzione dei consumi dei sistemi tecnologici di una casa.La riduzione dei consumi ha inizialmente affrontato la modalità stand-by degli elettrodomestici (con la tecnologia attuale si riesce a ridurre a 1 mW l'assorbimento in stand-by). Ora sono sotto osservazione quelle apparecchiature attive h24, come il modem-router VoIP, i moduli DALI, i moduli DMX, i sistemi di allarme e i sistemi domotici.Il rapporto costi/benefici determina l'accettabilità della spesa necessaria al funzionamento di questi dispositivi.L'assorbimento di qualche Watt dei dispositivi domotici può sembrare accettabile, ma se un sistema domotico ne contiene una decina, l'energia assorbita da un sistema domotico può diventare confrontabile con quella dei sistemi che supervisiona.Faccio un esempio concreto. Una abitazione in classe A può richiedere qualche kW termico per mantenere costante la temperatura interna. Nel mio caso, a temperature intorno ai 7 C, la potenza termica richiesta è circa 2 kW. Riscaldando casa con una PdC aria-acqua, a quelle temperature il COP è di circa 4, cioè la PdC assorbe circa 500 W per riscaldare casa. Se la domotica assorbisse complessivamente 50W, si potrebbe affermare che il sistema domotico fornisce il 10% del riscaldamento...Per questo motivo, meno moduli formano un sistema domotico, meglio è.Aggiungere gateway consente di integrare altri sistemi o tecnologie (es. wireless), ma i consumi ne risentono!Una architettura "tipo PLC", pur essendo antecedente a quella EIB-KNX o SCS, è più adatta a gestire moduli "addormentati" per ridurre i consumi.Poiché il PLC legge periodicamente gli ingressi, calcola il valore delle uscite e invia i relativi comandi di attuazione, consente ai moduli di I/O di addormentarsi, cioè di non eseguire i comandi ricevuti.Nel caso di un comando di lettura di un ingresso, si avrà un errore di comunicazione, ma il PLC dispone sempre del precedente valore dell'ingresso per i suoi calcoli.Nel caso di un comando di attuazione, l'uscita non sarà aggiornata, ma il PLC potrà aggiornarla lo stesso in seguito.Addormentando i moduli di I/O si avrà quindi il beneficio di ridurre i consumi al costo di una leggera riduzione della velocità di risposta del PLC agli stimoli esterni che nei sistemi domotici è spesso accettabile.Anche con gli SCADA non ho esperienza diretta. Lo SCADA sarebbe in questo caso il sistema che supervisiona quello domotico? O intendevi il contrario?Io intendevo il significato letterale di SCADA: Supervisory Control And Data AcquisitionAnche la gestione del sistema domotico con uno schermo touch o da smartphone è uno SCADA, perché se visualizza lo stato di accensione delle luci o la temperatura delle stanze, da qualche parte dovrà andarli a leggere...
del_user_56966 Inserita: 7 gennaio 2016 Segnala Inserita: 7 gennaio 2016 Concordo con la tua analisi EtaPhiOttima Analisi, mi trovo in accordo con EtaPhi e Livio...La mia esperienza deriva dall'industriale, non sono stato abituato "a tarare i protocolli" ma semmai i convertitori...all'inizio in epoca non sospetta...frequentando una presentazione EIB (oggi ribattezzato KNX) feci una domanda al tecnico di una nota casa che stava proponendo il sistema...la domanda era questa..."lei dice che i messaggi vengono inviati per evento e che se l'evento non viene ricevuto l'attuazione non viene eseguita?"il tecnico mi rispose che in un sistema ad eventi i messaggi non sono ripetuti all'infinito e quindi dopo alcuni tentativi una mancata attuazione è sempre possibile...allora feci la domanda successiva..."quindi se premo un pulsante e la luce non si accende?"la risposta fu questa... e la ricordo come se fosse adesso...semplice lei prema di nuovo il pulsante......il mio pensiero però non era rivolto all'accensione di una luce... ma alla mancata attuazione di una valvola, di un allarme gas, di un blocco caldaia ecc..in questi e altri 1000 casi una mancata attuazione... è improponibile...
smoothhands Inserita: 7 gennaio 2016 Autore Segnala Inserita: 7 gennaio 2016 Non posso che ringraziare EtaPhi per le interessanti considerazioni che ha condiviso sul forum.
smoothhands Inserita: 15 gennaio 2016 Autore Segnala Inserita: 15 gennaio 2016 (modificato) Visto l'importanza dei concetti e dei ragionamenti qui presentati volevo riprendere un attimol'argomento per precisare alcune cose. Spero che EtaPhi non me ne voglia anche perchèritengo quanto da lui espresso di notevole utilità e fondamentalmente corretto.Questa, ripeto a scanso di equivoci, è solamente una precisazione. Un protocollo di comunicazione non può essere ad eventi.Un protocollo di comunicazione è l'insieme di specifiche tecniche che contengono regole oaltre convenzioni al fine di scambiare informazione tra dispositivi attraverso un mezzo di comunicazione.Le specifiche riguardano il formato dei dati che vengono scambiati, il formato degli indirizzi, leregole di routing, la rilevazione di errori di trasmissione, controllo di sequenza e di flusso, etc...Tipici protocolli sono l'ormai famoso TCP/IP, il modbus TCP/RTU, e seguono tutti gli altri piùo meno proprietari. I problemi illustrati molto chiaramente da EtaPhi sono riconducibili invece al modello di interazione che avviene tra dispositivi appartenenti a un sistema domotico.Il modello di interazione, che viene utilizzato anche nel sistema KNX, è un modello a scambio di messaggi (i famositelegrammi) e la comunicazione, in generale, può essere di diversi tipi:sincrona: quando il mittente spedisce il messaggio ed attende sino a quando il ricevente non ha ricevuto il messaggio, elaborato la risposta ed inviata nuovamente al mittenteasinrona: quando il mittente spedisce il messaggio e continua ad effettuare le proprie operazioniremote invocation: quando il mittente aspetta che il ricevente sia pronto per ricevere e, solo dopo che ilricevente si è dato disponibile per ricevere, il mittente invia il messaggio.In base al tipo di comunicazione che viene utilizzata può sorgere il il problema 1 evidenziato da EtaPhi: ovveroil destinatario può uscire dal sistema e quindi non essere più raggiungibile. Diverso è il problema del punto 2 in quando riguarda questioni legate alle tecnologie di accesso al mezzo di trasmissione.In particolare alle tecniche per evitare le collisioni in sistemi ad accesso multiplo di una risorsa condivisa (il nostro bus).Questioni che mi pare di aver visto richiamare anche da Livio in alcune discussioni. Ora... non ho verificato quale particolare tecnologia utilizzi il KNX (a divisione di tempo, a divisione di frequenza, a divisionedi codice, etc...) ma il problema a quanto pare ce l'ha eccome.Nel caso del modbus invece, se ho capito bene, l'accesso non può essere multiplo perchè viene definito un master che chiede informazionia uno slave... che ha un certo tempo per rispondere (e qui si ricade nelle regole di interazione). Quindi non dovrebberoesserci pericoli di collisione sebbene i dispositivi si attestino tutti sullo stesso mezzo trasmissivo Questo voleva essere un esempio. Il punto 3 invece riguarda proprio il protocollo di comunicazione in quanto si parla proprio di definizione di dati scambiati. Per quanto riguarda la programmazione orientata agli eventi... qui si parla di paradigmi di programmazione.Citando wikipedia:Mentre in un programma tradizionale l'esecuzione delle istruzioni segue percorsi fissi, che si ramificano soltanto in punti ben determinati predefiniti dal programmatore, nei programmi scritti utilizzando la tecnica a eventi il flusso del programma è largamente determinato dal verificarsi di eventi esterni.[Si può pensare di]...eseguire all'infinito un loop di istruzioni all'interno del quale vi sono istruzioni che verificano continuamente la comparsa delle informazioni da elaborare [...] e quindi lanciare l'esecuzione della parte di programma scritta appositamente per gestire l'evento in questione.Gli eventi esterni a cui il programma deve reagire possono essere rilevati mediante polling (interrogazione) eseguito all'interno di un loop di programma, oppure in risposta ad un interrupt. In molte applicazioni si usa una combinazione di entrambe queste due tecniche.Ho visto associare programmazioni orientate agli eventi a sistemi real-time. Modificato: 15 gennaio 2016 da smoothhands
Microchip1967 Inserita: 16 gennaio 2016 Segnala Inserita: 16 gennaio 2016 (modificato) remote invocation: quando il mittente aspetta che il ricevente sia pronto per ricevere e, solo dopo che ilricevente si è dato disponibile per ricevere, il mittente invia il messaggio.In base al tipo di comunicazione che viene utilizzata può sorgere il il problema 1 evidenziato da EtaPhi: ovveroil destinatario può uscire dal sistema e quindi non essere più raggiungibile. Vorrei ricordare che su KNX i vari telegrammi hanno livelli di priorità programmabiliSe devo segnalare un blocco caldaia usero' il livello "alarm" che ha priorità sugli altri telegrammiSinceramente se dovessimo elimiare tutti i sistemi "ad eventi" dovremmo cominciare ad elimiare, ad esempio, la rete cellulare, la rete TCP-IP, e quant'altroDipende sempre da cosa uno deve fare.Un impianto di allarme per me deve essere "supervisionato", ovvero una centrale che esegue il polling (ed infatti una anti-intrusione su knx non la consiglio a nessuno, non è il suo uso)Un sistema domotico per casa puo' benissimo essere ad eventi. Modificato: 16 gennaio 2016 da Microchip1967
Livio Orsini Inserita: 16 gennaio 2016 Segnala Inserita: 16 gennaio 2016 Sinceramente se dovessimo elimiare tutti i sistemi "ad eventi" dovremmo cominciare ad elimiare, ad esempio, la rete cellulare, la rete TCP-IP, e quant'altro Difatti nelle zone con scarsa capacità delle celle, nelle ore di maggior traffico, spesso e volentieri gli utenti si trovano disconnessi improvvisamente dalla cella, specie se il collegamento è pittosto lungo.
smoothhands Inserita: 16 gennaio 2016 Autore Segnala Inserita: 16 gennaio 2016 (modificato) Sinceramente se dovessimo elimiare tutti i sistemi "ad eventi" dovremmo cominciare ad elimiare, ad esempio, la rete cellulare, la rete TCP-IPMi dispiace ma, anche se oramai nell'uso comune viene naturale chiamarla così, TCP/IP è un protocollo di comunicazione e nulla ha a che fare con "la rete" che è diventata a tutt'oggi una cosa molto complessa della quale sono previstidifferenti classificazioni in base a quale caratteristica si vuole evidenziare:- in base alla topologia (fisica e logica) - reti a stella, ad anello, grafo... broadcast...- in base al canale trasmissivo - la rete ethernet, doppino telefonico, fibra, wireless (i vari tipi)...- in base all'estensione geografica - PAN, LAN, MAN ...Non è il TCP/IP ad essere ad eventi ma probabilmente qualche meccanismo di segnalazione da parte di qualche schedao di qualche pezzo software dell'architettura di rete che chiede a un altro componente hardware o pezzo software di trattare un segnale, un messaggio o che altro... che intende inviargli.La rete cellulare, d'altro canto, è un qualcosa di estremamente complesso che sicuramente da qualche parteavrà qualche meccanismo gestito ad eventi ma sicuramente non può essere ad eventi nel suo complesso.Come giustamente Livio fa notare quando una stazione radio-base è congestionata è difficile poter telefonare.Puoi pensare a situazioni quali uno stadio di calcio oppure una manifestazione con tante persone.Il problema evidenziato è dovuto alla tecnica utilizzate per accedere al mezzo di comunicazione (che perdefinizione è una risorsa limitata e costosa) e metodo per evitare le collisioni. Poi, per come la vedo io, non ritengo che il sistema konnex sia un sistema da scartare a priori.La mia richiesta iniziale è proprio per capire le differenze a livello di architettura dei varisistemi domotici per poi poterli distinguere in base a qualcosa di più tecnico anzichè a qualcosa a un livello di sensazioni.Se poi il konnex ha, e continuerà ad avere, una diffusione come quella attuale evidentemente ha deipregi e dei campi di applicazione per i quali risulta essere una scelta naturale.Di solito quando ci sono dei possibili problemi si studia anche il modo di evitarli. Modificato: 16 gennaio 2016 da smoothhands
Microchip1967 Inserita: 16 gennaio 2016 Segnala Inserita: 16 gennaio 2016 Difatti nelle zone con scarsa capacità delle celle, nelle ore di maggior traffico, spesso e volentieri gli utenti si trovano disconnessi improvvisamente dalla cella, specie se il collegamento è pittosto lungo. Questo capita perchè gli utenti hanno una "priorità" normaleviceversa i sistemi gsm che usano le forse dell'ordine/sicurezza/soccorso hanno il flag di massima priorità, che prende la precedenza massima della comunicazioni.Ed infatti per loro la comunicazione è sempre garantita (come ad esepio per il 118 che riceve sempre il numero del chiamante e la localizzazione, indipendentemente da quanto settato dall'utente)Per quanto riguarda lo sgancio, è perchp semplicemente la cella è in saturazione e non ha piu' risorse disponibili.Se guardi a Fieramilano vedrai che è strapiena di piccole cella ad alta capacità per quanto riguarda TCP-IP, hai ragione, mi sono spiegato male... ma comunque anche in questo caso nei frames hai l'indirizzo ip del mittente e del destinatario e anche in questo caso hai l'invio dei dati e l'ascolto dell ACK da parte del mittente... se non riceve la risposta sarà poi il mittente a decidere cosa fare.p..s. sul KNX con collegamento TP i dispositivi sono sempre all'ascolto del traffico, e sono costantemente aggiornati sullo stato dei dati che li riguardano.Il punto critico puo' essere un "riavvio del sistema", ma basta impostare nei singoli moduli la ritrasmissione dello stato degli ingressi/uscite al ritorno dell'alimentazione (e si puo' impostare anche il ritardo dell'ìinvio) per riottere il "riallineamento" del sistema
Livio Orsini Inserita: 17 gennaio 2016 Segnala Inserita: 17 gennaio 2016 Questo capita perchè gli utenti hanno una "priorità" normale Appunto.Ma questo può capitare ache per utenze con priorità più elevata.Se c'è, per ipotesi, un solo "posto" ad alta priorità e 3 partecipanti ad alta priorità uno parla e gli altri attendono.Sarebbe differente se il sistema lavorasse in divisione di tempo come avviene, ad esempio, con i processsi di un sistema operativo in tempo reale. Anche i processi ad alta priorità hanno un tempo di accesso ben preciso, oltre al quale vengono sospesi. Questo garantisce che tutti i partecipanti abbiano sempre la possiiblità di accedere alla CPU.Per quanto riguarda lo sgancio, è perchp semplicemente la cella è in saturazione e non ha piu' risorse disponibili.Non è esattamente così; se lo fosse sarebbe solo impedito l'aggancio a nuovi partecipanti.E' un tentativo un po' rozzo di garantire l'accesso a tutti i partecipanti, però non essendoci, o non potendo esserci, una schedulazione l'accesso è sempre e comunque casuale.
del_user_56966 Inserita: 17 gennaio 2016 Segnala Inserita: 17 gennaio 2016 domotica ed eventi... é male?Rispondendo alla tua domanda direi che va scisso il problema tra eventi, hardware di comunicazione e protocolli specifici...l'evento per sua natura ha carattere positivo... ma nel caso applicato ha una specifica architettura va capito che negli esempi sopra esposti...la colpa di eventuali disservizi non sono da attribuire alla tecnologia ad eventi in se ma semmai alla sommatoria di questa con un hardware di comunicazione molto lento e all'architettura ormai datata... Con altre velocità e altre architetture l'evento è una risorsa importante nel controllo di applicazioni che utilizzano molteplici dispositivi distribuiti...
Livio Orsini Inserita: 17 gennaio 2016 Segnala Inserita: 17 gennaio 2016 Il problema è sempre il solito: quale può essere la massima latenza tollerabile?Se l'evento è memorizzato, anche se la latenza è molto lunga sarà comunque riconosciuto, altrimenti può andare perso.Anche assegnando le priorità non si ha la garanzia che un evento sia perso.
Messaggi consigliati
Crea un account o accedi per commentare
Devi essere un utente per poter lasciare un commento
Crea un account
Registrati per un nuovo account nella nostra comunità. è facile!
Registra un nuovo accountAccedi
Hai già un account? Accedi qui.
Accedi ora