Home Assistant: Open source Python3 home automation - deel 5

[Gizz]

Rudolfus schreef op zondag 12 juli 2026 @ 11:17:
[...]

Staan identiek bij beide apps.

Maar wát is er dan identiek ingesteld?

Met deze instelling krijg ik notificaties direct binnen op Samsung telefoons (A52, A51):


Daarnaast in de companion app de volgende settings, maar die zijn volgens mij default:


Ter vergelijking: hiernaast heb ik nog een Samsung tablet waarbij de energy-settings nog op optimized staan voor de HA companion app. Die meldt bijvoorbeeld soms pas na een half uur, of als ik het scherm aanzet, dat er wordt aangebeld

In mijn automations gebruik ik voor de notificatie:

YAML:

actions:
  - data:
      message: Er wordt aangebeld!
    action: notify.notify_iedereen

En zodat ik het ook hoor als ik een podcast aan het luisteren ben:

YAML:

  - metadata: {}
    data:
      message: TTS
      data:
        tts_text: Er wordt aangebeld
        ttl: 0
        priority: high
    action: notify.mobile_app_a52_gizz

Dit werkt dus allemaal perfect, op Samsung-spul.

[ Voor 15% gewijzigd door Gizz op 12-07-2026 11:32 ]

[Septillion]

@TheFes Ja, het is allemaal wat nieuw inderdaad. Verschillende opties bij een action is nu nog wel een probleem. En dat is ook niet helemaal weg als er een mobile_app.send_message (of mobile_app.send_notification lijkt me logischer) zou zijn gezien de enorme verschillen tussen Android en iOS.

[fub]

Septillion schreef op zondag 12 juli 2026 @ 10:16:
@fub Je kan de actie dus gewoon los testen. En je kan dus via de automation trace ook zien of de automation getriggerd is geweest. Je uitgeklede variant doet in ieder geval niet meer wat je oorspronkelijk wilde...

Als ik de notificatie los test, dan krijg ik daadwerkelijk de notificatie op mijn telefoon, dat is niet het probleem. Het probleem is dat deze automation niet wordt getriggered. Als ik in het overzicht van automations kijk, dan zie ik ook 'never' staan bij de 'Last Triggered'. Terwijl ik zou verwachten dat de automation elke keer als de temperatuur van het weerstation verandert, deze automation getriggered zou worden.

Het probleem is dus precies dat die automation niet gedraaid wordt, en dat ik niet weet wat ik moet doen om daar voor te zorgen.

[Rudolfus]

Gizz schreef op zondag 12 juli 2026 @ 11:26:
[...]

Dit werkt dus allemaal perfect, op Samsung-spul.

Ik heb de instellingen identiek staan, behalve App icon badges, dat aanpassen helpt ook niet.
Is dit het nadeel van het hebben van een S23 ultra?
Ik ben een soort van blij dat ArthurMorgan ook problemen ondervond.
Ik zal het vanmiddag nog proberen met de S24 (non-ultra) van mijn vrouw, anders weet ik het ook niet meer.
Dan moet ik notificaties maar door Dirigera uit laten sturen met al zijn beperkingen.

[ Voor 8% gewijzigd door Rudolfus op 12-07-2026 12:29 ]

[JukeboxBill]

fub schreef op zondag 12 juli 2026 @ 12:02:
[...]

Als ik de notificatie los test, dan krijg ik daadwerkelijk de notificatie op mijn telefoon, dat is niet het probleem. Het probleem is dat deze automation niet wordt getriggered. Als ik in het overzicht van automations kijk, dan zie ik ook 'never' staan bij de 'Last Triggered'. Terwijl ik zou verwachten dat de automation elke keer als de temperatuur van het weerstation verandert, deze automation getriggered zou worden.

Het probleem is dus precies dat die automation niet gedraaid wordt, en dat ik niet weet wat ik moet doen om daar voor te zorgen.

Probeer het eens op een simpele manier.
Ik doe een dergelijke automatisering met een template sensor die de twee sensors van elkaar aftrekt en iets laat gebeuren als het getal negatief wordt.
Dit heb ik b.v.b. in mijn configuration.yaml staan:

YAML:

  - sensor:
      - name: "T-verschil woonkamer-buiten"
        unique_id: 9999999989
        unit_of_measurement: "°C"
        state: >
          {{ (states('sensor.t_woonkamer') | float - states('sensor.lumi_t_rv_7_temperatuur') | float) | round(1) }}

[ Voor 1% gewijzigd door Septillion op 12-07-2026 20:10 . Reden: Denk aan de 'yaml' bij de code tags aub! Zie topic warning en hoe deze post is aangepast. ]

[ddgcpeters]

Zowel met mij Samsung A52s en nu m'n A57 krijg ik de notificaties ook gewoon binnen. Inderdaad battery save uit.

Op 2 manieren in HA zelfs,

action: notify.send_message

Of

domain: mobile_app
type: notify

[fub]

fub schreef op zondag 12 juli 2026 @ 12:02:
Het probleem is dus precies dat die automation niet gedraaid wordt, en dat ik niet weet wat ik moet doen om daar voor te zorgen.

The plot thickens: als ik niet trigger op een verandering van de temperatuur van het weerstation, maar op een verandering van de temperatuur van de sensor binnen, dan werkt het wel. Blijkbaar is er dus iets speciaals met de REST integratie, of ik heb dat niet goed geconfigureerd ofzo. Ik heb nu dus aanknopingspunten om verder te zoeken.

[Septillion]

@fub Kan je verloop van die rest sensor eens laten zien dan? Dus grafiek en more info dialoog?

Nu is het wel zo dat deze triggers pas net gereleased zijn dus als er nog een bug in zit zou me dat op dit moment niet verbazen

[ Voor 40% gewijzigd door Septillion op 12-07-2026 13:02 ]

[Septillion]

@JukeboxBill Als je het op meerdere plekken gebruikt is dat natuurlijk prima maar voor alleen automation wat overdreven. Dat kan ook direct.

En nog een tip, geef de sensor een availability want dit is vragen om errors in je log als een van de twee sensoren unavailable is. Daarnaast is device class meegeven ook goed idee.

[fub]

Ok, ik denk dat ik het gefixed heb. Ik haalde gewoon de temperatuur uit de JSON response van de REST service, en HA liet ook mooi een grafiekje zien enzo. Maar het type van dat ding bleek "unknown" te zijn, en als ik het wilde converteren naar een float (zodat ik een helper kon maken die het temperatuur-verschil tussen binnen en buiten als waarde had, zoals iemand suggereerde) dan ging dat fout omdat een unknown niet naar een float valt te converteren, blijkbaar.
Dus ik heb het value template van de rest sensor aangepast naar

code:

"{{  value_json.temp | float(0) }}"

en nu is het een float en valt er mee te rekenen!
Volgens mij ga ik er nu uitkomen. Dankjewel voor alle hulp en het meedenken (en/of "rubberducking").

[Tarax]

@BiG-GuY wat me wel verbaasde vandaag was dat mijn dochter de luiken met de originele afstandbediening bediende maar dat de status dan in HA niet aangepast werd. Ik heb haar gezegd dan maar altijd HA te gebruiken (dan kan ik tenminste ook vertrouwen op de weergegeven status, open of dicht).

Maar ik had verwacht dat de status in HA wordt aangepast als je de originele knoppen gebruikt (of is dat een denkfout van mij?)

[RobertMe]

Tarax schreef op zondag 12 juli 2026 @ 17:54:
@BiG-GuY wat me wel verbaasde vandaag was dat mijn dochter de luiken met de originele afstandbediening bediende maar dat de status dan in HA niet aangepast werd. Ik heb haar gezegd dan maar altijd HA te gebruiken (dan kan ik tenminste ook vertrouwen op de weergegeven status, open of dicht).

Maar ik had verwacht dat de status in HA wordt aangepast als je de originele knoppen gebruikt (of is dat een denkfout van mij?)

Somfy IO is wel tweewegs, dus met feedback van het rolluik terug, maar volgens mij had @BiG-GuY dat nog niet aan de praat?
Somfy RTS is sowieso niet tweewegs en at best "gokken" en afluisteren (er wordt op afstandsbediening op omhoog geklikt en X seconden later op stop waarbij die in die X seconden waarschijnlijk Y procent heeft bewogen).

[Tarax]

RobertMe schreef op zondag 12 juli 2026 @ 17:56:
[...]

Somfy IO is wel tweewegs, dus met feedback van het rolluik terug, maar volgens mij had @BiG-GuY dat nog niet aan de praat?
Somfy RTS is sowieso niet tweewegs en at best "gokken" en afluisteren (er wordt op afstandsbediening op omhoog geklikt en X seconden later op stop waarbij die in die X seconden waarschijnlijk Y procent heeft bewogen).

Ah ja, RTS is alleen eenwegs, dat was ik vergeten... En RTS is wat ik heb, geen IO. Bedankt voor de opheldering.

[edwin2021]

Rudolfus schreef op zondag 12 juli 2026 @ 12:04:
[...]

Ik heb de instellingen identiek staan, behalve App icon badges, dat aanpassen helpt ook niet.
Is dit het nadeel van het hebben van een S23 ultra?
Ik ben een soort van blij dat ArthurMorgan ook problemen ondervond.
Ik zal het vanmiddag nog proberen met de S24 (non-ultra) van mijn vrouw, anders weet ik het ook niet meer.
Dan moet ik notificaties maar door Dirigera uit laten sturen met al zijn beperkingen.

Je kunt de notificaties ook via diverse channel sturen. Samsung handelt die channel ieder met aparte instellingen of. Volgens mij is er iets van emergency en die komt altijd binnen en gaat ook altijd af. In samsung ergens (weet echt niet meer waar) zit een optie die je aan kunt zetten en dan ineens kun je bij de app notificaties ook per channel aan en uitzetten.

[Rudolfus]

Ik denk dat je deze bedoelt. Heb ik ook mee gestoeid maar tevergeefs.

[BiG-GuY]

Tarax schreef op zondag 12 juli 2026 @ 17:54:
@BiG-GuY wat me wel verbaasde vandaag was dat mijn dochter de luiken met de originele afstandbediening bediende maar dat de status dan in HA niet aangepast werd. Ik heb haar gezegd dan maar altijd HA te gebruiken (dan kan ik tenminste ook vertrouwen op de weergegeven status, open of dicht).

Maar ik had verwacht dat de status in HA wordt aangepast als je de originele knoppen gebruikt (of is dat een denkfout van mij?)

Hier heb je Two Way (2W) communicatie voor nodig. Voor IO is het 2W protocol nog niet geïmplementeerd. Op dit moment gebruikt mijn Somfy IO Bridge 1W communicatie, het simuleert in feite een fysieke IO Remote die ook via 1W communiceren.

Somfy RTS is sowieso enkel een One Way (1W) communicatie protocol, dus kan nooit de status laten zien. De Somfy RTS Bridge heeft dus enkel fictieve statussen. Persoonlijk gebruik ik de 'My' Mode met in feite 'drie standen'. Heb wel een Retry Weak Signal Commands toegevoegd per apparaat dat je toevoegt, voor als je apparaten hebt die vaker slecht reageren, dan stuurt hij automatisch de commando's vaker met een delay ertussen.

Ben de afgelopen dagen en vandaag druk bezig geweest om 2W werkend te krijgen, maar tot zover nog geen succes. Ik breng later vandaag wel een update uit met wat optimalisaties.

Als je wel een Tahoma in huis hebt, kan die 'afgeluisterd' worden op updates van de positie van de Somfy IO apparaten, dat heb ik zelf wel in gebruik om te kunnen zien wat de status van mijn IO Rolluiken is, maar idealiter kan ik de Tahoma uiteindelijk helemaal weg doen. Dit kan momenteel enkel gebruikt worden als je ook een Tahoma Switch of andere Hub in huis hebt.

Heb zelf overigens Hue Tap Dial switches via Zigbee (Z2M) gekoppeld aan mijn HA en gebruik daarvan twee knoppen per kamer voor het besturen van de gordijnen/rolluiken. Op die manier houdt HA de status bij. De fysieke remotes hebben we puur als back-up en gebruiken we niet actief.

[ Voor 9% gewijzigd door BiG-GuY op 12-07-2026 19:59 ]

[Tarax]

BiG-GuY schreef op zondag 12 juli 2026 @ 19:56:
[...]

Hier heb je Two Way (2W) communicatie voor nodig. Voor IO is het 2W protocol nog niet geïmplementeerd. Op dit moment gebruikt mijn Somfy IO Bridge 1W communicatie, het simuleert in feite een fysieke IO Remote die ook via 1W communiceren.

Somfy RTS is sowieso enkel een One Way (1W) communicatie protocol, dus kan nooit de status laten zien.

Ben de afgelopen dagen en vandaag druk bezig geweest om 2W werkend te krijgen, maar tot zover nog geen succes. Ik breng later vandaag wel een update uit met wat optimalisaties.

Als je wel een Tahoma in huis hebt, kan die 'afgeluisterd' worden op updates van de positie van de Somfy IO apparaten, dat heb ik zelf wel in gebruik om te kunnen zien wat de status van mijn IO Rolluiken is, maar idealiter kan ik de Tahoma uiteindelijk helemaal weg doen. Dit kan momenteel enkel gebruikt worden als je ook een Tahoma Switch of andere Hub in huis hebt.

Heb zelf overigens Hue Tap Dial switches via Zigbee (Z2M) gekoppeld aan mijn HA en gebruik daarvan twee knoppen per kamer voor het besturen van de gordijnen/rolluiken. Op die manier houdt HA de status bij. De fysieke remotes hebben we puur als back-up en gebruiken we niet actief.

Dank voor je reactie. Mijn luiken hebben alleen RTS, dus ik heb helaas niets aan IO. Een Tahoma heb ik ook niet.

Maar ik kan hier verder prima mee leven, het is al veel beter dan naar zolder moeten lopen om die stomme knopjes in te gaan drukken (terwijl ik ze nu in één keer allebei tegelijk open of dicht doe met HA).

Je werk wordt in ieder geval geweldig gewaardeerd!

[BiG-GuY]

Tarax schreef op zondag 12 juli 2026 @ 20:05:
[...]

Dank voor je reactie. Mijn luiken hebben alleen RTS, dus ik heb helaas niets aan IO. Een Tahoma heb ik ook niet.

Maar ik kan hier verder prima mee leven, het is al veel beter dan naar zolder moeten lopen om die stomme knopjes in te gaan drukken (terwijl ik ze nu in één keer allebei tegelijk open of dicht doe met HA).

Je werk wordt in ieder geval geweldig gewaardeerd!

Heb zelf dus wel een Tahoma Switch, maar voor RTS is die vrij nutteloos, ja hij kan centraal commando's naar RTS apparaten sturen, maar de Somfy houdt zelf geen status bij. Dus zodra een knop gedrukt is, gaan de gordijnen daarna altijd naar status Unknown. En de signalen vanuit de Tahoma komen vaak niet aan. Terwijl ik dit nu met deze implementatie een stuk stabieler heb. Zeker met de "dubbele commando's" voor degene die verder weg zijn.

Ook zijn er verschillende beperkingen waar ik tegenaan liep met de lokale API's van de Tahoma Switch, waar ik nu geen last van heb.

[Septillion]

fub schreef op zondag 12 juli 2026 @ 17:30:
Ok, ik denk dat ik het gefixed heb. Ik haalde gewoon de temperatuur uit de JSON response van de REST service, en HA liet ook mooi een grafiekje zien enzo. Maar het type van dat ding bleek "unknown" te zijn, en als ik het wilde converteren naar een float (zodat ik een helper kon maken die het temperatuur-verschil tussen binnen en buiten als waarde had, zoals iemand suggereerde) dan ging dat fout omdat een unknown niet naar een float valt te converteren, blijkbaar.
Dus ik heb het value template van de rest sensor aangepast naar

code:

"{{  value_json.temp | float(0) }}"

en nu is het een float en valt er mee te rekenen!
Volgens mij ga ik er nu uitkomen. Dankjewel voor alle hulp en het meedenken (en/of "rubberducking").

Was de staat echt "unknown"?

Want dan ging er wat anders mis. In HA is elke state, ook temperaturen etc, namelijk een string. Ofwel, je template maakt er qua state dus geen float van. Dus zolang die string maar een getal is (met punt als decimaalteken) en de device class klopt, dan is HA blij.

[Rudolfus]

Workaround gemaakt voor de notificaties met behulp van ADB volgens https://www.reddit.com/r/GalaxyS23/comments/117aoat/notifications_not_working_delayed_notifications/

Nu werkt het wél, totdat ik mijn telefoon reboot. Dan moet ik hem weer aan een pc hangen en met ADB weer forceren. Uiteraard eigenlijk geen optie. Frapant dat de jongens van Ikea hier wel wat op gevonden hebben want voor Dirigera is deze noodgreep niet nodig.

[Tarax]

BiG-GuY schreef op zondag 12 juli 2026 @ 20:09:
[...]

Heb zelf dus wel een Tahoma Switch, maar voor RTS is die vrij nutteloos, ja hij kan centraal commando's naar RTS apparaten sturen, maar de Somfy houdt zelf geen status bij. Dus zodra een knop gedrukt is, gaan de gordijnen daarna altijd naar status Unknown. En de signalen vanuit de Tahoma komen vaak niet aan. Terwijl ik dit nu met deze implementatie een stuk stabieler heb. Zeker met de "dubbele commando's" voor degene die verder weg zijn.

Ook zijn er verschillende beperkingen waar ik tegenaan liep met de lokale API's van de Tahoma Switch, waar ik nu geen last van heb.

Ik ben in ieder geval heel blij met deze LilyGo-oplossing. Het werkt als een trein, het bereik is prima (van meterkast naar zolder in een niet heel oud huis met dikke betonnen vloeren) en het is een stuk goedkoper dan een RfxCom of zo.

Ik ga er wellicht nog wat automations tegenaan gooien en dan vind ik het helemaal oké.

[BiG-GuY]

Heb ondertussen van beide een nieuwe versie uitgebracht en gelijk gesplitst qua Repo. Voor RTS vooral verfijningen. Voor IO veel ontdekt en wat verbeteringen, maar nog geen werkende 2W helaas.

• Somfy IO Bridge
• Somfy RTS Bridge

[Septillion]

@Rudolfus Volgens mij is het dus niet zo zeer dat ze een oplossing gevonden hebben maar dat Samsung ze dus goedgekeurd heeft. Appmakers zijn gewoon afhankelijk van de grillen van Samsung.

[Rudolfus]

Septillion schreef op maandag 13 juli 2026 @ 07:42:
@Rudolfus Volgens mij is het dus niet zo zeer dat ze een oplossing gevonden hebben maar dat Samsung ze dus goedgekeurd heeft. Appmakers zijn gewoon afhankelijk van de grillen van Samsung.

Daar kan ik me inderdaad wat bij voorstellen.

Dan hou ik het wel bij mijn work-around en denk ik volgende keer misschien wel aan een ander merk als deze Samsung eruit gaat.

[Jan Smit]

BiG-GuY schreef op zondag 12 juli 2026 @ 23:51:
Heb ondertussen van beide een nieuwe versie uitgebracht en gelijk gesplitst qua Repo. Voor RTS vooral verfijningen. Voor IO veel ontdekt en wat verbeteringen, maar nog geen werkende 2W helaas.

• Somfy IO Bridge
• Somfy RTS Bridge

Ik gebruik nu een Rfxcomm 433 Mhz (met HA integratie) voor de RTS bediening, van zowel een Somfy zonwering, een screen, maar ook nog een obsolete KaKu en een aantal plisse-gordijnen met Brel motor.
Rfxcomm ondersteunt best wel veel protocollen, maar het device bleek in het verleden niet zo stabiel in HA (na veel geklooi met de USB poorten/passthrough/ser2net lijkt het nu stabiel).

Is het aannemelijk dat het 433Mhz bordje de functionaliteit van een Rfxcomm kan evenaren?

[BiG-GuY]

Jan Smit schreef op maandag 13 juli 2026 @ 08:47:
[...]

Ik gebruik nu een Rfxcomm 433 Mhz (met HA integratie) voor de RTS bediening, van zowel een Somfy zonwering, een screen, maar ook nog een obsolete KaKu en een aantal plisse-gordijnen met Brel motor.
Rfxcomm ondersteunt best wel veel protocollen, maar het device bleek in het verleden niet zo stabiel in HA (na veel geklooi met de USB poorten/passthrough/ser2net lijkt het nu stabiel).

Is het aannemelijk dat het 433Mhz bordje de functionaliteit van een Rfxcomm kan evenaren?

Technisch vast, maar mijn integratie is puur gebaseerd op Somfy RTS, dus praat enkel specifiek de Somfy RTS kanalen die iets afwijken van de normale 433Mhz kanalen.

In de aansturing zal dus iets ingebouwd moeten worden om de andere apparaattypes te ondersteunen op andere frequenties op hetzelfde bordje. Doordat 433Mhz grotendeels niet encrypted is en 1 weg verkeer is, is dat in verhouding makkelijker te maken, maar weet niet of anderen dit al gemaakt hebben voor die bordjes, omdat ik het zelf niet nodig heb voor de andere types.

[fub]

Septillion schreef op zondag 12 juli 2026 @ 20:09:
[...]
Was de staat echt "unknown"?

Ja. Ik had een template sensor gemaakt die als value-template iets had als

code:

{{ sensor.weerstation | typeof }}

om te zien wat dat zou geven, en de waarde van de template-sensor was "unknown".
Dus nu is het een ordentelijke float. Ik heb een helper gemaakt die de twee waarden van elkaar af trekt (buiten vs binnen), en ik heb een toggle gemaakt 'Buiten warmer dan binnen'. Nu heb ik twee automations gemaakt, die ik gewoon elke 2 minuten laat draaien: als de toggle aan is en het verschil is negatief (dus binnen is warmer dan buiten) dan gaat de toggle uit en stuur ik een notificatie naar mijn telefoon dat de ramen open moeten. En de andere checkt of de toggle uit is en dat het verschil positief is (dus buiten warmer dan binnen) dan gaat de toggle aan en stuur ik een notificatie naar mijn telefoon dat de ramen dicht moeten.

Dat lijkt prima te werken!

[JanHenk]

@BiG-GuY Mooi werk! Ik heb zo'n bordje besteld voor een paar tientjes, zou mooi zijn als ik ons knikarmscherm (met Somfy RTS, enige apparaat hier op dat protocol) kan bedienen Die genoemde Rfxcomm was me altijd net wat te duur...

Hoe werken jullie dit soort bordjes weg? Case, voeding, etc.?

[ Voor 3% gewijzigd door JanHenk op 13-07-2026 09:15 ]

[Gizz]

JanHenk schreef op maandag 13 juli 2026 @ 09:12:
Hoe werken jullie dit soort bordjes weg? Case, voeding, etc.?

Snel, maar niet zo mooi: generieke projectdoosjes met daarin een paar gaten geboord voor ventilatie en usb-aansluiting

Mooier: passende behuizing, geprint met 3d-printer. Voor LilyGO TTGO T3 LoRa32 zijn al veel modellen beschikbaar.

[BiG-GuY]

JanHenk schreef op maandag 13 juli 2026 @ 09:12:
@BiG-GuY Mooi werk! Ik heb zo'n bordje besteld voor een paar tientjes, zou mooi zijn als ik ons knikarmscherm (met Somfy RTS, enige apparaat hier op dat protocol) kan bedienen Die genoemde Rfxcomm was me altijd net wat te duur...

Hoe werken jullie dit soort bordjes weg? Case, voeding, etc.?

Heb ze voor nu in de meterkast "hangen" aan de USB kabels. Heb al een 3D geprinte case besteld op Etsy, die moet nog binnenkomen. Heb ook andere USB powered apparaten in de meterkast, dus gewoon een IKEA 3xUSB-A Adapter in gebruik ervoor.

[Tomson7]

Goeiemorgen allemaal,

Ik heb een poging gedaan om de battery sim draaiend te krijgen maar ik kom er niet uit.

Ondanks dat de P1 meter meer export dan import aangeeft, laad de batterij niet op.
Voor zover ik kan zien werkt de sim niet meer met een YAML, dus die delen is lastig. Dit zijn de algemene instellingen:

Hoofdparameters

• Batterijgrootte in kWh* 8,038
• Maximale laadsnelheid in kW* 4
• Maximale ontlaadsnelheid in kW* 4
• Ontlaadefficiëntie of curve (bijv. 0.95 of 0:0.9, 5:0.95)* 0.9
• Laadefficiëntie of curve (bijv. 0.95 of 0:0.9, 5:0.95)* 0.9
• Nominale batterijcycli* 10000
• Capaciteit aan het einde van de levensduur (0 tot 1)* 0,7
• Updatefrequentie in seconden* 59
• Minimaal door gebruiker selecteerbare SOC (0 tot 1)* 0,1
• Solarenergie sensor Energie opgewekt vandaag WQG0BGF00Q
• Nominaal vermogen van de omvormer in kW 3

Wie heeft er een idee (of richting) wat er fout gaat?

[CappieL]

Tomson7 schreef op maandag 13 juli 2026 @ 10:21:
Goeiemorgen allemaal,

Ik heb een poging gedaan om de battery sim draaiend te krijgen maar ik kom er niet uit.

Ondanks dat de P1 meter meer export dan import aangeeft, laad de batterij niet op.
Voor zover ik kan zien werkt de sim niet meer met een YAML, dus die delen is lastig. Dit zijn de algemene instellingen:

Hoofdparameters

• Batterijgrootte in kWh* 8,038
• Maximale laadsnelheid in kW* 4
• Maximale ontlaadsnelheid in kW* 4
• Ontlaadefficiëntie of curve (bijv. 0.95 of 0:0.9, 5:0.95)* 0.9
• Laadefficiëntie of curve (bijv. 0.95 of 0:0.9, 5:0.95)* 0.9
• Nominale batterijcycli* 10000
• Capaciteit aan het einde van de levensduur (0 tot 1)* 0,7
• Updatefrequentie in seconden* 59
• Minimaal door gebruiker selecteerbare SOC (0 tot 1)* 0,1
• Solarenergie sensor Energie opgewekt vandaag WQG0BGF00Q
• Nominaal vermogen van de omvormer in kW 3

Wie heeft er een idee (of richting) wat er fout gaat?

Ik draaide vorig jaar een eerdere versie, die Solarenergie hoefde je destijds niet in te vullen.
Zie de toegevoegde waarde er niet zo van in. Als je die niet invult, doet ie het dan?

Nadat je bovenstaande informatie over de batterij hebt ingevoerd, moet je nog je P1-meter-sensoren ingeven. Heb je dat correct gedaan?

[Septillion]

fub schreef op maandag 13 juli 2026 @ 09:10:
[...]

Ja. Ik had een template sensor gemaakt die als value-template iets had als

code:

{{ sensor.weerstation | typeof }}

om te zien wat dat zou geven, en de waarde van de template-sensor was "unknown".
Dus nu is het een ordentelijke float. Ik heb een helper gemaakt die de twee waarden van elkaar af trekt (buiten vs binnen), en ik heb een toggle gemaakt 'Buiten warmer dan binnen'. Nu heb ik twee automations gemaakt, die ik gewoon elke 2 minuten laat draaien: als de toggle aan is en het verschil is negatief (dus binnen is warmer dan buiten) dan gaat de toggle uit en stuur ik een notificatie naar mijn telefoon dat de ramen open moeten. En de andere checkt of de toggle uit is en dat het verschil positief is (dus buiten warmer dan binnen) dan gaat de toggle aan en stuur ik een notificatie naar mijn telefoon dat de ramen dicht moeten.

Dat lijkt prima te werken!

Dat die template unknown geeft klopt want zo kan je namelijk helemaal niet naar een entity verwijzen. Dus typeof van iets dat niet bestaat is inderdaad 'unknown'.

Zoals gezegd, elke state in HA is een string. Kan je ook zien als je de state correct opvraagt in Settings => Dev tools => Tempaltes

Django/Jinja:

{{ states('sensor.weerstation') |typeof }}
{# of #}
{{ states.sensor.weerstation.state |typeof }}
{# Laatste haalt state direct op maar is in normaal gebruik niet aan
 te raden omdat het bijvoorbeeld tijdens start up errors geeft. #}

Alles bij elkaar heb je nu dus een aardige Rube Goldberg machine gemaakt voor iets dat je dus gewoon direct in een automation trigger kan doen En een automation "gewoon elke 2 minuten laten draaien" is een hele domme manier van automatiseren. Dat is als elke twee minuten naar de voordeur gaan om te kijken of er iemand staat ipv naar de deurbel te luisteren.

Dus ik zou er toch nog eens naar kijken en er van leren. Onder aan de streep is dan wat je hebt namelijk makkelijker en slimmer dan nu

[ Voor 9% gewijzigd door Septillion op 13-07-2026 12:02 ]

[Tomson7]

CappieL schreef op maandag 13 juli 2026 @ 11:54:
[...]

Ik draaide vorig jaar een eerdere versie, die Solarenergie hoefde je destijds niet in te vullen.
Zie de toegevoegde waarde er niet zo van in. Als je die niet invult, doet ie het dan?

Nadat je bovenstaande informatie over de batterij hebt ingevoerd, moet je nog je P1-meter-sensoren ingeven. Heb je dat correct gedaan?

Solarenergie heb ik verwijderd en nog steeds geen verschil. In en export zijn gedefinieerd als de overeenkomstige sensoren van m'n P1 meter.

[Septillion]

@Tomson7 In meeste gevallen kan je de solar parameters leeg laten. Zijn alleen nodig voor batterij systemen die alleen uit PV kunnen laden en niet van het net. En om de sim daarmee te laten werken moet de PV vaker dan de battery sim updaten. Maar voor meeste batterijen dus gewoon leeg laten.

Qua settings, aan de standaard waardes te zien moet je daar altijd een punt als decimaal gebruiken. Dus nu is bijvoorbeeld Batterijgrootte in kWh* 8,038 dus ruim 8 Megawattuur Update op 59 klinkt mij ook raar.

En dan belangrijkste mist nog in je post, de P1 meters. Meeste P1 integraties hebben geen total import en total export sensoren maar tariff 1 en tariff 2. Ofwel, dan moet je aan battery sim wel alle 4 toevoegen (2x import/consumed en 2x export/produced).

[belly89]

Jan Smit schreef op maandag 13 juli 2026 @ 08:47:
[...]


Rfxcomm ondersteunt best wel veel protocollen, maar het device bleek in het verleden niet zo stabiel in HA (na veel geklooi met de USB poorten/passthrough/ser2net lijkt het nu stabiel).

Ik ervaar met mijn Rfxcomm ook instabiliteit. Nog tips waar ik het kan zoeken om dit te verhelpen? Nu werkt USB stick opnieuw aansluiten maar dat is fysiek en niet echt een goeie oplossing natuurlijk

[Ben(V)]

Heb jaren een Rfxcomm in gebruik gehad om klikaanklikuit devices te sturen en temp/vocht sensors uit te lezen via HA op Synology en nooit enige instabiliteit gehad.

Ben inmiddels helemaal over op Zigbee dus de Rfxcomm is uitgefaseerd.

[Gizz]

@belly89 wat bedoel je met instabiel? Dat er wel commando's worden verstuurd maar dat je Somfy-producten niet altijd reageren? Of dat de usb-verbinding tussen de RFXcom en je HA-server echt wegvalt?

Hier al 10+jaar een RFXcom, super stabiel. Aangesloten op een passief usb 2.0 - hubje (zoals eigenlijk altijd aangeraden bij usb-devices met een antenne) via een lange kabel met eerst op een Synology en nu al ruim een jaar op mijn Proxmox-bak. HA als VM met usb-passthrough.

Wat schijnt te helpen voor een betrouwbare werking is zo min mogelijk protocollen aanzetten in de firmware van de RFXcom.

[ Voor 9% gewijzigd door Gizz op 13-07-2026 15:03 ]

[Tomson7]

Septillion schreef op maandag 13 juli 2026 @ 12:19:
@Tomson7 In meeste gevallen kan je de solar parameters leeg laten. Zijn alleen nodig voor batterij systemen die alleen uit PV kunnen laden en niet van het net. En om de sim daarmee te laten werken moet de PV vaker dan de battery sim updaten. Maar voor meeste batterijen dus gewoon leeg laten.

Qua settings, aan de standaard waardes te zien moet je daar altijd een punt als decimaal gebruiken. Dus nu is bijvoorbeeld Batterijgrootte in kWh* 8,038 dus ruim 8 Megawattuur Update op 59 klinkt mij ook raar.

En dan belangrijkste mist nog in je post, de P1 meters. Meeste P1 integraties hebben geen total import en total export sensoren maar tariff 1 en tariff 2. Ofwel, dan moet je aan battery sim wel alle 4 toevoegen (2x import/consumed en 2x export/produced).

Nou schiet mij maar lek, net de accu opnieuw aangemaakt en voilla hij lijkt te werken.

Het decimaalscheidinsteken lijkt wel te kloppen. Als ik 0.8 invul bij efficiëntie krijg ik de melding dat ik een getal <1 in moet vullen. Bij 0,8 vervolgens geen foutmelding. Die 59 seconden is inderdaad raar, zal er wel in gescrold hebben...

De Home wizzard P1 meter heeft ook totale in en export en om het simpel te houden ben ik daar mee begonnen.

[Jan Smit]

belly89 schreef op maandag 13 juli 2026 @ 12:57:
[...]

Ik ervaar met mijn Rfxcomm ook instabiliteit. Nog tips waar ik het kan zoeken om dit te verhelpen? Nu werkt USB stick opnieuw aansluiten maar dat is fysiek en niet echt een goeie oplossing natuurlijk

Ik heb hier uren aan besteed. In eerste instantie werd (door AI) mijn Rpi aangewezen als boosdoener, vanwege instabiliteit op de usb-poort-voeding, met name de blauwe usb3 poorten. Aangeraden wordt een losse usb hub mèt eigen voeding te nemen. Die voeding zou alles oplossen. Maar blijkbaar niet in mijn geval.

Toen heb ik een script gemaakt met elke nacht een reboot. Toen werkte de Rfxcomm wel weer even maar meestal niet 24 uur lang.

Inmiddels zit mijn HA op een Dell mini-pc, proxmox. Ik had daar usb passthrough en kreeg weer dezelfde uitval van de rfxcomm. Toen heb ik een poging gedaan met ser2net op de proxmox host. Dat werkte niet want de ser2net koppeling in HA is buggy.

Daarna heb ik de hele boel gefrustreerd weer gewoon ingeplugd in de zwarte usb2 poorten op de Dell pc en een andere passthrough manier geprobeerd, namelijk niet op device maar op poort (de uitdaging dan is dat je dus niet je usb stekker in een andere poort steekt want dan werkt je passthrough niet meer. ).
Met de laatste manier, en misschien een paar aardstralen die anders lopen en wat magisch feeënstof heb ik geen instabiliteit meer gehad.

Ik gebruik de rfxcomm nog vanwege 3 apparaten, maar ik wil dit graag gaan migreren naar een stabieler esp bordje.
2 van de 3 gebruiken somfy (zonnescherm en screen)
1 van de 3 is van Brel en ik weet niet of dat gaat werken met de Somfy RTS oplossing.

Hopelijk heb je er wat aan, want als het werkt, werkt het (vrij naar Cruyff).

[PCan]

Voor wie het zich afvraagt, de Anker F2000 767 Powerstation is defect en staat sinds 8 Juli ingepakt te wachten in de gang om opgehaald te worden.
Het is beloofd dat deze omgeruild wordt door Anker voor een C2000 gen2.
Daarvoor willen ze eerst het oude toestel hebben, maar ze hebben het nog te druk om die op te halen.
Inmiddels een Victron Phoenix 24V/500W omvormer aangeschaft zodat de primaire batterij met de zonnepanelen weer gebruikt kan worden. Want dit lijkt allemaal erg lang te duren.

[fub]

Septillion schreef op maandag 13 juli 2026 @ 11:58:
Alles bij elkaar heb je nu dus een aardige Rube Goldberg machine gemaakt voor iets dat je dus gewoon direct in een automation trigger kan doen En een automation "gewoon elke 2 minuten laten draaien" is een hele domme manier van automatiseren. Dat is als elke twee minuten naar de voordeur gaan om te kijken of er iemand staat ipv naar de deurbel te luisteren.

Ik heb, voor de grap om het uit te proberen, een automation gemaakt die zou moeten triggeren op een verandering in de temperatuur die vanaf het weerstation komt. Verder geen voorwaardes, gewoon elke verandering zou goed moeten zijn.
En ik zie in mijn dashboard die waarde veranderen, maar de automation wordt niet getriggered. Als ik dezelfde automation maak maar dan met een verandering in binnentemperatuur dan triggert'ie wel. Waarom? Misschien omdat het een REST sensor is en die geen triggers hebben?

Dus om jouw analogie te gebruiken: als de deurbel niet gaat dan kan ik er niet naar luisteren, en dan moet ik maar eens in de zoveel tijd kijken of er iemand staat, ja. Als het niet gaat zoals het moet, dan moet het maar zoals het gaat.

[Septillion]

@fub Zoals ik eerder aan gaf, kijk eens goed naar de implementatie van de weerstation sensor. Deel de yaml voor die rest sensor eens. Verwacht dat er daar iets mis gaat. Misschien een device class of dus een stomme spatie ofzo.

Om dus in de analogie te blijven, als je wel een deurbel hebt maar die gaat niet zou ik tijd stoppen in hem repareren ipv periodiek de deur te controleren

[MikeyMan]

Zijn er hier meer mensen met een shelly wall display icm home assistant? De ui is na een update recent nogal van slag. Geen idee of het aan een shelly of een ha update ligt. Zie er weinig berichten over.

[fub]

Septillion schreef op maandag 13 juli 2026 @ 22:06:
@fub Zoals ik eerder aan gaf, kijk eens goed naar de implementatie van de weerstation sensor. Deel de yaml voor die rest sensor eens. Verwacht dat er daar iets mis gaat. Misschien een device class of dus een stomme spatie ofzo.

Maar de sensor doet het wel, en ik krijg ook een grafiek en de waarde wordt geupdate in mijn dashboard en alles. Ik heb een helper gemaakt die met die waarde rekent. Dus die integratie werkt gewoon, voor alles wat ik kan nagaan en zie.

YAML:

sensor:
  - platform: rest
    name: "Weerstation"
    resource: "[URL]"
    value_template: "{{  value_json.temp | float(0) }}"
    device_class: "temperature"
    scan_interval: 330
    state_class: "measurement"
    unique_id: "weerstation"

Ik heb de URL weggelaten, want daar zit mijn persoonlijke key in. Maar het resultaat van de GET is bijvoorbeeld

code:

{"datum":"13-07-26","tijd":"22:15","temp":24.6}

[Septillion]

@fub Ik mis in je rest sensor config een hele belangrijke key, unit_of_measurement. Zonder dat is het geen geldig temperature entity.

En persoonlijk zou ik verkeerde state afvangen netjes afvangen ipv hem 0 te maken. Zou ik dus iets gebruiken als:

YAML:

sensor:
  - platform: rest
    name: "Weerstation"
    resource: "[URL]"
    value_template: >-
      {% if value_json.temp is defined and value_json.temp |is_number %}
        {{ value_json.temp }}
      {% else %}
        none
      {% endif %}
    device_class: "temperature"
    scan_interval: 330
    state_class: "measurement"
    unique_id: "weerstation"
    unit_of_measurement: "°C"

[fub]

Septillion schreef op maandag 13 juli 2026 @ 22:29:
@fub Ik mis in je rest sensor config een hele belangrijke key, unit_of_measurement. Zonder dat is het geen geldig temperature entity.

Huh, inderdaad, dat fixte het. Ik heb in de documentatie zitten zoeken waar ik had kunnen vinden dat ik die had moeten toevoegen (want die parameter is immers optioneel) maar ik kan dat zo 1-2-3 niet vinden. En je zou ook kunnen denken dat je niet hoeft te weten wat de eenheid is om te zien dat de waarde is veranderd, maar goed.
Dank voor je hulp!

[BarryH]

Septillion schreef op woensdag 8 juli 2026 @ 07:27:
@BarryH Dan zou ik even een toetsenbord en monitor aansluiten. Dan kan je via de CLI de backup terug zetten of de configuration.yaml aanpassen.

@TheFes

Gelukt! Bedankt voor de tips

[TheFes]

fub schreef op maandag 13 juli 2026 @ 23:01:
[...]

Huh, inderdaad, dat fixte het. Ik heb in de documentatie zitten zoeken waar ik had kunnen vinden dat ik die had moeten toevoegen (want die parameter is immers optioneel) maar ik kan dat zo 1-2-3 niet vinden. En je zou ook kunnen denken dat je niet hoeft te weten wat de eenheid is om te zien dat de waarde is veranderd, maar goed.
Dank voor je hulp!

Zonder unit_of_measurement ziet HA het niet als een numerieke waarde, dus werken triggers/conditions die uitgaan van een numerieke waarde niet.

Voor een rest sensor is dat inderdaad een optionele waarde, want je result kan ook best een string zijn (bijvoorbeeld sunny als je rest sensor de huidige weerstatus weergeeft).

[Septillion]

@fub Op de pagina van de device classes staat steeds vermeld wat geldige eenheden zijn voor die classe. Dingen kunnen dus in de basis wel optioneel zijn maar nodig als je iets specifiek wilt bereiken.

En volgens mij heeft een device class zonder correcte eenheid errors in je log.

Maar zou het dus eigenlijk ook een bug willen noemen dat de nieuwe trigger dus voor de selectielijst incorrecte entities (dus hier, zonder geldige eenheid) niet weg laat. Dat zou namelijk een hele goede extra hint zijn dat iets niet klopt.

[edwin2021]

Rudolfus schreef op maandag 13 juli 2026 @ 08:39:
[...]

Daar kan ik me inderdaad wat bij voorstellen.

Dan hou ik het wel bij mijn work-around en denk ik volgende keer misschien wel aan een ander merk als deze Samsung eruit gaat.

Ik heb het op zowel s24 als S25 werkend maar moet even kijken hoe precies. Wat inderdaad wat pielen.

[BiG-GuY]

Rudolfus schreef op maandag 13 juli 2026 @ 08:39:
[...]

Daar kan ik me inderdaad wat bij voorstellen.

Dan hou ik het wel bij mijn work-around en denk ik volgende keer misschien wel aan een ander merk als deze Samsung eruit gaat.

Dit is niet uniek aan Samsung. Het is eerder een Android probleem. Verschillende Chinese merken zijn veel agressiever in applicaties in de achtergrond sluiten. Die negeren ook doodleuk de Battery Unrestricted setting, wat bij Samsung wel gewoon werkt.

Het helpt om Persistent Connection in de Companion App in te stellen/toe te staan. Dan ben je ook niet afhankelijk van Google Firebase, waar vaak de vertraging door komt.

Op mijn Samsung S26U (en voorheen S25+) blijft hij netjes in de achtergrond draaien. Normale HA notificaties kunnen vertraagd aankomen, wanneer het scherm uit is. Maar als je ze een hogere prioriteit meegeeft, komen ze altijd direct aan bij mij. Ook als het scherm uit is.

Heb zelf mijn Unifi deurbel notificaties via HA ingesteld, omdat dit sneller is dan via de originele app. En die zend ik met hoge prioriteit en komen zo altijd direct aan op zowel Samsung als Fairphone toestellen.

YAML:

alias: Notify
action: notify.mobile_app_deni_phone
data:
  message: Someone rang the doorbell!
  data:
    channel: Doorbell
    clickAction: /lovelace/front_door
    image: /api/camera_proxy/camera.front_door
    importance: high
    notification_icon: mdi:doorbell-video
    priority: high
    ttl: 0

[ Voor 13% gewijzigd door BiG-GuY op 14-07-2026 08:24 ]

[belly89]

Jan Smit schreef op maandag 13 juli 2026 @ 14:14:
[...]

Ik heb hier uren aan besteed. In eerste instantie werd (door AI) mijn Rpi aangewezen als boosdoener, vanwege instabiliteit op de usb-poort-voeding, met name de blauwe usb3 poorten. Aangeraden wordt een losse usb hub mèt eigen voeding te nemen. Die voeding zou alles oplossen. Maar blijkbaar niet in mijn geval.

Toen heb ik een script gemaakt met elke nacht een reboot. Toen werkte de Rfxcomm wel weer even maar meestal niet 24 uur lang.

Inmiddels zit mijn HA op een Dell mini-pc, proxmox. Ik had daar usb passthrough en kreeg weer dezelfde uitval van de rfxcomm. Toen heb ik een poging gedaan met ser2net op de proxmox host. Dat werkte niet want de ser2net koppeling in HA is buggy.

Daarna heb ik de hele boel gefrustreerd weer gewoon ingeplugd in de zwarte usb2 poorten op de Dell pc en een andere passthrough manier geprobeerd, namelijk niet op device maar op poort (de uitdaging dan is dat je dus niet je usb stekker in een andere poort steekt want dan werkt je passthrough niet meer. ).
Met de laatste manier, en misschien een paar aardstralen die anders lopen en wat magisch feeënstof heb ik geen instabiliteit meer gehad.

Ik gebruik de rfxcomm nog vanwege 3 apparaten, maar ik wil dit graag gaan migreren naar een stabieler esp bordje.
2 van de 3 gebruiken somfy (zonnescherm en screen)
1 van de 3 is van Brel en ik weet niet of dat gaat werken met de Somfy RTS oplossing.

Hopelijk heb je er wat aan, want als het werkt, werkt het (vrij naar Cruyff).

Bedankt voor je reactie. Geen eenduidige oplossing helaas (was ik al bang voor. Ga maar eens op onderzoek uit wat voor mij werkt. Misschien een andere USB ingang of een langere/andere verlengkabel

Gizz schreef op maandag 13 juli 2026 @ 13:08:
@belly89 wat bedoel je met instabiel? Dat er wel commando's worden verstuurd maar dat je Somfy-producten niet altijd reageren? Of dat de usb-verbinding tussen de RFXcom en je HA-server echt wegvalt?

Hier al 10+jaar een RFXcom, super stabiel. Aangesloten op een passief usb 2.0 - hubje (zoals eigenlijk altijd aangeraden bij usb-devices met een antenne) via een lange kabel met eerst op een Synology en nu al ruim een jaar op mijn Proxmox-bak. HA als VM met usb-passthrough.

Wat schijnt te helpen voor een betrouwbare werking is zo min mogelijk protocollen aanzetten in de firmware van de RFXcom.

De USB verbinding lijkt weg te vallen. de lampjes op de RFXcom reageren niet meer. Als ik de USB eruit/erin doe werkt het daarna vaak wel weer even. Qua protocollen heb ik alleen ac & arc aanstaan. Ik zal eens een andere USB ingang of een langere/andere verlengkabel proberen!

[Ben(V)]

@belly89

Klinkt alsof je bios in een powersave mode geconfigureerd is en de usb poort in "sleep mode" zet als hij een tijdje niet gebruikt wordt en dat de Rfxcom hem er niet uit die "sleep mode" krijgt.

[ Voor 3% gewijzigd door Ben(V) op 14-07-2026 11:59 ]

[Get!em]

Met de laatste update is de "condition" voor datetime stukgemaakt voor mij. Deze nam altijd ook de datum mee, maar na de laatste homeassistant update, doet hij alleen wat met de tijd.

Ik heb een helper die een datetime heeft. Die staat 7 dagen in de toekomst ingepland na een bepaalde actie.

Ik wil in een andere automation om 9u elke ochtend testen of deze helper in het verleden ligt. Zo ja, dan gaat de automatisering verder.

Hoe schrijf ik die conditie nu?

Ik wil bewust om 9 uur testen, zodat, mocht de helper niet verandert zijn, de volgende dag de automation weer de acties uitvoert.


Edit... gevonden, dit werkt.

YAML:

condition: template
value_template: >
  {{ states('input_datetime.mijn_helper') | as_datetime
  | as_local <= now() }}

[ Voor 16% gewijzigd door Get!em op 14-07-2026 10:22 ]

[TheFes]

Get!em schreef op dinsdag 14 juli 2026 @ 09:44:
Met de laatste update is de "condition" voor datetime stukgemaakt voor mij. Deze nam altijd ook de datum mee, maar na de laatste homeassistant update, doet hij alleen wat met de tijd.

Ik heb een helper die een datetime heeft. Die staat 7 dagen in de toekomst ingepland na een bepaalde actie.

Ik wil in een andere automation om 9u elke ochtend testen of deze helper in het verleden ligt. Zo ja, dan gaat de automatisering verder.

Hoe schrijf ik die conditie nu?

Ik wil bewust om 9 uur testen, zodat, mocht de helper niet verandert zijn, de volgende dag de automation weer de acties uitvoert.


Edit... gevonden, dit werkt.

YAML:

condition: template
value_template: >
  {{ states('input_datetime.mijn_helper') | as_datetime
  | as_local <= now() }}

Welke condition gebruikte je hiervoor dan, die nu niet meer werkt?
Als dat inderdaad het geval is, zou een bug melding wel op zijn plaats zijn.

[Get!em]

TheFes schreef op dinsdag 14 juli 2026 @ 10:42:
[...]


Welke condition gebruikte je hiervoor dan, die nu niet meer werkt?
Als dat inderdaad het geval is, zou een bug melding wel op zijn plaats zijn.

Ik gebruikte “time”. Er staat nu in de documentatie dat deze alleen nog maar time afhandelt en geen date.

Ik heb hem een jaar lang gebruikt om conditie te testen of 9uur vandaag later is dan de datetime helper, en dat deed t prima.

Na de updates eind juni is dat stuk gegaan.

[ Voor 19% gewijzigd door Get!em op 14-07-2026 10:52 ]

[TheFes]

Get!em schreef op dinsdag 14 juli 2026 @ 10:47:
[...]

Ik gebruikte “time”. Er staat nu in de documentatie dat deze alleen nog maar time afhandelt en geen date.

Ik heb hem een jaar lang gebruikt om conditie te testen of 9uur vandaag later is dan de datetime helper, en dat deed t prima.

Na de updates eind juni is dat stuk gegaan.

Die note in de documentatie is in juni 2021 toegevoegd in deze commit. Dat was ook toen daadwerkelijk support voor het verwijzen naar entities voor de tijd is toegevoegd. Dus dat is niet gewijzigd sinds de laatste release.

Weet je zeker dat het voorheen wel werkte?

Anyway, de template condition die je nu hebt is verder prima.

[Get!em]

TheFes schreef op dinsdag 14 juli 2026 @ 10:56:
[...]


Die note in de documentatie is in juni 2021 toegevoegd in deze commit. Dat was ook toen daadwerkelijk support voor het verwijzen naar entities voor de tijd is toegevoegd. Dus dat is niet gewijzigd sinds de laatste release.

Weet je zeker dat het voorheen wel werkte?

Anyway, de template condition die je nu hebt is verder prima.

Weet zeker dat t werkte, gezien mijn legionella run er vanaf hangt en ik er een notificatie van ontvang op mobiel.

Anyhow, gefixt.

[Septillion]

Anderzijds eigenlijk wel gek dat (input_)datetime geen propose specific trigger ontvangen heeft.

[TheFes]

Septillion schreef op dinsdag 14 juli 2026 @ 11:09:
Anderzijds eigenlijk wel gek dat (input_)datetime geen propose specific trigger ontvangen heeft.

Ik heb daar wel op Discord voorstellen over voorbij zien komen. Eigenlijk voor alles wat een datetime als state heeft (scene, sensors met timestamp device class, datetime helpers, events, etc)

[Septillion]

@TheFes Dat zou helemaal goed zijn natuurlijk. Maar is het denk ik wel weer lastig voor dat er geen datetime of time device class bestaat.

Maar gezien hoe feature compleet het gepresenteerd is vind ik het dus wel verwondelijk dat sommige domains er dus nog niet in zitten.

offtopic:
Eigenlijk is de term device class überhaupt raar en zou het entity class moeten heten...

[belly89]

Ben(V) schreef op dinsdag 14 juli 2026 @ 09:32:
@belly89

Klinkt alsof je bios in een powersave mode geconfigureerd is en de usb poort in "sleep mode" zet als hij een tijdje niet gebruikt wordt en dat de Rfxcom hem er niet uit die "sleep mode" krijgt.

Dat zal best eens kunnen inderdaad, vanavond even testen!! Thanks

[Raven]

Voor degenen waar Home Assistant gebruik maakt van de BLE van Shelly's:

Shelly is begonnen met de uitrol van firmware 2.0.0, hierbij viel mij iets op:

Removed
BLE: Remove global enable flag from config (auto-activate/deactivate scanning) BREAKING CHANGE

Daar ik nieuwsgierig ben wat er breaking aan is, even zitten Googlen, de AI kwam met dit:

In Shelly firmware 2.0.0, the primary breaking change regarding Bluetooth Low Energy (BLE) is the removal of the global BLE.config.enable flag.

Key Details & Action Required
- Auto-Activation: BLE scanning now automatically activates only when needed by scripts, BLU gateways, or BTHome devices, and shuts down when idle.

- Removed Configuration: The global enable property in BLE.GetConfig no longer exists. If your scripts, automations, or API calls explicitly check or set this property, they will throw errors and fail.

- RPC Control Remains: While the scanner toggle is gone, the rpc.enable property remains to control whether BLE can be used to send RPC commands to the device.

[Borromini]

Ik heb wat trend sensors opgezet maar daar lijkt niks mee te gebeuren. Het idee is 0,5° C stijging te traceren op een half uur (0,5 / 1800). Gisteren ingesteld, ik had verwacht dat er deze morgen wel zouden triggeren, maar ze blijven allemaal op 'unknown' staan.

Heb ik deze verkeerd opgezet?

YAML:

- platform: trend
  sensors:
    bad_1e_temp_stijgend:
      entity_id: sensor.mi_sensor_fa5a_temperature
      unique_id: bad_1e_temp_stijgend_trend
      sample_duration: 1800
      max_samples: 200
      min_samples: 60
      min_gradient: 0.000277
      device_class: heat

[Sjoop1985]

@Borromini Weet je zeker dat de oorspronkelijke sensor minimaal 60 waardes genereert in het window van 1800 seconden (wat neerkomt op gemiddeld 1 keer per 30 seconden). De meeste batterij gevoede sensoren halen dat niet als de temperatuur niet voldoende verandert.

[Borromini]

Goed punt. Ik was op de specs van mijn SwitchBot-sensoren afgegaan, die zeggen elke 4s, maar inderdaad. Ik zal de waardes verlagen en zien wat dat geeft, bedankt.

[CappieL]

fub schreef op maandag 13 juli 2026 @ 22:16:
[...]

Maar de sensor doet het wel, en ik krijg ook een grafiek en de waarde wordt geupdate in mijn dashboard en alles. Ik heb een helper gemaakt die met die waarde rekent. Dus die integratie werkt gewoon, voor alles wat ik kan nagaan en zie.

YAML:

sensor:
  - platform: rest
    name: "Weerstation"
    resource: "~[URL]"
    value_template: "{{  value_json.temp | float(0) }}"
    device_class: "temperature"
    scan_interval: 330
    state_class: "measurement"
    unique_id: "weerstation"

Ik heb de URL weggelaten, want daar zit mijn persoonlijke key in. Maar het resultaat van de GET is bijvoorbeeld

code:

{"datum":"13-07-26","tijd":"22:15","temp":24.6}

Zou je de URL willen tonen (bijv in MO-tags) en dan je persoonlijke key kunnen vervangen voor insert_personal_key_here?

[fub]

CappieL schreef op woensdag 15 juli 2026 @ 10:07:
Zou je de URL willen tonen (bijv in MO-tags) en dan je persoonlijke key kunnen vervangen voor insert_personal_key_here?

Nee, want de naam van het dorp waar ik woon staat in de URL. En je komt toch niet aan een key, want die moet de beheerder van het weerstation met de hand voor jou aanmaken, dat is niet de een of andere online flow die je zelf kunt doorlopen.

Maar als je niet een lokaal weerstation hebt waarvan je contact hebt met de beheerder, dan is er nog altijd de Open Meteo API. Ook een REST API die je kunt uitlezen: https://open-meteo.com/en/docs. (Er is ook een standaared integratie maar die levert niet alle data die beschikbaar is. Via die docs kan je je eigen API call samenstellen met de data die jij wil hebben.)

[ Voor 30% gewijzigd door fub op 15-07-2026 11:00 ]

[Card Nox]

Card Nox schreef op donderdag 2 juli 2026 @ 17:12:
Mensen die hier de Tesla Fleet API werkend hebben gekregen in Home Assistant, ik krijg het maar niet voor elkaar, hulp is welkom.

Iemand? Wil er graag voor betalen, ik krijg het simpelweg niet voor elkaar...

[janvanduschoten]

Card Nox schreef op woensdag 15 juli 2026 @ 13:07:
[...]

Iemand? Wil er graag voor betalen, ik krijg het simpelweg niet voor elkaar...

Ik heb zelf geen Tesla, maar wat gaat er mis? Claude gaf al aan dat "de Tesla Fleet API-integratie is berucht om zijn setup-frictie"

[Stubby]

Card Nox schreef op woensdag 15 juli 2026 @ 13:07:
[...]

Iemand? Wil er graag voor betalen, ik krijg het simpelweg niet voor elkaar...

Works on my machine... Wat wil je weten?

[akatar]

Korte vraag, ik heb een weerstation die via mqtt naar homeassistant gaat, op een gegeven moment kreeg ik geen data meer binnen en heb ik in HA mqtt de devices verwidjerd. Het probleem was simpel op te lossen, batterijen vervangen en mijn weerstation kwam weer tot leven.

Alleen zegt HA nu: eniteit niet gevonden en idd de devices worden niet opnieuw aangemaakt na het verwijderen (de gegevens komen gewoon aan volgens mqtt explorer)

Is er een manier dat deze opnieuw worden aangemaakt? Ik zie het ff niet.

[Septillion]

@akatar Maar hoe is de MQTT ooit in HA gekomen? Heb je zelf MQTT sensoren aangemaakt, was dat een losse integratie of deed het ding (type zou handig zijn) aan HA auto discovery?

[Borromini]

Ondertussen heb ik m'n trend sensors werkend. Alleen heb ik er twee - die monitoren toevallig allebei een SwitchBot sensor - die niet resetten. De ene een dalende trend, de andere met een stijgende. Moet ik hier met de sample-instellingen spelen? Of heb ik iets over het hoofd gezien?

Min/max is 5/30, dat lijkt me niet extreem overdreven, maar goed...

YAML:

slaap_voor_temp_stijgend:
      entity_id: sensor.meter_pro_co2_33ed_temperatuur
      unique_id: slaap_voor_temp_stijgend_trend
      sample_duration: 1800
      max_samples: 30
      min_samples: 5
      min_gradient: 0.000277
      device_class: heat

Screenshots:

[Sjoop1985]

Hoe ziet het verloop van de bron sensoren eruit op datzelfde tijdsinterval?

[akatar]

Septillion schreef op woensdag 15 juli 2026 @ 23:27:
@akatar Maar hoe is de MQTT ooit in HA gekomen? Heb je zelf MQTT sensoren aangemaakt, was dat een losse integratie of deed het ding (type zou handig zijn) aan HA auto discovery?

Het originele device, rfxcom 868 doet aan ha auto discovery, zodoende kwamen de sensoren in HA. Na het vrwijderen van deze sensoren worden deze niet meer opnieuw toegevoegd en heb ik zelf geen idee waar ik dit kan instellen oid

[Septillion]

@akatar RFXcom al herstart? Meeste devices sturen dan de auto discovery weer.

En raad RFXcom niet aan om Auto discovery weer uit te zetten zodra ze toegevoegd zijn? Gekeken of die setting nog aan staat?

[Septillion]

@Borromini Mijn batterij sensoren geven makkelijk minder dan 5 sample per 30 minuten als de temperatuur stabiel is.

[GeeMoney]

Goedenavond, het is weer zover
Ik krijg weer meldingen dat er iets deprecated is maar krijg het niet gecorrigeerd in de code:



Ik heb het volgende:

YAML:

sensor:
  - platform: template
    sensors:               
      fairland_wpu_mode:
        friendly_name: "Zwembad WPU Mode"
        unique_id: "Zwembad WPU Mode"
        value_template: >
          {% if states.sensor.fairland_zwembad_wpu_mode.state == "0" %}
          Normal
          {% elif states.sensor.fairland_zwembad_wpu_mode.state == "1" %}
          Silence                                            
          {% elif states.sensor.fairland_zwembad_wpu_mode.state == "2" %}
          Super Silence         
          {% elif states.sensor.fairland_zwembad_wpu_mode.state == "3" %}
          Turbo                                         
          {% endif %}
  - platform: template
    sensors:               
      fairland_wpu_power:
        friendly_name: "Zwembad WPU Power"
        unique_id: "Zwembad WPU Power"
        unit_of_measurement: "W"
        value_template: >
          {% set voltage = states('sensor.fairland_zwembad_wpu_pfc_volt') | float %}
          {% set ampere = states('sensor.fairland_zwembad_wpu_compressor_amp') | float %}

          {{ ((voltage * ampere) ) | round(1, default=0) }}

template:
  - number:
      - name: Temperatuur Zwembad WPU
        unique_id: template_number_temp_waterpomp
        state: "{{ states('sensor.fairland_zwembad_wpu_heating_temp') }}"
        min: 28
        max: 34
        step: 1.0
        set_value: 
          - service: modbus.write_register
            data:
              hub: waveshare1
              address: 3
              slave: 1
              value: "{{ (value +30) * 2  }}"

Als ik letterlijk doe wat hij zegt dan krijg ik dit maar werkt het evengoed niet:

YAML:

template:
  - number:
      - name: Temperatuur Zwembad WPU
        unique_id: template_number_temp_waterpomp
        state: "{{ states('sensor.fairland_zwembad_wpu_heating_temp') }}"
        min: 28
        max: 34
        step: 1.0
        set_value: 
          - service: modbus.write_register
            data:
              hub: waveshare1
              address: 3
              slave: 1
              value: "{{ (value +30) * 2  }}"

  - sensor:                  
      fairland_wpu_mode:      
        friendly_name: "Zwembad WPU Mode"
        unique_id: "Zwembad WPU Mode"    
        value_template: >                
          {% if states.sensor.fairland_zwembad_wpu_mode.state == "0" %}
          Normal                                                       
          {% elif states.sensor.fairland_zwembad_wpu_mode.state == "1" %}
          Silence                                                        
          {% elif states.sensor.fairland_zwembad_wpu_mode.state == "2" %}
          Super Silence                                                  
          {% elif states.sensor.fairland_zwembad_wpu_mode.state == "3" %}
          Turbo                                                          
          {% endif %}                                                    

  - sensor:                                                  
      fairland_wpu_power:      
        friendly_name: "Zwembad WPU Power"
        unique_id: "Zwembad WPU Power"    
        unit_of_measurement: "W"                        
        value_template: >                 
          {% set voltage = states('sensor.fairland_zwembad_wpu_pfc_volt') | float %}
          {% set ampere = states('sensor.fairland_zwembad_wpu_compressor_amp') | float %}
                                                                                         
          {{ ((voltage * ampere) ) | round(1, default=0) }}  

[ Voor 33% gewijzigd door GeeMoney op 16-07-2026 19:00 ]

[akatar]

Septillion schreef op donderdag 16 juli 2026 @ 18:08:
@akatar RFXcom al herstart? Meeste devices sturen dan de auto discovery weer.

En raad RFXcom niet aan om Auto discovery weer uit te zetten zodra ze toegevoegd zijn? Gekeken of die setting nog aan staat?

Auto discovery stond aan, deze uitgezet, reboot en weer aanegzet. hetzelfde verhaal. met mqtt explorer zie ik hem ook langskomen, maar e devices worden niet opnieuw weer aangemaakt.

[verjager]

@GeeMoney
Er moet maar 1x sensor: onder template:

En elke sensor beginnen (inspringen) met een streepje.

Zie voorbeeld https://www.home-assistant.io/integrations/template/#sensor

[GeeMoney]

verjager schreef op donderdag 16 juli 2026 @ 19:19:
@GeeMoney
Er moet maar 1x sensor: onder template:

En elke sensor beginnen (inspringen) met een streepje.

Zie voorbeeld https://www.home-assistant.io/integrations/template/#sensor

Dat voorbeeld kan ik ook niet matchen met meerdere sensors, ik ben te stom denk ik.

Nu heb ik dit maar ook dan werken ze niet:

YAML:

template:
  - number:
      - name: Temperatuur Zwembad WPU
        unique_id: template_number_temp_waterpomp
        state: "{{ states('sensor.fairland_zwembad_wpu_heating_temp') }}"
        min: 28
        max: 34
        step: 1.0
        set_value: 
          - service: modbus.write_register
            data:
              hub: waveshare1
              address: 3
              slave: 1
              value: "{{ (value +30) * 2  }}"

  - sensor:                  
     - fairland_wpu_mode:      
        friendly_name: "Zwembad WPU Mode"
        unique_id: "Zwembad WPU Mode"    
        value_template: >                
          {% if states.sensor.fairland_zwembad_wpu_mode.state == "0" %}
          Normal                                                       
          {% elif states.sensor.fairland_zwembad_wpu_mode.state == "1" %}
          Silence                                                        
          {% elif states.sensor.fairland_zwembad_wpu_mode.state == "2" %}
          Super Silence                                                  
          {% elif states.sensor.fairland_zwembad_wpu_mode.state == "3" %}
          Turbo                                                          
          {% endif %}                                                    

     - fairland_wpu_power:      
        friendly_name: "Zwembad WPU Power"
        unique_id: "Zwembad WPU Power"    
        unit_of_measurement: "W"                        
        value_template: >                 
          {% set voltage = states('sensor.fairland_zwembad_wpu_pfc_volt') | float %}
          {% set ampere = states('sensor.fairland_zwembad_wpu_compressor_amp') | float %}
                                                                                         
          {{ ((voltage * ampere) ) | round(1, default=0) }}  

[Septillion]

@GeeMoney Dan heb je of heel lang geen updates gedaan of je hebt al heel lang de deprecation melding weggedrukt... Laatste kwam zelfs met copy paste versie van nieuwe style.

YAML:

template:
  - sensor:
      - name: "Zwembad WPU Mode"
        unique_id: "Zwembad WPU Mode"
        default_entity_id: sensor.fairland_wpu_mode
        state: >-
          {% if states('sensor.fairland_zwembad_wpu_mode') == "0" %}
            Normal
          {% elif states('sensor.fairland_zwembad_wpu_mode') == "1" %}
            Silence                                            
          {% elif states('sensor.fairland_zwembad_wpu_mode') == "2" %}
            Super Silence         
          {% elif states('sensor.fairland_zwembad_wpu_mode') == "3" %}
            Turbo                                         
          {% endif %}
        availability: "{{ has_value('sensor.fairland_zwembad_wpu_mode') }}"
      - name: "Zwembad WPU Apparant Power"
        unique_id: "Zwembad WPU Mode"
        default_entity_id: sensor.fairland_wpu_power
        unit_of_measurement: "VA"
        state_class: measurement
        device_class: apparent_power
        state: >-          
          {% set voltage = states('sensor.fairland_zwembad_wpu_pfc_volt') | float %}
          {% set ampere = states('sensor.fairland_zwembad_wpu_compressor_amp') | float %}
          {{ ((voltage * ampere) ) | round(1) }}
        availability: >-
          {{ has_value('sensor.fairland_zwembad_wpu_pfc_volt')
          and has_value('sensor.fairland_zwembad_wpu_compressor_amp') }}
  - number:
      - name: Temperatuur Zwembad WPU
        unique_id: template_number_temp_waterpomp
        state: "{{ states('sensor.fairland_zwembad_wpu_heating_temp') }}"
        availability: "{{ has_value('sensor.fairland_zwembad_wpu_heating_temp') }}"
        min: 28
        max: 34
        step: 1.0
        set_value: 
          - service: modbus.write_register
            data:
              hub: waveshare1
              address: 3
              slave: 1
              value: "{{ (value + 30) * 2  }}"

Fixes:
- Nieuwe template format
- Fix dat state altijd opgehaald wordt met state(), scheelt je weer errors in je log
- Fix dat de templates een availability hebben, scheelt je weer errors in je log
- Unit fix van je power, want in AC geeft spanning maal stroom alleen power in watt als het resistieve belasting is
- Device en state class toegevoegd

[TheFes]

GeeMoney schreef op donderdag 16 juli 2026 @ 19:32:
[...]


Dat voorbeeld kan ik ook niet matchen met meerdere sensors, ik ben te stom denk ik.

Nu heb ik dit maar ook dan werken ze niet:

YAML:

template:
  - number:
      - name: Temperatuur Zwembad WPU
        unique_id: template_number_temp_waterpomp
        state: "{{ states('sensor.fairland_zwembad_wpu_heating_temp') }}"
        min: 28
        max: 34
        step: 1.0
        set_value: 
          - service: modbus.write_register
            data:
              hub: waveshare1
              address: 3
              slave: 1
              value: "{{ (value +30) * 2  }}"

  - sensor:                  
     - fairland_wpu_mode:      
        friendly_name: "Zwembad WPU Mode"
        unique_id: "Zwembad WPU Mode"    
        value_template: >                
          {% if states.sensor.fairland_zwembad_wpu_mode.state == "0" %}
          Normal                                                       
          {% elif states.sensor.fairland_zwembad_wpu_mode.state == "1" %}
          Silence                                                        
          {% elif states.sensor.fairland_zwembad_wpu_mode.state == "2" %}
          Super Silence                                                  
          {% elif states.sensor.fairland_zwembad_wpu_mode.state == "3" %}
          Turbo                                                          
          {% endif %}                                                    

     - fairland_wpu_power:      
        friendly_name: "Zwembad WPU Power"
        unique_id: "Zwembad WPU Power"    
        unit_of_measurement: "W"                        
        value_template: >                 
          {% set voltage = states('sensor.fairland_zwembad_wpu_pfc_volt') | float %}
          {% set ampere = states('sensor.fairland_zwembad_wpu_compressor_amp') | float %}
                                                                                         
          {{ ((voltage * ampere) ) | round(1, default=0) }}  

Er is veel meer mis dan @verjager aangeeft.

Heb je deze template sensors al lang? Want vanaf 2025.12 zijn er al repair meldingen geweest dat deze legacy syntax gaat verdwijnen, echter stond daar het eerste half jaar nog precies de YAML die het dan in de moderne syntax moet worden bij.
Vanaf 2026.6 wordt de legacy syntax helemaal niet meer ondersteund, en kon er daarom ook geen nieuwe code meer in de repair melding weergegeven worden.

Als je het weer terugbrengt naar de oude situatie, kun je met deze custom integration de moderne syntax YAML genereren.
https://github.com/Petro31/hass-migrate-template

In dit topic op het HA forum vindt je nog meer informatie
https://community.home-as...ntities-in-2026-6/1011847

Als je echt wil is het ook wel handmatig te doen.
Heb de eerste als voorbeeld gedaan
~~~~~~~~~~~~~~~~

YAML:

  - sensor:                  
      - default_entity_id: sensor.fairland_wpu_mode    
        name: "Zwembad WPU Mode"
        unique_id: "Zwembad WPU Mode"    
        state: >                
          {% if states.sensor.fairland_zwembad_wpu_mode.state == "0" %}
          Normal                                                       
          {% elif states.sensor.fairland_zwembad_wpu_mode.state == "1" %}
          Silence                                                        
          {% elif states.sensor.fairland_zwembad_wpu_mode.state == "2" %}
          Super Silence                                                  
          {% elif states.sensor.fairland_zwembad_wpu_mode.state == "3" %}
          Turbo                                                          
          {% endif %}

[ Voor 14% gewijzigd door TheFes op 16-07-2026 19:54 ]

[GeeMoney]

@Septillion en @TheFes ik heb lang niet ge update inderdaad omdat het 9 van de 10x meer stuk maakt dan mij lief is .
Jullie kennen mijn mening over HA denk ik maar ik moest weer eens updaten vanwege een integratie en dan haal je dus ook weer gelijk dit soort zaken op je hals.

[Septillion]

@GeeMoney Ik zou toch iets vaker updaten, deprecation meldingen staan een half jaar. Of je moet echt heeel heeeel heeeeeeeeeeeeel goed alle changelogs gaan lezen. Maar minimaal 1x per half jaar updaten is makkelijker.

[Septillion]

@akatar Topic dat je laat zien is gewoon het state topic. Maar de auto discovery berichten staan in homeassistant/<domain>/<device>. Moet je daar even neuzen/zoeken naar de berichten voor je sensor.

[GeeMoney]

@Septillion in de log zie ik nu ook deze melding:

Entity sensor.itho_autotemp_woonkamer_kw (<class 'homeassistant.components.mqtt.sensor.MqttSensor'>) is using state class 'measurement' which is impossible considering device class ('energy') it is using; expected None or one of 'total_increasing', 'total'; Please update your configuration if your entity is manually configured .

Gaat om deze als voorbeeld:

YAML:

    - name: "Itho AutoTemp Woonkamer kW"
      state_topic: "itho-auto/ithostatus"
      value_template: "{{ value_json['Room 1 power kW (kW)'] }}"
      unique_id: "itho_auto_woonkamer_kw"
      state_class: "measurement"
      device: { identifiers: ["itho-auto-6778"] }
      device_class: "energy"
      unit_of_measurement: "kWh"

[ Voor 33% gewijzigd door GeeMoney op 16-07-2026 22:06 ]

[TheFes]

GeeMoney schreef op donderdag 16 juli 2026 @ 22:05:
@Septillion in de log zie ik nu ook deze melding:

Entity sensor.itho_autotemp_woonkamer_kw (<class 'homeassistant.components.mqtt.sensor.MqttSensor'>) is using state class 'measurement' which is impossible considering device class ('energy') it is using; expected None or one of 'total_increasing', 'total'; Please update your configuration if your entity is manually configured .

Gaat om deze als voorbeeld:

YAML:

    - name: "Itho AutoTemp Woonkamer kW"
      state_topic: "itho-auto/ithostatus"
      value_template: "{{ value_json['Room 1 power kW (kW)'] }}"
      unique_id: "itho_auto_woonkamer_kw"
      state_class: "measurement"
      device: { identifiers: ["itho-auto-6778"] }
      device_class: "energy"
      unit_of_measurement: "kWh"

De name een state kijken er op te wijzen dat het hier om power gaat en niet energy, met kW als unit. Dan zou het dus dit worden.

YAML:

    - name: "Itho AutoTemp Woonkamer kW"
      state_topic: "itho-auto/ithostatus"
      value_template: "{{ value_json['Room 1 power kW (kW)'] }}"
      unique_id: "itho_auto_woonkamer_kw"
      state_class: "measurement"
      device: { identifiers: ["itho-auto-6778"] }
      device_class: "power"
      unit_of_measurement: "kW"

[Septillion]

@GeeMoney Wat er staat klopt. Misschien is de foutmelding aangescherpt, maar het is altijd fout geweest.

Een energy waarde loopt altijd alleen op of begint opnieuw. Gezien het altijd een eenheid over een tijdspanne is. Vergelijk het met rijden, de afstand die je gereden hebt op je teller loopt ook alleen op of je reset hem naar 0. Er is geen instantaneous waarde zonder tijdspanne.

Maar inderdaad, aan topic en naam te zien heb je vermogen en energie (power en energy) door elkaar gehaald. Dus moet je er device_class: power van maken met als eenheid kW. Of je kW ook in de naam wilt hebben kan je ook over twijfelen.

En als je ergens het device ook een naam geeft verwacht ik overigens ook entities met dubbelop namen.

Als de Itho ook een last will topic heeft kan je ook hier availability toevoegen.

~~~[edit]@TheFes was me voor omdat ik schijnbaar niet op send gedrukt had

[editedit]
Alleen zonder avilability, want weet niet waar die zit, zou ik dus iets als het volgende doen

YAML:

    - name: "Vermogen"
      state_topic: "itho-auto/ithostatus"
      value_template: "{{ value_json['Room 1 power kW (kW)'] }}"
      unique_id: "itho_auto_woonkamer_kw"
      state_class: "measurement"
      device: 
        identifiers: 
          - "itho-auto-6778"
        name: Itho AutoTemp Woonkamer
      device_class: "power"
      unit_of_measurement: "kW"

[ Voor 40% gewijzigd door Septillion op 16-07-2026 22:27 ]

[Borromini]

Sjoop1985 schreef op donderdag 16 juli 2026 @ 13:24:
Hoe ziet het verloop van de bron sensoren eruit op datzelfde tijdsinterval?

Sensor dalende trend is daarnet pas getriggerd, niet abnormaal met dit weer. Afgelopen nacht ook nauwelijks afgekoeld hier.



Sensor stijgende trend is wel de hele dag op actief blijven staan (sinds gisteren 15/7 's morgens), terwijl die stijging zeker niet over de hele periode 0,5° C per half uur was (en 's nachts is de temperatuur gezakt). Die sensor had dan toch vrij snel moeten resetten?



@Septillion OK. Nog minder samples dus .

[GeeMoney]

Wederom dank heren, het moet inderdaad power zijn en geen energy. Die naamswijziging voer ik even niet door want ik heb 10 groepen die ik op die manier uitlees dus dan is name: vermogen niet heel handig ?

[Septillion]

@Borromini Waarom niet gewoon op 2 en het laten leiden door de tijdsduur?

Volgens mij heeft de trendsensor alleen nog steeds wel het gebrek dat het alleen met de samples in het tijdsframe werkt. Het extrapoleert niet de state van voor het tijdsframe als de steady state aan het begin van het tijdsframe ofzo. Dus lange tijd steady state kunnen lastig zijn.

[Septillion]

@GeeMoney Naam is natuurlijk aan jezelf.:)

Maar HA prefixt de device naam voor de entity naam. Dus onder aan de streep heb je dus als nog "Itho AutoTemp Woonkamer Vermogen". Of het device "Itho AutoTemp Woonkamer" moet heten of gewoon "Itho" (en entity "AutoTemp Woonkamer Vermogen") ligt even aan wat werkelijk het device is

[turkeyhakan]

Ik weet niet of het hier hoort, maar ik kon al een aantal weken mijn HA niet meer updaten. Was heel traag. Uiteindelijk een error gezien

1. data_filesystem_check_error
2. os_filesystem_check_error

Niet kunnen oplossen helaas. Ik denk dat mijn SD kaart die erin zat, z'n beste tijd heeft gehad. Kan dat kloppen? Is een SanDisk Extreme 32GB. Is nu ongeveer 5 jaar oud.

Gelukkig kon ik nog een back-up maken en ben ik die nu aan het terugzetten. Heb maar gelijk een Samsung T7 SSD aangesloten.

[Ben(V)]

SD kaarten zijn volkomen ongeschikt voor HA, die kunnen maar een beperkt aantal keren beschreven worden en HA schrijft continue erg veel kleine hoeveelheden data.

[stijn1309]

Ben(V) schreef op vrijdag 17 juli 2026 @ 09:26:
SD kaarten zijn volkomen ongeschikt voor HA, die kunnen maar een beperkt aantal keren beschreven worden en HA schrijft continue erg veel kleine hoeveelheden data.

Nou... 3 jaar probleemloos gedraaid op een SD kaart en nu op ssd maar dan vanwege de overstap naar een mini pc ipv raspbery pi.

De sd doet nu nog dienst in de raspberry pi wat nu een webservertje is.

Wat je alleen wel moet doen is een Goede SD kaart kopen die een stuk duurder is. Eerder had ik ook de goedkopere en gaven na een jaar problemen.

[Ben(V)]

Zou hem maar gewoon weggooien want hij is onbetrouwbaar geworden, tenzij je af en toe een crash niet erg vind.
En duur of goedkoop zal misschien iets in levensduur schelen maar de basis techniek is hetzelfde en niet geschikt voor veel schrijf acties.

Dit is gewoon een algemeen bekent probleem bij een pi.

[kepler]

eiPionezero schreef op vrijdag 17 juli 2026 @ 12:23:
Showcase van een waarschijnlijk atypische maar voor ons zeer praktische automation.

Drie weken geleden vader geworden van een prachtig wondertje. Dit minimensje consumeert niet alleen melk, maar produceert ook plas en kerrie. Vanuit de kraamzorg en het consultatiebureau was er het advies om deze output bij te houden: tijdstip en categorie. Dit kan heel mooi in een boekje worden opgeschreven, maar om vier uur 's nachts schiet dit er wel eens bij in, en de volgende ochtend heb je na dagenlang zeer weinig slaap geen idee meer wat er is gebeurd, wat de administratie niet ten goede komt. De oplossing? Home Assistant.

Als basis een Ikea afstandsbediening, de klassieke Zigbee Rodret aan/uit/dimmer.
'aan' kort indrukken registreert een plasje, 'uit' kort indrukken een poepje, en ingedrukt houden corrigeert een registratie:

YAML:

alias: Luier - knop naar teller
description: Registreert plas- en poepluiers via de IKEA knop
triggers:
  - trigger: event
    alias: Plas +1
    id: plas_plus
    event_type: zha_event
    event_data:
      device_ieee: c0:9b:9e:ff:fe:73:df:15
      command: "on"
  - trigger: event
    alias: Poep +1
    id: poep_plus
    event_type: zha_event
    event_data:
      device_ieee: c0:9b:9e:ff:fe:73:df:15
      command: "off"
  - trigger: event
    alias: Plas -1
    id: plas_min
    event_type: zha_event
    event_data:
      device_ieee: c0:9b:9e:ff:fe:73:df:15
      command: move_with_on_off
  - trigger: event
    alias: Poep -1
    id: poep_min
    event_type: zha_event
    event_data:
      device_ieee: c0:9b:9e:ff:fe:73:df:15
      command: move
actions:
  - choose:
      - conditions:
          - condition: trigger
            id: plas_plus
        sequence:
          - action: counter.increment
            target:
              entity_id: counter.babyplas
      - conditions:
          - condition: trigger
            id: plas_min
        sequence:
          - action: counter.decrement
            target:
              entity_id: counter.babyplas
      - conditions:
          - condition: trigger
            id: poep_plus
        sequence:
          - action: counter.increment
            target:
              entity_id: counter.babypoep
      - conditions:
          - condition: trigger
            id: poep_min
        sequence:
          - action: counter.decrement
            target:
              entity_id: counter.babypoep
mode: queued
max: 10

Om middernacht worden de statistieken gereset:

YAML:

alias: Luier - dagreset
description: Reset de dagelijkse plas- en poepregistratie om middernacht
triggers:
  - trigger: time
    at: "00:00:00"
actions:
  - action: counter.reset
    target:
      entity_id:
        - counter.babyplas
        - counter.babypoep
mode: single

En bij elke wijziging gaat er ook een notificatie naar de telefoons van zowel papa als mama, voor wat extra digitale betrokkenheid. De notificatie titel is zo opgesteld dat ook vanaf een Garmin smartwatch direct duidelijk is wat er exact is gebeurd:

YAML:

alias: Luier - melding bij tellerwijziging
description: Stuurt een melding bij een wijziging van de plas- of poepregistratie
triggers:
  - trigger: state
    entity_id: counter.babyplas
  - trigger: state
    entity_id: counter.babypoep
conditions:
  - condition: template
    value_template: "{{ trigger.to_state.state != '0' }}"
actions:
  - variables:
      soort: |
        {% if trigger.entity_id == 'counter.babyplas' %}
          Plas
        {% else %}
          Poep
        {% endif %}
      actie: |
        {% if trigger.to_state.state | int > trigger.from_state.state | int %}
          geregistreerd
        {% else %}
          gecorrigeerd
        {% endif %}
  - action: notify.send_message
    target:
      entity_id:
        - notify.phone1
        - notify.phone2
    data:
      title: "{{ soort }} {{ actie }} ({{ trigger.to_state.state }})"
      message: >
        Vandaag: 💦 {{ states('counter.babyplas') }} • 💩 {{ states('counter.babypoep') }}
mode: queued
max: 10

Vervolgens op het main dashboard in home assistant een grafiek van de afgelopen paar dagen

Het leuke: deze aanpak heeft een zeer hoge WAF, ook (schoon)moeder en bezoek is enthousiast over de eenvoud en het gemak

Haha mooie oplossing en gefeliciteerd!

En dit hebben wij ook gedaan in het begin, maar waren we al snel weer klaar mee Hoop andere leuke automations te verzinnen voor kinderen trouwens