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.

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 (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.

Alles kan gehacked worden, maar wat gezonde risico analyse is op zijn plek.

Bij internetbankieren, bankpassen, browsers en operating systemen: ja, doe alles op alles om dat veilig te doen.

Een intern netwerk, waar geen zaken met hoog profiel (sluizen, bruggen, reactoren) of veel data aanwezig is. Tsja. De echte boeven met randsomware pakken het liefst waar veel geld zit en veel gegevens via makkelijke geautomatiseerde hacks. Meestal gewoon bestanden op Windows (netwerk)schijven via phishing.

Een zelf ontwikkelde MQTT omgeving waarbij je de excessen en fail-safe ook nog via hardware en/of lokale software doet lijkt me nu niet iets waar je je extreem veel zorgen over moet maken.

Let ook vooral op de admin interface van routers e.d. dat zijn namelijk 'bekende' plekken. Net als software updates.

Een ESP of Raspi met MQTT in een pand met beveiligde wifi lijkt me eerder door elektriciteitsstoring, storm-, brandschade of diefstal geraakt te worden dan door een hacker.

Precies K7Jz! Een browser is een stuk software wat miljoenen mensen draaien. Als daar een bug in zit, kan je duizenden tot honderdduizenden computers "overnemen" om een DDOS op te draaien. Of op een dag draait de hacker dan "heeft deze computer bitcoins? maak ze over naar hacker-verzamel-rekening".

Dat zijn gewilde targets. De basics (beveiligde wifi, router die verbindingen van buiten niet zomaar doorlaat) maken dat een hacker het vooruitzicht heeft dat ie je slaapkamer lichten aan en uit kan zetten. Whohooo!

Nee, dat is niet interessant. Komt gewoon goed.

Op 27 april 2023 10:51:47 schreef rew:
Precies K7Jz! Een browser is een stuk software wat miljoenen mensen draaien. Als daar een bug in zit, kan je duizenden tot honderdduizenden computers "overnemen" om een DDOS op te draaien. Of op een dag draait de hacker dan "heeft deze computer bitcoins? maak ze over naar hacker-verzamel-rekening".

Dat zijn gewilde targets. De basics (beveiligde wifi, router die verbindingen van buiten niet zomaar doorlaat) maken dat een hacker het vooruitzicht heeft dat ie je slaapkamer lichten aan en uit kan zetten. Whohooo!

Nee, dat is niet interessant. Komt gewoon goed.

Je verwarming op 35 Graden zetten terwijl je er niet bent is dan weer wat minder.

Als je zin hebt om te gaan fröbelen, fröbel dan je eigen netwerk protocol in elkaar. EspressiF heeft ook een "mesh network" dinges protocol gemaakt voor de ESP's. Je kunt de radio in de ESP32 dus ook helemaal zonder WiFi gebruiken als een generieke 2.4GHz transceiver.

En dan fröbel je natuurlijk ook je eigen beveligingslaag in elkaar die druipt van de "Security though obscurity". Hoe warriger je de code schrijf hoe beter. Als je het dan ook nog zo in elkaar fröbelt dat de uiteindelijke commando structuur van je protocol obscuur is en een klein "aanvals oppervlak" heeft, dan is het nog een stukje veiliger.

Daar bovenop kun je ook nog paketten loggen. Als er dan een aanval komt, dan gaat vermoedelijk het aantal berichten fors omhoog. Dit kun je dan detekteren, aan een alarm bel trekken, en tegelijkertijd (half) foutieve antwoorden terug gaan sturen om die aanvaller in de war te brengen.

Of je fröbelt 2 (of meer) verschillende protcolollen in elkaar. Dan kun je bij een hack poging overschakelen naar een ander protocol, of je gebruikt de protocollen door elkaar om hackers nog meer in de war te brengen. En zo valt er vast nog wel meer in elkaar te fröbelen.

[Bericht gewijzigd door Kortsluiting_Online op (47%)]

Op 27 april 2023 11:01:53 schreef bprosman:
[...]
Je verwarming op 35 Graden zetten terwijl je er niet bent is dan weer wat minder.

Er zijn altijd hele vervelende sabotage hacks te verzinnen. Waarschijnlijk zal een hacker of beter gezegd geautomatiseerde malware liever voor diefstal en afpersing gaan dan voor pesterij.

Naast encryptie die zo goed als onfeilbaar is kan je voor het geval dat dat of knooppunten worden gekraakt ook nog zaken configureren. Een thermostaat module kan je op maximaal 23 vastzetten en ook na een bepaalde tijd weer laten terugvallen naar een standaard waarde.

ip2ban is een voorbeeld van een interessante aanpak. Naast het blokkeren na X foutieve inlogpogingen worden ip addressen ook geblokkeerd als ze veel 404 pagina's opvragen of gaan zoeken op /admin/ /wp-admin etcetera.

Op 27 april 2023 09:57:12 schreef Paulinha_B:
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?

Als je uitgaat van een standaard zoals Home Assistant i.c.m. ESPHome valt er nog genoeg te fröbelen. Zowel in Home Assistant als in ESPHome. Als bijvoorbeeld de communicatie niet veilig genoeg vind, kun je dit altijd verbeteren. Help je de community ook nog mee.

Mensen die hun eigen audioversterker of zendstation fröbelen gaan meestal uit van een of meerdere bestaande ontwerpen die worden verbeterd. Degene die van 0 af aan beginnen hebben in ieder geval jaren ervaring met het concept.

En eeh domotica platform in elkaar freubelen staat niet in verhouding tot het bouwen van een buizenbakje.

Dat komt pas in de buurt als je ook zelf je buizen gaat maken.

@K7Jz: daar zitten een paar fraaie ideetjes tussen, dankjewel, ik laat het bezinken.

@Sine: het verschil is dat ik vele decennia professioneel met software ben bezig geweest, inclusief beveiligingsbeslommeringen; daarentegen heb ik met audio alleen maar gehobbied, en niet iedereen was onder de indruk van de resultaten - ook al moest men wel toegeven dat het best fraai klonk. Sta me ook toe om nogmaals te herhalen dat ik deze draad enkel opende om over de communicatie te brainstormen - en dat is al behoorlijk vruchtbaar gebleken - daar waar ik de applicatiekant best wel onder controle denk te hebben.

Ik zie mezelf dan ook veel eerder iets domotica-achtigs programmeren (het is ook geen echte domotica, he, zoals van het begin af aan gesteld) dan dat ik zelf buizen ga maken. Trouwens op mijn leeftijd zijn mijn longen te zwak om zoveel vacuum/onderdruk te produceren :)

Op 29 april 2023 13:45:11 schreef Paulinha_B:
Trouwens op mijn leeftijd zijn mijn longen te zwak om zoveel vacuum/onderdruk te produceren :)

Ook dan doe je iets verkeerd: je longen zijn nodig om glas te blazen, het vacuum maak je met een pomp... :+

Alle gekheid op een stokje, HomeAssistant draait stabiel en biedt heel veel knutselmogelijkheden. Zelf heb ik een eenvoudige Remeha thermostaat met een ESP32 bestuurbaar gemaakt met een eigen protocol. Werkt gewoon met shell (bash) scripts en de tools die we onder Linux hebben (ncat e.d.). De 'voordeur controller' die ik onlangs met een ESP32 heb gemaakt regelt de buitenlamp, deurbel, camera met monitor, huisnummer en de pakketbox. Alles inmiddels geintegreerd in HomeAssistant.