Home Assistant: Open source Python3 home automation - deel 5

[Hermarcel]

@grizzlywilde
Ik heb nul ervaring met Zigbee, maar iets als Google al geprobeerd?

[Ben(V)]

grizzlywilde schreef op dinsdag 21 oktober 2025 @ 09:10:
Ik heb nieuwe temp/luchtvochtigheid sensoren gekocht. De Sonoff SNZB-02P. Na installatie krijg ik in HA de melding dat er een nieuwe firmware is. Als ik het apparaat echter probeer bij te werken krijg ik deze melding:

code:

Logger: homeassistant.components.websocket_api.http.connection
Bron: components/websocket_api/commands.py:317
integratie: Home Assistant WebSocket API (documentatie, problemen)
Eerst voorgekomen: 20 oktober 2025 om 18:55:14 (3 gebeurtenissen)
Laatst gelogd: 09:04:40

[140650989577824] Error during service call to update.install: Update was not successful: Failed to deliver packet: <TXStatus.MAC_TRANSACTION_EXPIRED: 240>
[140650900076192] Error during service call to update.install: Update was not successful: Failed to deliver packet: <TXStatus.MAC_TRANSACTION_EXPIRED: 240>

Niet een erg uitgebreide foutmelding. Iemand toevallig enig idee? Ik heb HA, en zelfs het hele x86 systeem waar het op draait, al herstart en meerdere keren de firmware update geprobeerd te draaien.

Dit soort devices gaan volledig offline als ze geen verandering in temperatuur of vochtigheid te melden hebben en dus kun je hem dan ook helemaal niet bereiken en ook niet updaten.

De beste methode is om die SNZB-02P dicht bij de coordinator te houden, dan de reset knop van dat ding indrukken om vervolgens de update te starten.
Het kan zijn dat je het een paar keer moet proberen want die dingen vallen weer snel in slaap.
Als je geen PC in de buurt hebt kun je hem ook via een ander Zigbee device upgraden, maar dan moet je wel "upgrade via this device gebruiken".

Houd er rekening mee dat het updaten lang duurt en dat daarna de batterij behoorlijk leeg zal zijn.

[pietje63]

MRNX schreef op maandag 20 oktober 2025 @ 21:50:
[...]


Wel de vraag nog hoe het zit met de indents voor de sql? Ik krijg het AI niet aan hun kunstmatige verstand gepeuterd dat de sql aan het begin moet ipv de sensor.

Ik heb letterlijk tegen chatgpt gezegd "zit het probleem niet in sensor: ipv sql:
zie https://www.home-assistant.io/integrations/sql/", en daarna ging het goed

Overigens: de meta_id moet metadata_id zijn en dat is inderdaad een nummer. Toen ik die eenmaal vond was het een beetje prutsen en heel veel heen en weer met Gemini.

My bad, was even uit mijn hoofd op mijn telefoon , goed dat je het corrigeert voor andere gebruikers (en LLMs die deze pagina meelezen)

[TheFes]

@pietje63 @MRNX
Er is ook een recorder.get_statistics action die een response geeft met de data die je wil. Op basis van die data kun je ook een trigger based template sensor maken die bijvoorbeeld elke dag om middernacht, of elk uur ververst.
Die is vrij nieuw, dus het zal nog even duren voordat een LLM daarmee zal komen.

[pietje63]

@TheFes
Dat is inderdaad een handige optie! Met de volgende code krijg ik ook het gasverbuik van vorige maand. De setup is intuïtiever, en kan me ook voorstellen dat het opzetten van de automatisering eenvoudiger is. Van de andere kant heb ik al wat ervaring met sql. Ik neem aan dat op de achtergrond vergelijkbare sql wordt uitgevoerd dus dat het performance wise niets scheelt.

YAML:

action: recorder.get_statistics
data:
  statistic_ids:
    - sensor.gas_jaar
  start_time: "2025-09-01 00:00:00"
  end_time: "2025-09-30 23:59:59"
  period: month
  types:
    - change
  units:
    energy: kWh
response_variable: consumption_stats

nota bene: ik gebruikte in eerste instantie 24:00:00 voor eindtijd, maar krijg dan een maand extra.. 23:59:59 als eindtijd oogt minder mooi en voelt minder compleet (je mist toch de laatste seconde..)

[TheFes]

pietje63 schreef op dinsdag 21 oktober 2025 @ 13:47:
@TheFes
Dat is inderdaad een handige optie! Met de volgende code krijg ik ook het gasverbuik van vorige maand. De setup is intuïtiever, en kan me ook voorstellen dat het opzetten van de automatisering eenvoudiger is. Van de andere kant heb ik al wat ervaring met sql. Ik neem aan dat op de achtergrond vergelijkbare sql wordt uitgevoerd dus dat het performance wise niets scheelt.

YAML:

action: recorder.get_statistics
data:
  statistic_ids:
    - sensor.gas_jaar
  start_time: "2025-09-01 00:00:00"
  end_time: "2025-09-30 23:59:59"
  period: month
  types:
    - change
  units:
    energy: kWh
response_variable: consumption_stats

nota bene: ik gebruikte in eerste instantie 24:00:00 voor eindtijd, maar krijg dan een maand extra.. 23:59:59 als eindtijd oogt minder mooi en voelt minder compleet (je mist toch de laatste seconde..)

Nee, die seconde mis je niet. Als de als periode month kiest pakt hij altijd de gehele maand. Ook als je bijvoorbeeld dit gebruikt:

YAML:

  start_time: "2025-09-14 00:00:00"
  end_time: "2025-09-15 23:59:59"

[I-King]

Wat is de meest simpele plug-and-play oplossing zodat mijn partner makkelijk kan zien of het warmwater op niveau is?

Ik heb een warmtepomp en een sww vat. Ik heb deze scherp afgesteld zodat hij niet continue aan 't bijverwarmen is. Maar heel soms als mijn partner het bad in wil net ná de kinderen, dan is hij aan 't opwarmen waardoor je een frisse douche hebt.

• Mijn simpelste idee, een knopje, die een rood/oranje/groen ledje geeft.
• Alternatief, de HA app op haar telefoon zetten, maar die heeft ze vaak niet bij zich
• Een simpel schermpje die de temperatuur weergeeft.

Low maintenance, low effort, geen batterijen vervangen iedere maand


Iemand een makkelijk en goed idee?

[ Voor 5% gewijzigd door I-King op 21-10-2025 15:20 ]

[kepler]

I-King schreef op dinsdag 21 oktober 2025 @ 15:18:
Wat is de meest simpele plug-and-play oplossing zodat mijn partner makkelijk kan zien of het warmwater op niveau is?

Ik heb een warmtepomp en een sww vat. Ik heb deze scherp afgesteld zodat hij niet continue aan 't bijverwarmen is. Maar heel soms als mijn partner het bad in wil net ná de kinderen, dan is hij aan 't opwarmen waardoor je een frisse douche hebt.

• Mijn simpelste idee, een knopje, die een rood/oranje/groen ledje geeft.
• Alternatief, de HA app op haar telefoon zetten, maar die heeft ze vaak niet bij zich
• Een simpel schermpje die de temperatuur weergeeft.

Low maintenance, low effort, geen batterijen vervangen iedere maand


Iemand een makkelijk en goed idee?

Wat betreft het weergeven, ik ben heel tevreden met de epaper screens die ik aanstuurt via https://openepaperlink.de/
Kan je ook gelijk meer info inzetten



En gelijk een wedervraag, hoe bepaal je nauwkeurig of er nog genoeg warm water is? Ik merk dat de watertemp in het sww vat niet altijd een goede indicatie is. En hier wordt er ook pas verwarmd als de zon (genoeg) schijnt, dus ben benieuwd naar jou oplossing
(Gelukkig komt koud water niet heel vaak voor nog)

[thechib12]

TheFes schreef op dinsdag 21 oktober 2025 @ 06:51:
[...]

Smart Life is Tuya.

Dat was het inderdaad! Integratie werkt, thanks

[Thorsd]

grizzlywilde schreef op dinsdag 21 oktober 2025 @ 09:10:
Ik heb nieuwe temp/luchtvochtigheid sensoren gekocht. De Sonoff SNZB-02P. Na installatie krijg ik in HA de melding dat er een nieuwe firmware is. Als ik het apparaat echter probeer bij te werken krijg ik deze melding:

code:

Logger: homeassistant.components.websocket_api.http.connection
Bron: components/websocket_api/commands.py:317
integratie: Home Assistant WebSocket API (documentatie, problemen)
Eerst voorgekomen: 20 oktober 2025 om 18:55:14 (3 gebeurtenissen)
Laatst gelogd: 09:04:40

[140650989577824] Error during service call to update.install: Update was not successful: Failed to deliver packet: <TXStatus.MAC_TRANSACTION_EXPIRED: 240>
[140650900076192] Error during service call to update.install: Update was not successful: Failed to deliver packet: <TXStatus.MAC_TRANSACTION_EXPIRED: 240>

Niet een erg uitgebreide foutmelding. Iemand toevallig enig idee? Ik heb HA, en zelfs het hele x86 systeem waar het op draait, al herstart en meerdere keren de firmware update geprobeerd te draaien.

Ik heb deze ook, en afgelopen week maar 's de update knop in HA geklikt en er verder niet naar om gekeken. Ze lijken nu geupdate (FW 0x00002200). Geen knop ingedrukt en batterij is ook nog 100%. Dit is met de ZHA integratie, HA 2025.8.3.

[I-King]

kepler schreef op dinsdag 21 oktober 2025 @ 15:32:
[...]

Wat betreft het weergeven, ik ben heel tevreden met de epaper screens die ik aanstuurt via https://openepaperlink.de/
Kan je ook gelijk meer info inzetten

[Afbeelding]

En gelijk een wedervraag, hoe bepaal je nauwkeurig of er nog genoeg warm water is? Ik merk dat de watertemp in het sww vat niet altijd een goede indicatie is. En hier wordt er ook pas verwarmd als de zon (genoeg) schijnt, dus ben benieuwd naar jou oplossing
(Gelukkig komt koud water niet heel vaak voor nog)

Ahja, dit ben ik een keer tegengekomen, is ook een topic van geloof ik. Dacht dat dat altijd veel priegelen was. Toch maar eens induiken dan.

Ik heb in principe 2 sensors, 1 onderin de tank en 1 bovenin, en ik heb een threshold vanaf wanneer hij mag verwarmen. Niets complex. Maar omdat hij gaat mengen bij verwarmen kan 't vat 2/3e koud zijn en 1/3e warm waardoor je ineens onder de comfortgrens zakt.

[Get!em]

Thorsd schreef op dinsdag 21 oktober 2025 @ 20:55:
[...]


Ik heb deze ook, en afgelopen week maar 's de update knop in HA geklikt en er verder niet naar om gekeken. Ze lijken nu geupdate (FW 0x00002200). Geen knop ingedrukt en batterij is ook nog 100%. Dit is met de ZHA integratie, HA 2025.8.3.

Update duurt zomaar tot 2uur per apparaat. Beter ook maar 1 per keer tegelijk doen.
Batterij ging bij mij na vorige update van 100 naar 40% en waren daarna zo binnen 3 maanden leeg. Wisselen van batterij is koud kunstje, maar toch.

[Borromini]

Ik heb met volgende YAML een sensor geïmplementeerd om graaddagen te berekenen, maar die doet niks meer. Zou elke 6' moeten updaten, maar als ik de entity state nakijk dan gebeurt er niks meer na de YAML reload of HA herstart. De sensor voor de temperatuur werkt, die wordt ook voor andere dingen gebruikt en heb ik in de template editor geladen om te dubbelchecken.

Hoe kan ik uitvlooien waarom die niet bijwerkt?

YAML:

- trigger:
    - trigger: time_pattern
      id: "update"
      minutes: "/6"    # Herhaal elke 6 minuten
    - trigger: time_pattern
      id: "clear"   # Zet teller terug naar nul om middernacht
      hours: "0"
      minutes: "1"
  sensor:
    - name: Graaddag
      unique_id: degree_day
      state: >-
        {% if trigger.id == "update" %}
          {% set freq = 0.1 %}
          {% set base = 16.5 %}
          {% set current_temp = states('sensor.thuis_current_temperature') | float(0) %}
          {% set partial_dd = max(0, (base - current_temp) / (24 / freq)) %}
          {{ (this.state | float(default=0)) + partial_dd | round(1) }}
        {% else %}
          {{ 0 }}
        {% endif %}
      state_class: total_increasing

[TheFes]

Borromini schreef op dinsdag 21 oktober 2025 @ 21:47:
Ik heb met volgende YAML een sensor geïmplementeerd om graaddagen te berekenen, maar die doet niks meer. Zou elke 6' moeten updaten, maar als ik de entity state nakijk dan gebeurt er niks meer na de YAML reload of HA herstart. De sensor voor de temperatuur werkt, die wordt ook voor andere dingen gebruikt en heb ik in de template editor geladen om te dubbelchecken.

Hoe kan ik uitvlooien waarom die niet bijwerkt?

YAML:

- trigger:
    - trigger: time_pattern
      id: "update"
      minutes: "/6"    # Herhaal elke 6 minuten
    - trigger: time_pattern
      id: "clear"   # Zet teller terug naar nul om middernacht
      hours: "0"
      minutes: "1"
  sensor:
    - name: Graaddag
      unique_id: degree_day
      state: >-
        {% if trigger.id == "update" %}
          {% set freq = 0.1 %}
          {% set base = 16.5 %}
          {% set current_temp = states('sensor.thuis_current_temperature') | float(0) %}
          {% set partial_dd = max(0, (base - current_temp) / (24 / freq)) %}
          {{ (this.state | float(default=0)) + partial_dd | round(1) }}
        {% else %}
          {{ 0 }}
        {% endif %}
      state_class: total_increasing

En wat is de state op dit moment dan?

[Borromini]

Die is 0 maar wordt zo ingesteld zolang er nog niks wordt uitgelezen. Ondertussen in de logs wel dit te zien, dus toch iets mis, ook al lijkt de YAML op zich wel correct

Logger: homeassistant.config
Bron: config.py:354
Eerst voorgekomen: 21:51:32 (8 gebeurtenissen)
Laatst gelogd: 21:59:47

Invalid config for 'template' at templates.yaml, line 155: invalid template (TemplateSyntaxError: unexpected '}', expected ')') for dictionary value 'sensor->0->state', got '{% if trigger.id == "update" %}\n {% set freq = 0.1 %}\n {% set base = 16.5 %}\n {% set current_temp = states(\'sensor.thuis_current_temperature\') | float(0) %}\n {% set partial_dd = max(0, (base - current_temp) / (24 / freq)) %}\n {{ (this.state | float() + partial_dd | round(1) }}\n{% else %}\n {{ 0 }}\n{% endif %}'
Invalid config for 'template' at templates.yaml, line 155: invalid template (TemplateSyntaxError: expected token ')', got '=') for dictionary value 'sensor->0->state', got '{% if trigger.id == "update" %}\n {% set freq = 0.1 %}\n {% set base = 16.5 %}\n {% set current_temp = states(\'sensor.thuis_current_temperature\') | float(0) %}\n {% set partial_dd = max(0, (base - current_temp) / (24 / freq)) %}\n {{ (this.state | float((default=0)) + partial_dd | round(1) }}\n{% else %}\n {{ 0 }}\n{% endif %}'
Invalid config for 'template' at templates.yaml, line 155: invalid template (TemplateSyntaxError: expected token ')', got '=') for dictionary value 'sensor->0->state', got '{% if trigger.id == "update" %}\n {% set freq = 0.1 %}\n {% set base = 16.5 %}\n {% set current_temp = states(\'sensor.thuis_current_temperature\') | float(0) %}\n {% set partial_dd = max(0, (base - current_temp) / (24 / freq)) %}\n {{ (this.state | float((default=0)) + partial_dd }}\n{% else %}\n {{ 0 }}\n{% endif %}'

[ Voor 47% gewijzigd door Borromini op 21-10-2025 22:02 ]

[Septillion]

@Borromini Zijn dat niet gewoon oude errors?

En is je probleem niet dat je partial_dd afrond op 1 decimaal? Want zeg dat het nu 10 graden is probeer je 6,5/240 = 0.027 => afgerond 0.0

[iqcgubon]

Tweeledig vraagje hier. Werkt de Webpage card eigenlijk op websites buiten die van HA zelf?

Als je het kaartje toevoegt toont die standaard de homepage van Home Assistant en die werkt prima. Maar letterlijk eender welke andere website die ik probeer wil niet laden. "Waterfox Can’t Open This Page". Ik neem aan dat bijna elke website tegenwoordig hun x-frame-options op Deny heeft staan. Dus no luck?

Voor mensen met een SMA-systeem thuis: Ik zou namelijk graag de widget "Energiestroom" in mijn HA weergeven.



Ik kan dit uiteraard ook nabouwen met alle data die ik rechtstreeks uitlees van de omvormer, maar als het gewoon voor het grijpen ligt...

[TheFes]

Septillion schreef op dinsdag 21 oktober 2025 @ 22:59:
@Borromini Zijn dat niet gewoon oude errors?

En is je probleem niet dat je partial_dd afrond op 1 decimaal? Want zeg dat het nu 10 graden is probeer je 6,5/240 = 0.027 => afgerond 0.0

Ik gok dat @Borromini de gehele uitkomst will afronden en dus even haakjes moet gebruiken zodat niet alleen partial_dd afgerond wordt.

[Septillion]

@TheFes Waarschijnlijk. Maar ook dat is nutteloos. Want als partial_dd zo'n kleine stap is en de state altijd maar 1 decimaal is dan heb je ook altijd state + partial_dd = state indien je weer afrond

Ofwel, als je zo wilt sommen moet je state dus wel genoeg decimalen bevatten ofwel, beter niet afronden.

@Borromini Maar even out of the box, wat je daar dus feitelijk doet is een integraal (benadering). Wat je dus volgens mij ook zou kunnen doen is:
- Template sensor met (base - current_temp)
- Riemann sum (= stapgewijze integraal) daarover
- En een utility meter daarover als je het per uur wilt.

[dotcom87]

We hebben een nieuw bed besteld. Ons vorige bed had nachtlampjes ingebouwd, maar dat is met het nieuwe bed niet het geval. Daarom was ik aan het kijken om misschien een led strip achter het hoofdbord te plaatsen, wat toch wat moderner oogt denk ik.

- Welke LED strip zou hiervoor het best geschikt zijn? Ik heb Zigbee en Wi-Fi als opties voor de connectie met Home Assistant.
- Een bedieningsknop zou misschien nog wel handig zijn. Ik ben wel van plan om het licht automatisch te laten dimmen over een tijd van 15 minuten eens we in bed liggen.

[Borromini]

Septillion schreef op dinsdag 21 oktober 2025 @ 22:59:
@Borromini Zijn dat niet gewoon oude errors?

En is je probleem niet dat je partial_dd afrond op 1 decimaal? Want zeg dat het nu 10 graden is probeer je 6,5/240 = 0.027 => afgerond 0.0

Die komen terug naar boven bij elke herstart of reload (net nog even geprobeerd).



Ik zal vanavond 'ns kijken of ik dat naar Riemann kan omzetten, deze code had ik van het HA forum geplukt.

[ Voor 9% gewijzigd door Borromini op 22-10-2025 09:35 ]

[RobertMe]

dotcom87 schreef op woensdag 22 oktober 2025 @ 09:22:
- Welke LED strip zou hiervoor het best geschikt zijn? Ik heb Zigbee en Wi-Fi als opties voor de connectie met Home Assistant.

Effectief zijn dit twee vragen. Welke LED strip en welke controller. En het antwoord kan een combinatie zijn, maar kan ook los zijn. Je kunt ook prima een losse LED strip kopen en vervolgens een Atom LED controller (op wifi, met WLED als software) of een Gledopto controller (Zigbee?). (Of dus een Hue LED strip wat wel een product is, maar ook dan een losse strip die je met connector in controller steekt ).

V.w.b. LED strip is dan ook nog de vraag wat je wilt. Alleen wit of ook kleuren? (En als kleuren (RGB), wil je dan ook fatsoenlijk wit, met witte leds (dus RGBW)? Of is "wit" maken met gekleurde leds voldoende?). En is het voldoende als de hele strip één "stand" (kleur / helderheid) heeft? Of wil je mogelijk verschillende kleuren / gradient / ... gebruiken? ("Domme" analoge led strip waarbij de controller puur iets met de stroom doet v.w.b. helderheid van de leds, vs een digitale / adresseerbare led strip waarbij elke led individueel aangestuurd wordt).

[dotcom87]

RobertMe schreef op woensdag 22 oktober 2025 @ 09:32:
[...]

Effectief zijn dit twee vragen. Welke LED strip en welke controller. En het antwoord kan een combinatie zijn, maar kan ook los zijn. Je kunt ook prima een losse LED strip kopen en vervolgens een Atom LED controller (op wifi, met WLED als software) of een Gledopto controller (Zigbee?). (Of dus een Hue LED strip wat wel een product is, maar ook dan een losse strip die je met connector in controller steekt ).

V.w.b. LED strip is dan ook nog de vraag wat je wilt. Alleen wit of ook kleuren? (En als kleuren (RGB), wil je dan ook fatsoenlijk wit, met witte leds (dus RGBW)? Of is "wit" maken met gekleurde leds voldoende?). En is het voldoende als de hele strip één "stand" (kleur / helderheid) heeft? Of wil je mogelijk verschillende kleuren / gradient / ... gebruiken? ("Domme" analoge led strip waarbij de controller puur iets met de stroom doet v.w.b. helderheid van de leds, vs een digitale / adresseerbare led strip waarbij elke led individueel aangestuurd wordt).

Mijn vraag was misschien inderdaad niet helemaal duidelijk gesteld

We willen er geen kleurboek van maken Bedoeling is om wit tinten (van feller wit tot warm wit) te gaan gebruiken. Zo wat zachte "ambient" animaties zouden wel nog leuk zijn, maar geen must.
De Athom controller spreekt me wel erg aan (ik heb ook al presence sensors van hun).

[TheFes]

Borromini schreef op woensdag 22 oktober 2025 @ 09:32:
[...]

Die komen terug naar boven bij elke herstart of reload (net nog even geprobeerd).

[Afbeelding]

Ik zal vanavond 'ns kijken of ik dat naar Riemann kan omzetten, deze code had ik van het HA forum geplukt.

Als je dit invoert in devtools > templates zul je zien dat het template gewoon goed is. Bij mij komt er nu 0.1 uit

code:

{% set trigger = dict(id='update') %}
{% set this = dict(state=0) %}
    
    {% if trigger.id == "update" %}
          {% set freq = 0.1 %}
          {% set base = 16.5 %}
          {% set current_temp = states('sensor.thuis_current_temperature') | float(0) %}
          {% set partial_dd = max(0, (base - current_temp) / (24 / freq)) %}
          {{ (this.state | float(default=0)) + partial_dd | round(1) }}
        {% else %}
          {{ 0 }}
        {% endif %}

Ik heb verder die sensor niet, dus hij zal 0 gebruiken (default waarde voor het float filter)

[CWH]

Ik las net op AD over een AccuSaver, een stekker die laden van een fietsaccu stopt bij 98/99% om warmteontwikkeling en degradatie van de accu te voorkomen.
Is zoiets, en zoja hoe, niet ook via een slimme stekker en HA te bereiken?

[CappieL]

CWH schreef op woensdag 22 oktober 2025 @ 09:55:
Ik las net op AD over een AccuSaver, een stekker die laden van een fietsaccu stopt bij 98/99% om warmteontwikkeling en degradatie van de accu te voorkomen.
Is zoiets, en zoja hoe, niet ook via een slimme stekker en HA te bereiken?

Ja, je kunt een slimme stekker laten afschakelen wanneer de accu aan het einde van zijn laad-cyclus is (vermogen < x Watt voor y minuten).

Enkel zit de logica in deze stekker verwerkt en heb je geen extern schakelsysteem nodig.

Wanneer je dan weer een accu aan de lader hangt, zet je de stekker weer aan door op het knopje op de stekker te drukken (of middels een knop/schuifje in HA).

[ Voor 23% gewijzigd door CappieL op 22-10-2025 10:13 ]

[Ben(V)]

Gewoon een simpele powerplug die stroom kant meten en die je kunt besturen met HA.
Even kijken wat de stroom is als hij bij 95% lading is en dan HA bij een stroom lager dan die waarde laten afschakelen.

Zou trouwens iedereen moeten doen die accu's laat laden.
Lees maar eens hoe vaak er tegenwoordig van die dingen in de brand vliegen door overladen.

[ Voor 27% gewijzigd door Ben(V) op 22-10-2025 11:46 ]

[maartend]

Ben(V) schreef op woensdag 22 oktober 2025 @ 11:44:
Gewoon een simpele powerplug die stroom kant meten en die je kunt besturen met HA.
Even kijken wat de stroom is als hij bij 95% lading is en dan HA bij een stroom lager dan die waarde laten afschakelen.

En hoe kijk je of de accu 95% is geladen?

[Ben(V)]

Even een keer monitoren als je hem vollaad.
De laadstroom neemt af als je in de buurt komt.
HA levert je een prima grafiekje daarvoor aan.

[ Voor 21% gewijzigd door Ben(V) op 22-10-2025 12:04 ]

[CappieL]

Of je nu wilt opladen tot 95% of tot 100%, het gaat er vooral om dat je hem niet continu aan de lader laat hangen. vol = vol.
Dus je kunt gaan kijken hoeveel de laadstroom is op 95%, maar je kunt ook kijken wanneer het laden helemaal is gestopt (vermogen = 0) en dat je hem dan uitschakelt.

[ Voor 39% gewijzigd door CappieL op 22-10-2025 12:19 ]

[Septillion]

Een loodaccu of nikkelaccu kan prima tegen druppelladen. Maar een lithiumaccu vind dat inderdaad niet zo leuk. Eigenlijk dus idioot dat er laders zijn die niet gewoon stoppen

[Ben(V)]

Niet helemaal volladen tot de max is erg goed voor de levensduur van de accu, dus misschien wel slim om iets eerder te stoppen.

[-Casper]

CWH schreef op woensdag 22 oktober 2025 @ 09:55:
Ik las net op AD over een AccuSaver, een stekker die laden van een fietsaccu stopt bij 98/99% om warmteontwikkeling en degradatie van de accu te voorkomen.
Is zoiets, en zoja hoe, niet ook via een slimme stekker en HA te bereiken?

Veel reacties maar geen voorbeeld, dus ik zal even een automation delen die ik hiervoor gebruik:

YAML:

alias: Ebike - Lader uit bij 100%
description: ""
mode: single
triggers:
  - entity_id: sensor.ebike_lader_power
    below: 5
    for:
      seconds: 30
    trigger: numeric_state
conditions: []
actions:
  - entity_id: switch.ebike_lader
    action: switch.turn_off

Geen rekening gehouden met laden tot een lager percentage dan 100%, maar gewoon recht toe recht aan: vol is stekker uit.

[CappieL]

-Casper schreef op woensdag 22 oktober 2025 @ 13:14:
[...]

Veel reacties maar geen voorbeeld, dus ik zal even een automation delen die ik hiervoor gebruik:

YAML:

alias: Ebike - Lader uit bij 100%
description: ""
mode: single
triggers:
  - entity_id: sensor.ebike_lader_power
    below: 5
    for:
      seconds: 30
    trigger: numeric_state
conditions: []
actions:
  - entity_id: switch.ebike_lader
    action: switch.turn_off

Geen rekening gehouden met laden tot een lager percentage dan 100%, maar gewoon recht toe recht aan: vol is stekker uit.

Als je een paar keer de laadcurve van je accu hebt bekeken, kun je de 5W uit het voorbeeld makkelijk aanpassen voor welke waarde je maar wilt, om zodoende tot het gewenste laad-percentage te komen.
Het laden van mijn bakfiets-accu begint op 180W en loopt dan af naar 49W en stopt dan abrupt, dus zal ik hem onder de 50W laten afschakelen. Zit ie nagenoeg op 100% en hangt ie er niet te lang aan

[ Voor 7% gewijzigd door CappieL op 22-10-2025 15:20 ]

[JanHenk]

Maar even zonder gekheid, zo'n lader stopt dus gewoon uit zichzelf. Heeft het dan veel nut om een smart plug ertussen te zetten en die uit te schakelen?

Ik snap dat het leuk is vanuit een automatiseringsoogpunt trouwens hoor, wil zelf ook nog een smart plug er tussen zetten om zoveel mogelijk te laden op de zon (schakelen met evcc).

[TheBull]

JanHenk schreef op woensdag 22 oktober 2025 @ 16:19:
Maar even zonder gekheid, zo'n lader stopt dus gewoon uit zichzelf. Heeft het dan veel nut om een smart plug ertussen te zetten en die uit te schakelen?

Net wat je wilt (je zit hier niet voor niks mee te lezen).... AccuSaver kopen voor 59 euro of bij de action een smart plug kopen voor 6,49 euro, die dan bijv. de naam AccuSaver geven en hiervoor een script schrijven zoals hierboven beschreven.

Ik heb zo'n smart plug gebruikt om mijn wasmachine/droger 'slimmer' te maken en een berichtje te ontvangen wanneer de was klaar is (verbruik <= 0 watt gedurende 10 seconden). Zelfde principe.

[ Voor 3% gewijzigd door TheBull op 22-10-2025 16:27 ]

[CappieL]

JanHenk schreef op woensdag 22 oktober 2025 @ 16:19:
Maar even zonder gekheid, zo'n lader stopt dus gewoon uit zichzelf. Heeft het dan veel nut om een smart plug ertussen te zetten en die uit te schakelen?

Ik snap dat het leuk is vanuit een automatiseringsoogpunt trouwens hoor, wil zelf ook nog een smart plug er tussen zetten om zoveel mogelijk te laden op de zon (schakelen met evcc).

De acculader stopt inderdaad vanzelf, maar zal nog steeds proberen een beetje bij te laden.
Het liefst zou je je fietsaccu niet tot 100% willen laden, maar bijv. tot 95%.
Die Accusaver zorgt er gewoon voor dat de accu niet te lang aan een actieve lader ligt (door de spanning te schakelen).

[thechib12]

Ik heb nu de integratie met Zonneplan werkend in Home Assistant, en probeer ik die mooie home assistant grafiek werkend te krijgen, alleen zijn de waardes in de grafiek verkeerd.
Als ik handmatig op de sensor waardes kijk, zijn ze correct. In de screenshot beneden zie je dat de tabel waarde verkeerd is, maar als ik op die waarde klik komt er in de popup een andere waarde. Home assistant rebooten maakte geen verschil. Dit geldt ook voor de andere waardes zoals gas consumptie.

[ Voor 3% gewijzigd door thechib12 op 22-10-2025 17:14 ]

[Driek]

thechib12 schreef op woensdag 22 oktober 2025 @ 17:13:
Ik heb nu de integratie met Zonneplan werkend in Home Assistant, en probeer ik die mooie home assistant grafiek werkend te krijgen, alleen zijn de waardes in de grafiek verkeerd.
Als ik handmatig op de sensor waardes kijk, zijn ze correct. In de screenshot beneden zie je dat de tabel waarde verkeerd is, maar als ik op die waarde klik komt er in de popup een andere waarde. Home assistant rebooten maakte geen verschil.

[Afbeelding]

hier kan een uur tijdverschil tussen zitten, vandaar het verschil

[thechib12]

Driek schreef op woensdag 22 oktober 2025 @ 17:14:
[...]

hier kan een uur tijdverschil tussen zitten, vandaar het verschil

Dat snap ik, maar de actuele sensor waardes in home assistant zijn correct, alleen geeft hij de verkeerde waardes weer in de grafiek. Hij heeft de data dus maar gebruikt het niet.

[Driek]

thechib12 schreef op woensdag 22 oktober 2025 @ 17:15:
[...]


Dat snap ik, maar de actuele sensor waardes in home assistant zijn correct, alleen geeft hij de verkeerde waardes weer in de grafiek. Hij heeft de data dus maar gebruikt het niet.

omdat het energy dashboard een andere bron gebruikt, die niet zo vaak geupdate wordt

[Septillion]

@JanHenk Nouwja, een goede lithium lader zou gewoon stoppen en klaar. Dan is er ook geen risico.

Een slechte lader gaat proberen te druppelladen of doorladen en dat is niet goed voor lithium. En schijnbaar zijn er gewoon veel slechte laders in omloop.

[CWH]

-Casper schreef op woensdag 22 oktober 2025 @ 13:14:
[...]

Veel reacties maar geen voorbeeld, dus ik zal even een automation delen die ik hiervoor gebruik:

YAML:

alias: Ebike - Lader uit bij 100%
description: ""
mode: single
triggers:
  - entity_id: sensor.ebike_lader_power
    below: 5
    for:
      seconds: 30
    trigger: numeric_state
conditions: []
actions:
  - entity_id: switch.ebike_lader
    action: switch.turn_off

Geen rekening gehouden met laden tot een lager percentage dan 100%, maar gewoon recht toe recht aan: vol is stekker uit.

Bedankt! Ga het hiermee proberen!

[Hmmbob]

-Casper schreef op woensdag 22 oktober 2025 @ 13:14:
[...]

Veel reacties maar geen voorbeeld, dus ik zal even een automation delen die ik hiervoor gebruik:

YAML:

alias: Ebike - Lader uit bij 100%
description: ""
mode: single
triggers:
  - entity_id: sensor.ebike_lader_power
    below: 5
    for:
      seconds: 30
    trigger: numeric_state
conditions: []
actions:
  - entity_id: switch.ebike_lader
    action: switch.turn_off

Geen rekening gehouden met laden tot een lager percentage dan 100%, maar gewoon recht toe recht aan: vol is stekker uit.

Heb ik nog wel een leuke om toe te voegen: soms zetten onze kinderen de lader aan maar zit de stekker niet goed - dan gebeurt er niet veel qua laden. Dat levert natuurlijk teleurstelling in de ochtend op

Dat kan je natuurlijk ook detecteren. We hebben 2 laders, dus de automation houdt daar rekening mee:

YAML:

    - alias: "Fietslader aan, maar geen stroomverbruik"
      id: fietslader_links_aan_maar_geen_verbruik
      mode: single
      trigger:
        - platform: state
          entity_id: switch.fietslader_links
          to: "on"
          from: "off"
          id: links
        - platform: state
          entity_id: switch.fietslader_rechts
          to: "on"
          from: "off"
          id: rechts
      action:
        - alias: "Checking what sensor to use"
          choose:
            - conditions:
                - "{{ trigger.id == 'links' }}"
              sequence:
                - wait_for_trigger:
                    - platform: numeric_state
                      entity_id: sensor.fietslader_links_power
                      above: 5
                  timeout: "00:05:00"
                  continue_on_timeout: true
            - conditions:
                - "{{ trigger.id == 'rechts' }}"
              sequence:
                - wait_for_trigger:
                    - platform: numeric_state
                      entity_id: sensor.fietslader_rechts_power
                      above: 5
                  timeout: "00:05:00"
                  continue_on_timeout: true
          default:
            - stop: "Cannot determine power sensor to use - trigger.id did not match"
        - choose:
            - conditions: "{{ wait.trigger is none }}"
              sequence:
                - service: notify.mobile_app_sm_a556b
                  data:
                    title: "Let op: Fietslader {{trigger.id}}"
                    message: "De fietslader {{trigger.id}} is aangezet, maar er is na 5 minuten nog geen stroomverbruik gedetecteerd."
                    data:
                      notification_icon: mdi:bicycle-electric
                      ttl: 0
                      priority: high

[Hmmbob]

En als ik dan toch bezig ben: het uitschakelen houdt bij ons ook rekening met dat er 2 laders zijn:

YAML:

    - id: schuur_fietslader
      alias: Fietsaccu lader in de schuur uitschakelen na laden
      description: Fietsaccu lader in de schuur uitschakelen na laden
      mode: single
      triggers:
        - trigger: numeric_state
          entity_id: sensor.fietslader_links_power
          for:
            minutes: 5
          below: 5
          variables:
            switch: switch.fietslader_links
        - trigger: numeric_state
          entity_id: sensor.fietslader_rechts_power
          for:
            minutes: 5
          below: 5
          variables:
            switch: switch.fietslader_rechts
      conditions:
        - alias: "Please, not on restarts"
          condition: template
          value_template: "{{ trigger.from_state.state | is_number }}"
        - alias: "Only if the switch is still on"
          condition: template
          value_template: "{{ is_state(switch, 'on') }}"
      actions:
        - alias: "Lader uitschakelen"
          action: switch.turn_off
          target:
            entity_id: "{{ switch }}"
        - alias: "Sending push notification"
          action: notify.mobile_app_sm_a556b
          data:
            title: "Fietslader uitgeschakeld"
            message: "De {{ state_attr(switch, 'friendly_name') }} is automatisch uitgeschakeld ({{ now().strftime('%H:%M') }})"
            data:
              notification_icon: mdi:bicycle-electric
              ttl: 0
              priority: high
              clickAction: "/lovelace/other"

Beide codes staan ook op GitHub
https://github.com/hmmbob...-%20Outside/bikeshed.yaml

[HuismAndré]

Septillion schreef op woensdag 22 oktober 2025 @ 17:27:
@JanHenk Nouwja, een goede lithium lader zou gewoon stoppen en klaar. Dan is er ook geen risico.

Een slechte lader gaat proberen te druppelladen of doorladen en dat is niet goed voor lithium. En schijnbaar zijn er gewoon veel slechte laders in omloop.

Soms is het ook gewoon gebaseerd op aannames of informatie die afkomstig is uit de NiCd/NiMh tijd (inclusief handleidingen die nog dit soort niet meer kloppende info bevatten). Beter is het om het gewoon te controleren met een slim stopcontactje en/of een slimme thermometer. Dan kun je prima bijhouden wat er werkelijk gebeurt. Dingen die niet warm worden zijn niet boos (en hoeven dus ook niet perse afgeschakeld te worden). Dingen die amper power verbruiken (<1W) zijn ook niet boos.

Uiteraard is het terugdringen van verborgen (standby) verbruik altijd een goed idee maar daarin moet niet doorgeschoten worden. Als je een slim stopcontactje toevoegt dat 24/7 0.5W gebruikt om gedurende 8 uur per dag 2W aan standby verbruik te voorkomen dan ben je geld aan het weggooien (er is namelijk ook nog zoiets als de afschrijving van dat slimme stopcontactje dat je ertussen geplaatst hebt).

Het bijhouden van de accu van een telefoon/tablet e.d. is al helemaal kinderlijk eenvoudig. Je voegt de mobiele app integratie toe aan HA, voegt de apparaten in kwestie toe aan de integratie en gaat de temperatuur van de accu's monitoren. Ook hier geldt weer "een blije accu wordt niet heet en een koele accu is niet boos".

Apparaten gaan tegenwoordig veel slimmer om met hun accu dan vroeger het geval was. Waarom? Nou, een belangrijke reden kan zijn productaansprakelijkheid. Kost nogal wat voor een fabrikant als dankzij zijn apparaten een paar duizend huizen per jaar afbranden waarbij de oorzaak aantoonbaar hun apparaat is.

Ik vraag me trouwens af of het opladen tot 95% vs 100% echt zoden aan de dijk zet. Bij 100% vs. 80% zie je duidelijk een verschil (en bij 100% vs. 70% is dat verschil nog fiks groter). Maar bij 100% vs 95%? Volgens de beschikbare AI's gaat het om "slightly". Ik zou dan eerder richten op 80% (als je met de vermindering in range kunt leven).

[JanHenk]

Ik kan mijn e-bike zo instellen dat ie stopt met laden bij 80% en dat is voor mij ruim voldoende, dus dat gebruik ik ook altijd.

Bij de e-bakfiets hebben we de capaciteit doorgaans wel nodig. Die wordt ook gewoon tot 100% geladen.

Ik kan me niet voorstellen dat de fabrikanten Bosch en Panasonic slechte laders leveren.. Maar misschien ben ik mis.

Desniettemin wil ik binnenkort wel de twee laders automatiseren, maar daarvoor moet ik eerst nog wat stopcontacten regelen op de betreffende plek

Bedankt voor de inspiratie wederom, daarom lees ik hier mee!

[Borromini]

@Septillion @TheFes Bedankt allebei, 't was toch een sluitend haakje dat ontbrak. In een poging om de code wat te stroomlijnen was er één verdwenen en dan was het feest .

[Hmmbob]

HuismAndré schreef op woensdag 22 oktober 2025 @ 19:03:
[...]

Soms is het ook gewoon gebaseerd op aannames of informatie die afkomstig is uit de NiCd/NiMh tijd (inclusief handleidingen die nog dit soort niet meer kloppende info bevatten). Beter is het om het gewoon te controleren met een slim stopcontactje en/of een slimme thermometer. Dan kun je prima bijhouden wat er werkelijk gebeurt. Dingen die niet warm worden zijn niet boos (en hoeven dus ook niet perse afgeschakeld te worden). Dingen die amper power verbruiken (<1W) zijn ook niet boos.

Uiteraard is het terugdringen van verborgen (standby) verbruik altijd een goed idee maar daarin moet niet doorgeschoten worden. Als je een slim stopcontactje toevoegt dat 24/7 0.5W gebruikt om gedurende 8 uur per dag 2W aan standby verbruik te voorkomen dan ben je geld aan het weggooien (er is namelijk ook nog zoiets als de afschrijving van dat slimme stopcontactje dat je ertussen geplaatst hebt).

Het bijhouden van de accu van een telefoon/tablet e.d. is al helemaal kinderlijk eenvoudig. Je voegt de mobiele app integratie toe aan HA, voegt de apparaten in kwestie toe aan de integratie en gaat de temperatuur van de accu's monitoren. Ook hier geldt weer "een blije accu wordt niet heet en een koele accu is niet boos".

Apparaten gaan tegenwoordig veel slimmer om met hun accu dan vroeger het geval was. Waarom? Nou, een belangrijke reden kan zijn productaansprakelijkheid. Kost nogal wat voor een fabrikant als dankzij zijn apparaten een paar duizend huizen per jaar afbranden waarbij de oorzaak aantoonbaar hun apparaat is.

Ik vraag me trouwens af of het opladen tot 95% vs 100% echt zoden aan de dijk zet. Bij 100% vs. 80% zie je duidelijk een verschil (en bij 100% vs. 70% is dat verschil nog fiks groter). Maar bij 100% vs 95%? Volgens de beschikbare AI's gaat het om "slightly". Ik zou dan eerder richten op 80% (als je met de vermindering in range kunt leven).

Da's allemaal heel rationeel bedacht, maar als je iemand in huis hebt die een aantal keer "fietsaccu", "brand" en "oplader" in één zin gelezen heeft, zit je toch gewoon met een slimme stekker bovenstaande code te bouwen.

[Hippe Lip]

Ik heb een Shelly tussenstekker bij mijn fietslader zitten. En ik heb proefondervindelijk vastgesteld dat mijn accu 106 seconde nodig heeft om één procentpunt bij te laden. Dus om er 20% bij te krijgen moet de lader 20 x 106 = 2120 s aan staan.

Dat is heel eenvoudig in een HA-automatisering gezet. De timer daarvoor zit zelfs in die Shelly stekker, zodat je na de aftrap onafhankelijk bent van HA:
http://192.168.2.121/relay/0?turn=on&timer=2120

En op die manier laad ik mijn accu altijd tot 90%. Nooit verder.

[TheFes]

Hippe Lip schreef op woensdag 22 oktober 2025 @ 23:42:
Ik heb een Shelly tussenstekker bij mijn fietslader zitten. En ik heb proefondervindelijk vastgesteld dat mijn accu 106 seconde nodig heeft om één procentpunt bij te laden. Dus om er 20% bij te krijgen moet de lader 20 x 106 = 2120 s aan staan.

Dat is heel eenvoudig in een HA-automatisering gezet. De timer daarvoor zit zelfs in die Shelly stekker, zodat je na de aftrap onafhankelijk bent van HA:
http://192.168.2.121/relay/0?turn=on&timer=2120

En op die manier laad ik mijn accu altijd tot 90%. Nooit verder.

Ik weet niet veel van accu's laden, maar wat ik wel weet is dat het laden in het begin altijd sneller gaat dan tegen het einde. Die check op aantal seconden per procentpunt lijkt me niet echt betrouwbaar.

[Erik80]

Ik miste een integratie om wat voetbalcompetities te volgen. Daarom ben ik samen met wat AI-collega's maar mijn eigen integratie gaan bouwen. Voor mij werkt het, misschien voor iemand anders ook?
Je vind hem hier: https://github.com/rikkie80/football_data_multi

[Stubby]

Erik80 schreef op donderdag 23 oktober 2025 @ 09:22:
Ik miste een integratie om wat voetbalcompetities te volgen. Daarom ben ik samen met wat AI-collega's maar mijn eigen integratie gaan bouwen. Voor mij werkt het, misschien voor iemand anders ook?
Je vind hem hier: https://github.com/rikkie80/football-data-multi

Je link moet met underscores ipv koppeltekens

[Erik80]

🙈 aangepast. Thanks

[TheFes]

Erik80 schreef op donderdag 23 oktober 2025 @ 09:38:
🙈 aangepast. Thanks

Misschien ook even aangeven dat je card voorbeeld gebruik maakt van verschillende custom components (card-mod, flex-table-card)
Oh, en de term Lovelace wordt door het HA team zelf niet meer gebruikt, dat is gewoon Dashboard tegenwoordig.

[ Voor 19% gewijzigd door TheFes op 23-10-2025 09:55 ]

[luigi87]

Kan iemand mij verklaren waarom de energie prijzen niet omgaan naar kwartieren ipv uren?

Ik heb inmiddels de laatste HA versie draaien.
En zowel nordpool, Frank Energy en Energy Zero geven mij nog uur prijzen.

Wat zie ik over het hoofd?

[ArthurMorgan]

@Septillion
ik ben een absolute beginner (sinds gisteren) maar een van de redenen om HA te willen is mede jouw PV limiterscript.

Het werkt, dank je wel!
Een vraag. Ik heb bij pv max power 4200 ingevuld, en bij power set point -500 (ja ik wil tijdens het salderen nog steeds net iets minder dan 1000 kWh exporteren in totaal voor ik bij de volgende staffel uit kom )
Alleen als ik dan de entiteit "net exportlimiet" de waarde laat weergeven op het dashboard. Dan snap ik de waarden ervan niet. Ik heb waarden boven de 7000 W gezien, dus ver boven de echte max.





Ik doe waarschijnlijk iets verkeerd, maar wat?

/edit: ook in de solargo app worden de veel te hoge limieten nu weergegeven. Heb voor de zekerheid even de blueprint uitgezet.
/edit 2: pv power ook de info van de omvormer zelf laten halen hoewel die minder accuraat is. Maar het probleem blijft exact hetzelfde.

[ Voor 9% gewijzigd door ArthurMorgan op 23-10-2025 11:16 ]

[dixet]

luigi87 schreef op donderdag 23 oktober 2025 @ 10:26:
Kan iemand mij verklaren waarom de energie prijzen niet omgaan naar kwartieren ipv uren?

Ik heb inmiddels de laatste HA versie draaien.
En zowel nordpool, Frank Energy en Energy Zero geven mij nog uur prijzen.

Wat zie ik over het hoofd?

De energiemarkt is wel over naar kwartierprijzen, maar de meeste energieleveranciers hanteren nog steeds uurprijzen richting de consument. Anders zouden ze ook alle contracten moeten aanpassen, daar staat (tenminste bij mij) in dat de tarieven per uur worden bepaald. Dus Frank Energie en Energy Zero zullen voorlopig uurtarieven blijven tonen. Als dit je energiekeveranciers zijn wil je waarschijnlijk ook in HA uurprijzen blijven zien om je verbruik slim te plannen.

Nordpool is als het goed is wel over op kwartierprijzen. In de historie van de Current price sensor zou je ieder kwartier een nieuwe prijs moeten zien.

[ Voor 6% gewijzigd door dixet op 23-10-2025 11:25 ]

[loyske]

Iemand hier een idee of er een PIR sensor is die bij beweging ook de Lux waarde doorgeeft? Zwave of Zigbee.

Gebruik hier een Aeotec Multi Sensor op de badkamer op batterijen. Beweging wordt uiteraard gedetecteerd.
Maar Temp, Vocht en Lux wordt volgens een instelling in mijn geval 1x per uur doorgestuurd. Lux had ik nu graag wat vaker, maar zou handig zijn als dat gebeurd tijdens beweging. Alleen dat kan dus niet.

[dixet]

loyske schreef op donderdag 23 oktober 2025 @ 11:30:
Iemand hier een idee of er een PIR sensor is die bij beweging ook de Lux waarde doorgeeft? Zwave of Zigbee.

Gebruik hier een Aeotec Multi Sensor op de badkamer op batterijen. Beweging wordt uiteraard gedetecteerd.
Maar Temp, Vocht en Lux wordt volgens een instelling in mijn geval 1x per uur doorgestuurd. Lux had ik nu graag wat vaker, maar zou handig zijn als dat gebeurd tijdens beweging. Alleen dat kan dus niet.

Volgens mij doet de Philips Hue Motion sensor dat. Die geeft standaard 1x per kwartier de lux door, maar bij beweging wordt deze ook geüpdated.
Dat is heel duidelijk als het in de kamer begint te schemeren en het licht nog niet aangaat op de lux trigger: zodra ik even ga dansen voor de sensor gaat het licht aan 💡(en ik heb geen trigger op beweging).

[luigi87]

dixet schreef op donderdag 23 oktober 2025 @ 11:22:
[...]

De energiemarkt is wel over naar kwartierprijzen, maar de meeste energieleveranciers hanteren nog steeds uurprijzen richting de consument. Anders zouden ze ook alle contracten moeten aanpassen, daar staat (tenminste bij mij) in dat de tarieven per uur worden bepaald. Dus Frank Energie en Energy Zero zullen voorlopig uurtarieven blijven tonen. Als dit je energiekeveranciers zijn wil je waarschijnlijk ook in HA uurprijzen blijven zien om je verbruik slim te plannen.

Nordpool is als het goed is wel over op kwartierprijzen. In de historie van de Current price sensor zou je ieder kwartier een nieuwe prijs moeten zien.

Ah duidelijk, ik ben vooral nu aan het loggen om te begrijpen wat de prijzen doen bij welk weer etc.

Gekke is dat nordpool bij nog steeds per uur prijzen doet. En geen kwartieren, heb de integratie al herladen maar nog steeds uur prijsjes.

[Animal]

Om mijn wasmachine nog beter in te plannen wil ik kijken naar het gebruik per kwartier. Ik exporteer hiervoor de energy entiteit van wasmachine_energy. Zodra ik de filter heb toegepast (vandaag van 5:00 tot 8:00) en ik exporteer de CSV(zodat chatGPT er een overzicht per kwartier van kan maken) zie ik in de CSV een export van 3 tot 5 uur.
Is dit een home assistant bug of heeft het met tijdzones te maken?

[ Voor 4% gewijzigd door Animal op 23-10-2025 12:47 ]

[synoniem]

Animal schreef op donderdag 23 oktober 2025 @ 12:40:
Om mijn wasmachine nog beter in te plannen wil ik kijken naar het gebruik per kwartier. Ik exporteer hiervoor de energy entiteit van wasmachine_energy. Zodra ik de filter heb toegepast (vandaag van 5:00 tot 8:00) en ik exporteer de CSV(zodat chatGPT er een overzicht per kwartier van kan maken) zie ik in de CSV een export van 3 tot 5 uur.
Is dit een home assistant bug of heeft het met tijdzones te maken?

Ja verschil tussen UTC en Europe/Amsterdam is nu nog +2 uur en na zondag 02:00 uur weer +1 uur.

[Animal]

synoniem schreef op donderdag 23 oktober 2025 @ 12:59:
[...]

Ja verschil tussen UTC en Europe/Amsterdam is nu nog +2 uur en na zondag 02:00 uur weer +1 uur.

Dankje. Ik zie ook dat Claude dit wel snapt

[TheFes]

luigi87 schreef op donderdag 23 oktober 2025 @ 11:39:
[...]


Ah duidelijk, ik ben vooral nu aan het loggen om te begrijpen wat de prijzen doen bij welk weer etc.

Gekke is dat nordpool bij nog steeds per uur prijzen doet. En geen kwartieren, heb de integratie al herladen maar nog steeds uur prijsjes.

Heb je het dan over de custom Nordpool integratie, of the core Nordpool integratie?
Beide geven bij mij overigens kwartierprijzen. Voor de core integration is er in 2025.10.1 een fix toegepast voor de kwartierprijzen.

edit:
De custom Nordpool integratie geeft wel kwartierprijzen in de attributes, maar niet als state, die update maar eens per uur

[ Voor 10% gewijzigd door TheFes op 23-10-2025 15:43 ]

[Animal]

TheFes schreef op donderdag 23 oktober 2025 @ 13:24:
[...]


Heb je het dan over de custom Nordpool integratie, of the core Nordpool integratie?
Beide geven bij mij overigens kwartierprijzen. Voor de core integration is er in 2025.10.1 een fix toegepast voor de kwartierprijzen.

Ik ben sinds gisteren overgestapt naar GE-Spot. Actieve developer en er is een kwartier entity en een hourly entity. Hij kijkt naar 3 bronnen (Noordpool, entsoe en spotenergy)

https://github.com/enoch85/ge-spot

[luigi87]

TheFes schreef op donderdag 23 oktober 2025 @ 13:24:
[...]


Heb je het dan over de custom Nordpool integratie, of the core Nordpool integratie?
Beide geven bij mij overigens kwartierprijzen. Voor de core integration is er in 2025.10.1 een fix toegepast voor de kwartierprijzen.

Thanks

Ik draai blijkbaar de custom (hacs versie)
Ik ga ff switchen naar de core integratie.

Edit:
Ja ik draaide op de Hacks versie zonder dit te weten. Verschil is minimaal om te achterhalen enkel het oranje doosje als plaatje.

Heb nu veel meer sensors, die ik ook misde.

Thanks, had dit dus helemaal over het hoofd gezien

Edit 2:
@TheFes thanks, het is nu gefixed !

[ Voor 25% gewijzigd door luigi87 op 23-10-2025 15:20 ]

[Rik.]

Ik draai Home Assistant met DuckDNS icm een Lets Encrypt certificaat. Deze blijkt verlopen te zijn en is niet automatisch verlengd. Ik krijg nu deze foutmelding bij het proberen te verlengen.

Poort 80 staat op de router wel gewoon open, lijkt er alleen op alsof HA niet reageert op poort 80.

code:

 + Validation is pending...
/usr/bin/dehydrated: line 1164: break: only meaningful in a `for', `while', or `until' loop
 + Cleaning challenge tokens...
OK + Challenge validation has failed :(
ERROR: Challenge is invalid! (returned: invalid) (result: ["type"]  "dns-01"
["url"] "https://acme-v02.api.letsencrypt.org/acme/chall/2550732951/602003197631/jzkYog"
["status"]  "invalid"
["validated"]   "2025-10-23T15:54:17Z"
["error","type"]    "urn:ietf:params:acme:error:dns"
["error","detail"]  "While processing CAA for fictiefdomeinvoortweakers.duckdns.org: DNS problem: SERVFAIL looking up CAA for duckdns.org - the domain's nameservers may be malfunctioning"
["error"]   {"type":"urn:ietf:params:acme:error:dns","detail":"While processing CAA for fictiefdomeinvoortweakers.duckdns.org: DNS problem: SERVFAIL looking up CAA for duckdns.org - the domain's nameservers may be malfunctioning"}

Iemand enig idee hoe ik dit kan fixen?

[Septillion]

@Rik. Maakt de DuckDNS addon niet gebruik van de DNS challenge methode? Dus dan is port 80 niet nodig.

Maar DuckDNS is helaas afgelopen jaar wel suuuuper flacky. Dus zou me niets verbazen als het dus gewoon failed doordat DuckDNS niet reageert.

[synoniem]

Septillion schreef op donderdag 23 oktober 2025 @ 18:13:
@Rik. Maakt de DuckDNS addon niet gebruik van de DNS challenge methode? Dus dan is port 80 niet nodig.

Maar DuckDNS is helaas afgelopen jaar wel suuuuper flacky. Dus zou me niets verbazen als het dus gewoon failed doordat DuckDNS niet reageert.

Als ik naar de foutmelding kijk zou het ook kunnen dat een CAA record met 0 issue "letsencrypt.org" ontbreekt voor het (sub)domain. Ik gebruik zelf Dynu (gratis) en daar kan je alle type records aanmaken, weet niet of dat ook voor DuckDNS geldt.

[Rik.]

Septillion schreef op donderdag 23 oktober 2025 @ 18:13:
@Rik. Maakt de DuckDNS addon niet gebruik van de DNS challenge methode? Dus dan is port 80 niet nodig.

Maar DuckDNS is helaas afgelopen jaar wel suuuuper flacky. Dus zou me niets verbazen als het dus gewoon failed doordat DuckDNS niet reageert.

Geen idee welke methode ze gebruiken, merk alleen dat het voor geen meter werkt momenteel...
Hebben jullie ideeën hoe ik dit anders kan fixen?

Wil wel externe toegang hebben, dit ook voor Google Home integratie.
Ik vind het uiteraard geen probleem om een paar uur bezig te zijn met het instellen hiervan, maar dit moet niet elke paar maanden bij het verlopen van het SSL certificaat zo zijn, dan gaat het mij iets teveel tijd kosten.

[ Voor 16% gewijzigd door Rik. op 23-10-2025 19:08 ]

[dannyvdb1997]

Meer mensen die in de iPhone-app last hebben van het fenomeen dat onder andere de zijbalk niet meer sticky is en mee kan scrollen? Heb het ook met pop-ups van Bubble Card, die ineens scrollable zijn en lege ruimtes geven, hetzelfde als bij de zijbalk. Draai van alles de laatste versie, en m’n iPhone draait op iOS 26.0.1. Vind het erg storend…

Heb de cache al een aantal keer geleegd, HA opnieuw opgestart, de app opnieuw geïnstalleerd, maar niets lijkt te helpen.

[ Voor 27% gewijzigd door dannyvdb1997 op 23-10-2025 19:09 ]

[Septillion]

@Rik. Hoe probeerde je eigenlijk dan te verlengen nu? Of heeft de addon er een trigger voor?

Zelf draai ik de Let's Encrypt addon en doet mijn router DDNS naar DuckDNS. Je zou kunnen proberen om de DuckDNS geen certificaat te laten maken en dat via Let's Encrypt addon te doen. Die kan wel een probe op poort 80 doen.

[Rik.]

Septillion schreef op donderdag 23 oktober 2025 @ 19:15:
@Rik. Hoe probeerde je eigenlijk dan te verlengen nu? Of heeft de addon er een trigger voor?

Zelf draai ik de Let's Encrypt addon en doet mijn router DDNS naar DuckDNS. Je zou kunnen proberen om de DuckDNS geen certificaat te laten maken en dat via Let's Encrypt addon te doen. Die kan wel een probe op poort 80 doen.

Ik weet eerlijk gezegd niet meer precies hoe ik het 3 maanden terug ingesteld heb helaas, had ik eigenlijk gewoon op moeten schrijven maar helaas..

Ik heb nu in LetsEncrypt dit staan:

code:

keyfile: privkey.pem
certfile: fullchain.pem
challenge: http
dns: {}
domains:
  - fictiefdomeinvoortweakers.duckdns.org
email: [e-mail]

En DuckDNS addon dit:

code:

domains:
  - fictiefdomeinvoortweakers.duckdns.org
token: fictieve token
aliases: []
lets_encrypt:
  accept_terms: false
  algo: secp384r1
  certfile: fullchain.pem
  keyfile: privkey.pem
seconds: 300

Poort 80 staat open als externe poort, naar interne poort 8123
Dit zou voldoende moeten zijn toch? Zou niet weten hoe ik het in DuckDNS zelf uitschakel namelijk, maar volgens mij is accept terms false daarin voldoende.

Toch in Lets Encrypt addon deze foutmelding:

code:

The Certificate Authority reported these problems:
  Domain: fictiefdomeinvoortweakers.duckdns.org
  Type:   connection
  Detail: IP ADRES: Fetching http://fictiefdomeinvoortweakers.duckdns.org/.well-known/acme-challenge/DSDjIxcW9jYn_JKaB-WClWJQX3MOJSXbm85aOSn1N-8: Error getting validation data
Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.
Some challenges have failed.

In configuration.yaml staat dit:

code:

http:
  ssl_certificate: /ssl/fullchain.pem
  ssl_key: /ssl/privkey.pem

Durf niet te zeggen of m'n router DDNS ondersteunt, dat moet ik morgen dan even uitzoeken, want dat is idd een betere optie.

[ Voor 29% gewijzigd door Rik. op 23-10-2025 19:36 ]

[Septillion]

@Rik. Port 80 moet je dan doorzetten naar poort 80, niet 8123.

[Rik.]

Septillion schreef op donderdag 23 oktober 2025 @ 20:12:
@Rik. Port 80 moet je dan doorzetten naar poort 80, niet 8123.

Dan kreeg ik juist dat de poort dicht was, want HA draait op 8123.

Maar het is opgelost Lets Encrypt stond op secp384r1, dat aangepast naar rsa en in 1x werkend

[Borromini]

Septillion schreef op woensdag 22 oktober 2025 @ 09:14:
@TheFes Waarschijnlijk. Maar ook dat is nutteloos. Want als partial_dd zo'n kleine stap is en de state altijd maar 1 decimaal is dan heb je ook altijd state + partial_dd = state indien je weer afrond

Ofwel, als je zo wilt sommen moet je state dus wel genoeg decimalen bevatten ofwel, beter niet afronden.

@Borromini Maar even out of the box, wat je daar dus feitelijk doet is een integraal (benadering). Wat je dus volgens mij ook zou kunnen doen is:
- Template sensor met (base - current_temp)
- Riemann sum (= stapgewijze integraal) daarover
- En een utility meter daarover als je het per uur wilt.

Om hier nog even op terug te komen: de utility meters ik al, om die graaddagen per dag/maand/jaar bij te houden. De Riemann-sommen ook voor energieverbruik. Is het die tweede trigger om om middernacht te resetten die wringt? (Ik snap het gevoel wel.) Of is er een ander voordeel? Het voordeel nu is dat het allemaal samen in mijn template YAML staat .

[Septillion]

@Borromini Hoe bedoel je met wringt?

Of bedoel je waarom de utility meter? Want dat is inderdaad omdat een Riemann gewoon oneindig door blijft gaan.

[Septillion]

Rik. schreef op donderdag 23 oktober 2025 @ 20:17:
[...]

Dan kreeg ik juist dat de poort dicht was, want HA draait op 8123.

Maar het is opgelost Lets Encrypt stond op secp384r1, dat aangepast naar rsa en in 1x werkend

Klopt, want er draait dan alleen heel kort iets tijdens de renewal. Jij gaat er dan niets zien. Tijdens een renewal is Let's Encrypt dan ook niet interesseert in je HA maar juist dat hij via poort 80 de juiste challenge response op kan halen zodat je daarmee bewijst dat jij de controle hebt over het domein.

Maar goed dat het überhaupt nu werkt

[Septillion]

ArthurMorgan schreef op donderdag 23 oktober 2025 @ 10:55:
@Septillion
ik ben een absolute beginner (sinds gisteren) maar een van de redenen om HA te willen is mede jouw PV limiterscript.

Het werkt, dank je wel!
Een vraag. Ik heb bij pv max power 4200 ingevuld, en bij power set point -500 (ja ik wil tijdens het salderen nog steeds net iets minder dan 1000 kWh exporteren in totaal voor ik bij de volgende staffel uit kom )
Alleen als ik dan de entiteit "net exportlimiet" de waarde laat weergeven op het dashboard. Dan snap ik de waarden ervan niet. Ik heb waarden boven de 7000 W gezien, dus ver boven de echte max.

[Afbeelding]

[Afbeelding]

Ik doe waarschijnlijk iets verkeerd, maar wat?

/edit: ook in de solargo app worden de veel te hoge limieten nu weergegeven. Heb voor de zekerheid even de blueprint uitgezet.
/edit 2: pv power ook de info van de omvormer zelf laten halen hoewel die minder accuraat is. Maar het probleem blijft exact hetzelfde.

Wat bedoel je precies met "te hoge limieten weergegeven"?

De blueprint pakt de schaal van de entity die je bij "PV Power limit" opgeeft als de volledig te regelen schaal. En zo te zien is je "Goodwe Net exportlimit" entity dus ver boven je 4200W in te stellen. Dus dat is wel raar. Waar komt die entity vandaan?

En je HW Power sensor, die gaat dus negatief bij terugleveren?

[Rik.]

Septillion schreef op donderdag 23 oktober 2025 @ 21:22:
[...]

Klopt, want er draait dan alleen heel kort iets tijdens de renewal. Jij gaat er dan niets zien. Tijdens een renewal is Let's Encrypt dan ook niet interesseert in je HA maar juist dat hij via poort 80 de juiste challenge response op kan halen zodat je daarmee bewijst dat jij de controle hebt over het domein.

Maar goed dat het überhaupt nu werkt

Kan ik dan beter intern 80 open laten zodat automatisch verlengen ook goed gaat? Of heb ik extern 80 naar intern 8123 ook nodig?

[Septillion]

@Rik. Voor de DNS challenge hoeft er niets open te staan.

Voor de http challenge moet je poort 80 extern naar poort 80 van HA open hebben staan, anders kan er niet verlengt worden.

Dus weet niet zo goed wat je bedoelt met "intern open laten".

[ArthurMorgan]

Septillion schreef op donderdag 23 oktober 2025 @ 21:31:
[...]

Wat bedoel je precies met "te hoge limieten weergegeven"?

De blueprint pakt de schaal van de entity die je bij "PV Power limit" opgeeft als de volledig te regelen schaal. En zo te zien is je "Goodwe Net exportlimit" entity dus ver boven je 4200W in te stellen. Dus dat is wel raar. Waar komt die entity vandaan?

En je HW Power sensor, die gaat dus negatief bij terugleveren?

Hij gaat naar limieten ver boven de gevraagde import. Ik zou verwachten dat als ik bijvoorbeeld 1000 Watt aan import heb, 500 aan opwek hij de limiet op 2000 Watt zet. Maar het is dus veel hoger. (In het plaatje hierboven meer dan 2 keer zo hoog ) En dus ook hoger dan de limiet van 4200 W die de omvormer heeft èn die in de blueprint staat bij PV max power.

De entity is er gewoon een van de omvormer. Ook een app als solargo gebruikt die. Ik zie de limieten die de blueprint doorgeeft daar ook terug. In feite gewoon de weergave van de limiet die de blueprint maakt.

in de blueprint heb ik dus deze staan bij pv power limit
number.goodwe_net_exportlimiet

en dit is de weergave op mijn dashboard

YAML:

 entity: number.goodwe_net_exportlimiet
secondary_info: state

dus precies dezelfde.

Ik ga morgen de blueprint weer even aanzetten, dan kan ik op de omvormer ook zien wat daar als limiet gegeven wordt. (dat is in procenten, maar dan kan ik zien of daar een percentage van meer dan 100% staat)

[ Voor 35% gewijzigd door ArthurMorgan op 23-10-2025 22:07 ]

[Antonio di]

Rik. schreef op donderdag 23 oktober 2025 @ 21:46:
[...]

Kan ik dan beter intern 80 open laten zodat automatisch verlengen ook goed gaat? Of heb ik extern 80 naar intern 8123 ook nodig?

Hopelijk kom je hier mee verder:
Lees mijn post voor Duckdns etc. met plaatjes/fotos wat ik ingevuld heb, zie:
Antonio di in "Home Assistant: Open source Python3 home automation - deel 5"

Je kunt tegenwoordig ook bij 1 "server" in de HA App (companion App) naast bijv. de DDNS ook een lokale toegang op geven. Bij mij werkt dat op mijn MOTO telefoon(s) i.c.m. mijn Ziggo router (de Wifi) niet goed (weet niet waarom) . Dus ik heb in de HA app nog steeds 2 "servers" die allebei naar hetzelfde HA-smarthome-servertje verwijzingen (1 lokaal en 1 via DDNS) .

[ Voor 27% gewijzigd door Antonio di op 24-10-2025 14:42 ]

[Wachten...]

BiG-GuY schreef op vrijdag 6 juni 2025 @ 07:57:
[...]

Waarom maak je het jezelf moeilijk? Voor een startende gebruiker hebben ze Home Assistant Green en Home Assistant Yellow uitgebracht. Die werken plug&play uit de doos.

Voor licht gebruik is de Green waarschijnlijk meer dan genoeg voor je. Daar worden de Zigbee USB dongles vanzelf in herkend en kan je gewoon de volledige Home Assistant OS gebruiken met Add-Ons.

Dan kan je je NAS gebruiken voor puur opslag, als je dat nodig hebt. Het is nog maar de vraag hoe lang de USB workaround blijft werken met een Synology NAS, kijkende welke kant ze op aan gaan zijn met beperkingen in hardware.

Er zijn ook netwerk gebaseerde Zigbee Coördinators, zoals de SLZB-06 en SLZB-MR01, dan hoef je niks met USB te doen en zou je het wel makkelijk kunnen gebruiken met Home Assistant Container op je NAS.

Alternatief zou nog een mini PC zijn met bijvoorbeeld een N100 of N150 CPU. De installatie daarop is iets complexer, dus weet niet of dat voor jou geschikt is. Er zijn ook verschillende webshops die voorgeïnstalleerde mini PC's verkopen met Home Assistant OS.

Ben zelf een geavanceerde gebruiker en kom uiteindelijk toch steeds terug op een losse mini PC voor puur Home Assistant OS met Add-Ons. Omdat het gewoon makkelijker werkt, makkelijker te onderhouden en zuiniger is.

Heb nu een NUC14 Essential met N355 die trekt gemiddeld 5-7W en reageert supersnel + de SLZB-MR01 voor ZHA en Z2M tegelijk.

Mag ik vragen waarom je beide netwerken draait? Ik ben namelijk zelf aan het kijken voor een nieuwe stick, omdat mijn Conbee II steeds minder stabiel is. De SLZB ziet er wel top uit. Ik moet dus alleen even kijken welke versie ik het beste kan pakken.

Ik draai voornamelijk op HUE spullen via Z2MQTT. Kun je overigens dan gewoon de oude stick eruit halen. de nieuwe erin en dan opnieuw pairen? Of zitten er wel echt meer handelingen aan?

[Borromini]

Septillion schreef op donderdag 23 oktober 2025 @ 21:19:
@Borromini Hoe bedoel je met wringt?

Of bedoel je waarom de utility meter? Want dat is inderdaad omdat een Riemann gewoon oneindig door blijft gaan.

In de zin dat de huidige code je misschien het gevoel geeft dat het inefficiënt is? Of dat het met de Riemann-som 'eleganter' kan.

[Septillion]

@Borromini Het is vooral dat een Riemann helper het al native kan doen op elke state change. Dus in die zin effectiever dan polling.

[Septillion]

ArthurMorgan schreef op donderdag 23 oktober 2025 @ 21:54:
[...]


Hij gaat naar limieten ver boven de gevraagde import. Ik zou verwachten dat als ik bijvoorbeeld 1000 Watt aan import heb, 500 aan opwek hij de limiet op 2000 Watt zet. Maar het is dus veel hoger. (In het plaatje hierboven meer dan 2 keer zo hoog ) En dus ook hoger dan de limiet van 4200 W die de omvormer heeft èn die in de blueprint staat bij PV max power.

De entity is er gewoon een van de omvormer. Ook een app als solargo gebruikt die. Ik zie de limieten die de blueprint doorgeeft daar ook terug. In feite gewoon de weergave van de limiet die de blueprint maakt.

in de blueprint heb ik dus deze staan bij pv power limit
number.goodwe_net_exportlimiet

en dit is de weergave op mijn dashboard

YAML:

 entity: number.goodwe_net_exportlimiet
secondary_info: state

dus precies dezelfde.

Ik ga morgen de blueprint weer even aanzetten, dan kan ik op de omvormer ook zien wat daar als limiet gegeven wordt. (dat is in procenten, maar dan kan ik zien of daar een percentage van meer dan 100% staat)

Ik heb het er dus niet over wat de blueprint doet, maar waarom die limiter zo idioot hoog kan. Toch niet logisch dat je de limiet op 7000W kan zetten van een 4000W omvormer?

De blueprint is gemaakt dat het "PV max power" verwacht indien "PV power limit" op max staat.

Maar als het dus een algemene limiet is voor alle type omvormers maar dat hij wel gewoon op 200 de boel limiteert tot 200W, dan zal je als "PV max power" de max op kunnen geven van number.goodwe_net_exportlimiet. De blueprint zal dan de limiet gewoon blijven ophogen maar dan ben je gewoon echt gelimiteerd door je omvormer.

[BiG-GuY]

Wachten... schreef op donderdag 23 oktober 2025 @ 22:00:
[...]

Mag ik vragen waarom je beide netwerken draait? Ik ben namelijk zelf aan het kijken voor een nieuwe stick, omdat mijn Conbee II steeds minder stabiel is. De SLZB ziet er wel top uit. Ik moet dus alleen even kijken welke versie ik het beste kan pakken.

Ik draai voornamelijk op HUE spullen via Z2MQTT. Kun je overigens dan gewoon de oude stick eruit halen. de nieuwe erin en dan opnieuw pairen? Of zitten er wel echt meer handelingen aan?

Bepaalde apparaten werken beter via ZHA en andere weer via Z2M. Heb uiteindelijk het grootste deel via ZHA draaien, maar specifiek Bosch Smart Home zijn veel completer ondersteund in Z2M bijvoorbeeld, dus die heb ik aan Z2M gekoppeld.

[Wachten...]

BiG-GuY schreef op donderdag 23 oktober 2025 @ 22:50:
[...]

Bepaalde apparaten werken beter via ZHA en andere weer via Z2M. Heb uiteindelijk het grootste deel via ZHA draaien, maar specifiek Bosch Smart Home zijn veel completer ondersteund in Z2M bijvoorbeeld, dus die heb ik aan Z2M gekoppeld.

Grappig dat jij het andersom hebt. Ik heb ooit ZHA geprobeerd (2x) maar dat was echt een drama en werkte totaal niet fijn. Nu al dik 2 jaar over op z2mqtt, daarvoor zat ik op Deconz. Maar goed om te weten en bedankt voor je toelichting.

[ArthurMorgan]

Septillion schreef op donderdag 23 oktober 2025 @ 22:32:
[...]

Ik heb het er dus niet over wat de blueprint doet, maar waarom die limiter zo idioot hoog kan. Toch niet logisch dat je de limiet op 7000W kan zetten van een 4000W omvormer?

De blueprint is gemaakt dat het "PV max power" verwacht indien "PV power limit" op max staat.

Maar als het dus een algemene limiet is voor alle type omvormers maar dat hij wel gewoon op 200 de boel limiteert tot 200W, dan zal je als "PV max power" de max op kunnen geven van number.goodwe_net_exportlimiet. De blueprint zal dan de limiet gewoon blijven ophogen maar dan ben je gewoon echt gelimiteerd door je omvormer.

Ik ga er vandaag mee aan de gang.

Maar de doorgegeven limiet die veel hoger is dan import + opwek + setpoint is dus wel te verwachten zolang de export zelf niet hoger is dan de setpoint?

/edit: bovenstaande heb ik nu weggewerkt, het enige probleem dat over gebleven is is de maximale limiet die 2,5 keer hoger ligt dan de feitelijke limiet.

[ Voor 7% gewijzigd door ArthurMorgan op 24-10-2025 10:29 ]

[ArthurMorgan]

De limit kan tot 10.000, op de omvormer komt dan ook 238%. Dat is dus een echte no go.

Als ik de PV max power op 10.000 zet in de blueprint dan is in elk geval het setpoint nu goed. Maar het risico is dan wel dat als ik hoog zomer veel gebruik hij door kan geven dat hij meer dan 4200 Watt mag doorvoeren. Dat kan de omvormer opblazen. (ik heb 5810 piekwatt op een plat dak in oost-west opstelling)
Dus ik moet eigenlijk ergens een mogelijkheid hebben om die PV max power hard vast te zetten op 4200 Watt.


/edit:
Alles werkt goed, met uitzondering van de maximale limiet die doorgegeven wordt. Is tot aan ergens maart geen probleem. Maar daarna wel.

offtopic:
de PV power moet een positief getal geven om te werken kwam ik achter. Ik gebruikte op een gegeven moment de tussenmeter van HW, en die geeft in mijn weergaven een negatief getal wat rare uitkomsten geeft. Ter overweging dat in de blueprint vermelden?

[ Voor 29% gewijzigd door ArthurMorgan op 24-10-2025 10:27 ]

[Rik.]

Septillion schreef op donderdag 23 oktober 2025 @ 21:49:
@Rik. Voor de DNS challenge hoeft er niets open te staan.

Voor de http challenge moet je poort 80 extern naar poort 80 van HA open hebben staan, anders kan er niet verlengt worden.

Dus weet niet zo goed wat je bedoelt met "intern open laten".

Dank voor de hulp!
Het vreemde is nu wel dat ik intern de server niet kan bereiken via fictiefdomeinvoortweakers.duckdns.org, dit kon ik eerder wel gewoon.



Is dat iets wat in de instellingen aangepast kan worden?

[TheFes]

Rik. schreef op vrijdag 24 oktober 2025 @ 08:31:
[...]

Dank voor de hulp!
Het vreemde is nu wel dat ik intern de server niet kan bereiken via fictiefdomeinvoortweakers.duckdns.org, dit kon ik eerder wel gewoon.

[Afbeelding]

Is dat iets wat in de instellingen aangepast kan worden?

Daarvoor moet poort 80 wel geforward worden naar 8123.
Je moet even uitzoeken hoe de renewal van de certificaten werkt. Als daarvoor 80 > 80 nodig is, kun je dus niet zowel de renewal doen via fictiefdomeinvoortweakers.duckdns.org als HA bereiken via datzelfde domein. Je zult dan dus een 2e poort moeten forwarden naar 8123 en die gebruiken om HA te bereiken.

[Rik.]

TheFes schreef op vrijdag 24 oktober 2025 @ 08:53:
[...]


Daarvoor moet poort 80 wel geforward worden naar 8123.
Je moet even uitzoeken hoe de renewal van de certificaten werkt. Als daarvoor 80 > 80 nodig is, kun je dus niet zowel de renewal doen via fictiefdomeinvoortweakers.duckdns.org als HA bereiken via datzelfde domein. Je zult dan dus een 2e poort moeten forwarden naar 8123 en die gebruiken om HA te bereiken.

Het vreemde is dat het 3 maanden lang gewoon gewerkt heeft. Ik heb 80 -> 8123 open staan. Voor renewal kan ik eventueel 80 -> 80 openzetten, maar renewal is inmiddels al gelukt dus dat kan het niet zijn.

Dit is wat ik nu open heb staan:


Vind het bijzonder dat dit nu ineens dus zo werkt. Voorheen kon ik via 192.168.178.5 HA niet bereiken want dat moest allemaal via dat DuckDNS adres, maar nu is het dus andersom.

Edit: Nevermind, blijkbaar heeft dit tijd nodig. Ik had gisteren een instelling gewijzigd in configuration.yaml dat intern altijd via het IP kan en extern via het DuckDNS adres. Dit heb ik gisteren om 17:00 al weggehaald omdat dit voor nu nog niet is wat ik wil (wellicht later wel). Ondertussen HA al zeker 3x herstart, en toch nog steeds bereikbaar via IP. Nu net nog een herstart gedaan en nu werkt het weer zoals voorheen.

[ Voor 16% gewijzigd door Rik. op 24-10-2025 09:16 ]

[TheFes]

Rik. schreef op vrijdag 24 oktober 2025 @ 09:12:
[...]

Het vreemde is dat het 3 maanden lang gewoon gewerkt heeft. Ik heb 80 -> 8123 open staan. Voor renewal kan ik eventueel 80 -> 80 openzetten, maar renewal is inmiddels al gelukt dus dat kan het niet zijn.

Dit is wat ik nu open heb staan:
[Afbeelding]

Vind het bijzonder dat dit nu ineens dus zo werkt. Voorheen kon ik via 192.168.178.5 HA niet bereiken want dat moest allemaal via dat DuckDNS adres, maar nu is het dus andersom.

Het ging goed omdat je 80 > 8123 ingesteld had
Maar daarom ging de renewal niet goed.

Even voor de zekerheid, gebruikte je
http://fictiefdomeinvoortweakers.duckdns.org of https://fictiefdomeinvoortweakers.duckdns.org (http of https)

HA zou altijd via het interne adres bereikbaar moeten zijn, maar als je een ssl certificaat ingesteld hebt dan moet je intern ook https gebruiken, en dan de certificaatwaarschuwing negeren.

[ Voor 9% gewijzigd door TheFes op 24-10-2025 09:18 ]

[Rik.]

TheFes schreef op vrijdag 24 oktober 2025 @ 09:16:
[...]


Het ging goed omdat je 80 > 8123 ingesteld had
Maar daarom ging de renewal niet goed.

Even voor de zekerheid, gebruikte je
http://fictiefdomeinvoortweakers.duckdns.org of https://fictiefdomeinvoortweakers.duckdns.org (http of https)

Ik gebruikte het https adres
Ja die renewal is daardoor wel een dingetje idd, want dat zal over 3 maanden weer hetzelfde gaan... Toch vreemd dat het gisteren dan alsnog gelukt is ondanks dat ik niks aan de instellingen van portforwarding gewijzigd heb.

[TheFes]

Rik. schreef op vrijdag 24 oktober 2025 @ 09:17:
[...]

Ik gebruikte het https adres
Ja die renewal is daardoor wel een dingetje idd, want dat zal over 3 maanden weer hetzelfde gaan... Toch vreemd dat het gisteren dan alsnog gelukt is ondanks dat ik niks aan de instellingen van portforwarding gewijzigd heb.

Je zou 443 > 8123 kunnen gebruiken als je https gebruikt, 80 > 8123 is dan niet nodig.

[Rik.]

TheFes schreef op vrijdag 24 oktober 2025 @ 09:19:
[...]


Je zou 443 > 8123 kunnen gebruiken als je https gebruikt, 80 > 8123 is dan niet nodig.

Zooooo goedemorgen... Dat is idd ook waarom ik destijds ook 443 -> 8123 geopend had.

Weet je toevallig ook of er een manier is om intern 192.168.178.5 te gebruiken en extern het HTTPS DuckDNS adres?
Intern krijg ik nu toch echt deze foutmelding:


Is dat eigenlijk dan gewoon alleen dit in de configuration.yaml zetten?

code:

homeassistant:
  internal_url: "http://192.168.178.5:8123"
  external_url: "https://fictiefdomeinvoortweakers.duckdns.org"

[TheFes]

Rik. schreef op vrijdag 24 oktober 2025 @ 09:22:
[...]

Zooooo goedemorgen... Dat is idd ook waarom ik destijds ook 443 -> 8123 geopend had.

Weet je toevallig ook of er een manier is om intern 192.168.178.5 te gebruiken en extern het HTTPS DuckDNS adres?
Intern krijg ik nu toch echt deze foutmelding:
[Afbeelding]

Is dat eigenlijk dan gewoon alleen dit in de configuration.yaml zetten?

code:

homeassistant:
  internal_url: "http://192.168.178.5:8123"
  external_url: "https://fictiefdomeinvoortweakers.duckdns.org"

Dat hoeft sowieso niet in je configuration.yaml te staan, dat kun je ook in de GUI configeren.
Maar met je huidige setup zou je HA intern bereikbaar moeten zijn via https:// 192.168.178.5:8123.
Je krijgt dan een certificaatwaarschuwing en die moet je dan negeren. Dat werkt echter niet in de app, want die wil een geldig certificaat.

Wil je dat niet, dan zou je iets als Nginx Proxy Manager (NPM) kunnen gebruiken. Je stuurt in je router dan de externe verzoeken op poort 443 door naar NPM. NPM stuurt de verzoeken dan door naar http://192.168.178.5:8123
Je moet in HA dan wel een trusted_proxies instellen zodat HA weet dat verzoeken vanuit NPM toegestaan zijn, maar je hoeft in HA geen https te gebruiken, waardoor HA intern gewoon via http blijft werken.