Zendure producten in Home Assistant integreren deel 2

[klump4u]

Tijgerkracht schreef op dinsdag 23 september 2025 @ 17:11:
[...]


Hier mag de stroom niet van de accu naar de auto, je hebt dan 2x omvormer verlies, dus dat blokkeer ik zoveel mogelijk

Die snap ik niet? Naar de vaatwasser is toch ook 2 keer verlies?

[gielz]

klump4u schreef op dinsdag 23 september 2025 @ 19:37:
[...]

Die snap ik niet? Naar de vaatwasser is toch ook 2 keer verlies?

Zit het niet zo?

Zon naar Batterij naar huis DC > AC > DC > AC
Zon naar Batterij naar auto DC > AC > DC > AC > DC > AC
Zon naar Batterij naar vaatwasser DC > AC > DC > AC

[klump4u]

gielz schreef op dinsdag 23 september 2025 @ 19:42:
[...]


Zit het niet zo?

Zon naar Batterij naar huis DC > AC > DC > AC
Zon naar Batterij naar auto DC > AC > DC > AC > DC > AC
Zon naar Batterij naar vaatwasser DC > AC > DC > AC

Klopt wel maar als ik de auto uit het net laadt dan heb ik ook AC>DC, dus waar zit de winst?

[gielz]

klump4u schreef op dinsdag 23 september 2025 @ 20:07:
[...]

Klopt wel maar als ik de auto uit het net laadt dan heb ik ook AC>DC, dus waar zit de winst?

Heb zelf geen EV maar ik zou zeggen je laad hem op uit de batterij is 15% extra verlies. Die heb je dan niet als je hem direct van uit het net vol knalt. Maar is wellicht meer voor een ander topic

[klump4u]

gielz schreef op dinsdag 23 september 2025 @ 20:12:
[...]


Heb zelf geen EV maar ik zou zeggen je laad hem op uit de batterij is 15% extra verlies. Die heb je dan niet als je hem direct van uit het net vol knalt. Maar is wellicht meer voor een ander topic

Het wordt regelmatig hier naar voren gebracht om er een automatiek van te maken, die extra 15% verlies is dan van de accu neem ik aan? Die heb ik toch ook als ik de accu voor het huishouden gebruik? Ik begrijp niet waar het extra verlies dan in zit.

[Tijgerkracht]

klump4u schreef op dinsdag 23 september 2025 @ 19:37:
[...]

Die snap ik niet? Naar de vaatwasser is toch ook 2 keer verlies?

Uitgaande van een AC2400 die alleen uit het net kan laden

Vaatwasser:
AC->DC-AC->Vaatwasser (2x omzetten)

Electrische auto
AC(net)->DC(accu in)->AC(accu uit)->DC(auto in) als je laad vanuit de batterij
AC(net)->DC(auto in) als je laad vanuit het net (1x omzetten)
Bij laden uit het net heb je dus minder omzet verlies.

[klump4u]

Tijgerkracht schreef op dinsdag 23 september 2025 @ 20:44:
[...]


Uitgaande van een AC2400 die alleen uit het net kan laden

Vaatwasser:
AC->DC-AC->Vaatwasser (2x omzetten)

Electrische auto
AC(net)->DC(accu in)->AC(accu uit)->DC(auto in) als je laad vanuit de batterij
AC(net)->DC(auto in) als je laad vanuit het net (1x omzetten)
Bij laden uit het net heb je dus minder omzet verlies.

Dat zeg ik ook de hele tijd maar het maakt toch niks uit of je nu 2 maal omzet voor je huishouden of 2 maal voor je auto. Die accu maakt het niet uit waaraan je hem leegmaakt de uitgaande kWh blijven toch gelijk.

[Tijgerkracht]

klump4u schreef op dinsdag 23 september 2025 @ 20:49:
[...]

Dat zeg ik ook de hele tijd maar het maakt toch niks uit of je nu 2 maal omzet voor je huishouden of 2 maal voor je auto. Die accu maakt het niet uit waaraan je hem leegmaakt de uitgaande kWh blijven toch gelijk.

Als je de nacht door kan komen met goedkope stroom uit je batterij en de auto opladen niet nee.
Ik laad de EV hier alleen overdag op overschot zonnestroom en kom de nacht dan net door met de Zendure.
Maar ja, ik heb slechts 3x AB3000X

[gielz]

Een tijd geleden had ik eens gekeken wat er in de battery packs voor vermogen voorbij komt en dan uiteindelijk uit de omvormer komt via zenSDK. Niets meer mee gedaan tot de post van @Aardedraadje dat daar wellicht de efficentie uit berekend kan worden.

Sinds gisteren begonnen met testen en dat het plug-n-play is. Dat wil zeggen configuration.yaml paar regeltjes toevoegen en lekker laten draaien.

Zie hier het voorlopige resultaat

[R.K]

Ik gebruik de laatste versie van de @gielz aansturing en automatisering. Lijkt het zelfs beter te doen dan de vorige.
In de nacht zie ik in mijn verbruiks-grafiek een keurige flatline (nom) ik zie echter een trend dat na een dag zonneladen en terugleveren dat de flatline niet automatisch terugkomt, ik schakel dan van nom naar een andere modus en weer terug naar nom, en dan werkt het weer goed. Waar kan dit aan liggen? Zie het streepje bij 18.50 uur.

[ Voor 31% gewijzigd door R.K op 24-09-2025 19:35 ]

[gielz]

R.K schreef op woensdag 24 september 2025 @ 19:31:
Ik gebruik de laatste versie van de @gielz aansturing en automatisering. Lijkt het zelfs beter te doen dan de vorige.
In de nacht zie ik in mijn verbruiks-grafiek een keurige flatline (nom) ik zie echter een trend dat na een dag zonneladen en terugleveren dat de flatline niet automatisch terugkomt, ik schakel dan van nom naar een andere modus en weer terug naar nom, en dan werkt het weer goed. Waar kan dit aan liggen? Zie het streepje bij 18.50 uur.[Afbeelding]

Ziet er heel goed uit! Wat je hier ziet is het moment dat de zon weg is en hij over moet gaan op ontladen om weer naar 0 te balanceren. Het start gedrag staat op 100 watt ingesteld en daarna zal hij naar 0 gaan balanceren.

Ik denk trouwens dat je niet de nieuwste automatisering hebt. In die van jou zit nog uitgesteld laden wat in de nieuwe versie niet meer zit. Je kunt dit zien in de automatisering description daar staat een versie datum.

[R.K]

Ik gebruik deze versie, van de week van github gehaald.

[gielz]

R.K schreef op woensdag 24 september 2025 @ 20:02:
Ik gebruik deze versie, van de week van github gehaald.[Afbeelding]

Dat is inderdaad de huidige versie, maar ziet er goed uit hoor. Heb je zelf iets gemaakt voor uitgesteld laden want ik zou dat export gedeelte in de ochtend niet verwachten alvorens hij gaat laden.

[R.K]

gielz schreef op woensdag 24 september 2025 @ 19:55:
[...]


Ziet er heel goed uit! Wat je hier ziet is het moment dat de zon weg is en hij over moet gaan op ontladen om weer naar 0 te balanceren. Het start gedrag staat op 100 watt ingesteld en daarna zal hij naar 0 gaan balanceren.

Dus als ik modus Nul op de meter draai de hele dag zou die flatline vanzelf terug moeten komen?

[R.K]

gielz schreef op woensdag 24 september 2025 @ 20:04:
[...]


Dat is inderdaad de huidige versie, maar ziet er goed uit hoor. Heb je zelf iets gemaakt voor uitgesteld laden want ik zou dat export gedeelte in de ochtend niet verwachten alvorens hij gaat laden.

Klopt, ik heb zelf iets gemaakt waardoor hij duurste uur exporteert. En dat was toevallig vanochtend.

[ Voor 4% gewijzigd door R.K op 24-09-2025 21:42 ]

[gielz]

R.K schreef op woensdag 24 september 2025 @ 20:06:
[...]


Dus als ik modus Nul op de meter draai de hele dag zou die flatline vanzelf terug moeten komen?

Klopt, zodra hij 100+ watt aanraakt gaat hij starten met ontladen en naar 0 watt toe. Mocht dit niet het geval zijn dan hoor ik dat graag dan kijken wij er even samen naar via DM. Wellicht heb je dan een bug gevonden.

Hier werkt het al maanden exact zoals een Homewizard PiB NOM draait.

[Aardedraadje]

Ik ben er nog wat mee aan het spelen maar deel graag alvast een voorlopig resultaat van een demping die ik aan het proberen ben.

Mij slimme meter (Kaifa, DSMR4) spoort niet helemaal. Ten eerste stuurt hij elke 10s een datagram, maar is de meting niet van de afgelopen 10s. Eerder een gemiddelde van de afgelopen 20-30 seconden.

Ten tweede gaat hij niet goed om met kleine schommelingen rond de nul. Het lijkt wel alsof hij soms vergeet om het teken (positief/negatief) om te wisselen en daarna met een extra grote stap de andere kant op even corrigeert. Het gevolg:



Zowel HW als Gielz aansturing hebben hier last van.

Vannacht geNOMd met de volgende wijzigingen:
- Elke regelactie wordt gedempt. De nieuw berekende stuurwaarde wordt voor slechts 50% meegenomen. De oude stuurwaarde geldt ook voor 50%.
- Wanneer ik binnen 20W van de gewenste waarde zit, geldt de nieuwe stuurwaarde voor 10%. De oude stuurwaarde voor 90%.

Vooral dat laatste helpt bij mijn meter enorm, omdat de meter dus niet lekker omgaat met het nulpunt. Dit levert het volgende plaatje op. Spot het punt waar ik overschakel naar de PiB



Ik moet deze bevindingen ook maar terugkoppelen aan HW. Maar man wat is het leuk om hier gewoon zelf mee te kunnen spelen.

[Mediacj]

Aardedraadje schreef op donderdag 25 september 2025 @ 05:55:
Mij slimme meter (Kaifa, DSMR4) spoort niet helemaal. Ten eerste stuurt hij elke 10s een datagram, maar is de meting niet van de afgelopen 10s. Eerder een gemiddelde van de afgelopen 20-30 seconden.

Ten tweede gaat hij niet goed om met kleine schommelingen rond de nul. Het lijkt wel alsof hij soms vergeet om het teken (positief/negatief) om te wisselen en daarna met een extra grote stap de andere kant op even corrigeert. Het gevolg:

Zou voor mij een reden zijn om bij de netbeheerder te zeuren voor een nieuwe DSMR5 meter

[DrNickB]

Aardedraadje schreef op donderdag 25 september 2025 @ 05:55:
Zowel HW als Gielz aansturing hebben hier last van.

Vannacht geNOMd met de volgende wijzigingen:
- Elke regelactie wordt gedempt. De nieuw berekende stuurwaarde wordt voor slechts 50% meegenomen. De oude stuurwaarde geldt ook voor 50%.
- Wanneer ik binnen 20W van de gewenste waarde zit, geldt de nieuwe stuurwaarde voor 10%. De oude stuurwaarde voor 90%.

Zou je een code snippet kunnen delen an je berekeningen(als dat hier past)?
Heb hier zelf ook last van, heb wel updates elke seconde, en al mijn sensoren updaten bij wijziging,
Alleen als bijvoorbeeld de inductie kookplaat aanstaat, op een 'warm houdt standje' dan schiet hij per seconde aan en uit, wat pieken opleverd en hij heel veel corrigeert. (Gielz update zelf elke 4 sec)

Heb zelf nog geen echte logica om echt te detecteren of het de kook plaat is en daarop weer te gaan sturen, dus een iets minder heftige op en neer zou ook cool zijn in dit geval.

[gielz]

DrNickB schreef op donderdag 25 september 2025 @ 18:57:
[...]


Zou je een code snippet kunnen delen an je berekeningen(als dat hier past)?
Heb hier zelf ook last van, heb wel updates elke seconde, en al mijn sensoren updaten bij wijziging,
Alleen als bijvoorbeeld de inductie kookplaat aanstaat, op een 'warm houdt standje' dan schiet hij per seconde aan en uit, wat pieken opleverd en hij heel veel corrigeert. (Gielz update zelf elke 4 sec)

Heb zelf nog geen echte logica om echt te detecteren of het de kook plaat is en daarop weer te gaan sturen, dus een iets minder heftige op en neer zou ook cool zijn in dit geval.

Heb je ook gekeken wat dat pingpongen kost? Hier bijvoorbeeld vanavond 0,141kwh import door inductie koken (3 pitten). Je zou dit bijvoorbeeld kunnen detecteren door een HW energysocket op de afzuigkap. Maar dan zal je waarschijnlijk wel een stuk meer gaan exporteren tijdens die kookbeurt.



Bij de Homewizard PIB zag ik exact dit zelfde gedrag.

[DrNickB]

gielz schreef op donderdag 25 september 2025 @ 19:32:
[...]
Heb je ook gekeken wat dat pingpongen kost?

Het is zeker geen verwijd op de automatisering.
Want hij werkt verder prima.

Het kost me 'niks', sf800p kan toch me kookplaat niet volledig leveren. Mag nog salderen onder de 500kwh zonder kosten (pas net 2weken panelen).
Ik weet alleen niet hoe goed het is om van 800 naar 200 en weer terug te gaan om de 4 sec. Voor de hardware.

Me led tv is ook te merken met verschillende kleuren en intensiteit, schier verbruik ook op en neer.

Ik heb geen stekker plugs over en voor ik die investeringen eruit heb, met de winst dat het zou opleveren, ben ik 50jaar verder.

Zit deze dagen nog op 98% zonnestroom gebruik, dus mijn doel is tot dusverre prima gehaald.

[Aardedraadje]

DrNickB schreef op donderdag 25 september 2025 @ 18:57:
[...]


Zou je een code snippet kunnen delen an je berekeningen(als dat hier past)?
Heb hier zelf ook last van, heb wel updates elke seconde, en al mijn sensoren updaten bij wijziging,
Alleen als bijvoorbeeld de inductie kookplaat aanstaat, op een 'warm houdt standje' dan schiet hij per seconde aan en uit, wat pieken opleverd en hij heel veel corrigeert. (Gielz update zelf elke 4 sec)

Heb zelf nog geen echte logica om echt te detecteren of het de kook plaat is en daarop weer te gaan sturen, dus een iets minder heftige op en neer zou ook cool zijn in dit geval.

Sure!

Ik heb het alleen nog toegepast voor de actie zendure_x_ontladen_balanceren:

code:

outputLimit: >-
  {% set demping = states('input_number.nulregeling_demper') | float(0) %}
  {% set regel_grens = states('input_number.nulregeling_bandbreedte') | float(0) %}
  {% set cap = 2400 %}
  {% set correctie = states('input_number.nulregeling_ontladen_correctie') | float(0) %}
  {% set p1 = states('sensor.p1_meter_active_power') | float(0) %}
  {% set huidig = states('sensor.zendure_2400_ac_vermogen_aansturing') | float(0) %}
  {% set totaal = (p1 - huidig - correctie) %}
  {% set nieuw = [ [totaal, 0] | max, cap ] | min %}
  {% set verschil = (p1 - correctie) | abs %}
  {% if verschil <= regel_grens %}
    {{ ((0.1 * nieuw) | round(0, "floor") - (0.9 * huidig) | round(0)) | int }}
  {% else %}
    {{ ((demping * nieuw) - ((1-demping) * huidig)) | int }}
  {% endif %}

Dan heb ik de volgende input number helpers aangemaakt die ik in de UI kan aanpassen:
input_number.nulregeling_demper: Dempt de respons, in mijn geval staat die op 0.5.
input_number.nulregeling_bandbreedte: Bij hoeveel verschil vanaf de gewenste waarde sta je slechts langzame wijzigingen toe. Staat bij mij op 25W.
input_number.nulregeling_ontladen_correctie: Waar regel je naartoe. Staat in mijn geval op -5W. voegt weinig toe om in de UI te hebben, maar ik wilde er wat mee spelen.

Het werkt nog niet perfect en zoals @gielz al zegt, eigenlijk kan het schommelen weinig kwaad. Maar ik heb zo wel mijn nachtelijke import/export kunnen verbeteren van 0.02 kWh per uur import en export, naar 0.01 export en geen import. Volgens de niet-zo-slimme meter dan

[DrNickB]

Aardedraadje schreef op vrijdag 26 september 2025 @ 05:33:
[...]
Sure!

Thnx!
altijd leuk om verschillende ideeën en oplossingen te zien en kijken hoe het uitpakt.
Met me kookplaat zit er misschien wat winst in, om hem minder te laten schommelen,
terwijl misschien met grote hoge last (koffie apparaat) dat hij wat minder snel 'bij' is.

[Taro]

@FireSon Ik zie dat in 1.1.4 pre 7 de 4x SF800's op NOM constant aan het klapperen zijn:



De bypass gaat uit, export op 0. Ik heb zelf een script lopen dat dat direct weer corrigeert want ik wil immers dat de 3x2400AC met dat overschot gaan laden en zo NOM houden ipv de export van de SF800 micro-omvormers te beperken.

Ik heb hun Fuse groups al op de optie staan: Niet gebruikt, maar ze worden dus wél door de integratie aangestuurd en dit is niet de juiste manier. Ik verwacht dat de accu's gaan laden om NOM te houden ipv dat de 4xSF800's worden uitgeschakeld.

Kan je een optie opnemen om een device helemaal uit te sluiten van deelname aan de integratie?

Zo ziet dat er uit binnen 20 minuten, heb ze dus alle 4 inmiddels in een secundair account zitten om dit te voorkomen:

[ Voor 14% gewijzigd door Taro op 26-09-2025 12:18 ]

[gielz]

Hier nog geen dynamisch contract (ze willen mij wel heel graag weg hebben. huidige contract is zeer slecht voor mijn leverancier). Maar ben al wel alvast begonnen om voor 2027 Dynamisch NOM in te bouwen binnen mijn zenSDK sturing (plug-n-play).

Het idee is dat hij vol automatisch zijn NOM doet en op de goedkoopste x uren die je instelt gaat bijladen indien voldoende spread wat in de winter wel noodzakelijk is. Nu zit ik alleen even met die spread. Ik kijk nu naar het gemiddelde tarief van de ingestelde laaduurtjes en kijk vervolgens naar de overige niet goedkope uren wat dan de spread zou zijn. Dit omdat je immers in de niet goedkope uren die geladen stroom NOM gaat in zetten.

Zit ik dan zo goed als dynamische noob? En hoeveel spread wil je eigenlijk zon beetje hebben om überhaupt op te laden in de winter van 2027? Er word dus niet op de duurste uren ontladen in deze modus.

Ook moet het allemaal mooi visueel. Hier onder zie je dus heel duidelijk wat de prijzen zijn, waar je op dit moment wat betreft tijd van de dag zit en in het grijs welke uren hij voor je zal gaan laden.

[Devke]

gielz schreef op vrijdag 26 september 2025 @ 12:28:
Hier nog geen dynamisch contract (ze willen mij wel heel graag weg hebben. huidige contract is zeer slecht voor mijn leverancier). Maar ben al wel alvast begonnen om voor 2027 Dynamisch NOM in te bouwen binnen mijn zenSDK sturing (plug-n-play).

Het idee is dat hij vol automatisch zijn NOM doet en op de goedkoopste x uren die je instelt gaat bijladen indien voldoende spread wat in de winter wel noodzakelijk is. Nu zit ik alleen even met die spread. Ik kijk nu naar het gemiddelde tarief van de ingestelde laaduurtjes en kijk vervolgens naar de overige niet goedkope uren wat dan de spread zou zijn. Dit omdat je immers in de niet goedkope uren die geladen stroom NOM gaat in zetten.

Zit ik dan zo goed als dynamische noob? En hoeveel spread wil je eigenlijk zon beetje hebben om überhaupt op te laden in de winter van 2027? Er word dus niet op de duurste uren ontladen in deze modus.

Ook moet het allemaal mooi visueel. Hier onder zie je dus heel duidelijk wat de prijzen zijn, waar je op dit moment wat betreft tijd van de dag zit en in het grijs welke uren hij voor je zal gaan laden.

[Afbeelding]

Ga uit van een 80% RTE. Ga je afschrijving meenemen? Want dan zal 3 zonder te rekenen al te weinig zijn. Ik denk dat er nog wel een groot aantal mensen is die de batterijen (deels) weer legen op de duurste uren. Hier gaan ze compleet leeg nog steeds. Dit zijn 2 verschillende situaties.

[Taro]

gielz schreef op vrijdag 26 september 2025 @ 12:28:
Hier nog geen dynamisch contract (ze willen mij wel heel graag weg hebben. huidige contract is zeer slecht voor mijn leverancier). Maar ben al wel alvast begonnen om voor 2027 Dynamisch NOM in te bouwen binnen mijn zenSDK sturing (plug-n-play).

Het idee is dat hij vol automatisch zijn NOM doet en op de goedkoopste x uren die je instelt gaat bijladen indien voldoende spread wat in de winter wel noodzakelijk is. Nu zit ik alleen even met die spread. Ik kijk nu naar het gemiddelde tarief van de ingestelde laaduurtjes en kijk vervolgens naar de overige niet goedkope uren wat dan de spread zou zijn. Dit omdat je immers in de niet goedkope uren die geladen stroom NOM gaat in zetten.

Zit ik dan zo goed als dynamische noob? En hoeveel spread wil je eigenlijk zon beetje hebben om überhaupt op te laden in de winter van 2027? Er word dus niet op de duurste uren ontladen in deze modus.

Ook moet het allemaal mooi visueel. Hier onder zie je dus heel duidelijk wat de prijzen zijn, waar je op dit moment wat betreft tijd van de dag zit en in het grijs welke uren hij voor je zal gaan laden.

[Afbeelding]

Zou het een optie zijn om de input van een aantal velden of bekende waardes in de spread berekening mee te nemen?

• Gemiddelde RTE (kan invoerveld, of automatische berekening zijn)
• Afschrijving per kWh
• Minimale marge in ct/kWh

Kan mij voorstellen dat de een die minimale marge op 0 zet, de ander wil pas een cycle opofferen of stopcontacten belasten boven de 5 ct/kWh marge, etc.

Op die manier kan je kijken naar welke lage en hoge prijzen in aanmerking komen om na aftrek van RTE, afschrijving en minimale gewenste marge wel of niet in te laden en ontladen. Maar dit kan al heel snel complex worden, want neem je bijv. de volgende dag ook mee in je berekening?

[gielz]

Taro schreef op vrijdag 26 september 2025 @ 14:38:
[...]

Zou het een optie zijn om de input van een aantal velden of bekende waardes in de spread berekening mee te nemen?

• Gemiddelde RTE (kan invoerveld, of automatische berekening zijn)
• Afschrijving per kWh
• Minimale marge in ct/kWh

Kan mij voorstellen dat de een die minimale marge op 0 zet, de ander wil pas een cycle opofferen of stopcontacten belasten boven de 5 ct/kWh marge, etc.

Op die manier kan je kijken naar welke lage en hoge prijzen in aanmerking komen om na aftrek van RTE, afschrijving en minimale gewenste marge wel of niet in te laden en ontladen. Maar dit kan al heel snel complex worden, want neem je bijv. de volgende dag ook mee in je berekening?

Ik wil het eigenlijk zo simpel mogelijk houden. Bijvoorbeeld je vult in hoeveel goedkope uren je een beetje wenselijk vind. Daarna komt er een % spread uit en als deze boven een bepaald % is zal hij deze uren gaan laden. Die te behalen spread % is dan instelbaar maar onder de 25% is het zonder afschrijving al niet rendabel bij 80% rte. (of ik heb het mis?)

Voor nu kijkt hij alleen naar vandaag, dat eerst maar goed en makkelijk laten werken.

[Taro]

gielz schreef op vrijdag 26 september 2025 @ 17:29:
[...]


Ik wil het eigenlijk zo simpel mogelijk houden. Bijvoorbeeld je vult in hoeveel goedkope uren je een beetje wenselijk vind. Daarna komt er een % spread uit en als deze boven een bepaald % is zal hij deze uren gaan laden. Die te behalen spread % is dan instelbaar maar onder de 25% is het zonder afschrijving al niet rendabel bij 80% rte. (of ik heb het mis?)

Voor nu kijkt hij alleen naar vandaag, dat eerst maar goed en makkelijk laten werken.

Je moet het bedrag incl. BTW pakken (want %), daarna maal de RTE. Dan heb je waardes waar je mee kunt rekenen. Dan zit je met een issue, want dan moet je de afschrijving en gewenste marge nog verrekenen, maar eigenlijk moet je die alleen van de hoge uren afhalen, zodat je het verschil tussen laag en hoog kunt zien en kunt bepalen of het de moeite waard is. Maar welke uren bereken je dat dan mee? Misschien in een array gooien, sorteren van laag naar hoog en hoog naar laag, dan eerst voor de 1e, dan voor de 2e controleren, etc. tot het punt dat de spread negatief is en dan stop je. Andere uitdaging: Als de hoge uren voor de lage uren liggen, dan heb je niets om mee te ontladen.

Het lijkt heel simpel, maar ik heb bijv. heel bewust mijn strategie hierop ingericht:

3 duurste uren in de avond ontladen, dan NOM, dan duurste 2 uren in de ochtend ontladen, zodat ze leeg zijn, en onder een bepaald bedrag laden wat soms ook al vroeger is dan de 2 duurste uren in de ochtend, maar dat is dan dus prima aangezien daar al ruimte voor was omdat er al 3 uren + NOM was ontladen. Zo is er altijd capaciteit beschikbaar.

In de lente en zomer is dit overigens nog iets geoptimaliseerd vs herst en winter, dan wordt er minder uren ontladen en tussendoor altijd NOM ipv Smart Discharge en Smart Charge gebruikt om alle zonnestroom op te slaan. Daarnaast heb ik knopjes voor wel/niet goedkoop manueel inkopen en opties om die op 15, 17 of 20 cent in te stellen, of gewoon de goedkoopste 5 uren.

Je wil het simpel houden, begrijp ik, maar het is mogelijk complexer dan je verwacht. Hopelijk lukt het je en ik wil zeker meedenken/meehelpen, maar benieuwd welke obstakels er gaandeweg naar voren komen.

[qltel]

Goedemiddag.

Ik heb vandaag mijn Hyper 2000 met AB2000X ontvangen. App geïnstalleerd, firmware geupdate, de Fireson integratie geïnstalleerd en ik zie alle gegevens keurig in HA. Ik gebruik Firmware: 1.1.4-pre7. Er hangen geen zonnepanelen aan de Hyper, die zitten namelijk op andere inverters aangesloten.

Het lukt me echter niet om "nul op de meter" te krijgen. De accu laad niet, hij ontlaad niet. Hij doet eigenlijk niets. En ik zie vast iets over het hoofd.





Kan iemand hier me op weg helpen?

Ah, nu ik de Device fusegroup op 800 Watt heb gezet begint hij ineens te ontladen. Dat lijkt dus hetgeen te zijn wat ik over het hoofd zag.

[ Voor 9% gewijzigd door qltel op 27-09-2025 15:32 ]

[DJN]

qltel schreef op zaterdag 27 september 2025 @ 15:06:
Goedemiddag.

Ik heb vandaag mijn Hyper 2000 met AB2000X ontvangen. App geïnstalleerd, firmware geupdate, de Fireson integratie geïnstalleerd en ik zie alle gegevens keurig in HA. Ik gebruik Firmware: 1.1.4-pre7. Er hangen geen zonnepanelen aan de Hyper, die zitten namelijk op andere inverters aangesloten.

Het lukt me echter niet om "nul op de meter" te krijgen. De accu laad niet, hij ontlaad niet. Hij doet eigenlijk niets. En ik zie vast iets over het hoofd.

[Afbeelding]

[Afbeelding]

Kan iemand hier me op weg helpen?

Device fusegroep staat niet goed. Fireson integratie pakt Hyper zo niet mee. Je kunt deze bv op ‘apparaat is aangesloten op aparte groep of fase’ zetten

[qltel]

DJN schreef op zaterdag 27 september 2025 @ 15:33:
[...]


Device fusegroep staat niet goed. Fireson integratie pakt Hyper zo niet mee. Je kunt deze bv op ‘apparaat is aangesloten op aparte groep of fase’ zetten

Ik had het net gevonden. Dat was het inderdaad!

[markduffy]

Ik ben nog vrij nieuw in HA. Dus nog best wel zoekende.
Nu probeer ik uit de startpost de configuratie YAML te implementeren, maar loop beetje vast omdat ik 2 sets heb.

Kunnen jullie mij beetje opweg helpen?
Ik heb nog niet alle regels overgenomen, omdat mij op een gegeve moment op begon te vallen dat ik sommige dingen volgens mij er nu niet in kan zetten omdat ik 2 sets heb.
En loop dus o.a. vast op de unique_ids omdat ik 2 apparaten heb. En kan van bijvoorbeeld onderstaand deze niet vinden (zie t niet tussen entiteiten of statussen) Dus kan daardoor ook niet de vervangende vinden.
unique_id: Zendure_2400_AC_Batterij_1_Temperatuur

"Excuus voor de newbie vraag ;)"

code:

 Laad standaard set van integraties. Niet verwijderen.
default_config:

# Laad frontend thema's uit de themes-map
frontend:
  themes: !include_dir_merge_named themes

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

# ============================================================
# Input helpers (blijven hetzelfde, gelden voor beide sets)
# ============================================================
input_select:
  zendure_2400_ac_modus_selecteren:
    name: Zendure 2400 AC Modus Selecteren
    icon: mdi:battery-charging-wireless
    options:
      - Standby
      - Handmatig
      - Nul op de meter
      - Alleen slim ontladen
      - Alleen slim opladen
      - Opladen met 2400 watt
      - Ontladen met 2400 watt

input_number:
  zendure_2400_ac_handmatig_vermogen:
    name: Zendure 2400 AC Handmatig Vermogen
    min: -2400
    max: 2400
    step: 1
    mode: box
    unit_of_measurement: "W"

# ============================================================
# Zendure 1 sensoren
# ============================================================
rest:
  - resource: http://http://192.168.1.XXX/properties/report
    scan_interval: 1
    sensor:
      - name: "Zendure1 Vermogen Export"
        value_template: "{{ value_json['properties']['packInputPower'] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure1 Vermogen Import"
        value_template: "{{ value_json['properties']['outputPackPower'] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure1 Laadpercentage"
        value_template: "{{ value_json['properties']['electricLevel'] }}"
        unit_of_measurement: "%"
        device_class: battery
        state_class: measurement

  # ============================================================
  # Zendure 2 sensoren
  # ============================================================
  - resource: http://http://192.168.1.XX/properties/report
    scan_interval: 1
    sensor:
      - name: "Zendure2 Vermogen Export"
        value_template: "{{ value_json['properties']['packInputPower'] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure2 Vermogen Import"
        value_template: "{{ value_json['properties']['outputPackPower'] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure2 Laadpercentage"
        value_template: "{{ value_json['properties']['electricLevel'] }}"
        unit_of_measurement: "%"
        device_class: battery
        state_class: measurement

  # ============================================================
  # Shelly Input
  # ============================================================
  template:
  - sensor:
      - name: "Shelly Aansturing"
        state: "{{ states('sensor.shelly_total_active_power') | float(0) }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement


# ============================================================
# Rest commands Zendure 1
# ============================================================
rest_command:
  zendure1_opslaan_in_ram:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXXX","properties":{"smartMode": 1 }}'

  zendure1_snel_laden:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXX","properties":{"acMode": 1, "inputLimit": 2400 }}'

  zendure1_stop_met_laden:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXX","properties":{"acMode": 1, "inputLimit": 0 }}'

  zendure1_snel_ontladen:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXXX","properties":{"acMode": 2, "outputLimit": 2400 }}'

  zendure1_stop_met_ontladen:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXX","properties":{"acMode": 2, "outputLimit": 0 }}'

  zendure1_stop_met_alles:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXXX","properties":{"outputLimit": 0, "inputLimit": 0 }}'

  zendure1_standby:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXX","properties":{"smartMode": 0, "outputLimit": 0, "inputLimit": 0 }}'

# ============================================================
# Rest commands Zendure 2
# ============================================================
  zendure2_opslaan_in_ram:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN3XXXX","properties":{"smartMode": 1 }}'

  zendure2_snel_laden:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPNXXXX","properties":{"acMode": 1, "inputLimit": 2400 }}'

  zendure2_stop_met_laden:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN3NXXXX","properties":{"acMode": 1, "inputLimit": 0 }}'

  zendure2_snel_ontladen:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPXXXXX","properties":{"acMode": 2, "outputLimit": 2400 }}'

  zendure2_stop_met_ontladen:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN3XXXXX","properties":{"acMode": 2, "outputLimit": 0 }}'

  zendure2_stop_met_alles:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN3XXXX","properties":{"outputLimit": 0, "inputLimit": 0 }}'

  zendure2_standby:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPXXXXX","properties":{"smartMode": 0, "outputLimit": 0, "inputLimit": 0 }}'

[gielz]

markduffy schreef op zaterdag 27 september 2025 @ 19:09:
Ik ben nog vrij nieuw in HA. Dus nog best wel zoekende.
Nu probeer ik uit de startpost de configuratie YAML te implementeren, maar loop beetje vast omdat ik 2 sets heb.

Kunnen jullie mij beetje opweg helpen?
Ik heb nog niet alle regels overgenomen, omdat mij op een gegeve moment op begon te vallen dat ik sommige dingen volgens mij er nu niet in kan zetten omdat ik 2 sets heb.
En loop dus o.a. vast op de unique_ids omdat ik 2 apparaten heb. En kan van bijvoorbeeld onderstaand deze niet vinden (zie t niet tussen entiteiten of statussen) Dus kan daardoor ook niet de vervangende vinden.
unique_id: Zendure_2400_AC_Batterij_1_Temperatuur

"Excuus voor de newbie vraag ;)"

code:

 Laad standaard set van integraties. Niet verwijderen.
default_config:

# Laad frontend thema's uit de themes-map
frontend:
  themes: !include_dir_merge_named themes

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

# ============================================================
# Input helpers (blijven hetzelfde, gelden voor beide sets)
# ============================================================
input_select:
  zendure_2400_ac_modus_selecteren:
    name: Zendure 2400 AC Modus Selecteren
    icon: mdi:battery-charging-wireless
    options:
      - Standby
      - Handmatig
      - Nul op de meter
      - Alleen slim ontladen
      - Alleen slim opladen
      - Opladen met 2400 watt
      - Ontladen met 2400 watt

input_number:
  zendure_2400_ac_handmatig_vermogen:
    name: Zendure 2400 AC Handmatig Vermogen
    min: -2400
    max: 2400
    step: 1
    mode: box
    unit_of_measurement: "W"

# ============================================================
# Zendure 1 sensoren
# ============================================================
rest:
  - resource: http://http://192.168.1.XXX/properties/report
    scan_interval: 1
    sensor:
      - name: "Zendure1 Vermogen Export"
        value_template: "{{ value_json['properties']['packInputPower'] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure1 Vermogen Import"
        value_template: "{{ value_json['properties']['outputPackPower'] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure1 Laadpercentage"
        value_template: "{{ value_json['properties']['electricLevel'] }}"
        unit_of_measurement: "%"
        device_class: battery
        state_class: measurement

  # ============================================================
  # Zendure 2 sensoren
  # ============================================================
  - resource: http://http://192.168.1.XX/properties/report
    scan_interval: 1
    sensor:
      - name: "Zendure2 Vermogen Export"
        value_template: "{{ value_json['properties']['packInputPower'] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure2 Vermogen Import"
        value_template: "{{ value_json['properties']['outputPackPower'] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure2 Laadpercentage"
        value_template: "{{ value_json['properties']['electricLevel'] }}"
        unit_of_measurement: "%"
        device_class: battery
        state_class: measurement

  # ============================================================
  # Shelly Input
  # ============================================================
  template:
  - sensor:
      - name: "Shelly Aansturing"
        state: "{{ states('sensor.shelly_total_active_power') | float(0) }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement


# ============================================================
# Rest commands Zendure 1
# ============================================================
rest_command:
  zendure1_opslaan_in_ram:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXXX","properties":{"smartMode": 1 }}'

  zendure1_snel_laden:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXX","properties":{"acMode": 1, "inputLimit": 2400 }}'

  zendure1_stop_met_laden:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXX","properties":{"acMode": 1, "inputLimit": 0 }}'

  zendure1_snel_ontladen:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXXX","properties":{"acMode": 2, "outputLimit": 2400 }}'

  zendure1_stop_met_ontladen:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXX","properties":{"acMode": 2, "outputLimit": 0 }}'

  zendure1_stop_met_alles:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXXX","properties":{"outputLimit": 0, "inputLimit": 0 }}'

  zendure1_standby:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN4NXXXX","properties":{"smartMode": 0, "outputLimit": 0, "inputLimit": 0 }}'

# ============================================================
# Rest commands Zendure 2
# ============================================================
  zendure2_opslaan_in_ram:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN3XXXX","properties":{"smartMode": 1 }}'

  zendure2_snel_laden:
    url: http://http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPNXXXX","properties":{"acMode": 1, "inputLimit": 2400 }}'

  zendure2_stop_met_laden:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN3NXXXX","properties":{"acMode": 1, "inputLimit": 0 }}'

  zendure2_snel_ontladen:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPXXXXX","properties":{"acMode": 2, "outputLimit": 2400 }}'

  zendure2_stop_met_ontladen:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN3XXXXX","properties":{"acMode": 2, "outputLimit": 0 }}'

  zendure2_stop_met_alles:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPN3XXXX","properties":{"outputLimit": 0, "inputLimit": 0 }}'

  zendure2_standby:
    url: http://192.168.1.XXX/properties/write
    method: POST
    payload: '{"sn":"HOA1NPXXXXX","properties":{"smartMode": 0, "outputLimit": 0, "inputLimit": 0 }}'

Wil je trouwens met 2 devices gaan NOMen? Dan is de officiële Zendure HA een betere optie omdat deze meerdere devices ondersteund.

[dr.trimble]

ik heb een P1-meter die draait op een ESP32. Hieruit krijg ik volgende waarden: power consumed en power produced. De waarden komen via wifi binnen in HA. Kan ik dit ook gebruiken om de Zendure aan te sturen? ik maak gebruik van ZENSDK.

[martinvdm]

dr.trimble schreef op zondag 28 september 2025 @ 18:52:
ik heb een P1-meter die draait op een ESP32. Hieruit krijg ik volgende waarden: power consumed en power produced. De waarden komen via wifi binnen in HA. Kan ik dit ook gebruiken om de Zendure aan te sturen? ik maak gebruik van ZENSDK.

Ja je kunt iedere p1 meter gebruiken, kun je ingeven in de integratie.

[dr.trimble]

martinvdm schreef op zondag 28 september 2025 @ 20:01:
[...]

Ja je kunt iedere p1 meter gebruiken, kun je ingeven in de integratie.

daar heb ik momenteel mijn zendure P1 meter instaan:
- resource: http://192.168.0.127/properties/report # Zendure P1
scan_interval: 1
sensor:
- name: "P1 Aansturing API v1"
value_template: "{{ value_json['total_power'] }}"
unique_id: P1_Aansturing_API_V1
unit_of_measurement: "W"
state_class: measurement
device_class: power

ik heb echter geen idee hoe ik dat moet aanpassen voor de andere P1-meter (esp32)

[gielz]

dr.trimble schreef op zondag 28 september 2025 @ 20:32:
[...]

daar heb ik momenteel mijn zendure P1 meter instaan:
- resource: http://192.168.0.127/properties/report # Zendure P1
scan_interval: 1
sensor:
- name: "P1 Aansturing API v1"
value_template: "{{ value_json['total_power'] }}"
unique_id: P1_Aansturing_API_V1
unit_of_measurement: "W"
state_class: measurement
device_class: power

ik heb echter geen idee hoe ik dat moet aanpassen voor de andere P1-meter (esp32)

Welke aansturing wil je exact gebruiken? En die P1 esp32 meter, daarvan heb je dus import (in plus wattage) en export (in min wattage) los in Home Assistant per seconden?

[dr.trimble]

gielz schreef op zondag 28 september 2025 @ 20:41:
[...]


Welke aansturing wil je exact gebruiken? En die P1 esp32 meter, daarvan heb je dus import (in plus wattage) en export (in min wattage) los in Home Assistant per seconden?

het is de bedoeling de P1 op de esp32 te gebruiken ipv de zendure P1 aangezien ik die betrouwbaarder vind. ik krijg hier 2 sensoren van: sensor.energiemeter_power_consumed en sensor.energiemeter_power_produced

[gielz]

dr.trimble schreef op zondag 28 september 2025 @ 20:54:
[...]

het is de bedoeling de P1 op de esp32 te gebruiken ipv de zendure P1 aangezien ik die betrouwbaarder vind. ik krijg hier 2 sensoren van: sensor.energiemeter_power_consumed en sensor.energiemeter_power_produced

Maar hoe zien die sensoren er uit in HA en zijn ze per seconden en + en - zoals verwacht. Nog steeds onduidelijk welke sturing je gaat gebruiken.

[dr.trimble]

gielz schreef op zondag 28 september 2025 @ 20:57:
[...]


Maar hoe zien die sensoren er uit in HA en zijn ze per seconden en + en - zoals verwacht. Nog steeds onduidelijk welke sturing je gaat gebruiken.

wat bedoel je met welke sturing?
De sensoren worden elke seconde ge-updated. Beide sensoren zijn positef

[gielz]

dr.trimble schreef op zondag 28 september 2025 @ 21:02:
[...]

wat bedoel je met welke sturing?
De sensoren worden elke seconde ge-updated. Beide sensoren zijn positef

Ga je voor Zendure HA, ZenSDK Gielz of ZenSDK Zelfbouw? Als ze beide positief zijn moet je de export sensor even een min waarde maken de import is prima en dat combineren in een template helper. Vervolgens heb je een werkende P1. ChatGPT kan dit zo voor je maken, vervolgens gooi je die in een sjabloon om te testen alvorens je een echte template aanmaakt.

[dr.trimble]

gielz schreef op zondag 28 september 2025 @ 21:07:
[...]


Ga je voor Zendure HA, ZenSDK Gielz of ZenSDK Zelfbouw? Als ze beide positief zijn moet je de export sensor even een min waarde maken de import is prima en dat combineren in een template helper. Vervolgens heb je een werkende P1. ChatGPT kan dit zo voor je maken, vervolgens gooi je die in een sjabloon om te testen alvorens je een echte template aanmaakt.

aah, ik gebruik de zensdk Gielz. ff zoeken hoe ik dit alles in een helper krijg want ben daar geen krak in ;-).

[DrNickB]

Ik had het zelfde probleem een beetje, mijn USB P1, gaf een Import en een Export waarde, beide positief.
Hiervoor een template sensor aangemaakt in configuration.yaml om deze waardes van elkaar af te trekken.
Hierdoor krijg ik mijn verschil. En deze sensor gebruik ik binnen de gielz code om bijv NOM aan te sturen.

code:

template:
  - sensor:
      - name: "Verbruik en Levering verschil"
        unique_id: verbruik_levering_verschil
        state_class: measurement
        device_class: energy
        state: "{{ states('sensor.electricity_meter_power_consumption_2') | int(0) - states('sensor.electricity_meter_power_production_2') | int(0) }}"
        unit_of_measurement: "Wh"

[dr.trimble]

het maken van de sensor "verbruik en levering verschil" is gelukt maar die blijft steeds op O staan . Enig idee hoe dit komt.
Ik heb de code volledig overgenomen en enkel de naam van de sensoren vervangen

[DrNickB]

dr.trimble schreef op zondag 28 september 2025 @ 21:43:
het maken van de sensor "verbruik en levering verschil" is gelukt maar die blijft steeds op O staan . Enig idee hoe dit komt.
Ik heb de code volledig overgenomen en enkel de naam van de sensoren vervangen

Nee zo snel niet eerlijk gezegd.
Beide waardes / states zijn goed zichtbaar in developerview? hebben een waarde?
Geen type fout gemaakt? Buiten de yaml reload, misschien een HA herstart proberen?

[dr.trimble]

ik heb copy paste gedaan en de sensor blijft op 0. Via developerview zijn waardes ok. Ook herstart gedaan.
De sensoren geven wel het vermogen weer, dus power? Via chatgpt de code veranderd naar onderstaande maar ook hier blijft de waarde van de nieuwe sensor "O"
template:
- sensor:
- name: "Verbruik en Levering verschil"
unique_id: verbruik_levering_verschil
state_class: measurement
device_class: power
unit_of_measurement: "kW"
state: >
{% set verbruik = states('sensor.electricity_meter_power_consumption_2') | float(0) %}
{% set levering = states('sensor.electricity_meter_power_production_2') | float(0) %}
{{ verbruik - levering }}

[gielz]

dr.trimble schreef op maandag 29 september 2025 @ 18:35:
ik heb copy paste gedaan en de sensor blijft op 0. Via developerview zijn waardes ok. Ook herstart gedaan.
De sensoren geven wel het vermogen weer, dus power? Via chatgpt de code veranderd naar onderstaande maar ook hier blijft de waarde van de nieuwe sensor "O"
template:
- sensor:
- name: "Verbruik en Levering verschil"
unique_id: verbruik_levering_verschil
state_class: measurement
device_class: power
unit_of_measurement: "kW"
state: >
{% set verbruik = states('sensor.electricity_meter_power_consumption_2') | float(0) %}
{% set levering = states('sensor.electricity_meter_power_production_2') | float(0) %}
{{ verbruik - levering }}

Kun je vanaf afstand niet echt helpen maar de batterij had zelf ook + bij ontladen en + bij opladen. Dit heb ik toen opgelost door de onderstaande code. Wellicht kun je dit samen met ChatGPT tot een werkende P1 ombouwen;

code:

      - name: "Zendure 2400 AC Vermogen Aansturing"
        value_template: >
          {% set opladen = value_json['properties']['outputPackPower'] | int %}
          {% set ontladen = - (value_json['properties']['packInputPower'] | int) %}
          {% if opladen != 0 %}
            {{ opladen }}
          {% else %}
            {{ ontladen }}
          {% endif %}

[DrNickB]

dr.trimble schreef op zondag 28 september 2025 @ 21:43:
het maken van de sensor "verbruik en levering verschil" is gelukt maar die blijft steeds op O staan . Enig idee hoe dit komt.
Ik heb de code volledig overgenomen en enkel de naam van de sensoren vervangen

Ik zat alleen nog te denken, dat misschien de input waardes in een andere range vallen als wat we hier verwachten.
Mijn p1 waardes heb ik zo ingesteld, dat deze in watt worden uitgestuurd. 1kw is dan ook 1000.
In mijn stukje code heb ik dan ook Wh als unit gebruikt en int (hele getallen) ipv float (komma getallen).
Omdat je wel een 0 als waardes krijgt, lijkt hij toch 'iets' te rekenen.

Wat zijn p1 sensor waardes volgens developer view -> states ?

1 van mijn inputs:

code:

state: 19.0

state_class: measurement
unit_of_measurement: W
device_class: power
friendly_name: Electricity Meter v5 Power consumption

[Bikkelreal]

Vraag Ik gebruik nu de intregatie Cheapest Energy Hours, is er ook iets voor 1 oktober als het naar 15 min gaat?

[DrNickB]

Bikkelreal schreef op maandag 29 september 2025 @ 19:46:
Vraag Ik gebruik nu de intregatie Cheapest Energy Hours, is er ook iets voor 1 oktober als het naar 15 min gaat?

Goede vraag, nog niks over gelezen.
Maar gaat hij ook echt al naar 15min prijzen bij uw leverancier, of worden het wel blokken, maar dan met 1 'uur' prijs,
was laatste wat ik een beetje las tenminste.

[dr.trimble]

[quote]DrNickB schreef op maandag 29 september 2025 @ 19:40:
[...]


Wat zijn p1 sensor waardes volgens developer view -> states ?

mijn waarden zijn uitgedrukt in kW

state: 0.224000006914139

state_class: measurement
unit_of_measurement: kW
device_class: power
friendly_name: Energie uit net

[ Voor 36% gewijzigd door dr.trimble op 29-09-2025 20:30 ]

[Jacqui]

Een paar energieleveranciers met dynamische prijzen, waaronder in ieder geval Tibber, gaan naar kwartierprijzen en volgen daarmee een Europese trend voor betere afstemming van de prijzen. Volgens de aankondiging op hun site, kunnen de prijzen écht iedere 15 minuten veranderen. Op sommige momenten zal dit voordelig voor de consument uitpakken, op andere wellicht nadelig.
Je kunt dan dus ook niet meer zomaar de x-goedkoopste uren gebruiken voor de aansturing, lijkt mij. In theorie kan de prijs zelfs binnen een uur fluctueren van hoog naar laag en weer naar hoog.

Ik hoop dat de integraties van b.v. Nordpool en Cheapest Hours deze trend zullen volgen en hierop hun aanpassingen doorvoeren...

Aan degene die dieper in de materie zitten en ook al meer met HA bezig zijn, de vraag: Is het wellicht een idee om gebruik te maken van staffels. Eigenlijk net zoals bij Zenki dyn. prijzen optie, dat je een hoog en laag kunt aangeven, waarbij moet worden ontladen cq. geladen, maar dan met meer stappen dan in de app.
Ik zou mij dan het volgende kunnen voorstellen (prijzen zonder belasting en btw):
> 0,20 dan max. ontladen (lekker verdienen )
> 0,12 en <= 0,20 dan b.v. 800W ontladen (of NOM)
> 0,05 en <= 0,12 dan NOM
> 0 en en <= 0,05 dan 800W laden
<= 0 dan max laden

Het afgelopen jaar heb ik namelijk voor het laden van de EV en van mijn 'domme' boiler ook gewoon naar de prijs gekeken en niet perse naar de zonne-opwek. De auto moet toch vol en het water warm , dus dan het liefst op de goedkope uren. Als de prijs wat hoger is 's morgens, of eind van de middag, is het terugleveren immers ook lucratiever.

Update
Blijkbaar is bij https://github.com/TheFes/cheapest-energy-hours al een fix ingebouwd voor kwartierprijzen

[ Voor 3% gewijzigd door Jacqui op 29-09-2025 20:58 ]

[martinvdm]

Jacqui schreef op maandag 29 september 2025 @ 20:42:
Een paar energieleveranciers met dynamische prijzen, waaronder in ieder geval Tibber, gaan naar kwartierprijzen en volgen daarmee een Europese trend voor betere afstemming van de prijzen. Volgens de aankondiging op hun site, kunnen de prijzen écht iedere 15 minuten veranderen. Op sommige momenten zal dit voordelig voor de consument uitpakken, op andere wellicht nadelig.
Je kunt dan dus ook niet meer zomaar de x-goedkoopste uren gebruiken voor de aansturing, lijkt mij. In theorie kan de prijs zelfs binnen een uur fluctueren van hoog naar laag en weer naar hoog.

Ik hoop dat de integraties van b.v. Nordpool en Cheapest Hours deze trend zullen volgen en hierop hun aanpassingen doorvoeren...

Aan degene die dieper in de materie zitten en ook al meer met HA bezig zijn, de vraag: Is het wellicht een idee om gebruik te maken van staffels. Eigenlijk net zoals bij Zenki dyn. prijzen optie, dat je een hoog en laag kunt aangeven, waarbij moet worden ontladen cq. geladen, maar dan met meer stappen dan in de app.
Ik zou mij dan het volgende kunnen voorstellen (prijzen zonder belasting en btw):
> 0,20 dan max. ontladen (lekker verdienen )
> 0,12 en <= 0,20 dan b.v. 800W ontladen (of NOM)
> 0,05 en <= 0,12 dan NOM
> 0 en en <= 0,05 dan 800W laden
<= 0 dan max laden

Het afgelopen jaar heb ik namelijk voor het laden van de EV en van mijn 'domme' boiler ook gewoon naar de prijs gekeken en niet perse naar de zonne-opwek. De auto moet toch vol en het water warm , dus dan het liefst op de goedkope uren. Als de prijs wat hoger is 's morgens, of eind van de middag, is het terugleveren immers ook lucratiever.

Update
Blijkbaar is bij https://github.com/TheFes/cheapest-energy-hours al een fix ingebouwd voor kwartierprijzen

Het is volgens mij nog slechts een fix als de integratie meer dan verwacht aantal data points heeft (dus per kwartier). Eigenlijk zou de integratie dan ook cheapest_quarter moeten gaan heten . Maargoed verder beetje off-topic.

[DrNickB]

dr.trimble schreef op maandag 29 september 2025 @ 20:29:mijn waarden zijn uitgedrukt in kW

state: 0.224000006914139

state_class: measurement
unit_of_measurement: kW
device_class: power
friendly_name: Energie uit net

Ik heb even snel een testje opgezet.
ik heb 2 input waardes gemaakt, deze heb ik de waarde kW mee gegeven, fictief er iets in gezet.
in de config yaml heb ik een nieuwe sensor aangemaakt.

code:

  - sensor:
      - name: "TesT verschil"
        unique_id: verbruik_levering_verschil_test
        state_class: measurement
        device_class: energy
        state: "{{ states('input_number.input_test_kwh') | float(0) - states('input_number.output_test_kwh') | float(0) }}"
        unit_of_measurement: "kWh"

Input: 0.22 ; output: 0.33 -> resultaat: -0.11
Waardes zijn uitgedrukt in kWh; geen idee of de code van gielz hier mee om kan gaan
Als je deze aanpast van kWh naar Wh wordt de waarde nog kleiner.

andere extra oplossing zou kunnen zijn om een nieuwe waarde aan te maken die weer * 1000 doet.

code:

  - sensor:
      - name: "TesT verschil - watt"
        unique_id: verbruik_levering_verschil_test_watt
        state_class: measurement
        device_class: energy
        state: "{{ (states('sensor.test_verschil') | float(0)) * 1000 | int(0) }}"
        unit_of_measurement: "Wh"

maar zoals gielz ook aangeeft, is op afstand beetje lastig kijken.

*overigens zou je dit meteen kunnen omrekenen in de eerste sensor variabele, wordt alleen iets langer commandotje.

[ Voor 3% gewijzigd door DrNickB op 29-09-2025 22:54 ]

[klump4u]

DrNickB schreef op maandag 29 september 2025 @ 22:41:
[...]


Ik heb even snel een testje opgezet.
ik heb 2 input waardes gemaakt, deze heb ik de waarde kW mee gegeven, fictief er iets in gezet.
in de config yaml heb ik een nieuwe sensor aangemaakt.

code:

  - sensor:
      - name: "TesT verschil"
        unique_id: verbruik_levering_verschil_test
        state_class: measurement
        device_class: energy
        state: "{{ states('input_number.input_test_kwh') | float(0) - states('input_number.output_test_kwh') | float(0) }}"
        unit_of_measurement: "kWh"

Input: 0.22 ; output: 0.33 -> resultaat: -0.11
Waardes zijn uitgedrukt in kWh; geen idee of de code van gielz hier mee om kan gaan
Als je deze aanpast van kWh naar Wh wordt de waarde nog kleiner.

andere extra oplossing zou kunnen zijn om een nieuwe waarde aan te maken die weer * 1000 doet.

code:

  - sensor:
      - name: "TesT verschil - watt"
        unique_id: verbruik_levering_verschil_test_watt
        state_class: measurement
        device_class: energy
        state: "{{ (states('sensor.test_verschil') | float(0)) * 1000 | int(0) }}"
        unit_of_measurement: "Wh"

maar zoals gielz ook aangeeft, is op afstand beetje lastig kijken.

*overigens zou je dit meteen kunnen omrekenen in de eerste sensor variabele, wordt alleen iets langer commandotje.

Maak gewoon een helper aan met een template sensor, hoef je niet in je configuratie te klooien.

code:

 {{ states("sensor.electricity_meter_energieverbruik") |float *1000 - states("sensor.electricity_meter_energieproductie") | float * 1000}}

[ Voor 4% gewijzigd door klump4u op 30-09-2025 09:16 ]

[DrNickB]

klump4u schreef op dinsdag 30 september 2025 @ 09:12:
[...]
Maak gewoon een helper aan met een template sensor, hoef je niet in je configuratie te klooien.

Zover ik had kunnen vinden was het niet mogelijk om via de gui een waarde te berekenen met een min som (-). vandaar uitgeweken naar configuratie.

[klump4u]

DrNickB schreef op dinsdag 30 september 2025 @ 09:15:
[...]

Zover ik had kunnen vinden was het niet mogelijk om via de gui een waarde te berekenen met een min som (-). vandaar uitgeweken naar configuratie.

Zie edit

[DrNickB]

klump4u schreef op dinsdag 30 september 2025 @ 09:16:
[...]Zie edit

Netjes, wist ik niet. Ben ook niet zo super bekend binnen HA.

[klump4u]

DrNickB schreef op dinsdag 30 september 2025 @ 09:21:
[...]

Netjes, wist ik niet. Ben ook niet zo super bekend binnen HA.

Ik ook niet, je blijft er vanalles in ontdekken maar verder prima software.

[gielz]

Nordpool is over van 1 uur naar 15 minuten. Ik zie nu bij selecteren dat het in blokjes van 15min gaat en dus geen hele uren meer.

https://dataportal-api.no...ryArea=NL&date=2025-10-01

[dennisdew16]

@gielz Hoe werkt jou berekening in de nieuwe situatie? Zou het in theorie kunnen als jij twee goedkoopste uren instelt dat ie acht losse kwartieren kiest of wel nog steeds blokken van een uur en dus gemiddeld laagste uur periode?

[gielz]

dennisdew16 schreef op dinsdag 30 september 2025 @ 14:26:
@gielz Hoe werkt jou berekening in de nieuwe situatie? Zou het in theorie kunnen als jij twee goedkoopste uren instelt dat ie acht losse kwartieren kiest of wel nog steeds blokken van een uur en dus gemiddeld laagste uur periode?

Ik heb niets veranderd hij ging opeens gewoon zo werken met de nieuwe 15 minuten data en pakt dus blokjes van 15minuten die of het goedkoopst zijn of het duurst.

ik heb nu de raw_tomorrow van Nordpool omgevormd naar 4x15 is 1 uur en daar het gemiddelde van. Conform zonneplan heb ik dan afwijkingen in de afronding van minder dan 1 cent (0,01-0,03 cent)

[ Voor 24% gewijzigd door gielz op 30-09-2025 16:24 ]

[remcoXP]

klump4u schreef op zaterdag 13 september 2025 @ 12:53:
[...]

Ik heb de SF2400AC in evcc via HA. Moet je in de evcc.yaml toevoegen als random accu

wil je vertellen hoe je dit gedaan hebt?

[Gyrolion]

[EDIT]: ivm de lage hoge prijs sturing van gielz is de onderstaande goedkope / dure uren even het archief in gegaan.


Dat ziet er wel netjes uit met die automatische goedkoopste en duurste uren!
Daar moet ik me ook eens in gaan verdiepen. Want dat scheelt zelf een hoop gepiel.
Wat ik nu heb gedaan is sliders gemaakt waar ik de ontlaad en oplaad prijs kan instellen. En dat zichtbaar gemaakt in de prijs grafiek.

De automatische oplaad en ontlaad gaat weer samen met de automatisering welke ik heb gebouwd waar het laden van de auto, zons opgang en ondergang, etc. in zit gebakken. Zodat niet de stroom van het 1 naar het andere batterijtje wordt gestuurd.

Als het bij jou een beetje werkt heb ik ook wel interesse hoe die automatisering in elkaar steekt.

[ Voor 3% gewijzigd door Gyrolion op 30-09-2025 22:08 ]

[martinvdm]

Mijn Apexchart is een beetje de weg kwijt sinds recente updates van o.a. kwartierdata en ook ha update. Lopen ook best wat bugs, oa. Met color_threshold en stroke_width. Die functioneren ook niet lekker meer bij mij. Ik wacht denk ik ff af..

[dennisdew16]

gielz schreef op dinsdag 30 september 2025 @ 14:33:
[...]


Ik heb niets veranderd hij ging opeens gewoon zo werken met de nieuwe 15 minuten data en pakt dus blokjes van 15minuten die of het goedkoopst zijn of het duurst.

ik heb nu de raw_tomorrow van Nordpool omgevormd naar 4x15 is 1 uur en daar het gemiddelde van. Conform zonneplan heb ik dan afwijkingen in de afronding van minder dan 1 cent (0,01-0,03 cent)

[Afbeelding]

Heb je van je proeftuin en dan de 15min variant misschien de yaml etc?

[gielz]

dennisdew16 schreef op dinsdag 30 september 2025 @ 19:44:
[...]

Heb je van je proeftuin en dan de 15min variant misschien de yaml etc?

Haha DM mij maar even dan stuur ik je alles. Zijn inmiddels wel een hoop testers....

[klump4u]

remcoXP schreef op dinsdag 30 september 2025 @ 18:33:
[...]


wil je vertellen hoe je dit gedaan hebt?

Dit is een voorbeeld, je moet even zoeken wat de bearer token is hoe je hem gebruikt.
Edit, hier staat de token uitgelegd https://community.home-as...ved-access-token/162159/5
Ik ben op vakantie dus kan niet overal bij nu.

YAML:

  - name: ha.saj.pv
    type: custom
    power:
      source: http
      uri: http://<ha_ip>:8123/api/states/sensor.saj_mqtt_summary_photovoltaic_power
      method: GET
      headers:
        - Authorization: Bearer <token>
      insecure: true
      jq: .state|tonumber
      timeout: 2s

  - name: ha.saj.battery
    type: custom
    power:
      source: http
      uri: http://<ha_ip>:8123/api/states/sensor.saj_mqtt_summary_battery_power
      method: GET
      headers:
        - Authorization: Bearer <token>
      insecure: true
      jq: .state|tonumber
      timeout: 2s
    soc:
      source: http
      uri: http://<ha_ip>:8123/api/states/sensor.saj_mqtt_battery_soc
      method: GET
      headers:
        - Authorization: Bearer <token>
      insecure: true
      jq: .state|tonumber
      timeout: 2s

site:
  title: Thuis
  meters:
    grid: ha.dsmr.grid
    pv: ha.saj.pv
    battery: ha.saj.battery

[ Voor 4% gewijzigd door klump4u op 30-09-2025 20:43 ]

[Bikkelreal]

gielz schreef op dinsdag 30 september 2025 @ 14:33:
[...]


Ik heb niets veranderd hij ging opeens gewoon zo werken met de nieuwe 15 minuten data en pakt dus blokjes van 15minuten die of het goedkoopst zijn of het duurst.

ik heb nu de raw_tomorrow van Nordpool omgevormd naar 4x15 is 1 uur en daar het gemiddelde van. Conform zonneplan heb ik dan afwijkingen in de afronding van minder dan 1 cent (0,01-0,03 cent)

[Afbeelding]

Hoe heb je die groene/rode blokken in de apexcharts-card gemaakt:)

[dennisdew16]

Is er iemand die de batterij ook aanstuurt met een actuele prijs sensor? Die van mij van tibber en nordpool updaten de sensor waarde nog steeds op het hele uur dus dat schiet niet op. Is wel een luxe probleem en zal waarschijnlijk over een paar dagen wel goed zijn maar wil er nu al mee aan de gang

[dennisdew16]

@Bikkelreal Ik zou gielz even een DM sturen, dat is wat makkelijker met die honderden regels aan code

[DJN]

Voor Tibber gebruikers: prijs per kwartier ipv per uur zodat de sensor.tibber_prices 96 datapoints krijgt ipv 24

YAML:

- platform: rest
  name: Tibber Prices
  resource: https://api.tibber.com/v1-beta/gql
  method: POST
  payload: '{ "query": "{ viewer { homes { currentSubscription { status priceInfo (resolution: QUARTER_HOURLY) { current { total } today { total } tomorrow { total } } } } } }" }'
  json_attributes_path: "$.data.viewer.homes[0].currentSubscription.priceInfo"
  json_attributes:
    - today
    - tomorrow
  value_template: "{{ value_json.data.viewer.homes[0].currentSubscription.priceInfo.current.total | float }}"
  scan_interval: 30
  headers:
    Authorization: [je eigen API token Tibber]
    Content-Type: application/json
    User-Agent: REST
  unit_of_measurement: EUR/kWh

YAML:

type: custom:apexcharts-card
experimental:
  color_threshold: true
all_series_config:
  unit: Cent/kWh
apex_config:
  grid:
    show: true
    borderColor: "#E0E0E0"
  chart:
    height: 250px
  tooltip:
    enabled: true
    followCursor: false
    x:
      show: false
    fixed:
      enabled: true
header:
  show: true
  title: Stroomprijs 24h
  show_states: true
  colorize_states: true
  standard_format: false
graph_span: 23h
now:
  show: true
  label: Nu
span:
  start: day
series:
  - entity: sensor.tibber_prices
    show:
      extremas: true
      legend_value: true
      in_header: before_now
      name_in_header: false
    color_threshold:
      - value: 0
        color: 4DD0E1
      - value: 10
        color: 26A69A
      - value: 15
        color: 4CAF50
      - value: 20
        color: 7CB342
      - value: 25
        color: FBC02D
      - value: 30
        color: EF6C00
      - value: 40
        color: B71C1C
    type: column
    extend_to: false
    stroke_width: -1
    float_precision: 0
    data_generator: |
      const noon = new Date()
      noon.setHours(0, 0, 0, 0)
      const prices = entity.attributes.today.concat(entity.attributes.tomorrow);
      const data = [];
      for(let i = 0; i < prices.length; i++) {
        data.push([noon.getTime() + i * 1000 * 900, prices[i].total * 100])
      }
      return data;

[ Voor 49% gewijzigd door DJN op 01-10-2025 11:14 ]

[Peutpeut]

Heb de nieuwe set nu in HEMS zitten voor NOM via de Zendure App.

Begrijp ik het goed dat ik de set uit HEMS moet halen wil ik aansturing via Home Assistant doen? Om bijvoorbeeld te pauzeren zodra de EV aan de lader gaat?
Houdt dit in dat ik ook NOM via HA moet gaan uitvoeren?

[klump4u]

Peutpeut schreef op woensdag 1 oktober 2025 @ 14:17:
Heb de nieuwe set nu in HEMS zitten voor NOM via de Zendure App.

Begrijp ik het goed dat ik de set uit HEMS moet halen wil ik aansturing via Home Assistant doen? Om bijvoorbeeld te pauzeren zodra de EV aan de lader gaat?
Houdt dit in dat ik ook NOM via HA moet gaan uitvoeren?

Beide ja. Je kan dan ook de Zendure eventueel voorrang geven tov de EV

[ Voor 7% gewijzigd door klump4u op 01-10-2025 14:27 ]

[Gyrolion]

Peutpeut schreef op woensdag 1 oktober 2025 @ 14:17:
Heb de nieuwe set nu in HEMS zitten voor NOM via de Zendure App.

Begrijp ik het goed dat ik de set uit HEMS moet halen wil ik aansturing via Home Assistant doen? Om bijvoorbeeld te pauzeren zodra de EV aan de lader gaat?
Houdt dit in dat ik ook NOM via HA moet gaan uitvoeren?

Dit is precies hoe ik het nu gebouwd heb in samenwerking met de Gielz automation.
Als de auto gaat laden gaat de Zendure in stand-by modus.
Stop de auto met laden dan gaat de Zendure weer naar Nul op de meter modus en dan neemt de Gielz het weer over.

Hiervoor moet je los van de Gielz automation een extra automation maken welke dus de input knoppen bediend tussen stand-by, nul op de meter, etc.

[avdwerf]

Gyrolion schreef op woensdag 1 oktober 2025 @ 15:20:
[...]


Dit is precies hoe ik het nu gebouwd heb in samenwerking met de Gielz automation.
Als de auto gaat laden gaat de Zendure in stand-by modus.
Stop de auto met laden dan gaat de Zendure weer naar Nul op de meter modus en dan neemt de Gielz het weer over.

Hiervoor moet je los van de Gielz automation een extra automation maken welke dus de input knoppen bediend tussen stand-by, nul op de meter, etc.

Misschien nog een mooie kleine toevoeging. Zet hem niet op standby maar "Slim opladen". Mocht er wat overblijven van de zonopbrengst (als de EV bijv. op 1 fase aan het laden is) gaat dat niet terug naar het net maar mooi de accu in.

[CopyCatz]

Ik draai op de automation van gielz, en de afgelopen dagen met weinig zon heb ik de accu's bijna helemaal leeg gehad. Nu viel me op dat wanneer ik onder de 10% zak, de NOM blijft "hangen". Het gecompenseerde verbruik was bv 600 watt, ik zet alles uit waardoor ik terugval naar 300 maar de automation blijft 600 compenseren. Is dit ingebouwd of gaat er iets niet goed?

[gielz]

CopyCatz schreef op woensdag 1 oktober 2025 @ 22:31:
Ik draai op de automation van gielz, en de afgelopen dagen met weinig zon heb ik de accu's bijna helemaal leeg gehad. Nu viel me op dat wanneer ik onder de 10% zak, de NOM blijft "hangen". Het gecompenseerde verbruik was bv 600 watt, ik zet alles uit waardoor ik terugval naar 300 maar de automation blijft 600 compenseren. Is dit ingebouwd of gaat er iets niet goed?

Beetje onduidelijk verhaal maar dan kan er aan liggen dat ik net wakker ben. Heb je iets van screenshots om te laten zien wat je bedoeld? Hier is de batterij geregeld leeg en komt netjes weer tot leven.

Wie weet heb je een bug gevonden.

[DrNickB]

CopyCatz schreef op woensdag 1 oktober 2025 @ 22:31:
Ik draai op de automation van gielz, en de afgelopen dagen met weinig zon heb ik de accu's bijna helemaal leeg gehad. Nu viel me op dat wanneer ik onder de 10% zak, de NOM blijft "hangen". Het gecompenseerde verbruik was bv 600 watt, ik zet alles uit waardoor ik terugval naar 300 maar de automation blijft 600 compenseren. Is dit ingebouwd of gaat er iets niet goed?

Is het niet zo dat in de automation de lower limit op 10% staat ingesteld?
op moment dat hij 10 (of lager is) stopt de automation met schakelen (als ik het goed interpreteer)
Of laat ik het anders zeggen, ik gebruik alleen de 'Slim ontladen' / NOM optie, opladen doe ik via zon.

[Gyrolion]

Ik heb volgens mij hetzelfde fenomeen meegemaakt eergister op gister, toen was accu al vroeg leeg <10% en bleef toen vast plakken in een state dat hij langzaam aan het ontladen was, en varieerde niet meer mee met het thuis gebruik.
Maar het gekke is ook, ik zie het nu niet terug op het vermogen van de homewizard p1 meter of de zendure meters.
Hij zit op fase 3 waar in principe niet veel overheen gaat, en die staat gewoon netjes op 0 watt.
Dit heeft hij gedaan van 9% tot 5%. Wat ik me dan afvraag, waar is deze 400 watt naar toe gegaan? Of is dit gewoon het standaard stand-by verbruik?

Zelf dacht ik dat het door de instellingen in de zendure app zelf lag, deze stond namelijk ingesteld op minimaal 5%, heb toen wat zitten rommelen maar verder eigenlijk niet meer over nagedacht.
Het veranderde namelijk niks.
Het stukje off-grid stopcontact staat in de zendure app ook op off, dus daar kan de stroom ook niet naartoe.

Heb er dus ook geen goede data voor.. en denk dat hij met dit bewolkte dagje misschien weer in dezelfde state gaat komen.. of ik kan hem er in forceren als het moet.
Nu staat de instelling in de app van zendure wel vast, 10% is het minimale wat hij mag behalen niet lager.


Hier zie je de leegloop in de nacht van 1 oktober (begin van de trend) tussen 0:00 en 08:00 (op 08:00 heb ik even met de state zitten spelen om wat automations te testen.)

[ Voor 7% gewijzigd door Gyrolion op 02-10-2025 12:17 ]

[gielz]

Gyrolion schreef op donderdag 2 oktober 2025 @ 12:03:
Ik heb volgens mij hetzelfde fenomeen meegemaakt eergister op gister, toen was accu al vroeg leeg <10% en bleef toen vast plakken in een state dat hij langzaam aan het ontladen was, en varieerde niet meer mee met het thuis gebruik.
Maar het gekke is ook, ik zie het nu niet terug op het vermogen van de homewizard p1 meter of de zendure meters.
Hij zit op fase 3 waar in principe niet veel overheen gaat, en die staat gewoon netjes op 0 watt.
Dit heeft hij gedaan van 9% tot 5%. Wat ik me dan afvraag, waar is deze 400 watt naar toe gegaan? Of is dit gewoon het standaard stand-by verbruik?

Zelf dacht ik dat het door de instellingen in de zendure app zelf lag, deze stond namelijk ingesteld op minimaal 5%, heb toen wat zitten rommelen maar verder eigenlijk niet meer over nagedacht.
Het veranderde namelijk niks.
Het stukje off-grid stopcontact staat in de zendure app ook op off, dus daar kan de stroom ook niet naartoe.

Heb er dus ook geen goede data voor.. en denk dat hij met dit bewolkte dagje misschien weer in dezelfde state gaat komen.. of ik kan hem er in forceren als het moet.
Nu staat de instelling in de app van zendure wel vast, 10% is het minimale wat hij mag behalen niet lager.


Hier zie je de leegloop in de nacht van 1 oktober (begin van de trend) tussen 0:00 en 08:00 (op 08:00 heb ik even met de state zitten spelen om wat automations te testen.)

[Afbeelding]

Meet je ook via een externe meter het vermogen van de batterij?

[Gyrolion]

Deze is onderweg, ik ga er een homewizard meter tussen plakken om te kijken of er daadwerkelijk stroom de batterij uit is gevloeid of dat het een soort balancerings act is geweest.
Volgens de site kan deze meter prima 2400 watt dragen, en schakelt hij zichzelf uit als hij te warm wordt.. dus dat moet goedkomen.

[ Voor 8% gewijzigd door Gyrolion op 02-10-2025 13:04 ]

[gielz]

zenSDK (Gielz) - Update zonder update

Even een korte update uit het dynamisch front wat ontwikkeld word voor de zenSDK (Gielz). Inmiddels zijn wij 100en regels code verder en tig opgeloste bugs. Het draait nu ter test bij een aantal Tweakers en blijkt ook in de praktijk plug-n-play. Wat komt er aan;

- 15min of 1 uur sturing
- Spread berekeningen met inhoudelijk informatie wat hij nou exact berekend heeft
- Aparte NOM spread berekening waarbij de dure uren voor het opladen niet mee berekend worden
- Een JA en NEE sensor om de juiste modus te kiezen (kunt dus bestaande automatiseringen gebruiken)
- Voor de min-maxers een handmatige invoer. Morgen niet wat je wilt, pas het aan en voer eenmalig uit.
- Alles visueel zichtbaar op het scherm.

[ Voor 13% gewijzigd door gielz op 02-10-2025 17:10 ]

[gielz]

Gyrolion schreef op donderdag 2 oktober 2025 @ 13:04:
Deze is onderweg, ik ga er een homewizard meter tussen plakken om te kijken of er daadwerkelijk stroom de batterij uit is gevloeid of dat het een soort balancerings act is geweest.
Volgens de site kan deze meter prima 2400 watt dragen, en schakelt hij zichzelf uit als hij te warm wordt.. dus dat moet goedkomen.

Ik heb wellicht het probleem kunnen nabootsen. Wanneer je minimale SOC op 5% hebt staan gaat het mis. De automatisering gaat namelijk uit van de 10% SOC. Zodra hij dan op de 10% beland gaat hij geen informatie meer sturen naar de batterij en blijft hij op het laatste ontlaadbericht hangen en ontladen tot die 5%.

Uiteraard op te lossen en staat inmiddels op het lijstje maar voor nu zou ik minimale SOC op 10% laten staan.

[CopyCatz]

gielz schreef op donderdag 2 oktober 2025 @ 17:21:
[...]


Ik heb wellicht het probleem kunnen nabootsen. Wanneer je minimale SOC op 5% hebt staan gaat het mis. De automatisering gaat namelijk uit van de 10% SOC. Zodra hij dan op de 10% beland gaat hij geen informatie meer sturen naar de batterij en blijft hij op het laatste ontlaadbericht hangen en ontladen tot die 5%.

Uiteraard op te lossen en staat inmiddels op het lijstje maar voor nu zou ik minimale SOC op 10% laten staan.

Dat zal het zijn, ik had inderdaad de min soc naar 5% gezet omdat dat al eigenlijk 10% is

Goed bezig met de integratie trouwens!

[dennisdew16]

CopyCatz schreef op donderdag 2 oktober 2025 @ 18:34:
[...]


Dat zal het zijn, ik had inderdaad de min soc naar 5% gezet omdat dat al eigenlijk 10% is

Goed bezig met de integratie trouwens!

Als je de 5% instelt in de automatisering en in de zendure app is er niks aan de hand. Doe ik ook al een aantal weken

[klump4u]

dennisdew16 schreef op donderdag 2 oktober 2025 @ 19:06:
[...]

Als je de 5% instelt in de automatisering en in de zendure app is er niks aan de hand. Doe ik ook al een aantal weken

Welke regel in de automatisering is dit?
Edit, regel 118 en 155?

[ Voor 4% gewijzigd door klump4u op 02-10-2025 20:07 ]

[dennisdew16]

@klump4u In de automatisering -> aansturing -> stap 2 en stap 3 staat beide een voorwaarde: "Als zendure 2400ac laadpercentage hoger is dan X". Deze staat normaal gesproken op 10, deze kan je dan aanpassen naar 5. Mocht je er niet uitkomen stuur je maar een dm

Edit: correct, die regels inderdaad.

[ Voor 7% gewijzigd door dennisdew16 op 02-10-2025 20:12 ]

[klump4u]

dennisdew16 schreef op donderdag 2 oktober 2025 @ 20:11:
@klump4u In de automatisering -> aansturing -> stap 2 en stap 3 staat beide een voorwaarde: "Als zendure 2400ac laadpercentage hoger is dan X". Deze staat normaal gesproken op 10, deze kan je dan aanpassen naar 5. Mocht je er niet uitkomen stuur je maar een dm

Edit: correct, die regels inderdaad.

Gelukt, is inderdaad dan regel 118 en 155 bij mij als ik hem als yaml lees of bewerk.

[gielz]

@dennisdew16 @klump4u @CopyCatz

Voor de volgende automatisering update heb ik het nu dynamisch gemaakt. Hij zal nu naar de minimale soc sensor kijken die nog niet bestond ten tijden toen deze NOM gemaakt is.

Dan zou het voor iedereen altijd goed moeten gaan. Ik kijk het even aan t/m Zondag.

code:

          - condition: template
            value_template: |
              {{ states('sensor.zendure_2400_ac_laadpercentage') | float >
               states('sensor.zendure_2400_ac_minimale_laadpercentage') | float }}

[MGZ]

Hallo techneuten,
Misschien een ontzettende noob vraag,maar is dit allemaal redelijk plug n play voor iemand die nog geen HA heeft dus ook geen ervaring daarmee? Of is Homey dan toch een betere optie?

[Aziraphale]

MGZ schreef op donderdag 2 oktober 2025 @ 22:56:
Hallo techneuten,
Misschien een ontzettende noob vraag,maar is dit allemaal redelijk plug n play voor iemand die nog geen HA heeft dus ook geen ervaring daarmee? Of is Homey dan toch een betere optie?

Ik zou voor Homey gaan, bevalt mij erg goed. In HA heb ik het wel geprobeerd en ik heb Fireson op de achtergrond ook draaien, maar dat is puur om te monitoren. Automatiseren hiervan is in HA veel lastiger.

[gielz]

MGZ schreef op donderdag 2 oktober 2025 @ 22:56:
Hallo techneuten,
Misschien een ontzettende noob vraag,maar is dit allemaal redelijk plug n play voor iemand die nog geen HA heeft dus ook geen ervaring daarmee? Of is Homey dan toch een betere optie?

Je vraagt dit wel in het verkeerde topic "Wij van WC eend (HA) adviseren WC eend (HA)" Ik zou eerst even goed kijken wat je exact wilt bereiken en hoeveel het mag kosten. Je hebt bijvoorbeeld al een werkende Home Assistent OS (Yellow) voor rond de 130 euro waarmee je direct aan de slag kunt. Of wellicht heb je al een NAS staan waar je Home Assistant volledig gratis op kunt installeren.

Op feestjes zeg ik altijd "Zoek je een nieuwe goedkope hobby begin aan Home Assistant".

[klump4u]

Als je HA eenmaal door hebt is alles makkelijk, ik heb er een tijdje over gedaan maar ga binnenkort mijn Domoticz afbouwen en geheel over naar HA, Homey ken ik niet maar lijkt mij commerciëler. Maar ik kan het ook mis hebben

[Batavia]

Ik zit te kijken naar mijn zendure te integreren in homeassistant.

Ik heb DAO (day ahead optimizer) (soms) draaiende.
Klopt het dat nu de fireson integration + zenSDK een goede combi is?
Ik zat ook te kijken naar Gielz maar als ik het zo inschat is het iets meer handmatige configuratie en eigenlijk overlap in fucntionaliteit van DAO.

Of hebben mensen hier andere/betere ervaringen met Gielz? Los van dat hij hier actief op het forum is wat natuurlijk altijd een pluspunt is.

[MGZ]

klump4u schreef op vrijdag 3 oktober 2025 @ 09:17:
Als je HA eenmaal door hebt is alles makkelijk, ik heb er een tijdje over gedaan maar ga binnenkort mijn Domoticz afbouwen en geheel over naar HA, Homey ken ik niet maar lijkt mij commerciëler. Maar ik kan het ook mis hebben

Voor HA heb je toch wel de nodige programmeer kennis nodig? En als men die niet heeft,dan lijkt me het best lastig om HA onder de knie te krijgen, maar dat weten de gebruikers hier denk ik beter in te schatten dan ikzelf

[klump4u]

MGZ schreef op vrijdag 3 oktober 2025 @ 11:19:
[...]

Voor HA heb je toch wel de nodige programmeer kennis nodig? En als men die niet heeft,dan lijkt me het best lastig om HA onder de knie te krijgen, maar dat weten de gebruikers hier denk ik beter in te schatten dan ikzelf

Dat is nu net de uitdaging, jezelf prikkelen om toch iets voor mekaar te krijgen.

[Idefix70]

MGZ schreef op vrijdag 3 oktober 2025 @ 11:19:
[...]

Voor HA heb je toch wel de nodige programmeer kennis nodig? En als men die niet heeft,dan lijkt me het best lastig om HA onder de knie te krijgen, maar dat weten de gebruikers hier denk ik beter in te schatten dan ikzelf

Lang leve chatGPT

[xobdorp]

Sinds gisteren over op dynamische tarieven en logische stap genomen om alles in Home Assistant te hangen. Fireson-integratie had ik al een tijdje voor de verschillende statistieken, dus meeste werk zat erin om cheapest hours goed te configureren en een automation op te zetten.
Automation doet nu niks anders dan laten op goedkope momenten, ontladen op dure momenten en de rest van de tijd NOM.
Op zo’n dag als vandaag (prijs stabiel tussen 14/15 cent) doet ie alleen maar NOM. Komende dagen en weken bepalen of er nog meer toeters en bellen nodig zijn…