Communicatie tussen µC en nodes

buckfast_beekeeper

Golden Member

Mijn serre wil ik aanpassen met een automatische bewatering. In de serre komen 8 rijen met waterreservoirs. Elke rij krijgt een vlotter voor max peil en een vlotter voor minimaal peil (3 draden). Aan elke rij komt een µC (waarschijnlijk ATtiny2313 of gelijkaardig) die de 2 sensoren uitleest en een magneetventiel opent op commando van de hoofd µC. Waarschijnlijk een ESP32. Ter controle waarschijnlijk 4 ledjes op de ATtiny ter controle van de sensoren, klep en communicatie.

De centrale gaat de 8 nodes pollen. Dit dient niet snel te gebeuren. Als de lage waterstand is bereikt wil dat niet zeggen dat 5 minuten later al het water op is. Zodra de centrale een node heeft die water kan gebruiken, gaat de klep open gestuurd worden en een pomp ingeschakeld. De centrale gaat nu om de x tijd de max waterstand pollen. Zodra deze bereikt is, pomp uitschakelen en klep dicht sturen. Zo staat er nooit druk op het ganse systeem. Na een wachttijd (snel in en uitschakelen van de pomp vermijden) worden dan weer de nodes opgevraagd en indien nodig begint alles op nieuw. Uiteraard kan het ook dat ik de nodes een bericht laat sturen zodra de lage waterstand wordt bereikt.

Vraag is welke hardware communicatie gebruiken tussen centrale en nodes. De nodes krijgen een uniek nummer, via dip switchen of softwarematig. De communicatie kan perfect in JSON boodschappen. Dat is allemaal niet zo spannend. Maar gebruiken we RS232 voor communicatie of een ander protocol? Snelheid is niet de grootste bekommernis. Een watervoorraad zou ongeveer 1 week moeten volstaan. Ik wil onze buur ontlasten tijdens het verlof. Ook wil ik neusrot voorkomen bij onregelmatig water geven. Lengte uiterste punten ongeveer 8 meter.

Als extra beveiliging kan er uiteraard altijd een flow meter geplaatst zodat er nooit meer water gevuld wordt dan praktisch mogelijk.

Edit: Wifi vind ik hier minder geschikt.

Van Lambiek wordt goede geuze gemaakt.
Arco

Special Member

Op 6 augustus 2022 15:58:26 schreef buckfast_beekeeper:
...en een magneetventiel opent op commando van de hoofd µC. Waarschijnlijk een ESP32.
...
...
Wifi vind ik hier minder geschikt.

Contradictio in terminis? ... :)

RS232 werkt prima op kortere afstanden...

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

WIFI vind ik hier wel geschikt :-)
Als je ter plekke een beetje spanning hebt, dan kun je een serie ESP12's nemen (of een ESP32, maar dat is qua performance niet nodig). Die kun je bv met MQTT met een host laten praten. Kunnen ze zelf iets melden en hoef je niet steeds te pollen.

"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein
bprosman

Golden Member

Maar gebruiken we RS232 voor communicatie of een ander protocol?

RS232 is niet echt een "protocol" maar meer een hardware definitie.
Ik zou RS485 gebruiken.

Als protocol gebruik ik voor dit soort zaken al jaren "SNAP".
https://pi3g.com/2019/04/23/introduction-to-the-snap-protocol/

De jongere generatie loopt veel te vaak zijn PIC achterna.
big_fat_mama

Zie Paulinha_B

RS-232 voldoet over meerdere tientallen meters, zelfs bij 9600 baud; en dat lijkt meer dan snel genoeg. Wel zorgvuldig aarden en grounden, resp. pen 1 en 7 van de DB25 als ik me dat nog goed herinner. Zelf zou ik iets differentieels verkiezen, maar dat is misschien overkill.

RS232 is niet echt een "protocol" maar meer een hardware definitie.

Zoiets wou ik eerst ook opperen, maar RS232 omvat wel degelijk ook specificaties van baud-rates, woordformaat met start- en stopbit enzovoort. Het definieert zowel de hardware als het protocol.

[Bericht gewijzigd door big_fat_mama op zaterdag 6 augustus 2022 16:23:09 (34%)

hoe beter de vraag geschreven, zoveel te meer kans op goed antwoord

Ik zou een power-ground-comm kabel maken. Voor de communicatie zou ik denken aan RS485 of gewoon UART.

Als je op locaties een klep moet sturen, dan moet die power iets van 12V zijn. Dan kan je op de modules een locale 12V->5V DCDC zetten, maar je kan ook op de modules er van uitgaan dat de 5V aangeboden wordt. Dan kan je eventueel na een wat langere kabel de doorgaande 5V onderbreken en een andere module 12V->5V maken die een locale 5V maakt van de 10-12V die op de "grote power" draad staat.

[Bericht gewijzigd door rew op zaterdag 6 augustus 2022 16:25:15 (66%)

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
buckfast_beekeeper

Golden Member

Waarom geen WiFi? Dan blijft ESP32 en ESP8266 over. RPi is gewoon overkill.

De ESP32 maakt het wel mogelijk een webinterface te maken zodat ik nodes kan in en uitschakelen. Ook het geheel kan starten en stoppen.

Op 6 augustus 2022 16:08:20 schreef flipflop:
WIFI vind ik hier wel geschikt :-)
Als je ter plekke een beetje spanning hebt, dan kun je een serie ESP12's nemen (of een ESP32, maar dat is qua performance niet nodig). Die kun je bv met MQTT met een host laten praten. Kunnen ze zelf iets melden en hoef je niet steeds te pollen.

Uiteraard zal er spanning aanwezig zijn. De kleppen zijn 12V (12V 200VA is sowieso al aanwezig in de serre).

Uiteindelijk loopt het aantal WiFi clients ook snel op. Je basis communicatie wordt dan ook afhankelijk van je WiFi aanwezigheid. Valt die toevallig uit tijdens mijn verlof, dan zie ik de buur die niet terug opstarten.

Van Lambiek wordt goede geuze gemaakt.
fatbeard

Honourable Member

Voor één master met een aantal slaves is RS485 de aangewezen weg, als je het wilt bekabelen. Draadloos kan uiteraard ook, maar dan heb je ook beveiliging tegen hackers nodig...

Op 6 augustus 2022 16:16:16 schreef bprosman:
[...]
Als protocol gebruik ik voor dit soort zaken al jaren "SNAP".
https://pi3g.com/2019/04/23/introduction-to-the-snap-protocol/

Wel jammer dat alle links in dat artikel uitmonden in een 403 (access forbidden) foutmelding.
De firma HTH blijkt inmiddels ook niet meer te bestaan: www.hth.com is een koreaanse(?) gaming site, www.hth.se is een ikea-achtige webshop...

Ik zou graag de volledige definitie van het protocol hebben; er zijn wel (met veel moeite) stukjes van te vinden maar nix volledigs...

Een goed begin is geen excuus voor half werk; goed gereedschap trouwens ook niet. Niets is ooit onmogelijk voor hen die het niet hoeven te doen.
bprosman

Golden Member

Op 6 augustus 2022 17:15:17 schreef fatbeard:
Voor één master met een aantal slaves is RS485 de aangewezen weg, als je het wilt bekabelen. Draadloos kan uiteraard ook, maar dan heb je ook beveiliging tegen hackers nodig...

[...]

Wel jammer dat alle links in dat artikel uitmonden in een 403 (access forbidden) foutmelding.
De firma HTH blijkt inmiddels ook niet meer te bestaan: www.hth.com is een koreaanse(?) gaming site, www.hth.se is een ikea-achtige webshop...

Ik zou graag de volledige definitie van het protocol hebben; er zijn wel (met veel moeite) stukjes van te vinden maar nix volledigs...

U vraagt wij draaien :

snap.pdf

SNAP-023.ZIP

SNAP-024.ZIP

SNAP-025.ZIP

De jongere generatie loopt veel te vaak zijn PIC achterna.
PE9SMS

Special Member

Document revision 1.03 i.p.v. 1.02:

snap.pdf

En hier nog wat inspiratie voor TS en anderen:
http://yaspnet.sourceforge.net/

[Bericht gewijzigd door PE9SMS op zaterdag 6 augustus 2022 17:53:26 (45%)

This signature is intentionally left blank.
fatbeard

Honourable Member

Een goed begin is geen excuus voor half werk; goed gereedschap trouwens ook niet. Niets is ooit onmogelijk voor hen die het niet hoeven te doen.

Op 6 augustus 2022 17:15:17 schreef fatbeard:
Draadloos kan uiteraard ook, maar dan heb je ook beveiliging tegen hackers nodig...

Op het Bascom forum van MCS Electronics stond recentelijk een mooie bijdrage die dat tegen gaat:
"Rolling code - send data more secure"
https://www.mcselec.com/index2.php?option=com_forum&Itemid=59&…

RS232 is een point-to-point verbinding, niet geschikt voor multi-drop. RS485 if RS422 is dan beter. Persoonlijk gebruik ik al snel CAN bus, maar dat hebben dergelijke kleine controllers vaak niet.

8m zou ik nog wel aandurven met I2C op lage bitrate en kleine serieweerstandjes bij elke microcontroller.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
mel

Golden Member

Ik ben natuurlijk een hopeloze ouwe l*l,maar vroeguh gebruikte ik gewoon een 20mA loop.Voordeel is kabelbreukdetectie, en de lengte kan vrij lang zijn.

u=ir betekent niet :U bent ingenieur..
Arco

Special Member

RS232 kan wel met meerdere units, je zet ze in serie. (Tx van unit1 aan Rx van unit2, Tx van unit2 aan Rx van unit3, enz...)
De units moeten de data dan gewoon doorsturen naar de volgende...

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
bprosman

Golden Member

Op 7 augustus 2022 07:48:01 schreef Arco:
RS232 kan wel met meerdere units, je zet ze in serie. (Tx van unit1 aan Rx van unit2, Tx van unit2 aan Rx van unit3, enz...)
De units moeten de data dan gewoon doorsturen naar de volgende...

Maar dan heb je wel iets met "Ketting en de zwakste schakel".

De jongere generatie loopt veel te vaak zijn PIC achterna.
Arco

Special Member

Heeft ook voordelen: je weet dan meteen dat ze allemaal nog 'leven'... :)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Op een shared-bus als RS485 weet je dat ook als je alle slaves hebt gevraagd: Ben je er nog? . Kortom dat is niet een feature wat alleen op die manier kan.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
buckfast_beekeeper

Golden Member

Op 6 augustus 2022 22:06:35 schreef SparkyGSX:
RS232 is een point-to-point verbinding, niet geschikt voor multi-drop. RS485 if RS422 is dan beter. Persoonlijk gebruik ik al snel CAN bus, maar dat hebben dergelijke kleine controllers vaak niet.

8m zou ik nog wel aandurven met I2C op lage bitrate en kleine serieweerstandjes bij elke microcontroller.

RS485 lijkt inderdaad beter geschikt. Moet er wel een MAX3485 aan de ESP en MAX485 aan de AVR nodes.

Op 7 augustus 2022 07:48:01 schreef Arco:
RS232 kan wel met meerdere units, je zet ze in serie. (Tx van unit1 aan Rx van unit2, Tx van unit2 aan Rx van unit3, enz...)
De units moeten de data dan gewoon doorsturen naar de volgende...

Hebben de nodes wat meer werk, dat is bijzaak. Als node 1 in de reeks uitvalt, zijn ze allemaal onbereikbaar. Met RS485/RS422 is dat niet het geval. Als twisted pair kan een goedkope UTP wel dienen.

Dat RS485 semi duplex is, ook geen probleem. Er is tijd zat voor communicatie.

Op 7 augustus 2022 09:00:08 schreef Arco:
Heeft ook voordelen: je weet dan meteen dat ze allemaal nog 'leven'... :)

De 'master' gaat sowieso om de x tijd alle nodes pollen.

Van Lambiek wordt goede geuze gemaakt.

Een gedeelde bus met pull-up en alle nodes een open-collector kan ook, maar als een draadje meer of minder niet uitmaakt, kun je dat ook met I2C doen, dat is kwa software wellicht eenvoudiger. Het kost evenveel pinnen van de microcontroller, tenzij je de interne transistor gebruikt, dan kan het met één pin, maar dan moet je weer bitbangen.

Met zo'n Tiny controller zijn de UART, I2C en bitbangen je opties, denk ik. Aangezien alles langzaam mag is bitbangen wel een optie, maar dat is best veel werk als je het zelf moet bouwen.

Aangezien de nodes niet onderling praten, en niet op eigen initiatief gaan zenden, heb je helemaal geen arbitratie nodig, de master vraagt en de slave antwoordt.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
big_fat_mama

Zie Paulinha_B

Aangezien alles langzaam mag is bitbangen wel een optie, maar dat is best veel werk als je het zelf moet bouwen.

Wat betekent "bitbangen" (in dexe context)?

hoe beter de vraag geschreven, zoveel te meer kans op goed antwoord
bprosman

Golden Member

De jongere generatie loopt veel te vaak zijn PIC achterna.
marcob

Golden Member

Op de site ww.picbasic.nl staat een drie draads bus beschreven, (+/-/data)
https://www.picbasic.nl/huis-automatisering.htm
Kan natuurlijk met elk andere processor gedaan worden.

https://www.picbasic.nl/images/schema_communicatie.gif

People tend to overestimate what can be done in one year and to underestimate what can be done in five or ten years
Arco

Special Member

Da's vergelijkbaar met de Uni/o bus van Microchip...

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
buckfast_beekeeper

Golden Member

Ondertussen zijn we een ganse tijd verder en is het voor >90% operationeel. Het heeft wat langer geduurd dan gepland maar dat had zijn redenen.

Er is uiteindelijk gekozen voor RS485 communicatie met een ESP32 master, 1 ATmega644p cliënt voor de pomp en 8 ATmega644P cliënts voor de waterhuishouding van de waterreservoirs.

De ATmega cliënts zijn allemaal voorzien van een 14,7456MHz kristal. Communicatie tussen master en cliënt gebeurd op 19200Bd. Dit blijkt snel genoeg voor het beoogde doel.

Wat staat er nog te doen?

  • Database opslag van de gegevens zodat de frequentie van vullen en waterverbruik beter kan gevolgd worden.
  • Watersensor in de wateropslag om het peil te monitoren. Zo kan er vermeden worden dat er meer water genomen wordt dan voorradig en de pomp gaat droog lopen. Hiervoor werd een 4-20mA druksensor aangekocht maar die dient nog geprogrammeerd en geplaatst. Communicatie met master zal via MQTT verlopen. Te laat aan gedacht een RS485 kabel mee te trekken met de water buis.
  • Enkele knoppen en leds aan de master bevestigen.

Elke cliënt kan een adres worden ingesteld. Dat maakt het mogelijk snel cliënts te wisselen mochten er problemen opduiken. Er is ook geen behoefte om elke clïent van unieke software te voorzien. Nadeel? Gebruik van 9 ingangen van de ATmega (8 BCD en 1 Blank). Voordeel als er communicatie is met de cliënt licht het display op.

Master met ILI9341 3,2" scherm. Toetsen en 3 leds dienen nog aangesloten. Aan de achterzijde, niet zo spannend, van de PCB een ESP32 dev board, MAX3485, EEPROM en de connectoren voor RS485 en 5V voeding. Alleen bij de master is de afscherming van de RS485 120Ω kabel aan GND gelegd. Op alle andere bordjes wordt de afscherming doorverbonden zonder gebruik van GND.

Pomp cliënt. Onderaan links de adres instelling. Onderaan de 2 flow meters (totaal ingenomen water en water doorgestuurd naar de waterreservoirs). Daar net boven batterij van de RTC. Zo zet de cliënt om middernacht UTC zijn verbruik op 0. Rechts 2 relais voor de pomp en de waterklep met hun connector. Bovenaan links 5V aansluiting en 2 RS485 aansluitingen. Naast de condensator het 'kristal' en MAX485.

Achterzijde van een water cliënt. De pomp ziet er functioneel ongeveer gelijk uit aan de achterzijde. De led drivers zijn BCD => 7 segment decoders type MC14511. Er naast het RTC IC.

Water cliënt voorzijde. Naast de adres displays de connector van de peilmeting. Gebaseerd op NC contacten bij te lage waterstand en open contacten bij gevulde waterstand. Mocht er een draad breken, wordt er steeds een geopend contact weergegeven en zal de bak niet gevuld worden. Ook als de connector wordt uitgetrokken is er geen bij vulling meer. Na 10 seconden geopend hoog water contact wordt de klep gesloten. Net boven deze connector een neopixel. Groen bij gevulde bak (beide sensoren open). Geel bij normale waterstand (sensor hoog gesloten, sensor laag open). Mauve bij lage waterstand (beide sensoren gesloten). Rood bij fout (laag sensor gesloten hoog sensor open). Rechts naast lithium cel het printrelais dat de 24V klep stuurt. Net er boven de connector voor de klep. In eerste instantie voorzien dat klep met een stekker kon uitgetrokken worden. Uiteindelijk vast aangesloten zodat 2 contacten niet gebruikt worden. Net er boven DS18B20 temperatuur aansluiting. Meet de temperatuur van het aanwezige water. Overige zaken idem als pomp cliënt.

Van Lambiek wordt goede geuze gemaakt.