Communicatie RPi <=> ESP32

MQTT is echt niet zo moeilijk.
Ik ben het onlangs (nuja, draait ondertussen al een jaar hier) ook beginnen gebruiken voor Home Assistant,
was simpeler dan verwacht (ik had het "up and running", inclusief installatie, testing, en communicatie in productie) binnen een half uur.
Je kan zelfs één MQTT server gebruiken voor je hele opzet met meerdere RPI's en meerdere ESP modules. (gewoon ieder z'n eigen topic)

Verder zou je ook gewoon een TCP/UDP webclient/webserver kunnen opzetten in code, maar dat gaat je meer moeite kosten dan met MQTT !
Een soort "chat" zou ook nog een optie zijn, maar dat valt allemaal in't niets, in vergelijking met de "easyness" van MQTT

succes,
Kris

Dankje, Kris. MQTT lijkt inderdaad best doenbaar, en het meest geschikt in deze situatie. Het allerlaatste dat ik ga doen is het gebruiken van poorten 80 of zelfs 443 (http resp. https), dat is pas de kat bij de melk zetten!

Op 26 april 2023 12:08:51 schreef Paulinha_B:
Dankje, Kris. MQTT lijkt inderdaad best doenbaar, en het meest geschikt in deze situatie. Het allerlaatste dat ik ga doen is het gebruiken van poorten 80 of zelfs 443 (http resp. https), dat is pas de kat bij de melk zetten!

Een beetje hacker gebruikt een poort scanner. Dus de andere "open" poort is dan snel gevonden.
Ik neem aan dat je op je "Nodes" de webserver ook uit zet.
Zet je devices in ieder geval op een apart vlan

hkcert.org heeft een heleboel nuttige documenten hierover.
https://www.hkcert.org/f/blog/263544/95140340-8c09-4c9a-8c32-cedb3eb26…

[Bericht gewijzigd door bprosman op woensdag 26 april 2023 13:00:34 (13%)

Misschien gewoon https en dan een openapi maken?
Je kan de authenticatie dan doen met OAuth.

Voordeel is dat dit redelijk standaard is, dus je hebt er veel tooling omheen.

Maar om echt een goed antwoord te geven zou ik moeten weten wat precies de bedoeling is. Ga je nu bestanden of gegeven doorsturen?

[Bericht gewijzigd door hardbass op woensdag 26 april 2023 13:20:44 (28%)

Het gaat over het uitwisselen van meetgegevens, parameters, instellingen (bv. ESP32 meldt: "bad A is boven de drempelwaarde A1", centrale meldt terug: "open klep 24"). Aanvankelijk had ik voorzien om deze in bestandjes te gieten die dan per ftp of sftp of nfs konden worden gedeeld, maar met mqtt is dat niet meer nodig.

"gewoon" https is voor mij helemaal niet gewoon mqtt ook niet, maar lijkt mij wel eenvoudiger op te zetten. Hoe waterdicht het is, dat is nog even te bekijken, maar ik besef best dat vroeg of laat alles kan gehackt worden, 100% security bestaat niet.

@Bram: ja, een apart subnet is voorzien, en dat wordt niet routeerbaar. Met vlan-tagging werk ik totnogtoe niet. Die hkcert-site ga ik eens grondig bekijken, alleen nu niet gelijk onmiddellijk direct...

Settings zouden nog via een bestand kunnen, dat zou enig sinds logisch zijn. Bijvoorbeeld in JSON formaat ofzo.

Meetwaardes en aansturing zou ik absoluut niet via bestanden doen. Dan is MQTT een veel geschiktere oplossing. Wellicht kan je ook wegkomen met ModbusTCP.

"(bv. ESP32 meldt: "bad A is boven de drempelwaarde A1", centrale meldt terug: "open klep 24")"

Let hier wel op! Geen verbinding kan een groot probleem opleveren.

Bijvoorbeeld, als je met een brander een vat opwarmt en de centrale moet bedenken wanneer die brander uit moet slaan dan zal de brander aan blijven als er geen verbinding is. Dat kan best wel gevaarlijke situaties opleveren.

Maar goed, dat is wat lastig in te schatten zonder het systeem beter te kennen

mqtt met TLS en authenticate?

mqtt is een een redelijke standaard voor het uitwisselen van dit soort gegevens en acties.

Gebruik maken van een standaard oplossing is vaak veiliger dan zelf iets maken en wellicht iets over het hoofd zien (tuurlijk het kan altijd) en wat je zegt 100% veilig is iets met een aansluiting nooit.

Wat gebeurt er als iemand een uart aan je esp hangt?

En verder zou je inderdaad logica locaal willen draaien in een esp en alleen de logica oprdrachten (klep 24 open als boven drempelwaarde) oversturen welke lokaal door de esp worden gecheckt

@hardbass: Ja, natuurlijk moet men bij het opzetten van dit soort toestanden bedacht zijn op alle mogelijke manieren waarop er iets mis kan gaan, uiteraard jawel. En dat zijn er heel wat, ik ben het me wel bewust. Dat zit echter op een ander niveau, hier ging het me zuiver over de communicatie.

ModbusTCP zou ik nog eens kunnen bekijken, maar het lijkt me dat ik minstens voorlopig best uitkom met MQTT.

@Gerwin: extra beveiliging op mqtt is zeker te bekijken, goede tip, zo te zien! En inderdaad, het heeft weinig zin het wiel te willen heruitvinden; tenzij men echt iets kan bedenken dat - voor de gegeven opdracht - beter voldoet dan de beschikbare standaarden. Maar voor de gegevensuitwisseling lijkt me dat zeer onwaarschijnlijk.

@allen: dank voor het meedenken!

[Bericht gewijzigd door Paulinha_B op woensdag 26 april 2023 14:28:09 (28%)

Toevallig onlangs deze gezien:

https://www.youtube.com/watch?v=3nwr7tasnLE

Heb hier zelf ook HomeAssistant draaien maar nog niet met ESPhome, wel al ESP32 aangekoppeld via eigen protocol (via UDP) maar vond bovenstaande wel erg interessant.

Op 26 april 2023 15:10:16 schreef KGE:
Toevallig onlangs deze gezien:

https://www.youtube.com/watch?v=3nwr7tasnLE

Heb hier zelf ook HomeAssistant draaien maar nog niet met ESPhome, wel al ESP32 aangekoppeld via eigen protocol (via UDP) maar vond bovenstaande wel erg interessant.

Ah, the guy with the Swiss accent

FTP, NFS en consorte zijn echt bedoeld voor veel grotere machines dan ESP32. Tuurlijk, als het moet dan kan het wel, maar juist in jou geval: Het MOET niet. Nergens voor nodig. Gewoon iets eenvoudigs doen. Je algemene opzet is prima om bijvoorbeeld de presentatie door de raspberry te laten doen, Die raspberry vraagt de ESP32's uit en/of vangt de verzonden data op.

Tip: Schrijf de software zo dat de verzamelde data ergens op de RPI beschikbaar is, en presenteer het dan vanuit die verzamelde data met een apart programma (apache+ PHP script of zo).

Er zijn mensen die de neiging krijgen om dan 1 programma te maken wat alles doet. Zie bijvoorbeeld octoprint. Daar zit dus "de server" die de presentatie doet, ook de data naar de 3Dprinter te sturen. Dat betekent dat als ie te lang over een web-request doet, de 3Dprinter "out of data" komt te zitten. Dus men adviseert: Een raspberry pi 1 is niet snel genoeg om octoprint te draaien.... WTF? Een 700 MHz 32-bit ARM met 512Mb RAM kan een Atmega328 op 16MHz met 2k RAM niet bezig houden???

Had er een apart "stuur-data-naar-printer" programma geweest wat ook een communicatie-kanaal naar de "besturing" in de gaten houdt, dan had DAT op een hoge CPU prio kunnen draaien en kan het prima op een raspberry pi 1.

Maar niet alleen performance is fijn. Ook gewoon voor het maken van de software is het gunstig dat er nu twee aparte delen zijn.

Hehe, dankjewel, beste @rew. Voor mij is het reeds lang duidelijk dat de beste benadering NIET is om een enkele grote doos te maken waar alles in zit, maar veel beter om allemaal kleine doosjes te maken die elks hun eigen gespecialiseerde ding doen, en met elkaar communiceren. Op zijn minst wordt daarmee debugging veel simpeler.

Off-topic voorbeeld: mijn zelfgeschreven navigatie-applicatie valt uiteen in enerzijds het inzamelen van GNSS-informatie, en het wegschrijven derzelve in diverse bestanden, en anderszijds weergave op basis van deze (en andere) bestanden. Valt nu de satellietontvangst uit, dan blijft er gewoon het laatste prentje op scherm staan - met een waarschuwing erbij.

Tussen haakjes (maar dit gaat wel buiten de scope van dit forum) het hele verhaal van "multi-threading" was ook alleen maar nodig om die ene grote doos over meerdere cpu-kernen te kunnen verspreiden; al die kleine doosjes konden reeds veertig jaar geleden probleemloos verdeeld worden over de beschikbare cpu's.

Out of the box kun je iets opzetten met Home Assistant en ESPHome.

Home Assistant op de rPI en ESPHome op de ESP32. Beide zijn ze volledig geïntegreerd met elkaar.

In ESPHome kun je zelf de modules kiezen, dus kies je niet voor de Webpage optie, dan heeft de ESP geen locale webpagina. Optie OTA kun je kiezen, UART wel of niet enz. De communicatie tussen ESP en HA is encrypt, maar nooit zelf in verdiept. Zie https://esphome.io/index.html

homeassistant was een van de hele vroege afvallers.

Tenzij ik het grondig verkeerd begrepen heb is dat helemaal afhankelijk van een eigen zeer knutselige versie van Linux. Zoals ook anderen reeds aanbevolen houd ik me liever aan standaardtoestanden.

Dat heb je verkeerd begrepen (of ik zit verkeerd). Je bent vrij in de installatie methoden. Maar om het iedereen makkelijk te maken, kan het gelijk vanuit de 'Raspberry Pi Imager'tool. https://www.home-assistant.io/installation/

Op 26 april 2023 17:54:17 schreef Paulinha_B:
homeassistant was een van de hele vroege afvallers.

Tenzij ik het grondig verkeerd begrepen heb is dat helemaal afhankelijk van een eigen zeer knutselige versie van Linux. Zoals ook anderen reeds aanbevolen houd ik me liever aan standaardtoestanden.

Dan heb je het inderdaad verkeerd begrepen, dit kan ook gewoon op een "gewone" Linux geinstalleerd worden, of in een (bijv. Docker) container.

Overigens is het geen "Knutselige versie" van Linux maar een Linux versie waar alle (voor HomeAssistant) overbodig spul uitgehaald is.

Sommige pakketten zijn "een gedoe" voor beginners om te installeren. Sommige pakketten bieden dan een image aan van een distributie met de software reeds geinstalleerd.

Octoprint / Octopi is een voorbeeld. Ik heb Octoprint op mijn Orangepi gewoon zelf met de hand geinstalleerd. Dat was zo'n gedoe, dat ik voortaan maar gewoon een raspberry pi inzet ipv de iets goedkopere orange pi.

bv. ESP32 meldt: "bad A is boven de drempelwaarde A1", centrale meldt terug: "open klep 24".

Ik zou het nooit op die manier doen via MQTT. Want er is geen enkele terugkoppeling. Dan zou ik eerder een opdracht geven als "Centrale stuurt drempelwaarde naar ESP32. ESP32 doet de rest. En evt ESP32 meldt actueel niveau aan centrale."

Dankje, met de programmatie en de logica kom ik wel rond. Mijn vraag gold enkel de communicatie.

staat nog een leuk stukje op de Elektuur site :
https://www.elektormagazine.nl/news/mijn-pad-naar-het-iot-3-mqtt

Op 26 april 2023 17:54:17 schreef Paulinha_B:
homeassistant was een van de hele vroege afvallers.

Tenzij ik het grondig verkeerd begrepen heb is dat helemaal afhankelijk van een eigen zeer knutselige versie van Linux.

Ik ga je aanname niet bevestigen Maar het draait (als je hun image gebruikt) op een embedded linux.
Dat mag bij jou onder 'knutselig' vallen. Ik zie dat eerder als afgeslankt. Minder meuk is minder mogelijke aanvalshoeken.

Maar ... je kunt het prima onder je standaard Debian / Raspbian / whatever linux versie draaien als je dat wilt. De installers daarvoor staan ook gewoon tussen de downloads. Ik heb het zelf enkele jaren op Raspbian gedraaid omdat hun image destijds nog niet kon booten van USB.

Als je iets van automatisering wilt gaan bouwen is echt het laatste wat ik zou doen het wiel opnieuw gaan uitvinden. Er lopen verschillende projecten die al jaren met een berg aan mensen aan gewerkt is (3,197 Contributors in het geval van HASS)

Een groot voordeel is dat ook een hoop commercieel spul al compleet is voorgebakken (denk aan sensoren, schakelaars, lampjes en schakelbare stopcontacten van allerlei fabrikanten en protocollen)

En als je zelf wilt fröbelen, bijvoorbeeld omdat je wilt fröbelen of omdat er geen commerciële toepassing beschikbaar is dan is ESPhome een goed begin.

[Bericht gewijzigd door Sine op donderdag 27 april 2023 09:38:57 (15%)

Een veilig communicatieprotocol maakt het nog niet veilig, dan kan het net zo goed zo lek als een zeef zijn

@Sine: Dank voor de verduidelijking over het onderliggende O/S.

Denk maar dat ik zelf wil fröbelen, bijvoorbeeld omdat ik wil fröbelen.
Er zijn er wel die hun eigen audioversterker of zendstation fröbelen, waarom zou ik dan geen software fröbelen?

Op 27 april 2023 09:57:12 schreef Paulinha_B:
@Sine: Dank voor de verduidelijking over het onderliggende O/S.

Denk maar dat ik zelf wil fröbelen, bijvoorbeeld omdat ik wil fröbelen.
Er zijn er wel die hun eigen audioversterker of zendstation fröbelen, waarom zou ik dan geen software fröbelen?

De kans dat je er ergens een veiligheidslek in fröbelt is aanzienlijk groter dan in een open source community waar een paar duizend man meekijken.