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.
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/
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%)
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%)
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.
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...
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 :
Special Member
Document revision 1.03 i.p.v. 1.02:
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%)
Honourable Member
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.
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.
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...
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".
Special Member
Heeft ook voordelen: je weet dan meteen dat ze allemaal nog 'leven'...
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.
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.
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.
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)?
Golden Member
Op 7 augustus 2022 11:33:27 schreef big_fat_mama:
[...]
Wat betekent "bitbangen" (in dexe context)?
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.
Special Member
Da's vergelijkbaar met de Uni/o bus van Microchip...
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?
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.
Golden Member
De bedrading van de cliënt kastjes. De PCB steunen op maat geprint.
Aanwezig 5V DC en 24V DC (klepsturing) in een genummerde kabel en en uit verbonden met de gekende WAGO. 2 RS485 aansluitingen. Links boven DS18B20 temperatuur aansluiting. Onderaan links aansluiting water sensoren.
De gemonteerde water cliënt.
De bijhorende elektriciteitsvoorziening en relais voor de pomp. Kast dient nog lichtjes aangepast. De 24V transformator is net te hoog. Deze zal op de zijkant gemonteerd worden na de oogst.
Het doel.
Golden Member
Webinterface net voor de middag.
Enkele tijd later heeft de cliënt op adres 4 zich bijgevuld.
Er wordt gebruik gemaakt van websocket en JSON gegevens overdracht. Ook voor de communicatie tussen master en cliënt wordt JSON toegepast.
Elke 10 minuten worden de cliënt opgevraagd. Zoals te zien op de webpage kan dat bij 19600Bd aan 4 cliënt per seconde. Meer dan voldoende snel voor zaken die niet op de seconde dienen geregeld. Zodra een cliënt vult worden pomp en cliënt elke 5 seconden opgevraagd. Na elke poll worden de web gegevens aangepast.
Vraag van master:
{"Adres":1,"Status":"?"}
Antwoord pomp:
{"Adres":1,"Status":"Alive","Pomp":"Uit","Klep":"Dicht","WaterFlowIn":0,"WaterHoevIn":0,"WaterHoevInJaar":1.947301,"WaterFlowUit":0,"WaterHoevUit":0,"WaterHoevUitJaar":0,"RTCTemperatuur":26,"Versie":"1.6"}
Noot: dit is communicatie met een gelijkaardige print die nu op de tafel ligt om de nieuwe programmering te testen. Er is ook maar 1 flow sensor aanwezig.
Vraag master:
{"Adres":2,"Status":"?"}
Antwoord water cliënt:
{"Adres":2,"Status":"Alive","Klep":"Dicht","Waterniveau":"HW","Temperatuur":"24.3","RTCTemperatuur":25.25,"LG":1685799825,"ErrorString":"","Versie":"1.6"}
Ook hier testopstelling. LG is de UTC timestamp dat de cliënt het laatste zijn water heeft bijgevuld. Wordt opgeslagen in de ATmega EEPROM bij het sluiten van de klep.
Indien de cliënt niet antwoord is er na 300ms een timeout en wordt de cliënt als off line weergegeven. Zowel het TFT scherm als in de webinterface.
ps: het waterverbruik weerspiegelt niet het verbruik van dit jaar. De sensoren zijn maar onlangs aangesloten en geprogrammeerd in de master. Automatisch werken had een hogere prioriteit.
