Domotica: quale bus da campo.

Salve, ho la necessità di avere un bus da campo per un progettino di domotica. So che l'argomento e stato trattato e ritrattato molte volte, (discussione lunghe 32 pagine in cui si si parlava già di prototipi per poi scomparire del tutto!), ma di tutte le discussioni non ho mai visto nè una conclusione nè uno schema (a parte il progetto domotica di bl4d3!).
Se devo essere sincero, sul bus da campo non mi sembra che ci siamo delle idee chiare (layer fisico, protocollo ecc ecc) ed io non sono di meno... ho delle idee un po confuse quindi spero che da questa discussione ne esce qualcosa di buono.
Le mie necessità sono le seguenti:

  • collegare i vari arduino, se presenti
  • collegare i dispositivi di input (io expander) che possono essere sia vicino al pcb che distante
  • collegare i dispositivi di output (schede relè) che possono essere sia vicino al pcb che distante
  • collegare touch screen distanti dal pcb

Per adesso una soluzione che ho individuato è quello di utilizzare il bus i2c che quando va fuori al pcb utilizza gli extender della nxp: P82B715 and P82B96.

Suggerimenti?

Secondo me stai facendo una domanda troppo vaga, schematizza meglio ed esponi le tue perplessità.

ciao, il titolo "bus da campo" fa pensare a un campo di grano, una distesa di terra :slight_smile: , devi considerare che non tutti i lettori del forum conoscono il termine tecnico "campo" che distingue la zona di controllo da quella degli attuatori e/o sensori (se è così che volevi intendere). Secondo me così hai eliminato 1/4 di possibili lettori.

  • il P82B715 and P82B96 che hai menzionato fa 20m su ic2 non ti bastano? hai distanze più lunghe?
  • il progetto domotica di bl4d3 tratta più che altro il domotichome su palmare che non discute di interfacce elettroniche ma di software android.

Io ti suggerirei di fare un bus RS422 ed RS485 o realizzare dei nodi lan con tante ethernet, non chiedi una cosa di tutti i giorni pochi hanno realizzato un progetto funzionante e nessuno ha messo il progetto completo, ma a pezzi qualcosa puoi trovare.
Se hai comprato arduino e pensato, tanto su internet trovo progetti completi, in questo caso hai sbagliato :), ti devi sbattere un po'.

ciao

Ti consiglio il modbus su rs485 in half-duplex. Per le librerie puoi usare queste:
https://sites.google.com/site/jpmzometa/arduino-mbrt

Ti conviene far fare da master ad un hmi e tutti gli arduino in slave. Ormai tutti gli hmi supportano il modbus, e la 485 ti garantisce immunità ai disturbi.

@pablos non a caso ho messo "domotica" nel titolo, chi è interessato a tale argomento penso che dia una sbirciatina :slight_smile:

pablos:
il termine tecnico "campo" che distingue la zona di controllo da quella degli attuatori e/o sensori (se è così che volevi intendere).

Questo è quello che intendo dire per bus di campo:
“Bus di campo” è un’espressione generica che descrive una forma di comunicazione digitale dedicata ai sistemi a basso livello, quali sensori o attuatori, la quale si prevede sostituirà nell’industria la tecnologia analogica per collegamenti punto a punto basata su segnali a 4-20mA (PLC). L’architettura a bus consente una notevole riduzione dei cablaggi e dei costi. Il bus rappresenta il solo mezzo fisico utilizzato per trasportare i dati e quindi per interconnettere i vari dispositivi.
tratto da: http://old.disco.unimib.it/informaticaindustriale/PDF_Utili/bus_di_campo.pdf

i il P82B715 and P82B96 dovrebbero ardare bene almeno in teoria. Il P82B96 da datasheet con tensione de bus di comunicazione a 15V può superare anche i 100m.
Ma non ho trovato nessuno che li abbia utilizzati o fatto prove. Non metto in dubbio che con tali integrati si possano mettere in contatto dei dispositivi a 20 metri ed oltre di distanza... il dubbio è la sensibilità al rumore. Non vorrei che ogni volta che si accende il frigo le tapparelle di casa iniziano chiudersi!

Per quanto riguarda rs485, ho visto in giro solo come far comunicare più arduino tra di loro... ma non visto nulla su come far comunicare i sensori o attuatori.

daddeTr:
i il P82B715 and P82B96 dovrebbero ardare bene almeno in teoria. Il P82B96 da datasheet con tensione de bus di comunicazione a 15V può superare anche i 100m.

Con la RS485 arrivi a 1200 metri ed è molto semplice da implementare a livello hardware, inoltre è tra i migliori bus come velocità e immunità al rumore.

Per quanto riguarda rs485, ho visto in giro solo come far comunicare più arduino tra di loro... ma non visto nulla su come far comunicare i sensori o attuatori.

In effetti se ci pensi bene con un 485 quello che vai a fare è la comunicazione tra 2 o più arduino, in pricipio di base dovrai avere un arduino master dove è caricato il programma di gestione di tutti gli slave, ma tutti gli slave dovranno anch'essi essere dei microcontroller con un programmino di riconoscimento ed elaborazione dei suoi pacchetti, ad esso sono collegate porte out( es relè) e porte input (contatti o sensori analog) che restituiranno i valori quando il master gli interroga. Gli slave potrebbero essere degli arduino NANo, degli ATtiny, però la strada è quella. In definitiva sia il Master che gli slave devono essere tutti microcontroller chi più grande chi più piccolo

ciao

Ciao

posso confermare anch'io la bontà del bus 485: l'ho utilizzato in molti progetti anche con topologie di rete diverse e con dispositivi in stile "plug'n'play" sul bus senza problemi.
Lato nodi periferici volendo potresti pensare a qualcosa di più leggero di un Arduino, un microcontrollore associato ai tuoi sensori che si occupa solo della parte "slave" di comunicazione sul bus + un tranceiver 485 appunto.

Grazie a voi adesso ho le idee più chiare.
credo proprio che farò un transceiver 485 + pic.

Luca, dato che te hai già fatto queste cose, sul bus poi metti un protocollo di comunicazione per la sicurezza del trasporto del dato?
qualcosa del tipo:
A comunica a B
B riceve
B comunica ad A che la ricezione è ok
ecc ecc

oppure dai per scontato che se trasmetti un dato, dai per scontado che quel dato arriva?

Ciao!

dipende molto dalla criticità della comunicazione... normalmente aggiungo almeno un byte di parità alla fine del pacchetto (classico XOR bit a bit degli altri bytes) in modo che chi riceve abbia un minimo di controllo sulla bontà di quanto ricevuto.

l'ack invece l'ho implementato solo in un caso, unito ad un sistema locale di buffer (= memorizzo i pacchetti trasmessi) per eventuali ritrasmissioni... ti complica non poco l'algoritmo perché devi prevedere qualche forma di identificazione dei pacchetti e di timeout.

daddeTr:
Grazie a voi adesso ho le idee più chiare.
credo proprio che farò un transceiver 485 + pic.

Luca, dato che te hai già fatto queste cose, sul bus poi metti un protocollo di comunicazione per la sicurezza del trasporto del dato?
qualcosa del tipo:
A comunica a B
B riceve
B comunica ad A che la ricezione è ok
ecc ecc

oppure dai per scontato che se trasmetti un dato, dai per scontado che quel dato arriva?

Se utilizzi il modbus con la libreria che ti ho dato sopra non hai più da preoccuparti di niente. E' previsto anche un controllo CRC della trasmissione.

Janos:
Se utilizzi il modbus con la libreria che ti ho dato sopra non hai più da preoccuparti di niente. E' previsto anche un controllo CRC della trasmissione.

Ho visto il modbus è può andare bene per far comunicare più arduini tra di loro.
Nel mio caso, dovrei mettere il modbus slave sul pic... e qui penso che le cose si complicano un tantino.

si, sul pic è improponibile, anche perché si programmano in assembly...

Janos:
si, sul pic è improponibile, anche perché si programmano in assembly...

ciao

per i PIC vi sono compilatori basic, c...

daddeTr:
Ho visto il modbus è può andare bene per far comunicare più arduini tra di loro.
Nel mio caso, dovrei mettere il modbus slave sul pic... e qui penso che le cose si complicano un tantino.

Assolutamente no, esistono librerie pronte per il C18 (pic serie 18), o il C30 (pic serie 24,30 e33), per il modbus, sia slave che master.
Ho citato solo i compilatori di Microchip per i quali sono disponibili versioni free, ma le librerie modbus ci sono per tutti i compilatori per pic.

Janos:
si, sul pic è improponibile, anche perché si programmano in assembly...

Affermazione assolutamente sbagliata, tutti i pic si possono programmare in C, e anche altri linguaggi, solo sulle mcu più piccole, serie 10 e 12, per via della limitata quantità di flash e ram disponibile può essere vantaggioso usare l'assembly, non è comunque un obbligo, salvo casi particolari, e questo vale anche per le piccole mcu di altri produttori.

Chiedo venia... XD

Qualche novità?