Zendure producten in Home Assistant integreren deel 2

[YvonneVP]

Hippe Lip schreef op woensdag 22 april 2026 @ 21:25:
[...]

Jawel hoor, wel op mijn laatste vraag

Maar ik haalde mijn vraag van eerder op de dag aan en daarop kwam geen antwoord. Ervaring leert binnen een actief topic als dit dat er meestal nix meer komt als er niet binnen 2 uur is gereageerd. Dan is dat al zoveel pagina’s terug…

Toch verbaas ik me er nog steeds over dat hierover geen documentatie of toelichting ergens te vinden is.
Jammer, maat tis niet anders kennelijk.

Ik begrijp dat je graag extra documentatie wilt als alles compleet nieuw is voor je. Hetgeen @gielz en @gast777 doen is volledig in hun eigen tijd en op vrijwillige basis. Sommige dingen zijn ook na te vragen via bijvoorbeeld ChatGPT of Google. Dat zijn dus ook nog resources die je kunt gebruiken om verder te kunnen komen. Ik ben ook begonnen zonder enige kennis, en dat is nog niet zo heel lang terug. Ik heb ook vragen gesteld, maar meestal pas als ik zelf echt nergens iets tegen kwam zoals in de logs oid. En ja, ik kwam er ook wel eens achter dat ik gewoon verkeerd gekeken heb. Het is een leercurve waar iemand dan doorheen moet, en die is soms taai. Vanuit mijn ervaring leer je echter meer, en sneller, door eerst zelf echt te gaan zoeken en ChatGPT en/of Google in te zetten, dan de vragen op het forum te stellen en te wachten op een antwoord. Mijn leerkurve ging door het eerst zelf uit te zoeken, en te doorgronden, sneller. En ik weet dat dit voor ieder anders is. Het is dus ook slechts een tip die ik je kan geven, die gebaseerd is op mijn eigen ervaring. Documentatie, ook voor newbies is namelijk nog steeds geen garantie dat ook elke newbie het begrijpt. En juist omdat Gielz en Gast777 alles op vrijwillige basis doen, en ze zo te merken nog genoeg op hun bordje hebben liggen aan wensen en wijzigingen, lijkt het me dus handiger om ook andere mogelijkheden te gebruiken die voor iedereen toegankelijk zijn.

[YvonneVP]

hemertje schreef op woensdag 22 april 2026 @ 21:55:
[...]


@gielz
is het een idee dat je dit dashboard mbt schakelen van de offgrid contactdoos opneemt in je volgende versie tbv in/uitschakelen van eventuele externe ventilatoren?

De ventilator laten beginnen bij 35 graden is al best snel. En als je dan een ventilator hebt die je ook nog best goed hoort dan zou dat wel eens een irritant ventilatortje kunnen worden. Ik heb een ventilator gekocht die op de omvormer geplaatst is, en die dus automatisch begint te koelen als de temperatuur te hoog wordt. Als ik mijn batterijen flink aan het opladen ben dan kom ik in de buurt van 42 graden, maar dan begint de ventilator nog niet te blazen om te koelen. Misschien dat dit anders zal worden als mijn stapeltje batterijen verplaatst gaan worden naar de trapkast. En dan zal ik dus moeten zorgen dat warme lucht uit de trapkast wordt geblazen. Daar heb ik een ventilator voor gekocht die aangesloten wordt op een temperatuur controller met stopcontact. En op die controller kan ik dus een omgevingstemperatuur instellen zodat de ventilator zijn werk gaat doen als het nodig is. Ik heb daar dan dus geen omkijken naar en vind ik persoonlijk dus makkelijker dan wanneer ik elke keer moet kijken of ik misschien een ventilator toch maar aan moet zetten. Die temperatuur controller zou ik ook op de batterij aan kunnen sluiten, maar dat is dan uiteindelijk lood om oud ijzer omdat het verbruik minimaal zal zijn, en het dus nog niet eens om echte centen zal gaan die ik dan eventueel zou besparen. En aangezien ik aan het NOMmen ben zal die stroom uiteindelijk ook uit de batterij komen, maar heb ik niet het sluip verbruik omdat de off grid contactdoos actief is van de batterij. Die pakt namelijk altijd een minimum aan stroom uit de batterij, ongeacht of er iets op is aangesloten.

[YvonneVP]

Hippe Lip schreef op woensdag 22 april 2026 @ 22:46:
[...]

Dat kan, maar helaas negeer je de essentie van de vraag.

Misschien kan iemand anders me verder helpen?

Eigenlijk maakt het niets uit of je de prijzen incl. EB en btw gebruikt om te handelen, of ex EB en btw. Uiteindelijk gaat het om de winst die je wilt maken. Of een kale prijs nu met of zonder belastingen is. Als je inkoopt tegen prijs x dan wil je een bepaalde winst behalen, en niet slechts 2 of 3 cent. Het is dus uiteindelijk aan jouzelf wat je aan winst wilt behalen, of waar je tevreden mee bent. En dat is dus waar de minimale spread voor is, dan kun je namelijk zien hoe groot het verschil is tussen inkoop en verkoop op die dag op basis van de goedkoper en dure uren. Is dit een antwoord op je vraag?

[Gerritdh1991]

Devke schreef op vrijdag 1 mei 2026 @ 20:33:
[...]

Doel je hierop?

[Afbeelding]

Klopt inderdaad! Dat lijkt dus niet te gebeuren.

[Devke]

Gerritdh1991 schreef op zaterdag 2 mei 2026 @ 15:09:
[...]


Klopt inderdaad! Dat lijkt dus niet te gebeuren.

Ik test regelmatig de @gielz integratie maar volgens mij is dit meer een mededeling dat er begrepen wordt dat de omvormer zal ingrijpen als hij boven een bepaalde temperatuur komt. Zover ik weet zit dit niet in de integratie dat het vandaar uit gebeurd. Of ik moet hebben zitten slapen , wat ook zomaar kan

Edit: Het BMS van de batterij regelt dit.

[ Voor 6% gewijzigd door Devke op 02-05-2026 16:01 ]

[koboy]

YvonneVP schreef op zaterdag 2 mei 2026 @ 15:00:
[...]

Eigenlijk maakt het niets uit of je de prijzen incl. EB en btw gebruikt om te handelen, of ex EB en btw. Uiteindelijk gaat het om de winst die je wilt maken. Of een kale prijs nu met of zonder belastingen is. Als je inkoopt tegen prijs x dan wil je een bepaalde winst behalen, en niet slechts 2 of 3 cent. Het is dus uiteindelijk aan jouzelf wat je aan winst wilt behalen, of waar je tevreden mee bent. En dat is dus waar de minimale spread voor is, dan kun je namelijk zien hoe groot het verschil is tussen inkoop en verkoop op die dag op basis van de goedkoper en dure uren. Is dit een antwoord op je vraag?

Als je kijkt naar de te maken winst in centen dan maakt kaal of inclusief nu niet zo veel (beetje BTW) uit.
Probleem zit alleen in de RTE van je systeem, die is geen 100% en wordt gerekend in procenten. Daardoor moet je rekenen met de daadwerkelijke totale kosten, zeker dit jaar en volgend jaar ook op de paar momenten dat je gaat laden vanaf het net.

[MikeyMan]

gielz schreef op zaterdag 2 mei 2026 @ 09:40:
[...]


Alleen bij de originele, bij de gielz kun je dit na installatie invullen. Voor de zendure p1 heb je beide de rest code nodig. Bij gielz in combinatie met je homewizard p1 alleen je ip-adres

Misschien heeft iemand anders er nog iets aan. Maar als je de p1 meter wilt toevoegen kun je op de drie puntjes drukken en dan voor herconfigureer kiezen. Je kunt daar de p1 meter selecteren en herstarten.

[m-vw]

koboy schreef op vrijdag 1 mei 2026 @ 11:07:
[...]


Wat je benoemt is de grote uitdaging waar we allemaal voor staan, maar is met wat knutselwerk in HA op te lossen mits je PV omvormer regelbaar is in HA.

Ikzelf het voor een "eenvoudiger" oplossing gekozen: een over gedimensioneerd accu die de meestal maar 4 negatieve uren aan PV productie kan opvangen. 5 lukt vrij zeker ook nog wel.
Overschot wordt dan duur gedumpt in de avond.
Voordeel: technisch eenvoudiger omdat ik maar 1 apparaat (accu) hoef te sturen. Ook heb ik wanneer ik dat wil extra capaciteit direct bij te schakelen staan.
Nadeel: financieel levert het uitgesteld terugleveren van het overschoot veel minder op. Mijn bierviltje zegt ongeveer de helft.

Ik heb ook gedacht aan extra accu's. Maar die krijg ik in de zomer, waarschijnlijk, niet leeg en in de winter niet vol. Heb nu 3,2kwh op het dak en daar komt dit jaar nog wel iets bij, maar niet genoeg om 's winters 4/5/6 accu's te vullen.

Belangrijk om te weten is dat ik op een vast contract zit en dus niets doe met dynamische prijzen maar puur ga voor NOM.

[koboy]

m-vw schreef op zaterdag 2 mei 2026 @ 20:09:
[...]


Ik heb ook gedacht aan extra accu's. Maar die krijg ik in de zomer, waarschijnlijk, niet leeg en in de winter niet vol. Heb nu 3,2kwh op het dak en daar komt dit jaar nog wel iets bij, maar niet genoeg om 's winters 4/5/6 accu's te vullen.

Belangrijk om te weten is dat ik op een vast contract zit en dus niets doe met dynamische prijzen maar puur ga voor NOM.

Met vast is het helemaal simpel qua capaciteit: genoeg om de NOM te kunnen houden 8 v/d 12 maanden inclusief (ont)laadverliezen. Zou zelf dan wat maar boven afronden om slijtage op te kunnen vangen.

[Hippe Lip]

YvonneVP schreef op zaterdag 2 mei 2026 @ 14:06:
[...]

Probeer ChatGPT eens, of gewoon Google zou waarschijnlijk ook de nodige informatie kunnen geven wat 'spread' inhoud in de energiemarkt bij het gebruik van batterijen.

Ik ben inmiddels een stuk verder in het begrip en denk dat ik het in de zomer niet nodig heb. Ik heb vooral een flink overschot aan PV, dus loopt mijn accu overdag vol en stel ik de duurste uren in om ‘m weer te legen.
Jammer dat dit (nog) niet kan door simpelweg te zeggen dat ik de 8 duurste kwartieren tussen (bijvoorbeeld) 8 ‘s avonds en 8 in de ochtend wil ontladen. Als je met aantal wil werken, dan lopen die over de hele dag, dus ook de ochtend ervóór. In de winter werkt dat misschien, maar niet in de zomer.

Komend najaar en zeker in de winter dan heb ik die spread wel nodig omdat PV dan niet genoeg oplevert om het etmaal door te komen. Tegen die tijd ga ik me er verder in verdiepen.
Maar dank voor je suggestie, @YvonneVP

[ctrl-tab]

Hippe Lip schreef op zaterdag 2 mei 2026 @ 23:59:
[...]

Ik ben inmiddels een stuk verder in het begrip en denk dat ik het in de zomer niet nodig heb. Ik heb vooral een flink overschot aan PV, dus loopt mijn accu overdag vol en stel ik de duurste uren in om ‘m weer te legen.
Jammer dat dit (nog) niet kan door simpelweg te zeggen dat ik de 8 duurste kwartieren tussen (bijvoorbeeld) 8 ‘s avonds en 8 in de ochtend wil ontladen. Als je met aantal wil werken, dan lopen die over de hele dag, dus ook de ochtend ervóór. In de winter werkt dat misschien, maar niet in de zomer.

Komend najaar en zeker in de winter dan heb ik die spread wel nodig omdat PV dan niet genoeg oplevert om het etmaal door te komen. Tegen die tijd ga ik me er verder in verdiepen.
Maar dank voor je suggestie, @YvonneVP

Overweeg een integratie met homeassistant.
Precies wat je noemt kan met de AIO energy management integration

[Hippe Lip]

YvonneVP schreef op zaterdag 2 mei 2026 @ 14:16:
[...]

Ik begrijp dat je graag extra documentatie wilt als alles compleet nieuw is voor je. Hetgeen @gielz en @gast777 doen is volledig in hun eigen tijd en op vrijwillige basis. Sommige dingen zijn ook na te vragen via bijvoorbeeld ChatGPT of Google. Dat zijn dus ook nog resources die je kunt gebruiken om verder te kunnen komen. Ik ben ook begonnen zonder enige kennis, en dat is nog niet zo heel lang terug. Ik heb ook vragen gesteld, maar meestal pas als ik zelf echt nergens iets tegen kwam zoals in de logs oid. En ja, ik kwam er ook wel eens achter dat ik gewoon verkeerd gekeken heb. Het is een leercurve waar iemand dan doorheen moet, en die is soms taai. Vanuit mijn ervaring leer je echter meer, en sneller, door eerst zelf echt te gaan zoeken en ChatGPT en/of Google in te zetten, dan de vragen op het forum te stellen en te wachten op een antwoord. Mijn leerkurve ging door het eerst zelf uit te zoeken, en te doorgronden, sneller. En ik weet dat dit voor ieder anders is. Het is dus ook slechts een tip die ik je kan geven, die gebaseerd is op mijn eigen ervaring. Documentatie, ook voor newbies is namelijk nog steeds geen garantie dat ook elke newbie het begrijpt. En juist omdat Gielz en Gast777 alles op vrijwillige basis doen, en ze zo te merken nog genoeg op hun bordje hebben liggen aan wensen en wijzigingen, lijkt het me dus handiger om ook andere mogelijkheden te gebruiken die voor iedereen toegankelijk zijn.

Je hebt natuurlijk helemaal gelijk, @YvonneVP. Er wordt door @gielz en @gast777 ongelooflijk veel en vooral fraai werk geleverd. En de documentatie díé er is is ook niet verkeerd.

Het was meer de frustratie van de first-time user die eerst alles van die twee in een vloek en een zucht kan installeren, maar als het daarna op aanpassen of updaten aankomt, dan voel je je als in het donker in onbekende omgeving.
Ik kom wel over die frustratie heen hoor en het is zeker geen aanmerking aan de makers, maar soms moet het er even uit.

[Hippe Lip]

ctrl-tab schreef op zondag 3 mei 2026 @ 00:00:
Overweeg een integratie met homeassistant.
Precies wat je noemt kan met de AIO energy management integration

Ehhh, AIO? Of bedoel je DAO misschien, @ctrl-tab?

Die laatste staat op mijn lijstje om te gaan volgen, hier op dit platform, maar het ontbreekt me aan tijd om alles tegelijk te volgen. Ik lees nu een aantal topics over thuisbatterijen en probeer eerst mijn twee Zendure stacks een beetje in de vingers te krijgen.
Als ik daar meer op thuis ben dan is er wellicht tijd om DAO te volgen.

[Hippe Lip]

YvonneVP schreef op zaterdag 2 mei 2026 @ 15:00:
Eigenlijk maakt het niets uit of je de prijzen incl. EB en btw gebruikt om te handelen, of ex EB en btw. Uiteindelijk gaat het om de winst die je wilt maken. Of een kale prijs nu met of zonder belastingen is. Als je inkoopt tegen prijs x dan wil je een bepaalde winst behalen, en niet slechts 2 of 3 cent. Het is dus uiteindelijk aan jouzelf wat je aan winst wilt behalen, of waar je tevreden mee bent. En dat is dus waar de minimale spread voor is, dan kun je namelijk zien hoe groot het verschil is tussen inkoop en verkoop op die dag op basis van de goedkoper en dure uren. Is dit een antwoord op je vraag?

Toch begin ik langzaamaan te beseffen (ik ben een trage denker) dat het wel uitmaakt en dat je de totale prijs moet hebben, inclusief EB, BTW en toeslag. Die spread heb je nodig om de verliezen te compenseren en die verliezen zitten ook in de EB, BTW en toeslag. Tenminste als je het hebt over in- en verkoop. Niet als je de batterijen vanuit je PV vult, want das andere koek.

[ctrl-tab]

Hippe Lip schreef op zondag 3 mei 2026 @ 00:10:
[...]

Ehhh, AIO? Of bedoel je DAO misschien, @ctrl-tab?

Die laatste staat op mijn lijstje om te gaan volgen, hier op dit platform, maar het ontbreekt me aan tijd om alles tegelijk te volgen. Ik lees nu een aantal topics over thuisbatterijen en probeer eerst mijn twee Zendure stacks een beetje in de vingers te krijgen.
Als ik daar meer op thuis ben dan is er wellicht tijd om DAO te volgen.

Nee, aio energy management. Google het eens..

[Hippe Lip]

ctrl-tab schreef op zondag 3 mei 2026 @ 00:20:
[...]


Nee, aio energy management. Google het eens..

Das niet hier op Tweakers present? Ik zocht er net even op maar kwam geen topic tegen over AIO energy managment.

[ctrl-tab]

Hippe Lip schreef op zondag 3 mei 2026 @ 00:25:
[...]

Das niet hier op Tweakers present? Ik zocht er net even op maar kwam geen topic tegen over AIO energy managment.

Nee maar sommigen hier gebruiken het. Goed, denk dat dit voor het HA draadje bedoeld is.

https://github.com/kotope/aio_energy_management

[Pakhaas]

Hippe Lip schreef op zondag 3 mei 2026 @ 00:15:
[...]

Toch begin ik langzaamaan te beseffen (ik ben een trage denker) dat het wel uitmaakt en dat je de totale prijs moet hebben, inclusief EB, BTW en toeslag. Die spread heb je nodig om de verliezen te compenseren en die verliezen zitten ook in de EB, BTW en toeslag. Tenminste als je het hebt over in- en verkoop. Niet als je de batterijen vanuit je PV vult, want das andere koek.

Dat zei ik een week geleden ook, maar wilde je niet aannemen.

Vanuit de PV reken je ook met het all in tarief, want die krijg je er ook voor als je direct vanuit je PV teruglevert zonder op te slaan in batterij. Zonder de RTE verliezen. Dus dat is de "prijs" die je moet betalen.

Bijv als het niet goedkoop of duur is, wil je de PV niet opslaan in de batterij maar direct naar het net, omdat je er een redelijke prijs voor krijgt zonder RTE verliezen.

[gast777]

Voor de Gielz+Proxy gebruikers die graag de offgrid sockets willen kunnen schakelen vanuit Home Assistant, dat is nu beschikbaar.

Zie https://github.com/gast77...#nieuw-in-versie-20260503

[ Voor 41% gewijzigd door gast777 op 03-05-2026 10:11 ]

[gast777]

Voor de liefhebbers, dit is ook voor de Gielz zonder Proxy beschikbaar (proxy specifieke delen verwijderd). Zet dan dit in een package of configuration.yaml:

NL versie:

YAML:

template:

  - switch:
      - name: "Zendure Offgrid Socket"
        unique_id: zendure_offgrid_socket
        state: >
          {{ 'on' if is_state('sensor.zendure_2400_ac_offgrid_modus', 'Normaal') else 'off' }}
        icon: mdi:power-socket-de
        turn_on:
          - service: rest_command.set_zendure_offgrid_socket_on
        turn_off:
          - service: rest_command.set_zendure_offgrid_socket_off

rest_command:

  set_zendure_offgrid_socket_on:
    url: "http://{{ states('input_text.zendure_2400_ac_ip_adres') }}/properties/write"
    method: POST
    content_type: "application/json"
    payload: >
      {
        "sn": "{{ states('sensor.zendure_2400_ac_serienummer') }}",
        "properties": {
          "gridOffMode": 0
        }
      }

  set_zendure_offgrid_socket_off:
    url: "http://{{ states('input_text.zendure_2400_ac_ip_adres') }}/properties/write"
    method: POST
    content_type: "application/json"
    payload: >
      {
        "sn": "{{ states('sensor.zendure_2400_ac_serienummer') }}",
        "properties": {
          "gridOffMode": 2
        }
      }

EN versie:

YAML:

template:

  - switch:
      - name: "Zendure Offgrid Socket"
        unique_id: zendure_offgrid_socket
        state: >
          {{ 'on' if is_state('sensor.zendure_offgrid_mode', 'Normal') else 'off' }}
        icon: mdi:power-socket-de
        turn_on:
          - service: rest_command.set_zendure_offgrid_socket_on
        turn_off:
          - service: rest_command.set_zendure_offgrid_socket_off

rest_command:

  set_zendure_offgrid_socket_on:
    url: "http://{{ states('input_text.zendure_setting_ip_address') }}/properties/write"
    method: POST
    content_type: "application/json"
    payload: >
      {
        "sn": "{{ states('sensor.zendure_serial_number') }}",
        "properties": {
          "gridOffMode": 0
        }
      }

  set_zendure_offgrid_socket_off:
    url: "http://{{ states('input_text.zendure_setting_ip_address') }}/properties/write"
    method: POST
    content_type: "application/json"
    payload: >
      {
        "sn": "{{ states('sensor.zendure_serial_number') }}",
        "properties": {
          "gridOffMode": 2
        }
      }

NB: Deze werkt ook met de Proxy, maar dan zal de schakelaar alle offgrid sockets tegelijk schakelen.

[gast777]

Mocht je ergens tegenaan lopen dan hoor ik het graag (bijv via DM).

[TBird484]

gast777 schreef op zondag 3 mei 2026 @ 09:43:
Voor de Gielz+Proxy gebruikers die graag de offgrid sockets willen kunnen schakelen vanuit Home Assistant, dat is nu beschikbaar.

Goed bezig!
Dank voor deze mooie nieuwe feature.

[TBird484]

In de history van de calibrating sensors, die via de proxy code worden geleverd, is te zien dat deze voor mijn 3 AC2400+ omvormers altijd op no blijven staan.
Op het Gielz dashboard worden in de calibratiegrafiek de keren dat er tot 100% is opgeladen afgebeeld als groen. Hoe kan ik nu controleren of er daadwerkelijk calibratie heeft plaatsgevonden ?

[MikeyMan]

@gast777 nu nog een manier om bij een power outage de Sockets aan te zetten en minimale soc naar 0 te zetten. Die backup functionaliteit werkt vrij matig op deze manier

[gast777]

TBird484 schreef op zondag 3 mei 2026 @ 11:13:
In de history van de calibrating sensors, die via de proxy code worden geleverd, is te zien dat deze voor mijn 3 AC2400+ omvormers altijd op no blijven staan.
Op het Gielz dashboard worden in de calibratiegrafiek de keren dat er tot 100% is opgeladen afgebeeld als groen. Hoe kan ik nu controleren of er daadwerkelijk calibratie heeft plaatsgevonden ?

Die 'Kalibratie bezig' sensor is de Zendure "socStatus" property. Die is normaliter "0". Voor zover ik weet gaat die op "1" wanneer een geforceerde kalibratie run bezig is. Dat gebeurt als hij een maand niet de 100% SoC heeft gehaald. Zo'n run heb ik persoonlijk hier niet meegemaakt sinds die sensor bestaat, dus ik heb hem nog nooit op "1" zien staan, dus weet ook niet 100% zeker of die werkt. Je kunt dat ook niet forceren om te testen.

Het staat los van de kalibratie die Gielz bijhoudt, die bijhoudt wanneer de Zendure voor het laastst op 100% SoC heeft gestaan.

[TBird484]

gast777 schreef op zondag 3 mei 2026 @ 11:25:
[...]

Die 'Kalibratie bezig' sensor is de Zendure "socStatus" property. Die is normaliter "0". Voor zover ik weet gaat die op "1" wanneer een geforceerde kalibratie run bezig is. Dat gebeurt als hij een maand niet de 100% SoC heeft gehaald. Zo'n run heb ik persoonlijk hier niet meegemaakt sinds die sensor bestaat, dus ik heb hem nog nooit op "1" zien staan, dus weet ook niet 100% zeker of die werkt. Je kunt dat ook niet forceren om te testen.

Het staat los van de kalibratie die Gielz bijhoudt, die bijhoudt wanneer de Zendure voor het laastst op 100% SoC heeft gestaan.

Ok, helder. Komt er dus op neer dat we BMS vertrouwen dat het z'n werk doet en dat er geen manier is om dit te controleren.

[gast777]

MikeyMan schreef op zondag 3 mei 2026 @ 11:18:
@gast777 nu nog een manier om bij een power outage de Sockets aan te zetten en minimale soc naar 0 te zetten. Die backup functionaliteit werkt vrij matig op deze manier

Als bij een power outage je Home Assistant en je netwerk blijft werken (bijv via UPS), dan kan dat nu door middel van deze schakelaar prima via HA automatisch geregeld worden middels een automation.

Als dat niet zo is, dan kunnen we niets doen op dat moment vanuit HA. Dan ben je simpelweg te laat. Dan kun je nog overwegen om de sockets gewoon altijd aan te laten staan.

Of gewoon op dat moment naar het apparaat lopen en via de App en bluetooth de socket aanzetten en minimale soc omlaag. Je wilt dan toch waarschijnlijk een verlengsnoer/haspel erop aansluiten.

[YvonneVP]

..Christiaan.. schreef op zondag 26 april 2026 @ 22:43:
[...]


Ik heb deze van je gebruikt en met wat aanpassingen werkt het in mijn situatie. Claude heeft dat voor mij geregeld.
Die gaf mij wel dit terug over jouw aanpak:

[...]

Herken je dit?

Ik heb dit nu als resultaat:

Kale Nordpool prijs + Zonneplan opslag (1,653 ct) × BTW (21%) + energiebelasting (11,08 ct). De Norpool sensor uit Chielz komt bij mij nu overeen met de Zonneplanprijs. Wat weer handig is om een automatisering hierop af te stemmen.
Hoe zie jij trouwens de zonneplanprijzen met cijfers achter de komma? Ik zie alleen maar prijzen in hele centen in de Zonneplan app...

Bij het instellen van Nordpool heb je waarschijnlijk een vinkje gezet bij 'centen'. Ik zie dus 0.xxxx Ik had het helemaal inhet begin ook in centen staan, maar dat was toch best verwarrend vond ik. Kwartierprijzen kun je in Nordpool uitvinken, waardoor uurprijzen worden berekend. Claude heeft dus niet helemaal gelijk. Vandaar dat ik Nordpool opnieuw ingesteld heb waardoor ik dus 0.xxx al waarde krijg. Ik heb dus niets zelf gedaan om de berekening te maken, en dus slechts de instellingen voor Nordpool ingesteld om de juiste Zonneplan tarieven te krijgen, natuurlijk wel met de 'additional_costs template' gevuld met de code
{% set p = current_price | float(0) %}
{% set opslag = 0.01653 %}
{% set vat = 1.21 %}
{% set energiebelasting = 0.1108 %}
{{ ( ((p + opslag) * vat + energiebelasting) - p ) | float }}

[ Voor 3% gewijzigd door YvonneVP op 03-05-2026 12:34 ]

[..Christiaan..]

Top, ik ga hiermee aan de slag. Dank je wel!

[koboy]

..Christiaan.. schreef op zondag 3 mei 2026 @ 12:38:
Top, ik ga hiermee aan de slag. Dank je wel!

Ik zou de Nordpool gewoon op kwartieren laten staan. In Gielz zit een schuifje om om te rekenen naar uurtarieven. Scheelt je foutgevoelig het configureren van Nordpool als zonneplan over gaat

[YvonneVP]

ppaulv schreef op maandag 27 april 2026 @ 19:23:
@YvonneVP denk dat ik inderdaad zoiets moet gaan doen als jij aangeeft. Heb gisteren mijn dynamisch contract bij Zonneplan gecancelled omdat ik me realiseerde dat ik op een zonnige dag, ná het vullen van mijn eerst lege accu, nog zo'n 15 kWh naar het grid stuur, tegen een negatieve koopprijs dus positieve leverprijs plus belasting etc. Dat zou me zo'n 7,- per dag kosten schat ik even snel. En ik ben nog niet zover dat ik m'n SolarEdge automatisch kan laten 'dimmen'. Dat wil ik eerst in orde brengen voordat ik op dynamisch overga.
De omvormer hard met een schakelaar / zekerautomaat uitknallen is erg ongezond voor de omvormer heb ik begrepen en dat ga ik dus niet doen. Jij wel?

Als de prijzen negatief zijn, zoals afgelopen week, dan zet ik mijn zonnepanelen even tijdelijk uit. Dan laad ik mijn batterijen op, en als je de Zendure op een aparte groep hebt zitten dan kun je tot 2400 W opladen, en zodra óf de negatieve prijsperiode voorbij is óf de batterij volgeladen is, dan zet ik mijn panelen weer aan. Dan zal de Zendure niet gaan ontladen omdat je dan natuurlijk je zonnestroom nog hebt om te gebruiken. Pas als de zonnepanelen geen stroom meer leveren einde middag begin avond, zal dan de stroom van je batterijen gebruikt worden. En dan kun je dus lekker NOMmen, en de stroom gebruiken die je overdag heel goedkoop van het net hebt gehaald (vanwege de negatieve prijs). Ik zou het liefst bij dat soort momenten de Zonnestroom terugleveren aan het net, maar wel de goedkope stroom met negatieve prijs in mijn batterij proppen. Ik weet niet of daar een oplossing voor is, of voor is te verzinnen. Ik weet ook niet of er misschien andere mensen hier al een oplossing voor hebben.

[YvonneVP]

R.K schreef op maandag 27 april 2026 @ 22:32:
[...]

Ik weet niet welke Solaredge omvormer je hebt, maar ik kon op mijn SE3500 verbinding maken via de modbus en heb ook active power control aangezet, dat geeft je de mogelijkheid om in HA bij negatieve prijzen de omvormer (softwarematig) naar 0 te zetten. Werkte gisteren prima hier. Als je wilt weten hoe moet je maar even een p.m. sturen anders gaan we wellicht teveel offtopic.

Ik heb een SolarEdge SE3000. En wil ook wel weten hoe ik via HA dat kan doen, en dus de zonneproductie bij negatieve prijzen op 0 kan zetten. Nu zet ik mijn zonnepanelen ouderwets uit, zowel in de meterkast als op de omvormer.

[ppaulv]

gast777 schreef op zondag 3 mei 2026 @ 10:47:
Mocht je ergens tegenaan lopen dan hoor ik het graag (bijv via DM).

Interessant!

[ppaulv]

YvonneVP schreef op zondag 3 mei 2026 @ 13:40:
[...]

Ik heb een SolarEdge SE3000. En wil ook wel weten hoe ik via HA dat kan doen, en dus de zonneproductie bij negatieve prijzen op 0 kan zetten. Nu zet ik mijn zonnepanelen ouderwets uit, zowel in de meterkast als op de omvormer.

Zie mijn reactie van 1 mei 14.50 uur. Meen me te herinneren dat daarvoor nodig is dat je beheer rechten hebt op jouw 'site' van solaredge maar dat weet ik niet zeker.
En integratie solaredge modbus multi

[ Voor 3% gewijzigd door ppaulv op 03-05-2026 13:53 ]

[MikeyMan]

gast777 schreef op zondag 3 mei 2026 @ 11:39:
[...]

Of gewoon op dat moment naar het apparaat lopen en via de App en bluetooth de socket aanzetten en minimale soc omlaag. Je wilt dan toch waarschijnlijk een verlengsnoer/haspel erop aansluiten.

Wordt dat inmiddels ondersteund dan? Volgens mij trapt ie daar niet in... Maar eens proberen straks...

[gielz]

MikeyMan schreef op zondag 3 mei 2026 @ 13:58:
[...]


Wordt dat inmiddels ondersteund dan? Volgens mij trapt ie daar niet in... Maar eens proberen straks...

Werkt gewoon, geen reden om onnodig de offgrid aan te houden. Als je telefoon geen 5g of wifi meer heeft en je gaat bij je zendure app naar devices. Dan kun je daar direct bluetooth connection maken.

[gielz]

TBird484 schreef op zondag 3 mei 2026 @ 11:13:
In de history van de calibrating sensors, die via de proxy code worden geleverd, is te zien dat deze voor mijn 3 AC2400+ omvormers altijd op no blijven staan.
Op het Gielz dashboard worden in de calibratiegrafiek de keren dat er tot 100% is opgeladen afgebeeld als groen. Hoe kan ik nu controleren of er daadwerkelijk calibratie heeft plaatsgevonden ?

Zodra ze 30 dagen niet tot 100% zijn opgeladen springt deze sensor op “yes”. Vervolgens blokkeert je Zendure en kun je niets meer totdat deze op 100% komt of het 24:00 is (laatste is een bug). Hier al gezien in de winter.

De kalibratie grafiek toont je de momenten dat de 100% is gehaald. Er vind dan altijd kalibratie plaats.

[ppaulv]

gast777 schreef op zondag 3 mei 2026 @ 10:47:
Mocht je ergens tegenaan lopen dan hoor ik het graag (bijv via DM).

werkt als een zonnetje! Kudo's !

[smetzie]

Hoi allen,

Ik lees al een tijdje mee op dit forum en na aanschaf van de Zendure pro; toch aan de slag gegaan met de integratie van gielz. Wat er prachtig uitziet; alleen krijg ik het niet werkend (ondanks dit forum doorzoeken en de readme file te doorlezen). Hopelijk kunnen jullie even meekijken.

Tweetal 'problemen'
- Naast het kopje 'aansturen' staat de P1 meter continu op 0 (terwijl deze wel waarde geeft bij de instellingen tab).
- De grafieken van dynamisch vandaag/morgen blijven leeg; ik heb unknow weggehaald en de sensor van Nordpool toegevoegd. Deze geeft ook een waarde bij het instellingen tab.

Onderstaand de screens.






Alvast dank voor jullie hulp.

[YvonneVP]

NiCNCo schreef op dinsdag 28 april 2026 @ 10:23:
[...]


Het gebruikt de zonneplan P1 meter enitities inderdaad. Dus mocht je die ook hebben hoef je niks te doen anders dan manual dashboard card aan te maken met de volgende yaml. code in de card text editer.

[Afbeelding]

type: custom:vertical-stack-in-card
cards:
- type: horizontal-stack
cards:
- square: false
type: grid
columns: 2
cards:
- type: custom:mushroom-title-card
title: Stroom kosten
subtitle: vandaag
card_mod:
style: |
ha-card { padding: 6px 0px 0px 0px !important; }
.title { line-height: 1.2; }
.subtitle { margin-top: -8px; line-height: 1.1; opacity: 0.85; }
- type: custom:mushroom-title-card
title: >
{% set d =
states('sensor.zonneplan_electricity_delivery_costs_today') |
float(0) %} {% set p =
states('sensor.zonneplan_electricity_production_costs_today') |
float(0) %} € {{ (d - p) | round(2) }}
card_mod:
style: |
ha-card { padding: 6px 0px 0px 0px !important; }
.title {
text-align: right;
font-size: 52px!important;
line-height: 1;
}
style: |
ha-card { border: none; }
- type: horizontal-stack
card_mod:
style: |
:host { margin-top: -22px; }
cards:
- square: false
type: grid
columns: 3
cards:
- type: custom:mushroom-title-card
title: VERBRUIK
subtitle: >
{% set c =
states('sensor.zonneplan_electricity_consumption_today') |
float(0) %} {{ c | round(1) }} kWh x {{
((states('sensor.zonneplan_electricity_delivery_costs_today') |
float(0) / c * 100) | round(0)) if c > 0 else 0 }} ct
card_mod:
style: |
ha-card { padding: 10px !important; }
.title {
font-size: 11px!important;
color: #FFFFFF!important;
font-weight: 400!important;
line-height: 1.2;
}
.subtitle {
color: #FFFFFF!important;
margin-top: -6px;
line-height: 1.1;
}
- type: custom:mushroom-title-card
title: TERUGLEVERING
subtitle: >
{% set r = states('sensor.zonneplan_electricity_returned_today') |
float(0) %} {{ r | round(1) }} kWh x {{
((states('sensor.zonneplan_electricity_production_costs_today') |
float(0) / r * 100) | round(0)) if r > 0 else 0 }} ct
card_mod:
style: |
ha-card { padding: 10px !important; }
.title {
font-size: 11px!important;
color: #FFFFFF!important;
text-align: center;
font-weight: 400!important;
line-height: 1.2;
}
.subtitle {
text-align: center!important;
color: #FFFFFF!important;
margin-top: -6px;
line-height: 1.1;
}
- type: custom:mushroom-title-card
title: HUIDIG TARIEF
subtitle: >
{{ (states('sensor.zonneplan_current_electricity_tariff') |
float(0) * 100) | round(0) }} ct
card_mod:
style: |
ha-card { padding: 10px !important; }
.title {
font-size: 11px!important;
color: #FFFFFF!important;
text-align: right;
font-weight: 400!important;
line-height: 1.2;
}
.subtitle {
text-align: right!important;
color: #FFFFFF!important;
margin-top: -6px;
line-height: 1.1;
}
style: |
ha-card { border: none; }
card_mod:
style: |
ha-card {
background-color: #00A964;
--primary-text-color: #FFFFFF;
--secondary-text-color: #FFFFFF;
border-radius: 22px;
padding: 10px 12px 10px 12px;
}

Intressante kaart omdat ik ook Zonneplan als leverancier heb. Ik heb de Zonneplan integratie, maar toch mis ik bijvoorbeeld de entiteit snesor.zonneplan_electricity_production_costs_today terwijl deze wel tot de standaard zou horen. Enig idee waarom o.a. die sensor niet meekomt bij de installatie?

[gast777]

smetzie schreef op zondag 3 mei 2026 @ 16:11:
Hoi allen,

Ik lees al een tijdje mee op dit forum en na aanschaf van de Zendure pro; toch aan de slag gegaan met de integratie van gielz. Wat er prachtig uitziet; alleen krijg ik het niet werkend (ondanks dit forum doorzoeken en de readme file te doorlezen). Hopelijk kunnen jullie even meekijken.

Tweetal 'problemen'
- Naast het kopje 'aansturen' staat de P1 meter continu op 0 (terwijl deze wel waarde geeft bij de instellingen tab).

Alvast dank voor jullie hulp.

Je hebt "Afwijkende P1 Sensor" niet ingevuld. In plaats daarvan heb je zo te zien dat veld verwijderd van het dashboard en de P1 entiteit daar neergezet.

Dus even Afwijkende P1 Sensor veld terugzetten en invullen met de naam van je P1 sensor (sensor.xxxx).

Deze dus:

[ Voor 16% gewijzigd door gast777 op 03-05-2026 16:20 ]

[R1chardTM]

smetzie schreef op zondag 3 mei 2026 @ 16:11:
Hoi allen,

Ik lees al een tijdje mee op dit forum en na aanschaf van de Zendure pro; toch aan de slag gegaan met de integratie van gielz. Wat er prachtig uitziet; alleen krijg ik het niet werkend (ondanks dit forum doorzoeken en de readme file te doorlezen). Hopelijk kunnen jullie even meekijken.

Tweetal 'problemen'
- Naast het kopje 'aansturen' staat de P1 meter continu op 0 (terwijl deze wel waarde geeft bij de instellingen tab).
- De grafieken van dynamisch vandaag/morgen blijven leeg; ik heb unknow weggehaald en de sensor van Nordpool toegevoegd. Deze geeft ook een waarde bij het instellingen tab.

Onderstaand de screens.


[Afbeelding]

[Afbeelding]

Alvast dank voor jullie hulp.

Wat mij meteen opvalt is dat de modus op standby staat, zie eerste screenshot linksboven. Dan gaat er niets gebeuren, kies daar de gewenste modus. En het lijkt er ook op dat je iets geks gedaan hebt met de afwijkende P1 sensor. Dat veld ziet er bij mij uit als een invul veld. Lijkt er wel op als of je die entiteit heb zitten aanpassen, in plaats van in de UI het veld invullen met de naam van jouw P1 sensor.

Zo zien die twee dingen er bij mij uit.

[ Voor 27% gewijzigd door R1chardTM op 03-05-2026 16:29 ]

[smetzie]

R1chardTM schreef op zondag 3 mei 2026 @ 16:18:
[...]


Wat mij meteen opvalt is dat de modus op standby staat, zie eerste screenshot linksboven. Dan gaat er niets gebeuren, kies daar de gewenste modus. En het lijkt er ook op dat je iets geks gedaan hebt met de afwijkende P1 sensor. Dat veld ziet er bij mij uit als een invul veld. Lijkt er wel op als of je die entiteit heb zitten aanpassen, in plaats van in de UI het veld invullen met de naam van jouw P1 sensor.

Zo zien die twee dingen er bij mij uit.
[Afbeelding]

[Afbeelding]

Thanks; ik had idd dat veld aangepast. De P1 geeft nu een waarde.

Misschien heb ik zoiets soortgelijks gedaan voor de dynamisch vandaag/morgen grafieken.

[gast777]

smetzie schreef op zondag 3 mei 2026 @ 16:33:
[...]


Thanks; ik had idd dat veld aangepast. De P1 geeft nu een waarde.

Misschien heb ik zoiets soortgelijks gedaan voor de dynamisch vandaag/morgen grafieken.

Klopt inderdaad. Dit veld even terugzetten en invullen:

[Devke]

smetzie schreef op zondag 3 mei 2026 @ 16:11:
Hoi allen,

Ik lees al een tijdje mee op dit forum en na aanschaf van de Zendure pro; toch aan de slag gegaan met de integratie van gielz. Wat er prachtig uitziet; alleen krijg ik het niet werkend (ondanks dit forum doorzoeken en de readme file te doorlezen). Hopelijk kunnen jullie even meekijken.

Tweetal 'problemen'
- Naast het kopje 'aansturen' staat de P1 meter continu op 0 (terwijl deze wel waarde geeft bij de instellingen tab).
- De grafieken van dynamisch vandaag/morgen blijven leeg; ik heb unknow weggehaald en de sensor van Nordpool toegevoegd. Deze geeft ook een waarde bij het instellingen tab.

Onderstaand de screens.


[Afbeelding]

[Afbeelding]

Alvast dank voor jullie hulp.

Die 0 is de aansturing. Batterij staat op standby dus aansturing is er niet. Die 0 staat hier ook. Ik zie dat je spread op 25% staat, als je die nu eens naar 0 zet, dan wel actie?

[ctrl-tab]

Heeft iemand de gielz integratie werkend met de builtin nordpool integratie?
Ben al bezig geweest met een translatie template sensor maar kreeg het niet voor elkaar.

[smetzie]

gast777 schreef op zondag 3 mei 2026 @ 16:41:
[...]


Klopt inderdaad. Dit veld even terugzetten en invullen:
[Afbeelding]

Ah top dit, thanks voor de support; het werkt

[oeps]

Hallo allemaal,
Heb/had een issue met de Gielz integratie (of eigenlijk HA zelf). Heb nu een workaround maar snap de oorzaak niet. Sorry, wat langere post.
Ik deel het hier zodat het later door anderen gevonden kan worden en hopelijk weet iemand wat hier echt aan de hand is.


Het uitte zich (door toeval van het moment?) dat de batterij opeens op vol vermogen ging ontladen gedurende ongeveer 2 uur. Daarna normaal, wij waren weg dus het ging vanzelf allemaal! Bij mij is op vol vermogen gelukkig op dit moment nog 800W omdat de Zendure 2400 Pro (zonder panelen nog) nu nog op een stopcontact zit.

Ingezoomed:


Na speuren kwam ik het volgende tegen in de HA logging met eindeloos veel repeats in de logging:

WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:01[0m

Ik heb de batterij pas 3 weken en tot 30 april had ik een eigen +/- P1 Power sensor die elke 5 seconden ververst.
Afgelopen donderdag de rest api versie naar de Zendure P1 meter toegevoegd aan HA en die sensor in Gielz gezet. Werkte prima maar toen niet in de HA log gekeken.
Bij time-out errors is de eerste suggestie natuurlijk: Je hebt bagger Wifi of je hebt een bagger HA server.
De Zendure P1 meter en dongle en bridge hangen beiden in de meterkast naast een paar andere ESPhome sensors waaronder de P1 meter sensor die ik al tijden gebruik zonder problemen.
HA draait in een VM op Proxmox op een i5. De VM heeft 6GB ram en 6 virtuele CPU’s. Een ping naar Zendure P1 geeft gemiddeld 4,6ms roundtrip.
Als workaround gebruik ik nu gewoon weer de +/- Power sensor die ik had.
Om te testen heb ik de Zendure P1 via rest even op 2 seconden gezet. Met 1 seconde was de log zo’n beetje vol met bovenstaande error. Met 2 seconden heb ik een enkele time-out gezien gedurende een uur of 8.

• Ik weet uiteraard niet 100% zeker dat de time-outs de oorzaak zijn het opeens hard ontladen.

Mijn theorie tot nu toe: Af en toe is er door de Quooker even een piek waardoor de batterij op 800W ontladen gaat en net op dat moment gaf iets er de brui aan om zich twee uur later weer te herstellen. Zie ook de screenshots uit de Gielz log.In de HA log zie ik ook de volgende error:

Logger: homeassistant.components.rest.data
Source: components/rest/data.py:181
integration: RESTful (documentation, issues)
First occurred: 08:10:56 (171 occurrences)
Last logged: 16:24:06
Error fetching data: http://unknown/api/v1/data failed with Cannot connect to host unknown:80 ssl:default [DNS server returned answer with no data]
Error fetching data: http://unknown/properties/report failed with Cannot connect to host unknown:80 ssl:default [DNS server returned answer with no data]
Error fetching data: http:///api/v1/data failed with http:///api/v1/data
Error fetching data: http://192.168.178.156/properties/report failed with [Errno 104] Connection reset by peer

Ik snap de error message niet helemaal: http://192.168.178.156/properties/report failed zou kunnen als er even geen connectie is/
Maar http:///api/v1/data failed en http://unknown/api/v1/data failed snap ik niet. Lijkt dan een leeg IP adres veld of de tekst unknown in een IP address veld. In de screenshot met mijn instellingen.

De 192.168.178.156 is de 2400 Pro zelf. De wifi is meestal “Good”, heel soms “weak” (nog onderzoeken) maar in de periode van ontlading was het “Good”, tussen 16:00-18:00. Fritz-box bedrade AP is 2 muren en een verdieping verder. Daar is nog iets te verbeteren. AP dichter bij raam zodat de garage beter in beeld is.

Herkent iemand de problemen met Rest in HA (ik gebruik zelf één rest commando in HA om een ESPhome elke nacht even te herstarten.
Dank!

[DrNickB]

oeps schreef op zondag 3 mei 2026 @ 17:10:
Hallo allemaal,
...

Heb je ook iets meer logging van je Zendure P1 meter? Daar de waardes van? Connectiviteit etc?

Het lijkt er sterk op (ik ben geen expert) als je naar de eerste screenshot kijkt, dat 'iets' is waardoor hij wil gaan ontladen, maar daarna is je gebruik (Wit)/terug levering (groen) gelijk, eigenlijk lijkt de batterij te doen, wat hij hoort te doen.
Daarna lijkt je P1 (wit) iets meer heen en weer te schommelen, en daar lijkt de automatisering weer op te reageren.

[MikeyMan]

Bjorker schreef op woensdag 11 maart 2026 @ 12:06:
[...]

Ik zie dat je connection mode op cloud staat.
Is het met HA aansturing niet sneller om dit op ZenSDK in te stellen?

Is dit inderdaad sneller? Want dan zet ik hem ook om. Doet de app dan helemaal niks meer?

[TBird484]

ctrl-tab schreef op zondag 3 mei 2026 @ 16:58:
Heeft iemand de gielz integratie werkend met de builtin nordpool integratie?
Ben al bezig geweest met een translatie template sensor maar kreeg het niet voor elkaar.

Ja, die heb ik werkend.
Zie Wai_AM in "Zendure producten in Home Assistant integreren deel 2"
Bovenstaande config is voor de nederlandse versie van Gielz.
Ik heb op basis van de info zelf een template voor de engelse versie gemaakt.
Laat maar weten als je die nodig hebt.
Ik loop nog wel tegen een vreemd ding aan, ik moet perse de 15 min slider in Gielz aan hebben staan, anders wordt er in Gielz geen data verwerkt.

[oeps]

DrNickB schreef op zondag 3 mei 2026 @ 18:24:
[...]

Heb je ook iets meer logging van je Zendure P1 meter? Daar de waardes van? Connectiviteit etc?

Het lijkt er sterk op (ik ben geen expert) als je naar de eerste screenshot kijkt, dat 'iets' is waardoor hij wil gaan ontladen, maar daarna is je gebruik (Wit)/terug levering (groen) gelijk, eigenlijk lijkt de batterij te doen, wat hij hoort te doen.
Daarna lijkt je P1 (wit) iets meer heen en weer te schommelen, en daar lijkt de automatisering weer op te reageren.

Dank je voor je reactie.
Helaas geeft de Zendure P1 geen logging over wifi connectie. Kan dus alleen aan de router/AP kant wat zien wat ook beperkt is.

-66dBm is niet geweldig.
Het lijkt erop dat de Zendure spullen blijven plakken aan de Fritzbox router die veel verder staat. Heel vreemd want Fritzbox zou client steering moeten doen als de router vind dat de client een betere verbinding kan krijgen bij de AP.
Ik ga even dieper in mijn Wifi netwerk duiken.
Dank voor het Wifi zetje

[gast777]

oeps schreef op zondag 3 mei 2026 @ 17:10:
Herkent iemand de problemen met Rest in HA (ik gebruik zelf één rest commando in HA om een ESPhome elke nacht even te herstarten.
Dank!

Kun je de yaml configuratie van de Zendure P1 meter polling laten zien? Lijkt erop dat je daar geen IP adres gebruikt, maar een DNS naam. En dat de DNS lookup dan om een of andere reden even niet goed gaat.

Error fetching data: http://unknown/api/v1/data failed with Cannot connect to host unknown:80 ssl:default [DNS server returned answer with no data]
Error fetching data: http://unknown/properties/report failed with Cannot connect to host unknown:80 ssl:default [DNS server returned answer with no data]

Of is dat misschien de Homewizard P1 entry die probeert te connecten maar 'unknown' heeft als IP adres. In je screenshot staat er (empty value) bij de HomeWizard P1. Ik weet niet of dat normaal is....

[gast777]

Vul bij de HomeWizard P1 eens "unknown" in. Dat lijkt me default als je die niet gebruikt.

[oeps]

gast777 schreef op zondag 3 mei 2026 @ 20:03:
[...]
Kun je de yaml configuratie van de Zendure P1 meter polling laten zien? Lijkt erop dat je daar geen IP adres gebruikt, maar een DNS naam. En dat de DNS lookup dan om een of andere reden even niet goed gaat.

Of is dat misschien de Homewizard P1 entry die probeert te connecten maar 'unknown' heeft als IP adres. In je screenshot staat er (empty value) bij de HomeWizard P1. Ik weet niet of dat normaal is....

Dank voor het meedenken!
De yaml code die ik in mijn sensors.yaml heb staan (included in de configuration.yaml. Intern gebruik ik voor alle domotica spullen vaste ip addressen in HA altijd IP adressen, voor de zekerheid:

YAML:

# REST Sensors
# added 20260430
- platform: rest
  resource: http://192.168.178.162/properties/report
  scan_interval: 2
  name: "P1 Zendure API rest"
  value_template: "{{ value_json.total_power | float }}"
  unique_id: P1_Zendure_API_rest
  unit_of_measurement: "W"
  device_class: power
  state_class: measurement

Staat nu op 2 seconden was 1.
Ik weet dat ik het niet exact doe zoals in de documentatie staat maar ik kreeg allerlei errors bij config check als ik het exact overnam. Na wat knutselen kwam ik tot bovenstaande.

Configuration warnings
Setup of package 'zendure_gielz1986_global' failed: integration 'rest_command' cannot be merged, dict expected in main config
Invalid config for 'rest_command' at configuration.yaml, line 143: expected dictionary for dictionary value 'rest_command', got [{'reboot_moresenswoonkamer_url': {'url': 'http://192.168.178.143/Setup?action=reboot', 'method': 'get', 'timeout': 15}}, {'resource': 'http://192.168.178.162/properties/report', 'scan_interval': 1, 'sensor': [{'name': 'P1 Zendure API', 'value_template': '{{ value_json.total_power | float }}', 'unique_id': 'P1_Zendure_API', 'unit_of_measurement': 'W', 'device_class': 'power', 'state_class': 'measurement'}, {'name': 'P1 Zendure Phase A Power', 'value_template': '{{ value_json.a_aprt_power | fl...

Die error had te maken met dat ik al elders ook een rest commando gebruik reboot_moresenswoonkamer_url die je in de config check hierboven ziet.

Ik heb de HomeWizard entity die uiteraard niet beschikbaar is op disabled gezet sinds vanochtend om te kijken of dat invloed zou hebben op de logging. Ik heb even blabla opgegeven als HW IP adres en dat komt keurig in de log, dus toch een relatie met de HW die ik niet gebruik. Ga die error gewoon maar negeren.

Logger: homeassistant.components.rest.data
Source: components/rest/data.py:181
integration: RESTful (documentation, issues)
First occurred: 08:10:56 (253 occurrences)
Last logged: 20:30:10

Error fetching data: http://unknown/api/v1/data failed with Cannot connect to host unknown:80 ssl:default [DNS server returned answer with no data]
Error fetching data: http://unknown/properties/report failed with Cannot connect to host unknown:80 ssl:default [DNS server returned answer with no data]
Error fetching data: http:///api/v1/data failed with http:///api/v1/data
Error fetching data: http://192.168.178.156/properties/report failed with [Errno 104] Connection reset by peer
Error fetching data: http://blabla/api/v1/data failed with Cannot connect to host blabla:80 ssl:default [Timeout while contacting DNS servers]

Het zijn blijkbaar meerdere rest calls die in één log entry terecht komen. Beetje slordig van HA.

[DrNickB]

oeps schreef op zondag 3 mei 2026 @ 19:42:
[...]

Dank je voor je reactie.
Helaas geeft de Zendure P1 geen logging over wifi connectie. Kan dus alleen aan de router/AP kant wat zien wat ook beperkt is.

Dank voor het Wifi zetje

Was 2 delige vraag, maar zag dat ik het wat minder duidelijk had neer gezet.

Wat waren je historische waardes van de P1 over die periode.
Via meer waardes / Historie graph.

[ctrl-tab]

Mocht iemand interesse hebben om de officiele nordpool integratie werkend te krijgen met gielz;

- aanpassing nodig in gielz package, vanwege gebruik template sensor:

code:

sed -i 's/{{ item\.start\.isoformat() }}/{{ item.start if item.start is string else item.start.isoformat() }}/g' /config/packages/zendure_gielz1986_global.yaml

sed -i 's/{{ item\.end\.isoformat() }}/{{ item.end if item.end is string else item.end.isoformat() }}/g' /config/packages/zendure_gielz1986_global.yaml

- maak template sensor aan die een 'fake' hacs nordpool sensor creeert;
- config entry van officiele nordpoo integratie nog even invoeren;
- let op ik gebruik input values voor vat (.21) , opslag (0.02) , tax (0.091), kan je er ook statisch in zetten (zonneplan)
zonnebonus heb ik er niet in zitten.

code:

  - triggers:
      - trigger: time_pattern
        minutes: /15
      - trigger: homeassistant
        event: start
    actions:
      - delay: "00:00:30"
      - action: nordpool.get_prices_for_date
        data:
          config_entry: < ENTER CONFIG ENTRY ID >
          date: "{{ now().date() }}"
          areas: NL
          currency: EUR
        response_variable: today_price
      - action: nordpool.get_prices_for_date
        data:
          config_entry: < ENTER CONFIG ENTRY ID >
          date: "{{ now().date() + timedelta(days=1) }}"
          areas: NL
          currency: EUR
        response_variable: tomorrow_price 

    sensor:

      # --- CURRENT PRICE (mimics old HACS sensor) ---
      - name: nordpool_kwh_nl_eur_3_095_0
        unique_id: nordpool_kwh_nl_eur_3_095_0
        unit_of_measurement: "EUR/kWh"
        icon: mdi:currency-eur
        state_class: measurement
        state: >
          {% set opslag = states('input_number.energy_opslag') | float(0) %}
          {% set vat    = states('input_number.energy_vat')    | float(0) %}
          {% set tax    = states('input_number.energy_tax')    | float(0) %}
          {% if today_price is mapping and today_price['NL'] | list | count > 0 %}
            {% set now_slot = now().replace(second=0, microsecond=0) %}
            {% set now_slot = now_slot.replace(minute=(now_slot.minute // 15) * 15) %}
            {% set current = namespace(price=none) %}
            {% for state in today_price['NL'] %}
              {% set slot_start = state.start | as_datetime | as_local %}
              {% if slot_start == now_slot %}
                {% set current.price = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
              {% endif %}
            {% endfor %}
            {{ current.price | default('unavailable') }}
          {% else %}
            unavailable
          {% endif %}
        attributes:
          current_price: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% if today_price is mapping and today_price['NL'] | list | count > 0 %}
              {% set now_slot = now().replace(second=0, microsecond=0) %}
              {% set now_slot = now_slot.replace(minute=(now_slot.minute // 15) * 15) %}
              {% set current = namespace(price=none) %}
              {% for state in today_price['NL'] %}
                {% set slot_start = state.start | as_datetime | as_local %}
                {% if slot_start == now_slot %}
                  {% set current.price = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% endif %}
              {% endfor %}
              {{ current.price | default(none) }}
            {% else %}
              {{ none }}
            {% endif %}
          today: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[]) %}
            {% if today_price is mapping %}
              {% for state in today_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [(data.group | sum / 4) | round(5)] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
            {% endif %}
            {{ data.prices }}
          tomorrow: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[]) %}
            {% if tomorrow_price is mapping %}
              {% for state in tomorrow_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [(data.group | sum / 4) | round(5)] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
            {% endif %}
            {{ data.prices }}
          tomorrow_valid: >
            {{ tomorrow_price is mapping and tomorrow_price['NL'] | list | count > 0 }}
          average: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[]) %}
            {% if today_price is mapping %}
              {% for state in today_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [(data.group | sum / 4)] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
              {{ (data.prices | sum / data.prices | count) | round(5) }}
            {% else %}
              {{ 0 }}
            {% endif %}
          low_price: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set cutoff = 0.95 %}
            {% set data = namespace(prices=[], group=[]) %}
            {% if today_price is mapping %}
              {% for state in today_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [(data.group | sum / 4)] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
              {% set avg = data.prices | sum / data.prices | count %}
              {% set now_slot = now().replace(second=0, microsecond=0) %}
              {% set now_slot = now_slot.replace(minute=(now_slot.minute // 15) * 15) %}
              {% set current = namespace(price=avg) %}
              {% for state in today_price['NL'] %}
                {% set slot_start = state.start | as_datetime | as_local %}
                {% if slot_start == now_slot %}
                  {% set current.price = ((state.price / 1000 + tax + opslag) * (1 + vat)) %}
                {% endif %}
              {% endfor %}
              {{ current.price < avg * cutoff }}
            {% else %}
              {{ false }}
            {% endif %}
          raw_today: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[], starts=[], ends=[]) %}
            {% if today_price is mapping %}
              {% for state in today_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 1 %}
                  {% set data.starts = data.starts + [state.start] %}
                {% endif %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [{'start': data.starts[-1], 'end': state.end, 'value': (data.group | sum / 4) | round(5)}] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
            {% endif %}
            {{ data.prices }}
          raw_tomorrow: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[], starts=[], ends=[]) %}
            {% if tomorrow_price is mapping %}
              {% for state in tomorrow_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 1 %}
                  {% set data.starts = data.starts + [state.start] %}
                {% endif %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [{'start': data.starts[-1], 'end': state.end, 'value': (data.group | sum / 4) | round(5)}] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
            {% endif %}
            {{ data.prices }}

      # --- TOMORROW SENSOR ---
      - name: nordpool_tomorrow
        unique_id: nordpool_tomorrow
        state: >
          {% set opslag = states('input_number.energy_opslag') | float(0) %}
          {% set vat    = states('input_number.energy_vat')    | float(0) %}
          {% set tax    = states('input_number.energy_tax')    | float(0) %}
          {% set data = namespace(prices=[], group=[]) %}
          {% if tomorrow_price is mapping and tomorrow_price['NL'] | list | count > 0 %}
            {% for state in tomorrow_price['NL'] %}
              {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
              {% set data.group = data.group + [p] %}
              {% if data.group | count == 4 %}
                {% set data.prices = data.prices + [(data.group | sum / 4) | round(5)] %}
                {% set data.group = [] %}
              {% endif %}
            {% endfor %}
            {{ min(data.prices) }}
          {% else %}
            unavailable
          {% endif %}
        attributes:
          data: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[], starts=[]) %}
            {% if tomorrow_price is mapping %}
              {% for state in tomorrow_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 1 %}
                  {% set data.starts = data.starts + [state.start] %}
                {% endif %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [{'start': data.starts[-1], 'end': state.end, 'price': (data.group | sum / 4) | round(5)}] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
            {% endif %}
            {{ data.prices }}

[oeps]

DrNickB schreef op zondag 3 mei 2026 @ 21:07:
[...]

Was 2 delige vraag, maar zag dat ik het wat minder duidelijk had neer gezet.

Wat waren je historische waardes van de P1 over die periode.
Via meer waardes / Historie graph.

Nu snap ik hem
Beide P1 meters toegevoegd, geel de Zendure P1 die in gebruik was voor Gielz tijdens het ontlaad issue van iets voor 16:00 tot bijna 18:00.
De gele en blauwe lijn zijn overal beschikbaar (deze grafiek heeft natuurlijk geen resolutie van 1 seconde). Geel licht soms bovenop, dan weer blauw. Dat is rendering, niet onbeschikbaarheid.


En voor de compleetheid de vullingsgraag van de batterij:


Dank weer!

[hemertje]

Wai_AM schreef op vrijdag 24 april 2026 @ 13:35:
[Afbeelding]

Morgen is een goede test case of je alles goed kan doen

@Wai_AM

hoe ziet jou code voor deze kaarten eruit?

ik zie namelijk:





die van jou ziet er wat rustiger uit

[hemertje]

Wai_AM schreef op donderdag 23 april 2026 @ 08:03:
[...]


netjes.
mogelijke verbetering is dynamisch maken.
- input max temp
- input min temp
- input duration on
- input duration off

zodat het niet vast staat op temp en duur .

deze zijn instelbaar via de Helpers

code:

zendure_offgrid.yaml

[DrNickB]

oeps schreef op zondag 3 mei 2026 @ 21:46:
[...]

Nu snap ik hem
Beide P1 meters toegevoegd, geel de Zendure P1 die in gebruik was voor Gielz tijdens het ontlaad issue van iets voor 16:00 tot bijna 18:00.
De gele en blauwe lijn zijn overal beschikbaar (deze grafiek heeft natuurlijk geen resolutie van 1 seconde). Geel licht soms bovenop, dan weer blauw. Dat is rendering, niet onbeschikbaarheid.
[Afbeelding]

En voor de compleetheid de vullingsgraag van de batterij:
[Afbeelding]

Dank weer!

Ja, nee, sorry je bent me kwijt

p1 lijkt waardes te geven, je zendure lijkt waardes te geven, maar toch deed hij iets wat niet klopt
Maar zie ook niet heel goed terug in als ik je p1 data vergelijk met je screenshot daarvoor,
het lijkt alsof er wat andere waardes in gebruikt worden.
maar nogmaals geen expert en je bent me kwijt

[YvonneVP]

koboy schreef op zaterdag 2 mei 2026 @ 16:04:
[...]


Als je kijkt naar de te maken winst in centen dan maakt kaal of inclusief nu niet zo veel (beetje BTW) uit.
Probleem zit alleen in de RTE van je systeem, die is geen 100% en wordt gerekend in procenten. Daardoor moet je rekenen met de daadwerkelijke totale kosten, zeker dit jaar en volgend jaar ook op de paar momenten dat je gaat laden vanaf het net.

Ik zal in de zomer nagenoeg altijd gebruik maken van mijn zonnestroom om te batterijen te vullen, tenzij net als afgelopen week de goedkope periode negatief is. Dan gaan de zonnepaneeltjes even uit, en prop ik mijn batterij wel vol via het net. Zelf heb ik de prijzen incl. btw en EB. Dan is het namelijk gelijk aan wat ik in de app van Zonneplan zie, en is het voor mij allemaal wat gemakkelijker te vergelijken en zie ik ook gewoon fijn dezelfde prijzen. Scheelt me een hoop hoofdbrekers en gereken.

[YvonneVP]

Hippe Lip schreef op zaterdag 2 mei 2026 @ 23:59:
[...]

Ik ben inmiddels een stuk verder in het begrip en denk dat ik het in de zomer niet nodig heb. Ik heb vooral een flink overschot aan PV, dus loopt mijn accu overdag vol en stel ik de duurste uren in om ‘m weer te legen.
Jammer dat dit (nog) niet kan door simpelweg te zeggen dat ik de 8 duurste kwartieren tussen (bijvoorbeeld) 8 ‘s avonds en 8 in de ochtend wil ontladen. Als je met aantal wil werken, dan lopen die over de hele dag, dus ook de ochtend ervóór. In de winter werkt dat misschien, maar niet in de zomer.

Komend najaar en zeker in de winter dan heb ik die spread wel nodig omdat PV dan niet genoeg oplevert om het etmaal door te komen. Tegen die tijd ga ik me er verder in verdiepen.
Maar dank voor je suggestie, @YvonneVP

Je kunt toch dan handmatig de tijden om te laden en ontladen instellen met Gxx:xx en Dxx:xx. Ik zet gewoon aantal uren goedkoopste in, en aantal uren duurste. En tot nu komen die uren dagelijks goed overeen als zijnde de goedkoopste en duurste uren. Ik kijk er na 13 uur even naar hoe het de andere dag is met de prijzen, en that's it. Mijn provider rekent in uren, dus heb ik de uren ook in Gielz op uren ingesteld. Zou dit op kwartieren worden omgezet dan vermenigvuldig ik de uren van nu, goedkoopste en duurste, gewoon met 4 en dan komt het op hetzelfde neer. Maar zo lang mijn leverancier uren hanteert doe ik dat ook.

[YvonneVP]

Hippe Lip schreef op zondag 3 mei 2026 @ 00:03:
[...]

Je hebt natuurlijk helemaal gelijk, @YvonneVP. Er wordt door @gielz en @gast777 ongelooflijk veel en vooral fraai werk geleverd. En de documentatie díé er is is ook niet verkeerd.

Het was meer de frustratie van de first-time user die eerst alles van die twee in een vloek en een zucht kan installeren, maar als het daarna op aanpassen of updaten aankomt, dan voel je je als in het donker in onbekende omgeving.
Ik kom wel over die frustratie heen hoor en het is zeker geen aanmerking aan de makers, maar soms moet het er even uit.

Ik denk dat je misschien té snel té veel wilde. En daarmee zat je dan naar mijn beleving eerder jezelf in de weg. Vele vragen die je stelde zijn ook al eerder gesteld, en die zijn dan op het forum ook terug te vinden. Enige is dat je dan wel wat meer gebonden bent aan hoe je zoekt om ook het antwoord te kunnen vinden. Ik zou dus zeggen, neem de tijd om het je eigen te maken en probeer niet in 0,5 seconden van 0 naar 100 te willen. Dat levert namelijk frustratie op.

[YvonneVP]

Hippe Lip schreef op zondag 3 mei 2026 @ 00:15:
[...]

Toch begin ik langzaamaan te beseffen (ik ben een trage denker) dat het wel uitmaakt en dat je de totale prijs moet hebben, inclusief EB, BTW en toeslag. Die spread heb je nodig om de verliezen te compenseren en die verliezen zitten ook in de EB, BTW en toeslag. Tenminste als je het hebt over in- en verkoop. Niet als je de batterijen vanuit je PV vult, want das andere koek.

De batterijen vullen uit je PV is altijd de meest winstgevende. Je betaald in NL momenteel geen btw, geen EB, maar wel toeslag. Per kwh is de btw en EB te verwaarlozen, en als je inkoopt terwijl het zonnestroom is, die je later weer verkoopt dan is het ook heel makkelijk om te zien wat de duurste uren zijn om die PV stroom weer te dumpen. Ik denk dus dat je iets te complex aan het denken bent, en dat simpel denken soms juist makkelijker is en beter werkt. Je maakt het jezelf uiteindelijk alleen lastiger, zeker als het gaat om PV stroom. Die levert het meeste op, tenzij de goedkoopste prijzen negatief zijn zoals afgelopen week. Maar dan gaat bij mij de PV uit om van het net te laden. En die stroom dump ik niet om te verkopen, maar gebruik ik dus als mijn PV geen, of niet voldoende, stroom meer levert en draai ik NOM tot de andere dag.

[YvonneVP]

koboy schreef op zondag 3 mei 2026 @ 13:33:
[...]


Ik zou de Nordpool gewoon op kwartieren laten staan. In Gielz zit een schuifje om om te rekenen naar uurtarieven. Scheelt je foutgevoelig het configureren van Nordpool als zonneplan over gaat

Dat is inderdaad ook een goede oplossing om gewoon uurtarieven te hebben.

[YvonneVP]

ppaulv schreef op zondag 3 mei 2026 @ 13:50:
[...]

Zie mijn reactie van 1 mei 14.50 uur. Meen me te herinneren dat daarvoor nodig is dat je beheer rechten hebt op jouw 'site' van solaredge maar dat weet ik niet zeker.
En integratie solaredge modbus multi

Ik zou admin rechten moeten hebben als ik online via mijn browser inlog, en anders vraag ik gewoon even bij het bedrijf die mijn SolarEdge monitort of ze me kunnen helpen.

[Hippe Lip]

YvonneVP schreef op maandag 4 mei 2026 @ 01:18:
[...]
Ik denk dus dat je iets te complex aan het denken bent, en dat simpel denken soms juist makkelijker is en beter werkt. Je maakt het jezelf uiteindelijk alleen lastiger,

Dank voor je reacties, @YvonneVP.
(Te) snel (te) veel willen, daar heb ik vaak last van, net zoals te complex denken. Zo zit mijn hoofd helaas in elkaar, ik weet het.
Ik zal het ermee moeten doen…

Desondanks ( of misschien juist dankzij dat?) is mijn motto: ‘eenvoud is kenmerk van het ware’.

[Pakhaas]

YvonneVP schreef op maandag 4 mei 2026 @ 01:18:
[...]

De batterijen vullen uit je PV is altijd de meest winstgevende. Je betaald in NL momenteel geen btw, geen EB, maar wel toeslag. Per kwh is de btw en EB te verwaarlozen, en als je inkoopt terwijl het zonnestroom is, die je later weer verkoopt dan is het ook heel makkelijk om te zien wat de duurste uren zijn om die PV stroom weer te dumpen. Ik denk dus dat je iets te complex aan het denken bent, en dat simpel denken soms juist makkelijker is en beter werkt. Je maakt het jezelf uiteindelijk alleen lastiger, zeker als het gaat om PV stroom. Die levert het meeste op, tenzij de goedkoopste prijzen negatief zijn zoals afgelopen week. Maar dan gaat bij mij de PV uit om van het net te laden. En die stroom dump ik niet om te verkopen, maar gebruik ik dus als mijn PV geen, of niet voldoende, stroom meer levert en draai ik NOM tot de andere dag.

Momenteel is dit niet het meest winstgevende. Dat is dynamisch handelen.

[Wai_AM]

hemertje schreef op zondag 3 mei 2026 @ 22:03:
[...]


@Wai_AM

hoe ziet jou code voor deze kaarten eruit?

ik zie namelijk:

[Afbeelding]

[Afbeelding]

die van jou ziet er wat rustiger uit

Marktprijs is ook "Line" krijg dan ook kleuren, met ¨column" krijg ik die niet.

[koboy]

YvonneVP schreef op maandag 4 mei 2026 @ 01:18:
[...]

De batterijen vullen uit je PV is altijd de meest winstgevende. Je betaald in NL momenteel geen btw, geen EB, maar wel toeslag. Per kwh is de btw en EB te verwaarlozen, en als je inkoopt terwijl het zonnestroom is, die je later weer verkoopt dan is het ook heel makkelijk om te zien wat de duurste uren zijn om die PV stroom weer te dumpen. Ik denk dus dat je iets te complex aan het denken bent, en dat simpel denken soms juist makkelijker is en beter werkt. Je maakt het jezelf uiteindelijk alleen lastiger, zeker als het gaat om PV stroom. Die levert het meeste op, tenzij de goedkoopste prijzen negatief zijn zoals afgelopen week. Maar dan gaat bij mij de PV uit om van het net te laden. En die stroom dump ik niet om te verkopen, maar gebruik ik dus als mijn PV geen, of niet voldoende, stroom meer levert en draai ik NOM tot de andere dag.

Batterijen uit PV vullen hoeft niet het meest winstgevende te zijn!
Bij teruglevering kleiner dan afname is de waarde van een teruggeleverde kWh gelijk aan die van een afgenomen kWh, dus inclusief BTW en EB en toeslag (in geval van zonneplan).
De 80% RTE is dus OOK van toepassing op de EB component, wat betekent dat je al ongeveer 2 cent winst moet maken op het EPEX deel om alleen de RTE over de EB te compenseren!

Edit: dat van die waarde geldt natuurlijk ook voor de waarde van stroom uit de accu. Ook stroom ingekocht tijdens all-in negatieve uren moet je voor maximale winst dumpen op het duurste moment en niet mee gaan NOMmen.

Heel bot gezegd: met een dynamisch contract is vrijwel elke notie van NOM geld weggooien. Er zijn 2 situaties waarin dit niet zo is:
1. Meer teruglevering dan afname
2. In de smalle prijsband tussen negatieve verkoopprijs en all-in negatieve prijs die je hebt bij leveranciers die de inkoopvergoeding niet teruggeven.
Maar in beide gevallen ga je NOMmen door de PV te regelen niet de accu.

[ Voor 18% gewijzigd door koboy op 04-05-2026 09:36 ]

[smetzie]

Ik ben nog vrij nieuw met Home Assistant en de Gielz-integratie, dus misschien stel ik wat beginnersvragen.
Mijn situatie:

Ik wil binnenkort 4 zonnepanelen aansluiten op een SolarFlow Pro 2400 met 5,2 kWh batterijcapaciteit. Op dit moment staat de ontlading nog op maximaal 800 watt, maar zodra hij op een eigen groep zit wil ik dit verhogen richting 2400 watt. Ik gebruik dynamische tarieven en hanteer ongeveer 12 cent prijsverschil als grens om de batterij tijdens dure uren te ontladen.

Waar ik tegenaan loop:
Tijdens dure uren wordt de batterij ontladen, maar daarna is hij vaak nog niet volledig leeg (vanwege 800w). Ik zou graag willen dat de batterij daarna automatisch het sluipverbruik in de nacht opvangt, in plaats van dat hij op stand-by gaat.

Mijn vragen:

• Kan ik instellen dat bijvoorbeeld 30% van de batterijcapaciteit beschikbaar blijft voor nachtelijk sluipverbruik?
• Moet ik hiervoor de modus van de SolarFlow via een Home Assistant-automatisering aanpassen?
• Welke modus of instellingen gebruiken jullie hiervoor in combinatie met de Gielz-integratie?
• Heeft iemand misschien een simpel voorbeeld van een automatisering, liefst met de gebruikte entiteiten of YAML?

Daarnaast heb ik een hybride auto met een accu van 14,1 kWh. Die laad ik vaak ’s nachts via een normaal 230V-stopcontact. Daar zit een slimme schakelaar tussen, die ik nu via HomeKit automatiseer.

• Hoe voorkomen jullie dat de thuisbatterij onbedoeld leeggetrokken wordt door het laden van de auto, is dat erg of juist niet handig?
• Is het slim om de SolarFlow tijdelijk op stand-by te zetten tijdens het autoladen, of werken jullie liever met een minimale SOC-grens?

Ik ben vooral benieuwd naar hoe anderen dit praktisch hebben ingericht.

[ppaulv]

koboy schreef op maandag 4 mei 2026 @ 09:14:
[...]


Batterijen uit PV vullen hoeft niet het meest winstgevende te zijn!
Bij teruglevering kleiner dan afname is de waarde van een teruggeleverde kWh gelijk aan die van een afgenomen kWh, dus inclusief BTW en EB en toeslag (in geval van zonneplan).
De 80% RTE is dus OOK van toepassing op de EB component, wat betekent dat je al ongeveer 2 cent winst moet maken op het EPEX deel om alleen de RTE over de EB te compenseren!

Edit: dat van die waarde geldt natuurlijk ook voor de waarde van stroom uit de accu. Ook stroom ingekocht tijdens all-in negatieve uren moet je voor maximale winst dumpen op het duurste moment en niet mee gaan NOMmen.

Heel bot gezegd: met een dynamisch contract is vrijwel elke notie van NOM geld weggooien. Er zijn 2 situaties waarin dit niet zo is:
1. Meer teruglevering dan afname
2. In de smalle prijsband tussen negatieve verkoopprijs en all-in negatieve prijs die je hebt bij leveranciers die de inkoopvergoeding niet teruggeven.
Maar in beide gevallen ga je NOMmen door de PV te regelen niet de accu.

Denk dat je laatste opmerking helemaal correct is. Wat daarvoor staat ongetwijfeld ook..

[RemmyB83]

Vorige week heb ik de fireson integratie geupdate, en sinds dien heb ik wat problemen. Deze nogmaals geupdate door een tip hier naar fw 1.3.1.
Maar ik blijf wat rare dingen zien.
Ik heb 2x een sf800 plus.
Hems staat uit.
ZenSDK staat uit.
En Gielz staat aan op NOM.
Accu's waren leeg, ze hebben vandaag wat bij geladen. Vervolgens zijn ze weer leeg, maar nu gaan ze weer niet laden. Lijkt wel of er ergens iets blijft hangen.
Gisteren het zelfde, en toen even zit spelen met hems en fireson. En dan start het uiteindelijk wel. Maar dat is natuurlijk niet de bedoeling.
Extra info: proxy versie 20260430

[Devke]

RemmyB83 schreef op maandag 4 mei 2026 @ 12:41:
Vorige week heb ik de fireson integratie geupdate, en sinds dien heb ik wat problemen. Deze nogmaals geupdate door een tip hier naar fw 1.3.1.
Maar ik blijf wat rare dingen zien.
Ik heb 2x een sf800 plus.
Hems staat uit.
ZenSDK staat uit.
En Gielz staat aan op NOM.
Accu's waren leeg, ze hebben vandaag wat bij geladen. Vervolgens zijn ze weer leeg, maar nu gaan ze weer niet laden. Lijkt wel of er ergens iets blijft hangen.
Gisteren het zelfde, en toen even zit spelen met hems en fireson. En dan start het uiteindelijk wel. Maar dat is natuurlijk niet de bedoeling.
Extra info: proxy versie 20260430

[Afbeelding]

[Afbeelding]

Je gebruikt gielz en Fireson niet gelijktijdig hoop ik? Er kan maar 1 kapitein op het schip actief zijn.

[Maarten60]

smetzie schreef op maandag 4 mei 2026 @ 10:57:
Ik ben nog vrij nieuw met Home Assistant en de Gielz-integratie,

Daarnaast heb ik een hybride auto met een accu van 14,1 kWh. Die laad ik vaak ’s nachts via een normaal 230V-stopcontact. Daar zit een slimme schakelaar tussen, die ik nu via HomeKit automatiseer.

Hoe voorkomen jullie dat de thuisbatterij onbedoeld leeggetrokken wordt door het laden van de auto, is dat erg of juist niet handig?

Auto uit batterij laden is een keuze. Ik laad meestal overdag met zonnestroom, maar als je de batterij met zonnestroom laadt en ‘s morgens vermogen over hebt zou ik de batterij gebruiken (gratis stroom).

• Is het slim om de SolarFlow tijdelijk op stand-by te zetten tijdens het autoladen, of werken jullie liever met een minimale SOC-grens?

Omdat ik overdag via de panelen wil laden, wil ik de batterij (verlies via RTE) niet gebruiken. Ik heb een automatisering die bij laden door auto de batterij in slim opladen zet. Dus niet ontladen maar wel laden als er (pv) stroom over is.

[RemmyB83]

Devke schreef op maandag 4 mei 2026 @ 12:47:
[...]

Je gebruikt gielz en Fireson niet gelijktijdig hoop ik? Er kan maar 1 kapitein op het schip actief zijn.

Nee die staat uit.
Maar gisteren toen ik die even aanzette ging hij weer.... nu doe ik dat even niet om te trouble shoote.

[gast777]

RemmyB83 schreef op maandag 4 mei 2026 @ 12:51:
[...]

[Afbeelding]
Nee die staat uit.
Maar gisteren toen ik die even aanzette ging hij weer.... nu doe ik dat even niet om te trouble shoote.

Onlangs had iemand vage problemen en toen die MQTT uitschakelde op de Zendures was het probleem weg. Fireson gebruikt MQTT dacht ik toch? En tegelijkertijd polt Gielz elke seconde richting de devices via HTTP/REST. Dat beide tegelijk doen zou overbelasting en problemen kunnen veroorzaken.

Ik zou dus zeggen, als test kun je MQTT uitschakelen op je Zendures. En dan kijken of de problemen weg zijn. Sowieso zou ik adviseren niet Gielz en Fireson tegelijk te gebruiken. Ook al is het niet aansturen, ook het alleen informatie pollen en MQTT zenden tegelijk kan wellicht te veel worden voor de Zendures.

[ralphkeb]

RemmyB83 schreef op maandag 4 mei 2026 @ 12:41:
Vorige week heb ik de fireson integratie geupdate, en sinds dien heb ik wat problemen. Deze nogmaals geupdate door een tip hier naar fw 1.3.1.
Maar ik blijf wat rare dingen zien.
Ik heb 2x een sf800 plus.
Hems staat uit.
ZenSDK staat uit.
En Gielz staat aan op NOM.
Accu's waren leeg, ze hebben vandaag wat bij geladen. Vervolgens zijn ze weer leeg, maar nu gaan ze weer niet laden. Lijkt wel of er ergens iets blijft hangen.
Gisteren het zelfde, en toen even zit spelen met hems en fireson. En dan start het uiteindelijk wel. Maar dat is natuurlijk niet de bedoeling.
Extra info: proxy versie 20260430

[Afbeelding]

[Afbeelding]

Ik weet niet wat er ingesteld staat in het configuratie scherm van Gielz? Als er bij het discharging scherm bij start discharge -300 staat en wat ik zie in je schermafbeelding je verbruik -150 W is gaat hij volgens mij niet opladen.

[RemmyB83]

gast777 schreef op maandag 4 mei 2026 @ 13:37:
[...]


Onlangs had iemand vage problemen en toen die MQTT uitschakelde op de Zendures was het probleem weg. Fireson gebruikt MQTT dacht ik toch? En tegelijkertijd polt Gielz elke seconde richting de devices via HTTP/REST. Dat beide tegelijk doen zou overbelasting en problemen kunnen veroorzaken.

Ik zou dus zeggen, als test kun je MQTT uitschakelen op je Zendures. En dan kijken of de problemen weg zijn. Sowieso zou ik adviseren niet Gielz en Fireson tegelijk te gebruiken. Ook al is het niet aansturen, ook het alleen informatie pollen en MQTT zenden tegelijk kan wellicht te veel worden voor de Zendures.

Bedankt voor het meedenken🙂

Logboek in gielz bleef ook op 11.50 hangen, en werd niet elke 5 sec ververst. Na dat ik via gielz de mode op standby had gezet, en weer terug op NOM begon het weer te werken. Gekke was als ik er op het logboek klikte zag ik wel dat hij elke 5 sec werd getriggert.

Ik heb MQTT idd aan staan, en heb ze nu uitgezet. Hopelijk is dat het probleem.
En anders zet ik fireson ook nog wel uit.

In iedergeval alvast bedankt

[RemmyB83]

ralphkeb schreef op maandag 4 mei 2026 @ 13:44:
[...]


Ik weet niet wat er ingesteld staat in het configuratie scherm van Gielz? Als er bij het discharging scherm bij start discharge -300 staat en wat ik zie in je schermafbeelding je verbruik -150 W is gaat hij volgens mij niet opladen.

Bedankt voor je reactie🙂
Maar daar zit het probleem denk ik niet.

[Hippe Lip]

Pakhaas schreef op maandag 4 mei 2026 @ 06:49:
[...]

Momenteel is dit niet het meest winstgevende. Dat is dynamisch handelen.

@Pakhaas
Ook als je PV op een gemiddelde dag meer opwekt dan je in je batterijen kwijt kan en ruim meer is dan je in een etmaal zelf verbruikt?

[ Voor 8% gewijzigd door Hippe Lip op 04-05-2026 21:32 ]

[Pakhaas]

Hippe Lip schreef op maandag 4 mei 2026 @ 21:29:
[...]

@Pakhaas
Ook als je PV op een gemiddelde dag meer opwekt dan je in je batterijen kwijt kan en ruim meer is dan je in een etmaal zelf verbruikt?

Waarom zou dat het anders maken?

[Hippe Lip]

Pakhaas schreef op maandag 4 mei 2026 @ 21:33:
[...]

Waarom zou dat het anders maken?

Ik weet het niet en daarom stel ik jou die vraag.

[Pakhaas]

Hippe Lip schreef op maandag 4 mei 2026 @ 21:46:
[...]

Ik weet het niet en daarom stel ik jou die vraag.

Ik stelde die wedervraag om je even te triggeren.

Bijv morgen. Dan is het overdag 26ct en avonds op duurste 31ct. Als je dan PV overschot gaat opslaan in je batterij met 80% RTE betaal je in werkelijk 31.2ct om de PV opwek op te slaan. Immers als je de PV rechtsteeks had teruggeleverd kreeg je direct 26ct zonder laad- en ontlaadverliezen. Dus dat is de kostprijs bij batterij laden met PV.
Morgen blijven de batterijen in standby en lever ik PV direct terug.

Daarom is nu Dynamisch Handelen economisch het voordeligste. Laden als goedkoop is en ontladen als duur is en de rest op standby.

Dat wordt volgend jaar anders want dan krijg je bij terugleveren alleen kale prijs. Dan is PV opslaan voor later verbruik juist wel aantrekkelijk.

[ Voor 3% gewijzigd door Pakhaas op 04-05-2026 21:56 ]

[Hippe Lip]

Pakhaas schreef op maandag 4 mei 2026 @ 21:55:
[...]

Ik stelde die wedervraag om je even te triggeren.

Bijv morgen. Dan is het overdag 26ct en avonds op duurste 31ct. Als je dan PV overschot gaat opslaan in je batterij met 80% RTE betaal je in werkelijk 31.2ct om de PV opwek op te slaan. Immers als je de PV rechtsteeks had teruggeleverd kreeg je direct 26ct zonder laad- en ontlaadverliezen. Dus dat is de kostprijs bij batterij laden met PV.
Morgen blijven de batterijen in standby en lever ik PV direct terug.

Daarom is nu Dynamisch Handelen economisch het voordeligste. Laden als goedkoop is en ontladen als duur is en de rest op standby.

Dat wordt volgend jaar anders want dan krijg je bij terugleveren alleen kale prijs. Dan is PV opslaan voor later verbruik juist wel aantrekkelijk.

Dank voor deze uitleg @Pakhaas.
Die had ik even nodig.

Dan nog wel twee andere vragen.

1. Wat voor spreiding kies je dan? Minimaal 20% om je verliezen te compenseren, maar wel hoger omdat je anders nog steeds heen en weer aan het pompen bent met nul winst. Maar hoeveel is dan een geschikte drempel? 30%?
2. En kies je dan voor alleen Dynamic Trading of voor Smart Matching + Smart Matching? Want bij een paar matige dagen haal je die 30% (of hoeveel je ook kiest) nauwelijks en staat de boel te nixen. Is het dan beter wel te NOMmen?

[Pakhaas]

Hippe Lip schreef op maandag 4 mei 2026 @ 22:19:
[...]

Dank voor deze uitleg @Pakhaas.
Die had ik even nodig.

Dan nog wel twee andere vragen.

1. Wat voor spreiding kies je dan? Minimaal 20% om je verliezen te compenseren, maar wel hoger omdat je anders nog steeds heen en weer aan het pompen bent met nul winst. Maar hoeveel is dan een geschikte drempel? 30%?
2. En kies je dan voor alleen Dynamic Trading of voor Smart Matching + Smart Matching? Want bij een paar matige dagen haal je die 30% (of hoeveel je ook kiest) nauwelijks en staat de boel te nixen. Is het dan beter wel te NOMmen?

Ik ken de termen die je noemt niet. Ik werk met de NL versie van Gielz.

Minimale spread zeggen ze 25%, maar in praktijk heb ik liever 40-50% want zit bij Tibber en daar betaal je een hogere opslag voor levering dan wat je als bonus bij teruglevering terug krijgt.

Bovendien hou je met RTE nog geen rekening met afschrijving, dus voor een paar centen doe ik niet mee.

NOM moet je nou juist niet doen haha. Bij NOM sla je alsnog PV overschot op, en dat wil je nou juist direct het net op hebben, zoals ik hierboven net heb uitgelegd.

[ Voor 4% gewijzigd door Pakhaas op 04-05-2026 22:27 ]

[koboy]

@Hippe Lip
Een RTE van 80% komt overeen met een spread van 25%. Aangezien de RTE 83% of meer in geval van de 2500ACplus/pro is, maak je dan net een minimale winst als je alle kosten terugkrijgt zoals bij Zonneplan.

Ikzelf pak ook die minimale winst, want alle kleine beetjes helpen en wie het kleine niet eert....

[Hippe Lip]

Pakhaas schreef op maandag 4 mei 2026 @ 22:25:
[...]

Ik ken de termen die je noemt niet. Ik werk met de NL versie van Gielz.

@Pakhaas
Dynamic Trading of voor Smart Matching + Smart Matching
=
Dynamisch handelen of Dynamisch handelen + NOM

Minimale spread zeggen ze 25%, maar in praktijk heb ik liever 40-50% want zit bij Tibber en daar betaal je een hogere opslag voor levering dan wat je als bonus bij teruglevering terug krijgt.

Bovendien hou je met RTE nog geen rekening met afschrijving, dus voor een paar centen doe ik niet mee.

NOM moet je nou juist niet doen haha. Bij NOM sla je alsnog PV overschot op, en dat wil je nou juist direct het net op hebben, zoals ik hierboven net heb uitgelegd.

Ah, die opslag had ik nog niet aan gedacht. Die moet ik nog mee calculeren. Die is hier 2,5 cent, te betalen bij zowel heen als terug. Ik zit bij SamenOM (don’t ask).

En doet het eigen gebruik er nog toe? Ik heb door allerlei apparatuur in huis een basisverbruik van ca. 500W rond de klok. Dat gaat dus altijd door, ook op dagen dat je die spread van laten we zeggen 40% niet haalt. Ik kan me voorstellen dat NOM dan wel zinvol is: overdag enig overschot in de accu (op goedkopere uren) om dat in de avond en nacht tijdens duurdere uren te gebruiken?
Of is dat wishful thinking?

[ Voor 5% gewijzigd door Hippe Lip op 04-05-2026 23:07 ]

[Pakhaas]

Hippe Lip schreef op maandag 4 mei 2026 @ 22:36:
[...]

@Pakhaas
Dynamic Trading of voor Smart Matching + Smart Matching
=
Dynamisch handelen of Dynamisch handelen + NOM

[...]

Ah, die opslag had ik nog niet aan gedacht. Die moet ik nog mee calculeren. Die is hier 2,5 cent, te betalen bij zowel heen als terug. Ik zit bij SamenOM (don’t ask).

En doet het eigen gebruik er nog toe? Ik heb door allerlei apparatuur in huis een basisverbruik van ca. 500W rond de klok. Dat gaat dus altijd door, ook op dagen dat je die spread van laten we zeggen 40% niet haalt. Ik kan me voorstellen dat NOM dan wel zinvol is: overdag enig overschot in de accu (op goedkopere uren) om dat in de avond en nacht tijdens duurdere uren te gebruiken?
Of is dat wishful thinking?

Die opslag van 2.5ct heen en terug hoef je dus niets mee te doen he. Die is immers zelfde heen en terug.

NOM is en blijft nu nee, puur economisch bekeken. Goedkope uren laden, dure uren ontladen. Wellicht kan chatgpt wat vragen voor je voorrekenen, dan kan je het wat visueel maken.

[ Voor 3% gewijzigd door Pakhaas op 04-05-2026 22:54 ]

[Hippe Lip]

Pakhaas schreef op maandag 4 mei 2026 @ 22:48:
Die opslag van 2.5ct heen en terug hoef je dus niets mee te doen he. Die is immers zelfde heen en terug.

@Pakhaas
Helaas. Daarom zei ik al: die 2,5 cent (inclusief BTW) is in beide richtingen te betalen! Die komt er dus bij in geval van afname en wordt in mindering gebracht op de vergoeding bij terugleveren.
Dat maakt de minimale spread die nodig is om überhaupt quitte te spelen waarschijnlijk nog wat hoger.
Maar omdat dit (die 2,5 cent) een absoluut bedrag is en de spread relatief is doe ik er nog even over om dat om te rekenen in benodigde spread.

NOM is en blijft nu nee, puur economisch bekeken. Goedkope uren laden, dure uren ontladen. Maar gezien de vragen die je stelt, heb ik nog niet het idee dat je het begrijpt. Wellicht kan chatgpt wat vragen voor je voorrekenen, dan kan je het wat visueel maken.

Ik zei het al een tijdje geleden: ik ben een trage denker. Ik heb dit soort gesprekken juist nodig om het goed in het hoofd te krijgen. Het is niet een kwestie van het er niet mee eens zijn of eraan twijfelen. Het komt maar langzaam, stapje voor stapje binnen. Het zal mede de leeftijd zijn?

[Mistraller]

Ik voel me ergens heel dom, maar de Gielz integratie, al dan niet met proxy, krijg ik niet soepel werkend en is bij mij bijzonder instabiel.
Ik heb alles volgens de instructies ingericht, de data van beide zendures verschijnt in het dashboard, HEMS is uitgevinkt; en beide hebben een "uitstekende" wifi verbinding.
So far so good....Echter is mijn hele HA daarna een heel stuk meer unresponsive, en ik zie ook steeds de connectie wegschieten, dan is de data op het dashboard tijdelijk op unavailable. (gaps in de graphs).
Ik kan in het Gielz dash "Snel ontladen en snel Opladen" activeren; en dan worden de ingestelde waardes toegepast.
NOM, handmatig doet echter niets. De zendures blijven op standby staan.

Ik had het nachtje eerder ook al getest, en toen was in de ochtend mijn HA gecrashed.

NodeRed heb ik als addon app geinstalleerd binnen ha.
Mijn HA draaide tot nu toe soepel in een KVM up een ubuntu laptop (vraag me af of dit er iets toedoet maar goed)

Om nodeRed even uit te sluiten heb ik de flow gedisabled en in Gielz het IP van 1 zendure ingesteld.
Verbinding lijkt dan iets stabieler, maar ook hier kan ik niet Handmatig een wattage instellen, NOM doen, slechts max ontladen en max laden. En opvragen van de automations pagina in de settings duurt ineens dik 10 seconden.

Ik heb van alle files de NL versie gebruikt. En overal de nieuwste versie.

Ik heb geen idee waar dit nu aan ligt, het lijkt wel een te zware integratie voor mijn HA? Nooit eerder gezien dit gedrag. Maar gekke is dus ook dat ik maar een paar modi werkend kan krijgen. (handmatig had het zeker moeten doen)

De automation heb ik nog omgezet naar trigger op de P1 sensor ipv die 5 seconden trigger om te kijken wat het doet; maar lijkt eerder slechter te werken (dacht dat ik dit begrepen had uit het grote zendure topic; omdat ik nog een dsmr4 heb leek me dit zinvol.

[ Voor 14% gewijzigd door Mistraller op 05-05-2026 02:19 ]

[YvonneVP]

Pakhaas schreef op maandag 4 mei 2026 @ 06:49:
[...]

Momenteel is dit niet het meest winstgevende. Dat is dynamisch handelen.

Tenzij je voor NOM gaat, en dus de stroom van je batterij wilt gebruiken als het zonnetje onder is gegaan.

[YvonneVP]

koboy schreef op maandag 4 mei 2026 @ 09:14:
[...]


Batterijen uit PV vullen hoeft niet het meest winstgevende te zijn!
Bij teruglevering kleiner dan afname is de waarde van een teruggeleverde kWh gelijk aan die van een afgenomen kWh, dus inclusief BTW en EB en toeslag (in geval van zonneplan).
De 80% RTE is dus OOK van toepassing op de EB component, wat betekent dat je al ongeveer 2 cent winst moet maken op het EPEX deel om alleen de RTE over de EB te compenseren!

Edit: dat van die waarde geldt natuurlijk ook voor de waarde van stroom uit de accu. Ook stroom ingekocht tijdens all-in negatieve uren moet je voor maximale winst dumpen op het duurste moment en niet mee gaan NOMmen.

Heel bot gezegd: met een dynamisch contract is vrijwel elke notie van NOM geld weggooien. Er zijn 2 situaties waarin dit niet zo is:
1. Meer teruglevering dan afname
2. In de smalle prijsband tussen negatieve verkoopprijs en all-in negatieve prijs die je hebt bij leveranciers die de inkoopvergoeding niet teruggeven.
Maar in beide gevallen ga je NOMmen door de PV te regelen niet de accu.

Als je met het verhandelen van stroom wilt verdienen dan zal je ook een grotere capaciteit moeten hebben zodat handelen ook echt zin heeft. Met iets van 6,nogwat kwh haal je ook flink wat besparing binnen als je de batterij vol gooit tijdens goedkope, of nog beter negatieve uren, of van je PV. Die stroom kun je tot de andere dag gebruiken, en dan heb je dus nauwelijks verbruik. Voor dat ene jaartje dat handelen nog nut heeft ga ik in ieder geval geen grote investering doen, die ik in die paar maanden die we nog hebben tot de saldering verdwijnt never nooit terug zal verdienen.

[Hippe Lip]

Pakhaas schreef op maandag 4 mei 2026 @ 06:49:
Momenteel is dit (NOM) niet het meest winstgevende. Dat is dynamisch handelen.

Hippe Lip schreef op maandag 4 mei 2026 @ 21:29:
@Pakhaas
Ook als je PV op een gemiddelde dag meer opwekt dan je in je batterijen kwijt kan en ruim meer is dan je in een etmaal zelf verbruikt?

Pakhaas schreef op maandag 4 mei 2026 @ 21:33:
Waarom zou dat het anders maken?

Waarom dat het anders maakt? Dat zal ik je vertellen, @Pakhaas. Het duurde even voordat ik het doorhad.

Je uitleg in de diverse posts hierboven (na de post van gisteren 21:33) lijken niet te kloppen. En sorry dat ik het moet zeggen, maar je komt nog niet eens in de buurt, ook al klonk het in eerste instantie aardig geloofwaardig.

Eerst even wat feiten.

1. Ik ben netto gebruiker, dus neem in een jaar meer af dan ik teruglever, waardoor ik ook alle belastingen kan verrekenen bij het terugleveren.
2. Als de stroom 20 cent inkoop kost, dan moet die verkoop minimaal 20/0,8 (RTE) + 2,5 (inkoopvergoeding) = 27,5 cent opleveren voor break even. Dat is een spread van 37,5%. Bij een lagere stroomprijs wordt dat nog meer: bij 10 cent zelfs 50% en dan verdien ik dus nog geen cent, dus de spread moet hoger zijn dan dat. En dan heb ik de afschrijving van de batterij nog niet eens meegerekend.

Dan terug naar het nu. Dit is de grafiek van vandaag. En dan heb ik gekozen voor 16 kwartieren inkoop en 12 kwartieren verkoop.



Op een dag als vandaag zou ik dan niets inkopen en niets verkopen als ik jouw advies volg omdat ik die spread van 37,5% lang niet haal.
En omdat je zegt dat ik ook geen NOM moet draaien, doe ik nix met de vulling van mijn batterijen en moet ik alle 24 uren stroom inkopen voor ruim 27 cent x 500W x 24 uur = 3,25 euro volgens jou:

Pakhaas schreef op maandag 4 mei 2026 @ 22:48:
NOM is en blijft nu nee, puur economisch bekeken. Goedkope uren laden, dure uren ontladen.

Intussen vullen mijn panelen zich zelfs op een druilerige dag als gisteren voldoende om nog 2 uren terug te kunnen leveren aan het net, wat me 20-22 cent per kWh opleverde: 4,8 kW x 2 uur x 21 cent = 2 euro en houd ik voldoende over om de nacht door te komen tot de PV weer op gang komt.

Ergo:
Zou ik jouw redenering volg dan kost vandaag me 3,25.
Als ik eigenwijs ben en wel NOM draai en bovendien tijdens de 2 duurste uren teruglever vandaag tegen ruim 30 (piektarief vandaag) - 2,5 (terugleverkosten) = 27,5 cent x 4,8 kW dan kost me dat nix in het verbruik (NOM) en vang ik zelfs ca. 2,65 euro voor het terugleveren van het overschot van de dag.
Dat is een verschil van bijna 6 euro op één dag!
En met jouw advies herhaalt iets soortgelijks zich elke dag dat die spread niet bereikt wordt. Dat gaat me dus een hoop geld kosten.

Daarom ben ik blij met mijn NOM en lever ik vaak 3 tot 4 uur per etmaal terug tegen de dan hoogste prijzen.
Ja, er zullen dagen zijn dat ik wél die spread haal en dan kan ik kijken of in- en verkoop die dag wél rendabel kunnen zijn. Maar dan moet het dus zó rendabel zijn dat het de winst die ik hierboven beschrijf nog eens overstijgt.

[gielz]

Mistraller schreef op dinsdag 5 mei 2026 @ 02:02:
Ik voel me ergens heel dom, maar de Gielz integratie, al dan niet met proxy, krijg ik niet soepel werkend en is bij mij bijzonder instabiel.
Ik heb alles volgens de instructies ingericht, de data van beide zendures verschijnt in het dashboard, HEMS is uitgevinkt; en beide hebben een "uitstekende" wifi verbinding.
So far so good....Echter is mijn hele HA daarna een heel stuk meer unresponsive, en ik zie ook steeds de connectie wegschieten, dan is de data op het dashboard tijdelijk op unavailable. (gaps in de graphs).
Ik kan in het Gielz dash "Snel ontladen en snel Opladen" activeren; en dan worden de ingestelde waardes toegepast.
NOM, handmatig doet echter niets. De zendures blijven op standby staan.

Ik had het nachtje eerder ook al getest, en toen was in de ochtend mijn HA gecrashed.

NodeRed heb ik als addon app geinstalleerd binnen ha.
Mijn HA draaide tot nu toe soepel in een KVM up een ubuntu laptop (vraag me af of dit er iets toedoet maar goed)

Om nodeRed even uit te sluiten heb ik de flow gedisabled en in Gielz het IP van 1 zendure ingesteld.
Verbinding lijkt dan iets stabieler, maar ook hier kan ik niet Handmatig een wattage instellen, NOM doen, slechts max ontladen en max laden. En opvragen van de automations pagina in de settings duurt ineens dik 10 seconden.

Ik heb van alle files de NL versie gebruikt. En overal de nieuwste versie.

Ik heb geen idee waar dit nu aan ligt, het lijkt wel een te zware integratie voor mijn HA? Nooit eerder gezien dit gedrag. Maar gekke is dus ook dat ik maar een paar modi werkend kan krijgen. (handmatig had het zeker moeten doen)

De automation heb ik nog omgezet naar trigger op de P1 sensor ipv die 5 seconden trigger om te kijken wat het doet; maar lijkt eerder slechter te werken (dacht dat ik dit begrepen had uit het grote zendure topic; omdat ik nog een dsmr4 heb leek me dit zinvol.

Als je bepaalde sturingen doet moet je dit terug zien in het logbook. Hoe ziet deze er uit?

En installeer even https://www.home-assistant.io/integrations/systemmonitor/

[Pakhaas]

@Hippe Lip je mist in je berekening de opportunity costs die je hebt als je PV overschot opslaat in je batterij voor later verbruik. Overschot van je PV is niet gratis. Die vertegenwoordigd een prijs die je anders had gekregen als je het direct had teruggeleverd zonder RTE verliezen. Verder wil ik het hier bij laten. Dit topic gaat voornamelijk over HA icm Zendure.

[Mimiix]

Mistraller schreef op dinsdag 5 mei 2026 @ 02:02:
Ik voel me ergens heel dom, maar de Gielz integratie, al dan niet met proxy, krijg ik niet soepel werkend en is bij mij bijzonder instabiel.
Ik heb alles volgens de instructies ingericht, de data van beide zendures verschijnt in het dashboard, HEMS is uitgevinkt; en beide hebben een "uitstekende" wifi verbinding.
So far so good....Echter is mijn hele HA daarna een heel stuk meer unresponsive, en ik zie ook steeds de connectie wegschieten, dan is de data op het dashboard tijdelijk op unavailable. (gaps in de graphs).
Ik kan in het Gielz dash "Snel ontladen en snel Opladen" activeren; en dan worden de ingestelde waardes toegepast.
NOM, handmatig doet echter niets. De zendures blijven op standby staan.

Ik had het nachtje eerder ook al getest, en toen was in de ochtend mijn HA gecrashed.

NodeRed heb ik als addon app geinstalleerd binnen ha.
Mijn HA draaide tot nu toe soepel in een KVM up een ubuntu laptop (vraag me af of dit er iets toedoet maar goed)

Om nodeRed even uit te sluiten heb ik de flow gedisabled en in Gielz het IP van 1 zendure ingesteld.
Verbinding lijkt dan iets stabieler, maar ook hier kan ik niet Handmatig een wattage instellen, NOM doen, slechts max ontladen en max laden. En opvragen van de automations pagina in de settings duurt ineens dik 10 seconden.

Ik heb van alle files de NL versie gebruikt. En overal de nieuwste versie.

Ik heb geen idee waar dit nu aan ligt, het lijkt wel een te zware integratie voor mijn HA? Nooit eerder gezien dit gedrag. Maar gekke is dus ook dat ik maar een paar modi werkend kan krijgen. (handmatig had het zeker moeten doen)

De automation heb ik nog omgezet naar trigger op de P1 sensor ipv die 5 seconden trigger om te kijken wat het doet; maar lijkt eerder slechter te werken (dacht dat ik dit begrepen had uit het grote zendure topic; omdat ik nog een dsmr4 heb leek me dit zinvol.

Op wat voor hardware draait HA (SSD/HDD, CPU)? Ik vermoed dat je HA host gewoon te traag is om bij te blijven. Een ander issue kan een defecte ethernet kabel zijn, waardoor de throughput fout gaat. Eventueel zou een DHCP issue kunnen spelen, waarbij je meerdere devices met hetzelfde IP hebt maar dat is wel heel ver gezocht.

[Mistraller]

gielz schreef op dinsdag 5 mei 2026 @ 07:13:
[...]


Als je bepaalde sturingen doet moet je dit terug zien in het logbook. Hoe ziet deze er uit?

En installeer even https://www.home-assistant.io/integrations/systemmonitor/
[Afbeelding]

Goeie tip; ik had inderdaad wel naar de resources gekeken maar ik had inderdaad nog geen goede history. Uit de logs lijken simpelweg de acties te missen.

Mimiix schreef op dinsdag 5 mei 2026 @ 08:14:
[...]


Op wat voor hardware draait HA (SSD/HDD, CPU)? Ik vermoed dat je HA host gewoon te traag is om bij te blijven. Een ander issue kan een defecte ethernet kabel zijn, waardoor de throughput fout gaat. Eventueel zou een DHCP issue kunnen spelen, waarbij je meerdere devices met hetzelfde IP hebt maar dat is wel heel ver gezocht.

Uiteraard ook mijn eerste gedachte. Die laptop waar het geheel op draait is al een oudje inderdaad. Maar met 900 entiteiten, ZHA, influx, grafana, een heleboel kleine integraties, en relatief eenvoudige automations tot nu toe altijd als een zonnetje.
Draait op een SSD. duplicate IP gaat je HA niet van op z'n gat Maar nee, ik heb de zendures een reserved IP in de router gegeven en ik kan ze verder prima zien in de app. En ik heb nooit netwerk issues gehad, zou sterk zijn als dat nu ineens aan het licht komt.

Echter: Resources lijkt wel de basis te zijn van de problemen. Ik zag dat hij enorm heeft staan swappen, tot ongeveer 6u vannacht, toen was ha core volgens mij gecrashed. En toen had ik dus node-red al gestopt en gielz naar 1 zendure laten kijken.
Helaas is ram uitbreiding voor die laptop bizar duur. Ik had 2GB toegewezen aan de VM, omdat de host slechts 4gb heeft. Nu de vm naar 2,5gig gezet en dat lijkt wel te helpen.
Dus ik hou het even in de gaten. Het lijkt wel by far de meest resource intensieve toevoeging op mijn HA instance die ik tot nu toe gezien heb, en dat zag ik niet aankomen; ik meen dat er geen minimale system resources waren opgegeven. Als blijkt dat ik daaronder zit is het misschien slim om in de prerequisites op te nemen. Dan zal ik nog wel eens meer testen, ik heb nog een andere laptop waar nieuwer type geheugen in gaat (en ook al zit). Reden voor laptop? Backup power

Dus ik ga het nog eens met de system monitor integration bekijken.

Tot zover alvast bedankt voor het meedenken!


Edit: Node-RED weet aangezet, en sommige stappen in de flow duren naar mijn idee wel érg lang . Gekke is dat het lijkt dat ie met zendure 3 wil connecten, maar die staat gewoon op "". (Call 3 zendure API; econn reset)
Swap usage in HA loopt weer op. Lijkt wel een memory leak?

[core-ssh ~]$ free -h
total used free shared buff/cache available
Mem: 2.4G 1.5G 36.1M 4.1M 864.6M 989.7M
Swap: 815.1M 348.4M 466.7M

[ Voor 7% gewijzigd door Mistraller op 05-05-2026 10:46 ]

[Hippe Lip]

Pakhaas schreef op dinsdag 5 mei 2026 @ 07:53:
@Hippe Lip je mist in je berekening de opportunity costs die je hebt als je PV overschot opslaat in je batterij voor later verbruik. Overschot van je PV is niet gratis. Die vertegenwoordigd een prijs die je anders had gekregen als je het direct had teruggeleverd zonder RTE verliezen.

Je hebt gelijk, @Pakhaas. Die heb ik gemist.

Verder wil ik het hier bij laten. Dit topic gaat voornamelijk over HA icm Zendure.

[ Voor 11% gewijzigd door Hippe Lip op 05-05-2026 12:11 ]