Door Koen Vervloesem

Freelanceredacteur

Raspberry Pi als brein van je smarthome

Deel 1: Flexibele domoticahardware

06-09-2021 • 06:00

171

Singlepage-opmaak

Interferentie op 2,4GHz

Wie de high-level specificaties van de hier vermelde draadloze protocollen al eens heeft opgezocht, heeft wellicht gemerkt dat vele in hetzelfde frequentiedomein rond 2,4GHz werken. Dat geldt niet alleen voor Zigbee en Thread, die beide het op 2,4GHz werkende IEEE 802.15.4 als verbindingslaag gebruiken, maar ook voor bluetooth en Wi-Fi 4 en 6. Hoewel er bij het ontwerp van deze protocollen rekening mee is gehouden, levert dat in minder optimale omstandigheden storende interferentie op. Als je een multiprotocolgateway van je Raspberry Pi maakt, hou je hier dus maar beter rekening mee. Er zijn talloze studies gedaan naar interferentie tussen verschillende netwerken op 2,4GHz.

Een eerste maatregel tegen interferentie die je kunt nemen, is geen wifi gebruiken op je Raspberry Pi. Als je het toch niet gebruikt, schakel je dit het best gewoon uit. Dat kan met de device tree overlay 'disable-wifi' in /boot/config.txt. Voor de betrouwbaarheid is het zoals gezegd toch al beter om ethernet te gebruiken voor netwerkconnectiviteit. De interferentie met andere protocollen op 2,4GHz is een extra reden. Gebruik je op je Raspberry Pi ook geen bluetooth voor domoticadoeleinden, schakel dat dan eveneens uit met de overlay 'disable-bt'.

Verder kun je het best verschillende 2,4GHz-radio's op een afstand van elkaar plaatsen. Twee hats op elkaar monteren of twee USB-transceivers naast of boven elkaar in je Raspberry Pi steken is dus geen goed idee. Een korte USB-verlengkabel om je Zigbee- of Thread-transceiver aan te sluiten en iets verder te leggen, zal een betrouwbaarder netwerk opleveren. Het ontvangen vermogen is immers omgekeerd evenredig met het kwadraat van de afstand.

USB-verlengkabel
Met een USB-verlengkabel kun je deze goedkope, op CC2531 gebaseerde Zigbee-adapter verder van storingsbronnen leggen.

De juiste kanalen

Uiteraard moet je ook rekening houden met de omliggende 2,4GHz-netwerken, zowel van jezelf als van je buren. Heel wat draadloze iot-apparaten werken bijvoorbeeld niet op 5GHz, maar op 2,4GHz. Niet alleen commercieel verkrijgbare, maar ook doe-het-zelfapparaten met een ESP8266- of ESP32-microcontroller.

De gebruikte kanalen zijn daarbij belangrijk. wifispecialist MetaGeek heeft een inzichtelijke uitleg over coëxistentie van Zigbee en wifi, die ook geldt voor Thread en wifi, omdat Thread dezelfde 802.15.4-kanalen gebruikt. Als je bijvoorbeeld de drie niet-overlappende wifikanalen 1, 6 en 11 gebruikt, storen die de 802.15.4-kanalen van 11 tot en met 24. En dat terwijl 802.15.4 maar zestien kanalen rond 2,4GHz heeft, genummerd van 11 tot en met 26.

Om interferentie te voorkomen, kun je wifikanaal 11 ongebruikt laten, zodat 802.15.4-kanaal 24 niet wordt gestoord. Dan stel je voor je Zigbee- of Thread-netwerk kanaal 24 in. Of je laat wifikanaal 6 ongebruikt en werkt dan met 802.15.4-kanaal 18. De zijbanden van de wifikanalen, die geen wifidata dragen, kunnen overigens ook nog storen. Dit effect speelt vooral als de wifizender in de nabijheid is. Een strategische plaatsing van je Zigbee- en Thread-apparaten helpt hierbij al veel. Overigens houd je de wifikanalen het best 20MHz breed in plaats van 40MHz om de interferentie met 802.15.4 zo laag mogelijk te houden. Uiteraard heb je dan wel minder bandbreedte tot je beschikking in je wifinetwerk.

Zibgee-kanalen
Stel de juiste kanalen in je wifiaccesspoints in om de overlap met 802.15.4-kanalen te reduceren. Afbeelding: MetaGeek

Tot slot

De Raspberry Pi is een krachtig processorbordje met een uitgebreid ecosysteem van hardware om er een domoticacontroller van te maken. Daarbij moet je wel goed nadenken over betrouwbaarheid en interferentie tussen draadloze protocollen, maar dan heb je een flexibele en toekomstvaste basis voor de automatisering van je huis.

Met hardware alleen ben je uiteraard niets. In een volgend artikel bekijken we daarom enkele geïntegreerde opensourcedomoticaplatforms voor de Raspberry Pi met hun ecosystemen. Ook op dat gebied heb je heel wat keuze en is grote flexibiliteit mogelijk.

Lees meer

Reacties (171)

171
170
82
8
0
68
Wijzig sortering
Ik verwachtte hier toch behoorlijk wat meer diepgang. Domotica houdt vooral niet op bij de hardware! Want commerciele partijen als Fibaro maken niet alleen een gelikte doos, maar verzorgen ook authenticatie en toegang vanaf het internet, alsook een app voor je telefoon. Hoe doen de open source partijen dat? Werkt de boel nog als je internetverbinding eruit knalt? Met wat voor comfort kun je dan wel scripts maken? Hoeveel flexibiliteit win ik met de open source spullen ten opzichte van Homey, Vera en Fibaro? Want dat is het echte onderscheid tussen de commerciele partijen en het open source spul en dus de reden om voor de Raspberry Pi te kiezen.

Ter verduidelijking, ik heb Domoticz en Fibaro naast elkaar draaien, waarbij Domoticz de spullen afhandeld die Fibaro niet doet (energiemeting en zonnepanelen) en de HABridge runt voor voice control via Alexa. Eerst had ik de ambitie om de Fibaro er uit te gooien, maar Domoticz was zo basic qua opzet dat ik daar mee opgehouden ben. Zeker omdat de app vooral niet beviel bij mijn vrouw en kinderen.

edit: verduidelijking.

[Reactie gewijzigd door J_van_Ekris op 22 juli 2024 14:48]

Inderdaad @Femme moest hier op in gaan. Hij heeft wel de meest domotica huis van Nederland. Hier kan volgens mij niemand aan tippen.

Echter nu ik er bij nadenk is hij niet in zee gegaan met Rpi maar juist met eigen spul en programmeertaal
Ik heb mijn huis altijd op andere single board computers gedraaid, o.a. een Odroid C2, XU4 en N2 omdat die sneller waren dan de Raspberry Pi's en betrouwbaarder eMMC geheugen hebben. De Pi 4 is qua performance wel ok, alleen jammer dat er nog steeds geen eMMC-module of m.2-ssd op kan. De Compute Module 4 lost dit wel voor je op.

Inmiddels gebruik ik een Ryzen Embedded vanwege de toegenomen belasting en geheugengebruik. Omdat mijn systeem overwegend bedraad is en vooral de aanwezigheidsdetectie veel events triggert (de pir- en radar-sensoren triggeren continu de bijbehorende digitale uitgangen, timeouts zijn softwarematig) is wat meer cpu performance gewenst. Tevens doe ik real time energiemonitoring op alle groepen in de verdeler (30 enkelfase, 7x drie-fase) wat samen met alle andere variabeleveranderingen in het systeem zo'n 50 datapunten per seconde oplevert die worden weggeschreven naar InfluxDB.

Wat betreft de hardware is de single board computer eigenlijk niet zo'n spannend. Een RPi is toevalig goedkoop en makkelijk verkrijgbaar. Welke hardware je gebruikt voor je sensoren en actoren is veel bepalender voor de mogelijkheden en de betrouwbaarheid. Hoe fijn, gebruiksvriendelijk en slim het systeem uiteindelijk werkt hangt vooral af van de software.
M.2 (SATA) SSD kan volgensmij in een van de Argon behuizingen over de USB 3 bus. Dan heb je wel de betrouwbaarheid en formfactor van een SSD, echter kan men dan geen SSD-snelheden verwachten.

Edit:
Ik heb die behuizing, en die bevalt me erg goed. Als ik me niet vergis zit er bij mij ook een IR transciever óf ingebouwd óf kan er simpel ingebouwd worden.

[Reactie gewijzigd door reaping miner op 22 juli 2024 14:48]

Wat gebruik je om de stroom te meten? Kant en klare DIN rail ammeters nemen nogal veel plaats in..
Conventionele tussenmeters zouden inderdaad veel te veel ruimte innemen.

Ik gebruik Eastron SDM630MCT-2L-meters die twee driefase groepen kunnen meten met behulp van externe current transformers. Zolang je maar de juiste fase meet op de juiste ingang kun je ze ook voor enkelfase loads gebruiken. Een SDM630MCT-2L berekent dan weliswaar niet het energieverbruik per fase. De nieuwere SDM630MCT-4L (met 4x 3-fase) kan dat wel.

Nog wat mooier voor grote verdelers zijn circuit branch monitors die onder andere in datacenters worden toegepast om het energiegebruik per klant af te rekenen. Ik heb hier een Anord Mardix liggen die tot 96 circuits kan meten in een hele compacte behuizing.
Thanks voor je uitgebreide antwoord! Ik vind zulke dingen zelf super interessant om te meten, maar in de zekeringskast thuis is er totaal geen plaats. Ik dacht eraan ze te herbedraden, maar dan moet het wel een upgrade zijn met iets als dit. Heb weer wat nieuws om vanalles over op te zoeken ;)
In een bestaande huis-tuin-en-keuken groepenkast heeft inderdaad niet de ruimte om CT's op alle fasedraden te kunnen aanbrengen. Een paar lukt vaak wel maar is erg prutsen qua ruimte. Ik heb mijn groepenkast volledig opnieuw opgebouwd en een rij van 22x22cm kasten gebruikt voor CT's en een klemmenstrook voorlpotentiaalverdeling. De ruimte kon ik winnen door aardlekautomaten te gebruiken ipv gewone zekeringsautomaten in combinatie met losse aardlekschakelaars.

Oplossingen zoals de Anord Mardix Multi Circuit Monitor maken het qua bekabeling wel een stuk makkelijker maar alsnog is het alleen geschikt voor retrofit in industriële verdelers. Een consumenten groepenkast moet je opnieuw opbouwen om ruimte te creëren.
Misschien de bekendste maar zeker niet de grootste of uitgebreidste.
Ik ben wel eens ergens in een huis geweest. Dat was echt ongelofelijk.
Voor de duidelijkheid, ik heb het niet over mijn eigen domotica installaties.
Domotica stopt inderdaad niet bij de hardware, maar dit artikel wel. Zoals er in staat is dit deel 1 en die gaat over hardware.

Nog even geduld dus op een vervolgdeel.
Domotica stopt inderdaad niet bij de hardware, maar dit artikel wel. Zoals er in staat is dit deel 1 en die gaat over hardware.
Dat stuk van de titel krijg je pas te zien nadat je je Plus-artikel hebt geopend. Erg flauw!
Volledig mee eens. Artikel gelezen; conclusie je kunt een Raspberry Pi gebruiken voor je smart-home. Joh! Als je dit artikel vergelijkt met bijvoorbeeld het blog van Femme, dan is dit imho geen plus artikel. Even afwachten op deel 2 dan maar.
wellicht had je daarom ook de volgorde van artikelen moeten omdraaien. Het oplossen van een probleem start je niet met het kopen van hardware, maar met analyse van het probleem en het matchen met een software oplossing, welke vraagt om bepaalde hardware.
Mee eens. Ik kies niet voor "Raspberry Pi", maar voor een stuk software waar ik vervolgens hardware onder ga schuiven. En alleen Raspberry Pi beschouwen is dan erg beperkt: waarom geen NUC of dedicated Homey of Fibaro hardware beschouwen?
En een rpi is nog niet volledig, als je ook zigbee of 433mhz wil doen. Een van de pluspunten van Homey.

Hoewel een Tweaker toch mogelijk liever eigen hardware heeft
Rpi is zeker niet volledig, dat klopt, Maar is wel zeer goed uit te breiden. Ik ben bijvoorbeeld zeer tevreden met mijn RPi icm mijn Zigbee USB tranciever. Ik gebruik dit samen met Zigbee2MQTT en lijkt prima te werken met HomeAssistant.
Dit inderdaad. Wij hebben Home Assistant op een RPI4 draaien, en ik moet zeggen dat ik erg onder de indruk ben van het platform. Verlichting en slimme schakelaars gaan erg goed (Philips Hue en Shelly in gebruik, allebei werken voortreffelijk). Zelfs de versterker integreert naadloos. Sommige zaken zijn echter bijzonder lastig te integreren met het platform, met name verwarming (Magnum slimme WiFi thermostaat heb ik geprobeerd, is een drama), vanwege gesloten protocollen.
Over de magnum thermostaat: is dat geen tuya device? Daar zijn wel custom integraties voor, weet ik toevallig.
Dat is het inderdaad. Ik ga daar nog even wat beter naar kijken, bedankt voor de tip!
Localtuya of de nieuwe tuyav2 heten de integraties die ik heb getest. Kun je iig iets
Ik heb dit een tijdlang met ZWave thermostaten gedaan en een Zwave transceiver. Werkte perfect!
Ik vind het geen makkelijke oplossing hoor, dat Home Assistant..

Ik dacht het wel 'even' te leren aangezien open source oplossingen vaak een goede community hebben maar duidelijke n00b-handleidingen krijg ik niet gevonden.

Heb daarom nu alleen maar AdGuard Home als plugin erop staan en een kabel gekocht waar ik mijn 'slimme' meter mee kan uitlezen. Tenminste, alleen het actuele gebruik want ik krijg het niet eens voor elkaar om mooie overzichtjes te maken waar ik online wel eens afbeeldingen van zie.

Ik snap er dus geen drol van en durf daarom eigenlijk geen board of controller oid aan te schaffen zodat ik aan echte domotica kan beginnen. Vind die z-wave inbouw schakelaars en dimmers erg mooi maar veel te duur als ik het niet werkend krijg.
Geeft niet, je leert het vanzelf. HA wordt steeds gebruiksvriendelijker, maar het is niet heel simpel allemaal.
Zeker het recorder en statistics deel icm custom properties... Maar goed, is dus nog in ontwikkeling en de debug messsgrs zijn met de laatste update weer beter geworden.
Ik heb ook wel even zitten pielen voordat het werkte, ook omdat ik niet de docker oplossing wilde. Als je een beetje handig bent met python heb je het wel zo voor elkaar. Kortweg komt het hierop neer (Linux):
- Disable SE Linux (wellicht dat dit nog wel te fixen valt)
- Installeer de python dev packages
- Installeer de python package voor home assistant
- Open poort 8123 in je firewall
- Configureer home assistant als een service zodat-ie start bij 't opstarten

Daarna wijst het zich redelijk vanzelf. Mocht je het willen proberen en er niet uit komen mag je altijd een pm sturen :).

PS: shelly.cloud levert inbouwschakelaars en lampen voor <15 euro, op wifi. Persoonlijk vind ik 't ideaal.
Dat vind ik dus niet.. Zoals gezegd heb ik gewoon de Home Assistant OS op een Pi4 gezet (dat vind ik dan juist het makkelijke deel)....

Echter, bij alleen al het maken van coole dashboards loop ik ramvast en snap ik de gegeven uitleg niet eens. En ja, inderdaad, op wat powershell ervaring na totaal geen afiniteit met programmeren.
Maar gebruiksvriendelijk is het zeker niet.
Ja, dit vind ik ook een gebrek, ik had ook diepgang verwacht.
Ik ben zelf al jaren een fan van Domoticz en gebruik dit nog als enige in combinatie met de webinterface voor de mobiel.

Tot nu toe kan ik hier behoorlijk mee uit te voeten met 200 sensoren.
In het begin 7 tot 9 jaar Domoticz geleden gehad, totdat ik bij iedere software update weer een paar dagen bezig was om mijn eigen sensoren aan de praat te krijgen. Overgestapt op FHEM en nooit meer van weg gegaan deze werkt met plugins en was vele malen meer schaalbaar dan Domoticz. Alle sensoren in een lange switch statement werkt gewoon niet. Weet niet of dat nu nog is. Zolang FHEM werkt blijft het lekker draaien.
Die App problemen van Domoticz heb ik ook gehad met mijn vrouw en dochter.
Mijn zoon had er geen problemen mee.
De bediening en de NL vertaling van Domoticz zijn niet de beste en zouden echt veel beter kunnen.
Met Open-hab ook dat soort problemen. HA was iets beter moet ik zeggen.

Met de Lupus XT2-plus set (voornamelijk Alarm maar ook smarthome) is mijn vrouw erg blij met de App, ondanks dat die alleen in EN en DE taal beschikbaar is en zij die talen niet machtig is.
We wachten nog op ES en NL van Lupus Electronics :) :+

[Reactie gewijzigd door Antonio di op 22 juli 2024 14:48]

Welke nuance ik absoluut mis is de component beveiliging. Leuk dat je allemaal domotica hebt, maar al mijn iot apparaten die via TCP/IP (en dus niet bluetooth of zigbee) werken, zitten op een gastnetwerk. Als je dit professioneler wil aanpakken kun/hoor je voor domotica een apart vlan te gebruiken. Niet alleen omdat veel iot apparaten een cloud dienst gebruiken en je niet weet wat daardoor allemaal op je thuis netwerk wordt verzonden ( zie ook de Ring apparatuur die via LORA locatie tracking beter mogelijk maken) maar ook omdat praktisch alle iot apparatuur achterloopt met beveiliging, bijvoorbeeld door een hardware RNG die eenvoudig te kraken is effectief geen beveiligde verbinding overblijft.
Dit onderschrijf ik.

Komt zelf uit de (virtual) networking en security wereld, hele huis vol met domotica, maar eerst netjes alles scheiden. Kom zo veel mensen tegen met een "slim" deurslot welke vervolgens gewoon vrij te bedienen is vanaf het wireless netwerk, of nog erger, met een app dat ding op afstand via de cloud open kunnen doen. Het is wel je voordeur!

Ook simpele dingen als externe connectiviteit, al die apparatuur probeert tegenwoordig met een server/service op het internet te communiceren, dat zijn allemaal verbindingen die het netwerk open zetten voor buitenaf. Mijn IoT/Domotica netwerk heeft zelfs geen internet toegang om dit te voorkomen.
Wat heb je aan een "slim" deurslot, als je het niet vrij te bedienen is via je wireless netwerk? Ik zie de toegevoegde waarde zelf totaal niet, omdat ik zelf de toegang tot mijn deur wil beheren en ik geen situatie kan bedenken dat ik op afstand een deur open ga doen, maar als je zo'n ding hebt, dan wil je er ook makkelijk gebruik van kunnen maken. Overigens moet je als hacker wel heel veel moeite doen, om via de route van de cloud in te breken. Dan moet je weten dat iemand een dergelijk slot heeft, dan moet je weten welk ip-adres dat slot heeft, en dan moet je nog inbreken in de cloud.

De meeste apparatuur heeft overigens geen verbinding van buiten af nodig. In het firewall van mijn modem staat dat dicht en levert nooit problemen op.

Alle apparaten op het gast netwerk maakt dat je met je telefoon ook op het gastnetwerk moet inloggen, om te kunnen bedienen. En dan kun je met je telefoon (of tablet) weer niet bij je eigen netwerk, dus moet je binnenshuis twee wifinetwerken in de lucht houden, en maakt je smartphone altijd weer net verbinding met het netwerk wat je niet wilde.

Het is allemaal vast wel weer oplosbaar, maar daarmee ook weer ingewikkelder en meer kennis vereist. Daar tegenover staat dat het risico van een inbraak op jouw netwerk via domotica apparatuur heel erg klein is.
Overigens moet je als hacker wel heel veel moeite doen, om via de route van de cloud in te breken.
Dat is helaas veel gemakkelijker dan het lijkt, het is digitaal in een cloud, dus er is een account op de cloud met een email adres en wachtwoord (en grote kans dat er geen 2FA op zit), het is net zo makkelijk/moeilijk als het toegang verkrijgen tot een Facebook, Twitter of andere account met wat social engineering.
Alleen in dit geval is het de voordeur in plaats van een "social" account zonder waarde.
De meeste apparatuur heeft overigens geen verbinding van buiten af nodig. In het firewall van mijn modem staat dat dicht en levert nooit problemen op.
Maar hoe staat het met de verbinding die naar buiten gaan vanuit je device en daarmee toegang van buiten af opent? Een legio aan apparaten die thuis staan hoef je niets voor toe te staan op je firewall/router en toch kun je er van buitenaf bij, zelfs als je inkomend helemaal dicht getimmerd hebt.
Het is allemaal vast wel weer oplosbaar, maar daarmee ook weer ingewikkelder en meer kennis vereist.
Dat was ook een het punt van mijn reactie. Er wordt veel te makkelijk omgegaan met een "smart" home door de gemiddelde gebruiker. Je geeft letterlijk controle uit handen naar een apparaat dat door mensen misbruikt kan worden als je niet weet wat je doet. Dat iemand je lampen aan of uit gaat zetten voor de grap is alleen vervelend, maar als mensen je deuren van het slot kunnen halen, je garagedeur of je ramen/rolluiken kunnen openen zonder jouw toestemming wordt het een heel ander verhaal.
Wat betreft verschillende WiFi, dat is inderdaad allemaal op te lossen, zo ben ik zelf verbonden met mijn telefoon maar kan wel bij domotica spullen die helemaal afgeschermd zijn. Maar ja, daar moet je het wel voor snappen en heb je ook weer wat betere apparatuur voor nodig in je netwerk.
Daar tegenover staat dat het risico van een inbraak op jouw netwerk via domotica apparatuur heel erg klein is.
Ik denk dat dat risico steeds groter wordt gezien de adoptie van domotica, een simpele Google Home kan al voor problemen zorgen.

[Reactie gewijzigd door drocona op 22 juli 2024 14:48]

Ik heb van van Homematic IP in huis en ik heb geeneens een account. Dat device meldt zichzelf zelfstandig aan op de server. Maar je hebt gelijk in geval men graag wilt weten waar je woont, je dat naar waarheid invult en men is zo lomp om naw in de zelfde database als het device op te slaan, dat het dan wel makkelijk wordt.

Apparaten die van buiten af benaderbaar zijn, maken zelf een verbinding met de server. Mits beveiligd, kom je er als hacker niet tussen (tenzij je het ssl-protocol weet te kraken). Ik had bij het configureren van mijn IP-telefonie per ongeluk de firewall open gegooid. Prompt had ik geen telefonie meer. Juist omdat in het verleden nog wel eens werd ingebroken op devices om ze automatisch naar betaalde nummers te laten bellen.

Het grootste risico zit wel in de hubs zelf die allerhande protocollen ondersteunen. Als dat protocol niet zo veilig is, heb je geen internetverbinding nodig, maar breek je via een draadloze verbinding in op de hub zelf.
Wanneer krijgt een artikel op Tweakers het "plus" predikaat?
Ik zou zelf de lat wat hoger leggen, want voor een plus artikel verwacht ik wat meer diepgang..
Ik vermoed dat ze dit artikel hebben gesplitst om mensen die 3 gratis berichten lezen te verleiden om alsnog een plus abonnement te nemen, helaas ten koste van de kwaliteit van het artikel (naar mijn mening).
Mijn ervaring met een RPi als server voor Home assistant zijn niet al te best. Een keer een sd kaart die kapot ging en zelf een keer een RPi die kapot ging. Ik ben uiteindelijk overgeschakeld naar een NUC met HassOS in een VM, en dat bevalt een stuk beter. Gewoon de hele VM laten backuppen 😬
Als je een RPi in een productieomgeving gebruikt (dus ook als Home-server) *Altijd* Log2Ram gebruiken, het is zo simpel en je SD-kaartje gaat ineens 1000x langer mee, zie: https://github.com/azlux/log2ram - daarmee maak je een ramdisk in je RPi-geheugen voor logbestanden. Dat kan tegenwoordig makkelijk met de sloten geheugen voor de Pi4. En geen schrijfacties meer op je SD = geen slijtage. :)

Of misschien nog beter inderdaad vanaf een SSD draaien (en dan meteen ook log2ram toepassen), dat kost ook nog maar bijzonder weinig tegenwoordig.
Vorig jaar oktober gestart met HomeAssistant op een SD kaart, draait nog steeds! Wel maak ik regelmatig backups als ik m'n config wijzig of zaken update.

[Reactie gewijzigd door Bas170 op 22 juli 2024 14:48]

Ik draai zelf ook home assistant op een raspi 4b met wd purple micro SD. Ik gebruik daarnaast MariaDB op mijn Synology Nas om alle sensor data op te slaan. En dit moet bij ons ook wel... Ik schrijf gemiddeld 900.000 events weg per 5 dagen. (Lamp aan, airco aan, temp sensor omhoog) etc etc. Is allemaal 1 event.

Zelfs een WD purple zal niet lang meegaan als deze een paar miljoen writes per week moet doen. En dan is er sinds kort nog de statistics bij gekomen die op de lange termijn sensor data bijhoudt. Die zit ook al op een 120.000 database entries.

Beter kun je inderdaad een zeer betrouwbare HDD gebruiken om deze data op te slaan. Voor de rest heb ik nu in HA een 1200 entities en is bijna ons hele huis nu voorzien van domotica. De cpu van de raspi 4b draait nu op 5 - 10% load gemiddeld. Geheugen zit op 1.5 GB gebruikt. En de opslag op bijna 15 GB. Ik adviseer voor een groter domotica systeem altijd minimaal 64 gb opslag

Ik vind overigens het artikel zeer weinig informatief. Maar wellicht komt dit ook omdat ik er zelf al veel vanaf weet
Ik vond het juist een reden om de HA opslag los te hebben van mijn NAS. Op mijn NAS heb ik belangrijke bestanden, daarom gebruik ik een losse usb Samsung T5 SSD. Overigens lukt mij dit op mijn Pi 3B+ alleen met een supervised installatie. Data opslag kun je beperken met de recorder settings.
Ja klopt en ik snap je gedachte. In de toekomst wil ik nog een keer een volledige losse server opzetten met eigen opslag. Ons systeem is in korte tijd echt zo bizar gegroeid dat het een beetje de pi ontstegen is
Van vorig jaar oktober tot nu, dat is nog geen jaar, dat maakt niet veel indruk op me.
Ik heb Linux 'servers' (zo'n pizzadoos van silicongraphics onder andere) zes jaar draaiend gehad met maar één of drie reboots, waarvan een door een stroomstoring.
Een raspberry pi die ik enkele jaren heb gebruikt heeft nooit langer dan 250 dagen gedraaid zonder dat de stekker er uit moest - (maar dat zou heel goed door het achterliggende netwerk veroorzaakt kunnen zijn).
Een domotica controller moet toch echt jarenlang ongestoord zijn werk doen: huisgenoten accepteren niet als 'het soms even niet werkt' tot paps tijd heeft om een stekkertje uit en in te pluggen of erger.
huisgenoten accepteren niet als 'het soms even niet werkt' tot paps tijd heeft om een stekkertje uit en in te pluggen of erger.
Zeker niet als dat storinkje staat tussen hun en een game-ervaring.

Mijn Raspberry Pi draait meestal zo'n half jaar zonder storingen, de Fibaro haalt makkelijk het jaar.
Kun je niet gewoon de watchdog configureren op de Pi? Dan reset hij zichzelf.
Helemaal mee eens, als je wat fanatieker bezig bent kom je snel uit op een NUC. Icm met docker en andere leuke services (selfhosted)
Goedkoper is een tweedehand thinclient zoals een hp t630 te kopen. Goedkoper dan een pi en vele malen betrouwbaarder.
Dat die pi dood ging is natuurlijk gewoon domme pech. Ik heb persoonlijk nooit problemen gehad met 'a-merk' SD-kaartjes. Ik koop ze eigenlijk alleen van Sandisk (256GB). De a-merk SD-kaartjes doen aan wear-leveling, dus dat zal ongetwijfeld een stuk schelen in betrouwbaarheid.

Ik had pasgeleden op andere pi wel een overleden kaartje van m'n Unifi-controller. Dit was echter zo'n 8GB-kaartje die je soms krijgt bij van die Pi-bundels.
Ook dat is geluk hebben.
Ik heb nu al ruim twee jaar HA draaien en na de dood van de derde highend SD kaart (van oa. samsung en sandisk gehad ) heb ik een half jaar geleden alles op een intel nuc met ssd gezet. Qua performance en stabiliteit is dat velen malen beter en met de kosten die ik kwijt was met de SD kaartjes, was het eigenlijk goedkoper geweest om meteen een NUC te kopen. Toegegeven. Ik heb dan ook erg veel apparaten en sensoren gekoppeld. (bijna 200).

Ik had kunnen kiezen om de rpi met een ssd uit te kunnen rusten, maar een intel nuc is in mijn ogen dan een veel betere optie. Geen gedoe met behuizing, RAM is uitbreidbaar en de performance winst, tov van een NUC, is groot. De meegeleverde wallmount maakt het monteren in een meterkast ook eenvoudig.

Daarnaast is de Intel NUC ook merkbaar stabieler. Waarbij ik de raspberry pi met HA soms 1x per maand toch maar eens moest resetten, heb ik dit bij de NUC nog niet hoeven te doen.
(( Samsung vermijd ik altijd zoveel mogelijk. Dat is eigenlijk het enige A-merk waar ik altijd 'pech' mee heb gehad. zowel SSDs als witgoed. Ik begin er niet meer aan ))

Snelheid geloof ik direct, maar stabiliteit? De pi's die ik in gebruik heb en had, zijn bij mij nooit instabiel geweest. Qua hardware bleven ze bleven altijd draaien. De enige stabiliteitsproblemen die ik ooit had, waren doordat ik erg veel in Raspbian aan het prutten was (low-level), maar dan viel eigenlijk alleen het OS om. Niet de pi zelf. Geheugenbeperkingen loop ik (vooralsnog) niet tegen aan (heb een 2GB-pi voor HA draaien)

Ik heb nu 25 fysieke zwave apparaten, 33 zigbee apparaten en nog een aantal apparaten die via netwerkverbindingen lopen in m'n lan, dus lang niet zo veel als jij hebt. Allicht dat ik een keer tegen een grens aan ga lopen als ik nog meer apparaten ga krijgen.

Uit nieuwsgierigheid. Had je wel een 'originele voeding' bij je pi? Een vriend van mij had heel gedoe met z'n pi's (instabiel inderdaad), maar toen hij z'n Ali-express voedingen verving met 'a-merk' voedingen (of in elk geval goede) had hij nooit meer problemen.
Ik weet niet wat voor een SD kaart je gebruikt. Maar ik draai al meer dan 4 jaar Hassio zonder problemen. 18 lampen 12 sensoren met extra apps erop. Nooit problemen gehad. Sinds dit jaar ook geupgrade naar Pi4 4gb met de argon one m.2 SSD case. En ben zeker van mening dat je Hassio voor een gemiddelde huishouden kunt gebruiken > net al velen die een pi4 gebruiken met Hassio.

Meeste klachten komen ook van een oude pi 3 geen 3+ en ook slechte SD kaartjes. Dat lees je al zo op het internet. en forums van Hassio.

Moet ook zegen leuke post heb zojuist ook de ZigBee CC2538 Raspberry Pi-module kunnen bemachtigen.
Ik had een Pi met 512MB RAM. Dat wilde ook echt voor geen meter. Maar goed, dat zegt het artikel zelf ook. Ik heb nu de VM maar op mijn server draaien.
Mijn pi 3b met 2 gig ram was onvoldoende om HA native te draaien. Kwam voornamelijk door geheugen tekort waardoor er veel swapping onstond. Draai nu op pi 4 met 4 Gb ram en ssd gaat prima
100% mee eens. Ook overgestapt naar een NUC en de Pi in de kast gelegt. NUC met Proxmox (of welke hypervisor dan ook natuurlijk) met HA er op werkt 10 keer beter. SSD is sneller en betrouwbaarder dan een MicroSD kaartje.

Ik vind het ook raar dat ze in dit "plus" artikel dan ook zo hangen op een Pi als backbone voor je smarthome, terwijl nagenoeg alle tweakesr inmiddels wel weten dat dat echt niet de fijnste oplossing is.
Draai mijn Pi's van een NFS store via PXE. Dat scheelt een hoop geneuzel met SD kaartjes. Gaan altijd net stuk als het niet uitkomt. Via ZFS snapshot je zo de hele Pi.

Goed, moet je wel een NAS hebben, maar dat is niet onoverkomelijk. :)
Heb inderdaad de zelfde ervaring met RPi. Het gaat altijd een keer kapot. Ben ook overgestapt op een NUC, maar dan met HA in een docker container.
Ik ben uiteindelijk overgeschakeld naar een NUC met HassOS in een VM, en dat bevalt een stuk beter. Gewoon de hele VM laten backuppen
Je kan het ook draaien op een SSD. Een SD kaart is me te onbetrouwbaar. Verder heb je addons om automatisch je HA backups te syncronizeren met Google Drive. Hierbij kan je ook aangeven om een aantal dagen, weken, maanden en jaren als opslag te houden.

Verder voor je NUC zou ik kijken naar de kastjes van Akasa, hiermee kan je ervoor zorgen dat de NUC echt doodstil is (passief gekoeld).
Ik heb nu de eerder genoemde Argon One met SSD uitbreiding. Scheelt enorm in performance en stabilitieti.
Ik heb een case gekocht voor mijn Raspi (DeskPi Pro) waarmee een SSD aan te sluiten is op een van de USB poorten. Totale nieuwkosten groeien al richting NUC gebied dus zou eerder een NUC aanraden maar gok dat veel Tweakers al ergens een Raspi hebben liggen en/of een SSD over dus dan is het wellicht nog een mooie tussenoplossing.
Dat een RPi kapot gaat kan natuurlijk gewoon gebeuren. SD-kaartjes is een ander verhaal. Bij diverse sites kon je kits krijgen incl. SD-kaartje en daar zaten meestal spotgoedkope, waardeloze kaartjes bij. Een A-merk zou het wel een paar jaar moeten uithouden (tenzij je enorm veel data laat verwerken). Beter is om een SSD aan de RPi te hangen.
Ik heb ook op een oudere Pi Homeassistant gedraaid, en inderdaad ook vanwege snelheid in SD problemen overgestapt naar een NUC. Ik draai echter wel bare metal op de NUC, backups van Homeassistant worden door een addon weggeschreven naar een samba share op mijn NAS. Daar worden ze vervolgens weer meegenomen de cloud backup in. Het enige dat ik dan niet heb is een volledige machinebackup, maar daaar kan ik mee leven.

Waarmee virtualiseer jij op de NUC?
Ik heb een nuc met hassos, heerlijk! Dit na rpi en een Ubuntu nuc gehad te hebben.
Ik heb dat ook 1x gehad, maar dat kwam omdat ik echt alles in de log liet wegschrijven en dus eigenlijk een constante data stroom had naar de SD.
Als je dan het stroom van je RPi haalt is je SD corrupt.

Heb nu enkel nog in de log staan wat nieuw is en wat ik tijdelijk wil monitoren.

En met deze settings draai nu al dik 4 jaar zonder issues, en al vaak genoeg het stroom er zo af gehad.
Ik gebruik een rpi 4 (4Gb)met ice tower cooler en een adwits usb 3.0 m.2. Sata case met een goedkope wd kaart en deze is echt retesnel en heb er nog nooit issue’s mee gehad. Is ook echt nog wel betaalbaar. Voor setup kun je eens kijken naar ouder filmpje van explaining computers (zoekterm: explaining computers en ssd). Echt top opstelling voor draaien van bijvoorbeeld home assistant. Inmiddels boot de nieuwe firmware wel van usb, in het filmpje moest je nog een en ander tweaken 😉. Maar als je lid bent van tweakers moet dat laatste geen probleem zijn 😂

[Reactie gewijzigd door N. Steenvoorde op 22 juli 2024 14:48]

Ik heb al heel wat jaartjes ervaring met domotica, voornamelijk Domoticz maar ook Home Assistant. Ik heb Zwave en Zigbee met verschillende controllers en Rpi's. Maar van Openthread Border Router met een npc heb ik nog nooit gehoord. Het wordt tussen neus en lippen door genoemd, maar op het Tweakers Forum kom ik hier niets over tegen. Als ik het goed begrijp is het een mesh-protocol over wifi. Iemand ervaring hiermee? Is het wat?

[Reactie gewijzigd door ZatarraNL op 22 juli 2024 14:48]

Thread is een IPv6-gebaseerd, zelfhelend draadloos mesh-netwerkprotocol over 802.15.4. Niet over wifi dus. Het leuke aan Thread is dat er geen gateway meer nodig is die pakketjes van Thread-apparaten ‘vertaalt’ naar een IP-protocol, maar alleen een border router die zowel een IEEE 802.15.4-radio als een wifi- of ethernetverbinding heeft. Die hoeft louter IPv6-pakketten door te sturen. Elk Thread-apparaat is dus in je netwerk adresseerbaar via een IPv6-adres. Onderaan de homepage van OpenThread vind je een lijst met apparaten die het protocol ondersteunen, onder andere stopcontacten van Eve en verlichting van Nanoleaf. Ik heb zelf nog geen ervaring met Thread in productie, maar het is duidelijk de richting waarin bedrijven zoals Apple en Google gaan. Zo steunt de nieuwe standaard Matter sterk op Thread als onderlaag. Meer over Thread vind je in het Plus-artikel over IP-netwerken in smarthomes en iot.

[Reactie gewijzigd door koenvervloesem op 22 juli 2024 14:48]

Ik krijg er zon jeuk van dat er zo vaak maar een pi aangerukt wordt..
Home Assistant, pi-hole, fileserver.. noem maar op, sommige mensen draaien er wel 5 tegelijk.

Ik zou zeggen kijk eens op het zuinige server topic voor een zuinige, snellere en meer betrouwbare oplossing!
Ik heb bewust mijn pihole op een Pi geinstalleerd terwijl ik een server heb. Als ik bezig ben met klooien wil ik niet dat iemand anders in het huis er last van heeft.
Wat weerhoud je er van om op die server een VM op te starten?
Ik wil mijn testomgeving volledig gescheiden houden. Mijn vriendin werkt veel thuis (losstaand van corona) en een stabiele verbinding is belangrijk voor haar. Ik kan dan niet een host gaan rebooten.
daarmee geef je geen antwoord op de vraag; waarom geen VM of container? Daarvoor hoef je geen host te rebooten. Met een LXD container heb je een shell identiek aan een Linux host. Standaard maakt LXD een apart netwerk aan, dus de host en de container communiceren standaard niet met elkaar.

Nadeel is trouwens wel dat als je de host reboot, de containers ook gereboot worden (even andersom redenerend).
Het is een Windows host (Hyper-V) en die moet regelmatig gereboot worden voor patches.
Ik draai het op 1 pi. Draait best stabiel. Alleen mijn ssd is niet van de beste kwaliteit.
Wil je een voorbeeld geven?
Kan je ook gewoon allemaal op 1 pi draaien. Waarom direct een duurdere server, zeker als je pas er mee aan "het prullen" bent. Dan is een Pi een ideale oplossing.

Het is niet dat Pi-hole / hassio (kan over gediscussieerd worden) / fileserver veel resources vereisen?
Eens, alleen soms wil je gewoon een fysiek machientje hebben. Alles in software is leuk; alleen wordt het soms een beetje een kluwen als je met bridging en andere trucjes netwerkverkeer moet sturen. Dan is een fysiek machientje op een fysiek poortje net iets handiger.
Het is natuurlijk ook een beetje spreiden van risico op die manier.
Stel dat je een NUC hebt waar je alles op draait. Als die stuk gaat ligt gelijk in eens alles plat en heb je gelijk heel veel werk om alles weer aan de praat te krijgen.

Uiteraard hebben je domotica, je pi-hole, enz. enz. allemaal andere taken, maar je wil tin principe wel alles hebben draaien.

Puur anekdotisch:
Ik heb zelf een HA-image op één pi4, en een Unifi controller op een andere pi4. Beide pi's hebben ook een Adguard Home installatie draaien. (als de ene er mee stopt heb ik dus nog wel DNS in m'n netwerk. Ik kan ook relatief simpel de software die op ene draait naar de andere overbrengen.

Mijn persoonlijke ervaring met de betrouwbaarheid van pi's is prima. Ik gebruik alleen A-merk SD-kaartjes (meestal Sandisk) en 'originele' stroom-adapters. Ik heb nooit problemen gehad. (( allicht heb ik domme mazzel gehad natuurlijk ))
Over betrouwbaarheid niks te klagen met PI(4). In combinatie met een USB - SSD draait dat spul al velen jaren 7 x 365 dagen zonder uitval.

Een goede reden voor de PI is om een stukje scheiding en beschikbaarheid te realiseren. 1 voor extern DMZ, 1 voor HA en dan zuinig server voor intern (file server etc). Op vakantie de interne uit en de rest zoomt gewoon door.
Een zeropi of orangepi met allwinner h3 als pihole naast de router trekt max 2W.

Als file server is USB niet geschikt vanwege commit issues dus valt een boel af (<rpi4).
Als video player, retrogaming of data aggregatie is een pi daarentegen wel geschikt.

Wat van belang is voor een pi is een goede voeding, een goede voedingskabel (niet te lang) en een goede SD kaart (samsung/sandisk) of eMMC.

SD-kaart kun je schrijfacties beperken door commit in fstab aan te passen en naar ramdisk te loggen (ramlog), vooral HA wil nog wel eens een berg loggen.

Kijk ook eens naar armbian.com voor alternatieven voor pi, zeer stabiel.

Ivgl tot meeste arm oplossingen (muv marvell), van een celeron J-series is de I/O goed, voor cpu taken/graphics te zwak. Voor re-encoding van media kun je het beste op x86-64 blijven.

Als je daarnaast een flinke HA inrichting hebt dan is een zuinige server voor media/file/ha taken een goed idee.

Maar niet zuiniger of betrouwbaarder.
Home Assistent (en node red en mqtt) draait op mijn synology in Docker. Incl zwave en andere dongles. Eerdere ervaringen op een RPi waren niet goed vanwege stabiliteit en traagheid. (Toen nog rpi 2B o.i.d.). Ook een keer falende sd kaart gehad. De syno regeld backup van de de config en data volumes.

Ik mis in het artikel wel de s/w componenten. Gezien de titel was dat wel een klein beetje op zijn plaats. Voelt meer als een artikel uit het Raspberry Pi blad met niet echt veel diepgang.

[Reactie gewijzigd door Jochem op 22 juli 2024 14:48]

Precies, een promotie artikel.
Ik verwachte dat Domoticz en HomeAssitant tegen elkaar uitgezet werden.
Oei eerst even de laatste alinea nog lezen: t ging hier in t artikel om de hardware, het artikel met de software moet nog komen
Geduld is een goede deugd
De VS situatie wordt helemaal niet gesuggereerd. Ik verwacht ook geen recept voor pannenkoeken.
Hetzelfde hier, beetje teleurgesteld.
Dan zou ik maar niet de update naar DSM7 doen, want dan werken je USB dongels niet meer.
Er zijn wel workarounds om de Z-Wave en Zigbee USB dongels weer aan de praat te krijgen maar dat is verre weg van een ideale oplossing.
goede tip inderdaad. Heb meer problemen gelezen over DSM7.
En problemen zijn ook de reden waarom ik nog wacht met de overstap naar DSM7 op m’n 1821+.
Maar ik heb wel een extra Pi4 besteld om als z-waveJS server te draaien wat nu nog op m’n 1821+ draait, ik verwacht namelijk niet dat Synology het USB beleid gaat terug draaien en uiteindelijk zal je wel over moeten naar DSM7.

[Reactie gewijzigd door Goldwing1973 op 22 juli 2024 14:48]

In mijn geval viel dat gelukkig mee; ik heb onder DSM 7 een Ubuntu VM draaien met daarop een docker container met Home Assistant icm z-wave en zigbee dongels, dat draait zonder problemen.
Nog goedkoper zijn een Sonoff zbbridge en daarnaast een Sonoff Rf bridge, flash er tasmota op en je hebt 2 dedicated bridges die een tientje per stuk kosten en alles kunnen bedienen wat wilt, dat werkt zelfs zonder homeassistant (dmv rules). Ik draai alleen in node-red en ieder device zit in mn homekit dmv homebridge-mqtt, incl. de 5 euro deurbel.
Oke stomme vraag die ik ook kan Googlen: waarin is de rfxcom anders dan die van sonoff?
Rfxcom is een controller die als je de goede hebt gekocht alles op de 433mhz en soms net iets daarboven (somfy protocol) kan ontvangen en verzenden. Daarnaast leest deze doordat hiervan de versleuteling ontbreekt ook makkelijk de temperatuurmeter van de buren uit als die er iets van een temperatuurmeter hebben hangen.. Sonoff was vroeger vooral wifi gestuurd. Inmiddels hebben ze voor vele protocollen een zender of ontvanger. Mooie van sonoff is dat je er ‘makkelijk’ andere firmware op flashed (tasmota, espeasy, esphome, enz). Draai zelf vooral tasmota op mijn sonoff schakelaars voor meer controle. Sonoff heeft overigens ook eigens hubs e.d waarmee je net als een rfxcom allerlei apparatuur kunt aansturen is een kwestie van smaak en geld. Heb zelf al jaren lang een rfxcom en die bevalt me prima. Ook na nu net van domoticz te zijn overgeschakeld op home assistant. Deze laatste is in combinate met tasmota en esphome (esp8266, esp32, rpi, ..) echt een topper aan het worden. Geweldige ondersteuning die bij domoticz mijns inziens beperkter is. Protocollen nu in gebruik, 433mhz (incl somfy), zigbee, zwave in allerlei apparatuur (kaku, ikea, sonoff, lidl, action, marmitek) daarnaast werk ik het liefst met eigen sensoren middels esphome, tasmota op esp32, esp8266, wemos d1 mini’s met dallas sensoren, dht11, dht22, led schermpjes, co2 sensoren, enz. De hobby is het allemaal aan elkaar te laten werken en aan elkaar te ‘klooien’. Suc6 hiermee💪👍

[Reactie gewijzigd door N. Steenvoorde op 22 juli 2024 14:48]

Ja, ik heb inderdaad de rfxcom voor mijn somfy apparaten (en die van de buren) :+
Mooi beschreven, die ESP’s zijn in inderdaad heel erg handig en super goedkoop.
Samen met MQTT ben je heel veelzijdig en kan je er van alles op aansluiten en aansturen, en prima laten communiceren met je domotica applicatie. (Bij mij OpenHAB en Domoticz)
Gelijk een vraag, ik gebruik nu een Pi4B in een Argon One behuizing, met SD kaart.

Welke SSD zou ik hiervoor kunnen gebruiken en is niet al te lomp van formaat (Pi ligt in een vensterbank)?
De goedkoopste mSSD die je kunt vinden.
Je hebt voor 20,- een crucial ssd met 120gb vergeet niet er ook een kabeltje bij te bestellen 😉
Ik heb zo'n SSD en soms kan Domoticz niets wegschijven op de SSD en is een herstart noodzakelijk.
Wellicht is de Argon One M2 uitbreiding interessant. Tezamen met een Samsung 860 evo of een WD Red SA500 (sata)M2.
Dat is zeker een interessante optie, dat oogt namelijk ook wat netter. Thanks!
Anoniem: 1302638 6 september 2021 07:02
Ik gebruik nu twee raspberry pi zero w’s om Bluetooth sensoren uit te lezen. Planten sensors bijvoorbeeld. Het enige dat ze doen is die sensor benaderen en de info via WiFi in een database duwen.
Hier gebruik ik een ESP32 voor, die leest mijn plant sensors uit en stuurt de info door naar HA via de ESPHome integratie. Zo’n ESP32 kost ook maar een tientje ofzo, ideaal spul. Daarnaast heb ik nog een ESP8266 die mijn mechanische ventilatie (WTW) bestuurt: als ik douche standje 3, normaal standje 2 en ‘s nachts standje 1.
Mooi geregeld, maar weet je dat stand 1 normaal gesproken gebruikt wordt voor als er niemand thuis is?
@Bumpy_NL Is dat niet verschillend per WTW? Bij ons staat die op automatisch (o.b.v. CO2) en tenzij ik hem handmatig op 2 of 3 zet blijft die gewoon op 1 staan (2 volw, 3 kids in huis).

Ik ben hier namelijk serieus wel benieuwd naar. Bij ons zit 1 bediening in de woonkamer en 1 in de kamer naast de badkamer. Deze werken alleen niet samen, als ik hem in de woonkamer dus op 3 zet kan ik hem in de slaapkamer van mijn dochter niet terugzetten naar 1. Nu slapen wij zelf op de 2de verdieping, en als die op 3 staat kan je dus 's avonds weer naar beneden om hem omlaag te zetten... ;). Daarom pas ik eigenlijk nooit handmatig het niveau aan.

Nu is het zomer en vraag ik me wel eens af of het überhaupt nut heeft om hem aan te laten. Binnen is het al maanden >23° en staan de ramen standaard open. Maar ook in de winter als alles potdicht zit blijft die gewoon op 1 draaien.
Aansturing op CO2 is mooi, maar als je alleen in de woonkamer meet dan doet dat voor de slaapkamer niets. Die situatie heb ik thuis ook. Geopende ramen schelen natuurlijk heel veel en daarmee is stand 1 mogelijk voldoende. In de winter op 1 lijkt mij niet wenselijk. Om meer inzicht te krijgen zul je moeten meten.
Welke WTW heb je? Die van mij heeft een 0-10v aansturing en met wat soldeerwerk van een vriend, een Wemos D1 Mini Lite en een guide op het forum (https://gathering.tweaker...message/61711690#61711690) heb ik het ook werkend gekregen.
Dat zou best kunnen, goede tip! Wellicht laat ik de WTW dan naar standje 1 springen zodra de device_tracker in HA ziet dat ik niet meer thuis ben (ik regel aanwezigheid in mijn eenpersoonshuishouden via een ping naar mijn iPhone IP, na 5 min geen ping te hebben ontvangen weet HA dat ik niet meer thuis ben) en weer terug naar standje 2 als ik thuis ben.

Moet zeggen dat sinds mijn fan geautomatiseerd is, ik 1 van mijn fysieke irritatiepunten heb weggewerkt: als ik ga douchen vergat ik 9/10 keer de fan op standje 3 aan te zetten. Dat is nu via een Aqara humidity sensor in combinatie met een python hygrostat oplossing (https://github.com/bassch...sistant-generic-hygrostat) niet meer nodig. Gotta love technology!
Interessant! Ik zou ook wel wat plantensensors willen. Heb je hier een tutorial voor gevolgd of zo? Werkelijk geen idee waar ik moet beginnen.
Zie hier: https://lovetechstuff.com...rocontroller-and-esphome/

:)

Het was ook mijn eerste keer ESPHome, gewoon even tutorial volgen en het werkt goed! Laat maar weten als je er met de config van deze site niet uitkomt, dan kan ik mijn eigen config/yaml ook even delen
Leuk, ga ik bekijken! Denk wel dat je moet oppassen met water geven he? Kortsluittechnisch :+
Niet dat ik weet, die sensoren van Aqara / Xiaomi meten ook het waterpercentage en zijn IP5 gecertificeerd, dus inderdaad niet een sloot water erover heen gooien maar van een beetje water gaan ze niet dood (de plant ook niet :+)
Welke plant sensoren heb je?

Op dit item kan niet meer gereageerd worden.