Domotica Low Cost

[del_user_56966]

voglia di fare lunghi trattati e valutazioni (anche perche per quelle mi faccio pagare... )

ma almeno uno dei vari punti te lo accenno va!

nella tabella metti in impianti di tipo "tradizionale" anche Konnex e dichiari che è di tipo centralizzato!?

mentre il vostro è messo come distribuito!

mi pare che questo sia un errore madornale, KNX rispetto a concetrare su Embedded come quelli che vedo

sul sito è l'opposto esatto... e uno dei sistemi distribuiti per eccellenza (almeno come tipologia nativa).

Questo non può essere fatto passare come una svista...

[Giuseppe70]

in effetti anch'io lo vedo come un centralizzato, non si puo' pensare di mettere un modulo da 12 I/O per gestire due o tre utenze, il konnex invece e' sicuramente distribuito e con lo svantaggio che ogni componente deve essere konnex e non tradizionale, ed e' per questo che io preferisco il centralizzato, nelle abitazioni

[Giuseppe70]

comunque aleandro, in un discorso low cost mi piacerebbe che portassi esempi e idee palpabili, invece stai sempre a criticare, ma lavori per net o cugini ? porta degli esempi concreti, ad esempio potresti mettere cosa costa all'utente avere tutte le cose che offre un modulo come quello ma con componenti hplc altrimenti siamo sempre a parlare dell'aria fritta. si sta parlando di costi, buttiamoli dentro sti costi e facciamo un confronto

[del_user_56966]

cosa centra questo discorso?

se porti delle questioni su un forum le critiche su pregi/difetti e la norma....

altrimementi perchè postare delle risposte sarebbe un monologo...

poi perchè vuoi necessariamente portare il discorso su HomePLC??

per una volta ogni tanto che non ne parlo...

ma se proprio vuoi scegli tu l'argomento portando un esempio concreto in paragone, ma ti avverto quello

fatto sopra, ovvero pubblicità esplicita !!

non sarebbe permesso dal regolamento, anche se spesso è difficile esporre delle funzionalità

differenziandole dal fattore implicito che è di fatto è una forma di pubblicità per il prodotto...

[Giuseppe70]

sul regolamento non discuto e mi attengo a quello che dice, anzi per etica non ho menzionato neanche prezzi dei prodotti domotici che ho elencato, l'utente invece è stato corretto, si è presentato e ha anche chiesto che il suo post venisse cancellato se disturba, non è per mancanza di rispetto nei tuoi confronti ma le tue idee sposano ben poco un concetto di domotica low cost, non ti offendere ma non so neanche che ci fai e perchè spendi il tempo in una discussione simile, io ti ho etichettato come hplc perchè in tutti i tuoi interventi che ho letto e che leggo anche volentieri è lampante che il tuo prodotto è quello, rispetto anche le scelte e come già detto l'ho scelto anch'io in contesti di un certo tipo, ma non vedo solo quello.

questo discorso centra e molto, quello che ti ho chiesto per stare in termini di low cost è che mi fai una lista componenti e prezzi per arrivare a fare quello che un modulo come quello o come quelli che ho menzionato io all'inizio, sappiamo bene che i prezzi di listino ovviamente non sono quelli all'installatore, gli sconti del mercato chi è del settore li conosce bene e non è neanche giusto menzionarli in un forum aperto a tutti, quindi partiamo dai prezzi di listino no ?

qui un utente ti ha già dato un prezzo che trovi in un sito, se non erro sono 600 euro per il modulo 12 in e 12 relè e le varie caratteristiche che si possono vedere nella scheda tecnica.

con home plc o altri prodotti essi siano a quanto stiamo ? in, out, amperometrica per ogni carico, interfaccia ethernet ecc ecc, non guardare distribuito o centralizzato, parti già da un prodotto che come hai ben detto non può definirsi distribuito ma come ben sai anche home plc si può disporre in modo centralizzato...

poi ci sono i costi di posa cavi ecc che se vuoi valuteremo, discuteremo, ricordo comunque che la corrente con qualche filo agli utilizzatori bisogna pur portarla anche se si fa un distribuito....

partiamo dal centralizzato ? poi magari discutiamo dei pro e contro di entrambe le soluzioni ? poi magari mettiamo come base un appartamento tricamere o altro e sviluppiamo i costi per impianti completi ?

con me se vuoi trovi pane per i tuoi denti e da discussione calda la trasformiamo rimanendo pacati in una bollente ? sono sicuro che al riguardo troveremo molti interessati tra installatori, progettisti, appassionati e utenti, diciamo una tavola rotonda in nome del low cost ?

di prodotti ce ne sono un infinità e dopo anni di ricerche ancora mi capita di inciampare su qualcuno che non ho mai visto da tanti che ne escono, quindi abbiamo ampio spazio di discussione se vogliamo senza tirare in ballo pubblicità esplicita o meno che non siamo bambini su, siam qui per discutere e mi auguro anche per essere costruttivi.

[Giuseppe70]

anzi, partiamo proprio dalla domanda iniziale della discussione come base di confronto:

""Volendo proporre un sistema domotico (luci, tapparelle, dimmer, videocit, remotizzazione, touch pannel) devo trovare un marchio economico. L'appartamento è composto da 2 camere da letto, wc e zona giorno il tutto su 55m2. ""

parliamo di 9 luci ( 2 camere, bagno, specchiera, disimpegno, cucina, salotto, terrazzino,garage ), 5 tapparelle, videocitofono e touch di comando, ma ci aggiungo anche la termoregolazione per ogni zona, quindi calcolando una zona giorno da appartamentino direi 4 zone.

giù con le idee qualsiasi marchio certificato sia.

datemi il tempo di buttar giù due conti con sebastian e vi dico a quanto riuscirei a farlo in aggiunta di un tradizionale senza regalar niente.

P.S. a parte metterò anche il prezzo per l'allarme anche se non richiesto ma tanto per farlo completo e il controllo di almeno 3 carichi.

Modificato: 4 aprile 2013 da Giuseppe70

[nextime]

Aleandro, Giuseppe, ok, forse allora dobbiamo metterci d'accordo su cosa intendiamo per centralizzato e distribuito.

Da quel che ho capito ( correggetemi se sbaglio) voi intendete per distribuito ad esempio konnex perche' prevede tanti modulini I/O separati, mentre vedete il "mio" sistema come centralizzato perche' ha 12 ingressi, 12 uscite etc su un unico dispositivo. Ci sta, se ho capito bene ha una sua logica.

Io pero' per centralizzato e distribuito intendo un'altra cosa. Quello che intendo io e' questo:

Un sistema centralizzato e' dipendente da un punto centrale che gestisce le operazioni dei vari dispositivi, senza il quale si perdono funzionalita' di rilievo tali da rendere il sistema, seppur magari con funzioni minime ancora attive, molto meno funzionale. Insomma, e' centralizzato quando c'e' un single point of failure.

Ora, negli impianti KNX ( e nella maggior parte di quelli a bus) i moduli I/O sono "relativamente stupidi", nel senso che si, hanno un minimo di configurabilita', ma per lo piu' tutte le logiche di attuazione sono gestite da un server centrale senza il quale si perdono il 90% delle funzionalita' avanzate. E anche qui correggetemi se sbaglio!

Nelle "mie" schede, invece, la logica di funzionamento rimane sulle singole schede e NON dipendono dal server centrale, qualora il server centrale morisse si perde solo l'interfaccia web unificata ( che pero' e' anche distribuibile a sua volta ), ma la funzionalita' del sistema rimane per il 90% identica e non ci sono perdite di funzioni rilevanti.

In poche parole, quindi, voi parlate di centralizzazione/distribuzione a livello piu' "hw" o "fisico", mentre io parlo di centralizzazione e/o distribuzione piu' "sw", o "logico". Penso che sia questo il motivo di incomprensione sui termini usati nella mia comparazione...

Quindi in poche parole confermo che la mia tabella, stando alla mia definizione di "distribuito" e' corretta! Probabilmente l'incomprensione deriva dal mio background che arriva piu' dal mondo informatico che da quello elettrico.

Aleandro2008: mi rendo conto che il mio post puo' apparire come pubblicita' esplicita, e come ho esordito non nascondo che ovviamente il mio scopo e' anche in parte promozionale, chiedendo agli admin di modificare e/o eliminare il post se lo ritengono necessario. Tuttavia penso con la partecipazione attiva al thread di aver chiaramente dimostrato che non sono entrato nel discorso solo per scopi di promozione, ma anche e soprattutto per discutere e scambiarmi opinioni che ritengo comunque utili al discorso e anche a me per capire se le mie idee in proposito che hanno portato anche alla realizzazioen di un prodotto possono essere recepite, oltre che per lo scambio di vedute che ritengo sempre arricchire tutti, me in primis, sui pregi e difetti di quel che si fa.

Ad ogni modo ribadisco, se il mio approccio disturba qualcuno ditemelo, e se e' il caso capisco senza problemi anche la cancellazione e/o modifica dei miei post.

PS: non rispondero' al "preventivo" di esempio perche' in quel caso mi rendo conto che supererei la linea in cui diventerebbe spam esplicito e sgradito!

PS2: metto konnex tra i "tradizionali" perche' e' una tabella comparativa non tra impianto domotico e impianto tradizionale, ma tra impianto domotico fatto con il mio sistema e impianto domotico "tradizionale" ovvero a bus ( partendo dal presupposto che vedo la ethernet come innovativa in questo campo, e il bus come "il vecchio modo" ). Insomma, basta mettersi d'accordo sul significato dei termini probabilmente e ci capiamo meglio

Modificato: 4 aprile 2013 da nextime

[Livio Migliaresi]

il mio scopo e' anche in parte promozionale, chiedendo agli admin di modificare e/o eliminare il post se lo ritengono necessario. Tuttavia penso con la partecipazione attiva al thread di aver chiaramente dimostrato che non sono entrato nel discorso solo per scopi di promozione, ma anche e soprattutto per discutere...........

In parte un tuo messaggio è stato modificato; nel condividere quanto nella seconda parte, un augurio che la discussione possa mantenersi sempre sulla massima cordialità e correttezza.

P.S.: modificata la tua firma: regolamento

In firma e' solo consentito inserire NOME COGNOME USERNAME SALUTI

ed email <username>@plcforum.info con carattere di dimensione massima =5

P.S. 2: ciao Ale; ho scoperto un nuovo ristorantino!!!!!!!

[del_user_56966]

l'incomprensione deriva dal mio background che arriva piu' dal mondo informatico che da quello elettrico.

sai che non lo avevo mica notato!?...

I termini non si possono personalizzare a piacere, per impianti distribuiti si intende quelli che

distribuiscono nei vari locali cablaggio e logica, per centralizzato si intende quelli che centralizzano in un

unico quadro tutti i cablaggi e di conseguenza la logica!

[nextime]

Livio: ok, mi scuso per aver fatto l'italiano e non aver letto prima il regolamento. Spero che la firma ora vada bene, tecnicamente la parte in cui dico "developer e geek" non e' un saluto ma non penso che sia contrario al regolamento visto che non fa nessuna pubblicita' ne altro che possa dare fastidio, nel caso non vada bene ditemelo e lo rimuovo.

Aleandro: sono d'accordo che i termini non si possano utilizzare a piacere, ma nei limiti del vocabolario. Qui stiamo parlando di un sistema ibrido che unisce il mondo elettrico a quello informatico, nel mondo informatico la mia definizione e' quella corretta, nel mondo elettrico probabilmente e' piu comune la tua. Ma visto che in questo caso parliamo di un sistema a meta' strada, direi che sono corrette entrambe e che sia giusto specificare quindi cosa si intende. Anche perche' quando dici che "per centralizzato si intende un unico quadro con tutti i cablaggi e "di conseguenza" anche la logica" io non mi ci ritrovo per nulla, la logica e la parte fisica sono totalmente separate e indipendenti nel concetto di distribuzione. Se io ho 4 dispositivi anche ipoteticamente localizzati in un unico quadro possono avere una logica totalmente distribuita in quanto magari collaborano ma sono uno indipendente dall'altro e in grado di funzionare completamente stand-alone. Un sistema con dispositivi diffusi fisicamente invece puo' avere logica completamente centralizzata se dipendono da un server centrale.

Come vedi la mia definizione non e' scorretta, semplicemente sono due definizioni diverse normalmente utilizzati in ambiti differenti, e quando i due ambiti differenti si incrociano in un campo comune avvengono le incomprensioni....

Personalmente, per gli scopi per cui ho strutturato il sistema che ho fatto, e per i motivi per cui l'ho distribuito, l'accezione piu' corretta da usare, personalmente, credo sia quella di distribuzione logica ( i motivi sono assenza di single point of failure logico, la parte fisica e' meno rilevante e puo' anche essere fatta in maniera ridondante volendo ) per evitare appunto la centralizzazione su un server centro stella, che e' quello che mi fa dire che la maggior parte dei sistemi a bus sono invece centralizzati ( indipendentemente dalla diffusione o meno dei dispositivi fisici ).

Comunque sia, al di la delle opinioni personali, credo che ora sia chiaro cosa intendevo nella famosa tabella comparativa e quindi il fatto che, alla luce di quanto detto, sia corretta ( ammettendo che il mio uso di "distribuito" e "centralizzato" sia corretto )

Se poi vuoi approfondire la cosa sulle motivazioni per cui nel mondo da cui arrivo ( informatico ) e nel sistema che ho ideato si intenda la distribuzione in quel modo e la centralizzazione nell'altro, possiamo anche parlarne senza problemi

***

per favore adegua la firma come da regolamento.

Modificato: 5 aprile 2013 da Livio Migliaresi

[del_user_56966]

non ti offendere ma non so neanche che ci fai e perchè spendi il tempo in una discussione simile, io ti ho etichettato come hplc perchè in tutti i tuoi interventi che ho letto e che leggo anche volentieri è lampante che il tuo prodotto è quello,

ci mancherebbe, ci vuol ben altro per offendermi....

ora non mi pare che se sto parlando di KNX tu mi venga fuori con

"sai dato che ho letto i tuoi post su altre parti del Forum dovresti parlare di Homeplc!!"

almeno posso decidere io di cosa parlare?!!?

se ti può interessare posso parlare anche di altre 20 architetture di Domotica e altrettante Industriali

fino ai DCS... quindi la scelta della risposta da dare la attingo da un database personale di circa

32 anni d'automazione in vari campi...

questo discorso centra e molto, quello che ti ho chiesto per stare in termini di low cost è che mi fai una lista componenti e prezzi per arrivare a fare quello che un modulo come quello o come quelli che ho menzionato io all'inizio, sappiamo bene che i prezzi di listino ovviamente non sono quelli all'installatore, gli sconti del mercato chi è del settore li conosce bene e non è neanche giusto menzionarli in un forum aperto a tutti, quindi partiamo dai prezzi di listino no ?

fare un approccio con i prezzi di listino non serve che a confondere le idee, tutto dipende dagli sconti

applicati se un prodotto ha il 15% di sconto da listino e l'altro il 55-60% cambia tutto...

quindi risulta molto difficile poter far capire cosa costa meno sparando cifre a caso...

QUI ho già riassunto come si deve valutare un lavoro dall'A alla Z, e anticipato che il costo del solo

materiale non è essenziale, ci sono sistemi dove il materiale costa 10 e la programmazione /messa in

marcia costa 15 e poi ci sono anche quelli che il cliente maledice il giorno che li ha istallati...

per esempio su questo punto ho un personale record tipo ZERO problemi

che in questo settore per chi lo conosce a fondo già la dice...lunga!!

poi ci sono i costi di posa cavi ecc che se vuoi valuteremo, discuteremo, ricordo comunque che la corrente con qualche filo agli utilizzatori bisogna pur portarla anche se si fa un distribuito....

si ma si passa da migliaia di metri di rame a poche decine di metri...

e anche il rame oggi costa molto caro! (quindi va messo nel conto) poi ci sono i quadri elettrici che

devi mettere se gli apparati sono ingombranti e non si possono mettere nelle 503... ecc..

e in una casa di 55M2 sinceramente oltre che fuorni norma è anche improbabile trovare gli spazi...

con me se vuoi trovi pane per i tuoi denti e da discussione calda la trasformiamo rimanendo pacati in una bollente ? sono sicuro che al riguardo troveremo molti interessati tra installatori, progettisti, appassionati e utenti, diciamo una tavola rotonda in nome del low cost ?

be! se è pane che vuoi.... con me su Internet puoi trovare più di 40.000 discussioni in merito ...

quindi accomodati, ma ricorda la risposta la scelgo sempre e solo io...

OT

Ciao Livio... bene bene...!! segna che poi lo testiamo...

Fine OT

[del_user_56966]

Comunque sia, al di la delle opinioni personali, credo che ora sia chiaro cosa intendevo nella famosa tabella comparativa

quello era solo un esempio, non mi piace ribattere punto per punto quello che considero errato...

se per te è tutto OK, fino a che qualcuno dei tuoi clienti non ti porrà obiezioni va bene cosi...

a meno che anche tu non voglia lanciare sfide "alla modi" Giuseppe...

se invece hai pazienza saranno i clienti stessi a darti ragione o torto sulle scelte operate...

questo è un bel settore...

se fai bene capita anche (raramente) di avere complimenti

se invece fai male vai dritto in tribunale...

[nextime]

Aleandro:

be un esempio che spero ora sia chiaro!

Comunque no, non sono tipo da "Sfide" di questo genere, non mi interessano proprio

Semmai quello che mi interessa e' confrontarsi, perche', ribadisco come ho gia' detto, sono convinto che arricchisca tutti i partecipanti farlo, sempre e comunque se il confronto e' onesto ed educato!

Per quanto riguarda i clienti... al momento posso dire che sono pure io a zero lamentele e tanti complimenti, per i tribunali spero di non finirci mai, ma penso anche di aver fatto tutte le cose a modino per evitarlo ( e penso anche di essere ben oltre il minimo sindacale)

Ad ogni modo, non pretenod che tu faccia le tue critiche per forza, ovviamente, ma ribadisco che se vuoi/hai voglia/ti interessa farle, io non posso che esserne felice: lo considero come un'occasione per migliorare se non altro quantomeno la comunicazione e il modo di far passare i messaggi che intendevo far passare ( ad esempio sto pensando come modificare la parte relativa alla distribuzione per evitare i fraintendimenti come quelli gia' discussi, ma rimanendo nel concetto che volevo esprimere e che a me sembrava tanto chiaro e ovvio ).

Io credo sinceramente e veramente, al di la dei discorsi commerciali, di aver fatto un bel sistema, anche parecchio innovativo per molti aspetti, ma ovviamente non pretendo che sia perfetto e/o possa piacere a tutti, ma se non si discute onestamente con persone che, per quanto io possa saperne, sono competenti al fine di migliorarsi, come si puo' pretendere di raggiungere i livelli di eccellenza che sono il mio obiettivo?

Aggiungo una piccola nota:

ho già riassunto come si deve valutare un lavoro dall'A alla Z, e anticipato che il costo del solo

materiale non è essenziale, ci sono sistemi dove il materiale costa 10 e la programmazione /messa in

marcia costa 15

Ecco, quello della "programmazione" ( o piu correttamente configurazione ) e' proprio uno dei punti su cui sono fermamente convinto che il sistema che produco sia superiore e di molto confronto agli altri. Non devi installare nessun software dedicato, fai tutto via web, anche in remoto, e, come si suol dire in gergo tra informatici, "a prova di scimmia" e in maniera rapidissima e facilissima. Al punto che, volendo e ammettendo che il cliente non sia proprio a digiuno dell'uso del web, sosteniamo in maniera convinta che anche l'utente finale, volendo, potrebbe riconfigurarsi il sistema in autonomia ( nei limiti di quel che l'installatore si accorda per permettergli di fare, onde evitare i tribunali di cui sopra in certi casi! )

Ovviamente questa semplicita' di configurazione si traduce anche in costi irrisori in questa parte... ( sia economici che di tempo! )

Modificato: 5 aprile 2013 da nextime

[del_user_56966]

Ecco, quello della "programmazione" ( o piu correttamente configurazione )

OK, quindi non si programma realmente ma si configura... nessun linguaggio standard?

ma mi pareva di capire da qualche parte che l'utente non era legato al produttore, se il programma

Web o non Web non rispetta alcuno standard è una cosa vostra personale?

ne date almeno i sorgenti open?..... perchè in caso diverso l'utente sarebbe legato mani e piedi

ancora di più che con altri programmi e linguaggi più noti e utilizzati a livello internazionale...

[EtaPhi]

Ho cercato di capire il funzionamento del sistema UnixMedia leggendo la documentazione presente nel loro sito.

Forse mi è sfuggito qualcosa di importante, perché non sono stato così colpito da volerlo utilizzare nella mia casa da ristrutturare.

Una rete TCP/IP collega i moduli del sistema. Questa scelta dei progettisti ha il vantaggio di usare una tecnologia di uso comune, ma ha anche dei difetti.

Un difetto è il costo: una rete RS 485 costa meno perché può usare gli stessi cavi UTP ma è meno "pesante" come risorse hardware e software richieste.

Una rete RS 485 è sicuramente meno veloce, ma ciò ha come controparte una maggiore estensione della rete: fino a 1200 metri senza l'uso di ripetitori o altri dispositivi permanentemente accesi.

La limitata velocità di una rete RS 485 non consente ovviamente di trasmettere contenuti multimediali contemporaneamente all'automazione della casa.

Questo non è un problema perché multimedia e automazione hanno esigenze così contrastanti da suggerire l'uso di reti separate: RS 485 per l'automazione e TCP/IP per il multimedia.

L'uso di una rete TCP/IP sia per l'automazione che per il multimedia espone il sistema agli attacchi via rete che è per me un altro difetto.

Per proteggersi è ovviamente indispensabile usare un firewall, ma ciò potrebbe aumentare il numero di dispositivi permanentemente accesi e non garantisce al 100% perchè la sicurezza del il firewall può avere delle falle.

Il protocollo IKAP usa una protezione crittografica per garantire la sicurezza anche in caso di compromissione del firewall.

Ciò ha alcuni effetti negativi: servono più risorse elaborative per la comunicazione (e quindi si hanno costi e consumi maggiori).

Anche la più impenetrabile protezione crittografica non garantisce tuttavia il sistema contro un attacco di tipo DoS (denial of service).

Una rete RS 485 non ha queste limitazioni perché è fisicamente distinta e perché i progettisti possono realizzare un insieme di procedure automatiche di rilevamento degli attacchi.

Non a caso, la maggioranza dei sistemi di sicurezza certificati usa una rete RS 485.

L'architettura ricorda molto quella del sistema KNX: un sensore rileva un segnale o un'azione dell'utente e reagisce inviando uno o più messaggi.

I dispositivi che riconoscono il messaggio eseguono un'azione (es. attuando un'uscita o inviando altri messaggi).

Forse ciò è una limitazione. Per me è un difetto perché la gestione degli ingressi (cioè cosa accade quando varia un ingresso) è pre-cablata.

Un esempio può forse spiegare cosa intendo.

Per avere l'assorbimento "ufficiale" di un impianto elettrico è possibile misurare la frequenza degli impulsi luminosi emessi da un contatore elettonico.

Più sono frequenti, maggiore è l'assobimento.

Poiché un DMVR3 non misura il tempo tra due impulsi, non è quindi possibile rilevare la potenza misurata dal contatore elettronico che realmente decide quando distaccare la fornitura elettrica.

I progettisti potranno sicuramente ovviare a questa limitazione in una prossima versione del firmware o della documentazione, ma non potranno soddisfare tutti gli usi con logiche pre-cablate...

Non mi convince anche la scelta di concentrare così tanti ingressi e uscite in un unico modulo.

Tale scelta è sicuramente giustificata dai costi, perché distribuisce il maggiore costo delle risorse di comunicazione e di elaborazione su un maggiore numero di I/O.

Tuttavia costringe a concentrare gli I/O, cioè costringe a usare cavi più lunghi per collegare gli I/O aumentando il rischio di interferenze, specie per gli ingressi analogici.

Non mi piace la scelta di avere un micro-pc (non importa se il suo sistema operativo è Linux invece di Windows) per avere funzionalità "evolute".

Queste funzioni sono tipiche di uno SCADA che non deve essere indispensabile per l'automazione della casa.

UnixMedia afferma che un micro-pc non è indispensabile se si rinuncia alle funzionalità "evolute"...

Il controllore DMQmini è un Raspberry Pi più il suo contenitore che posso acquistare per 40 euro circa.

UnixMedia lo vende a 300 euro.

La differenza di prezzo è ovviamente dovuta al software pre-installato che, essendo principalmente Open-Source, dovrebbe essere quasi gratis...

Tutte queste cose non mi convincono, ma le mie impressioni potrebbero cambiare con il tempo perché il sistema UnixMedia mi sembra ancora giovane...

[nextime]

Aleandro2008:

Allora, parlando di configurazione parlavo in generale non solo riferito al nostro sistema, normalmente quando gli installatori in ambito domotico parlando di programmazione, lo fanno in maniera impropria e sarebbe piu' giusto parlare di configurazione appunto, ed era a questo che mi riferivo.

Detto questo, per quel che riguarda il sistema che produco, il discorso e' cosi:

Il sistema e' pronto all'uso out-of-the box e quindi basta solo una configurazione e non serve agire come programmazione per usarlo. La configurazione avviene completamente con dei form web guidati, e quindi non e' necessario appunto scrivere codice in nessun linguaggio di programmazione.

Poi il fatto che non sia necessario non significa che non si possa farlo!

In effetti poi e' possibile interfacciarsi con il sistema in diversi modi e a diversi livelli tramite apposite API, disponibili sia per diversi linguaggi che come web service a cui interfacciarsi, il tutto utilizzando standard ben definiti ( es: per le api web sono fornite via WebSocket, Wamp, restfull api json ).

Per le parti poi integrate, tipo chesso' per dirne una la telefonia, usiamo protocolli noti e standard ( es: SIP ) etc etc.

Per quanto riguarda i sorgenti, l'unica parte closed source e' il firmware della scheda, che ha tutti i modi possibili per essere riconfigurata e interfacciata come dicevo sopra in maniera del tutto aperta ad ogni modo. Per quanto riguarda il resto dei software ( web server etc ) e' tutto open source e sotto licenze libere. Le api e le librerie di interfacciamento anche.

La videosorveglianza, il centralino telefonico, il mediaserver etc sono tutti fatti con software open source piuttosto noti ( asterisk, xbmc, zoneminder ) con delle nostre patch e/o modifiche di cui sono pienamente disponibili i sorgenti quando non sono inclusi proprio negli upstream.

Tutti le interfacce sono templatizzabiliu a livello grafico con metodi standard.

Il punto mio appunto era solo: un installatore non programma, installa e configura. Chi programma e' il programmatore o l'integratore, non confondiamo le due cose!

[nextime]

EtaPhi:

Allora, prima di tutto sicuramente un lato in cui siamo ancora carenti sul sito e' la documentazione, stiamo lavorando per mettere online tutti i manuali etc, ma ci vorra' ancora un po' di tempo... ( sono disponibili ma non nella maniera idonea al web, e stiamo facendo un lavoro di riscrittura e correzione per metterli online ), quindi mi scuso per questo.

Un difetto è il costo: una rete RS 485 costa meno perché può usare gli stessi cavi UTP ma è meno "pesante" come risorse hardware e software richieste.

In linea generale e' vero, ma, qualche switch a parte, il resto lo fanno gia' i nostri dispositivi quindi non c'e' problema da questo punto di vista, e bisogna considerare che molti dispositivi commerciali

( telecamere, telefoni VoIP etc ) sono gia' su rete ethernet IP, quindi se da un lato forse puo' essere un po' piu' pesante, dall'altro si evitano 2 reti separate da stendere...

Inoltre occorre considerare che le reti lan sono comunque sempre piu' diffuse indipendentemente dall'automazione domestica o meno presente...

Una rete RS 485 è sicuramente meno veloce, ma ciò ha come controparte una maggiore estensione della rete: fino a 1200 metri senza l'uso di ripetitori o altri dispositivi permanentemente accesi.

Verissimo. Ma appunto ha problemi di velocita' e, grazie alle sue limitazioni di banda e altro, spesso i protocolli che ci passano sopra sono anche molto meno sicuri ( crittografia autenticazione e simili sono piu' blande, se presenti ).

Ad ogni modo quando e se occorrono rilanci di lunga portata si possono usare diverse tecniche tramite appositi gateway, tra cui anche rs485 ma anche fibra ottica e altri, per fare rilanci di lunga portata in termini di distanze, quindi e' in realta' un non problema.

La limitata velocità di una rete RS 485 non consente ovviamente di trasmettere contenuti multimediali contemporaneamente all'automazione della casa.

Questo non è un problema perché multimedia e automazione hanno esigenze così contrastanti da suggerire l'uso di reti separate: RS 485 per l'automazione e TCP/IP per il multimedia.

Io penso invece che sia meglio avere un solo trasporto ( una sola rete fisica quindi ) e poi la separazione avvenga solo a livello di protocolli ed eventualmente a livello logico. Questo da maggiore flessibilita' anche nelle modifiche future, abbassa i costi complessivi, e rende il tutto piu' "riconfigurabile" senza interventi fisici, oltre che piu' semplice e meno prono a rotture.

'uso di una rete TCP/IP sia per l'automazione che per il multimedia espone il sistema agli attacchi via rete che è per me un altro difetto.

Qui la vedo diametralmente opposto.

La rete TCP/IP non significa per forza esposta all'esterno. Puo' essere una rete fisicamente isolata, oppure anche semplicemente isolata a livello logico ( VLAN e altre tecniche ), e quindi con lo stesso livello di sicurezza confronto all'esterno di una rete a bus seriale.

Al contrario, a livello software una rete su IP ha la possibilita' di essere molto piu' sicura:

- La maggiore disponibilita' di banda permette l'uso di sistemi di autenticazione e crittografia piu' evoluti e quindi anche piu' sicuri

- L'utilizzo di ip da accesso a tutti i sistemi e meccanismi di sicurezza sviluppati negli anni in ambito informatico, che sono notevolmente piu' evoluti e sofisticati di quelli sviluppati in ambito bus seriali.

Per il discorso firewall, il discorso e' esattamente equivalente a una rete rs485 o altro bus che abbia un gateway che poi la espone su internet: quel gateway lavora a tutti gli effetti come firewall: se quello viene "bucato" automaticamente si puo' operare sulla rete a bus iniettando comandi etc etc. Quindi da quel punto di vista non c'e' reale differenza, se non che una volta bypassato il "firewall" in una rete a bus spesso ci si trova in una rete considerata trusted e quindi con un livello di sicurezza inferiore, mentre nella rete IKAP il livello di sicurezza e' lo stesso fino all'ultimo dispositivo...

Vorrei ricordare i famosi virus per sistemi SCADA che sono circolati in IRAN ultimamente a memoria per ricordare che gli attacchi sono si possibili anche sulle reti != da quelle ethernet, eccome...

Per avere l'assorbimento "ufficiale" di un impianto elettrico è possibile misurare la frequenza degli impulsi luminosi emessi da un contatore elettonico.

Abbiamo l'apposito modulino anche per questo

Non ho ben capito cosa intendi per gestione pre-cablata. Perche' da un lato e' vero e ovvio che un tasto e' un tasto, e va cablato. Dall'altro e' vero che la logica e' totalmente riconfigurabile in qualsiasi momento dinamicamente via web... Mi spieghi meglio cosa intendi in questo punto del discorso che non mi e' chiaro?

Non mi convince anche la scelta di concentrare così tanti ingressi e uscite in un unico modulo.

Si, la scelta' e stata quella di sfruttare maggiormente le MCU per abbattere i costi e i consumi complessivi il piu' possibile. Abbiamo in realta' anche dei moduli con meno I/O e minori dimensioni ( non ancora online ) e ne stiamo progettando altri, ma il costo per singolo ingresso si alza. Per le distanze, sono comunque tutte progettate per funzionare anche in presenza di interferenze sulle distanze di 100 metri, anche se noi le dichiariamo per 50 metri ( tendenzialmente tutte le limitazioni che diamo come distanze portate e altro sono al 50% di quelle reali ).

Non mi piace la scelta di avere un micro-pc (non importa se il suo sistema operativo è Linux invece di Windows) per avere funzionalità "evolute".

Questa non e' stata una scelta, ma un obbligo. Non potevamo mica mettere un arm a 1 Ghz da 1W di consumo su ogni scheda I/O, altrimenti i costi e i consumi sarebbero stati ben diversi ( e anche il livello di rotture potenziali... ).

Un centralino telefonico asterisk necessita di maggiori risorse, quindi per questa funzionalita' ( che e' una di quelle che noi consideriamo "evolute" ) e' necessario avere una macchina piu' potente a disposizione. Il telefono voip funziona anche in assenza di centralino

se opportunamente configurato, ma alcune funzioni come la voicemail ad esempio senza centralino non c'e'....

Poi il sistema confermo funziona anche senza funzioni "evolute", gli scenari sono comunque dispobili, l'uso normale e' comunque disponibile, etc etc. Il confronto e' che, per quel che ne so, in un sistema domotico "tradizionale" ( a bus ) circa il 90% delle logiche sono in una centralina "centrale" ( permettetemi l'impiccio lessicale ), da noi sono il 10%...

Per il controlle DMQmini, si, e' un RPi che puoi acquistare per 40 euro circa. Poi devi aggiungere 16 euro circa per la wifi. E altri 15 per l'alimentatore. E altri 40 per il cape con l'RTC. E altri 10 per la scatola. ( a quanto siamo arrivati? ). Ah, dimenticavo. Vorrai mica usare una SDCard che rischia di rompersi in un paio di anni vero? Quindi ne serve una industriale. Aggiungiamo minimo minimo altri 50 euro...

Poi si, c'e' anche il software, ovviamente. Il software E' gratis, se ti scarichi i sorgenti, te lo compili per arm, te lo installi e te lo configuri da solo! ( i sorgenti sono tutti disponibili ). Se dobbiamo farlo noi per te permetti che non siamo una onlus, vero?

Piuttosto considera che, se hai le competenze per installartelo e integrartelo da solo su una macchina linux, RPi o altro che sia, ce l'hai gratis anche se noi investiamo risorse per svilupparlo ( non ci limitiamo a prendere software open source e ad installarlo, ma collaboriamo attivamente al suo sviluppo! ), e quindi di fatto addirittura in certi casi "regaliamo" il nostro lavoro...

Modificato: 5 aprile 2013 da nextime

[Giuseppe70]

wow, la cosa si fa interessante

aleandro se leggi bene non ho scritto come mi hai citato che "devi" parlare di hplc ma che è evidente che il tuo prodotto di riferimento,, o preferito, è quello, il discorso prezzi non era una sfida ma semmai un modo per confronti reali ma meglio così, in effetti non si può quantificare anche se i prezzi di listino son quelli su cui ci si basa sempre e i prezzi io non li faccio mai sparando cifre a caso... ed è già quantificato tutto, anzi, i preventivi che ho sempre fatto mettevano il solo impianto tradizionale e il prezzo aggiuntivo per quello integrato con tanto di specifiche voce per voce..... insomma non al kg

per pane per i tuoi denti si intende aver trovato chi gli piace dedicarsi a queste discussioni e non di certo in riferimento alla tua competenza in materia mi raccomando di non tirartela troppo però eh

per tornare un attimo sul discorso centralizzato o distribuito, io prediligo il centralizzato per una serie di motivi che ho già ampiamente spiegato, condivisibile o meno che sia, il prodotto UnixMedia visto così a me piace proprio perchè è un centralizzato, che poi i moduli si possano decentralizzare in vari punti non lo fa comunque un distribuito, nextime penso di aver capito il tuo concetto ma non è quello che si è sempre inteso nel settore.

aleandro, tra distribuito e centralizato volevo approfondire questo

citazione

""

si ma si passa da migliaia di metri di rame a poche decine di metri...

e anche il rame oggi costa molto caro! (quindi va messo nel conto) poi ci sono i quadri elettrici che

devi mettere se gli apparati sono ingombranti e non si possono mettere nelle 503... ecc..

e in una casa di 55M2 sinceramente oltre che fuorni norma è anche improbabile trovare gli spazi... ""

sistemi molto noti nati espressamente per il civile alle prime presentazioni e per un bel po di tempo affermavano in ogni dove che un sistema domotico permetteva anche di risparmiare filo, ogni volta che lo sento dire mi irrito perchè se è vero in un contesto industriale,commerciale o comunque di grandi dimensioni non è vero in un contesto civile, per di più su contesti piccoli come gli appartamenti, fase neutro e terra agli utilizzatori deve comunque arrivarci e le metrature spese sono quelle, in più si deve distribuire anche il bus che va da un pulsante all'altro, termostati e via dicendo, ne risulta che di cavi ce ne sono di più e non di meno ( il bus ), in un centralizzato con pulsanti classici tradizionali da mettere in conto ci sono i ritorni, ma che sono comunque 1 per stanza e i fili rimangono lo stesso numero che ci sarebbero con deviate ed invertite.... il cavo costa eccome, ma non è che il cavo bus te lo regalino anzi, nello specifico poi stiamo parlando appunto di piccoli contesti nella maggior parte dei casi su un solo piano dove le metrature non sono poi così esagerate da poter parlare di migliaia e migliaia di metri, in molti casi invece di filo se ne risparmia pure come nel caso dei termostati ad esempio dove potrei avere il centralino più vicino sia alla caldaia che alle valvole di zona eliminando anche il cavo che va ai termostati usando una semplice sonda....

ci sono poi sistemi definiti distribuiti ma che in realtà lavorano con moduli da 2 o 4 ingressi che devono essere messi da qualche parte e non di certo nella 503, quindi necessitano di varie scatole di derivazione e già la progettazione dell'impianto diventa più complessa.

quando parlo di buona predisposizione mi riferisco in generale inclusa la struttura dell'abitazione stessa perchè è verissimo che in case piccole è difficile trovare lo spazio ma un centralino voglia o non voglia glielo devi mettere, e metterne 1 da 12 moduli piuttosto che un altro non ti cambia assolutamente niente, diverso invece se ti servono scatole di derivazione a destra e a manca, nel mio caso poi stiamo parlando di moduli che offrono ben 8 in 8 out ingresso 2 zone temperatura 1 ingresso crepuscolare il tutto su 4 moduli, prendi l'appartamentino da 2 o tre camere come nell'esempio e ti rendi conto di quanto posto ti serve....

in pratica è come fare un impianto a relè dove di mezzo hai i moduli.

il discorso degli spazi non è colpa di un sistema piuttosto che di un altro, piuttosto delle imprese edili che ormai non san più su cosa risparmiare, se stiamo a ben vedere per farlo ad hoc un impianto la domotica neanche ci entra su un appartamento se contiamo la mole di tubi idraulici che negli anni son cresciuti di numero.... una volta ad un idraulico che doveva mettere le cassette di riscaldamento, l'impianto clima e quello di aspirazione centralizzata gli ho chiesto se aveva già deciso che io l'impianto dovevo farlo in giardino o con scatole di derivazione a soffitto anche loro han i loro problemi in questo senso, e anche di più.

mi spieghi perchè dici che in un appartamento come questo il tutto non sarebbe a norma ? in base a cosa ? poi in queste discussioni è anche difficile far palpare con mano la facilità o meno di programmazione o configurazione di un impianto, quindi ci dovremmo basare su quello che ognuno scrive,

per nextime, ho la possibilità di farti domande qui in merito al vostro prodotto con esempi pratici di quello che avrei in mente ?

[Giuseppe70]

ecco, se proprio non vogliamo parlare di prezzi parliamo degli ingombri e disposizione dell'impianto ?

[EtaPhi]

In linea generale e' vero, ma, qualche switch a parte, il resto lo fanno gia' i nostri dispositivi quindi non c'e' problema da questo punto di vista, e bisogna considerare che molti dispositivi commerciali ( telecamere, telefoni VoIP etc ) sono gia' su rete ethernet IP, quindi se da un lato forse puo' essere un po' piu' pesante, dall'altro si evitano 2 reti separate da stendere...

La distinzione tra bus di campo e bus generici (su cui transitano contenuti multimediali) è un fatto consolidato nel mondo dell'automazione.

Anche se recentemente si usa l'hardware ethernet per i bus di campo (es. EtherCat), non è pensabile usare un bus unico.

Il motivo è semplice: l'automazione richiede la trasmissione di pochi dati ad intervalli di tempo inderogabilmente fissati (qualche ms o centinaia di microsecondi).

I contenuti multimediali possono invece "attendere" qualche ms purché il mezzo di comunicazione sia sufficientemente rapido da far arrivare i dati quando servono.

Se una telecamera IP perde un frame, non accade niente di pericoloso.

Se lo stesso accade per un sistema di automazione (es. l'ABS di un'automobile), il risultato può essere disastroso...

Per questo motivo, senza che sia garantito il funzionamento anche in caso di guasto dei componenti hardware e software, un bus unico è percepito come un rischio.

Non a caso, sta destando preoccupazione la possibilità compromettere il funzionamento del bus di campo CAN attraverso i gadget multimediali (es. connessione bluetooth) di cui le nuove automobili sono dotate.

Se quindi è possibile eliminare a priori ogni rischio, perché non farlo?

Qui la vedo diametralmente opposto.

La rete TCP/IP non significa per forza esposta all'esterno. Puo' essere una rete fisicamente isolata, oppure anche semplicemente isolata a livello logico ( VLAN e altre tecniche ), e quindi con lo stesso livello di sicurezza confronto all'esterno di una rete a bus seriale.

La sicurezza di un sistema non dipende esclusivamente dall'uso di un algoritmo crittografico forte.

In questo campo non è possibile generalizzare dicendo che una rete TCP/IP è più sicura di una RS 485 perché può usare algoritmi più sofisticati.

Qualche anno fa, ho realizzato un progetto interamente open-source (compresi il firmware e gli schemi) basato su un bus RS 485 che non ha bisogno di proteggere il traffico dati per garantire la sicurezza.

In quel sistema è impossibile iniettare comandi perché il sistema funziona senza aver bisogno di comandi!

La logica è completamente distribuita sui microcontrollori a 8 bit che controllano le uscite.

Nonostante questo, esiste un gateway (anch'esso realizzato con un microcontrollore a 8 bit) che "virtualizza" l'intera rete facendola apparire come un'unico sistema di automazione.

Quel sistema domotico è però così radicalmente diverso da tutti gli altri che non ha avuto seguito.

Ha tuttavia dimostrato che è possibile eseguire in multitasking i tre processi indipendenti che controllano un dispositivo con soli 384 byte di RAM e 8192 byte di codice.

Con le stesse risorse, dubito che si possa gestire una rete TCP/IP...

Quei dispositivi sono molto economici (qualche decina di euro per gestire 4 ingressi e 4 uscite) e dimostrano che non è il costo a determinare il successo commerciale di un sistema domotico.

Se quindi facciamo la gara a trovare la soluzione più economica, io ho un vantaggio di almeno un ordine di grandezza che mi consente di stendere un cavo UTP in più per garantire maggiore sicurezza allo stesso prezzo...

Non ho ben capito cosa intendi per gestione pre-cablata

La gestione pre-cablata degli ingressi è un punto debole di quel sistema, ma anche di quello di UnixMedia.

Il concetto è semplice: come reagisce il sistema agli ingressi?

Nel mio sistema, una variazione degli ingressi attiva la funzione di transizione di stato che è associata all'ingresso.

Nel DMVR3 gli ingressi attivano una delle funzioni: "Pulsante", "Cambio", "ApertoSempre", "ChiusoSempre", "DoppioClick", "PulsanteELunga", "TriploClick", "ApertoChiuso", "ContinuoApertoChiuso", "ImpulsoAperto", "ContaImpulsoAperto", "ImpulsoChiuso", "ContaImpulsoChiuso", "ImpulsoApertoDoppio", "ImpulsoChiusoDoppio", "Seq2", "Seq2Step", "Seq3" e "Seq3Step" (spero di averle elencate tutte).

Per avere i comportamenti che non rientrano tra quelli "pre-codificati" (come nel mio precedente esempio) esistono dei modulini...

Dato che non ho i sorgenti del firmware, se serve un qualcosa "fuori-standard", devo aspettare una nuova release del firmware o acquistare dei modulini!

[nextime]

Giuseppe70:

per tornare un attimo sul discorso centralizzato o distribuito, io prediligo il centralizzato per una serie di motivi che ho già ampiamente spiegato, condivisibile o meno che sia, il prodotto UnixMedia visto così a me piace proprio perchè è un centralizzato, che poi i moduli si possano decentralizzare in vari punti non lo fa comunque un distribuito, nextime penso di aver capito il tuo concetto ma non è quello che si è sempre inteso nel settore.

Be ma tu stai parlando di settore impiantistica elettrica. La domotica va ben oltre ed entra in altri settori come l'automazione informatica dove invece si intende come dico io. Qual'e' quello giusto? Diciamo che da ora in poi ( e correggero' in tal senso anche le mie tabelle comparative ) parlero' di distribuzione applicativa, cosi' penso che sia piu' chiaro il concetto, perche' considero la distribuzione a quel livello essenziale e un punto di forza importante del mio sistema, non posso quindi andare a dire una cosa secondo me non corretta ( ovvero che knx sia distribuito e il mio centralizzato, a livello applicativo rimane vero l'esatto opposto! )

per nextime, ho la possibilità di farti domande qui in merito al vostro prodotto con esempi pratici di quello che avrei in mente ?

Assolutamente si, se andiamo troppo nel dettaglio e rischiamo di sconfinare nella promozione e/o spam semmai ci si sposta in privato, ma fino a quando e' possibile preferisco in pubblica e mi fa solo piacere discuterne perche' aiuta anche a me a capire quali siano i dubbi che devo chiarire meglio sul sito!

[nextime]

La distinzione tra bus di campo e bus generici (su cui transitano contenuti multimediali) è un fatto consolidato nel mondo dell'automazione.

Anche se recentemente si usa l'hardware ethernet per i bus di campo (es. EtherCat), non è pensabile usare un bus unico.

Che sia un fatto consolidato non significa che non sia ora di cambiarlo perche' obsoleto

Che non sia pensabile sinceramente non capisco perche', o meglio, capisco in determinati ambienti ( industriale ) dove sono necessarie latenze bassissime nell'ordine dei usec, ma in ambito civile se io premo un pulsante e la luce si accende dopo 20ms non direi che e' un problema, e quindi una normale comunicazione su ip va benissimo. Esistono poi modi per abbassare quelle latenze qualora sia necessario ( uno lo hai nominato, ethercat ), ma non vedo perche' non si possa pensare a un bus unico quando non c'e' tale necessita', visto gli indubbi vantaggi che porta.

Ad ogni modo per chiarire, io sono anche il primo beta tester di me stesso: a casa mia ho un impianto completamente su ip ( con un bus unico! ) decisamente portato all'estremo in tutto, e garantisco che non ho problemi

l motivo è semplice: l'automazione richiede la trasmissione di pochi dati ad intervalli di tempo inderogabilmente fissati (qualche ms o centinaia di microsecondi).

I contenuti multimediali possono invece "attendere" qualche ms purché il mezzo di comunicazione sia sufficientemente rapido da far arrivare i dati quando servono.

Con i tempi in "qualche ms" ci stiamo largamente anche su ip se il protocollo e la rete sono ben fatti. Andare sui microsecondi in linea generale nel domestico salvo casi specifici non e' realmente necessario in ambito di comunicazione tra le board...

e una telecamera IP perde un frame, non accade niente di pericoloso.

Se lo stesso accade per un sistema di automazione (es. l'ABS di un'automobile), il risultato può essere disastroso...

Be ma io non vendo schede per l'abs dell'auto, ma schede per la domotica di casa, per accendere luci prese e simili!

E la perdita di un frame provoca al limite che l'accensione avviene dopo 20 ms invece che 10ms, non credo che faccia differenza!

il bus unico dal punto dei guasti e' migliore, in quando e' possibile fare una rete a maglia con un alto grado di tolleranza alle rotture, mica per nulla e' usata per internet quel modello di connessione!

Se quindi è possibile eliminare a priori ogni rischio, perché non farlo?

ESATTO! e' proprio per questo che ho scelto ethernet, per eliminare ogni rischio!

La sicurezza di un sistema non dipende esclusivamente dall'uso di un algoritmo crittografico forte.

In questo campo non è possibile generalizzare dicendo che una rete TCP/IP è più sicura di una RS 485 perché può usare algoritmi più sofisticati.

Sono perfettamente d'accordo con te. Ed essendomi occupato a lungo di sicurezza informatica professionalmente posso dire di conoscere abbastanza bene la materia, e ti do pienamente ragione.

Ma e' sicuramente bero che il fatto di poter utilizzare meccanismi sofisticati ed estremamente evoluti nati e cresciuti in un ambiente estremamente non trusted come internet offre sicuramente un vantaggio non proprio di poco conto!

Per il sistema di cui parli che hai realizzato, tu dici che non e' possibile iniettare comandi perche' non c'e' bisogno di comandi. Ma in qualche modo ci sara' qualche comunicazione, e quella comunicazione se non usi crittografia puo' essere compromessa.

La logica completamente distribuita sui microcontrollori e' esattamente quel che faccio io! per questo io parlo di sistema "distribuito". Ma se l'ingresso "1" sulla scheda "A" deve accendere il rele' "4" sulla scheda "C" queste due devono comunicare in qualche modo!.

Per la cronaca, le schede DMRv3 montano un pic18 a 8 bit, ovviamente piu' "carrozzato" di quello di cui parli, ma fanno anche MOLTE MOLTE MOLTE piu' cose.. quindi per dire che sono molto economici occorrerebbe fare un paragone piu' ampio della sola MCU, che onestamente non e' certo la parte piu' costosa delle mie schede, che invece corrisponde ai sensori di corrente, ai rele', alla circuiteria tripla etc etc...

La gestione pre-cablata degli ingressi è un punto debole di quel sistema, ma anche di quello di UnixMedia ... .

A si, certo, in quel senso si. Io la chiamo "hard coded" o "preconfigurata", non precablata, per questo non capivo cosa intendevi, pensavo a qualcosa di fisico.

Da questo punto di vista si, e' una limitazione obbligata, ma attenzione, in realta' noi diamo anche la possibilita' di farsi il proprio firmware, quindi puoi benissimo farlo, ma in questo caso devi saper programmare, e ci fai quindi quel che vuoi ( e con il protocollo open source puoi rimetterlo comuqnue a parlare con le altre schede senza problemi ).

Ma di certo su un firmware "precotto" quel problema ci sara' sempre e comunque a meno che non prendi e riprogrammi ( non riconfiguri, ma riprogrammi proprio ) il tutto.

Tuttavia penso davvero che le modalita' d'uso di quelle schede siano davvero non dico omnicomprensive ma che, anche in varie combinazioni, coprano la stragrande maggioranza delle esigenze possibili, e dove non arrivano quelle, e' possibile comunque creare interazioni complesse dal controller ( quello si, centralizzato! ).

[EtaPhi]

Per il sistema di cui parli che hai realizzato, tu dici che non e' possibile iniettare comandi perche' non c'e' bisogno di comandi. Ma in qualche modo ci sara' qualche comunicazione, e quella comunicazione se non usi crittografia puo' essere compromessa

In quel sistema l'unica informazione che circola è lo stato dei dispositivi.

Ogni trasmissione elementare consiste in una coppia di byte: il primo è un indirizzo, il secondo è il dato associato.

La comunicazione è regolata da un controller che realizza anche un gateway con un PC o un altro dispositivo tramite un canale RS 232.

Non desidero entrare nei dettagli, anche perché ho scritto un libro (in inglese) ed altra documentazione che descrivono ogni aspetto del protocollo.

Poiché il controller stabilisce cosa transita sul bus e quando, un attaccante può cercare di sostituire il controller o un dispositivo.

Entrambi gli attacchi hanno scarse prossibilità di successo.

Il controller è infatti "chiaccherone" e non smette mai di comunicare. Se qualcuno prova a sovrapporsi a quello che dice, si ha un conflitto hardware che ogni dispositivo può rilevare e reagire come meglio crede (es. suonare l'allarme).

Se un attaccante tenta di sostituire un dispositivo, potrà solo sovrascrivere lo stato che viene inviato a tutti.

Anche questo tentativo può essere rilevato perché si ha un conflitto hardware.

La protezione più efficace è però il fatto che l'attaccante non conosce quale stato influenza le uscite.

Non può nemmeno modificare la configurazione dei dispositivi (l'unica che indica quale stato o combinazione di stati determina il valore di un'uscita) perché non può accedervi se non dopo aver superato una procedura di autenticazione challenge-reply basata su numeri random e una funzione di hash di cui non conosce la chiave principale.

In quel sistema esiste quindi una protezione crittografica, ma essa è utilizzata solo quando serve...

Poiché sulla la rete circolano solo stati, se qualcosa non funziona, cioè qualche trasmissione non ha successo, non si hanno problemi ma solo un rallentamento dell'evoluzione del sistema perché le successive comunicazioni aggiorneranno comunque gli stati.

Lo stesso protocollo può essere implementato con il servizio UDP che, tra l'altro, ha il vantaggio di essere locale e quindi indipendente dal routing dei pacchetti.

La scelta di trasmettere solo lo stato dei dispositivi ha anche altri vantaggi:

• rende inutile l'invio di messaggi di conferma
  
• non appesantisce la rete quando si aggiunge un sistema di supervisione
  
• semplifica la simulazione del funzionamento di un sistema domotico
  
• consente alcune funzioni diagnostiche interessanti
  

Cerco di chiarire l'ultimo punto con un esempio.

Quando interviene il dispositivo differenziale di protezione (salvavita), un dispositivo collegato alla rete elettrica o una parte di essa ha una dispersione verso massa.

Conoscendo lo stato del sistema immediatamente prima dell'intervento del salvavita, è possibile individuare la presa o la porzione di circuito elettrico in cui si è verificato il guasto.

In un sistema domotico basato su comandi, questa utile funzione è molto più difficile da realizzare perché non si conosce lo stato dei dispositivi oppure perché è necessario realizzare un sistema virtuale che in parallelo esegue tutti i comandi inviati a tutti i dispositivi nella sequenza corretta di ricevimento.

[del_user_56966]

Il punto mio appunto era solo: un installatore non programma, installa e configura. Chi programma e' il programmatore o l'integratore, non confondiamo le due cose!

e chi lo dice questo?

un istallatore può fare quello che ritiene più opportuno se è evoluto programma e fa cose anche

cose molto complesse che altri programmatori neppure si sognano, chiaramente serve un sistema

che permetta di farle..... ma non vorrei essere ripetitivo quindi un bel cerca sul forum può risolvere tutti

questi quesiti senzascrivere sempre le stesse cose... altrimenti poi mi tocca dare ragione a Giuseppe..

[Giuseppe70]

scusate, seppur un piacere leggere le vostre discussioni iper tecniche con termini e argomenti abbastanza tosti, non sarebbe il caso in questa discussione soffermarsi piuttosto su cose pratiche che parlino di componenti funzioni e problematiche o vantaggi di installazione sempre guardando il discorso iniziale ovvero il low cost ?

lo dico anche per i contenuti dei vostri post che sinceramente meriterebbero una discussione a se per future ricerche di utenti che magari vedendo un titolo low cost manco gli interessa e passa oltre perdendo probabilmente cose che invece sono di interesse.

io sono sincero, mi son perso nei meandri delle vostre righe e penso di lasciare lo spazio ad altri perchè veramente non riesco a seguirvi non avendo neanche la vostra esperienza.

poi se comincio a leggere del bluetooth che non mi fa andare l'abs della macchina in una discussione di lampadine e tapparelle vado a farmi una doccia fredda e mi leggo un buon libro

penso che scendiamo sui millisecondi di risposta di un pulsante della luce del cortile o del bagno non se ne esce più e alla fine ci si ritrova ad aver parlato di cose fantastiche per chi programma o produce ma alla fine di difficile comprensione di molti.