Zendure producten in Home Assistant integreren deel 2

[GHorsie]

ctrl-tab schreef op donderdag 21 mei 2026 @ 22:54:
[...]


Gratis bestaat niet. In plaats van terugleveren vang je de stroom nu op (import). Je kiest ervoor om niet voor 13 cent terug te leveren maar om die goedkope stroom op te slaan. Dus die kilowat kost je 13 cent op dat moment.
Daarna compenseer je je verbruik met de batterij tegen 30 cent per kilowat. Dus dat is in feite winst.

Als je een dynamisch contract hebt is dit op dit moment ongeveer 1-op-1.
Straks ligt het anders.

Nu wi ik die integratie ook gebruiken en heb ik dus die "aansturing" sensor ingesteld en een waarde die ik voor een kWh moet betalen. Maar als ik jouw opmerking goed begrijp zou ik niet het bedrag moeten invullen wat ik betaal voor een kWh maar een verschil?

Ik lever niet meer terug dan dat ik gebruik per jaar dus is het wat lastiger voor mij te begrijpen

Wat zou ik in moeten stellen bij de kosten?

[Aardedraadje]

ppaulv schreef op zaterdag 23 mei 2026 @ 12:31:
[...]

Ehhh ... dan wellicht even voor de heel erg blonde mensen hier (ikzelf iig, blijkbaar heb ik ergens iets gemist) : als ik nu al een dynamisch contract zou hebben (heb ik niet) is toch nu ook al
de inkoopprijs = marktprijs + belasting + leveranciersvergoeding (dit betaal je)
en verkoopprijs = - marktprijs + belasting + leveranciersvergoeding (dit krijg je)?
Dus belasting en leveranciersvergoeding betaal je altijd, alleen de marktprijs krijg je of betaal je.
Wat heb ik hier verkeerd begrepen ?

Door salderen krijg je nu energiebelasting nog terug. Straks niet meer.

[ppaulv]

Aardedraadje schreef op zaterdag 23 mei 2026 @ 12:59:
[...]

Door salderen krijg je nu energiebelasting nog terug. Straks niet meer.

aha, dat is het gat in m'n redenering. Dank hiervoor!
Als ik dan uitga van de Nordpool prijzen die ik via Gielz beschikbaar heb, wat zit daar dan wel / niet al in verwerkt? Ik kan wel gaan reverse-engineren op basis van jouw plaatjes (of andere plaatjes) maar dat blijft een gok. Ik vermoed dat het de kale marktprijs is, maar wat zie ik dan in die grafiek? Zijn de zaken als BTW en belasting en vergoeding (die ik ergens anders, weet zogauw niet meer waar) heb ingevuld daar dan in verwerkt?

[jannus66]

Waar staat ’deploy’ voor?

Wat moet ik dan doen?

[koboy]

ppaulv schreef op zaterdag 23 mei 2026 @ 12:31:
[...]

Ehhh ... dan wellicht even voor de heel erg blonde mensen hier (ikzelf iig, blijkbaar heb ik ergens iets gemist) : als ik nu al een dynamisch contract zou hebben (heb ik niet) is toch nu ook al
de inkoopprijs = marktprijs + belasting + leveranciersvergoeding (dit betaal je)
en verkoopprijs = - marktprijs + belasting + leveranciersvergoeding (dit krijg je)?
Dus belasting en leveranciersvergoeding betaal je altijd, alleen de marktprijs krijg je of betaal je.
Wat heb ik hier verkeerd begrepen ?

Dat het bij dynamische leveranciers met zo'n bende aan het worden is als bij vast/variabel.

Bij correct toepassen van het salderen moet namelijk ook de leveranciers vergoeding worden terugbetaald, maar niet alle leveranciers doen dat. Buiten het te salderen deel is er volgens mij nog maar 1 leverancier die ook dan de vergoeding uitbetaald. Zie hiervoor het dynamische tarieven topic.

[ Voor 3% gewijzigd door koboy op 23-05-2026 14:14 ]

[ctrl-tab]

GHorsie schreef op zaterdag 23 mei 2026 @ 12:45:
[...]

Nu wi ik die integratie ook gebruiken en heb ik dus die "aansturing" sensor ingesteld en een waarde die ik voor een kWh moet betalen. Maar als ik jouw opmerking goed begrijp zou ik niet het bedrag moeten invullen wat ik betaal voor een kWh maar een verschil?

Ik lever niet meer terug dan dat ik gebruik per jaar dus is het wat lastiger voor mij te begrijpen

Wat zou ik in moeten stellen bij de kosten?

Je moet een sensor ingeven doe representatief is voor jouw prijs. Dat hangt van aanbieder en type contract af (dynamisch of vast).

Bij zonneplan heb ik 1 kostensensor.. Dat klopt niet 100% want als ik de batterij na zonsondergang leeg krijg ik geen zonnebonus. Maar dat loopt wel los verder qua afwijking.

[gast777]

jannus66 schreef op zaterdag 23 mei 2026 @ 13:56:
Waar staat ’deploy’ voor?

Wat moet ik dan doen?

Dat is op de grote rode 'Deploy' knop drukken, rechtsboven.

[jannus66]

gast777 schreef op zaterdag 23 mei 2026 @ 14:42:
[...]

Dat is op de grote rode 'Deploy' knop drukken, rechtsboven.

Dank.

[TBird484]

gast777 schreef op zaterdag 23 mei 2026 @ 10:45:
[...]

Goede vraag. Dit is inderdaad nog even een dingetje, vanwege hoe het Dashboard 2 werkt.

Dit zijn de stappen bij upgraden om dit 100% goed te krijgen:

Top, Dashboard 2 werkt nu weer

Nog even een andere vraag, binnen Gielz staat automatic SOC Protection enabled. Als het percentage dan onder de ingestelde ondergrens komt, dan komt vanuit Gielz het commando laden met 1200W. Volgens mij heeft de proxy geen inzicht in het doel en behandeld dit als een standaard laadcommando. Ik had dus twee setje die onder de minimale SOC zaten en de proxy maakte daar dus 2 x 600W van. Wat je denk ik eigenlijk zou willen is dat beide setjes met 1200W geladen zouden worden. Klopt mijn aanname ?

[gast777]

TBird484 schreef op zaterdag 23 mei 2026 @ 17:00:
[...]

Top, Dashboard 2 werkt nu weer

Nog even een andere vraag, binnen Gielz staat automatic SOC Protection enabled. Als het percentage dan onder de ingestelde ondergrens komt, dan komt vanuit Gielz het commando laden met 1200W. Volgens mij heeft de proxy geen inzicht in het doel en behandeld dit als een standaard laadcommando. Ik had dus twee setje die onder de minimale SOC zaten en de proxy maakte daar dus 2 x 600W van. Wat je denk ik eigenlijk zou willen is dat beide setjes met 1200W geladen zouden worden. Klopt mijn aanname ?

Klopt, de proxy geeft gewoon de opdrachten van Gielz door aan de Zendures. De Proxy geeft als laadpercentage van de 'virtuele Zendure' het gemiddelde van de Laadpercentages van de twee Zendures door. Als dat onder het minimum ingestelde komt (bijv 10%), dan zal Gielz de laadopdracht geven Laden met 1200 W. Als 1 Zendure onder het minimum is zal die de 1200 W toebedeeld krijgen. Als beide eronder zitten, wordt het verdeeld.

Maakt het vermogen uit voor de SoC protectie? Als hij maar weer een beetje oplaadt tot het minimum is alles wat nodig is, zou ik denken. Misschien mis ik iets?

In ieder geval zal de proxy nooit als Gielz zegt "1200W laden", voor 2400W laden in totaal aan opdracht geven.

[TBird484]

gast777 schreef op zaterdag 23 mei 2026 @ 17:09:
[...]

Maakt het vermogen uit voor de SoC protectie? Als hij maar weer een beetje oplaadt tot het minimum is alles wat nodig is, zou ik denken. Misschien mis ik iets?

Geen idee, dat moeten we aan @gielz vragen waarom hij 1200W heeft ingesteld en of dat belangrijk is.

[specialkdk]

Misschien is het antwoord al gegeven, maar ik raak er met de zoekfunctie niet uit. Ik heb sinds kort een 2400AC+ batterij en ik stuur die aan via Home Assistant, met de Zendure integration (dus via API) voor de communicatie, en Battery SmartFlow AI voor de sturing. Dat werkt, maar eigenlijk hoop ik dat het nog ietsje sneller kan door die API er tussenuit te halen. Belangrijk om weten: mijn HA draait niet lokaal maar in een datacenter; ik heb een VPN tunnel naar dat netwerk zodat ik HA rechtstreeks kan bereiken (via het private IP dat die in het datacenter heeft) maar tenzij ik port forwards instel kan HA niet rechtstreeks aan devices in mijn netwerk. Voor MQTT maakt dat niet uit; als MQTT broker gebruik ik Mosquitto op HA. Maar de SDK gebruiken is dus niet handig want HA kan in principe niet aan de batterij.

Mijn batterij verbindt met de MQTT broker en ik heb de relevante entities gedefinieerd; dat werkt allemaal prima. Maar: als ik bv via MQTT de OutputLimit aanpas, wordt die enkele seconden later door de batterij overschreven ipv dat de batterij die parameter aanpakt. Ik veronderstel dat de batterij conflicterende informatie via de cloud binnenkrijgt, maar ik heb de communicatie richting cloud al eens volledig geblokkeerd en dan nog blijf ik dat probleem hebben. HEMS integratie staat uiteraard al uit. Ik heb ook ergens de suggestie gezien om mqtteu.zen-iot.com op DNS niveau om te leiden naar mijn eigen MQTT server zodat de batterij DENKT dat ze met de cloud verbonden is, maar dat werkt niet want de batterij lust mijn self-signed certificaat niet.

In de Zendure integratie in HA kan je wisselen tussen Connection mode Cloud of ZenSDK, maar dat maakt geen verschil. Dus: kan iemand mij zeggen wat ik waar moet uitzetten zodat de batterij ENKEL nog luistert naar mijn MQTT commando's?

[gielz]

TBird484 schreef op zaterdag 23 mei 2026 @ 17:26:
[...]

Geen idee, dat moeten we aan @gielz vragen waarom hij 1200W heeft ingesteld en of dat belangrijk is.

Het vermogen 1200 is er alleen maar om ervoor te zorgen dat je niet onnodig veel gaat bijladen. Nu zal dit wel iets efficiënter zijn op 1200 watt dan 2x 600 watt of 3x 400 watt maar dit is verwaarloosbaar.

[Mscroos]

Ik heb weer gehad dat ik een tijdje geen aansturing heb gehad van @gielz via @gast777 proxy. Begrijp niet wat er gebeurd. Vanavond overigens de laatste versie van de proxy geïnstalleerd (draaide tot vanavond op 20260509). Wellicht gevraagd die zich anders...

Wat ik zag was een drop afgelopen nacht naar 0 export van de zendure. Dit is in het eerste snapshot te zien. Het grijze stuk in de grafiek geeft aan dat er wel data binnenkomt van het verbruik.




Ook direct naar de data van de P1 en de netwerk verbinding gekeken. P1 data komt gewoon binnen. en de netwerk kwaliteit is goed of excellent. Tussen ongeveer 2.30 en 3.10 kan je zien dat er wel P1 data is maar dat de accu op 0 blijft staan...




In de logs gezocht naar wat er gebeurd kan zijn.. de discharging is naar 0 gezet door Gielz om 2.26




En daarna pas weer aan om 3.07... ervoor nog een melding van standby dus de automatisering liep wel neem ik aan...



Iemand een idee???

[ Voor 3% gewijzigd door Mscroos op 23-05-2026 23:16 ]

[gast777]

Vreemd. Hoe staat je "Ontladen Starten Bij" / "Start Discharge At" waarde?

[Mscroos]

gast777 schreef op zondag 24 mei 2026 @ 07:36:
Vreemd. Hoe staat je "Ontladen Starten Bij" / "Start Discharge At" waarde?

@gielz die staat op -500, na je vraag ben ik verder gaan inzoomen op het moment dat dit begint om te begrijpen wat het gedrag is.

Hij staat bij het begin moment netjes NoM te draaien, krijgt een piek in verbruik. Tijdens het opschakelen valt de piek weg, Gaat weer naar mijn nacht verbruik van 450 watt, en schakelt nooit meer aan omdat deze onder de 500 zit.

De geleerde les is dat ik mijn discharge moet instellen onder het basis nacht verbruik.

Wat ik wel interessant vind is dat ik dit nog niet eerder heb meegemaakt, waarom schakelt hij midden in de piek eerst naar 0 en daarna gaat hij weer omhoog schakelen, piek is weg en dan weer naar 0. Andere pieken die ik heb gehad schakelen eigenlijk altijd meer op en neer zonder naar 0 te gaan.




Een piek met “normaal” gedrag deze schakelt niet eerst naar 0

[pasmanm]

Venimk1 schreef op dinsdag 19 mei 2026 @ 19:26:
[...]

Mijn batterij blijft gewoon op standby staan ????

Dit script is puur bedoeld om de maximale laadstroom te beperken.

De laadmodus moet je zelf instellen als 'nul op de meter'.

​P.S. ik heb weer wat wijzigingen, een update van dit script volgt binnenkort.

[gast777]

Mscroos schreef op zondag 24 mei 2026 @ 08:42:
[...]

De geleerde les is dat ik mijn discharge moet instellen onder het basis nacht verbruik.

Wat ik wel interessant vind is dat ik dit nog niet eerder heb meegemaakt, waarom schakelt hij midden in de piek eerst naar 0 en daarna gaat hij weer omhoog schakelen, piek is weg en dan weer naar 0. Andere pieken die ik heb gehad schakelen eigenlijk altijd meer op en neer zonder naar 0 te gaan.

Mooi dat dat inderdaad de oorzaak was. Het begon met een hoge piek in verbruik. Dan gaat de Zendure deze compenseren door veel meer te leveren. Toen de piek in vraag plotseling ophield, had het een beetje tijd nodig voor de Zendure om weer omlaag te gaan met het vermogen. Tijdens zo'n verandering kan het berekende gevraagde vermogen wel eens een beetje onnauwkeurig worden en richting nul gaan. En daarna bleef het gevraagde vermogen dus onder het minimum waarop je startte te leveren.

Oplossing is dus simpel, zoals je al door had: zet het "Ontladen Starten Bij" / "Start Discharge At" op een waarde die lager is dan je nachtverbruik. Anders heb je de kans dat als hij even stopt, dat hij niet meer start.

[Korvaag]

Korvaag schreef op dinsdag 19 mei 2026 @ 07:48:
@gielz Ik zie nog wel wat raars gebeuren. Misschien dat jij tips hebt. Ik ben zelf (nog) niet ervaren genoeg om dit te debuggen.

Even een korte schets:
- Ik heb twee merken accu's: Ecoflow en Zendure, beide units 4kWh
- Ecoflow doet NOM en Zendure dynamisch handelen

Wat ik nu zie is het volgende. Ik heb duurst / goedkoopste uren allebei op 4 uur ingesteld (heb een SF800 Pro dus die kan maar met 800W ontladen en 1000W laden wat dus grofweg 4 uur laden en ontladen is).

De grafiek geeft netjes weer dat bv vandaag duurste uren zijn om 6:00 en dan vanmiddag om 19:00 - 21:00. Lijkt prima te kloppen met ook andere apps/sensors zoals de app EnergyPricing of m'n Budget Energie app

Echter als ik dan kijk hoe laat de accu vanochtend is gaan ontladen: van 4:00 - 5:00. Dat is twee uur te vroeg. Het viel me gisteren ook al op met laden maar dat heb ik even genegeerd omdat ik dacht dat alle sensoren/grafieken nog moesten 'settelen' (lees: volledige sets aan waardes hebben voor 24 uur).

Ik heb uiteraard wel een vermoeden wat er mis gaat:
- Er gaat iets mis met timezones?
- Er gaat iets mis in de originele Nordpool sensor met omrekenen (maar waarom geeft de grafiek het dan wel goed weer)

M'n Home Assistant staat netjes op Amsterdam GMT+1. Language staat wel op Engels. Ik zie dit gedrag niet met andere automations. Ik heb bv ook AIO energy management en die schakelt wel op de juiste tijden.

Jij slimme tips?

edit:
iemand anders gevonden in het topic die het ook heeft maar zonder oplossing. Ik heb een clock toegevoegd aan een dashboard en deze staat netjes op 10:01 AM momenteel (ook moment van deze eerste edit). Timezone in settings staat goed, timezone in user staat goed en timezone in docker stack staat goed. Allemaal Europe/Amsterdam enzo.
Ook een testje gedaan met een template sensor met daarin {{ now() }} en dit geeft ook een voor mijn gevoel correcte waarde: 2026-05-20 12:15:00.333648+02:00 (en ik tik dit dus om 12:15).

Omdat ik mijn originele post niet meer mag editten even zo:

De oplossing van iemand anders in dit Topic heeft bij mij ook gewerkt: helaas niet gewerkt
- Backup maken
- Docker container weggooien en volume ook weggooien
- Home Assistant opnieuw deployen
- Bij eerste benadering van de nieuwe install een backup terugzetten.

Raadselachtig, maar het lijkt te werken. Ik weet 90% zeker dat het probleem nu weg is maar ik moet het volgende schakelmoment nog even afwachten om het voor de volle 100% te weten.

edit:
Helaas. Nog niet gerepareerd. De accu stopte net met laden ondanks dat volgens de grafiek de goedkoopste uren nog bezig waren. Wederom 2 uur te vroeg schakelend. Ik heb geen idee meer wat dit kan zijn.

Gefixed volgens mij. @ctrl-tab Mijn issue zat volgens mij in jouw template (niet lullig bedoeld). Jouw sensor berekent de raw_today en raw_tomorrow niet correct qua timezone. Ik heb jouw code deels aangepast:

YAML:

          raw_today: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[], starts=[], ends=[]) %}
            {% if today_price is mapping %}
              {% for state in today_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 1 %}
                  {# MODIFIED: Converts UTC string to a local string format #}
                  {% set local_start = (state.start | as_datetime | as_local).isoformat() %}
                  {% set data.starts = data.starts + [local_start] %}
                {% endif %}
                {% if data.group | count == 4 %}
                  {# MODIFIED: Converts end UTC string to local string format #}
                  {% set local_end = (state.end | as_datetime | as_local).isoformat() %}
                  {% set data.prices = data.prices + [{'start': data.starts[-1], 'end': local_end, 'value': (data.group | sum / 4) | round(5)}] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
            {% endif %}
            {{ data.prices }}
          raw_tomorrow: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[], starts=[], ends=[]) %}
            {% if tomorrow_price is mapping %}
              {% for state in tomorrow_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 1 %}
                  {# MODIFIED: Converts UTC string to a local string format #}
                  {% set local_start = (state.start | as_datetime | as_local).isoformat() %}
                  {% set data.starts = data.starts + [local_start] %}
                {% endif %}
                {% if data.group | count == 4 %}
                  {# MODIFIED: Converts end UTC string to local string format #}
                  {% set local_end = (state.end | as_datetime | as_local).isoformat() %}
                  {% set data.prices = data.prices + [{'start': data.starts[-1], 'end': local_end, 'value': (data.group | sum / 4) | round(5)}] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
            {% endif %}
            {{ data.prices }}

[ Voor 40% gewijzigd door Korvaag op 24-05-2026 18:52 ]

[Venimk1]

pasmanm schreef op zondag 24 mei 2026 @ 10:06:
[...]


[...]

heb hier zelf ook beetje aanpassingen gedaan, zodat ze toch sneller is opgeladen..

code:

alias: "Zendure: Agressief Solar Laden"
description: >-
  Agressievere versie van Slim Solar Laden. Laadt de batterij maximaal op met al
  het surplus boven het huisverbruik. Doel: 100% voor 16:00. Minimaal 800W, max
  2400W. Schakel deze UIT en de originele IN om terug te wisselen.
triggers:
  - minutes: /15
    trigger: time_pattern
conditions:
  - above: 100
    condition: numeric_state
    entity_id: sensor.sb3_0_1av_41_674_pv_power
  - condition: not
    conditions:
      - condition: state
        entity_id: automation.zendure_happy_hours_tijdelijk_laadvermogen
        state: "on"
        for:
          minutes: 0
      - condition: time
        after: "11:00:00"
        before: "16:00:00"
actions:
  - variables:
      eind_instelling: >-
        {% set baseload_w = 400 %}

        {% set min_laad_vermogen = 800 %}

        {% set max_laad_vermogen = 1600 %}

        {% set zendure_cap_wh = 5760 %}

        {% set zendure_huidig_perc =
        states('sensor.solarflow_2400_ac_electric_level') | float(0) %}

        {% set zendure_wh_nodig = (([100 - zendure_huidig_perc, 0] | max) / 100)
        * zendure_cap_wh * 1.1 %}

        {% set pv_now = states('sensor.sb3_0_1av_41_674_pv_power') | float(0) %}

        {% set surplus = [pv_now - baseload_w, 0] | max %}

        {% set forecasts =
        state_attr('sensor.solcast_pv_forecast_voorspelling_vandaag',
        'detailedForecast') %}

        {% set ns = namespace(slots=0) %}

        {% if forecasts is not none %}
          {% for slot in forecasts if as_datetime(slot.period_start) >= now() and as_datetime(slot.period_start) <= today_at('20:30') %}
            {% if slot.pv_estimate | float(0) * 2000 > baseload_w %}
              {% set ns.slots = ns.slots + 1 %}
            {% endif %}
          {% endfor %}
        {% endif %}

        {% set uren = [ns.slots * 0.5, 0.5] | max %}

        {% set benodigd = zendure_wh_nodig / uren %}

        {% set plafond = [benodigd, surplus, min_laad_vermogen] | max %}

        {{ [plafond | int, max_laad_vermogen] | min }}
  - action: input_number.set_value
    data:
      value: "{{ eind_instelling }}"
    target:
      entity_id: input_number.zendure_2400_ac_max_oplaadvermogen
mode: restart

[ctrl-tab]

Korvaag schreef op zondag 24 mei 2026 @ 13:41:
[...]

Gefixed volgens mij. @ctrl-tab Mijn issue zat volgens mij in jouw template (niet lullig bedoeld). Jouw sensor berekent de raw_today en raw_tomorrow niet correct qua timezone. Ik heb jouw code deels aangepast:

Vreemd, hier gaat ie wel goed. Klopt de bron wel?

[ctrl-tab]

Iemand bekend.met dit fenomeen? Gielz en lastste gast777 proxy;

Na charge vanmiddag blijft de temperatuur van invertors hangen op.40.graden..in homeassistant althans.

Nu met discharge weer een eerste meeting binnen en zakt nar werkelijke waarde.

Lijkt erop dat buiten de windows geen temperatuur binnen komt?

[Korvaag]

ctrl-tab schreef op zondag 24 mei 2026 @ 19:47:
[...]

Vreemd, hier gaat ie wel goed. Klopt de bron wel?

Ja volgens mij wel. Settings/integrations. Nordpool. Copy EntryID. Of ik moet dat deel verkeerd hebben begrepen natuurlijk.

[DrNickB]

hemertje schreef op vrijdag 22 mei 2026 @ 23:29:
[...]


@DrNickB

Goede vragen, even punt voor punt:

Acties naar de Zendure
Die zitten er wel in, maar indirect — de switch.zendure_x_offgrid_socket is de offgrid socket van de Zendure zelf, aangestuurd via de Gielz/gast777 integratie. De ventilator hangt aan die socket, dus switch.turn_on op die entity is de actie naar de Zendure. Er is geen directe API-call nodig, de integratie doet dat onder de motorkap.

Ohja dat is waar ook, ik gebruik nog een oudere versie en daar heb ik een eigen offgrid aansturing in gemaakt, die bestond toen nog niet.

hemertje schreef op vrijdag 22 mei 2026 @ 23:29:
Nooit aan / nooit uit door verkeerde thresholds
Hier heb je een punt. Er zit geen validatie in die voorkomt dat je temp_on lager instelt dan temp_off. Als je dat doet — zeg temp_on 30°C en temp_off 35°C — gaat de fan aan zodra de temperatuur boven de 30 komt, maar de UIT-trigger vuurt meteen ook want de temp is al onder de 35. Je krijgt dan een oscillatie of de fan gaat direct weer uit. Omgekeerd, temp_on 40 en temp_off 40, en hij gaat nooit uit want below 40 triggert nooit als hij op 40 staat.

Ik had daar een condition op kunnen zetten die checkt of temp_on daadwerkelijk hoger is dan temp_off voor de automation vuurt, maar dat heb ik weggelaten om de code simpel te houden.

Goede aanvulling — hoe los jij dat in jouw versie op?

Ik heb een simpele eigen automatisering met eigen ingestelde waardes, zonder invoer velden
Boven 39 graden aan, onder de 36 graden uit.

[DrNickB]

@Hippe Lip Moest toch even foto'tje doen.
Moet eigenlijk nog wat langere boutjes met moertjes erop,
en eigenlijk de pootjes in het geheel laseren voor de mooi.

[Hippe Lip]

DrNickB schreef op zondag 24 mei 2026 @ 23:13:
@Hippe Lip Moest toch even foto'tje doen.
Moet eigenlijk nog wat langere boutjes met moertjes erop,
en eigenlijk de pootjes in het geheel laseren voor de mooi.

[Afbeelding]

Fraai gemaakt, @DrNickB
Bij een 2400AC is die montage een stuk eenvoudiger dan bij een 2400AC+ zoals bij mij, omdat daar de koelribben aan de achterkant zitten. Dat betekent dat je de boel er niet zomaar op kunt leggen, maar het op moet hangen. Zie mijn plaatjes een paar pagina’s terug.

[ctrl-tab]

ctrl-tab schreef op zondag 24 mei 2026 @ 20:06:
Iemand bekend.met dit fenomeen? Gielz en lastste gast777 proxy;

Na charge vanmiddag blijft de temperatuur van invertors hangen op.40.graden..in homeassistant althans.

Nu met discharge weer een eerste meeting binnen en zakt nar werkelijke waarde.

Lijkt erop dat buiten de windows geen temperatuur binnen komt?

[Afbeelding]

@gast777 enig idee? In proxy debug logs van de zendures, zie ik wel de juiste temperaturen, nu 30 graden. In HA blijft hij op 40 graden hangen.

Het lijkt erop dat alle proxy sensoren niet actief updaten na een charge/discharge(ssmary discharge modus nu)


Als.ik.een fast charge doe,.updaten de sensoren ineens naar de juiste waarde!

[ Voor 5% gewijzigd door ctrl-tab op 25-05-2026 07:27 ]

[gielz]

Gielz TEST release

⚠️⚠️ Dutch (NL) en English (Global) versies ⚠️⚠️

Let op: bij updaten dat je de juiste versie pakt van je bestaande configuratie. Stap je over dan raak je de historie kwijt.

Volg de GitHub ⭐⭐⭐

1) Zet een Star bij de Github pagina (dan volg je hem wat altijd handig is en maakt de aansturing populairder)
2) Klik op Watch en kies waar je exact een melding van wilt krijgen. Bij Custom kun je specifiek alleen releases aanvinken.
3) Bij je profiel onder Notifications kun je aangeven of het via github zelf gaat of naar je mailbox

Release

https://github.com/Gielz1...-zenSDK/tree/Next-release
Problemen graag via DM of GitHub issue.

English (Global)

⚠️ Please make sure to use the correct language update. ⚠️

New features

PV Export Disabled
You can now use a boolean to specify whether to export the PV generation from the connected panels when the battery is full, or to prevent it instead

Mix series

sensor.zendure_total_capacity
Added correct capacity for SolarFlow 3000 Mix AC+, SolarFlow 4000 Mix AC+ and SolarFlow 4000 Mix Pro

Bug fixes

SOC Protection
When SOC protection is disabled and the battery is discharged below the minimum state of charge, Smart Matching will not start. This issue has now been fixed.

Dynamic Charging/Discharging Cycle
When the battery lost connection to the network during dynamic charging or discharging, the cycle would restart immediately. From now on, if the battery reconnects to the network within 15 seconds, the cycle will continue normally.

Dynamic Charging/Discharging Running
Sometimes after a dynamic cycle, the battery won’t switch to Smart Matching when expected. After a dynamic cycle, an extra check will be performed to verify that the cycle is completely finished.

Dynamic Lowest Price Period
When no lowest price periods were selected, this sensor generated an error message in the logbook. This issue has now been resolved.

Dutch (NL)

⚠️ Zorg ervoor dat je de juiste taalupdate gebruikt. ⚠️

Nieuwe functies

PV Export Uitgeschakeld
Je kunt nu met een boolean aangeven of je de PV-opwek van de aangesloten panelen wilt exporteren wanneer de batterij vol is, of deze juist wilt tegenhouden.

Mix series

sensor.zendure_2400_ac_totale_capaciteit
Juiste capaciteit toegevoegd voor SolarFlow 3000 Mix AC+, SolarFlow 4000 Mix AC+ and SolarFlow 4000 Mix Pro

Bug fixes

SOC Bescherming
Wanneer SOC Bescherming is uitgeschakeld en de batterij onder het minimale laadpercentage wordt ontladen, start Nul op de meter niet. Dit probleem is nu opgelost.

Dynamisch Laden/Ontladen Cyclus
Wanneer tijdens het dynamisch laden of ontladen de batterij de verbinding met het netwerk verloor werd de cyclus direct herstart. Wanneer de batterij binnen 15 seconden weer verbinding heeft met het netwerk zal de cyclus vanaf nu gewoon doorlopen.

Dynamisch Laden/Ontladen Loopt
Soms schakelt de batterij na een dynamische cyclus niet naar Nul op de meter wanneer dat verwacht wordt. Na een dynamische cyclus wordt daarom een extra controle uitgevoerd om te verifiëren dat de cyclus volledig is afgerond.

Dynamisch Goedkoopste Periode
Wanneer er geen goedkope periodes waren geselecteerd gaf deze sensor een foutmelding in het logboek. Dit probleem is nu opgelost.

[gast777]

ctrl-tab schreef op maandag 25 mei 2026 @ 07:14:
[...]

@gast777 enig idee? In proxy debug logs van de zendures, zie ik wel de juiste temperaturen, nu 30 graden. In HA blijft hij op 40 graden hangen.

Dus in de debug van de GET Responses zie je de juiste temperaturen staan. Dus ook in de GET response die naar Home Assistent gaat?

Even de debug functie showen natuurlijk






Als Home Assistant dat in jouw geval soms niet juist toont dan ligt dat in ieder geval niet aan de proxy. Die heeft de juiste data aangeleverd.

(in dit geval 3091/10 - 273.1 = 36 graden)

Edit: als je de debug naar file laat schrijven dan voegt hij ook timestamps toe (in UTC tijdzone). Dan kun je ook zien of deze data ook echt tijdens het probleem is langsgekomen.

[ Voor 7% gewijzigd door gast777 op 25-05-2026 11:46 ]

[ctrl-tab]

gast777 schreef op maandag 25 mei 2026 @ 11:35:
[...]

Dus in de debug van de GET Responses zie je de juiste temperaturen staan. Dus ook in de GET response die naar Home Assistent gaat?

Even de debug functie showen natuurlijk

[Afbeelding]

[Afbeelding]


Als Home Assistant dat in jouw geval soms niet juist toont dan ligt dat in ieder geval niet aan de proxy. Die heeft de juiste data aangeleverd.

(in dit geval 3091/10 - 273.1 = 36 graden)

Edit: als je de debug naar file laat schrijven dan voegt hij ook timestamps toe (in UTC tijdzone). Dan kun je ook zien of deze data ook echt tijdens het probleem is langsgekomen.

Dit was de temperatuur op het moment dat de zendure 1 invertor temp 40-41 aan gaf. Het ging dus specifiek om de proxy sensor.

De 'normale' gielz sensor gaf wel 30-ish aan.

hyperTmp: 3021

[remcoXP]

Volgens mij is dynamisch handelen met zonneplan dit jaar nog het meest lucratief.

Stellen jullie dit dan iedere dag handmatig in of hebben jullie er een automation voor gemaakt?

[Pakhaas]

remcoXP schreef op maandag 25 mei 2026 @ 15:43:
Volgens mij is dynamisch handelen met zonneplan dit jaar nog het meest lucratief.

Stellen jullie dit dan iedere dag handmatig in of hebben jullie er een automation voor gemaakt?

Met @gielz integratie kan dat perfect. Alleen even kort de dag ervoor kijken wanneer goedkoop en duur.

[ppaulv]

Pakhaas schreef op maandag 25 mei 2026 @ 15:57:
[...]

Met @gielz integratie kan dat perfect. Alleen even kort de dag ervoor kijken wanneer goedkoop en duur.

Daar hoef je toch niet meer naar om te kijken of vergis ik me nu?

[Pakhaas]

ppaulv schreef op maandag 25 mei 2026 @ 16:52:
[...]

Daar hoef je toch niet meer naar om te kijken of vergis ik me nu?

Je hebt niet elke dag dezelfde aantal goedkope en dure uren. Dus kijk ik per dag over hoeveel kwartieren ik kan laden en ontladen. Daar pas ik het vermogen ook wat op aan.

[ctrl-tab]

gast777 schreef op maandag 25 mei 2026 @ 11:35:
[...]

Dus in de debug van de GET Responses zie je de juiste temperaturen staan. Dus ook in de GET response die naar Home Assistent gaat?

Even de debug functie showen natuurlijk

[Afbeelding]

[Afbeelding]


Als Home Assistant dat in jouw geval soms niet juist toont dan ligt dat in ieder geval niet aan de proxy. Die heeft de juiste data aangeleverd.

(in dit geval 3091/10 - 273.1 = 36 graden)

Edit: als je de debug naar file laat schrijven dan voegt hij ook timestamps toe (in UTC tijdzone). Dan kun je ook zien of deze data ook echt tijdens het probleem is langsgekomen.

Op dit moment, zie ik in de debug modus gewoon updates van de individuele zendures.

hyperTmp: 3021 en 3031

Het ding is dat er geen enkele specifieke sensor meer door komt. Ik denk totdat ik weer daadwerkelijk ga chargen of dischargen .

Power command blijft ook.op 2400 hangen.


Zie screenshots. En last update tijden.

[Devke]

remcoXP schreef op maandag 25 mei 2026 @ 15:43:
Volgens mij is dynamisch handelen met zonneplan dit jaar nog het meest lucratief.

Stellen jullie dit dan iedere dag handmatig in of hebben jullie er een automation voor gemaakt?

1x per dag (vaak als de tarieven weer bekend zijn voor de volgende dag) kijk ik even hoe ik wil dat er geladen en ontladen wordt. Ff instellen in de gielz integratie en rennen maar.

[koboy]

ppaulv schreef op maandag 25 mei 2026 @ 16:52:
[...]

Daar hoef je toch niet meer naar om te kijken of vergis ik me nu?

De integratie kijkt simpelweg naar het aantal ingestelde uren/kwartieren dat het goedkoopste en duurste zijn, doet verder geen planning t.o.v. het laadmoment. Gaat meestal prima, maar theezakjes drogers en opnieuw gebruikers als @Pakhaas en ondergetekende passen dit dagelijks even aan om er voor te zorgen dat er geen cent verloren gaat.
Soms is het bijvoorbeeld voordeliger om een stukje ochtend piek van de dag erna te pakken, of moet er even een extra uurtje toegevoegd worden om er voor te zorgen dat de accu diezelfde dag nog tot op de laaste electronen leeg is.

[Mistraller]

@gielz Iets wat ik mij nog wel afvraag; jij hebt in je instellingen etc geen disclaimer oid als je het vermogen hoger dan 800W zet, zou dat niet verstandig zijn in de vergezochte situatie dat iemand een zondebok zoekt voor een eigengemaakte fout? Zoals in fireson met de fusegroups oid.

[gielz]

Mistraller schreef op dinsdag 26 mei 2026 @ 00:11:
@gielz Iets wat ik mij nog wel afvraag; jij hebt in je instellingen etc geen disclaimer oid als je het vermogen hoger dan 800W zet, zou dat niet verstandig zijn in de vergezochte situatie dat iemand een zondebok zoekt voor een eigengemaakte fout? Zoals in fireson met de fusegroups oid.

Welke disclaimer toont zendure ha exact?

[Mistraller]

gielz schreef op dinsdag 26 mei 2026 @ 07:29:
[...]


Welke disclaimer toont zendure ha exact?

Als je HEMS gebruikt dan moet je zoals bekend zelfs signen. In fireson dwingt het instellen van de fusegroups je al wat meer om na te denken en het staat in de uitleg op github.
https://github.com/Zendure/Zendure-HA/wiki/Fuse-Group

Dus geen verwijt hoor, maar ik verbaasde mij dat het het zomaar kan om boven de 3000W discharge in te stellen, terwijl Zendure in HEMS heel erg hun best doet om de verantwoordelijkheid bij de gebruiker te krijgen. Ik had overigens verwacht dat zoiets in de firmware vastgelegd zou worden.

Is een overweging voor jouzelf vooral om je in te dekken; een klein stukje automation met een warning indien totaal vermogen hoger dan 800 danwel 3000 (net als hems) met een helper waarin je de status van een "gezien-vinkje" bij kunt houden of zo. >800: "Dedicated groep gebruiken" >3000 "verdeel je zendures over meerdere groepen en/of fases"
Vinkje zorgt ervoor dat je het maar 1x krijgt en dan kan je niet zeggen dat je het niet gezien hebt.

[ Voor 24% gewijzigd door Mistraller op 26-05-2026 10:13 ]

[gast777]

Mistraller schreef op dinsdag 26 mei 2026 @ 10:05:
[...]

Is een overweging voor jouzelf vooral om je in te dekken; een klein stukje automation met een warning indien totaal vermogen hoger dan 800 danwel 3000 (net als hems) met een helper waarin je de status van een "gezien-vinkje" bij kunt houden of zo. >800: "Dedicated groep gebruiken" >3000 "verdeel je zendures over meerdere groepen en/of fases"
Vinkje zorgt ervoor dat je het maar 1x krijgt en dan kan je niet zeggen dat je het niet gezien hebt.

Er is al een disclaimer (of bedoel je waarschuwing?):

https://github.com/Gielz1986/Zendure-HA-zenSDK/blob/main/LICENSE

code:

4. No Warranty

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
OR OTHER DEALINGS IN THE SOFTWARE.

[Mistraller]

gast777 schreef op dinsdag 26 mei 2026 @ 10:51:
[...]

Er is al een disclaimer (of bedoel je waarschuwing?):

https://github.com/Gielz1986/Zendure-HA-zenSDK/blob/main/LICENSE

code:

4. No Warranty

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
OR OTHER DEALINGS IN THE SOFTWARE.

Weet ik. Maar je zou het expliciet kunnen maken. Uiteindelijk zie ik zelfs hier op tweakers mensen twijfelen of het nou echt kwaad kan om meer dan 800W in te voeden op een bestaande groep

Het is slechts een ideetje

[Gramser]

Toch weer een gek dingetje vanochtend. Torentje nummer 2 van mijn AC2400+ reageerde eigenlijk niet meer en bleef maar laden op hetzelfde wattage. Op standby zetten ging niet. Automation uitzetten en HEMS weer aan: zelfde effect. Uiteindelijk ervoor gekozen om de batterijen -beide torens dan maar- spanningloos te maken via de knop en de stekker eruit. Minuutje of wat wachten, weer aanzetten, Gielz enablen en de boel doet het weer.

Toch jammer dat daar een fysieke actie voor nodig was, maar ondertussen heb ik van de gelegenheid gebruik gemaakt om zowel Giels als gast777 even te updaten. Dat was alweer even geleden. Het zou zo jammer zijn als dit in een vakantie gebeurt en je kunt er niks mee. M.n. dat hij niet reageerde op een standby-commando is jammer. Het zou ook zomaar kunnen dat dit bij een calibratie weer goed kwam, weet ik het, maar toch. Aandacht blijft vereist.

[gast777]

ctrl-tab schreef op maandag 25 mei 2026 @ 18:46:
[...]

Op dit moment, zie ik in de debug modus gewoon updates van de individuele zendures.

hyperTmp: 3021 en 3031

Het ding is dat er geen enkele specifieke sensor meer door komt. Ik denk totdat ik weer daadwerkelijk ga chargen of dischargen .

Power command blijft ook.op 2400 hangen.

OK, die algemene en device-specifieke sensoren zitten allemaal in dezelfde GET Response. De algemene worden in de proxy code (blokje "GET Response handling") van de device-specifieke afgeleid (bijv de gemiddelde of hoogste van de waardes van de Zendures wordt genomen).

Dus als de ene wel update en de andere niet, dan is dat heel vreemd. Als de proxy de waarden correct aanlevert aan HA (kun je controleren in de debug), dan zal het toch in HA moeten zitten.

Het chargen of dischargen zou hier in principe ook niets mee te maken moeten hebben, want deze sensoren worden altijd elke seconde opgevraagd door de REST GET request, ongeacht laad/ontlaad acties/status.

Wat misschien wel zou kunnen is dat geen enkele sensor meer update vanuit deze REST GET request (ook de algemene niet). Dan is er een communicatieprobleem en komen de GET Responses niet in HA aan om een of andere reden.

Mocht dit vaker voorkomen, stuur me dan eventueel de debug file en "Geschiedenis" grafiek van HA van tijdens het probleem via DM voor wat meer troubleshooting.

[Mscroos]

gielz schreef op dinsdag 26 mei 2026 @ 07:29:
[...]


Welke disclaimer toont zendure ha exact?

@gielz

[ppaulv]

koboy schreef op maandag 25 mei 2026 @ 20:09:
[...]

De integratie kijkt simpelweg naar het aantal ingestelde uren/kwartieren dat het goedkoopste en duurste zijn, doet verder geen planning t.o.v. het laadmoment. Gaat meestal prima, maar theezakjes drogers en opnieuw gebruikers als @Pakhaas en ondergetekende passen dit dagelijks even aan om er voor te zorgen dat er geen cent verloren gaat.
Soms is het bijvoorbeeld voordeliger om een stukje ochtend piek van de dag erna te pakken, of moet er even een extra uurtje toegevoegd worden om er voor te zorgen dat de accu diezelfde dag nog tot op de laaste electronen leeg is.

ja ok, als je daar tijd in wilt stoppen dan is dat maar zo. Maar ik heb vroeger geleerd dat 'goed' ook meestal 'goed genoeg' is dus daar ga ik niet veel tijd aan spenderen als het eenmaal soepel loopt. En m'n tijd aan andere zaken besteden ....

[Pakhaas]

ppaulv schreef op dinsdag 26 mei 2026 @ 12:12:
[...]

ja ok, als je daar tijd in wilt stoppen dan is dat maar zo. Maar ik heb vroeger geleerd dat 'goed' ook meestal 'goed genoeg' is dus daar ga ik niet veel tijd aan spenderen als het eenmaal soepel loopt. En m'n tijd aan andere zaken besteden ....

Ik moet toch dagelijks kijken wanneer ik 1 van de 2 EV's ga laden. In dat zelfde moment kijk ik ook even snel naar de batterijen. Als het mij 2min kost is het veel.

[R.K]

Ik zie soms een error verschijnen en dan verwijst HA naar de Zendure app, daar kan ik echter niets vinden, iemand een idee wat voor melding dit is en waar in de Zendure app ik dat terug kan vinden?

[Mistraller]

Gramser schreef op dinsdag 26 mei 2026 @ 11:12:
Toch weer een gek dingetje vanochtend. Torentje nummer 2 van mijn AC2400+ reageerde eigenlijk niet meer en bleef maar laden op hetzelfde wattage. Op standby zetten ging niet. Automation uitzetten en HEMS weer aan: zelfde effect. Uiteindelijk ervoor gekozen om de batterijen -beide torens dan maar- spanningloos te maken via de knop en de stekker eruit. Minuutje of wat wachten, weer aanzetten, Gielz enablen en de boel doet het weer.

Toch jammer dat daar een fysieke actie voor nodig was, maar ondertussen heb ik van de gelegenheid gebruik gemaakt om zowel Giels als gast777 even te updaten. Dat was alweer even geleden. Het zou zo jammer zijn als dit in een vakantie gebeurt en je kunt er niks mee. M.n. dat hij niet reageerde op een standby-commando is jammer. Het zou ook zomaar kunnen dat dit bij een calibratie weer goed kwam, weet ik het, maar toch. Aandacht blijft vereist.

Ik denk dat de webserver in de zendure niet altijd helemaal stabiel is. Post requests die niet meer verwerkt worden oid.

[Gramser]

Mistraller schreef op dinsdag 26 mei 2026 @ 13:00:
[...]

Ik denk dat de webserver in de zendure niet altijd helemaal stabiel is. Post requests die niet meer verwerkt worden oid.

Hmmm toch jammer dat je dan thuis moet zijn om dat te verhelpen. Of is er iets waarmee je ‘m weer wakker schudt en normaal laat doen..?

[Pakhaas]

Gramser schreef op dinsdag 26 mei 2026 @ 13:02:
[...]

Hmmm toch jammer dat je dan thuis moet zijn om dat te verhelpen. Of is er iets waarmee je ‘m weer wakker schudt en normaal laat doen..?

Je buren die de planten water geven ook leren hoe ze de batterij kunnen resetten 😅

[Gramser]

Pakhaas schreef op dinsdag 26 mei 2026 @ 13:03:
[...]

Je buren die de planten water geven ook leren hoe ze de batterij kunnen resetten 😅

Mijn buren kennende resetten ze de planten en geven de de batterijen water - ik pas

[Mistraller]

Gramser schreef op dinsdag 26 mei 2026 @ 13:02:
[...]

Hmmm toch jammer dat je dan thuis moet zijn om dat te verhelpen. Of is er iets waarmee je ‘m weer wakker schudt en normaal laat doen..?

misschien met een fingerbot het knopje laten indrukken

Het staat op de wishlist kennelijk. https://forum.zendure.com/d/13961

[Gramser]

Ik wacht de ontwikkelingen wel af 😆

[gast777]

R.K schreef op dinsdag 26 mei 2026 @ 12:50:
Ik zie soms een error verschijnen en dan verwijst HA naar de Zendure app, daar kan ik echter niets vinden, iemand een idee wat voor melding dit is en waar in de Zendure app ik dat terug kan vinden?[Afbeelding]

Dit gaat blijkbaar over de "Zendure 2400 AC Error" (niet te zien in je screenshot)?

YAML:

      - name: "Zendure 2400 AC Error"
        value_template: >
          {% set states = {0: "Geen meldingen", 1: "Zie Zendure APP"} %}
          {% set packState = value_json['properties']['is_error'] | int %}
          {{ states.get(packState, "Onbekend") }}
        unique_id: Zendure_2400_AC_Error
        icon: mdi:battery-alert

Dan geeft je zendure aan dat er een error is. Property "is_error" heeft waarde "1".

Meer weet HA ook niet, dus is de hoop dat de Zendure App meer informatie over de error zal geven.

[ctrl-tab]

Mistraller schreef op dinsdag 26 mei 2026 @ 13:10:
[...]

misschien met een fingerbot het knopje laten indrukken

Het staat op de wishlist kennelijk. https://forum.zendure.com/d/13961

Van de week postte Gielz dat deze feature daadwerkelijk gebouwd gaat worden

[Gramser]

Joh! Die had ik even gemist dus.

[R.K]

gast777 schreef op dinsdag 26 mei 2026 @ 13:23:
[...]

Dit gaat blijkbaar over de "Zendure 2400 AC Error" (niet te zien in je screenshot)?

YAML:

      - name: "Zendure 2400 AC Error"
        value_template: >
          {% set states = {0: "Geen meldingen", 1: "Zie Zendure APP"} %}
          {% set packState = value_json['properties']['is_error'] | int %}
          {{ states.get(packState, "Onbekend") }}
        unique_id: Zendure_2400_AC_Error
        icon: mdi:battery-alert

Dan geeft je zendure aan dat er een error is. Property "is_error" heeft waarde "1".

Meer weet HA ook niet, dus is de hoop dat de Zendure App meer informatie over de error zal geven.

Het is idd de 'Zendure 2400ac error' de app geeft nergens info over een error.

[gielz]

R.K schreef op dinsdag 26 mei 2026 @ 14:03:
[...]

Het is idd de 'Zendure 2400ac error' de app geeft nergens info over een error.

Bij de laatste firmware geeft hij ook een error zodra de batterij op 100% komt. Wellicht ook bij jou?

[koboy]

ppaulv schreef op dinsdag 26 mei 2026 @ 12:12:
[...]

ja ok, als je daar tijd in wilt stoppen dan is dat maar zo. Maar ik heb vroeger geleerd dat 'goed' ook meestal 'goed genoeg' is dus daar ga ik niet veel tijd aan spenderen als het eenmaal soepel loopt. En m'n tijd aan andere zaken besteden ....

Zeker, goed genoeg is goed genoeg als ik op vakantie ben. Nu kijk ik er even naar juist als ik met andere dingen bezig ben. De belastingdienst heeft 15 euro af te dragen BTW per kWh opslag van de BTW teruggave ingehouden, dus ik zit dit jaar even in de maximalisatie stand.

[Theetjuh]

Vraagje, ik ben op het moment de @gielz integratie aan het inrichten, ik heb het IP al toegevoegd, maar ik zit nu nog even met de P1 meter.
Ik maak hierbij gebruik van een ESPHome en dit product van Zuidwijk: https://www.zuidwijk.com/product/p1-reader-ethernet/

Hierbij heb ik 2 entities, hoe kan ik dat integreren in de enkele entitie 'home_energy_setting_meter_sensor'?:

• sensor.p1_port_power_produced
• sensor.p1_port_power_consumed

[Theetjuh]

Ik denk dat ik al wat heb gevonden, heb even een template sensor aangemaakt:

code:

Name: P1-Port Power
State: {{ ((states('sensor.p1_port_power_consumed') | float(0)) - (states('sensor.p1_port_power_produced') | float(0))) * 1000 }}
Unit of measurement: W (moet blijkbaar in Watt ipv Kilowatt?)
Device class: Power
State class: Measurement
Select a device: P1-Port

[ Voor 2% gewijzigd door Theetjuh op 26-05-2026 17:00 . Reden: correctie, zie volgende post ]

[R.K]

gielz schreef op dinsdag 26 mei 2026 @ 15:14:
[...]


Bij de laatste firmware geeft hij ook een error zodra de batterij op 100% komt. Wellicht ook bij jou?

Dat was het, error en battery 100% was op hetzelfde moment. Niet iets om mij druk om te maken dus. Bedankt voor de info.

[Theetjuh]

Theetjuh schreef op dinsdag 26 mei 2026 @ 15:45:
Ik denk dat ik al wat heb gevonden, heb even een template sensor aangemaakt:

code:

Name: P1-Port Power
State: {{ ((states('sensor.p1_port_power_produced') | float(0)) - (states('sensor.p1_port_power_consumed') | float(0))) * 1000 }}
Unit of measurement: W (moet blijkbaar in Watt ipv Kilowatt?)
Device class: Power
State class: Measurement
Select a device: P1-Port

Blijkbaar moet het een negatieve waarde zijn als je teveel stroom hebt en dus wilt chargen:

code:

{{ ((states('sensor.p1_port_power_consumed') | float(0)) - (states('sensor.p1_port_power_produced') | float(0))) * 1000 }}

[Tiesert]

Ik heb afgelopen weekend de 2400AC+ neergezet en gekozen voor de Zendure-HA integratie op basis van de SDK (local). Nu draait het systeem NOM en doet het geweldig. Maar hij laadt niet bij als de prijzen 's nachts laag zijn en er de volgende dag geen hoge opbrengst van de panelen wordt verwacht. Of de warmtepomp trekt 's morgens vroeg de batterij leeg terwijl ik dan later op de dag duurder moet inkopen. Of hij koopt al in terwijl even later de zon flink gaat schijnen en de batterijen gratis gevuld hadden kunnen worden.

Hoe zou ik dit het beste kunnen automatiseren icm Nordpool en bv forecast.solar? Bestaat er al iets om dit goed mee in te richten (liefst pyscript of Automation), of waar kan ik het best op zoeken hier op het forum? Dank voor het meedenken!

[Gramser]

Heb je de Gielz-integratie al bekeken? Volgens mij kan die wat jij wil?

[Tiesert]

Gramser schreef op woensdag 27 mei 2026 @ 12:17:
Heb je de Gielz-integratie al bekeken? Volgens mij kan die wat jij wil?

Dank je, veel gevolgd in deze groep. Ik zou graag vanuit de kern meerdere Zendure omvormers willen kunnen aansturen, liefst via pyScript, en niet NR hoeven toevoegen. Vandaar dat ik me afvraag hoe anderen dit doen obv bijvoorbeeld de standaard Zendure-ha integratie.

[Mistraller]

Tiesert schreef op woensdag 27 mei 2026 @ 14:57:
[...]

Dank je, veel gevolgd in deze groep. Ik zou graag vanuit de kern meerdere Zendure omvormers willen kunnen aansturen, liefst via pyScript, en niet NR hoeven toevoegen. Vandaar dat ik me afvraag hoe anderen dit doen obv bijvoorbeeld de standaard Zendure-ha integratie.

Kijk ff naar Fireson dan?

[gielz]

Tiesert schreef op woensdag 27 mei 2026 @ 11:10:
Ik heb afgelopen weekend de 2400AC+ neergezet en gekozen voor de Zendure-HA integratie op basis van de SDK (local). Nu draait het systeem NOM en doet het geweldig. Maar hij laadt niet bij als de prijzen 's nachts laag zijn en er de volgende dag geen hoge opbrengst van de panelen wordt verwacht. Of de warmtepomp trekt 's morgens vroeg de batterij leeg terwijl ik dan later op de dag duurder moet inkopen. Of hij koopt al in terwijl even later de zon flink gaat schijnen en de batterijen gratis gevuld hadden kunnen worden.

Hoe zou ik dit het beste kunnen automatiseren icm Nordpool en bv forecast.solar? Bestaat er al iets om dit goed mee in te richten (liefst pyscript of Automation), of waar kan ik het best op zoeken hier op het forum? Dank voor het meedenken!

Je zou kunnen kijken naar https://github.com/TheFes/cheapest-energy-hours of https://github.com/Gielz1986/Dynamisch-HA

Uiteraard moet je dan wel zelf de automatisering eromheen bouwen.

[Tiesert]

Mistraller schreef op woensdag 27 mei 2026 @ 14:59:
[...]

Kijk ff naar Fireson dan?

Ja, die zenSDK integratie die ik gebruik is fireson. Maar volgens mij alleen reactief op de P1-meter, en niet vooruitkijkend naar bijvoorbeeld zon of tarieven.

[thijsh02]

Heeft iemand al de Zendure smart plug pro geintegreerd in Home Assistant?

[Hippe Lip]

Tiesert schreef op woensdag 27 mei 2026 @ 11:10:
[…] Of hij koopt al in terwijl even later de zon flink gaat schijnen en de batterijen gratis gevuld hadden kunnen worden.

@Tiesert Dit is een denkfout en hier stonk ik in het begin ook in. Dit punt is hier al vaker langsgekomen.

Zolang we nog saldering hebben is het gebruik van je zonnestroom niet gratis. Als je die stroom niet gebruikt dan zou die teruggeleverd worden en krijg je er geld voor. Hoeveel dat is hangt af van je contract en eventueel van het moment. Je gebruik van je zonnestroom kost dus zoveel als wat je er anders voor gekregen had.

Dat is waarom het werken met een automatisering als die van @gielz gewoon ideaal is. Ik laad mijn accu nu dagelijks tijdens de 24 goedkoopste kwartieren op (hij heeft iets minder nodig om vol te raken) en ontlaad tijdens de 20 duurste kwartieren.
Geen omkijken naar en altijd het hoogste rendement.

[Tiesert]

Hippe Lip schreef op woensdag 27 mei 2026 @ 23:35:
[...]

@Tiesert Dit is een denkfout en hier stonk ik in het begin ook in. Dit punt is hier al vaker langsgekomen.

Zolang we nog saldering hebben is het gebruik van je zonnestroom niet gratis. Als je die stroom niet gebruikt dan zou die teruggeleverd worden en krijg je er geld voor. Hoeveel dat is hangt af van je contract en eventueel van het moment. Je gebruik van je zonnestroom kost dus zoveel als wat je er anders voor gekregen had.

Dat is waarom het werken met een automatisering als die van @gielz gewoon ideaal is. Ik laad mijn accu nu dagelijks tijdens de 24 goedkoopste kwartieren op (hij heeft iets minder nodig om vol te raken) en ontlaad tijdens de 20 duurste kwartieren.
Geen omkijken naar en altijd het hoogste rendement.

Ja, tuurlijk, dat is waar. Dank je wel. Ik zit me al voor te bereiden op 2027. Sterker nog, ik heb nog een vast contract dus ik kan de batterij er beter tussenuit laten. Maar ja, heb zo wel meer tijd om alles goed te krijgen. Geweldige basis om de goedkoopste kwartieren te nemen om te laden en de duurste om te ontladen. En wat is je plan in 2027? Want dan zul je het anders willen aanpakken neem ik aan?

[Hippe Lip]

@Tiesert
Ook ik ben me aant voorbereiden op volgend jaar. Dat is waarom ik vanaf januari voor het eerst op een dynamisch contract zit. Dan ga je vanzelf anders denken en dingen anders inrichten (aanrader dus). Op die manier kwam de batterij snel in zicht. Ik heb nu twee stapels 2400AC+ met elk nog 3 extra batterijen eronder; 2x 11 kWh dus.

Omdat ik full electric ben (en elektrisch rijd) heb ik 40 PV-panelen. Ik prijs mezelf gelukkig met een geschikt Oost-West-dak.

De batterijcapaciteit is te klein om er een hele PV-dagproductie in zomertijd in op te slaan en iets groter dan een etmaal verbruik in wintertijd. Dat leek me een geschikte balans.

Volgend jaar ga ik NOM draaien met die batterijen in de zomer (en voor- en najaar?) en op de goedkoopste kwartieren inkopen in de winter. Zo hoop ik aardig te kunnen besparen.

[Tiesert]

Hippe Lip schreef op donderdag 28 mei 2026 @ 00:35:
@Tiesert
Ook ik ban me aant voorbereiden op volgend jaar. Dat is waarom ik vanaf januari voor het eerst op een dynamisch contract zit. Dan ga je vanzelf anders denken en dingen anders inrichten (aanrader dus). Op die manier kwam de batterij snel in zicht. Ik heb nu twee stapels 2400AC+ met elk nog 3 extra batterijen eronder; 2x 11 kWh dus.

Omdat ik full electric ben (en elektrisch rijd) heb ik 40 PV-panelen. Ik prijs mezelf gelukkig met een geschikt Oost-West-dak.

De batterijcapaciteit is te klein om er een hele PV-dagproductie in zomertijd in op te slaan en iets groter dan een etmaal verbruik in wintertijd. Dat leek me een geschikte balans.

Volgend jaar ga ik NOM draaien met die batterijen in de zomer (en voor- en najaar?) en op de goedkoopste kwartieren inkopen in de winter. Zo hoop ik aardig te kunnen besparen.

Dank, soms is de oplossing eenvoudiger dan gedacht. Nog wel even de teruglevering uitschakelen als de batterijen volzitten. ;-)

[Luuk741]

Er gaat iets niet helemaal goed met mijn Zendure 2400AC+ met 1 extra batterij in Home Assistant. Ik draai de Gielz integratie met dynamisch handelen en dat draait eigenlijk als een zonnetje. Maar, vanmorgen viel het me op dat sinds gisteravond de batterij niet meer in de opslagcapaciteit zit (2.4 ipv 5.3kWh dus).

Het minimale ontlaadpercentage staat op 10%, maar hij stopte gisteren al bij 13% met ontladen. Sindsdien staat hij in standby, maar ik krijg de Zendure niet meer aan de praat. Niet door geforceerd snel te laden, en ook in de Zendure app of via HEMS lukt het niet. Iemand nog een tip? Ik ben op het moment niet thuis, dus een hard reset kan pas vanavond helaas.

Zie onderstaande afbeeldingen voor een inkijkje

[gielz]

Luuk741 schreef op donderdag 28 mei 2026 @ 08:00:
Er gaat iets niet helemaal goed met mijn Zendure 2400AC+ met 1 extra batterij in Home Assistant. Ik draai de Gielz integratie met dynamisch handelen en dat draait eigenlijk als een zonnetje. Maar, vanmorgen viel het me op dat sinds gisteravond de batterij niet meer in de opslagcapaciteit zit (2.4 ipv 5.3kWh dus).

Het minimale ontlaadpercentage staat op 10%, maar hij stopte gisteren al bij 13% met ontladen. Sindsdien staat hij in standby, maar ik krijg de Zendure niet meer aan de praat. Niet door geforceerd snel te laden, en ook in de Zendure app of via HEMS lukt het niet. Iemand nog een tip? Ik ben op het moment niet thuis, dus een hard reset kan pas vanavond helaas.

Zie onderstaande afbeeldingen voor een inkijkje

[Afbeelding]

[Afbeelding]

[Afbeelding]

Vreemd hij ziet wel 2 packs (2 batterijen) Hij gaat daarna kijken wat voor batterij dit is maar ziet dit blijkbaar niet. Als je in de Zendure APP kijkt zie je de batterijen dan wel bij devices? En reageert de batterij nog wel op settings zoals het maximale oplaadvermogen aanpassen naar bijvoorbeeld 1800 watt?

@geert1992 was ook laatst een batterij kwijt en zag deze niet in de Zendure APP en Zendure HA. Wat was hier toen het euvel?

[Luuk741]

gielz schreef op donderdag 28 mei 2026 @ 08:07:
[...]

Vreemd hij ziet wel 2 packs (2 batterijen) Hij gaat daarna kijken wat voor batterij dit is maar ziet dit blijkbaar niet. Als je in de Zendure APP kijkt zie je de batterijen dan wel bij devices? En reageert de batterij nog wel op settings zoals het maximale oplaadvermogen aanpassen naar bijvoorbeeld 1800 watt?

@geert1992 was ook laatst een batterij kwijt en zag deze niet in de Zendure APP en Zendure HA. Wat was hier toen het euvel?

Vreemd he? Ja, in de Zendure app staan wel beide batterijen nog. Ook het aanpassen van de instellingen is nog mogelijk, en onder het gezondheids tabblad komen dan ook de nieuwe ingestelde waardes te staan. Ik draai de up to date mei versie van je integratie die het hiervoor prima deed, dus daar zou niks vreemds in moeten zitten

Klinkt dus alsof het net wat anders is dan @geert1992 had.

[ Voor 16% gewijzigd door Luuk741 op 28-05-2026 08:14 ]

[geert1992]

Luuk741 schreef op donderdag 28 mei 2026 @ 08:13:
[...]

Vreemd he? Ja, in de Zendure app staan wel beide batterijen nog. Ook het aanpassen van de instellingen is nog mogelijk, en onder het gezondheids tabblad komen dan ook de nieuwe ingestelde waardes te staan. Ik draai de up to date mei versie van je integratie die het hiervoor prima deed, dus daar zou niks vreemds in moeten zitten

Klinkt dus alsof het net wat anders is dan @geert1992 had.

[Afbeelding]

Als je ze nog wel ziet in de app, dan hebben we inderdaad iets anders. Mijn batterij was foetsie, in de api, en in de app.

[m-vw]

Een berichtje van @thijsh02 over voeden van de fan via het noodstroomstopcontact deed mij denken dat er al eerder iemand hierover iets had gepost. Volgens mij werd daar het stopcontact geschakeld.

Helaas kan ik dat zo snel niet vinden. Wie weet welke ik bedoel?

[Luuk741]

m-vw schreef op donderdag 28 mei 2026 @ 08:42:
Een berichtje van @thijsh02 over voeden van de fan via het noodstroomstopcontact deed mij denken dat er al eerder iemand hierover iets had gepost. Volgens mij werd daar het stopcontact geschakeld.

Helaas kan ik dat zo snel niet vinden. Wie weet welke ik bedoel?

https://gathering.tweakers.net/forum/view_message/85271042

Deze toevallig?

[wautah91]

Luuk741 schreef op donderdag 28 mei 2026 @ 08:13:
[...]

Vreemd he? Ja, in de Zendure app staan wel beide batterijen nog. Ook het aanpassen van de instellingen is nog mogelijk, en onder het gezondheids tabblad komen dan ook de nieuwe ingestelde waardes te staan. Ik draai de up to date mei versie van je integratie die het hiervoor prima deed, dus daar zou niks vreemds in moeten zitten

Klinkt dus alsof het net wat anders is dan @geert1992 had.

[Afbeelding]

Heb je een app van je router? Dan kun je wellicht even de netwerktoegang van de Zendure blokkeren en na bijv. 5 minuten weer toestaan. Misschien dat ie dan weer tot leven komt. Werkt bij mij namelijk wel met een Hyper.

[Pakhaas]

Luuk741 schreef op donderdag 28 mei 2026 @ 08:00:
Er gaat iets niet helemaal goed met mijn Zendure 2400AC+ met 1 extra batterij in Home Assistant. Ik draai de Gielz integratie met dynamisch handelen en dat draait eigenlijk als een zonnetje. Maar, vanmorgen viel het me op dat sinds gisteravond de batterij niet meer in de opslagcapaciteit zit (2.4 ipv 5.3kWh dus).

Het minimale ontlaadpercentage staat op 10%, maar hij stopte gisteren al bij 13% met ontladen. Sindsdien staat hij in standby, maar ik krijg de Zendure niet meer aan de praat. Niet door geforceerd snel te laden, en ook in de Zendure app of via HEMS lukt het niet. Iemand nog een tip? Ik ben op het moment niet thuis, dus een hard reset kan pas vanavond helaas.

Zie onderstaande afbeeldingen voor een inkijkje

[Afbeelding]

[Afbeelding]

[Afbeelding]

Maar even snuffelen aan de connector

[ZuinigeRijder]

Hoe doen jullie een tijd-schema in Home Assistant om de verschillende modes van de batterijen aan te sturen op verschillende tijdstippen (NOM, Slim opladen, Dynamisch NOM). Gebruiken jullie daar hulpmiddelen voor, zoals Scheduler Card?

Ik wil bijvoorbeeld Slim ontladen tot bijvoorbeeld 10 uur en dan NOM van 10 tot 16:00 uur en daarna weer Slim ontladen. En dat weer eenvoudig aanpassen naar bijvoorbeeld andere tijdstippen.

[Wai_AM]

ZuinigeRijder schreef op donderdag 28 mei 2026 @ 09:34:
Hoe doen jullie een tijd-schema in Home Assistant om de verschillende modes van de batterijen aan te sturen op verschillende tijdstippen (NOM, Slim opladen, Dynamisch NOM). Gebruiken jullie daar hulpmiddelen voor, zoals Scheduler Card?

Ik wil bijvoorbeeld Slim ontladen tot bijvoorbeeld 10 uur en dan NOM van 10 tot 16:00 uur en daarna weer Slim ontladen. En dat weer eenvoudig aanpassen naar bijvoorbeeld andere tijdstippen.

automatisering aanmaken met tijdhelpers.
trigger: op begintijdstip tijdhelper1 , tijdhelper1 zet je op 10:00
doe dan: zendure NOM
trigger: op begintijdstip tijdhelper2 , tijdhelper2 zet je op 16:00
doe dan:zendure Slimontladen

Mocht je andere tijdstippen willen dan de helpers andere tijden geven, hoef je niks in je automatisering te verandern.

[Luuk741]

wautah91 schreef op donderdag 28 mei 2026 @ 09:21:
[...]

Heb je een app van je router? Dan kun je wellicht even de netwerktoegang van de Zendure blokkeren en na bijv. 5 minuten weer toestaan. Misschien dat ie dan weer tot leven komt. Werkt bij mij namelijk wel met een Hyper.

Geprobeerd maar helaas, dat heeft hem ook niet wakker kunnen krijgen.

@Pakhaas thuis de reuktest maar eens doen indd. Zou wel balen zijn als de 2400AC+ vergelijkbare problemen heeft (en ik de eerste ben die ze moet ondervinden )

[Gramser]

Luuk741 schreef op donderdag 28 mei 2026 @ 08:13:
[...]

Vreemd he? Ja, in de Zendure app staan wel beide batterijen nog. Ook het aanpassen van de instellingen is nog mogelijk, en onder het gezondheids tabblad komen dan ook de nieuwe ingestelde waardes te staan. Ik draai de up to date mei versie van je integratie die het hiervoor prima deed, dus daar zou niks vreemds in moeten zitten

Klinkt dus alsof het net wat anders is dan @geert1992 had.

[Afbeelding]

Ik heb het niet helemaal teruggelezen maar had je de batterijen/installatie al eens een reset gegeven? Dus even helemaal van de stroom en de wifi?

[Luuk741]

Gramser schreef op donderdag 28 mei 2026 @ 11:02:
[...]

Ik heb het niet helemaal teruggelezen maar had je de batterijen/installatie al eens een reset gegeven? Dus even helemaal van de stroom en de wifi?

Nee, enkel van de wifi gehaald via de Deco app. Ben helaas niet thuis dus hard reset zit er nog niet in. Dat wordt de volgende stap inderdaad, maar hoopte hem op afstand weer aan de praat te kunnen krijgen. Zou jammer zijn als dit tijdens een drie weekse vakantie gebeurt en alleen een hard reset de oplossing is

[Gramser]

Dat is precies de reden waarom ik blij was te vernemen (eergisteren ofzo) dat een hard reset-commando ook mogelijk zou worden vanuit de app. Want zo had ik onlangs ook een stapeltje dat maar bleef leveren, en niet reageerde op commando's. Niet gewacht tot wat er zou gebeuren als hij leeg was. Misschien had dat wel een trigger tot normaal gedrag teweeg gebracht... maar de harde reset werkte.

[Hippe Lip]

Tiesert schreef op donderdag 28 mei 2026 @ 01:01:
[...]

Dank, soms is de oplossing eenvoudiger dan gedacht. Nog wel even de teruglevering uitschakelen als de batterijen volzitten. ;-)

@Tiesert Die teruglevering hoef ik alleen uit te schakelen bij negatieve prijzen. Anders mag dat overschot rustig het net op. Met een beetje geluk verdien ik dan nog 5-10 cent die dag

[Luuk741]

Hm, gedurende de dag is de capaciteit van de eerste batterij (intern bij de omvormer) ook verdwenen. Gaat nog niet de goede kant op zo

[gast777]

Luuk741 schreef op donderdag 28 mei 2026 @ 16:44:
Hm, gedurende de dag is de capaciteit van de eerste batterij (intern bij de omvormer) ook verdwenen. Gaat nog niet de goede kant op zo [Afbeelding]

Die batterijspanning van 44 V lijkt me ook nogal laag. In ieder geval bij de SF2400AC is dat normaal ongeveer 50V. Ik weet niet wat voor model je hebt en wat het normale voltage daarbij is, maar het is wellicht een defect?

Zien ze er in de Zendure App nog wel normaal uit en is het systeem daarmee bruikbaar?

[Luuk741]

gast777 schreef op donderdag 28 mei 2026 @ 21:01:
[...]

Die batterijspanning van 44 V lijkt me ook nogal laag. In ieder geval bij de SF2400AC is dat normaal ongeveer 50V. Ik weet niet wat voor model je hebt en wat het normale voltage daarbij is, maar het is wellicht een defect?

Zien ze er in de Zendure App nog wel normaal uit en is het systeem daarmee bruikbaar?

Het is een 2400AC+. Normaliter schommelt de batterijspanning indd ook rond de 50V zie ik nu terug. Heb hem uiteindelijk wakker gekregen door de knop ongeveer 10 seconden ingedrukt te houden. Daarna even vol geladen en ontladen om te kijken hoe dat ging, maar leek weer normaal. Hij leek wel wat te klooien met het laadpercentage en toen hij net weer op de grens van 10% zat ging hij met vol vermogen pendelen i.p.v. in standby. Heb hem nu even op standby gezet en zal proberen hem morgen handmatig naar 100% te laden en zo te kalibreren, kijken of dat de boel weer rechttrekt.

Overigens staan beide batterijen weer in HA en klopt de capaciteit ook weer. Vanmiddag zag alles er in de Zendure app prima uit, maar ook daar kreeg ik hem niet uit de standby modus. Zowel in als buiten HEMS

[geert1992]

peterbier schreef op donderdag 28 mei 2026 @ 21:19:
[...]

Ho dat is anders de Hyper ja die stopte hier ook.
Maar ik gebruik geen MQTT voor Zendure.
De SF800pro en 2400AC pakte nom mooi op.
De Hyper ging naar 0.
Misschien een misverstand.😔

Doe het even hier;

Je kan ook de hyper lokaal aansturen door mosquito broker op HA te installeren;

en bij apparaten een MQTT device koppelen;

Dan kan je bij device settings de hyper op lokaal zetten, en zou die ook doordraaien wanneer internet wegvalt.

[ Voor 29% gewijzigd door geert1992 op 28-05-2026 21:33 ]

[Mscroos]

gielz schreef op donderdag 21 mei 2026 @ 14:17:
Wellicht handig om te weten. In de zenSDK API zijn ze nu het volgende aan het ontwikkelen;

https://github.com/Zendure/zenSDK

[...]

Ik heb net met de debug tool van @gast777 kunnen registreren wat er gebeurd als de accu niet meer reageert. Er werden gewoon POST opdrachten gestuurd en GET ontvangen van alle drie mijn systemen. De output bleef op 0 staan. Doordat de accu met de hoogste capaciteit aan de beurt was om te ontladen bleef de node-red daar de opdrachten naartoe sturen. Als jullie er iets aan hebben kan ik deze wel via DM sturen. Wellicht is er iets van een auto reset mogelijk in de toekomst?

[Henkoes]

Is het ook mogelijk om 4 of 5 torens te gebruik met de gast777 proxy? Extra vermogen zou super welkom zijn.

[ Voor 25% gewijzigd door Henkoes op 29-05-2026 10:45 ]

[Lange_Slurf]

Mscroos schreef op donderdag 28 mei 2026 @ 23:27:
[...]

Ik heb net met de debug tool van @gast777 kunnen registreren wat er gebeurd als de accu niet meer reageert. Er werden gewoon POST opdrachten gestuurd en GET ontvangen van alle drie mijn systemen. De output bleef op 0 staan. Doordat de accu met de hoogste capaciteit aan de beurt was om te ontladen bleef de node-red daar de opdrachten naartoe sturen. Als jullie er iets aan hebben kan ik deze wel via DM sturen. Wellicht is er iets van een auto reset mogelijk in de toekomst?

Ik heb onlangs ook iets soortgelijks gehad.
Opdrachten werden verstuurd maar niet uitgevoerd, uiteindelijk was de oplossing voor mij heel simpel. Beide stapels helemaal uitzetten en weer opnieuw op laten starten. Hierna is het issue niet meer voorgekomen

[Lange_Slurf]

Iemand een idee hoe het komt dat dit, en na 1400 uur ook het venster morgen, zo raar ingezoomd is na het openen van de pagina?
Als ik een beetje speel met de goedkope uren setting dan springt hij weer naar "24 uurs" view.

[Hippe Lip]

Lange_Slurf schreef op vrijdag 29 mei 2026 @ 10:34:
Iemand een idee hoe het komt dat dit, en na 1400 uur ook het venster morgen, zo raar ingezoomd is na het openen van de pagina?
Als ik een beetje speel met de goedkope uren setting dan springt hij weer naar "24 uurs" view.

[Afbeelding]

Ah, ik dacht dat ik de enige was. Dank je voor deze post.
Ik los het op door even naar een ander tabblad van de Gielz te gaan en weer teug. Dan staat de hele dag erop.

Maar het ligt dus niet aan mij of mijn telefoon of HA.

Ik heb het op mijn iPhone. En jij, @Lange_Slurf ?

[Mscroos]

Lange_Slurf schreef op vrijdag 29 mei 2026 @ 10:30:
[...]

Ik heb onlangs ook iets soortgelijks gehad.
Opdrachten werden verstuurd maar niet uitgevoerd, uiteindelijk was de oplossing voor mij heel simpel. Beide stapels helemaal uitzetten en weer opnieuw op laten starten. Hierna is het issue niet meer voorgekomen

Is bij mij ook de oplossing geweest, met de nieuwe "reboot" functie die in Zen SDK gaat komen hoop ik dat dit deze use-case automatisch gedetecteerd wordt en de betreffende unit restart vandaar mij post. Zoiets als "aangestuurd vermogen voor unit 1 <> ontvangen output vermogen voor unit 1 dan reboot"