Komunikacja RS485 pomiędzy kilkoma Arduino - inteligentny dom

Jestem w trakcie budowy domu i chciałbym zrobić swój własny "inteligentny dom"
Na razie w planach:
- system alarmowy (kontaktrony, czujki ruchu itd.)
- system wykrycia pożaru, zalania, gazu
- sterowanie oświetleniem (wewnętrzne, zewnętrzne, led)
- sterowanie roletami
- sterowanie bramą garażową, wjazdową
- sterowanie ogrzewaniem, piecem
- sterowanie innymi urządzeniami w domu
- monitoring temperatur, wilgotności, poziomu szamba
- sterowanie zraszaniem trawnika
i wiele wiele innych pomysłów i funkcjonalności które mam w głowie

Chciałbym to zrobić to na kilku Arduino + Raspberry Pi 3 jako jednostka centralna.
Myślałem nad komunikacją RS485 pomiędzy Arduino z wykorzystaniem shield-ów na układzie MAX485ESA lub innych.

Pytania do mądrzejszych i bardziej doświadczonych forumowiczów

Jak się zabrać za komunikację?
Jakie biblioteki są potrzebne? Z których sprawdzonych najlepiej skorzystać?
Czy to będzie działać sensownie tzn. czy np. będę w stanie szybko sterować wyjściami na Arduino z poziomu RPi3?
itd.
A może to głupi pomysł?

Pozdrawiam!

Do arduino jest gotowa biblioteka mysensors, która może gadać po rs485 lub bezprzewodowo (nrf24l01+ itp.) A jako kontroler na raspberrypi możesz wykorzystać Domoticz, który współpracuje z mysensors.

Zapomnij o jakiś wynalazkach typu Arduno. Tak to można się bawić na płytce stykowej lub budując jakąś makietę. Do HA potrzebujesz zrobić normalne płytki dostosowane do wymogów. Masz szereg gotowych protokołów komunikacyjnych, możesz użyć np. Modbus. Gotowe implementacje są praktycznie na każy MCU.

Jeśli :

- Masz ścisły budżet na HA
- Chcesz zrobić wszystko sam
- Umiesz coś zrobić na Arduino ( i tylko na Arduino )
- Elektronika nie jest Ci obca

to :

Przygotuj swoje własne płytki "Arduino" mające na pokładzie wszystko to i tylko to, co Ci bedzie potrzebne, przede wszystkim odpowiednie złącza do podłączenia przewodów zasilających, czujników, komunikacji, zabezpieczenia przed przepięciami i przeciążeniami ( na zasilaniu ) itp. Wbrew pozorom to nie jest trudne. Płytki arduino to nic innego niż jakaś ATmega w otoczeniu małej ( zbyt małej ) ilości elementów. Potem te płytki będziesz mógł programować w Arduino IDE czy każdym innym środowisku według Twojego uznania.
Jak napisał kol. tmf - płytki arduino są dobre do prototypowania i ogólnej zabawy. W rozwiązaniach permanentnych generują z biegiem czasu więcej problemów i niezawodność spada.

@mbulinski1977, może zamiast gotowych płytek Arduino zainteresują Cię moje moduły?



Sam zaczynam coś robić w kierunku "automatyzacji" mieszkania.
Moje moduły są zbudowane na ATmega8, ale można uC podmienić na ATmega328, wgrać bootloader Arduino i już masz płytkę zgodną z Arduino.
Na płytce jest 8 wejść (przyciski) 8 wyjść (przekaźniki) złącze odbiornika RC5, 2x ADC, MAX485, przetwornica STEP-DOWN. Płytka ma wymiary 50x50mm

*nie jest to jakiś profesjonalny projekt, a "wyrób" niedzielnego amatora elektroniki.
**soft piszę w BASCOM, ale może dzięki Tobie przejdę na Arduino/C

Dziękuję wszystkim za cenne informacje i czekam na dalsze uwagi.

Na gotowych płytkach Arduino chcę narazie rozwiązać problemy np. komunikacji pomiędzy poszczególnymi Arduino dlatego pytałem o RS485 i stosunkowo łatwy i szybki protokół do komunikacji po tym medium.

Oczywiście kwestie odpowiednich zabezpieczeń wejść wyjść itd. będę organizował. Na razie najważniejsza jest dla mnie warstwa i protokół do komunikacji pomiędzy Arduino.

@mbulinski1977 Wybierając protokół zwróć uwagę na jedno bardzo ważne założenie. Czy sytem ma być scentralizowany (w takiej sytuacji awaria sterownika, np. RPi robi katastrofę w domu), czy zdecentralizowany - w takiej sytuacji awaria zazwyczaj ogranicza się do jednego niedziałającego urządzenia. To z kolei wymusza protokół - czy masz master-slave (system scentralizowany), czy multimaster (system zdecentralizowany). Protokół z jednym masterem jest banalny. Master odpytuje urządzenia i im wysyła polecenia. Czas reakcji może być różny i awaria mastera to awaria całego systemu. System multimaster nie ma tych wad. ale odpowiedni protokół robi się skomplikowany. Tu można się posiłkować gotowcami, np. CAN - niestety magistrala CAN jest znacznie droższa niż RS485 (główne koszt kontrolerów CAN). Także zacznij od określenia fundamentalnych kwestii dla całego systemu, potem się skupisz na konkretnych rozwiązaniach pod określone założenia.

Po pierwsze - musisz ustalić sobie topologię sieci - czy będzie jeden master i reszta slave, czy będzie to multimaster itp. Protokołów ( z gotowymi bibliotekami ) jest sporo - ja ze swej strony polecam Modbus RTU ( znajdziesz biblioteki m.in. ModbusMaster i ModbusSlave ). Czemu akurat ten? Bo jest to niejako standard przemysłowy i wiele z fabrycznych urządzeń komunikuje się własnie tym protokołem i w razie potrzeby łatwo je zintegrujesz w swoim projekcie.

Z Modbus RTU mam do czynienia w pracy w systemach BMS. Ale to typowy Master Slave.
Jakie protokoły multimaster konkretnie macie na myśli?

@mbulinski1977 Notu własnie pojawia się problem. Dostępnych open-source multimasterów jak na lekarstwo. Jak pisaem rozwiązaniem sprzetowym jest CAN. Inne to wykorzystanie TCP/IP, ale to kłopot. Chyba, że by użyć modułów WiFi z ESP, ale średnio jestem przekonany do HA droga radiową.

WiFi odpada 😊

Rozumiem że to mogę wykorzystać:

https://botland.com.pl/arduino-shield-komunik...ry=RS485+%2F+CAN+Shield+dla+Arduino&results=2

Dodano po 19 [minuty]:

Tylko jak z obsługą samego protokołu CAN?

Są jakieś biblioteki do tego dla Arduino?

Ta nakładka na Arduino to tylko dwa transceivery RS485 (od biedy zapewne moga pracować z CAN). Natomiast tego co ci ciągle brakuje to kontrolera CAN. Samo Arduino bez kontrolera magistrali nie obsłuży jej. Biblioteki zapewne są, ale jakość ich może być arduinowa:)

A jeżeli kilka Arduino będą w tym samym miejscu powiedzmy ta sama szafa w której będzie cała automatyka to czy nie można by się zastanowić nad I2c 😊

O I2C do komunikacji pomiędzy płytkami zapomnij. Z kolei jeśli wszystko będzie w jednej szafie to po co ci kilka Arduino?

Bo sygnałów wejściowych i wyjściowych będzie 200-300. Dlatego chcę je rozdzielić na kilka Arduino.

mbulinski1977 napisał:

Bo sygnałów wejściowych i wyjściowych będzie 200-300. Dlatego chcę je rozdzielić na kilka Arduino.

Zastosuj expandery I/O na SPI czy I2C - np. MCP23017. Szkoda komplikować sobie życie i wprowadzać dodatkowe opóźnienia na komunikację między wieloma MCU tylko dla dodatkowych I/O.

mbulinski1977 napisał:

Bo sygnałów wejściowych i wyjściowych będzie 200-300. Dlatego chcę je rozdzielić na kilka Arduino.

Tak jak pisze kolega powyżej. Ekspandery to sensowne rozwiązanie. W takiej sytuacji nawet niepotrzebujesz Arduino, ekspander można dodać do RPi. Z drugiej strony jak rozumiem całe sterowanie będzie w szafie z której pociągniesz kable do sterowanych urządzeń. Jest to proste rozwiązanie, nie wymaga żadnej magistrali, ale policzyłeś ile kilometrów kabli na to pójdzie i jaka będzie cena?
Zwykle HA robi się tak, że masz magistralę do której podpinane są urządzenia fizycznie znajdujące się w puszkach (gniazdka, wyłączniki itd.). W takim układzie potrzebny jest tylko kabel do wspólnej magistrali. No i protokół wymiany danych

tmf napisał:

W takim układzie potrzebny jest tylko kabel do wspólnej magistrali. No i protokół wymiany danych

I spokojnie da się to zrobić w konfiguracji master/slaves
Co do protokołów i okablowania - ciekawe rozwiązanie możesz podpatrzeć np. tutaj http://ep.com.pl/artykuly/10203-iControl_System_automatyki_domowej_cz_.html
Jak to się sprawdza w życiu - osobiście jeszcze nie testowałem PLC ( Power Line Communication ) więc nie wiem jednak spotykałem sporo "fabrycznych" rozwiązań bazujących na tej technologii.

to ma działać z Rpi czy bez?

najprościej dla takiej liczby IO w jednej rozdzielni zrobić moduły przekaźnikowe na rs485. Rok temu wykonałem taka płytkę która z jednej strony pasuje do popularnej obudowy na szynę DIN a z drugiej posiada 12 przekaźników i złącze pod arduino nano + rs485.
Takie płytki można zestawiać i w zasadzie otrzymać dowolną liczbę wyjść przekaźnikowych.
Master wysyła co kilkaset ms paczkę z danymi dla przekaźników, jeśli nie ma jej przez dłuższy, zdefiniowany czas, wszystkie przekaźniki są wyłączane. użycie ekspanderów jest co prawda prostsze bo nie ma do nich softu ale trzeba się zabezpieczyć przed przerwaniem magistrali np poprzez dodanie jednego nadmiarowego, wprowadzenie lifebita i odczyt przez mastera.
Podejść jest wiele..

Problem z wejściami też można rozwiązać na wiele sposobów, najprostsze to wykorzystanie megi która po wciśnięciu przycisku wysyła komunikat przez rs do mastera, jeśli jedna to za mało można dodać drugą i juz masz ponad 100 wejść.
Można klawiatury matrycowej wtedy na jednym arduino nano spokojnie masz 64 przyciski.

Witam,

tmf napisał:

Jak pisaem rozwiązaniem sprzetowym jest CAN

moim zdaniem, jest to bardzo dobry pomysł.
Standard jest bardzo dobrze ugruntowany, bezpieczny, odporny na zakłócenia i łatwy do ewentualnej rozbudowy.
Pewną niedogodnością jest mniejsza szybkość transmisji przy długich łączach, ale w automatyce domowej chyba nie są potrzebne ogromne transfery.
Mikrokontrolery z kontrolerem CAN są łatwo dostępne, nie są też jakieś bardzo drogie, podobnie zresztą transceivery.
Żeby nie rzeźbić w czystym CAN-ie, można wykorzystać jakiś gotowy protokół, na przykład CANOpen, możliwe, że są gotowe (albo wymagające małych modyfikacji) profile potrzebnych urządzeń. Są tez gotowe stosy CANOpen na różne mikrokontrolery.

Pozdrawiam

Czy do komunikacji CAN mogę zastosować takie kontrolery?

https://botland.com.pl/arduino-shield-komunik...a-arduino.html?search_query=MCP2515&results=3

@mbulinski1977 Tak, możesz. O ile oczywiście cena cię nie zniechęca, bo na własnej PCB koszt dodania CAN (o ile nie a go użyty MCU) to 20% ceny tej płtki albo i mniej.

Dodano po 4 [minuty]:

ditomek napisał:

Problem z wejściami też można rozwiązać na wiele sposobów, najprostsze to wykorzystanie megi która po wciśnięciu przycisku wysyła komunikat przez rs do mastera, jeśli jedna to za mało można dodać drugą i juz masz ponad 100 wejść.

To wcale nie jest najprostsze. Jeśli slave sam inicjuje transfer danych, tak jak to opisaleś, to robi się z tego multimaster. W typowej konfiguracji master-slaves to master powinien okresowo odpytywać slave czy nie ma czegoś ciekawego. Robi się to problematyczne przy wielu slave, bo czas odpowiedzi na zdarzenie staje się nieciekawy. Można pójść tropem 1-wire i zrobić coś w stylu Alarm Search, gdzie można wytypować z którymi urządzeniami warto zagadać.

@tmf pisałem o rozwiązaniu w którym wszystkie kable sa w rozdzielni i jest jeden master (np Rpi)
Osobiście tak właśnie wyrzeźbiłem u siebie. W roli mastera mam arduino mege (dedykowany "shield")
Jak wiadomo mega na kilka uartów więc do jednego z nich podłączyłem atmege64 która zbiera sygnały z wyłączników w domu. Po wciśnięciu przycisku na serialu pojawia się krótki komunikat o zdarzeniu. Master odbiera go w przerwaniu i odpowiednio reaguje.

Pytałem w moim poście o Rpi ale autor nadal nie przedstawił koncepcji na komunikację.
Więc pewnie jest w lesie...

Kilka razy na elektrodzie były prezentowane płytki oparte na ESP. Zaimplementowanie interfejsu sieciowego z prawdziwego zdarzenia jest najlepsze. Wtedy można bez problemu użyć MQTT który naprawdę fajnie działa.
Tylko ta komunikacja wifi.... Gdyby można ja było efektywnie i tanio zastąpić kablem który i tak jest potrzebny do zasilania

ditomek napisał:

Tylko ta komunikacja wifi.... Gdyby można ja było efektywnie i tanio zastąpić kablem który i tak jest potrzebny do zasilania

Jeśli masz CPU który udźwignie komunikacje po IP, to możesz pakiety warstwy 2 puścić po RS485 i dorzucić do tego switch/bramkę wymieniający te pakiety z "prawdziwym lan", potrzebne 4 przewody. Albo po prostu eth, do zasilania i wymiany danych potrzeba też 4 przewodów (i nikt nie mówił, że koniecznie z gniazdem RJ45), ale raz, ze transformator, dwa, że potrzebny dla każdego urządzenia wolny port w switchu.

Lub spróbować czegoś "nowego" i oprzeć komunikację na wspomnianej wcześniej technologii PLC ( Power Line Communication ) i układach CY8CPLC10 .
Cytując artykuł w EP :

"Zintegrowany interfejs fizyczny modemu PLC (Physical Layer Interface).
Modulacja FSK zapewniająca prędkość transmisji na poziomie 2400 bitów na sekundę.
Kompletny protokół komunikacyjny zoptymalizowany dla sieci PLC zapewniający realizację wszystkich warstw komunikacji (Data Link, Transport i Network Layers).
Komunikacja dwukierunkowa typu half duplex z korekcją błędów (8 bitowe CRC) i sygnałem potwierdzenia (ACK).
Wbudowany mechanizm wielodostępu do medium komunikacyjnego (CSMA - Carrier Sense Multiple Access).
Zintegrowany interfejs sterujący I²C pracujący w trybie high-speed (400 kHz).
Wsparcie dla sieci zmiennoprądowych AC 110...240 V i stałoprądowych DC 12...24 V.
Wsparcie dla wielu trybów transmisji danych w sieci: master-slave, peer-to-peer i multimaster.
3 tryby adresowania urządzeń sieciowych: logiczny (8-bitów), rozszerzony logiczny (16-bitów) i fizyczny (64-bity).
2 tryby rozgłaszania adresów urządzeń: indywidualny i grupowy (możliwość przyporządkowania urządzeń do jednej z 256 grup i sterowania grupowego).
Szereg kilkudziesięciu rejestrów kontrolnych/ sterujących dających pełną kontrolę nad transmisją danych.
Wbudowany detektor BIU (Band-In-Use) zgodny ze standardem CENELEC EN 50065-1.
Zgodność ze standardem CENELEC EN50065-1:2001 i FCC part 15 (dla Ameryki Północnej). "

Źródło : http://ep.com.pl/artykuly/10203-iControl_System_automatyki_domowej_cz_.html

zster napisał:

Lub spróbować czegoś "nowego" i oprzeć komunikację na wspomnianej wcześniej technologii PLC ( Power Line Communication ) i układach CY8CPLC10 .

Tylko, że w porównaniu do RS485, czy nawet ethernetu, jest tu sporo więcej elementów towarzyszących, tak z grubsza 50 elementów w samym filtrze.

drobok napisał:

Coś za coś, nie trzeba kłaść kabli,. Jednak prościej iść w can, nawet taki stm32f1 go ma, pchanie się w arduino dla idei (a co za tym idzie wydania x razy więcej) wg mnie nie ma sensu.

W rzeczy samej, ponadto zewnętrzny kontroler CAN może (chociaż wcale nie musi) spowodować pewne problemy. Jeżeli oprogramowanie jest dobrze napisane (przerwania, kolejki komunikatów, itd.) wszystko będzie w porządku, jeżeli jest napisane słabo, przy bardziej intensywnym ruchu na magistrali, kontroler może mieć tendencję do gubienia komunikatów.
Wbudowany kontroler jest znacznie lepiej zintegrowany z rdzeniem procesora, pamięcią, itd, łatwiej jest napisać poprawnie działający program.

Sareph napisał:

Tylko, że w porównaniu do RS485, czy nawet ethernetu, jest tu sporo więcej elementów towarzyszących, tak z grubsza 50 elementów w samym filtrze.

To prawda. Minusem jest też zdecydowanie wolniejsza transmisja danych. Ale za to mamy : brak dodatkowego okablowania, możliwość dowolności w rozbudowie sieci ( nie trzeba dokładać okablowania sieciowego ), no i gotowy, elastyczny protokół komunikacyjny .

zster napisał:

To prawda. Minusem jest też zdecydowanie wolniejsza transmisja danych. Ale za to mamy : brak dodatkowego okablowania, możliwość dowolności w rozbudowie sieci ( nie trzeba dokładać okablowania sieciowego ), no i gotowy, elastyczny protokół komunikacyjny .

Prawda jest to zaiste. Ale do tego jest tez kolejne "ale" - nie zadziała jeśli nie ma doprowadzonego do puszki L i N. Więc dla kontaktów będzie ok dla oświetlenia może być problem. Także jak to zwykle bywa, co tam komu pasuje, ale dobrze mieć wybór.