Il bus da adottare deve avere ben determinate caratteristiche:

• Elevata velocità: se i messaggi viaggiano troppo lentamente, il sistema non risulta sufficientemente reattivo agli eventi
• Affidabilità e tolleranza ai guasti: un sensore guasto non deve bloccare il sistema
• Espandibilità: non devono esserci restrizioni troppo severe al numero di elementi
• Multimaster: è desiderabile che possano esserci più master che condividono il bus
• Capacità: devono poter passare pacchetti anche di 100 byte (vedi alla sezione comunicazioni)
• Copertura: il bus deve permettere di coprire anche distanze medio-lunghe (fino almeno ad un paio di km con "remotizzatori", almeno 200m in un singolo "ramo")

Le possibilità sono parecchie... In genere il tradeoff è tra velocità e distanza, o tra distanza e costo.

Il top sarebbe Ethernet su fibra, ma i costi sono insostenibili. Anche Ethernet su rame può essere interessante, ma ha costi ancora un po' alti (minimo una decina di euro per nodo).

Inizialmente ho optato per un RS485 che ad una velocità tutto sommato buona (100kbps) permette comunque di coprire distanze di tutto rispetto (1200m). Il contro è che prevede la presenza di soli 32 dispositivi sul bus e non prevede arbitraggio. "Sacrificando" un nodo possiamo inserire un repeater attivo che estenda le possibilità di indirizzamento. Usando il MAX487 si può arrivare a 128 device.

Ora sto valutando ATTENTAMENTE anche il bus CAN che permette comunque 1Km a 50Kbps. Ha il vantaggio di gestire l'accesso concorrente al bus da parte di più device, ma lo svantaggio di prevedere "pacchetti" di soli 64 bit di payload (che ci obbligherebbe ad usare un sistema crittografico con b=64 o ad usare un protocollo di più alto livello, vedi sotto Comunicazioni). Potendo avere più master si potrebbe ridurre il traffico di polling, facendo gestire in "autonomia" a delle "subnet" determinate funzioni (per es. il controllo luci, come succede in CARACA, anche se in questo caso fa lavorare CAN in point-to-point... un tantino overkill!). Però l'idea dei concentratori è molto interessante: si possono più facilmente isolare problemi sul bus, si può gestire una velocità molto elevata (le distanze da coprire sono molto più brevi, e nel caso serva un tratto lungo, si usa un concentratore dedicato),... Insomma tanti vantaggi col "solo" inconveniente del costo leggermente più elevato...

È molto interessante anche FlexRay (evoluzione di CAN), peccato che sia "licenziato" solo per usi automobilistici! Però alcune idee si possono "prendere in prestito"... In particolare i miniframe (frame "opzionali": se chi li detiene non ha nulla da trasmettere, basta che non impegni la linea durante il tempo di minislot ed il protocollo gestisce il passaggio diretto al minislot successivo, quasi senza spreco di banda -- ottimo per segnalazioni tipo interrupt con payload). La durata di un minislot deve essere almeno il doppio (meglio se il triplo) del tempo che impiega un bit per percorrere tutta la rete e venire decodificato dal transceiver, altrimenti un controller potrebbe sbagliare l'assegnazione del minislot. Altra idea interessante di FlexRay è la gestione della sincronizzazione, per permettere ai controller di unirsi alla rete in qualsiasi momento.

Altri bus (tipo Echelon) sono stati adottati in passato da alcuni sistemi antifurto, ma ormai vengono sostituiti per i costi troppo elevati (anche se c'è chi continua imperterrito a farli adottare...).

Come cavo si può generalmente utilizzare del semplice cavo Ethernet UTP, a meno che condizioni di particolare "rumore" portino ad optare per STP. Come connettori conviene usare gli standard RJ45. In questo modo qualunque elettricista dotato di tester per reti Ethernet (oramai sono tanti) è in grado di testare (e certificare!) i cablaggi.

Continuando a documentarmi, ho trovato che Konnex è in avanzato stadio di standardizzazione. Dato che l'antifurto si può considerare una sorta di apparecchiatura per la domotica, vale la pena di analizzare meglio la proposta di standard:

PRO: Standard, molti device già disponibili
CONTRO: Lentezza (9600bps), infrastruttura "pesante", royalty

I contro mi sembrano un po' troppo "pesanti", soprattutto per un sistema che si propone come standard! Può comunque valere la pena di prevedere device di "gateway" tra il bus adottato in OpenAlarm e KNX, così da non limitare l'utente.

È comunque da tenere ben presente la possibilità di trasportare sul bus anche l'alimentazione almeno per i device meno esigenti (sensori ed elementi passivi).