Home Assistant: Open source Python3 home automation - deel 5

[xzaz]

@JorickL Zoals @krijn1985 zegt; ser2net. De integratie zit gelijk in HA. Ze zijn net overgestapt naar json config dacht ik.

[janvanduschoten]

hemertje schreef op zaterdag 11 april 2026 @ 20:52:
[...]


@janvanduschoten wil je even meelezen

Net even gekeken, ik heb XS01-M rookmelders en die kunnen onderling communiceren, niet met HA. Mijn rookmelders hebben het basisstation nodig om verbinding te maken met internet en de HA integratie.

[Out.of.Control]

Ben sinds kort ook begonnen met HA.  Eerste indruk: wow, wat een mogelijkheden.  Een flink deel wat ik in elkaar heb geknutseld werkt al goed, maar een paar dingen nog niet helemaal.

Wat al wel werkt:

• Ik heb gekozen voor een HA green.  Dat werkt (vanzelfsprekend, zou ik zeggen) als een tierelier.
• Via de P1 meter van HomeWizard en twee Shelly Pro EM1’s meet ik de import/export en de zon-opwek.  Werkt uitstekend.  Het energy dashboard is geweldig!
• Via een Shelly 1PM heb ik een specifieke verbruiker ‘slim’ gemaakt en kan ik ook het verbruik bijhouden.  Werkt ook prima.
• Om wat te knutselen met verlichting en thread heb ik een Ikea Dirigera gekocht (2e handsje uit de buurt, die raak ik voor hetzelfde geld ook wel weer kwijt als er een betere keuze is).
  Reden om voor de Dirigera te kiezen was dat deze zowel Zigbee als Matter/thread ondersteund, terwijl een alternatief (zoals de ZBT-2) maar één van beide doet.  En alternatieven die beide doen, zijn een stuk duurder, zo lijkt het althans.  Mijn zoon had al twee Tradfri (Zigbee) lampen met een losse afstandsbediening, leek me handig om die dan ook te kunnen integreren.
• Verder heb ik een Ikea bewegingssensor (Myggspray), een slimme schakelaar (Grillplats) en een afstandsbediening (Bilresa) en een Kajplats peertje aangeschaft.  Allemaal thread spul.
• De Dirigera is verbonden met HA en staat als preferred network.
• De twee Zigbee lampen heb ik via de Ikea app gekoppeld met de Dirigera en verschenen direct in HA.  Dat werkt prima.  Enig minpuntje is dat de lampen als ‘aan’ zichtbaar blijven als mijn zoon ze met een fysieke schakelaar uitzet.  Andere devices krijgen na een tijdje de status ‘niet beschikbaar’.  Zal wel komen door de zigbee <-> matter vertaling door de Dirigera.  Maar hier valt prima mee te leven.
• De Kajplats lamp (Matter over thread) ook via de Ikea app gekoppeld, maar die verscheen niet in HA.  Daarna verwijderd uit de Ikea app en direct in HA gekoppeld, dat werkt nu prima en stabiel. Zowel aan/uit, helderheid en kleurtemperatuur zijn in te stellen en te automatiseren.
• Ook de Grillplats schakelaar direct in HA gekoppeld en werkt ook prima.  Via de HA app of web-interface kan ik de schakelaar en de lamp schakelen, stroomverbruik zien en via een automation aansturen.
• Via de beta-versie van de Matter server kon ik zonder probleem ook de firmware updaten van meerdere Ikea devices.

Echter, de bewegingssensor en afstandsbediening is een ander verhaal.  Op zich kan ik ze prima in HA koppelen en dan werken ze ook, maar na een paar minuten niet meer.  Als ik dan een knop druk op de afstandsbediening gebeurt er niets.  En even later (soms meer dan 10 minuten) later wordt de actie dan alsnog uitgevoerd.  Lijkt wel of de apparaten die batterijgevoed zijn geen constante verbinding hebben en dan eens in de zoveel tijd wakker worden en dan alsnog hun “bewaarde actie” versturen of zo.  Daar valt natuurlijk niet mee te werken.  Op Reddit en HA-forum zie ik dit ook veel voorbijkomen, dus ik verwacht ook niet dat iemand hier op GoT een oplossing voor heeft. 
Het is me ook niet duidelijk of dit aan HA, de hub of de devices zelf ligt (of een combinatie van). Hoop dat dit met een firmware update of HA update wordt opgelost.
Als zo’n ‘vertraagd’ commando wordt uitgevoerd, dan werkt de AB overigens verder wel eventjes zoals je zou verwachten (een nieuwe druk op de knop wordt direct uitgevoerd). Maar als je ‘m dan een paar minuten niet aanraakt, dan wordt een nieuwe actie niet direct verwerkt en kun je weer 10 minuten wachten totdat hij wakker wordt en de actie bij HA binnenkomt.

Andere optie zou zijn om een andere Thread border router te kopen, maar dan wil ik wel graag zeker weten dat dit goed werkt.  Heeft iemand daar ervaring mee (en dan specifiek de Ikea spullen op batterij)?  De Dirigera raak ik wel weer kwijt en mijn zoon kan zijn Zigbee lampen dan weer met de oude afstandsbediening bedienen.  Nieuw spul dat ik nog koop zal toch thread zijn, dus een nieuwe TBR hoeft niet ook Zigbee te kunnen.

[Septillion]

@JorickL Als je echt de Pi wilt blijven gebruiken is Ser2net inderdaad een optie. Op op de Pi DSMR Reader draaien.

Maar als het ook wat anders mag zijn dan zou je kunnen kijken naar een SlimmeLezer. Of helemaal zelfbouw. Er net nog één in elkaar gezet. Kost je één ESPtje en een weerstand. Meer is er niet nodig

[Septillion]

@Out.of.Control Als je smart bulb echt de stroom eraf gaat halen ga je nooit mooi krijgen.

En ja, batterij devices slapen eigenlijk de hele tijd. Maar die zouden wel gewoon wakker moeten worden van een knop en die gelijk verzenden. Ze luisteren alleen niet constant of er een Thread/Zigbee bericht binnenkomt voor ze.

Maar verder helaas geen idee waar dit probleem zit

[RobertMe]

Septillion schreef op zondag 12 april 2026 @ 11:52:
Of helemaal zelfbouw. Er net nog één in elkaar gezet. Kost je één ESPtje en een weerstand. Meer is er niet nodig

Kabel / draad en een RJ11 stekker zijn ook nodig Of dus een ouderwetse telefoonkabel met RJ11 waar je een kant af knipt.

[ Voor 21% gewijzigd door RobertMe op 12-04-2026 12:18 ]

[Septillion]

@RobertMe Okay okay En een draadje + stekker. Maar dan wel een RJ12 aka 6P6C.

Als je niet de voeding van de meter wilt/kunt gebruiken zou oude telefonie ook kunnen maar let dan wel op dat het de 6P4C is en niet 6P2C.

[ Voor 46% gewijzigd door Septillion op 12-04-2026 12:31 ]

[Dacuuu]

Ik draai al jaren home-assistant, maar het laatste jaar volg ik het allemaal wat minder. Update netjes hoor, en breaking changes los ik ook op. Maar nu heb ik wel 2 vragen die ik anders misschien niet gehad zou hebben

1) Ik heb een zigbee netwerk in huis wat draait op een zzh! CC2652R Multiprotocol RF Stick.
Zigbee2mqtt->Homeasistant. Nu bouwen we een stuk aan ons huis vast, wat achter de gevel zit. Het bereik zal daar niet best worden vermoed is. Hoe zullen jullie zoiets aanpakken, een 2e zigbee netwerk opzetten wat alleen voor de nieuwe aanbouw?

2) ik heb zojuist via hacs, battery_sim geïnstalleerd. En vervolgens Energy consumption (tarif 1), Energy consumption (tarif 2) en Energy production (tarif 1), Energy production (tarif 2) opgegeven. En vervolgens een Marstek Venus E 5.12kWh (2nd Gen) gekozen als battterij. Heb ik dit zo goed gedaan, of moet ik nog meer instellen? Ik wil alvast nu simuleren als ik eventueel volgend jaar een plug-in thuis accu wil aanschaffen. Ik heb zonnepanelen.

[ardvark99]

Yzord schreef op zaterdag 11 april 2026 @ 20:24:
Kan het zijn dat de laatste update van HA problemen opleveren? Mijn HA is na de laatste update constant niet meer te bereiken. Na een reboot doet hij het weer, maar na een tijdje is het weet niet meer bereikbaar. Iemand hier ook last van?

Zoek maar ff terug op mijn posts. Ik draai nu nog steeds op 2026.3.4 omdat bij mij ook na een paar minuten ha niet meer berijkbaar is, memory leak. Bij mij is whisper de schuldige.

[Septillion]

@Dacuuu Als bij die aanbouw gewoon al een net power zigbee device zit die als router fungeert is er denk ik niet zo veel aan de hand. Zigbee netwerk start hier in de kelder van de trapkast en de lampjes achter in de tuin (in een allu behuizing zelfs) doen het prima! Dus ik verwacht niet zo snel problemen eigenlijk.

Maar als je wilt is tweede Z2M instantie mogelijk. Alleen niet 2x op HA OS.

Voor Battery Sim, volgens mij kan die maar één entity aan voor import en één voor export. Maar laadt de UI steeds gewoon blanko entity picker. Dus heb je alleen de laatste ingesteld. Volgens mij moet je dus even template sensoren maken die de tarifs optellen.

[Yzord]

ardvark99 schreef op zondag 12 april 2026 @ 13:46:
[...]

Zoek maar ff terug op mijn posts. Ik draai nu nog steeds op 2026.3.4 omdat bij mij ook na een paar minuten ha niet meer berijkbaar is, memory leak. Bij mij is whisper de schuldige.

Ah, dank je, die heb ik idd draaien 👍

[jbhc]

Weet iemand hoe je een bluetooth proxy via ESPhome werkend krijgt?

Ik heb nu een esp32 geflashed en ik heb hem eindelijk zichtbaar in ESPhome (mDNS moet daar kennelijk voor aan staan in de router (Dat kostte even een uurtje om uit te vogelen)) maar hij is niet zichtbaar bij bluetooth in HA zelf.

Dit is de gebruikte code:

YAML:

esphome:
  name: bluetooth-proxy-schuur
  friendly_name: Bluetooth proxy schuur

esp32:
  board: esp32dev
  framework:
    type: esp-idf

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "R8s3qhfGlMO9GH8p8tzlWmaz3Fhq5ewvKp2Du0k8P24="

ota:
  - platform: esphome
    password: "551bd22d05a386fd1dba8e9baa52113b"

wifi:
  ssid: "Mijn WIFI"
  password: "Mijn WiFi wachtwoord"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Bluetooth-Proxy-Schuur"
    password: "Mijn wachtwoord"

captive_portal:

bluetooth_proxy:

[ Voor 3% gewijzigd door Septillion op 12-04-2026 16:48 . Reden: Denk aan de yaml ]

[peterpijpelink]

jbhc schreef op zondag 12 april 2026 @ 14:17:
Weet iemand hoe je een bluetooth proxy via ESPhome werkend krijgt?

ik heb via chrome browser en dan via deze instructie uitgevoerd. Als je hier bluetooth proxy kiest, flashed dan komt ie ook met de vraag om toe te voegen in HA. En je kan adopteren in ESPHome in HA.

[ Voor 4% gewijzigd door peterpijpelink op 12-04-2026 15:24 ]

[TheFes]

jbhc schreef op zondag 12 april 2026 @ 14:17:
Weet iemand hoe je een bluetooth proxy via ESPhome werkend krijgt?

Ik heb nu een esp32 geflashed en ik heb hem eindelijk zichtbaar in ESPhome (mDNS moet daar kennelijk voor aan staan in de router (Dat kostte even een uurtje om uit te vogelen)) maar hij is niet zichtbaar bij bluetooth in HA zelf.

Dit is de gebruikte code:

code:

esphome:
  name: bluetooth-proxy-schuur
  friendly_name: Bluetooth proxy schuur

esp32:
  board: esp32dev
  framework:
    type: esp-idf

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "R8s3qhfGlMO9GH8p8tzlWmaz3Fhq5ewvKp2Du0k8P24="

ota:
  - platform: esphome
    password: "551bd22d05a386fd1dba8e9baa52113b"

wifi:
  ssid: "Mijn WIFI"
  password: "Mijn WiFi wachtwoord"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Bluetooth-Proxy-Schuur"
    password: "Mijn wachtwoord"

captive_portal:

bluetooth_proxy:

Zie je hem wel in de ESPHome integratie? (Dus dan bedoel ik niet de ESPHome device builder app)

[jbhc]

@TheFes Nee, ik zie hem alleen in de builder inderdaad....

Ik heb hem daar nu toegevoegd. Eens kijken wat er nu gebeurd.

En, hij werkt. Bedankt voor het zetje in de juiste richting.

[ Voor 57% gewijzigd door jbhc op 12-04-2026 18:01 ]

[19roland70]

Ik wil HA supervisor updaten en krijg nu deze melding:

Actie update/install kon niet worden uitgevoerd. Error updating Home Assistant Supervisor: Update of Supervisor failed: failed to register layer: Error processing tar file(exit status 1): archive/tar: invalid tar header

Weet iemand wat hier misgaat?

[dixet]

19roland70 schreef op zondag 12 april 2026 @ 20:29:
Ik wil HA supervisor updaten en krijg nu deze melding:

Actie update/install kon niet worden uitgevoerd. Error updating Home Assistant Supervisor: Update of Supervisor failed: failed to register layer: Error processing tar file(exit status 1): archive/tar: invalid tar header

Weet iemand wat hier misgaat?

Wat voor installatie gebruik je dat je los de supervisor wilt updaten? Als je HAOS draait is de supervisor onderdeel van de OS release. Als je in een container draait heb je geen supervisor.

[TheFes]

dixet schreef op maandag 13 april 2026 @ 08:03:
[...]

Wat voor installatie gebruik je dat je los de supervisor wilt updaten? Als je HAOS draait is de supervisor onderdeel van de OS release. Als je in een container draait heb je geen supervisor.

Nee hoor, supervisor update onafhankelijk van OS. Wel is supervisor de enige die bij default automatisch update (6 uur nadat de update beschikbaar is).

[dixet]

TheFes schreef op maandag 13 april 2026 @ 08:11:
[...]

Nee hoor, supervisor update onafhankelijk van OS. Wel is supervisor de enige die bij default automatisch update (6 uur nadat de update beschikbaar is).

Weer wat geleerd En dat roept weer nieuwe vragen op

Ik zie dat de laatste release van de supervisor versie 2026.04.0 van 4 dagen geleden is. Mijn About pagina zegt dat ik nog op Supervisor 2026.03.3 zit. Dus toch niet helemaal updaten na 6 uur? Of is er bij mij iets mis gegaan? Ik zie in geen van de logs iets staan over supervisor updates.

En als Supervisor automatisch update, maar je hebt automatische updates van HAOS en Core uit staan, loop je dan niet het risico op compatibiliteitsissues tussen die componenten?

[TheFes]

dixet schreef op maandag 13 april 2026 @ 08:31:
[...]

Weer wat geleerd En dat roept weer nieuwe vragen op

Ik zie dat de laatste release van de supervisor versie 2026.04.0 van 4 dagen geleden is. Mijn About pagina zegt dat ik nog op Supervisor 2026.03.3 zit. Dus toch niet helemaal updaten na 6 uur? Of is er bij mij iets mis gegaan? Ik zie in geen van de logs iets staan over supervisor updates.

En als Supervisor automatisch update, maar je hebt automatische updates van HAOS en Core uit staan, loop je dan niet het risico op compatibiliteitsissues tussen die componenten?

Dan lijkt er inderdaad iets mis te gaan. Mijn Supervisor zit netjes op 2026.04.0 en daar heb ik niets voor moeten doen.

HAOS, HA Core en Supervisor zijn 3 aparte onderdelen die los van elkaar staan. HAOS is het OS waar alles op draait, zie het als dat je wel de laatste versie van Photoshop draait, maar dat op Windows 10 doet in plaats van Windows 11. Op zich heeft het OS geen invloed op de werking van de software die er op draait, tenzij je bepaalde drivers ofzo mist die vanuit het OS komen.
De supervisor heeft verder vooral invloed op de add-ons apps, die dus ook losse containers zijn, apart van core en het OS.
Een up to date Supervisor versie zal dus verder niet bijten met een OS of Core versie die achterlopen.

[dr.trimble]

Wij willen onze huidige laadstation voor de EV vervangen door een iets slimmere die we kunnen aansturen via HA. ik had gedacht om een wallbox pulsar plus aan te kopen maar lees nu op een FP-groep dat er veel problemen zijn met deze toestellen. Welk laadstation raden jullie aan? Voorwaarden zijn dat het zowel 1f als 3f kan aangesloten worden, variërende laadsnelheid, compatible met HA. Thx

[Ben(V)]

dixet schreef op maandag 13 april 2026 @ 08:31:
[...]

Weer wat geleerd En dat roept weer nieuwe vragen op

Ik zie dat de laatste release van de supervisor versie 2026.04.0 van 4 dagen geleden is. Mijn About pagina zegt dat ik nog op Supervisor 2026.03.3 zit. Dus toch niet helemaal updaten na 6 uur? Of is er bij mij iets mis gegaan? Ik zie in geen van de logs iets staan over supervisor updates.

En als Supervisor automatisch update, maar je hebt automatische updates van HAOS en Core uit staan, loop je dan niet het risico op compatibiliteitsissues tussen die componenten?

Hier hetzelfde de supervisor ging updaten stopte halverwege en nu zit ik op 2026.03.3 en daar blijft hij op.
De foutmelding was iets van
"Update of Supervisor failed: toomanyrequests: retry-after: 158.011µs, allowed: 44000/minut"
Als ik bij "Update" kijk zegt hij dat er geen nieuwe versie beschikbaar is,
Is het mogelijk hem te forceren naar een nieuwe versie?

[ Voor 11% gewijzigd door Ben(V) op 13-04-2026 09:35 ]

[D4NG3R]

Als ik ff op de container repo kijk zie ik dat 04.0 in 4 dagen tijd maar 13000 keer gedownload is, terwijl 03.3 in 13 dagen tijd meer dan 2 miljoen keer is gedownload.

Ik zit op 03.3 en krijg ook geen 04.0 aangeboden als ik naar updates zoek, er lijkt dus iets niet helemaal lekker te gaan. (HAOS 17.2, Core 2026.4.2)

Edit, yup. 03.3 wordt als laatste stable aangeboden: https://version.home-assistant.io/stable.json

JSON:

{
  "channel": "stable",
  "supervisor": "2026.03.3",
}

[ Voor 22% gewijzigd door D4NG3R op 13-04-2026 09:49 ]

[dixet]

D4NG3R schreef op maandag 13 april 2026 @ 09:46:
Als ik ff op de container repo kijk zie ik dat 04.0 in 4 dagen tijd maar 13000 keer gedownload is, terwijl 03.3 in 13 dagen tijd meer dan 2 miljoen keer is gedownload.

Ik zit op 03.3 en krijg ook geen 04.0 aangeboden als ik naar updates zoek, er lijkt dus iets niet helemaal lekker te gaan. (HAOS 17.2, Core 2026.4.2)

Edit, yup. 03.3 wordt als laatste stable aangeboden: https://version.home-assistant.io/stable.json

JSON:

{
  "channel": "stable",
  "supervisor": "2026.03.3",
}

Als ik de geschiedenis bekijk dan is dit geen rollback, maar is Supervisor 04.0 nog helemaal nooit aangeboden. ik gok dat @TheFes op het bèta kanaal zit...

[TheFes]

dixet schreef op maandag 13 april 2026 @ 11:01:
[...]

Als ik de geschiedenis bekijk dan is dit geen rollback, maar is Supervisor 04.0 nog helemaal nooit aangeboden. ik gok dat @TheFes op het bèta kanaal zit...

Ik zit wel op het beta kanaal, maar de 2024.04.0 release staat op Github wel als latest gemarkeerd, en niet als pre-release, dus dat zou op zich niet uit moeten maken dan.

[HuismAndré]

TheFes schreef op maandag 13 april 2026 @ 11:58:
[...]


Ik zit wel op het beta kanaal, maar de 2024.04.0 release staat op Github wel als latest gemarkeerd, en niet als pre-release, dus dat zou op zich niet uit moeten maken dan.

De een heeft het over stable, de ander over latest. Dat zijn verschillende versies.

[D4NG3R]

TheFes schreef op maandag 13 april 2026 @ 11:58:
[...]


Ik zit wel op het beta kanaal, maar de 2024.04.0 release staat op Github wel als latest gemarkeerd, en niet als pre-release, dus dat zou op zich niet uit moeten maken dan.

Mooi voor latest, maar dat is niet de image welke door het systeem wordt opgepikt.

In het update process wordt de supervisor variabele uit https://version.home-assistant.io/stable.json gepakt.

Bijv.
docker pull ghcr.io/home-assistant/amd64-hassio-supervisor:2026.03.3

Bij beta:
docker pull ghcr.io/home-assistant/amd64-hassio-supervisor:2026.04.0

[ Voor 11% gewijzigd door D4NG3R op 13-04-2026 12:26 ]

[Septillion]

Ja, zo te zien worden er voor supervisor gewoon nooit expliciet beta releases gedaan. Maar gewoon normale version number die eerst naar de dev en beta gebruikt wordt. En later als alles goed blijkt naar stable. Latest is gewoon een label dat Github standaard al aangevinkt heeft als je een nieuwe release maakt. Kan handig zijn maar HA gebruikt het dus niet. Definitieve release of niet wordt bepaald door de versions repository.

[HuismAndré]

Septillion schreef op maandag 13 april 2026 @ 12:52:
Ja, zo te zien worden er voor supervisor gewoon nooit expliciet beta releases gedaan. Maar gewoon normale version number die eerst naar de dev en beta gebruikt wordt. En later als alles goed blijkt naar stable. Latest is gewoon een label dat Github standaard al aangevinkt heeft als je een nieuwe release maakt. Kan handig zijn maar HA gebruikt het dus niet. Definitieve release of niet wordt bepaald door de versions repository.

Hangt er ook vanaf welke repository je gebruikt. In Docker hub krijg je, als je kiest voor stable, de hoofdversies (bijvoorbeeld 2026.4). Kies je voor latest dan krijg je ook de subversies (bijvoorbeeld 2026.4.1). Via Docker is het dus aan te raden de 'stable' te kiezen als je eens per maand updaten wel prima vindt en voor de 'latest' als je een beetje mee wilt lopen met de ontwikkeling gedurende de maand. Geen van de 2 heeft overigens iets te maken met beta (het beta kanaal loopt altijd 1 maand voor volgens mij).

Hoe het werkt kun je hier mooi zien door gebruik te maken van de filter tag: https://hub.docker.com/r/homeassistant/home-assistant/tags

[Ben(V)]

En ineens is de supervisor 2026.04.0 weer beschikbaar en kan ik ernaar updaten vanaf 2026.03.3

[Dacuuu]

Septillion schreef op zondag 12 april 2026 @ 14:01:
@Dacuuu Als bij die aanbouw gewoon al een net power zigbee device zit die als router fungeert is er denk ik niet zo veel aan de hand. Zigbee netwerk start hier in de kelder van de trapkast en de lampjes achter in de tuin (in een allu behuizing zelfs) doen het prima! Dus ik verwacht niet zo snel problemen eigenlijk.

Maar als je wilt is tweede Z2M instantie mogelijk. Alleen niet 2x op HA OS.

Voor Battery Sim, volgens mij kan die maar één entity aan voor import en één voor export. Maar laadt de UI steeds gewoon blanko entity picker. Dus heb je alleen de laatste ingesteld. Volgens mij moet je dus even template sensoren maken die de tarifs optellen.

Betreft zigbee, ga ik eerst kijken hoe het in de praktijk uitpakt. En adh daarvan ga ik verder.

Over de virtuele thuisaccu, moet ik dan de roze of de groene data gebruiken voor de thuis accu parameters?

[Raven]

Gister iets vreemds, eigenlijk, 2 vreemde dingen.

De STOFTMOLN Zigbee-lamp waar ik onder zat ging ineens uit en een paar minuten later (zag ik later pas) de eveneens STOFTMOLN in een andere kamer aan

Voor beide heb ik een automation die triggered op de verandering van status op de input van de erachter geplaatste Shelly 1PM Mini gen4. M.a.w.: Fysieke lampschakelaar omzetten (maakt niet uit welke kant) Zigbee lamp gaat aan of uit, afhankelijk van wat de vorige stand is.

Waar ik geen rekening mee had gehouden was dat het triggeren op verandering van status, niet alleen triggeren op aan->uit en uit->aan betekend, maar ook als de status héél kort onbeschikbaar wordt triggeren de automations.

Bij beide Shelly's was de input ineens en heel kort niet beschikbaar (niet tegelijk, er zat een paar min. tussen) en ik moest 2 keer kijken om de korte onbeschikbaar status te spotten, met de status van de lampen erbij was het wat makkelijker te zien


Na een korte Google zoektocht zag ik dat er al jaren wordt geklaagd over het gebrek aan een vinkje voor "exclude unavailable" bij het triggeren op statusveranderingen.

Maar buiten dat, wat zou een reden kunnen zijn dat HASS over zo'n korte periode een onbeschikbaar geeft? In de logs zie ik niet zo gauw iets terug op de betreffende tijdstippen, zag wel dat HASS behoorlijk wat zit te spammen in het log m.b.t. PTR-lookups. Elk uur binnen 1 minuut iets meer dan 500 lookups, maar die tijdstippen komen niet overeen.

[TheFes]

Raven schreef op maandag 13 april 2026 @ 17:52:
Gister iets vreemds, eigenlijk, 2 vreemde dingen.

De STOFTMOLN Zigbee-lamp waar ik onder zat ging ineens uit en een paar minuten later (zag ik later pas) de eveneens STOFTMOLN in een andere kamer aan

Voor beide heb ik een automation die triggered op de verandering van status op de input van de erachter geplaatste Shelly 1PM Mini gen4. M.a.w.: Fysieke lampschakelaar omzetten (maakt niet uit welke kant) Zigbee lamp gaat aan of uit, afhankelijk van wat de vorige stand is.

Waar ik geen rekening mee had gehouden was dat het triggeren op verandering van status, niet alleen triggeren op aan->uit en uit->aan betekend, maar ook als de status héél kort onbeschikbaar wordt triggeren de automations.

Bij beide Shelly's was de input ineens en heel kort niet beschikbaar (niet tegelijk, er zat een paar min. tussen) en ik moest 2 keer kijken om de korte onbeschikbaar status te spotten, met de status van de lampen erbij was het wat makkelijker te zien
[Afbeelding: klik voor groter]

Na een korte Google zoektocht zag ik dat er al jaren wordt geklaagd over het gebrek aan een vinkje voor "exclude unavailable" bij het triggeren op statusveranderingen.

Maar buiten dat, wat zou een reden kunnen zijn dat HASS over zo'n korte periode een onbeschikbaar geeft? In de logs zie ik niet zo gauw iets terug op de betreffende tijdstippen, zag wel dat HASS behoorlijk wat zit te spammen in het log m.b.t. PTR-lookups. Elk uur binnen 1 minuut iets meer dan 500 lookups, maar die tijdstippen komen niet overeen.

Als je een state trigger gebruikt kun je not_from: unavailable toevoegen om dit te voorkomen

[Raven]

@TheFes

YAML:

not_from:
  - unavailable
  - unknown

bij beide toegevoegd, maar buiten dat er al jaren om een simpel vinkje wordt gevraagd, waar komt die opvallend korte niet beschikbaar vandaan?

[Septillion]

HuismAndré schreef op maandag 13 april 2026 @ 15:12:
[...]

Hangt er ook vanaf welke repository je gebruikt. In Docker hub krijg je, als je kiest voor stable, de hoofdversies (bijvoorbeeld 2026.4). Kies je voor latest dan krijg je ook de subversies (bijvoorbeeld 2026.4.1). Via Docker is het dus aan te raden de 'stable' te kiezen als je eens per maand updaten wel prima vindt en voor de 'latest' als je een beetje mee wilt lopen met de ontwikkeling gedurende de maand. Geen van de 2 heeft overigens iets te maken met beta (het beta kanaal loopt altijd 1 maand voor volgens mij).

Hoe het werkt kun je hier mooi zien door gebruik te maken van de filter tag: https://hub.docker.com/r/homeassistant/home-assistant/tags

Mm, ja, ik had er bij moeten zetten dat ik het voor HA OS bedoelde.

Overigens vind ik het wel heel raar als de minor versies niet onder de stable vallen. Het zijn immers gewoon stable versies. En als je er al een van minder stable vind is het juist de .0. Vandaar dat ik die dan eigenlijk ook altijd oversla...

[Septillion]

@Dacuuu In het roze heb je energy entities, in het groen power entities. Battery sim gebruikt energy entities, de roze dus. Maar dat moet een enkele voor leveren zijn en een enkele voor terugleveren.

[Septillion]

@Raven Ik had ze niet zo zeer als vinkje willen zien, maar gewoon volle support via de GUI voor no_from en not_to....

En wat de reden is, geen idee. Maar ik zou het dan juist eerder buiten HA zoeken. Even netwerk hickup ofzo.

[Raven]

Septillion schreef op maandag 13 april 2026 @ 19:52:
@Raven Ik had ze niet zo zeer als vinkje willen zien, maar gewoon volle support via de GUI voor no_from en not_to....

En wat de reden is, geen idee. Maar ik zou het dan juist eerder buiten HA zoeken. Even netwerk hickup ofzo.

Dat zou helemaal mooi zijn, maar ja, verzoeken daarvoor worden van wat ik zo zag al jaren genegeerd.

Als beide tegelijkertijd hetzelfde probleem hadden zou ik dat ook denken, maar er zat een paar minuten tussen. Alhoewel, wel bij beide zo opvallend kort.

[Dacuuu]

Septillion schreef op maandag 13 april 2026 @ 19:48:
@Dacuuu In het roze heb je energy entities, in het groen power entities. Battery sim gebruikt energy entities, de roze dus. Maar dat moet een enkele voor leveren zijn en een enkele voor terugleveren.

Bedankt. Ik heb met de combine the state of several sensors gedaan, en dan de sum optie. Wist niet eens dat dit allemaal ingebouwd zat in HA

[Pjotter87]

Septillion schreef op woensdag 25 februari 2026 @ 16:53:
[...]

Kan je eens laten zien wat je nu uit deWarmte integratie aan entities hebt?

Sorry van de late reactie. Even druk met andere zaken.

Ik heb even de lijst opgezocht in de config

YAML:

"""Select platform for DeWarmte integration."""
from __future__ import annotations

from dataclasses import dataclass
from typing import Any, cast
from enum import Enum

from homeassistant.components.select import (
    SelectEntity,
    SelectEntityDescription,
)
from homeassistant.config_entries import ConfigEntry
from homeassistant.core import HomeAssistant
from homeassistant.helpers.entity_platform import AddEntitiesCallback
from homeassistant.helpers.update_coordinator import CoordinatorEntity

from . import DeWarmteDataUpdateCoordinator
from .const import DOMAIN
from .api.models.settings import SETTING_GROUPS

class HeatCurveMode(str, Enum):
    """Heat curve mode settings."""
    WEATHER = "weather"
    FIXED = "fixed"

class HeatingKind(str, Enum):
    """Heating kind settings."""
    CUSTOM = "custom"
    FLOOR = "floor"
    RADIATOR = "radiator"
    BOTH = "both"

class HeatingPerformanceMode(str, Enum):
    """Heating performance mode settings."""
    AUTO = "auto"
    POMP_AO_ONLY = "pomp_ao_only"
    POMP_AO_AND_BACKUP = "pomp_ao_and_backup"
    BACKUP_ONLY = "backup_only"

class SoundMode(str, Enum):
    """Sound mode settings."""
    NORMAL = "normal"
    SILENT = "silent"

class PowerLevel(str, Enum):
    """Power level settings."""
    MIN = "min"
    MED = "med"
    MAX = "max"

class ThermostatDelay(str, Enum):
    """Thermostat delay settings."""
    MIN = "min"
    MED = "med"
    MAX = "max"

class BackupHeatingMode(str, Enum):
    """Backup heating mode settings."""
    AUTO = "auto"
    ECO = "eco"
    COMFORT = "comfort"

class CoolingThermostatType(str, Enum):
    """Cooling thermostat type settings."""
    HEATING_ONLY = "heating_only"
    HEATING_AND_COOLING = "heating_and_cooling"

class CoolingControlMode(str, Enum):
    """Cooling control mode settings."""
    THERMOSTAT = "thermostat"
    COOLING_ONLY = "cooling_only"
    HEATING_ONLY = "heating_only"
    FORCED = "forced"

@dataclass(frozen=True)
class DeWarmteSelectEntityDescription(SelectEntityDescription):
    """Class describing DeWarmte select entities."""
    options_enum: type[Enum] | None = None

MODE_SELECTS = {
    "heat_curve_mode": DeWarmteSelectEntityDescription(
        key="heat_curve_mode",
        name="Heat Curve Mode",
        options_enum=HeatCurveMode,
        options=[mode.value for mode in HeatCurveMode],
    ),
    "heating_kind": DeWarmteSelectEntityDescription(
        key="heating_kind",
        name="Heating Kind",
        options_enum=HeatingKind,
        options=[kind.value for kind in HeatingKind],
    ),
    "heating_performance_mode": DeWarmteSelectEntityDescription(
        key="heating_performance_mode",
        name="Heating Performance Mode",
        options_enum=HeatingPerformanceMode,
        options=[mode.value for mode in HeatingPerformanceMode],
    ),
    "sound_mode": DeWarmteSelectEntityDescription(
        key="sound_mode",
        name="Sound Mode",
        options_enum=SoundMode,
        options=[mode.value for mode in SoundMode],
    ),
    "sound_compressor_power": DeWarmteSelectEntityDescription(
        key="sound_compressor_power",
        name="Sound Compressor Power",
        options_enum=PowerLevel,
        options=[level.value for level in PowerLevel],
    ),
    "sound_fan_speed": DeWarmteSelectEntityDescription(
        key="sound_fan_speed",
        name="Sound Fan Speed",
        options_enum=PowerLevel,
        options=[level.value for level in PowerLevel],
    ),
    "advanced_thermostat_delay": DeWarmteSelectEntityDescription(
        key="advanced_thermostat_delay",
        name="Advanced Thermostat Delay",
        options_enum=ThermostatDelay,
        options=[delay.value for delay in ThermostatDelay],
    ),
    "backup_heating_mode": DeWarmteSelectEntityDescription(
        key="backup_heating_mode",
        name="Backup Heating Mode",
        options_enum=BackupHeatingMode,
        options=[mode.value for mode in BackupHeatingMode],
    ),
    "cooling_thermostat_type": DeWarmteSelectEntityDescription(
        key="cooling_thermostat_type",
        name="Cooling Thermostat Type",
        options_enum=CoolingThermostatType,
        options=[type.value for type in CoolingThermostatType],
    ),
    "cooling_control_mode": DeWarmteSelectEntityDescription(
        key="cooling_control_mode",
        name="Cooling Control Mode",
        options_enum=CoolingControlMode,
        options=[mode.value for mode in CoolingControlMode],
    ),
}

async def async_setup_entry(
    hass: HomeAssistant,
    entry: ConfigEntry,
    async_add_entities: AddEntitiesCallback,
) -> None:
    """Set up the DeWarmte select entities."""
    coordinators = hass.data[DOMAIN][entry.entry_id]

    if not isinstance(coordinators, list):
        coordinators = [coordinators]

    for coordinator in coordinators:
        # Only create select entities for AO and MP devices (T devices have no settings)
        if not coordinator.device.product_id.startswith(("AO ", "MP ")):
            continue
            
        # Filter out cooling entities if cooling is not supported
        entities = []
        for description in MODE_SELECTS.values():
            # Skip cooling entities if cooling is not supported
            if description.key in SETTING_GROUPS["cooling"].keys:
                assert coordinator.device is not None, "Coordinator device must not be None"
                if not coordinator.device.supports_cooling:
                    continue
            entities.append(DeWarmteSelectEntity(coordinator, description))

        async_add_entities(entities)

class DeWarmteSelectEntity(CoordinatorEntity[DeWarmteDataUpdateCoordinator], SelectEntity): # type: ignore[override]
    """Representation of a DeWarmte select entity."""

    _attr_has_entity_name = True

    def __init__(
        self,
        coordinator: DeWarmteDataUpdateCoordinator,
        description: DeWarmteSelectEntityDescription,
    ) -> None:
        """Initialize the select entity."""
        super().__init__(coordinator)
        assert coordinator.device is not None, "Coordinator device must not be None"
        assert description.options is not None, "Select entity must have options"
        self.entity_description = description
        self._attr_unique_id = f"{coordinator.device.device_id}_{description.key}"
        self._attr_device_info = coordinator.device_info
        self._attr_options = description.options

    @property
    def dewarmte_description(self) -> DeWarmteSelectEntityDescription:
        """Get the DeWarmte specific entity description."""
        return cast(DeWarmteSelectEntityDescription, self.entity_description)

    @property
    def current_option(self) -> str | None:  # type: ignore[override]
        """Return the current selected option."""
        # Settings are cached in coordinator, read from there
        if not hasattr(self.coordinator, '_cached_settings') or not self.coordinator._cached_settings:
            return None

        settings = self.coordinator._cached_settings
        key = self.dewarmte_description.key

        # All settings are now at the root level
        return getattr(settings, key, None)

    async def async_select_option(self, option: str) -> None:
        """Change the selected option."""
        await self.coordinator.api.async_update_operation_settings(self.coordinator.device, self.dewarmte_description.key, option)
        await self.coordinator.async_request_refresh()

Dan gaat het dus over de optie in regel 68.

[Get!em]

Dacuuu schreef op maandag 13 april 2026 @ 21:36:
[...]

Bedankt. Ik heb met de combine the state of several sensors gedaan, en dan de sum optie. Wist niet eens dat dit allemaal ingebouwd zat in HA

Zet de sim battery NIET in je energy dashboard. Dan krijg je troep.

Gebruik een custom energy flow chart om te zien wat ie doet. Er zijn er genoeg die ook werken met een custom date selector.

Helaas is de populaire Energy-flow plus sinds HA 2026.4 stuk, en de fix komt pas veel later van de maintainer omdat ie er even geen tijd in steekt (en ook geen pull requests invoegt). Er is een manual fix voor, maar die is wat onhandig.

De sim battery maakt trouwens ook een entity aan met een simulated P1/grid energy, omdat ie NOM simuleert en daarmee import en export aanpast. Die moet je dus gebruiken in je custom energy card.

[Get!em]

Nog een pro tip: je kunt prima meerdere naast elkaar draaien om te kijken welke batterijgrootte bij je past.

Met meerdere tabs in een dashboard kun je met de custom energy flow cards dat inzichtelijk maken.

[Dacuuu]

Get!em schreef op maandag 13 april 2026 @ 21:44:
[...]
Zet de sim battery NIET in je energy dashboard. Dan krijg je troep..

Dit heb ik wel gedaan. Bedoel je hiermee dat je je echte gegevens sloopt omdat je een virtuele accu er aan heb toegevoegd? Opzich niet zo'n probleem, ik geef niet zo veel om die data. Ik kijk er wel naar hoor, vooral fijn om te zien hoeveel % eigen opwek ik verbruik op een dag enzo, maar het maakt me niet uit als ik deze data kwijtraak ofzo.

[TheFes]

Raven schreef op maandag 13 april 2026 @ 19:55:
[...]

Dat zou helemaal mooi zijn, maar ja, verzoeken daarvoor worden van wat ik zo zag al jaren genegeerd.

Als beide tegelijkertijd hetzelfde probleem hadden zou ik dat ook denken, maar er zat een paar minuten tussen. Alhoewel, wel bij beide zo opvallend kort.

Ik weet niet of het ooit bij de state trigger komt als GUI optie, maar de nieuwe purpose specific triggers negeren automatisch de changes vanaf unavailable. Dus er wordt wel degelijk iets mee gedaan.

[Get!em]

Dacuuu schreef op maandag 13 april 2026 @ 21:54:
[...]


Dit heb ik wel gedaan. Bedoel je hiermee dat je je echte gegevens sloopt omdat je een virtuele accu er aan heb toegevoegd? Opzich niet zo'n probleem, ik geef niet zo veel om die data. Ik kijk er wel naar hoor, vooral fijn om te zien hoeveel % eigen opwek ik verbruik op een dag enzo, maar het maakt me niet uit als ik deze data kwijtraak ofzo.

Ja die maak je “stuk”.

Bovendien heb je dan geen vergelijkingsmateriaal meer met en zonder batterij.

[Rik.]

Rik. schreef op woensdag 8 april 2026 @ 14:02:
Meer mensen die sinds een paar updates terug last hebben van slechte weergave van dropdowns en datumselecties bij gebruik van de iOS Themes - Dark Mode and Light Mode theme?

[Afbeelding]

En iemand enig idee hoe dit te fixen is?

Niemand die hetzelfde ervaart? Of weet hoe je dit op moet lossen?

[TheFes]

Rik. schreef op dinsdag 14 april 2026 @ 08:12:
[...]

Niemand die hetzelfde ervaart? Of weet hoe je dit op moet lossen?

Er zijn weer wat ccs variables aangepast, dat zal de developer van het theme dus moeten updaten. Het beste is om even op de Github repository te checken of iemand het al gemeld heeft, en zo niet, zelf een issue aan te maken.

[PCan]

Na update naar HA core 2026.4.2 weigerde HA in de Victron BLE integratie de authenticatie sleutels van de Victron Smartsolar charge controller mppt 100/30 en de Victron SmartBatterySense.
Had de sleutels opgeslagen in Excel en kon de juiste sleutels op verzoek dus opnieuw invoeren, maar ook die werden keer op keer geweigerd. Soms werden de sleutels even geaccepteerd, maar na een minuutje of zo weer geweigerd.
Heb met>
"ha core update --version 2026.4.1" (zonder "")
HA core terug gezet naar 2026.4.1 en alles lijkt weer normaal te werken.

[Raven]

@PCan https://github.com/home-assistant/core/issues/168019

---

Weet iemand hoe je ZHA helemaal kan verwijderen? De integratie is weg, de snelkoppeling op config/dashboard niet en HASS vindt het nodig iets te backuppen dat niet bestaat: "No ZHA gateway exists, skipping coordinator backup"

[ Voor 124% gewijzigd door Raven op 14-04-2026 10:38 ]

[Netsrek]

Sinds vorige week ben ik begonnen met HA en daar alle apparatuur aan te koppelen. Ik ben begonnen met mijn P1 monitor uitlezen (draait op RPi). Dat komt prima binnen.

Nu heb ik ook mijn Growatt omvormer middels API geintegreerd, maar de uitlezing van huidig opgewekt vermogen zit een factor 1000 verschil in.
Dus er staat opwekking:

Output power
2,200000 W

Terwijl dit in feite moet zijn

Output power
2200,000 W

Kan ik dit eenvoudig aanpassen met een handmatige multiplier van uitlezeing van die specifieke sensor? Ik ben geen expert, dus nog zoekende.