Zendure producten in Home Assistant integreren deel 2

[Taro]

wosp schreef op donderdag 24 juli 2025 @ 15:52:
Ik heb 3 SF 2400 AC's met elk 4 batterijen draaien. Na een tijdje de FireSon integratie gebruikt te hebben in HA, heb ik van de week besloten toch maar de overstap te maken naar de ZenSDK integratie naar voorbeeld van @gielz. Ik heb de templates (bijna helemaal) aangepast naar wens en geschikt gemaakt voor 3 omvormers, tot zover prima. [...]

Heb je dan ook NOM met 3 omvormers én verdeel je dynamisch de load tussen de 3? Of doen ze alle 3 exact hetzelfde en neem je bijv. geen SOC mee in de berekening?

Wil hier volgende week ook mee aan de slag, vandaar.

[wosp]

Taro schreef op donderdag 24 juli 2025 @ 17:07:
[...]

Heb je dan ook NOM met 3 omvormers én verdeel je dynamisch de load tussen de 3? Of doen ze alle 3 exact hetzelfde en neem je bijv. geen SOC mee in de berekening?

Wil hier volgende week ook mee aan de slag, vandaar.

Op dit moment houd ik nog geen rekening met de actuele SoC, nog wel een mooie om bij te bouwen. Load wordt nu gelijkmatig verdeeld door een factor (van voorbeeld @gielz) op te geven afhankelijk van het aantal omvormers dat actief is. Mijn omvormers blijven altijd tussen de 10-90% SoC, behalve voor de wekelijkse kalibratie. Stel dus even dat bij laden er 1 omvormer al op 90% zit en 2 nog niet, dan is het dus al wel zo geregeld dat omvormer 2 en 3 dan 50/50 de load krijgen, zijn ze alle drie actief dan 33,4/33,3/33,3% en als er nog maar 1 actief is, dan 100%. Zelfde voor ontladen. Het is wel een klusje kan ik je vertellen, laatste 2 dagen heel wat uurtjes aan besteed. Ik heb de handmatige modus nu ook verwerkt in het nom script, dus geen apart script meer daarvoor nodig. Nu ben ik nog bezig om de kalibratie ook in dit script te verwerken, via de modus selecteer automation trigger ik 'm dan elke zondag om 14.00 uur, maar mocht ik eens extra willen kalibreren, kan ik die gewoon uit de dropdown selecteren. Werkt allemaal tot nu toe prima, nog beetje met correctie en export_correctie spelen.

Bedankt @Devke en @gielz, ga ik (waarschijnlijk morgen) ff checken. Voor vandaag helaas geen speeltijd meer over.

[ Voor 3% gewijzigd door wosp op 24-07-2025 18:02 ]

[Taro]

@wosp Goed om te horen, zou mooi zijn als je je voortgang tot nu toe hier wil delen, dan kunnen anderen dit verbeteren en aanpassen en heb je daar zelf hopelijk ook weer voordeel van.

[wosp]

Ik zal de aangepaste scripts delen d.m.v. dit topic, zodra ik de huidige functionaliteit erin heb zitten. Zal van het weekend zijn denk ik.

[CrusherT]

Ook ik draai al even de Fireson integratie, waarvoor dank! Ben nog wat aan het klussen geweest met de Cheapest Hours integratie, om binnenkort meer op prijzen te gaan sturen (overstap naar dynamisch). Daarbij viel me op dat je 'standaard' precies op de uurwissel de instructie gaat geven om te laden/ontladen, en dat geeft op het net juist extra instabiliteit doordat meerdere partijen dat exact tegelijk doen (kijk maar eens op https://mainsfrequency.com/ naar de netfrequentie direct na een uurwissel waarbij de prijs flink verandert).

Om daar wat extra flexibiliteit in te krijgen was mijn idee om wat eerder te starten/stoppen met laden of ontladen. Ik heb daarvoor (als voorbeeld) de volgende automation gemaakt die kijkt of het volgende uur bij de duurste 3 uren van de namiddag hoort (en daarop een boolean aanpast). Door die automation dan wat eerder te triggeren kun je het laden/ontladen net wat eerder starten om niet exact samen met de rest van de tariefsturende wereld te zijn (in dit geval 45 seconden, maar natuurlijk aanpasbaar).

code:

alias: Duurste_3_uren_middag_bijwerken
description: ""
triggers:
  - trigger: time_pattern
    hours: "*"
    minutes: "59"
    seconds: "15"
conditions: []
actions:
  - choose:
      - conditions:
          - condition: template
            value_template: >
              {% set prices = state_attr('sensor.nordpool_kwh_nl_eur_3_10_021',
              'today') | default([]) %} {% set start_hour = 17 %} {% set
              end_hour = 24 %} {% set price_hour_pairs = namespace(pairs=[]) %}
              {% for i in range(start_hour, end_hour) %}
                {% if i < prices | length %}
                  {% set price_hour_pairs.pairs = price_hour_pairs.pairs + [(i, prices[i])] %}
                {% endif %}
              {% endfor %} {% set sorted_pairs = price_hour_pairs.pairs |
              sort(attribute=1, reverse=true) | list %} {% set top_3_indices =
              sorted_pairs[:3] | map(attribute=0) | list %} {% set top_3_hours =
              namespace(hours=[]) %} {% for i in top_3_indices %}
                {% set top_3_hours.hours = top_3_hours.hours + ['%02d:00' | format(i)] %}
              {% endfor %} {% set next_hour = (now() +
              timedelta(hours=1)).strftime('%H') + ':00' %} {{ next_hour in
              top_3_hours.hours }}
        sequence:
          - target:
              entity_id: input_boolean.duurste_3_uren_middag
            data: {}
            action: input_boolean.turn_on
    default:
      - target:
          entity_id: input_boolean.duurste_3_uren_middag
        data: {}
        action: input_boolean.turn_off
mode: single

[klump4u]

Ik ga het ook eens proberen met mijn 2400AC.
DSMR reader en een Shelly mini g3.

[jaychunlai]

Iemand een idee?

Vanuit mn laptop CLI, krijg ik response als ik de curl -X http://<ip-batterij>.../... Vervolgens met IP adres en SN in configuration.yaml alles erin gezet.

Na herstart van haOS, zie ik vervolgens geen entiteiten tussen RestFul / Restful commands

Developers tool: action aangeklikt en 1 van de commands uitgevoerd.
Error: Timeout when calling resource "http://192.168.x.x/properties/write"

Help a noob out? Bedankt

[ Voor 19% gewijzigd door jaychunlai op 25-07-2025 16:16 ]

[Devke]

jaychunlai schreef op vrijdag 25 juli 2025 @ 16:15:
Iemand een idee?

Vanuit mn laptop CLI, krijg ik response als ik de curl -X http://<ip-batterij>.../... Vervolgens met IP adres en SN in configuration.yaml alles erin gezet.

Na herstart van haOS, zie ik vervolgens geen entiteiten tussen RestFul / Restful commands

Developers tool: action aangeklikt en 1 van de commands uitgevoerd.
Error: Timeout when calling resource "http://192.168.x.x/properties/write"

Help a noob out? Bedankt

Typefoutje. Wel het goede IP adres gebruikt? (Kun je in de router ff checken). Ik zou IP adres dan ook gelijk even vastzetten.

YAML:

curl -X GET "http://ip>/properties/report"

[ Voor 4% gewijzigd door Devke op 25-07-2025 16:23 ]

[jaychunlai]

Devke schreef op vrijdag 25 juli 2025 @ 16:19:
[...]

Typefoutje? Wel het goede IP adres gebruikt? (Kun je in dr router ff checken). Ik zou IP adres dan ook gelijk even vastzetten.

IP adres is correct. Beetje copy paste idee en SN ook uit de curl gehaald. Zet IP wel vast als het werkt hihi
Update: lijkt erop dat ik vanuit haOS ook niet naar mn batterij IP kan pingen

[ Voor 36% gewijzigd door jaychunlai op 25-07-2025 16:26 ]

[Devke]

jaychunlai schreef op vrijdag 25 juli 2025 @ 16:23:
[...]


IP adres is correct. Beetje copy paste idee en SN ook uit de curl gehaald. Zet IP wel vast als het werkt hihi
Update: lijkt erop dat ik vanuit haOS ook niet naar mn batterij IP kan pingen

[Afbeelding]

Probeer het curl commando eens die ik net heb gepost. Heb de post nog aangepast. Je bent GET vergeten.

[jaychunlai]

Devke schreef op vrijdag 25 juli 2025 @ 16:28:
[...]

Probeer het curl commando eens die ik net heb gepost. Heb de post nog aangepast. Je bent GET vergeten.

Yea klopt ik was die vergeten in post, maar niet in mn CLI. Had de output gewoon gekregen.

[wosp]

@gielz Vandaag verder gewerkt aan de aanpassing van jouw template om deze geschikt te maken voor 3 omvormers, loopt tegen nog wat kleine probleempjes aan, maar die verwacht ik wel te kunnen oplossen.

Ik zit misschien inmiddels te lang naar m'n beeldscherm te turen (ga nu ook maar even stoppen), maar ik zie niet goed wat je wilt voorkomen met deze template bij opladen balanceren (en net zo een bij ontladen balanceren) ?

code:

              - condition: template
                value_template: >-
                  {% set cap = 800 %}
                  {% set factor = 1.00 %}
                  {% set corr = 80 %}
                  {% set total = hwpwr - p1mtr - corr %}
                  {% set limited = total if total > 0 else 0 %}
                  {% set target = (limited if limited < cap else cap) | int %}
                  {% set current = states('sensor.zendure_2400_ac_ingesteld_oplaadvermogen') | int(0) %}
                  {{ current != target }}

[klump4u]

Alles werkt behalve de NOM 1.00 automatisering.
Ik krijg deze fout:
Automatisering is niet beschikbaar
Triggers: required key not provided @ data[1]['trigger']

[gielz]

wosp schreef op vrijdag 25 juli 2025 @ 19:52:
@gielz Vandaag verder gewerkt aan de aanpassing van jouw template om deze geschikt te maken voor 3 omvormers, loopt tegen nog wat kleine probleempjes aan, maar die verwacht ik wel te kunnen oplossen.

Ik zit misschien inmiddels te lang naar m'n beeldscherm te turen (ga nu ook maar even stoppen), maar ik zie niet goed wat je wilt voorkomen met deze template bij opladen balanceren (en net zo een bij ontladen balanceren) ?

code:

              - condition: template
                value_template: >-
                  {% set cap = 800 %}
                  {% set factor = 1.00 %}
                  {% set corr = 80 %}
                  {% set total = hwpwr - p1mtr - corr %}
                  {% set limited = total if total > 0 else 0 %}
                  {% set target = (limited if limited < cap else cap) | int %}
                  {% set current = states('sensor.zendure_2400_ac_ingesteld_oplaadvermogen') | int(0) %}
                  {{ current != target }}

Was voor mij ook weer even zoeken, want ik heb al een tijd de NOM niet meer aangeraakt. Het werkt gewoon.

Wat hier gedaan word is dat er voorkomen word dat er een API update word verzonden naar de batterij als het vermogen al bekend is. Specifiek om freezes te voorkomen (werkt ook zonder prima), nice to have maar geen must als het een hersenbreker is bij meer batterijen. Lekker deactiveren

[gielz]

klump4u schreef op vrijdag 25 juli 2025 @ 19:56:
Alles werkt behalve de NOM 1.00 automatisering.
Ik krijg deze fout:
Automatisering is niet beschikbaar
Triggers: required key not provided @ data[1]['trigger']

Dit is nogal vaag. Ik zou de NOM die je wilt gebruiken (dus gaat copy + pasten) even in chatgpt gooien met deze foutmelding. Ben wel benieuwd wat het antwoord is.

[klump4u]

gielz schreef op vrijdag 25 juli 2025 @ 20:08:
[...]


Dit is nogal vaag. Ik zou de NOM die je wilt gebruiken (dus gaat copy + pasten) even in chatgpt gooien met deze foutmelding. Ben wel benieuwd wat het antwoord is.

Fout geheel mijnerzijds, copy paste in een YAML is lastig, het werkt nu wel.
Ik heb niks van HW dus moest alles herbenoemen en veel copy paste doen.

[TCMR]

gielz schreef op maandag 16 juni 2025 @ 12:55:

Ik heb geen bluetooth bij mijn batterij. Wat nu?

Je kunt hiervoor een bluetooth proxy maken die je in het stopcontact steekt en via wifi de bluetooth informatie naar Home Assistant stuurt.

Ik ben de afgelopen dagen door een hel gegaan om een ESP device te flashen met ESPhome bluetooth proxy erop. Want ik wil graag de SF800Pro via bluetooth->ethernet op m'n netwerk zetten. De bluetooth proxy draait, maar nu ik niet verder.

Is er wel Bluetooth ondersteuning in de SF800Pro, meer dan alleen zorgen dat je via de app makkelijk op je WiFi komt? Of moet ik dan toch de MQTT-server-route gaan nemen? Want die wil ik niet. Alles loopt als een zonnetje zo (rest API), alleen wil de de SF800Pro ver weg van het WiFi-bereik zetten, bij voorkeur dus met een BLE proxy. Kan het?

[gielz]

TCMR schreef op vrijdag 25 juli 2025 @ 20:49:
[...]

Ik ben de afgelopen dagen door een hel gegaan om een ESP device te flashen met ESPhome bluetooth proxy erop. Want ik wil graag de SF800Pro via bluetooth->ethernet op m'n netwerk zetten. De bluetooth proxy draait, maar nu ik niet verder.

Is er wel Bluetooth ondersteuning in de SF800Pro, meer dan alleen zorgen dat je via de app makkelijk op je WiFi komt? Of moet ik dan toch de MQTT-server-route gaan nemen? Want die wil ik niet. Alles loopt als een zonnetje zo (rest API), alleen wil de de SF800Pro ver weg van het WiFi-bereik zetten, bij voorkeur dus met een BLE proxy. Kan het?

Die ble proxy is alleen voor een reset na freeze in de fireson. Zie je uberhaupt de 800pro via bluetooth? De 2400ac bluetooth gaat uit na het installeren en is daarna niet meer te vinden.

Zou eerder kijken naar een repeater of ap met een kabeltje naar de locatie.

[TCMR]

gielz schreef op vrijdag 25 juli 2025 @ 21:06:
[...]
Zou eerder kijken naar een repeater of ap met een kabeltje naar de locatie.

Ja, dat zie ik nu ook in, want idd: Bluetooth lijkt alleen even gebruikt te worden voor het oversturen van de SSID+pw. Ik heb nog zo'n prachtig mini-routertje met OpenWRT liggen. Het is een stuk minder werk om die even als AP bedraad bij de SF800Pro te hangen.

Nou ja, het was leerzaam, zal ik maar zeggen (en vooral: ongelooflijk dat flashen van zo'n ESP device zelfs met twee verschillende USB TTY serial converters en alles netjes aangesloten niet werkte op macOS, Windows 11, uiteindelijk alleen direct op een Pi5 met HAOS, wat een hel...).

[gielz]

TCMR schreef op vrijdag 25 juli 2025 @ 21:18:
[...]

Ja, dat zie ik nu ook in, want idd: Bluetooth lijkt alleen even gebruikt te worden voor het oversturen van de SSID+pw. Ik heb nog zo'n prachtig mini-routertje met OpenWRT liggen. Het is een stuk minder werk om die even als AP bedraad bij de SF800Pro te hangen.

Nou ja, het was leerzaam, zal ik maar zeggen (en vooral: ongelooflijk dat flashen van zo'n ESP device zelfs met twee verschillende USB TTY serial converters en alles netjes aangesloten niet werkte op macOS, Windows 11, uiteindelijk alleen direct op een Pi5 met HAOS, wat een hel...).

Hier 5 min werk, toen was ik nog in de running voor de Hyper 🫣. Die AP lijkt mij een prachtige oplossing. Dan behoud je ook de aansturing die je prettig vind.

[jaychunlai]

Iemand hier die de Tibber Pulse gebruikt voor kWh Meter en die de NOM 1.0 script werkend heeft ?

[dennisdew16]

jaychunlai schreef op zaterdag 26 juli 2025 @ 00:20:
Iemand hier die de Tibber Pulse gebruikt voor kWh Meter en die de NOM 1.0 script werkend heeft ?

Elke P1 meter zou moeten werken. Zolang je de naam van de P1 entiteit maar aanpast in de automatisering. Zelf gebruik ik ook niet de HW meter maar gewoon dsmr reader in HA.
Heb je het al getest en werkt het niet of is het een vraag voordat je tot aankoop over gaat?

[jaychunlai]

dennisdew16 schreef op zaterdag 26 juli 2025 @ 00:31:
[...]

Elke P1 meter zou moeten werken. Zolang je de naam van de P1 entiteit maar aanpast in de automatisering. Zelf gebruik ik ook niet de HW meter maar gewoon dsmr reader in HA.
Heb je het al getest en werkt het niet of is het een vraag voordat je tot aankoop over gaat?

Ik heb Zendure AC2400 draaiende. Alleen loop ik de Nom 1.0 script af om dingen aan te passen die bij mij anders heet. En toen zag ik die kwh meter of stopcontact die je als resource in vult. Vraag me af wat ik daarmee moet :’)
Die heb ik tijdens copy paste naar configuration.yaml weg gehaald want ik dacht “ah heb ik niet” maar dan breekt natuurlijk de andere scripts hihi

[ Voor 10% gewijzigd door jaychunlai op 26-07-2025 00:46 ]

[dennisdew16]

jaychunlai schreef op zaterdag 26 juli 2025 @ 00:42:
[...]


Ik heb Zendure AC2400 draaiende. Alleen loop ik de Nom 1.0 script af om dingen aan te passen die bij mij anders heet. En toen zag ik die kwh meter of stopcontact die je als resource in vult. Vraag me af wat ik daarmee moet :’)
Die heb ik tijdens copy paste naar configuration.yaml weg gehaald want ik dacht “ah heb ik niet” maar dan breekt natuurlijk de andere scripts hihi

Oh dat gedeelte bedoel je. Dat is de meting van wat de accu in en uit gaat. Ik heb een losse kWh meter in de groepenkast geplaatst om dat te meten maar zoals je zegt een energysocket kan ook. Zonder werkt nog niet al was er volgens mij wel iemand bezig om dit te testen met een iets andere configuratie.

[wosp]

gielz schreef op vrijdag 25 juli 2025 @ 20:06:
[...]


Was voor mij ook weer even zoeken, want ik heb al een tijd de NOM niet meer aangeraakt. Het werkt gewoon.

Wat hier gedaan word is dat er voorkomen word dat er een API update word verzonden naar de batterij als het vermogen al bekend is. Specifiek om freezes te voorkomen (werkt ook zonder prima), nice to have maar geen must als het een hersenbreker is bij meer batterijen. Lekker deactiveren

Check, geen probleem, heb ze geschikt gemaakt voor 3 omvormers, wel mooi om te houden idd.

Heb nu geregeld:
- Geschikt gemaakt voor 3 omvormers
- Dynamic Load Balancing (@Taro)
- Handmatige Modus geïntegreerd in template
- Automatische wekelijkse kalibratie (+ mogelijkheid om met 1 druk op de knop een keer extra te kalibreren), na kalibratie terug naar modus die daarvoor geselecteerd was.
- Monitoring ingestelde minimale SoC en maximale SoC + automatische aanpassing indien foutief
- Monitoring van Modus Selecteren automation en indien uitgeschakeld terwijl NOM automatisering loopt deze weer inschakelen
- Monitoring van P1 en kWh meter data (is deze recent bijgewerkt), zo niet en draait er een modus die deze data nodig heeft (NOM + Slim Opladen + Slim Ontladen) dan stop alles (automagisch herstel bij herstel van de data moet ik nog even maken)
- Bij stoppen HA (bijv. reboot) wordt alles gestopt en modus welke draaide wordt onthouden, bij start HA wordt deze modus hervat (ook kalibreren)

Ik had verwacht het dit weekend af te hebben, maar dat gaat niet lukken vermoed ik door andere verplichtingen en ik heb er wat meer van gemaakt dan in eerste instantie gedacht. Ik zal het z.s.m. delen, wil het eerst ook nog even goed testen en wil de code nog wat opschonen.

[Taro]

@wosp Ik wou net naar de status vragen gezien ik nu weer tijd heb om ermee aan de slag te gaan en de 3e 2400 AC in gebruik heb genomen.

Als ik ergens mee kan helpen, of testen, dan hoor ik het graag!

[Taro]

Iemand FireSon integratie 1.1.0-pr8 al succesvol in gebruik met meerdere 2400AC's?

Ik twijfel even welke weg in te slaan. Bij voorkeur gebruik ik de FireSon integratie nog met 3x Hypers in lokale MQTT mode wat inmiddels al heel lang super stabiel draait. Aan de andere kant vind ik de @gielz en @wosp aanvliegroute ook wel mooi en die kan ik ernaast gebruiken.

Of ga ik tijdelijk met een 2e HA installatie aan de slag om de FireSon integratie met alleen de 2400AC's te kunnen testen. Anders moet ik iedere keer alle scripts aanpassen...

Keuzes, keuzes...

[Devke]

Ik zag dat mijn Zendure de opslag methode nog wel eens veranderd van RAM naar Flash. Ik heb hier een kleine automatisering voor gemaakt. Als de Zendure in die opslag modus komt dan wordt deze door een automatisering terug naar RAM gezet. Tevens een melding gestuurd naar mijn mobiel. Dat kan uit, maar geeft even een overzicht of dat vaak gebeurd en of het zich inderdaad goed hersteld. De test ging goed. Doe er evt je voordeel mee.

YAML:

- alias: Zendure - Terugzetten naar RAM-opslag
  description: Zet opslagmodus terug naar RAM als deze op Flash staat
  trigger:
    - platform: state
      entity_id: sensor.zendure_2400_ac_opslagmodus
      to: "Opslaan in Flash"
  condition: []
  action:
    - service: rest_command.zendure_opslaan_in_ram
    - service: notify.notify
      data:
        message: "Opslagmodus van Zendure AC 2400 van Flash naar RAM gewijzigd."
  mode: single

[gielz]

@Hieke Nu opgenomen in de FAQ

🔴 Uitgesteld laden in de opwekseizoen wil ik aanpassen of uitschakelen.

In de Zendure NOM 1.00 heb je bij optie 4 en 5 de uitgesteld laden voorwaarden zitten. Standaard staat deze op 2 uur na zonsondergang starten met laden en 1 uur voor zonsondergang stoppen met laden. Deze kun je aanpassen of de volledige voorwaarde regel uitschakelen.

[wosp]

Taro schreef op zaterdag 26 juli 2025 @ 14:32:
Iemand FireSon integratie 1.1.0-pr8 al succesvol in gebruik met meerdere 2400AC's?

Ik twijfel even welke weg in te slaan. Bij voorkeur gebruik ik de FireSon integratie nog met 3x Hypers in lokale MQTT mode wat inmiddels al heel lang super stabiel draait. Aan de andere kant vind ik de @gielz en @wosp aanvliegroute ook wel mooi en die kan ik ernaast gebruiken.

Of ga ik tijdelijk met een 2e HA installatie aan de slag om de FireSon integratie met alleen de 2400AC's te kunnen testen. Anders moet ik iedere keer alle scripts aanpassen...

Keuzes, keuzes...

Wat voor mij de reden was om toch zelf met de ZenSDK integratie en template van @gielz aan de slag te gaan was voornamelijk lokale communicatie. Een dag daarna ofzo kwam FireSon met de ZenSDK optie voor de 2400AC…Haha. Toch besloten de uren erin te blijven steken om het zelf te regelen, ben je uiteindelijk veel vrijer mee in je (toekomstige) opties. Dat had in mijn geval met de integratie van FireSon ook gemoeten, want die is ook niet voorzien van alle functies zoals ik het wil.

Ik ben niet bekend met de Hypers, maar waarom heb/wil je MQTT er tussen? Rechtstreeks naar de API praten lijkt me minder foutgevoelig?

Trouwens net zitten testen met de dynamic load balancing die ik vanochtend toegevoegd heb. Werkt echt super, hij verdeelt de load nu mooi over hoe de status is van de batterijen en past dat continue aan indien het uit de pas gaat lopen. Het is nog even wat afrondend werk, maar de mogelijkheden die ik nu heb gekregen/gemaakt zijn echt super gaaf, al zeg ik het zelf.

[ Voor 12% gewijzigd door wosp op 26-07-2025 16:13 ]

[pieterh78]

@gielz even kleine update. Heb nu in de config het uitlezen van de P1 op 10 sec staan, van de Energy socket op 11. De NOM automation loopt elke 9 seconden. Ik had bij het ontladen last van flinke schommelingen in het ontlaadvermogen. Die schoot naar de maximale 800 watt wanneer er bv maar 300 gevraagd werd en vervolgens weer naar 0 omdat er teruggeleverd werd etc. Ik heb in de automation nu de factor bij het ontladen naar 0,9 gezet ipv 1





Dit resulteerde in een nette grafiek van afgelopen nacht vond ik. 1 klein piekje van 85watt terugleveren maar verder alles ruim onder de 50 watt en heel veel zelfs tussen de 1 en 20 watt afname en levering. Die grote spike was de waterkoker of het koffie apparaat 😁



Begint ergens op te lijken nu. Denk je dat er nog meer winst te behalen valt? Liefst nog verder naar 0 maar dat wordt lastig denk ik met mij dsmr 4 meter?

[Taro]

wosp schreef op zaterdag 26 juli 2025 @ 16:03:
[...]


Wat voor mij de reden was om toch zelf met de ZenSDK integratie en template van @gielz aan de slag te gaan was voornamelijk lokale communicatie. Een dag daarna ofzo kwam FireSon met de ZenSDK optie voor de 2400AC…Haha. Toch besloten de uren erin te blijven steken om het zelf te regelen, ben je uiteindelijk veel vrijer mee in je (toekomstige) opties. Dat had in mijn geval met de integratie van FireSon ook gemoeten, want die is ook niet voorzien van alle functies zoals ik het wil.

Ik ben niet bekend met de Hypers, maar waarom heb/wil je MQTT er tussen? Rechtstreeks naar de API praten lijkt me minder foutgevoelig?

De Hypers ondersteunen dat naar mijn weten niet. Daarom via MQTT.

Trouwens net zitten testen met de dynamic load balancing die ik vanochtend toegevoegd heb. Werkt echt super, hij verdeelt de load nu mooi over hoe de status is van de batterijen en past dat continue aan indien het uit de pas gaat lopen. Het is nog even wat afrondend werk, maar de mogelijkheden die ik nu heb gekregen/gemaakt zijn echt super gaaf, al zeg ik het zelf.

Benieuwd

[gielz]

pieterh78 schreef op zaterdag 26 juli 2025 @ 16:25:
@gielz even kleine update. Heb nu in de config het uitlezen van de P1 op 10 sec staan, van de Energy socket op 11. De NOM automation loopt elke 9 seconden. Ik had bij het ontladen last van flinke schommelingen in het ontlaadvermogen. Die schoot naar de maximale 800 watt wanneer er bv maar 300 gevraagd werd en vervolgens weer naar 0 omdat er teruggeleverd werd etc. Ik heb in de automation nu de factor bij het ontladen naar 0,9 gezet ipv 1

[Afbeelding]

[Afbeelding]

Dit resulteerde in een nette grafiek van afgelopen nacht vond ik. 1 klein piekje van 85watt terugleveren maar verder alles ruim onder de 50 watt en heel veel zelfs tussen de 1 en 20 watt afname en levering. Die grote spike was de waterkoker of het koffie apparaat 😁

[Afbeelding]

Begint ergens op te lijken nu. Denk je dat er nog meer winst te behalen valt? Liefst nog verder naar 0 maar dat wordt lastig denk ik met mij dsmr 4 meter?

Wat ik zelf zou doen is eens bellen met je netbeheerder. En even goed uitleggen "ik wil NOM, duurzaam, beter mileu etc" en vragen of ze een nieuwe slimme meter kunnen plaatsen. Mocht dat niet lukken, paar keer bellen je kunt maar net een medewerker aan de lijn krijgen die helemaal voor is.

Mocht dit niet lukken kun je overwegen om een Shelly te (laten) plaatsen met CT klemmen of een KWH meter direct na je hoofdaansluiting.

Is dit allemaal geen optie dan kun je ook nog voor kiezen om overdag zoveel mogelijk te balanceren in NOM en dan als je gaat slapen hem van NOM naar handmatig te zetten met één standaard waarde. Vervolgens bij het opstaan weer NOM.

[pieterh78]

gielz schreef op zaterdag 26 juli 2025 @ 17:35:
[...]


Wat ik zelf zou doen is eens bellen met je netbeheerder. En even goed uitleggen "ik wil NOM, duurzaam, beter mileu etc" en vragen of ze een nieuwe slimme meter kunnen plaatsen. Mocht dat niet lukken, paar keer bellen je kunt maar net een medewerker aan de lijn krijgen die helemaal voor is.

Mocht dit niet lukken kun je overwegen om een Shelly te (laten) plaatsen met CT klemmen of een KWH meter direct na je hoofdaansluiting.

Is dit allemaal geen optie dan kun je ook nog voor kiezen om overdag zoveel mogelijk te balanceren in NOM en dan als je gaat slapen hem van NOM naar handmatig te zetten met één standaard waarde. Vervolgens bij het opstaan weer NOM.

Haha dat is nog een optie inderdaad. Waarschijnlijk komt er binnen nu en een half jaar toch een uitbreiding naar 3 fasen en dan komt er een nieuwe meter bij. Denk dat ik even zo laat. Het werkt best goed voor nu vind ik. Is al een heel verschil met wat het was.

[jaychunlai]

Hoe doen jullie dit? Als jullie NOM 1.0 draaien, hoe laden jullie de batterijen weer op ?

Zag al iets staan met zonsondergang dingetje

[ Voor 36% gewijzigd door jaychunlai op 28-07-2025 14:35 ]

[Hieke]

gielz schreef op zaterdag 26 juli 2025 @ 15:39:
@Hieke Nu opgenomen in de FAQ

🔴 Uitgesteld laden in de opwekseizoen wil ik aanpassen of uitschakelen.

In de Zendure NOM 1.00 heb je bij optie 4 en 5 de uitgesteld laden voorwaarden zitten. Standaard staat deze op 2 uur na zonsondergang starten met laden en 1 uur voor zonsondergang stoppen met laden. Deze kun je aanpassen of de volledige voorwaarde regel uitschakelen.
[Afbeelding]

Ik heb het script maar even handmatig naar eigen behoefte aangepast.

Dank voor de reminder.

Wat is de functie van Alleen slim opladen en Alleen slim ontladen?
En in welke situatie zou ik die moeten kiezen?

Draai in principe NOM. Heb nu de offset in de avond wat aangepast om nog wat avondzon van de panelen op het westen (1500 wp) mee te pikken als het koken voor ontlading van de accu heeft gezorgd. Alle beetjes helpen tenslotte.

[gielz]

Hieke schreef op maandag 28 juli 2025 @ 15:10:
[...]
Wat is de functie van Alleen slim opladen en Alleen slim ontladen?
En in welke situatie zou ik die moeten kiezen?

Hebben nog niet specifiek een doel buiten in dynamisch geloof ik. Wanneer je ze nu gebruikt zullen ze ook niet optimaal werken. Hiervoor moet je even de automatisering van stap (4 van 5) Batterij modus automatisering opnieuw overnemen. Ik heb hem vandaag werkend getest.

Meest gebruikte opties zijn NOM en vol vermogen ontladen en laden. Zelf gebruik ik alleen NOM.

[Taro]

Hieke schreef op maandag 28 juli 2025 @ 15:10:
[...]
Wat is de functie van Alleen slim opladen en Alleen slim ontladen?
En in welke situatie zou ik die moeten kiezen?

Die zijn bij dynamisch heel erg nuttig en zet ik zelf als volgt in:

Als het tarief laag is, bijv. 15 ct/kWh en je hebt de accu's volgeladen voor 15 ct/kWh, op dat moment zet je een grootverbruiker aan. Wil je dan dat dat vermogen uit de accu's komt of van het net? Juist, van het net. Dus bij een laag tarief wil je wel laden, maar niet ontladen. Dus kies je voor Smart Charging.

Andersom: Het tarief is 30 ct/kWh en er wordt overschot teruggeleverd, over 2 uur wordt het tarief 15 ct/kWh gedurende 6 uur lang. Wil je dan dat de accu's nu voor 30 ct/kWh worden volgeladen, of wil je wel ontladen, niet laden, straks je accu's goedkoper volgooien en nu duur terugleveren? Juist, laden wil je dan niet, maar ontladen wel. Dus kies je niet voor NOM, maar voor Smart Discharging.

[Hieke]

Ok, duidelijk. Maar dat moet dan wel geautomatiseerd gaan, lijkt mij. Dit wil je niet handmatig bewaken.

Ik houd het met lopend vast contract nog maar even bij NOM. Heb goed gevoel bij een score van 97% zelfvoorziening over afgelopen week.

[Taro]

Hieke schreef op maandag 28 juli 2025 @ 16:24:
Ok, duidelijk. Maar dat moet dan wel geautomatiseerd gaan, lijkt mij. Dit wil je niet handmatig bewaken.

Klopt, gaat hier dan ook volledig geautomatiseerd

Heb goed gevoel bij een score van 97% zelfvoorziening over afgelopen week.

Is ook supernetjes

[ Voor 19% gewijzigd door Taro op 28-07-2025 16:43 ]

[gielz]

Om wat meer duidelijkheid te krijgen in de TS wie welke aansturing gebruikt die binnen dit topic besproken worden heb ik een strawpoll gemaakt. Graag je Tweakers gebruikersnaam gebruiken zodat nieuwe gebruikers van Zendure kunnen zien wie wat nou eigenlijk gebruikt.

https://strawpoll.com/05ZdzxXvmn6

Bedankt alvast

[Peutpeut]

Topic deels doorgenomen, wat ik niet zo snel terug kan vinden is het volgende. Ik zou graag de 2400AC aansturen via Zendure met de Ecotracker, dit verloopt lokaal. Dan wil ik voor aansturing (rondom EV laden) en uitlezen een lokale integratie gebruiken. Is dat mogelijk via ZenSDK of ben ik dan een soort van verplicht om ook de NOM via Home Assistant te laten lopen?
Wat ik wil voorkomen is bij downtime van HA dat de NOM regeling niet meer werkt.

[Taro]

Peutpeut schreef op maandag 28 juli 2025 @ 20:15:
Topic deels doorgenomen, wat ik niet zo snel terug kan vinden is het volgende. Ik zou graag de 2400AC aansturen via Zendure met de Ecotracker, dit verloopt lokaal. Dan wil ik voor aansturing (rondom EV laden) en uitlezen een lokale integratie gebruiken. Is dat mogelijk via ZenSDK of ben ik dan een soort van verplicht om ook de NOM via Home Assistant te laten lopen?
Wat ik wil voorkomen is bij downtime van HA dat de NOM regeling niet meer werkt.

Eigenlijk wil je EV/laadpaal integratie in Zendure NOM, een feature request die ik lang geleden ook heb ingediend, maar die lastig voor ze te realiseren zal zijn ivm het ontbreken van een goede wereldwijde standaard waar ze op in kunnen haken.

Wat je kunt doen: HA lokaal draaien, lokaal ZenSDK gebruiken, lokale P1-meter gebruiken en dan je laadpaal aansturing meenemen, exact wat ik ook doe. Valt HA uit, dan knal je via je Zendure App alle devices in HEMS, NOM aan én door zonder EV/laadpaal ondersteuning.

[gielz]

Taro schreef op maandag 28 juli 2025 @ 20:25:
[...]

Eigenlijk wil je EV/laadpaal integratie in Zendure NOM, een feature request die ik lang geleden ook heb ingediend, maar die lastig voor ze te realiseren zal zijn ivm het ontbreken van een goede wereldwijde standaard waar ze op in kunnen haken.

Wat je kunt doen: HA lokaal draaien, lokaal ZenSDK gebruiken, lokale P1-meter gebruiken en dan je laadpaal aansturing meenemen, exact wat ik ook doe. Valt HA uit, dan knal je via je Zendure App alle devices in HEMS, NOM aan én door zonder EV/laadpaal ondersteuning.

Dit is ook hoe ik het hier exact heb. Alles draait via Home Assistant. Als deze plat gaat dan kost het mij 2-3 uur om een backup terug te plaatsen. Mocht dit niet lukken dan is de batterij mijn kleinste probleem omdat het hele huis via Home Assistant draait (niet alleen 2 lampjes ). Voor de batterij is het dan alleen een HEMS vinkje omschakelen via de Zendure APP en de batterij draait weer buiten Home Assistant om.

[wosp]

@Taro en eventuele anderen met interesse, mijn variant op de templates van @gielz is af, dat wil zeggen er is nog één theoretisch probleem door het toevoegen van dynamic load balancing dat ik kan bedenken maar nog geen echte oplossing voor bedacht heb. Nog eens goed over nadenken, denk gerust mee. :-) Probleem is dat als je load dynamisch stuurt a.d.h.v. de actuele SoC van de betreffende omvormer/batterij, dat bij grote vraag en een groot SoC verschil (dat laatste gebeurd in de praktijk niet vaak), dat het kan zijn als je bijv. 3 omvormers hebt en de vraag is maximaal (7200 Watt), terwijl batterij 1 en 2 elk 40% van de vraag moeten leveren en batterij 3 slechts 20%, dat batterij 3 ingesteld wordt op een ontlaadvermogen van 1440 Watt, 1 en 2 kunnen samen maximaal 4800 Watt leveren dus wordt er max. 6240 Watt geleverd i.p.v. 7200 Watt. Zat te denken aan iets dat als de te leveren waarde van een batterij hoger dan 2400 W is, dat het restant dan opgeteld moet worden bij een batterij die minder dan 2400 W moet leveren. Maar om dat netjes in de code te verwerken is me zo nog niet gelukt. Ook een beetje tijdgebrek vanaf morgen, dus wilde het graag vanavond afronden en hier posten.

Nog even globaal opsommen wat de toevoegingen zijn:

- Geschikt gemaakt voor 3 omvormers (2400 AC)
- Dynamic Load Balancing op basis van huidige SoC per omvormer
- Handmatige Modus standaard geïntegreerd in template
- Automatische wekelijkse kalibratie op zondag om 15.00 uur (+ mogelijkheid om met 1 druk op de knop een keer extra te kalibreren), na kalibratie terug naar modus die daarvoor geselecteerd was.
- Monitoring ingestelde minimale SoC (10%) en maximale SoC (90%) + automatische aanpassing indien foutief (tenzij aan het kalibreren, dan 10-100%)
- Monitoring van Modus Selecteren automation (nu Zendure Manager) en indien uitgeschakeld terwijl NOM automatisering (nu Zendure Worker) loopt deze weer inschakelen
- Monitoring van Zendure Worker automation indien deze benodigd is voor de werking + automatisch inschakelen
- Monitoring van P1 en kWh meter data (is deze recent bijgewerkt), zo niet en draait er een modus die deze data nodig heeft (NOM + Slim Opladen (nu NOM Alleen Opladen) + Slim Ontladen (nu NOM Alleen Ontladen)) dan stop alles. Bij herstel van de P1 en kWh meter data wordt de werking automatisch hervat.
- Bij stoppen HA (bijv. reboot) wordt alles gestopt en modus welke draaide wordt onthouden, bij start HA wordt deze modus hervat (ook kalibreren)
- Monitoring van de omvormers, indien deze niet synchroon lopen qua modus (opladen/ontladen/opladen) terwijl dit wel zo zou moeten zijn op dat moment, dan wordt dit hersteld.
- Ik zet de Led op alle omvormers standaard uit en check hier ook regelmatig op, indien aan, dan uitzetten.
- Indien één of twee omvormers wegvallen (of in een staat zijn waarin ze niks meer mogen, bijv. vol of leeg), worden de taken voor zover dat mogelijk is (max. 2400W per omvormer) overgenomen door de overgebleven omvormers. Als er nog maar 1 omvormer beschikbaar is, gaat deze uiteraard 100% van het werk leveren, bij 2 beschikbare dynamisch, maar zeg 50/50 voor het gemak. Zodra weggevallen omvormers weer beschikbaar komen, wordt dit weer teruggezet en gaan die automatisch weer mee doen en hun aandeel ontladen of opladen.
- De omvormers hebben met enige regelmaat zo'n -20W sluipverbruik als ze niks staan te doen (bij elke integratie die ik tot nu toe getest heb, in de Zendure app kan je dit alleen niet zien). Ik ben er achter dat meestal als dit het geval is, je dit kan oplossen door de modus aan te passen van Ontladen naar Opladen of andersom. Hij moet dan in de tegenovergestelde modus staat van waar hij als laatst in gedraaid heeft. Ik heb dit geïntegreerd in de templates dat dit altijd automatisch gebeurd zodra een omvormer naar idle stand gaat (bijv. vol geladen, of wachten op overschot). Helaas voorkomt dit niet altijd het sluipverbruik, maar het wordt wel gigantisch verminderd! Geen idee waarom het soms zo is als de tegenovergestelde modus gebruikt wordt dit toch sluipverbruik oplevert. Ingestelde vermogens staan in alle gevallen op 0 (en de laatst gebruikte modus inschakelen maakt dan ook geen verschil). Misschien kom ik er nog eens achter (of weet iemand dit) en kan ik de templates aanpassen zodat dit in alle gevallen het sluipverbruik tegen gaat.

Enkele zaken om rekening mee te houden:
- Indien de aansturing handmatig uitgeschakeld moet worden, eerst naar Standby modus, dan wordt de Zendure Worker al uitgeschakeld en daarna kan desgewenst ook de Zendure Manager uitgeschakeld worden. Daarna doet deze aansturing niks meer en kan je bijv. HEMS inschakelen om die op dat moment te gebruiken.
- Ik heb elke omvormer op een eigen groep (en eigen fase) en heb per omvormer 4 batterijen aangesloten en daardoor gebruik ik de maximale 2400 Watt overal (daardoor ook geen probleem met C-waarde). Ik ga er vanuit dat je dit ook zo hebt geregeld, zo niet dan dien je dit aan te passen in de templates! Idem. indien je bijvoorbeeld een wisselende configuratie hebt (omvormers met verschillend aantal batterijen). Met wat knip en plakwerk zouden de templates ook relatief simpel geschikt gemaakt moeten kunnen worden voor 2 of 4 omvormers, maar dat mag degene die dat wilt dan zelf doen. ;-)
- Ik heb de laatste functies vandaag afgemaakt en zover mogelijk getest, maar er kan daardoor hier en daar nog een foutje inzitten. Hoor het graag als je een dergelijke situatie tegenkomt met bij voorkeur een mogelijkheid om te reproduceren en de tracering van de automation in HA. Geen garanties!
- Ik gebruik de 3-fase kWh meter van HomeWizard en een P1 USB, ik heb de templates even aangepast zodat deze nu ingesteld staat om te gebruiken i.c.m. de HW P1, die zal vaker gebruikt worden en zit ook in het voorbeeld van @gielz. De 3-fase kWh meter kan uiteraard ook vervangen worden door losse energy sockets, dan even de configuration.yaml aanpassen naar wens.
- Het is een aardig grote automation geworden, soms is het bij openen de GUI weergave een beetje stroperig. YAML weergave is wel gewoon snel en het heeft geen invloed op de load van de HA machine bij mij. Mogelijk even geduld hebben bij openen als je de GUI weergave wilt gebruiken.

In de configuration.yaml even "search and replace" van:

<IP-BATTERIJ_1>
<IP-BATTERIJ_2>
<IP-BATTERIJ_3>
<SERIAL-2400AC_1>
<SERIAL-2400AC_2>
<SERIAL-2400AC_3>
<IP-HOMEWIZARD-P1>
<IP-HOMEWIZARD-3-FASE-KWHMETER>

configuration.yaml: https://pastebin.com/RaMZwjNS
Zendure Manager Automation: https://pastebin.com/h3BbErSD
Zendure Worker Automation: https://pastebin.com/k3mEpntk

HomeAssistant Shutdown Automation:

code:

alias: Home Assistant Shutdown
description: ""
triggers:
  - trigger: homeassistant
    event: shutdown
conditions: []
actions:
  - action: input_text.set_value
    metadata: {}
    data:
      value: "1"
    target:
      entity_id: input_text.zendure_ha_stop_of_herstart_wordt_uitgevoerd
  - if:
      - condition: not
        conditions:
          - condition: state
            entity_id: input_select.zendure_manager
            state: Standby
    then:
      - action: automation.turn_off
        metadata: {}
        data:
          stop_actions: true
        target:
          entity_id: automation.zendure_worker
      - if:
          - condition: state
            entity_id: sensor.zendure_2400_ac_1_modus
            state: Opladen
        then:
          - action: rest_command.zendure_2400_ac_1_stoppen_modus_is_opladen
            data: {}
      - if:
          - condition: state
            entity_id: sensor.zendure_2400_ac_2_modus
            state: Opladen
        then:
          - action: rest_command.zendure_2400_ac_2_stoppen_modus_is_opladen
            data: {}
      - if:
          - condition: state
            entity_id: sensor.zendure_2400_ac_3_modus
            state: Opladen
        then:
          - action: rest_command.zendure_2400_ac_3_stoppen_modus_is_opladen
            data: {}
      - if:
          - condition: state
            entity_id: sensor.zendure_2400_ac_1_modus
            state: Ontladen
        then:
          - action: rest_command.zendure_2400_ac_1_stoppen_modus_is_ontladen
            data: {}
      - if:
          - condition: state
            entity_id: sensor.zendure_2400_ac_2_modus
            state: Ontladen
        then:
          - action: rest_command.zendure_2400_ac_2_stoppen_modus_is_ontladen
            data: {}
      - if:
          - condition: state
            entity_id: sensor.zendure_2400_ac_3_modus
            state: Ontladen
        then:
          - action: rest_command.zendure_2400_ac_3_stoppen_modus_is_ontladen
            data: {}
mode: single

Home Assistant Start Automation:

code:

alias: Home Assistant Start
description: ""
triggers:
  - trigger: homeassistant
    event: start
conditions: []
actions:
  - action: input_text.set_value
    metadata: {}
    data:
      value: "0"
    target:
      entity_id: input_text.zendure_ha_stop_of_herstart_wordt_uitgevoerd
  - if:
      - condition: not
        conditions:
          - condition: state
            entity_id: input_select.zendure_manager
            state: Standby
    then:
      - action: automation.turn_on
        metadata: {}
        data: {}
        target:
          entity_id: automation.zendure_worker
mode: single

Verder zou je nog 2 zaken kunen toevoegen aan je dashboard voor het beheer

code:

features:
  - type: select-options
type: tile
entity: input_select.zendure_manager
features_position: inline
vertical: false
hide_state: true
show_entity_picture: false

code:

type: entities
entities:
  - entity: input_number.zendure_handmatig_vermogen
    name: Ingesteld Vermogen
show_header_toggle: false

Dan zijn we er wel geloof ik.

[ Voor 12% gewijzigd door wosp op 28-07-2025 21:44 ]

[Peutpeut]

Taro schreef op maandag 28 juli 2025 @ 20:25:
[...]

Eigenlijk wil je EV/laadpaal integratie in Zendure NOM, een feature request die ik lang geleden ook heb ingediend, maar die lastig voor ze te realiseren zal zijn ivm het ontbreken van een goede wereldwijde standaard waar ze op in kunnen haken.

Wat je kunt doen: HA lokaal draaien, lokaal ZenSDK gebruiken, lokale P1-meter gebruiken en dan je laadpaal aansturing meenemen, exact wat ik ook doe. Valt HA uit, dan knal je via je Zendure App alle devices in HEMS, NOM aan én door zonder EV/laadpaal ondersteuning.

Het voordeel van een lokaal verbonden P1 meter is dat de NOM regeling dan niet afhankelijk is van Home Assistant. De vraag blijft onbeantwoord, kan ik ZenSDK gebruiken zonder vast te zitten aan de NOM optie die daar in zit?

@gielz Hier idem, dan gaat er geen lamp meer vanzelf aan We hebben, waar het kan, nog zoveel mogelijk fysieke schakelaars laten zitten met Zigbee inbouwmodules, dan is op een handvol lampen na gelukt.

[gielz]

Peutpeut schreef op maandag 28 juli 2025 @ 21:36:
[...]

Het voordeel van een lokaal verbonden P1 meter is dat de NOM regeling dan niet afhankelijk is van Home Assistant. De vraag blijft onbeantwoord, kan ik ZenSDK gebruiken zonder vast te zitten aan de NOM optie die daar in zit?

@gielz Hier idem, dan gaat er geen lamp meer vanzelf aan We hebben, waar het kan, nog zoveel mogelijk fysieke schakelaars laten zitten met Zigbee inbouwmodules, dan is op een handvol lampen na gelukt.

De ZenSDK is alleen het platform. Daarbij draai je dan automatiseringen om de boel naar wens te regelen. De ZenSDK kan dus eigenlijk zelf niets buiten dat je data kunt opvragen en opdrachten kunt sturen.

Je zou bijvoorbeeld dus ook ZenSDK alleen kunnen gebruiken om in Home Assistant je batterij te bekijken maar dan via de Zendure APP de aansturing te laten lopen.

[gielz]

wosp schreef op maandag 28 juli 2025 @ 21:35:
@Taro en eventuele anderen met interesse, mijn variant op de templates van @gielz is af, dat wil zeggen er is nog één theoretisch probleem door het toevoegen van dynamic load balancing dat ik kan bedenken maar nog geen echte oplossing voor bedacht heb. Nog eens goed over nadenken, denk gerust mee. :-) Probleem is dat als je load dynamisch stuurt a.d.h.v. de actuele SoC van de betreffende omvormer/batterij, dat bij grote vraag en een groot SoC verschil (dat laatste gebeurd in de praktijk niet vaak), dat het kan zijn als je bijv. 3 omvormers hebt en de vraag is maximaal (7200 Watt), terwijl batterij 1 en 2 elk 40% van de vraag moeten leveren en batterij 3 slechts 20%, dat batterij 3 ingesteld wordt op een ontlaadvermogen van 1440 Watt, 1 en 2 kunnen samen maximaal 4800 Watt leveren dus wordt er max. 6240 Watt geleverd i.p.v. 7200 Watt. Zat te denken aan iets dat als de te leveren waarde van een batterij hoger dan 2400 W is, dat het restant dan opgeteld moet worden bij een batterij die minder dan 2400 W moet leveren. Maar om dat netjes in de code te verwerken is me zo nog niet gelukt. Ook een beetje tijdgebrek vanaf morgen, dus wilde het graag vanavond afronden en hier posten.

Nog even globaal opsommen wat de toevoegingen zijn:

- Geschikt gemaakt voor 3 omvormers (2400 AC)
- Dynamic Load Balancing op basis van huidige SoC per omvormer
- Handmatige Modus standaard geïntegreerd in template
- Automatische wekelijkse kalibratie op zondag om 15.00 uur (+ mogelijkheid om met 1 druk op de knop een keer extra te kalibreren), na kalibratie terug naar modus die daarvoor geselecteerd was.
- Monitoring ingestelde minimale SoC (10%) en maximale SoC (90%) + automatische aanpassing indien foutief (tenzij aan het kalibreren, dan 10-100%)
- Monitoring van Modus Selecteren automation (nu Zendure Manager) en indien uitgeschakeld terwijl NOM automatisering (nu Zendure Worker) loopt deze weer inschakelen
- Monitoring van Zendure Worker automation indien deze benodigd is voor de werking + automatisch inschakelen
- Monitoring van P1 en kWh meter data (is deze recent bijgewerkt), zo niet en draait er een modus die deze data nodig heeft (NOM + Slim Opladen (nu NOM Alleen Opladen) + Slim Ontladen (nu NOM Alleen Ontladen)) dan stop alles. Bij herstel van de P1 en kWh meter data wordt de werking automatisch hervat.
- Bij stoppen HA (bijv. reboot) wordt alles gestopt en modus welke draaide wordt onthouden, bij start HA wordt deze modus hervat (ook kalibreren)
- Monitoring van de omvormers, indien deze niet synchroon lopen qua modus (opladen/ontladen/opladen) terwijl dit wel zo zou moeten zijn op dat moment, dan wordt dit hersteld.
- Ik zet de Led op alle omvormers standaard uit en check hier ook regelmatig op, indien aan, dan uitzetten.
- Indien één of twee omvormers wegvallen (of in een staat zijn waarin ze niks meer mogen, bijv. vol of leeg), worden de taken voor zover dat mogelijk is (max. 2400W per omvormer) overgenomen door de overgebleven omvormers. Als er nog maar 1 omvormer beschikbaar is, gaat deze uiteraard 100% van het werk leveren, bij 2 beschikbare dynamisch, maar zeg 50/50 voor het gemak. Zodra weggevallen omvormers weer beschikbaar komen, wordt dit weer teruggezet en gaan die automatisch weer mee doen en hun aandeel ontladen of opladen.
- De omvormers hebben met enige regelmaat zo'n -20W sluipverbruik als ze niks staan te doen (bij elke integratie die ik tot nu toe getest heb, in de Zendure app kan je dit alleen niet zien). Ik ben er achter dat meestal als dit het geval is, je dit kan oplossen door de modus aan te passen van Ontladen naar Opladen of andersom. Hij moet dan in de tegenovergestelde modus staat van waar hij als laatst in gedraaid heeft. Ik heb dit geïntegreerd in de templates dat dit altijd automatisch gebeurd zodra een omvormer naar idle stand gaat (bijv. vol geladen, of wachten op overschot). Helaas voorkomt dit niet altijd het sluipverbruik, maar het wordt wel gigantisch verminderd! Geen idee waarom het soms zo is als de tegenovergestelde modus gebruikt wordt dit toch sluipverbruik oplevert. Ingestelde vermogens staan in alle gevallen op 0 (en de laatst gebruikte modus inschakelen maakt dan ook geen verschil). Misschien kom ik er nog eens achter (of weet iemand dit) en kan ik de templates aanpassen zodat dit in alle gevallen het sluipverbruik tegen gaat.

Enkele zaken om rekening mee te houden:
- Indien de aansturing handmatig uitgeschakeld moet worden, eerst naar Standby modus, dan wordt de Zendure Worker al uitgeschakeld en daarna kan desgewenst ook de Zendure Manager uitgeschakeld worden. Daarna doet deze aansturing niks meer en kan je bijv. HEMS inschakelen om die op dat moment te gebruiken.
- Ik heb elke omvormer op een eigen groep (en eigen fase) en heb per omvormer 4 batterijen aangesloten en daardoor gebruik ik de maximale 2400 Watt overal (daardoor ook geen probleem met C-waarde). Ik ga er vanuit dat je dit ook zo hebt geregeld, zo niet dan dien je dit aan te passen in de templates! Idem. indien je bijvoorbeeld een wisselende configuratie hebt (omvormers met verschillend aantal batterijen). Met wat knip en plakwerk zouden de templates ook relatief simpel geschikt gemaakt moeten kunnen worden voor 2 of 4 omvormers, maar dat mag degene die dat wilt dan zelf doen. ;-)
- Ik heb de laatste functies vandaag afgemaakt en zover mogelijk getest, maar er kan daardoor hier en daar nog een foutje inzitten. Hoor het graag als je een dergelijke situatie tegenkomt met bij voorkeur een mogelijkheid om te reproduceren en de tracering van de automation in HA. Geen garanties!
- Ik gebruik de 3-fase kWh meter van HomeWizard en een P1 USB, ik heb de templates even aangepast zodat deze nu ingesteld staat om te gebruiken i.c.m. de HW P1, die zal vaker gebruikt worden en zit ook in het voorbeeld van @gielz. De 3-fase kWh meter kan uiteraard ook vervangen worden door losse energy sockets, dan even de configuration.yaml aanpassen naar wens.
- Het is een aardig grote automation geworden, soms is het bij openen de GUI weergave een beetje stroperig. YAML weergave is wel gewoon snel en het heeft geen invloed op de load van de HA machine bij mij. Mogelijk even geduld hebben bij openen als je de GUI weergave wilt gebruiken.

In de configuration.yaml even "search and replace" van:

<IP-BATTERIJ_1>
<IP-BATTERIJ_2>
<IP-BATTERIJ_3>
<SERIAL-2400AC_1>
<SERIAL-2400AC_2>
<SERIAL-2400AC_3>
<IP-HOMEWIZARD-P1>
<IP-HOMEWIZARD-3-FASE-KWHMETER>

configuration.yaml: https://pastebin.com/RaMZwjNS
Zendure Manager Automation: https://pastebin.com/h3BbErSD
Zendure Worker Automation: https://pastebin.com/k3mEpntk

HomeAssistant Shutdown Automation:

code:

alias: Home Assistant Shutdown
description: ""
triggers:
  - trigger: homeassistant
    event: shutdown
conditions: []
actions:
  - action: input_text.set_value
    metadata: {}
    data:
      value: "1"
    target:
      entity_id: input_text.zendure_ha_stop_of_herstart_wordt_uitgevoerd
  - if:
      - condition: not
        conditions:
          - condition: state
            entity_id: input_select.zendure_manager
            state: Standby
    then:
      - action: automation.turn_off
        metadata: {}
        data:
          stop_actions: true
        target:
          entity_id: automation.zendure_worker
      - if:
          - condition: state
            entity_id: sensor.zendure_2400_ac_1_modus
            state: Opladen
        then:
          - action: rest_command.zendure_2400_ac_1_stoppen_modus_is_opladen
            data: {}
      - if:
          - condition: state
            entity_id: sensor.zendure_2400_ac_2_modus
            state: Opladen
        then:
          - action: rest_command.zendure_2400_ac_2_stoppen_modus_is_opladen
            data: {}
      - if:
          - condition: state
            entity_id: sensor.zendure_2400_ac_3_modus
            state: Opladen
        then:
          - action: rest_command.zendure_2400_ac_3_stoppen_modus_is_opladen
            data: {}
      - if:
          - condition: state
            entity_id: sensor.zendure_2400_ac_1_modus
            state: Ontladen
        then:
          - action: rest_command.zendure_2400_ac_1_stoppen_modus_is_ontladen
            data: {}
      - if:
          - condition: state
            entity_id: sensor.zendure_2400_ac_2_modus
            state: Ontladen
        then:
          - action: rest_command.zendure_2400_ac_2_stoppen_modus_is_ontladen
            data: {}
      - if:
          - condition: state
            entity_id: sensor.zendure_2400_ac_3_modus
            state: Ontladen
        then:
          - action: rest_command.zendure_2400_ac_3_stoppen_modus_is_ontladen
            data: {}
mode: single

Home Assistant Start Automation:

code:

alias: Home Assistant Start
description: ""
triggers:
  - trigger: homeassistant
    event: start
conditions: []
actions:
  - action: input_text.set_value
    metadata: {}
    data:
      value: "0"
    target:
      entity_id: input_text.zendure_ha_stop_of_herstart_wordt_uitgevoerd
  - if:
      - condition: not
        conditions:
          - condition: state
            entity_id: input_select.zendure_manager
            state: Standby
    then:
      - action: automation.turn_on
        metadata: {}
        data: {}
        target:
          entity_id: automation.zendure_worker
mode: single

Verder zou je nog 2 zaken kunen toevoegen aan je dashboard voor het beheer

code:

features:
  - type: select-options
type: tile
entity: input_select.zendure_manager
features_position: inline
vertical: false
hide_state: true
show_entity_picture: false

code:

type: entities
entities:
  - entity: input_number.zendure_handmatig_vermogen
    name: Ingesteld Vermogen
show_header_toggle: false

Dan zijn we er wel geloof ik.

Was wel een flinke huiswerk opdracht zo te zien.

Mocht je het allemaal zelf werkend hebben zou het ook wel gaaf zijn om te zien zijn hoe het allemaal samen met elkaar werkt om NOM te gaan met 3 stuks!

[geert1992]

gielz schreef op maandag 28 juli 2025 @ 19:12:
Om wat meer duidelijkheid te krijgen in de TS wie welke aansturing gebruikt die binnen dit topic besproken worden heb ik een strawpoll gemaakt. Graag je Tweakers gebruikersnaam gebruiken zodat nieuwe gebruikers van Zendure kunnen zien wie wat nou eigenlijk gebruikt.

https://strawpoll.com/05ZdzxXvmn6

Bedankt alvast

En wat moet je doen als je keuze er niet tussenstaat?

[gielz]

geert1992 schreef op maandag 28 juli 2025 @ 22:17:
[...]


En wat moet je doen als je keuze er niet tussenstaat?

Heb je geen eigen Homey topic.

Homey kan nu ook gekozen worden alleen heb ik daar niets voor in de TS staan. Wellicht kan een Homie iets over Homey schrijven. Of is dat echt plug-n-play?

[geert1992]

gielz schreef op maandag 28 juli 2025 @ 22:21:
[...]


Heb je geen eigen Homey topic.

Homey kan nu ook gekozen worden alleen heb ik daar niets voor in de TS staan. Wellicht kan een Homie iets over Homey schrijven. Of is dat echt plug-n-play?

Thanks @gielz .

Inmiddels heb ik al 1 homey, die net als ik ook homey gebruikt, namelijk @Aziraphale. Misschien kunnen we ons homey imperium uitbreiden, en inderdaad eens bezig gaan met een howto of iets degelijks.

[wosp]

gielz schreef op maandag 28 juli 2025 @ 22:17:
[...]


Was wel een flinke huiswerk opdracht zo te zien.

Mocht je het allemaal zelf werkend hebben zou het ook wel gaaf zijn om te zien zijn hoe het allemaal samen met elkaar werkt om NOM te gaan met 3 stuks!

Ja, het was flink meer werk dan vooraf gedacht. Je komt van het een in het ander. Ik heb zoveel mogelijk “wat als” situaties bedacht en daarop gebouwd en zoveel mogelijk fail proof en self healing gemaakt. Ben er wel blij mee, draait hier prima nom met 3 stuks op dit moment. Als ik binnenkort nog wat tijd over heb dan ga ik aan de slag met de samenwerking tussen de Zappi EV lader en de batterijen. Wil de auto altijd voorrang geven en nooit laden uit de batterijen. Gebeurd wel geregeld dat we hier zo’n 14.000-16.000 W opwek (60 panelen…oeps) hebben in de zomer, dus ze moeten wel tegelijk kunnen laden. Zal iets zijn met dat als de auto ingeplugd is dat de batterij naar NOM Opladen gaat tot (indien nog niet vol) een uur voor zonsondergang, dan autolader pauze en omschakelen naar normale NOM. In de ochtend weer starten. De autolader zelf staat al ingesteld op laden op alleen overschot. Van April tot September gaat er geen Watt de auto’s in die niet zelf opgewekt is. Was i.i.g. een leuke klus dit. Hoop dat anderen er ook nog wat aan hebben.

[mrme12345]

gielz schreef op maandag 28 juli 2025 @ 22:15:
[...]


De ZenSDK is alleen het platform. Daarbij draai je dan automatiseringen om de boel naar wens te regelen. De ZenSDK kan dus eigenlijk zelf niets buiten dat je data kunt opvragen en opdrachten kunt sturen.

Je zou bijvoorbeeld dus ook ZenSDK alleen kunnen gebruiken om in Home Assistant je batterij te bekijken maar dan via de Zendure APP de aansturing te laten lopen.

Ja zo heb ik het ook, ik gebruik de zenSDK in combinatie met node-red in HA om mijn NOM en pv overschot te laden. En dan met verschillende varianten voor de verschillende devices en combinaties.

[Peutpeut]

gielz schreef op maandag 28 juli 2025 @ 22:15:
[...]


De ZenSDK is alleen het platform. Daarbij draai je dan automatiseringen om de boel naar wens te regelen. De ZenSDK kan dus eigenlijk zelf niets buiten dat je data kunt opvragen en opdrachten kunt sturen.

Je zou bijvoorbeeld dus ook ZenSDK alleen kunnen gebruiken om in Home Assistant je batterij te bekijken maar dan via de Zendure APP de aansturing te laten lopen.

Dan ga ik daar eens mee beginnen zodra de set er is. 👍

[wosp]

@gielz Nog even een vraagje, in jouw template in opties 3 (ontladen balanceren) en optie 5 (opladen balanceren) heb je dat eerder besproken sjabloon om te voorkomen dat een opdracht naar de API gestuurd wordt indien diezelfde waarde al ingesteld staat. Nu viel me alleen nog op dat bij de sjabloon voor ontladen balanceren de correctie hier op 0 gezet wordt en bij opladen balanceren de factor die aan het begin van het sjabloon gezet is niet gebruikt wordt. Weet je heel toevallig nog waarom je dat zo gedaan hebt?

[gielz]

wosp schreef op dinsdag 29 juli 2025 @ 11:09:
@gielz Nog even een vraagje, in jouw template in opties 3 (ontladen balanceren) en optie 5 (opladen balanceren) heb je dat eerder besproken sjabloon om te voorkomen dat een opdracht naar de API gestuurd wordt indien diezelfde waarde al ingesteld staat. Nu viel me alleen nog op dat bij de sjabloon voor ontladen balanceren de correctie hier op 0 gezet wordt en bij opladen balanceren de factor die aan het begin van het sjabloon gezet is niet gebruikt wordt. Weet je heel toevallig nog waarom je dat zo gedaan hebt?

Die instellingen staan inderdaad niet goed en doen nu eigenlijk niets. Deze regel zorgt er alleen voor dat het API verkeer beperkt word en doet gelukkig niets voor de NOM.

Zal vanavond even de TS updaten met de correctie in de automatisering.

[Taro]

@wosp Thx, heb alles toegevoegd. Nu nog ff 3 uurtjes maximaal laden, daarna testen of het werkt

Vraagje: Heb zowel een HW P1-meter als HW 3-fase kWh meter, maar die laatste zit in de onderverdeler in de garage en meet dus niet bij de hoofdaansluiting. Heb daarom de regels van de 3-fase kWh meter verwijderd en die van de HW P1-meter correct ingevuld. Is dat de juiste aanvliegroute en moet ik dan ergens anders nog iets aanpassen of verwijzen naar de HW P1-meter ipv 3-fase kWh meter?

[wosp]

Taro schreef op dinsdag 29 juli 2025 @ 12:50:
@wosp Thx, heb alles toegevoegd. Nu nog ff 3 uurtjes maximaal laden, daarna testen of het werkt

Vraagje: Heb zowel een HW P1-meter als HW 3-fase kWh meter, maar die laatste zit in de onderverdeler in de garage en meet dus niet bij de hoofdaansluiting. Heb daarom de regels van de 3-fase kWh meter verwijderd en die van de HW P1-meter correct ingevuld. Is dat de juiste aanvliegroute en moet ik dan ergens anders nog iets aanpassen of verwijzen naar de HW P1-meter ipv 3-fase kWh meter?

Het doel van de 3-fase meter is het verbruik of ontladen van de batterijen samen te meten, de P1 meter wordt gebruikt om de hoofdaansluiting te meten. Je gebruikt in dit geval dus allebei, op voorwaarde dat die 3-fase meter alleen de batterijen meten en niks anders. Als dat niet zo is, dan zou je per omvormer een energy socket kunnen gebruiken. Daarbij (dat is misschien in mijn post van gisteren niet helemaal duidelijk) is het belangrijk dat je deze energy sockets toevoegt aan de configuration.yaml (vanwege elke seconde een update). Vervolgens verwijder je dan de 3-fase kWh meter uit de configuration.yaml, maar maak je een template sensor (Helper) aan in HA die je Zendure 2400 AC 1-3 Vermogen Aansturing API v1 (sensor.Zendure_2400_AC_1_3_Vermogen_Aansturing_API_V1) noemt (of anders, maar dan moet je de deze naam ook even "search and replace" aanpassen in de automations).

In die template sensor tel je de 3 energy sockets bij elkaar op, omdat de automations een totale waarde nodig hebben van de batterijen samen. Zal zoiets zijn (niet zelf getest):

code:

{% set energy_socket_1_wattage = states('sensor.Zendure_2400_AC_1_Vermogen_Aansturing_API_V1') | float %}
{% set energy_socket_2_wattage = states('sensor.Zendure_2400_AC_2_Vermogen_Aansturing_API_V1') | float %}
{% set energy_socket_3_wattage = states('sensor.Zendure_2400_AC_3_Vermogen_Aansturing_API_V1') | float %}
{{ energy_socket_1_wattage + energy_socket_2_wattage + energy_socket_3_wattage | round(0) }}

In de configuration.yaml moet uiteraard ook voor elke energy socket het voltage uit de API data gehaald worden (active_voltage). Dit is nodig voor de monitoring van de gegevens die nodig zijn voor NOM (het vermogen wordt niet geupdate als dit niet verandert is, waardoor de automation ten onrechte kan denken dat er geen recente update is geweest en de meter dus onbeschikbaar is. Het voltage wordt wel continue geupdate (want is nooit lang hetzelfde) en kan daardoor dus mooi voor de monitoring gebruikt worden om te checken of de meter nog beschikbaar is en data doorgeeft. In je configuration.yaml zou dat er dan ongeveer zo uit moeten komen zien:

code:

  - resource: http://<IP-HOMEWIZARD-P1>/api/v1/data
    scan_interval: 1
    sensor:
      - name: "P1 Aansturing API v1"
        value_template: "{{ value_json.active_power_w | float }}"
        unique_id: P1_Aansturing_API_V1
        unit_of_measurement: "W"
        device_class: power

  - resource: http://<IP-HOMEWIZARD-ENERGY-SOCKET-1>/api/v1/data
    scan_interval: 1

      - name: "Zendure 2400 AC #1 Vermogen Aansturing API v1"
        value_template: "{{ value_json.active_power_w | float }}"
        unique_id: Zendure_2400_AC_1_Vermogen_Aansturing_API_V1
        unit_of_measurement: "W"
        device_class: power

      - name: "Zendure 2400 AC #1 Voltage Aansturing API v1"
        value_template: "{{ value_json.active_voltage_v | float }}"
        unique_id: Zendure_2400_AC_1_Voltage_Aansturing_API_V1
        unit_of_measurement: "V"
        device_class: voltage

  - resource: http://<IP-HOMEWIZARD-ENERGY-SOCKET-2>/api/v1/data
    scan_interval: 1

      - name: "Zendure 2400 AC #2 Vermogen Aansturing API v1"
        value_template: "{{ value_json.active_power_w | float }}"
        unique_id: Zendure_2400_AC_2_Vermogen_Aansturing_API_V1
        unit_of_measurement: "W"
        device_class: power

      - name: "Zendure 2400 AC #2 Voltage Aansturing API v1"
        value_template: "{{ value_json.active_voltage_v | float }}"
        unique_id: Zendure_2400_AC_2_Voltage_Aansturing_API_V1
        unit_of_measurement: "V"
        device_class: voltage

  - resource: http://<IP-HOMEWIZARD-ENERGY-SOCKET-3>/api/v1/data
    scan_interval: 1

      - name: "Zendure 2400 AC #3 Vermogen Aansturing API v1"
        value_template: "{{ value_json.active_power_w | float }}"
        unique_id: Zendure_2400_AC_3_Vermogen_Aansturing_API_V1
        unit_of_measurement: "W"
        device_class: power

      - name: "Zendure 2400 AC #3 Voltage Aansturing API v1"
        value_template: "{{ value_json.active_voltage_v | float }}"
        unique_id: Zendure_2400_AC_3_Voltage_Aansturing_API_V1
        unit_of_measurement: "V"
        device_class: voltage

[ Voor 43% gewijzigd door wosp op 29-07-2025 15:40 ]

[wosp]

gielz schreef op dinsdag 29 juli 2025 @ 11:53:
[...]


Die instellingen staan inderdaad niet goed en doen nu eigenlijk niets. Deze regel zorgt er alleen voor dat het API verkeer beperkt word en doet gelukkig niets voor de NOM.

Zal vanavond even de TS updaten met de correctie in de automatisering.

Thanks, dan wordt het gewoon een kwestie van die factor wel toepassen en de correctie wel instellen zoals de andere correcties, of worden die factor en correctie er gewoon uitgehaald?

[ Voor 6% gewijzigd door wosp op 29-07-2025 15:29 ]

[Taro]

wosp schreef op dinsdag 29 juli 2025 @ 15:16:
[...]


Het doel van de 3-fase meter is het verbruik of ontladen van de batterijen samen te meten, de P1 meter wordt gebruikt om de hoofdaansluiting te meten. Je gebruikt in dit geval dus allebei, op voorwaarde dat die 3-fase meter alleen de batterijen meten en niks anders. Als dat niet zo is, dan zou je per omvormer een energy socket kunnen gebruiken. Daarbij (dat is misschien in mijn post van gisteren niet helemaal duidelijk) is het belangrijk dat je deze energy sockets toevoegt aan de configuration.yaml (vanwege elke seconde een update). Vervolgens verwijder je dan de 3-fase kWh meter uit de configuration.yaml, maar maak je een template sensor (Helper) aan in HA die je Zendure 2400 AC 1-3 Vermogen Aansturing API v1 (sensor.Zendure_2400_AC_1_3_Vermogen_Aansturing_API_V1) noemt (of anders, maar dan moet je de deze naam ook even "search and replace" aanpassen in de automations).

In die template sensor tel je de 3 energy sockets bij elkaar op, omdat de automations een totale waarde nodig hebben van de batterijen samen. Zal zoiets zijn (niet zelf getest):

code:

{% set energy_socket_1_wattage = states('sensor.Zendure_2400_AC_1_Vermogen_Aansturing_API_V1') | float %}
{% set energy_socket_2_wattage = states('sensor.Zendure_2400_AC_2_Vermogen_Aansturing_API_V1') | float %}
{% set energy_socket_3_wattage = states('sensor.Zendure_2400_AC_3_Vermogen_Aansturing_API_V1') | float %}
{{ energy_socket_1_wattage + energy_socket_2_wattage + energy_socket_3_wattage | round(0) }}

In de configuration.yaml moet uiteraard ook voor elke energy socket het voltage uit de API data gehaald worden (active_voltage). Dit is nodig voor de monitoring van de gegevens die nodig zijn voor NOM (het vermogen wordt niet geupdate als dit niet verandert is, waardoor de automation ten onrechte kan denken dat er geen recente update is geweest en de meter dus onbeschikbaar is. Het voltage wordt wel continue geupdate (want is nooit lang hetzelfde) en kan daardoor dus mooi voor de monitoring gebruikt worden om te checken of de meter nog beschikbaar is en data doorgeeft. In je configuration.yaml zou dat er dan ongeveer zo uit moeten komen zien:

code:

  - resource: http://<IP-HOMEWIZARD-P1>/api/v1/data
    scan_interval: 1
    sensor:
      - name: "P1 Aansturing API v1"
        value_template: "{{ value_json.active_power_w | float }}"
        unique_id: P1_Aansturing_API_V1
        unit_of_measurement: "W"
        device_class: power

  - resource: http://<IP-HOMEWIZARD-ENERGY-SOCKET-1>/api/v1/data
    scan_interval: 1

      - name: "Zendure 2400 AC #1 Vermogen Aansturing API v1"
        value_template: "{{ value_json.active_power_w | float }}"
        unique_id: Zendure_2400_AC_1_Vermogen_Aansturing_API_V1
        unit_of_measurement: "W"
        device_class: power

      - name: "Zendure 2400 AC #1 Voltage Aansturing API v1"
        value_template: "{{ value_json.active_voltage_v | float }}"
        unique_id: Zendure_2400_AC_1_Voltage_Aansturing_API_V1
        unit_of_measurement: "V"
        device_class: voltage

  - resource: http://<IP-HOMEWIZARD-ENERGY-SOCKET-2>/api/v1/data
    scan_interval: 1

      - name: "Zendure 2400 AC #2 Vermogen Aansturing API v1"
        value_template: "{{ value_json.active_power_w | float }}"
        unique_id: Zendure_2400_AC_2_Vermogen_Aansturing_API_V1
        unit_of_measurement: "W"
        device_class: power

      - name: "Zendure 2400 AC #2 Voltage Aansturing API v1"
        value_template: "{{ value_json.active_voltage_v | float }}"
        unique_id: Zendure_2400_AC_2_Voltage_Aansturing_API_V1
        unit_of_measurement: "V"
        device_class: voltage

  - resource: http://<IP-HOMEWIZARD-ENERGY-SOCKET-3>/api/v1/data
    scan_interval: 1

      - name: "Zendure 2400 AC #3 Vermogen Aansturing API v1"
        value_template: "{{ value_json.active_power_w | float }}"
        unique_id: Zendure_2400_AC_3_Vermogen_Aansturing_API_V1
        unit_of_measurement: "W"
        device_class: power

      - name: "Zendure 2400 AC #3 Voltage Aansturing API v1"
        value_template: "{{ value_json.active_voltage_v | float }}"
        unique_id: Zendure_2400_AC_3_Voltage_Aansturing_API_V1
        unit_of_measurement: "V"
        device_class: voltage

Ah, helder, dan moet ik hem dus wel gebruiken, maar aangezien er ook nog 3x Hypers op diezelfde 3-fase kWh meter zitten wordt dit een lastig verhaal. Of ik moet 2x HW Energy Socket erbij halen... Of de Hypers wegdoen

[gielz]

wosp schreef op dinsdag 29 juli 2025 @ 15:29:
[...]


Thanks, dan wordt het gewoon een kwestie van die factor wel toepassen en de correctie wel instellen zoals de andere correcties, of worden die factor en correctie er gewoon uitgehaald?

Klopt ja ik zet hem vanavond gelijk aan de rest maar dan zonder tikfouten 🤡

[wosp]

Taro schreef op dinsdag 29 juli 2025 @ 16:16:
[...]

Ah, helder, dan moet ik hem dus wel gebruiken, maar aangezien er ook nog 3x Hypers op diezelfde 3-fase kWh meter zitten wordt dit een lastig verhaal. Of ik moet 2x HW Energy Socket erbij halen... Of de Hypers wegdoen

Kan je een situatie creëren waarbij 2 hypers op fase 1 zitten, 2 2400AC's op fase2 en op fase3 een hyper en een 2400AC en die 2400AC die samen met de hyper staat aangesloten op een energy socket? Dan kan je het met je huidige spullen en een beetje creativiteit voor elkaar krijgen:

code:

  - resource: http://<IP-HOMEWIZARD-P1>/api/v1/data
    scan_interval: 1
    sensor:
      - name: "P1 Aansturing API v1"
        value_template: "{{ value_json.active_power_w | float }}"
        unique_id: P1_Aansturing_API_V1
        unit_of_measurement: "W"
        device_class: power

  - resource: http://<IP-HOMEWIZARD-3-FASE-KWHMETER>/api/v1/data
    scan_interval: 1

      - name: "Zendure 2400 AC #1 en AC #2 Vermogen Aansturing API v1"
        value_template: "{{ value_json.active_power_l2_w | float }}"
        unique_id: Zendure_2400_AC_1_Vermogen_Aansturing_API_V1
        unit_of_measurement: "W"
        device_class: power
 
      - name: "Zendure 2400 AC AC #1 en AC #2 Voltage Aansturing API v1"
        value_template: "{{ value_json.active_voltage_l2_v | float }}"
        unique_id: Zendure_2400_AC_1_Voltage_Aansturing_API_V1
        unit_of_measurement: "V"
        device_class: voltage
 
      - name: "Zendure 2400 AC #1 en AC #2 Vermogen Aansturing API v1"
        value_template: "{{ value_json.active_power_l2_w | float }}"
        unique_id: Zendure_2400_AC_2_Vermogen_Aansturing_API_V1
        unit_of_measurement: "W"
        device_class: power
 
      - name: "Zendure 2400 AC #1 en AC #2 Voltage Aansturing API v1"
        value_template: "{{ value_json.active_voltage_l2_v | float }}"
        unique_id: Zendure_2400_AC_2_Voltage_Aansturing_API_V1
        unit_of_measurement: "V"
        device_class: voltage

  - resource: http://<IP-HOMEWIZARD-ENERGY-SOCKET>/api/v1/data
    scan_interval: 1

      - name: "Zendure 2400 AC #3 Vermogen Aansturing API v1"
        value_template: "{{ value_json.active_power_w | float }}"
        unique_id: Zendure_2400_AC_3_Vermogen_Aansturing_API_V1
        unit_of_measurement: "W"
        device_class: power

      - name: "Zendure 2400 AC #3 Voltage Aansturing API v1"
        value_template: "{{ value_json.active_voltage_v | float }}"
        unique_id: Zendure_2400_AC_3_Voltage_Aansturing_API_V1
        unit_of_measurement: "V"
        device_class: voltage

Nog steeds die template helper (sensor.Zendure_2400_AC_1_3_Vermogen_Aansturing_API_V1) nodig, maar wel iets aangepast:

code:

{% set 2400_ac_1_en_2400_ac_2_wattage = states('sensor.Zendure_2400_AC_1_Vermogen_Aansturing_API_V1') | float %}
{% set 2400_ac_3_wattage = states('sensor.Zendure_2400_AC_3_Vermogen_Aansturing_API_V1') | float %}
{{ 2400_ac_1_en_2400_ac_2_wattage + 2400_ac_3_wattage | round(0) }}

Je zou die dubbele config (Zendure_2400_AC_2_Vermogen_Aansturing_API_V1 en Zendure_2400_AC_2_Voltage_Aansturing_API_V1) uit de configuration.yaml kunnen weghalen, maar dan moet je ook de automation templates aanpassen. Zo zou het prima moeten werken met de spullen die je al hebt.

Edit:
Nog een kleine aanpassing nodig: in de Zendure Worker Automation even zoeken op:

zendure_2400_ac_1_vermogen_aansturing_api_v1 en zendure_2400_ac_2_vermogen_aansturing_api_v1, die staan er allebei 2x in i.c.m. een "above: -30" waarde, maak daar bij allebei even "above: -60" van. Die van zendure_2400_ac_3_vermogen_aansturing_api_v1 op "above: -30" laten staan.

[ Voor 5% gewijzigd door wosp op 29-07-2025 17:24 ]

[Taro]

wosp schreef op dinsdag 29 juli 2025 @ 17:16:
[...]


Kan je een situatie creëren waarbij 2 hypers op fase 1 zitten, 2 2400AC's op fase2 en op fase3 een hyper en een 2400AC en die 2400AC die samen met de hyper staat aangesloten op een energy socket? Dan kan je het met je huidige spullen en een beetje creativiteit voor elkaar krijgen:

code:

  - resource: http://<IP-HOMEWIZARD-P1>/api/v1/data
    scan_interval: 1
    sensor:
      - name: "P1 Aansturing API v1"
        value_template: "{{ value_json.active_power_w | float }}"
        unique_id: P1_Aansturing_API_V1
        unit_of_measurement: "W"
        device_class: power

  - resource: http://<IP-HOMEWIZARD-3-FASE-KWHMETER>/api/v1/data
    scan_interval: 1

      - name: "Zendure 2400 AC #1 en AC #2 Vermogen Aansturing API v1"
        value_template: "{{ value_json.active_power_l2_w | float }}"
        unique_id: Zendure_2400_AC_1_Vermogen_Aansturing_API_V1
        unit_of_measurement: "W"
        device_class: power
 
      - name: "Zendure 2400 AC AC #1 en AC #2 Voltage Aansturing API v1"
        value_template: "{{ value_json.active_voltage_l2_v | float }}"
        unique_id: Zendure_2400_AC_1_Voltage_Aansturing_API_V1
        unit_of_measurement: "V"
        device_class: voltage
 
      - name: "Zendure 2400 AC #1 en AC #2 Vermogen Aansturing API v1"
        value_template: "{{ value_json.active_power_l2_w | float }}"
        unique_id: Zendure_2400_AC_2_Vermogen_Aansturing_API_V1
        unit_of_measurement: "W"
        device_class: power
 
      - name: "Zendure 2400 AC #1 en AC #2 Voltage Aansturing API v1"
        value_template: "{{ value_json.active_voltage_l2_v | float }}"
        unique_id: Zendure_2400_AC_2_Voltage_Aansturing_API_V1
        unit_of_measurement: "V"
        device_class: voltage

  - resource: http://<IP-HOMEWIZARD-ENERGY-SOCKET>/api/v1/data
    scan_interval: 1

      - name: "Zendure 2400 AC #3 Vermogen Aansturing API v1"
        value_template: "{{ value_json.active_power_w | float }}"
        unique_id: Zendure_2400_AC_3_Vermogen_Aansturing_API_V1
        unit_of_measurement: "W"
        device_class: power

      - name: "Zendure 2400 AC #3 Voltage Aansturing API v1"
        value_template: "{{ value_json.active_voltage_v | float }}"
        unique_id: Zendure_2400_AC_3_Voltage_Aansturing_API_V1
        unit_of_measurement: "V"
        device_class: voltage

Nog steeds die template helper (sensor.Zendure_2400_AC_1_3_Vermogen_Aansturing_API_V1) nodig, maar wel iets aangepast:

code:

{% set 2400_ac_1_en_2400_ac_2_wattage = states('sensor.Zendure_2400_AC_1_Vermogen_Aansturing_API_V1') | float %}
{% set 2400_ac_3_wattage = states('sensor.Zendure_2400_AC_3_Vermogen_Aansturing_API_V1') | float %}
{{ 2400_ac_1_en_2400_ac_2_wattage + 2400_ac_3_wattage | round(0) }}

Je zou die dubbele config (Zendure_2400_AC_2_Vermogen_Aansturing_API_V1 en Zendure_2400_AC_2_Voltage_Aansturing_API_V1) uit de configuration.yaml kunnen weghalen, maar dan moet je ook de automation templates aanpassen. Zo zou het prima moeten werken met de spullen die je al hebt.

Edit:
Nog een kleine aanpassing nodig: in de Zendure Worker Automation even zoeken op:

zendure_2400_ac_1_vermogen_aansturing_api_v1 en zendure_2400_ac_2_vermogen_aansturing_api_v1, die staan er allebei 2x in i.c.m. een "above: -30" waarde, maak daar bij allebei even "above: -60" van. Die van zendure_2400_ac_3_vermogen_aansturing_api_v1 op "above: -30" laten staan.

Die situatie kan ik creëren, maar daar zit een risico in: Nu is de max 1x1200 + 1x2400 = 3600 Watt per stopcontact/groep/fase. Met 2x 2400AC op hetzelfde stopcontact wordt die max 2x2400=4800 en dat wil ik niet riskeren. Daarnaast zou ik dan de fases scheef gaan belasten, dat is ook niet slim ivm de laadpaal.

[gielz]

Ondanks dat de NOM hier goed draait en hopelijk bij meer Tweakers toch een kleine aanpassing aan de NOM met betrekking tot API berichten richting de batterij. Werkt het prima dan zou ik lekker niets gaan aanpassen.

Update

‪‪2025-07-29 🔴‬ CHANGE - Zendure NOM 1.00 Automatisering afwijking gevonden in de code die controleert of er een nieuwe waarde naar de batterij verzonden moet worden of dat deze gelijk is aan het gewenste vermogen in optie 3 en 5. Geen invloed op bestaande NOM, wel iets minder data naar de batterij wanneer je langdurig NOM draait op vol vermogen.


Hier draait hij alweer 2 maanden vlekkeloos met standaard import van 0,000 - 0,001 KWH van 00:00 t/m 08:00.

[wosp]

Vanavond voor de grap eens zitten testen met de nieuwe integratie van @FireSon met ZenSDK ondersteuning. Daar zit nu ook standaard slimme ontlading en slim opladen in en er is geen extra kWh meter nodig (gebruikt waarschijnlijk de wat onnauwkeurige meters van de batterij zelf?). Verder valt op dat de NOM nu inderdaad door draait als internet wegvalt, maar als je dan een reboot van HA doet heb je wel een probleem, want voor het starten heeft ie blijkbaar wel internet nodig?!? Ook was er in zijn oude integratie een sensor om te zien hoe je verbinding had, die is verdwenen, net zoals een paar anderen (zoals heatstate van elke individuele batterij). Maar verder geen gekke dingen tot nu toe. Ik blijf er nog even op draaien als test, misschien blijf ik er wel op (hij lijkt iets stabielere NOM te hebben, bij mijn zeer wisselvallige stroomverbruik met veel pieken), al zou dat wel een beetje zonde zijn van al m’n werk, haha.

[gielz]

wosp schreef op woensdag 30 juli 2025 @ 01:48:
Vanavond voor de grap eens zitten testen met de nieuwe integratie van @FireSon met ZenSDK ondersteuning. Daar zit nu ook standaard slimme ontlading en slim opladen in en er is geen extra kWh meter nodig (gebruikt waarschijnlijk de wat onnauwkeurige meters van de batterij zelf?). Verder valt op dat de NOM nu inderdaad door draait als internet wegvalt, maar als je dan een reboot van HA doet heb je wel een probleem, want voor het starten heeft ie blijkbaar wel internet nodig?!? Ook was er in zijn oude integratie een sensor om te zien hoe je verbinding had, die is verdwenen, net zoals een paar anderen (zoals heatstate van elke individuele batterij). Maar verder geen gekke dingen tot nu toe. Ik blijf er nog even op draaien als test, misschien blijf ik er wel op (hij lijkt iets stabielere NOM te hebben, bij mijn zeer wisselvallige stroomverbruik met veel pieken), al zou dat wel een beetje zonde zijn van al m’n werk, haha.

Meld de dingen die je ziet ook even op de github van Fireson dan kan dit wellicht verbeterd worden in een toekomstige versie.

Hier met een enkele batterij is de aansturing een stuk eenvoudiger. Vannacht weer 0,001 kwh import en 0,000 kwh export.

[Roedie84]

Ik kan mijn AC2400 niet met een ander account delen, heb het topic doorgelezen maar kan niets vinden hierover. Iemand een idee?

[remcoXP]

Bij de Nieuwe beta kan ook ander mqtt brokers ingesteld worden, binnenkort maar eens testen

[Taro]

Roedie84 schreef op woensdag 30 juli 2025 @ 08:29:
Ik kan mijn AC2400 niet met een ander account delen, heb het topic doorgelezen maar kan niets vinden hierover. Iemand een idee?[Afbeelding]

De nieuwe devices kan je inderdaad niet meer op die manier delen. In HA zal je voor nu met je hoofdaccount moeten inloggen. Wel komt er binnenkort een optie aan om een API KEY te delen = de beste optie.

[Taro]

wosp schreef op woensdag 30 juli 2025 @ 01:48:
Vanavond voor de grap eens zitten testen met de nieuwe integratie van @FireSon met ZenSDK ondersteuning. Daar zit nu ook standaard slimme ontlading en slim opladen in en er is geen extra kWh meter nodig (gebruikt waarschijnlijk de wat onnauwkeurige meters van de batterij zelf?). Verder valt op dat de NOM nu inderdaad door draait als internet wegvalt, maar als je dan een reboot van HA doet heb je wel een probleem, want voor het starten heeft ie blijkbaar wel internet nodig?!? Ook was er in zijn oude integratie een sensor om te zien hoe je verbinding had, die is verdwenen, net zoals een paar anderen (zoals heatstate van elke individuele batterij). Maar verder geen gekke dingen tot nu toe. Ik blijf er nog even op draaien als test, misschien blijf ik er wel op (hij lijkt iets stabielere NOM te hebben, bij mijn zeer wisselvallige stroomverbruik met veel pieken), al zou dat wel een beetje zonde zijn van al m’n werk, haha.

Ik gebruik bij voorkeur ook de Fireson integratie omdat je dan zelf veel minder hoeft te wijzigen en de NOM is gewoon heel erg netjes zonder aanvullende stekkers.

1.1.0 pre 10 bevat inmiddels de volgende wijzigingen, incl. sf800/sf800p/2400 vermelding:

Fix Username/password login + mqtt server
use mDNS for SF-devices, if the IP address is unknown
Discard offline-devices during smart-matching
Setting cloud/Local MQTT connection per device
Setting Legacy device properties
Improved switching of local mqtt
Added initial version of zenSDK connection to SF800/800P and 2400, which only uses zenSDK to communicate (no mqtt)

Hier kriebelt het ook. Fireson zei een paar dagen geleden dat ik beter nog heel even kan wachten met upgraden ivm een aantal openstaande issues, maar dat dan als het goed is zowel de Hypers áls 2400AC's hierdoor tegelijkertijd aangestuurd zouden moeten kunnen worden zonder vast te lopen zoals in het verleden. Mijn ideale situatie

Overigens zou een recente Hyper update ook al verbetering hebben moeten laten zien mbt freezes. Maar aangezien ik nu al 2? maanden geen bevroren Hypers heb gehad ivm local MQTT aansturing kan ik dat niet checken danwel bevestigen.

[Bikkelreal]

Taro schreef op woensdag 30 juli 2025 @ 09:58:
[...]

Ik gebruik bij voorkeur ook de Fireson integratie omdat je dan zelf veel minder hoeft te wijzigen en de NOM is gewoon heel erg netjes zonder aanvullende stekkers.

1.1.0 pre 10 bevat inmiddels de volgende wijzigingen, incl. sf800/sf800p/2400 vermelding:

Fix Username/password login + mqtt server
use mDNS for SF-devices, if the IP address is unknown
Discard offline-devices during smart-matching
Setting cloud/Local MQTT connection per device
Setting Legacy device properties
Improved switching of local mqtt
Added initial version of zenSDK connection to SF800/800P and 2400, which only uses zenSDK to communicate (no mqtt)

Hier kriebelt het ook. Fireson zei een paar dagen geleden dat ik beter nog heel even kan wachten met upgraden ivm een aantal openstaande issues, maar dat dan als het goed is zowel de Hypers áls 2400AC's hierdoor tegelijkertijd aangestuurd zouden moeten kunnen worden zonder vast te lopen zoals in het verleden. Mijn ideale situatie

Overigens zou een recente Hyper update ook al verbetering hebben moeten laten zien mbt freezes. Maar aangezien ik nu al 2? maanden geen bevroren Hypers heb gehad ivm local MQTT aansturing kan ik dat niet checken danwel bevestigen.

Met de integratie 1.1.0-pr8 van FireSon loopt supper die kan je alvast gebruiken. (2X2400AC)
Ik kan nog zelfs in de App mee kijken terwijl HA loopt:)

[DJN]

Bikkelreal schreef op woensdag 30 juli 2025 @ 12:42:
[...]


Met de integratie 1.1.0-pr8 van FireSon loopt supper die kan je alvast gebruiken. (2X2400AC)
Ik kan nog zelfs in de App mee kijken terwijl HA loopt:)

Mooi! Hoe is het algoritme bij meerdere accu’s, wanneer wordt 2e omvormer ingeschakeld bij lage vraag?

[Roedie84]

Ik krijg middels de @FireSon integratie een rare temperatuur waarde te zien, namelijk rond de 3000. Hoe kan ik de daadwerkelijk temperatuur zien, is er een te hanteren factor? Gaat om een AC2400.

[klump4u]

Roedie84 schreef op woensdag 30 juli 2025 @ 15:50:
Ik krijg middels de @FireSon integratie een rare temperatuur waarde te zien, namelijk rond de 3000. Hoe kan ik de daadwerkelijk temperatuur zien, is er een te hanteren factor? Gaat om een AC2400.

Dat viel mij ook op toen ik dit draaide, ook een 2400AC.
Nu draai ik NOM 1.0

[Bikkelreal]

DJN schreef op woensdag 30 juli 2025 @ 15:46:
[...]


Mooi! Hoe is het algoritme bij meerdere accu’s, wanneer wordt 2e omvormer ingeschakeld bij lage vraag?

Ja gister nacht stonden beide op 39W te ontladen

[Taro]

Roedie84 schreef op woensdag 30 juli 2025 @ 15:50:
Ik krijg middels de @FireSon integratie een rare temperatuur waarde te zien, namelijk rond de 3000. Hoe kan ik de daadwerkelijk temperatuur zien, is er een te hanteren factor? Gaat om een AC2400.

Ja, is de waarde in Kelvin en delen door 10. Dus bijv. minus 2731 en daarna delen / 10.0 of delen door 10 en minus 273.1.

[Taro]

Bikkelreal schreef op woensdag 30 juli 2025 @ 12:42:
[...]


Met de integratie 1.1.0-pr8 van FireSon loopt supper die kan je alvast gebruiken. (2X2400AC)
Ik kan nog zelfs in de App mee kijken terwijl HA loopt:)

Ik kan niet wachten, maar gaat mij er om dat de 3xHypers nu zo blijven draaien als ze al doen en de 3x2400AC daarin netjes hetzelfde mee gaan draaien. Ik wil de bestaande situatie niet opofferen voor een slechtere situatie, dus ik wacht totdat de schoonheidsfoutjes er uit zijn.

[gielz]

Bikkelreal schreef op woensdag 30 juli 2025 @ 17:03:
[...]


Ja gister nacht stonden beide op 39W te ontladen

Maar je zou dan toch verwachten dat 1 al het vermogen pakt en de andere in standby draait voor een optimaal rendement? Of is dit iets wat nog komt?

[mrme12345]

gielz schreef op woensdag 30 juli 2025 @ 19:07:
[...]


Maar je zou dan toch verwachten dat 1 al het vermogen pakt en de andere in standby draait voor een optimaal rendement? Of is dit iets wat nog komt?

Dat zou inderdaad wel nodig zijn wil het efficient plaatsvinden. In mijn flows regel ik als ik meerdere devices aanstuur dat tot 1200w (de max output van de hyper, waar ik de meeste pv op aan het gesloten) alleen de hyper gebruikt wordt en alleen daarboven (bijvoorbeeld quooker en koken enz) de andere devices bijspringen. Scheelt ook hoop geschakel enz.

[Bikkelreal]

gielz schreef op woensdag 30 juli 2025 @ 19:07:
[...]


Maar je zou dan toch verwachten dat 1 al het vermogen pakt en de andere in standby draait voor een optimaal rendement? Of is dit iets wat nog komt?

Weet ik niet, misschien bij een nog lager verbruik doet hij dat.

[c0mplex1]

Taro schreef op woensdag 30 juli 2025 @ 17:30:
[...]

Ja, is de waarde in Fahrenheit en delen door 10. Dus bijv. minus 2731 en daarna delen / 10.0 of delen door 10 en minus 273.1.

Is geen Fahrenheit, maar Kelvin

[Taro]

c0mplex1 schreef op woensdag 30 juli 2025 @ 19:15:
[...]

Is geen Fahrenheit, maar Kelvin

Ah jah, ben alweer wat jaartjes van school af

[gielz]

Bikkelreal schreef op woensdag 30 juli 2025 @ 19:11:
[...]


Weet ik niet, misschien bij een nog lager verbruik doet hij dat.

Onder de 150 watt per omvormer is wel echt het minimale waarbij de RTE nog leuk blijft. Wellicht iets om op de github te plaatsen? Bij Homewizard gaat altijd eerst 1 omvormer tot 400 watt voordat splitsing gaat plaatsvinden.

[Bikkelreal]

gielz schreef op woensdag 30 juli 2025 @ 19:17:
[...]


Onder de 150 watt per omvormer is wel echt het minimale waarbij de RTE nog leuk blijft. Wellicht iets om op de github te plaatsen? Bij Homewizard gaat altijd eerst 1 omvormer tot 400 watt voordat splitsing gaat plaatsvinden.

Heb net gekeken in de history (HA) eerste 2400AC stond met 50W te ontladen en de ander met 36W de hele nacht.

[wosp]

Heel de dag op de nieuwe FireSon integratie gedraaid, inmiddels pre12, meerdere updates geweest vandaag. Draait prima tot zover. Die sensors waar ik het vannacht over had kloppen niet, die zijn er wel gewoon maar ik keek niet goed (zal vast door het tijdstip gekomen zijn). Probleem met het nodig hebben van een internet verbinding bij boot is er nog wel met de nieuwste release, die heb ik even aangemeld: https://github.com/FireSon/Zendure-HA/issues/506

Ook gelijk een feature request gedaan voor de mogelijkheid om een unit te gebruiken bij lager verbruik, dat lijkt mij ook wel mooi. Evenals een verzoek om de smartmode optie te kunnen beschrijven (opslaan in ram/flash), nu kan je die alleen lezen.

Voor de rest geen gekke dingen tegengekomen tot nu toe. :-)

[Mediacj]

De zenSDK staat nu ook op de Github pagina van Zendure, misschien leuk voor de topicstart:
https://github.com/Zendure/zenSDK

Ook wel interessant de melding "(More coming soon)" in de tabel waar de compatible devices staan. Wie weet gaan ze de Hypers alsnog toevoegen alhoewel dat door beperkte hardware niet mogelijk leek.

[ Voor 44% gewijzigd door Mediacj op 31-07-2025 10:19 ]

[xenobia12345]

Dag allemaal, korte intro:
Ik ben sinds vorige week in bezit van een tweetal 2400AC's. Ik heb daarvoor 3 aparte groepen aangelegd in de meterkast, waarbij elke groep op een andere fase zit. (Mogelijk dat er in de nabije toekomst nog een 3e 2400AC bijkomt, dan kan ik op alle fases werken.)

Inmiddels met behulp van Home Assistant en de config + automation van Gielz de boel draaiend. Wel heb ik een andere P1 meter in mijn setup, de ongetwijfeld bekende "Slimmelezer" van Marcel Zuidwijk. Ook heb ik op elke Zendure een Shelly Plug S Gen3 zitten. Dus op enkele punten wijk ik af van de hardware welke Gielz heeft opgenomen in zijn beschrijving.

Mijn vraag:

Ik heb, omdat ik twee batterijen gebruik, ook dubbele automations in HA aangemaakt. Ik heb echter de indruk dat ze elkaar soms een beetje tegenwerken. Omdat ze niet van elkaars bestaan "weten", proberen ze beide NOM te bereiken op eigen kracht lijkt het. Zie screenshot voor het gevolg.



De licht golvende beweging over de nul-lijn is als ie rustig loopt, is al best aardig, maar zit eigenlijk meer onder de nul, dan erboven.

De grotere uitschieters zijn vooral het probleem, ze lossen zich wel steeds op, maar komen af en toe ook weer terug. Ik heb al geprobeerd te spelen met de factor en de correctie in de automations. Ook heb ik in de automations de polling-interval ten opzichte van elkaar aangepast, zodat ze niet tegelijk gaan corrigeren.

Zijn er ideeën hoe dit golven met deze twee batterijen onder controle te krijgen?

[wosp]

Je probleem zal in de factor zitten. Bij 100% aanbod/vraag zal bij 2 units de factor op 0.50 moeten staan, bij 75% vraag op 0.375 enz. Daarbij moet je ook rekening houden met als 1 unit vol of leeg is, want dan moet de factor veranderen van de andere unit naar 1.00 en zodra die wel weer mee kan doen, moet die weer terug naar 0.50 (bij 100% vraag/aanbod). Tot slot zou je ook nog rekening willen houden met de SoC van elke unit om ze gelijkwaardig te laten laden en ontladen, dan moet je dus de factor dynamisch berekenen adhv de soc. In mijn variant van de integratie van @gielz zitten de templates daarvoor inbegrepen. Maar ik zou eerlijk gezegd bij meerdere units gewoon de nieuwe pre12 versie van de FireSon integratie gebruiken. Is ook zenSDK (dus lokale communicatie), maar dan hoef je zelf veel minder in te stellen en rekening mee te houden. Bij mij houdt de FireSon integratie ook nog eens beter de 0 bij NOM.

[gielz]

xenobia12345 schreef op donderdag 31 juli 2025 @ 18:41:
Dag allemaal, korte intro:
Ik ben sinds vorige week in bezit van een tweetal 2400AC's. Ik heb daarvoor 3 aparte groepen aangelegd in de meterkast, waarbij elke groep op een andere fase zit. (Mogelijk dat er in de nabije toekomst nog een 3e 2400AC bijkomt, dan kan ik op alle fases werken.)

Inmiddels met behulp van Home Assistant en de config + automation van Gielz de boel draaiend. Wel heb ik een andere P1 meter in mijn setup, de ongetwijfeld bekende "Slimmelezer" van Marcel Zuidwijk. Ook heb ik op elke Zendure een Shelly Plug S Gen3 zitten. Dus op enkele punten wijk ik af van de hardware welke Gielz heeft opgenomen in zijn beschrijving.

Mijn vraag:

Ik heb, omdat ik twee batterijen gebruik, ook dubbele automations in HA aangemaakt. Ik heb echter de indruk dat ze elkaar soms een beetje tegenwerken. Omdat ze niet van elkaars bestaan "weten", proberen ze beide NOM te bereiken op eigen kracht lijkt het. Zie screenshot voor het gevolg.

[Afbeelding]

De licht golvende beweging over de nul-lijn is als ie rustig loopt, is al best aardig, maar zit eigenlijk meer onder de nul, dan erboven.

De grotere uitschieters zijn vooral het probleem, ze lossen zich wel steeds op, maar komen af en toe ook weer terug. Ik heb al geprobeerd te spelen met de factor en de correctie in de automations. Ook heb ik in de automations de polling-interval ten opzichte van elkaar aangepast, zodat ze niet tegelijk gaan corrigeren.

Zijn er ideeën hoe dit golven met deze twee batterijen onder controle te krijgen?

Je zou ze in één automatisering moeten gieten die niet al te lang word. Met 2 of meer batterijen raad ik aan om de Fireson te proberen of NOM van Zendure zelf. Bij Fireson loop je nu dan nog wel tegen het probleem aan dat deze factor 0.5 gaat doen. Bij een laag vermogen is dat funest voor je RTE.

[wosp]

Om met 1 omvormer te ontladen bij lagere vermogens is in pre13 release toegevoegd, die is zojuist gereleased. Herstart van HA terwijl er geen internet is en dat dan de batterijen niks gaan doen zou ook opgelost moeten zijn (zal ik morgen even testen). Pre13 zojuist alvast geïnstalleerd en inderdaad staat er nu maar 1 omvormer te leveren op zo’n 500 Watt continue. Ziet er goed uit, zal positief zijn voor de RTE. Even afwachten hoe dat in de praktijk gaat zijn. Overigens hoef je bij de FireSon ZenSDK integratie geen rekening te houden met wegschrijven in RAM ipv Flash, dat doet ‘ie schijnbaar bij elke actie al zelf.

[ Voor 13% gewijzigd door wosp op 01-08-2025 00:25 ]

[Bikkelreal]

wosp schreef op vrijdag 1 augustus 2025 @ 00:23:
Om met 1 omvormer te ontladen bij lagere vermogens is in pre13 release toegevoegd, die is zojuist gereleased. Herstart van HA terwijl er geen internet is en dat dan de batterijen niks gaan doen zou ook opgelost moeten zijn (zal ik morgen even testen). Pre13 zojuist alvast geïnstalleerd en inderdaad staat er nu maar 1 omvormer te leveren op zo’n 500 Watt continue. Ziet er goed uit, zal positief zijn voor de RTE. Even afwachten hoe dat in de praktijk gaat zijn. Overigens hoef je bij de FireSon ZenSDK integratie geen rekening te houden met wegschrijven in RAM ipv Flash, dat doet ‘ie schijnbaar bij elke actie al zelf.

Net ook geinstalleert, met RAM had ik al gecheckt, weet nog niet wanneer met hoeveel "W" hij ook de andere unit zal gaan aansturen zodat ze beide werken.

[jordyc]

Hoe stabiel zijn de testversies van Fireson op dit moment? Volgens mij zit er weer een aantal hele mooie QoL improvements in en wil em graag eens gaan testen mits het stabiel draait.

[Taro]

De nieuwe versie van de Zendure App is beschikbaar en daarmee kan je ook de API-key ophalen. Vanaf nu dus mogelijk om de Fireson HA integratie ook via de API-key ipv je Zendure login te gebruiken.

Ik wil het echt heel graag testen, maar ik twijfel nog. Aan de andere kant: Kan ook zo terug naar de huidige versie toch?

[xenobia12345]

Taro schreef op vrijdag 1 augustus 2025 @ 10:23:
De nieuwe versie van de Zendure App is beschikbaar en daarmee kan je ook de API-key ophalen. Vanaf nu dus mogelijk om de Fireson HA integratie ook via de API-key ipv je Zendure login te gebruiken.

Ik wil het echt heel graag testen, maar ik twijfel nog. Aan de andere kant: Kan ook zo terug naar de huidige versie toch?

Een snelle test met de API (Authorisation Cloud Key) lijkt prima te werken icm de Fireson Zendure integratie met Home Assistant. Commando's komen door.

[Taro]

Kon niet wachten, na nog wat afstemming met Fireson ivm mijn situatie en icm de nieuwe Zendure App de stap gewaagd....

Liep natuurlijk tijdens de installatie weer direct tegen wat zaken aan, zoals de ACE1500 van mijn pa die ook in mijn 3e account zit, dus die heeft maar even pech en knikker ik er uit

Nu draait de 2400AC met de laagste SOC in zijn eentje om de zonne-opwek op te slurpen, dat werkt volgens mij zoals verwacht, met mooie 0 op de meter:


Ook heel benieuwd hoe dit samenwerkt met de SF800's die ook netjes worden herkend en ook via ZenSDK in te stellen zijn.

Nu dus de 3 Hypers uit het ene Zendure account verwijderen (Vandaar de missende entiteit foutmeldingen), toevoegen aan mijn 3e account. Dashboards opschonen, etc. Al besloten niet meer terug te gaan, maar vooruit te gaan en indien nodig weer te helpen met debuggen

Heel erg bedankt voor al je werk hier aan @FireSon

[Taro]

Kreeg na het toevoegen van de 3 Hypers aan hetzelfde account een foutmelding in HA. Fireson heeft even via Teams meegekeken. Inmiddels alle andere lokale REST API aansturingen uitgezet en alle devices via de Fireson integratie lopen.

Enige waar ik nog wel mijn twijfels over heb: Persoonlijk zie ik liever een verdeling van de load over alle devices op basis van SoC, opslag en vermogen zoals het was. Nu wordt de load gewisseld en pakt 1 device de max load, is er dan nog iets over wordt het 2e device bijgeschakeld. Dat is heel mooi voor de RTE, maar creëert ook een aantal nadelen:

• De load per fase kan heel erg wisselen, je krijgt fase onbalans
• De loadbalancer van een laadpaal zal eerder ingrijpen, dus gaat een EV langzamer laden
• De nul van de fases verschuift, dat kan problemen opleveren met 3-fase systemen
• Als er nu voor wordt gekozen alleen op een andere fase te laden klappen mijn zonnepanelen er weer uit zoals zojuist voor het eerst in maanden weer gebeurde

Persoonlijk zou ik wat efficiency / extra standby verliezen willen inleveren voor het gewoon verdelen van de load over alle devices ipv het maximale vermogen van 1 device te benutten en dat te rouleren zoals nu het geval is. Maar dit zal per situatie en huishouden verschillen.

Mijn voorkeur: Netjes uitsmeren Zou mooi zijn als ieder voor zich die keuze via een instelling kan maken, want ik begrijp de wens om dat anders te doen ook zeker.

Constatering: De export van de 4x SF800's wordt regelmatig op 0 gezet. Even kijken of ik dat kan voorkomen. In het ergste geval maak ik daar een controle op.

Edit: Nu gaat op Fase 1 dus alle zonnestroom naar het net en wordt op Fase 3 een 2400AC geladen op een andere fase. De Hyper én 2400AC op Fase 1 doen nu niets, terwijl die eigenlijk mee zouden moeten laden wat dus hiervoor met die andere verdeling wel zo was.

[ Voor 8% gewijzigd door Taro op 01-08-2025 14:07 ]

[Taro]

Voorbeeldje van het effect van deze keuze in mijn situatie. Op Fase 1 wordt maximaal teruggeleverd, die Hyper en 2400 AC doen helemaal niets. En op Fase B en Fase C worden 2x 2400AC en 1x Hyper geladen. Die onbalans in de fases is niet wenselijk:




@FireSon Kan je hier iets mee? Een toggle in de Zendure Manager om bijv. te kiezen tussen:

1. Powerdistributie verdelen op basis van vermogen, SoC en opslagcapaciteit
2. Powerdistributie optimaliseren op basis van standby verbruik en zo min mogelijk apparaten gebruiken

[ Voor 17% gewijzigd door Taro op 01-08-2025 14:13 ]

[pulsarz]

Zal idd afhangen van huishouden. Ik met 2 hypers heb net liever het watervalsysteem wat er nu in zit.

Trouwens de fireson integratie staat nu ook op de officiele zendure github zie ik!
https://github.com/Zendure/Zendure-HA

[Taro]

pulsarz schreef op vrijdag 1 augustus 2025 @ 15:38:
Zal idd afhangen van huishouden. Ik met 2 hypers heb net liever het watervalsysteem wat er nu in zit.

Ja, denk dat het met 2x800 of 2x1200 Watt vermogen anders is dan met 11.000 Watt zoals ik hier nu heb. Daar wil je niet teveel mee pingpongen.

En op het geheel is bijv. 20 Watt extra standby verbruik bij mij peanuts, terwijl het op 2 omvormers voor NOM wel weer veel doet.

Maar goed, besloten de 3 Hypers en 9x AB2000S te gaan verkopen, het begint hier uit de klauwen te lopen, kabelmanagement is niet mogelijk, etc.

[Taro]

@FireSon Ik zie hier nog 2 vreemde dingen:

1: Er blijft 400-500 Watt over en de 2400AC schaalt niet terug, die inmiddels een veel hogere SoC heeft dan alle andere devices:


2: De Hyper met hoogste SoC begint nu ineens ook te laden (#3), terwijl ik zou verwachten dat de Hyper met laagste SoC (#2) zou gaan laden?