Raspberry Pi als brein van je smarthome

Deel 3: zelf domoticasoftware koppelen

Node-RED: nodes verbinden in een flow

Uiteraard heb je nog meer van dit soort projecten die een specifiek type smarthomeapparaten met MQTT koppelen, maar we kunnen ze in dit artikel niet allemaal behandelen. Uiteindelijk versturen dan al je apparaten boodschappen naar MQTT-topics en kun je zelf ook je apparaten aansturen door boodschappen naar MQTT-topics te sturen. Maar hoe automatiseer je dat nu? Een handig project daarvoor is Node-RED, dat je ook als Docker-container op je Raspberry Pi kunt draaien. In de documentatie vind je een Docker Compose-bestand, maar het kan al eenvoudiger met:

services:
node-red:
image: nodered/node-red
container_name: node-red
restart: always
volumes:
- ./containers/node-red:/data
- /etc/localtime:/etc/localtime:ro
ports:
- "1880:1880"

Nadat je de container hebt gestart, is de webinterface van Node-RED beschikbaar op http://IP:1880.

Node-RED is een low-codeprogrammeeromgeving waarmee je allerlei api’s en diensten aan elkaar koppelt. Je schrijft geen code, maar verbindt ‘nodes’ in een ‘flow’. In de zijbalk links vind je alle beschikbare nodes, waarvan er standaard al veel zijn.

MQTT-nodes

Zo vind je onder 'network' de node 'mqtt in', waarmee je op een MQTT-topic inschrijft en de binnenkomende boodschappen verwerkt. Als je zo’n node naar je canvas versleept en de eigenschappen ervan bewerkt, klik dan bij 'Server' naast de optie 'Add new mqtt-broker…' op het potlood. Hier vul je de hostname en andere verbindingsparameters van je MQTT-broker in. Zodra de brokerconfiguratie is toegevoegd, kun je in de eigenschappen van de node het topic invullen waarnaar deze node luistert.

Op dezelfde manier kun je een node 'mqtt out' toevoegen, die zijn invoer als boodschap naar een ingesteld MQTT-topic stuurt. Zo kun je ook opdrachten naar smarthomeapparaten sturen via MQTT en zaken automatiseren.

In Node-RED lees je eenvoudig MQTT-boodschappen in.

MQTT-dashboard

Node-RED is ook handig om een eenvoudig dashboard voor je apparaten te maken. Daarvoor moet je eerst de extra node node-red-dashboard installeren vanuit het hamburgermenu en dan 'Manage palette'. Je maakt dan een mqtt in-node aan die naar een topic als 'bt-mqtt-gateway/ruuvitag/slaapkamer/temperature' verwijst, en aan die node koppel je bijvoorbeeld een node 'gauge' uit de collectie 'dashboard'. In de eigenschappen van het metertje voeg je dan een dashboardgroep toe, die verschillende dashboardwidgets groepeert, en een tab.

Je kunt allerlei instellingen van de gaugenode aanpassen, zoals label, eenheden, bereik en kleurgradiënt. Nadat je zo allerlei gauges hebt toegevoegd, klik je op 'Deploy' bovenaan in Node-RED en krijg je je dashboard te zien op http://IP:1880/ui/. De metertjes in het dashboard worden continu bijgewerkt met de nieuwste sensorwaardes die via MQTT worden ontvangen.

Een eenvoudig dashboard voor je MQTT-boodschappen is in Node-RED snel gemaakt.

Conclusie

Door allerlei domoticadiensten in Docker-containers te draaien op een Raspberry Pi, houd je het beheer ervan eenvoudig en flexibel, en zitten ze elkaar niet in de weg. Laat je ze allemaal via MQTT met elkaar communiceren, dan heb je ook één protocol om je apparaten op dezelfde manier aan te spreken. Bovendien hoeven al die diensten niet op dezelfde Raspberry Pi te draaien, zolang ze maar via dezelfde MQTT-broker communiceren.

Voor een dashboard en automatisering moet je dan wel zelf nog al die systemen aan elkaar knopen. Node-RED is daarvoor een krachtige oplossing. Dat is wat meer werk dan bij een geïntegreerd systeem als Home Assistant, maar je hebt wel meer flexibiliteit. In het volgende en laatste artikel van deze reeks gaan we in op de beveiliging van je smarthome.

Reacties (55)

[Koenkk]

Leuk om Zigbee2MQTT in dit artikel terug te zien!

Ik zie echter dat er geschreven wordt over Zigbee2MqttAssistant, dit wordt niet meer onderhouden. In plaats hiervan kan de ingebouwde frontend gebruikt worden: https://www.zigbee2mqtt.io/guide/configuration/frontend.html (deze heeft ook meer functionaliteit en scheelt weer een Docker container )

[Reactie gewijzigd door Koenkk op 22 juli 2024 23:26]

[horstefan]

Geschreven door een echte Tweaker zie ik

"De laatste regel is sinds Mosquitto 2.0 verplicht als je verbindingen zonder gebruikersnaam en wachtwoord wilt toelaten."

Lekker diensten draaien zonder authenticatie!

[wouser]

Snap je kritiek ten aanzien van diensten draaien zonder authenticatie maar aan de andere kant gebruik ik mijn domotica puur binnen mijn LAN. Heb doorgaans overal wel beveiliging op maar hoeft niet perse essentieel te zijn als je je domotica van het internet afschermt

[lenwar]

Als je je domoticasysteem echt honderd procent hebt afgescheiden van de rest van je netwerk, kan dat dan best oké zijn. Echter zodra er ook maar één component is dat met internet verbonden is ('slimme' TV/thermostaat/luchtreiniger/webcam/enz/enz/enz) kan het natuurlijk een mooie steppingstone worden naar de rest van je netwerk.

Ik ben persoonlijk van mening dat nooit een goede reden is om beveiliging 'uit te zetten'. De argumentatie 'laat ze maar zien dat m'n lamp aan of uit is', is in mijn optiek zeker geen goede reden.

[wouser]

Eens! In mijn situatie zit het op een aparte vlan welke geen internet toegang heeft.

Het stepping stone probleem is inderdaad een reëele uitdaging.

[lenwar]

In het verlengde hiervan.
Ik ben dan ook echt HEEL erg tegen al die 'slimme' apparaten die je via internet moet bedienen. Heel erg veel 'slimme' apparaten bedien je altijd via internet. Ook binnen je eigen netwerk. Anekdotisch voorbeeld:
Ik heb zelf twee Dyson luchtreinigers. Die hebben een app waarmee je ze kan programmeren en bedienen. Die werken echter altijd via het internet. De app werkt niet als de Dysons (of m'n telefoon) geen internetverbinding hebben.
Echter. Ik heb in m'n Home Assistant installatie een integratie die het, na (online) authenticatie, wel lokaal doet. De apparaten kunnen het dus wel, maar de bijbehorende app dus niet.

Ditzelfde zie ik bij een vriend van mij met een slimme thermostaat. Hij kan de app alleen gebruiken als de thermostaat verbinding heeft met internet heeft. Compleet idioot.

Er zijn uiteraard gebruiksdoeleinden te bedenken dat je je apparaten 'onderweg' wil kunnen bedienen, en uiteraard zijn er mogelijkheden met VPNs naar huis, maar dat is natuurlijk niet voor iedereen weggelegd. Het feit dat je niet de optie hebt om het alleen lokaal te doen is echt belachelijk in mijn ogen. Zeker met de kennis dat veel van die apparaten niet tot nauwelijks updates krijgen over de jaren heen.

[xbeam]

Voor thuis gebruikers is het al hele uitdaging om een vlan niet via de router op te zetten. Je kan op een een usg/ UDM/ media markt router wel internet blokkeren maar zodra de vlan je router aan raakt ben vatbaar voor slipstreaming en kost het hacker bij een verkeerde klik met je telefoon minder dan 2 minuten om toegang te krijgen tot je ow zo veilig IoT vlan.

https://youtu.be/8hrONVL5Syk

https://samy.pl/slipstream/

https://youtu.be/M-6ppoYDEV4

[Reactie gewijzigd door xbeam op 22 juli 2024 23:26]

[proditaki]

Mja ik doe hetzelfde.
Als iemand inbreekt op je LAN heb je overigens waarschijnlijk grotere problemen dan je domotica systeem.

[Ray_]

Er moet wel wat voer over blijven voor de volgende keer:

In de volgende (en laatste) aflevering gaan we dieper in op de beveiliging van je smarthome.

Al zou het Tweakers sieren na die zin nog even toe te lichten dat authenticatie geen slecht idee is. Kan je er wederom op wijzen dat het volgend artikel hier dieper op in gaat.

Overigens vind ik dit artikel een stuk beter geschreven dan de voorgaande in deze serie met eindelijk (iets) meer diepgang.

[Reactie gewijzigd door Ray_ op 22 juli 2024 23:26]

[horstefan]

Ik verwacht de volgende topics te zien in hoofdstuk beveiliging:
-SSH (met private key zou chique zijn)
-Wireguard VPN
-2 Factor Authentication

De tijd zal het leren.

[Peppershade]

Ik zou eerder een reverse proxy willen zien zoals Traefik of Nginx Proxy Manager, zeker met Traefik kan je een gehele SSO voor je applicaties zetten, dan hoef je ook niet te vertrouwen op de authenticatie van een of andere random Docker image die je op het internet gevonden hebt. Tuurlijk zet je met een VPN niks open, maar dat is niet altijd even praktisch.

[OMEGA_ReD]

Ik ben ook fan van reverse proxy, maar dan wel icm de (gratis) Cloudflare Argo tunnel.

De config is wat complexer maar heeft wel wat voordelen:

• Zorgt er voor dat je IP niet zichtbaar is
• Je heb wat extra bescherming en inzicht in het inkomende verkeer
• Bij een wisselend publiek IP blijft het ook gewoon werken
• Je hoeft geen poorten open te zetten

Mooi filmpje met uitleg hoe het werkt: link

[Reactie gewijzigd door OMEGA_ReD op 22 juli 2024 23:26]

[Peppershade]

Thanks voor de tip, heb nu zelf ook een werkende Cloudflare Argo tunnel, werkt super. Ik had voorheen altijd een Docker image draaien die via de Cloudflare API mijn IP-adres veranderde als ik een nieuw IP kreeg.

[mr.DJ95]

Vergeet ook de dienst van Nabu Casa (Home assistant) niet. Hiervoor verloopt de verbinding via hun en is het niet nodig om verkeer van buiten naar binnen open te zetten.

https://www.nabucasa.com/

[ouhaha]

je mag er zeker:
- officiele oplossing: Home Assistant Cloud (nabu casa)
- HTTPS (SSL) aan toevoegen, eventueel met 2FA en VPN (of duckdns)

[Koffie]

Zou inderdaad een ramp zijn als iemand op MQTT ziet wat er op 433Mhz uit de lucht is gegrepen aan informatie

[lenwar]

Of dat iemand via MQTT een bug in je domotica-systeem activeert en zo een steppingstone in je LAN plaatst. Er is nooit een goede reden om geen beveiliging aan te hebben op wat voor plaats dan ook in je eigen netwerk.

[MichielioZ]

Er is nooit een goede reden om geen beveiliging aan te hebben op wat voor plaats dan ook in je eigen netwerk.

Over het algemeen kost (goede) beveiliging meer moeite en tijd dan geen beveiliging.
Voor een lui persoon is dat een hele goede reden om geen beveiliging te hebben ;-)

[Olaf]

Ik heb daar nog even benadrukt dat het hier puur om een eenvoudig voorbeeld gaat en dat er een artikel komt dat dieper in gaat op de beveiliging. In de praktijk denk ik dat het bij thuissituaties draait om de beveiliging van je lan en als je die niet op orde hebt, heb je wel grotere problemen aan je hoofd.

[mr.DJ95]

Leuke serie om te lezen als HA gebruiker. Heb inmiddels menig (niet) technische vrienden weten te overtuigen en middels deze serie redelijk op weg gekregen.

Met veel diensten en services binnen Docker liep ik tegen het probleem aan het configureren van de IP's. Met name Containers die gebruik maken van autodiscovery hebben baat bij een eigen IP adres Middels MacVlan.

Mocht iemand hiermee aan de gang willen kan ik onderstaande compose adviseren.

version: "3"
services:
Container1:
networks:
dockervlan:
ipv4_address: 192.168.1.10 #check of dit IP adres beschikbaar is in je scope.

networks:
dockervlan:
driver: null
driver_opts:
parent: eno1 #mogelijk ETH0 in jouw situatie
ipam:
config:
- subnet: "192.168.1.0/24"
ip_range: 192.168.1.1/24
gateway: "192.168.1.1"
dockervlan:
driver: macvlan
driver_opts:
parent: eno1 #mogelijk ETH0 in jouw situatie
ipam:
config:
- subnet: "192.168.1.0/24" #check of deze reeks overeenkomt met je eigen subnet
ip_range: 192.168.1.1/24
gateway: "192.168.1.1"

Ik die dat de opmaak net goed meekomt, check even mijn Github met PiHole als voorbeeld:
https://github.com/a3426r...-Docker/blob/main/Pihole1

Ik ben benieuwd wat er besproken gaat worden in het volgende deel omtrent beveiliging.

[Reactie gewijzigd door mr.DJ95 op 22 juli 2024 23:26]

[himlims_]

zou eerder domoticz adviseren; meer vrijheid, aanzienlijk minder resources, vergelijkbaar qua HW support

[Majesty]

Hmm dat zou ik dan toch weer niet doen. Eerder Philips Hue, als ze niet zo technisch zijn. Als ze wel technisch zijn, dan HA met Conbee, dan kom je al een heel eind. Wel afhankelijk van wat de plannen zijn natuurlijk.

[himlims_]

zitten toch op tweakers? dan is domoticz een prima en gebruiksvriendleijk systeem. wat minder laagdrempelig als HA

[Majesty]

Het ging toch om niet technische vrienden, dus niet Tweakers? Denk Domoticz dan al teveel van het goede is.

[UTMachine]

macvlan is een leuke optie in Docker, maar ik doe nu een "extra" Proxmox VM opstarten als ik dit echt nodig heb, waarin dan weer Dockers draait. Ik had toch wat gezeik met het source IP adres als je meerdere IP adressen toevoegt (dan kan ik niet meer zien wie-wat-waar en Linux pakt normaliter het laagste adres lijkt het).

[Majesty]

Niet-technische vrienden weten overtuigen HA te gaan gebruiken? Ik heb veel respect voor je overtuiging skills , dat gaat mij nooit lukken. Loop zelf als wel technisch persoon nog regelmatig te stoeien met Home Assistant, hoewel ik het nog steeds erg leuk vindt om mee te werken.

Ik gebruik overigens zelf de ConbeeII, is nog wat gebruiksvriendelijker dan Zigbee2MQTT imo.

[Reactie gewijzigd door Majesty op 22 juli 2024 23:26]

[PhilipsFan]

Zigbee2MQTT heeft ook een eigen webinterface, die kun je standaard benaderen op <ip van je controller>:8082. Ik heb nog nooit iets anders nodig gehad.

Verder is de inrichting met Docker inderdaad ook hoe ik het heb ingericht. Het is erg handig om de data gescheiden te houden van de software. De data staat in volumes, de software in images. Bij mij staan alle volumes in dezelfde map op de host, zodat ik die ene map in 1x kan backuppen (gebeurt automatisch elke nacht).

Ik ben alleen nog op zoek naar een handige manier om een image te updaten. Nu pleur ik het draaiende image weg via portainer (eerst de container stopzetten) en start ik 'm daarna weer met dezelfde commandline (docker run etc). Maar ik vind dat wat teveel handelingen. In Portainer zou een knopje moeten zitten zodat je met 1 handeling de container kan stoppen, het image updaten en de container weer starten. Misschien kan ik iets maken met docker-compose, maar ik wil het eigenlijk via de GUI kunnen doen.

O en nog een kleinigheidje. Ik gebruik Aqara temperatuur- vocht- en druksensoren. Normaal gaat dat goed, maar die in mijn vriezer houdt er na een tijdje mee op. Hij blijft dan staan op -14 graden en dan komen er geen updates meer. Als ik de sensor weer uit de vriezer haal komen er na een tijdje weer updates binnen, als de sensor ontdooid is. Weet iemand daar iets op? Ik wil graag actuele waarden hebben voor de temperatuur van mijn vriezer. Zou de batterij niet meer goed werken bij -14?

[Reactie gewijzigd door PhilipsFan op 22 juli 2024 23:26]

[PatMan]

Ik ben alleen nog op zoek naar een handige manier om een image te updaten. Nu pleur ik het draaiende image weg via portainer (eerst de container stopzetten) en start ik 'm daarna weer met dezelfde commandline (docker run etc). Maar ik vind dat wat teveel handelingen. In Portainer zou een knopje moeten zitten zodat je met 1 handeling de container kan stoppen, het image updaten en de container weer starten. Misschien kan ik iets maken met docker-compose, maar ik wil het eigenlijk via de GUI kunnen doen.

Probeer de Recreate knop met "Pull latest image" eens

[PhilipsFan]

Dat had ik al eens eerder geprobeerd en leidde toen tot exact dezelfde container, terwijl er wel een nieuwe image bestond. Net nog even weer geprobeerd, nu heeft ie wel een update gedaan.

O en als je dit probeert met de Portainer container, dan gaat het gillend kapot

[PatMan]

Owh ok, misschien een bug van portainer geweest? Iig mooi dat het nu wel goed gaat.

Haha ja klopt, die kun je het beste vanaf de cli bijwerken

[Reactie gewijzigd door PatMan op 22 juli 2024 23:26]

[Gizz]

Zou de batterij niet meer goed werken bij -14?

Bingo

Wat men meestal doet is een klein gaatje boren om een ds18b20 naar binnen te steken. De rest van de elektronica kan dan mooi buiten de vriezer/koelkast blijven. Maar je maakt dan wel je isolatie minder.

[Mic2000]

Kijk, een echt tweakers artikel. Lekker veel praktische informatie

[UTMachine]

Ansich leuk artikel, alleen 1 klein probleemtje met sommige configuratie voorbeelden ... Deze zijn in yaml formaat en de uitlijning is er niet, dus veel mensen gaan v*** dat het niet direct werkt.

[rorie]

Goed artikel deze keer, komt aardig overeen met hoe ik het thuis heb ingericht. Gebruik zelf alleen maar Docker met o.a. Zigbee2mqtt, MQTT, Node-Red en Apache met database voor mijn zelf geschreven front end.

[Legobas]

De LSC spullen van de Action maken gebruik van het TUYA protocol. Het is niet een heel goed idee om dit te gebruiken want het gooit je netwerk open richting een Chinese server....

[TheDutchChief]

Heb het een hele tijd buiten de deur gehouden, nu is er toch een tuya wekker in huis gekomen. hoeft niet zo'n probleem te zijn. Heb een IoT-vlan ingericht waar de devices onderling niet kunnen praten tenzij ik daar nadrukkelijk iets voor geregeld heb. Niet alleen Tuya, maar ook mijn eufy-stofzuiger, petcare kattenluikje en volgende week mijn solaredge staan daar/zet ik daar in. Die willen allemaal naar huis babbelen. Die Solaredge mag straks op één ip/poort met domoticz (in een ander vlan) praten. Draait ook nog een pihole, dus zou ook nog eea dicht kunnen zetten. Ik denk dat ik er dan wel ben toch?

[oef!]

Het meeste was me al bekend maar meer van dit soort artikelen graag. Erg tweakers-waardig.

[plofkip]

De yaml formatting kan wel wat verbetering gebruiken. Helemaal gezien indentation erg belangrijk is.