Home Assistant: Open source Python3 home automation - deel 5

[Isane]

Ik lees mijn slimme meter via P1 uit in Home Assistant. Gasverbruik staat in het Energy Dashboard en ik heb mijn vaste gastarief van €1,20729/m³ ingesteld. Dit werkt, inclusief de kostenweergave.

Daarnaast betaal ik echter:

- Vaste leveringskosten gas: €0,22994/dag

- Netbeheerkosten: €0,70833/dag

Ik zou deze kosten ook graag in Home Assistant verwerken, liefst via helpers zodat ik de bedragen later eenvoudig kan aanpassen.

Hoe pakken jullie dit aan? Is het mogelijk om dit netjes in het Energy Dashboard te verwerken?

[ Voor 7% gewijzigd door Isane op 17-10-2026 22:50 ]

[XyRuS]

Ik mag graag Youtube kijken op de computer, maar op de bank hangen en op de televisie afspelen is ook wel eens fijn. Nu kan je casten naar Android TV maar dan opent een video niet in de Youtube app maar in een versimpelde speler.

Omdat ik wel eens wil spelen met vibecoden heb ik Claude er over laten nadenken hoe ik de video wel in de app kan laten spelen.

Claude heeft een chrome extensie gemaakt die de youtube link doorstuurt naar home assistant. Daar draait een automation met een webhook die de url vanuit de extensie weer doorstuurt als deeplink naar entity remote.tv_woonkamer.

Omdat het nu als deeplink via remote.tv_woonkamer naar de televisie wordt gestuurd opent wel de youtube app

Het project heb ik github gezet, en de claude prompts zijn hier te vinden. Alle code en documentatie op github zijn door Claude gemaakt. Dit project is ter lering en vermaak maar ik ben verbaasd wat je in zulke korte tijd kan maken met AI.

[DaRk PoIsOn]

XyRuS schreef op zondag 18 oktober 2026 @ 14:47:
Ik mag graag Youtube kijken op de computer, maar op de bank hangen en op de televisie afspelen is ook wel eens fijn. Nu kan je casten naar Android TV maar dan opent een video niet in de Youtube app maar in een versimpelde speler.

Omdat ik wel eens wil spelen met vibecoden heb ik Claude er over laten nadenken hoe ik de video wel in de app kan laten spelen.

Claude heeft een chrome extensie gemaakt die de youtube link doorstuurt naar home assistant. Daar draait een automation met een webhook die de url vanuit de extensie weer doorstuurt als deeplink naar entity remote.tv_woonkamer.

Omdat het nu als deeplink via remote.tv_woonkamer naar de televisie wordt gestuurd opent wel de youtube app

Het project heb ik github gezet, en de claude prompts zijn hier te vinden. Alle code en documentatie op github zijn door Claude gemaakt. Dit project is ter lering en vermaak maar ik ben verbaasd wat je in zulke korte tijd kan maken met AI.

Ik heb een Salora Android TV.
Als ik in de YouTube app op mijn telefoon een filmpje open en daarna op casten naar de tv druk, dan opend gewoon de YouTube app op de tv bij mij

[omweersbui]

Hallo,

ik heb een vraag die een domme vraag zou moeten zijn maar helaas heb ik het antwoord niet vinden. Ik wil Matter installeren op HA. Daar zijn verschillende kookboeken van te vinden op het internet. Alleen gaat deze allemaal uit van een USB-thread RCP router dongle and HA-OS. Systeem. Helaas heb ik geen van beide. Ik draai HA in docker en heb een ethernet-Thread-RCP(Zonoff Dongle max). Het is me niet gelukt om fatsoenlijke documentatie te vinden hoe ik Matter moet installeren in een Docker omgeving. Mocht je het weten kan je het dan met me delen.

Mijn concrete vraag nu is: Hoe stell ik in dat ik een ethernet based THread RCP border router heb in de openthread docker ?

Het voorbeeld dat openthread geeft in hun documentatie: docker run --name=otbr --detach --network=host --cap-add=NET_ADMIN --device=/dev/ttyACM0 --device=/dev/net/tun --volume=/var/lib/otbr:/data --env-file=otbr-env.list --restart=always openthread/border-router

Dit is vast niet de juiste plek. Maar er is vast iemand die dit weet hier. . Alvast bedankt!

[synoniem]

omweersbui schreef op zondag 18 oktober 2026 @ 18:39:
Hallo,

ik heb een vraag die een domme vraag zou moeten zijn maar helaas heb ik het antwoord niet vinden. Ik wil Matter installeren op HA. Daar zijn verschillende kookboeken van te vinden op het internet. Alleen gaat deze allemaal uit van een USB-thread RCP router dongle and HA-OS. Systeem. Helaas heb ik geen van beide. Ik draai HA in docker en heb een ethernet-Thread-RCP(Zonoff Dongle max). Het is me niet gelukt om fatsoenlijke documentatie te vinden hoe ik Matter moet installeren in een Docker omgeving. Mocht je het weten kan je het dan met me delen.

Mijn concrete vraag nu is: Hoe stell ik in dat ik een ethernet based THread RCP border router heb in de openthread docker ?

Het voorbeeld dat openthread geeft in hun documentatie: docker run --name=otbr --detach --network=host --cap-add=NET_ADMIN --device=/dev/ttyACM0 --device=/dev/net/tun --volume=/var/lib/otbr:/data --env-file=otbr-env.list --restart=always openthread/border-router

Dit is vast niet de juiste plek. Maar er is vast iemand die dit weet hier. . Alvast bedankt!

Ik verwacht eerlijk gezegd dat die ethernet dongle een webinterface heeft die je moet instellen en dat deze "zichzelf" meldt als Thread border router. En/of dan eventueel bij HA op dezelfde manier moet aanmelden als dat je bij een Zigbee ethernet dongle doet.

[Gizz]

@omweersbui ik weet niet of dit direct een antwoord op je vraag is, maar let erop dat je voor matter-over-thread met een eigen thread-borderrouter maar liefst 5 apps/integrations nodig hebt in HA:

1. OpenThread Border Router app
2. OpenThread Border Router integration
3. Thread integration
4. Matter app
5. Matter integration

Nummer 1 én 4 zul jij moeten draaien als losse docker containers. Die andere zijn integrations en kun je direct in HA instellen.

Welk image gebruik je voor de OTBR-app? Wat ik her en der lees is dat deze makkelijker is om met HA samen te laten werken én dat je daar de optie hebt om een netwerk-adres in te stellen voor je dongle: http://ghcr.io/ownbee/hass-otbr-docker

Standaard benader je de dongle via http://dongle-m.local/ als je het ip-adres niet weet. Zie ook Dongle-M first time setup en Connecting to Home Assistant via OTBR App(formerly Add-on) waar ook een handleiding inclusief screenshots staat. Die is welliswaar voor HAOS, maar moet jij goed kunnen volgen als je http://ghcr.io/ownbee/hass-otbr-docker gebruikt.

[ZtaaB]

Ik heb ben op zoek naar een mening/feedback over mijn volgende plan:

Ik heb HA draaien en wil mijn bejaarde Toon vervangen.

Ik verwarm mijn huis met mijn LG airco's die ik heb geintegreerd in HA. De cv draait dus 99.9% van de tijd niet. Alleen op echt koude dagen mag die even meedoen om een defrost op te vangen oid.

Mijn plan is dus om de Toon op zolder (niet goed geisoleerd, niet verwarmd) te hangen en de temperatuur voor verwarmen op 0 graden te zetten.

Ik wil de temperatuursensor van mijn LG airco die in de woonkamer/keuken hangt gebruiken om een shelly plus 1 schakelaar mijn cv als aan/uit te laten schakelen. Dus een virtuele thermostaat aanmaken in HA, temp koppelen met de sensor van de airco en via die gegevens de shelly plus 1 aansturen.

Ik wil de toon aangesloten laten op de opentherm aansluiting zodat ik nog wel makkelijk ketelinstellingen kan checken/wijzigen en brander data etc. kan uitlezen.

Dat de cv die 1 of 2 dagen per jaar dat hij in gebruik is niet echt modulerend stookt is in mijn geval dus geen enkel probleem (en zover ik weet, moduleerd die toch nog wel op de temperatuur van de retourleiding).

Ik denk dat dit wel gaat werken, of mis ik iets?

[Gizz]

@ZtaaB denk dat het van je ketel afhangt of hij het leuk vindt om zowel een OpenTherm-aansluiting als een gesloten kring op zijn aan-uit ingang te hebben.

offtopic:
Je vraagt om meningen/feedback: een gasaansluiting en CV-ketel houden voor jaarlijk 1 of 2 dagen bijstoken lijkt me een extreem efficiente manier om geld over de balk te gooien

[ZtaaB]

Gizz schreef op maandag 19 oktober 2026 @ 12:44:
@ZtaaB denk dat het van je ketel afhangt of hij het leuk vindt om zowel een OpenTherm-aansluiting als een gesloten kring op zijn aan-uit ingang te hebben.

offtopic:
Je vraagt om meningen/feedback: een gasaansluiting en CV-ketel houden voor jaarlijk 1 of 2 dagen bijstoken lijkt me een extreem efficiente manier om geld over de balk te gooien

Ja dat moet ik idd even uitproberen.

offtopic:
eens, maar de boel ombouwen naar volledig elektrisch ook voor sww en koken is mij voor nu een stap te ver

[Septillion]

Isane schreef op zaterdag 17 oktober 2026 @ 22:49:
Hoe pakken jullie dit aan?

Persoonlijk, niet. Want dan zou je imho ook de heffingskorting mee moeten nemen. En dan begin je dus elke dag met een negatief verbruik Gezien je meer heffingskorting krijgt dan je vast recht betaald.

Is het mogelijk om dit netjes in het Energy Dashboard te verwerken?

En nee, daar is dat niet in mee te nemen. Dus als je zoiets wilt zal je gewoon zelf aan de slag moeten gaan en dat op een dashboard tonen.

[ Voor 10% gewijzigd door Septillion op 19-10-2026 13:38 ]

[Kodess]

RobertMe schreef op zaterdag 17 oktober 2026 @ 09:50:
Hmm. Kwam, via Hacker News een GitHub draadje tegen met een report over dat HAOS buiten medeweten van de gebruiker met Have I Been Powned babbeld. Ik zal even geen links posten omdat de reacties bij beiden nogal "controversieel" zijn, wat vast ook is waarom het ineens ver bovenaan op HN stond

Waar het uiteindelijk op neer komt is dat HAOS alles dat gemarkeerd is als wachtwoord / secret (binnen HA en apps?) dus door HIBP heen haalt om evt een waarschuwing te geven dat je een gelekt wachtwoord gebruikt. En dit gebeurt schijnbaar al jaren, maar was niet "zichtbaar" (/geen waarschuwing bij een "gelekt" wachtwoord) door een bug.
Waarbij er twee soorten zorgen zijn, die IMO wel terecht zijn.

Ten eerste adverteert HA zich als volledig lokaal, gericht op privacy, etc. Maar zonder medeweten van de gebruiker (laat staan toestemming van de gebruiker) wordt er dus wel verbinding gelegd met een derde partij. Als in: HAOS verbindt met HIBP. En hierbij worden in principe ook prive-gegevens gedeeld (IP adres). En het geeft mogelijk ook in bepaalde mate inzicht dat op dat IP adres (ergens) HA draait, afhankelijk van de gebruikte user agent. En dat geldt dus voor elk systeem waar HA mee verbindt, maar als je bv een cloud integratie instelt is het "opt-in". Deze wachtwoord check is "opt-out", en bij wijze van niemand weet dat die er in zit.

En ten tweede zijn er twijfels over de veiligheid van HIBP. Wat er gebeurt is dat het wachtwoord lokaal met SHA1 wordt gehasht, en van het resultaat worden de eerste 5 tekens naar HIBP gestuurd. Waarna HIBP alle bekende wachtwoord hashes die met die 5 tekens beginnen retourneert, en HA lokaal kan vergelijken of de hash in die set zit, zo ja is het wachtwoord gelekt. Maar HIBP weet dus wel ongeveer hoeveel unieke wachtwoorden je hebt (op basis van het aantal "prefixes" die je opvraagt). En de wachtwoord database van HIBP zal gevuld zijn op basis van plain text wachtwoorden, die HIBP zelf gehasht heeft. En dus potentieel ook heeft opgeslagen "wachtwoord 'Welkom2026' heeft hash 'abcdefgh...'". Dus als jij vervolgens een "controle" doet met hash prefix 'abcde' kan HIBP potentieel weten dat je alsnog mogelijk 'Welkom2026' als wachtwoord hebt, of een van de andere wachtwoorden waarvan de hash begint met die 5 tekens. Waarmee een mogelijke brute force aanval dus maar honderden, of een paar duizend, wachtwoorden hoeft te proberen, i.p.v. vele miljoenen/miljarden.

Nu ga ik er vanuit dat zowel HA als HIBP de beste intenties hebben en niet uit zijn op misbruik. Maar het zet wel te denken. Ook gezien dus bij HA "that puts local control and privacy first". En ongevraagd met derde partijen communiceren is nu niet echt in het belang van privacy? En er is vast een reden dat wachtwoord managers, die ook vaak HIBP integreren, dit wél als opt-in doen.

Opt-out kan overigens met:

code:

ha security options --pwned=false

En blijkbaar dus zonder optie in de web interface.

https://github.com/home-assistant/supervisor/pull/7382
De functie is vanaf de volgende release opt-in

[Schway]

RobertMe schreef op zaterdag 17 oktober 2026 @ 09:50:
Hmm. Kwam, via Hacker News een GitHub draadje tegen met een report over dat HAOS buiten medeweten van de gebruiker met Have I Been Powned babbeld. Ik zal even geen links posten omdat de reacties bij beiden nogal "controversieel" zijn, wat vast ook is waarom het ineens ver bovenaan op HN stond

Waar het uiteindelijk op neer komt is dat HAOS alles dat gemarkeerd is als wachtwoord / secret (binnen HA en apps?) dus door HIBP heen haalt om evt een waarschuwing te geven dat je een gelekt wachtwoord gebruikt. En dit gebeurt schijnbaar al jaren, maar was niet "zichtbaar" (/geen waarschuwing bij een "gelekt" wachtwoord) door een bug.
Waarbij er twee soorten zorgen zijn, die IMO wel terecht zijn.

Ten eerste adverteert HA zich als volledig lokaal, gericht op privacy, etc. Maar zonder medeweten van de gebruiker (laat staan toestemming van de gebruiker) wordt er dus wel verbinding gelegd met een derde partij. Als in: HAOS verbindt met HIBP. En hierbij worden in principe ook prive-gegevens gedeeld (IP adres). En het geeft mogelijk ook in bepaalde mate inzicht dat op dat IP adres (ergens) HA draait, afhankelijk van de gebruikte user agent. En dat geldt dus voor elk systeem waar HA mee verbindt, maar als je bv een cloud integratie instelt is het "opt-in". Deze wachtwoord check is "opt-out", en bij wijze van niemand weet dat die er in zit.

En ten tweede zijn er twijfels over de veiligheid van HIBP. Wat er gebeurt is dat het wachtwoord lokaal met SHA1 wordt gehasht, en van het resultaat worden de eerste 5 tekens naar HIBP gestuurd. Waarna HIBP alle bekende wachtwoord hashes die met die 5 tekens beginnen retourneert, en HA lokaal kan vergelijken of de hash in die set zit, zo ja is het wachtwoord gelekt. Maar HIBP weet dus wel ongeveer hoeveel unieke wachtwoorden je hebt (op basis van het aantal "prefixes" die je opvraagt). En de wachtwoord database van HIBP zal gevuld zijn op basis van plain text wachtwoorden, die HIBP zelf gehasht heeft. En dus potentieel ook heeft opgeslagen "wachtwoord 'Welkom2026' heeft hash 'abcdefgh...'". Dus als jij vervolgens een "controle" doet met hash prefix 'abcde' kan HIBP potentieel weten dat je alsnog mogelijk 'Welkom2026' als wachtwoord hebt, of een van de andere wachtwoorden waarvan de hash begint met die 5 tekens. Waarmee een mogelijke brute force aanval dus maar honderden, of een paar duizend, wachtwoorden hoeft te proberen, i.p.v. vele miljoenen/miljarden.

Nu ga ik er vanuit dat zowel HA als HIBP de beste intenties hebben en niet uit zijn op misbruik. Maar het zet wel te denken. Ook gezien dus bij HA "that puts local control and privacy first". En ongevraagd met derde partijen communiceren is nu niet echt in het belang van privacy? En er is vast een reden dat wachtwoord managers, die ook vaak HIBP integreren, dit wél als opt-in doen.

Opt-out kan overigens met:

code:

ha security options --pwned=false

En blijkbaar dus zonder optie in de web interface.

HAOS is opensource toch? Kan je niet kijken hoe HA en HIBP samenwerken ipv speculeren?

[RobertMe]

Schway schreef op dinsdag 20 oktober 2026 @ 09:52:
[...]

HAOS is opensource toch? Kan je niet kijken hoe HA en HIBP samenwerken ipv speculeren?

Wat speculeer ik dan? Dat HAOS ongevraagd (/opt-out) met een derde partij communiceert is gewoon een feit. En waarom er twijfels zijn over de veiligheid van HIBP heb ik ook uitgelegd. Waarbij ik ook aangeef dat ik er vanuit ga dat beide partijen geen kwade bedoelingen hebben. Maar dan nog zijn er velen die het not done vinden dat het wachtwoord of een afgeleide daarvan zomaar verstuurd wordt naar "iets"/"iemand" (buiten dan datgene waarvoor je dat wachtwoord hebt ingesteld .

Of jij het vervolgens allemaal wel mee vind vallen of niet mag je prima zelf bepalen. Ik post hier alleen dat er "ophef" over deze feature was. En ik ga er zelf ook vanuit dat het risico van deze feature beperkt is. Maar vind ook dat je hierover geïnformeerd moet zijn, en in principe dus ook middels opt-in, en niet middels opt-out, laat staan via opt-out via een "obscuur" CLI commando (een opt-out in de webinterface kun je "ontdekken" als je rond klikt, een "--pwned=false" CLI flag bij een diep genest commando zul je niet snel ontdekken).

En gezien ze bij HAOS blijkbaar intussen besloten hebben om de default wel naar false aan te passen (zie de comment van @Kodess hierboven) geeft ook wel aan dat ze het achteraf niet heel verstandig vinden om het opt-out te maken.