Zendure producten in Home Assistant integreren deel 2

[gielz]

⛔ Zorg ervoor dat HEMS is uitgeschakeld in de Zendure-app ⛔

Beschik je over basiskennis van Home Assistant? Dan kun je hier direct mee aan de slag. Nieuw in Home Assistant? Wees gewaarschuwd: het is verslavend leuk om alles te automatiseren!
In dit topic bespreken we beide integraties en moedigen we je aan om je creativiteit te gebruiken. Deel je ervaringen — samen maken we het slimmer en beter.

Werkt bij jou alles naar wens? Deel dan even wat jij gebruikt in deze poll: https://strawpoll.com/05ZdzxXvmn6

*24-10-2025

🔋 Aansturing - zenSDK (Gielz) 🔋

Installatie	Github	https://github.com/Gielz1986/Zendure-HA-zenSDK
	Connectie	Lokaal
	Soort	Configuration.yaml + 1 automatisering
Aansturing	Omvormer(s)	Maximaal 1 omvormer ⛔
	Type(s)	Solarflow 2400 AC en Solarflow 800 pro (geen aangesloten zonnepanelen)
	Soort	zenSDK
Releasenotes	Github	https://github.com/Gielz1986/Zendure-HA-zenSDK/releases
Issues	Github	https://github.com/Gielz1986/Zendure-HA-zenSDK/issues

Informatie

Om in twee stappen je batterij lokaal werkend te krijgen in Home Assistant.

Gebaseerd op de zenSDK RESTful API voor Home Assistant. Deze setup maakt lokaal verbinding met één Zendure Solarflow 2400 AC / Zendure Solarflow 800 Pro (geen aangesloten zonnepanelen) zonder gebruik te maken van integraties maar werkt met één automatisering. Voor de gene die graag de batterij 100% lokaal in eigen beheer wilt zonder updates van derden en netjes in Home Assistant.

Modus opties

Standby	Zet volledig in standby en sensor.zendure_2400_ac_opslagmodus zal naar Opslaan in Flash gaan. Hierdoor is het ook 0 watt op een KWH MID Meter.
Handmatig	Via input_number.zendure_2400_ac_handmatig_vermogen kun je zelf aangeven wat de batterij doet.
Nul op de meter	Constant 0 op de meter behouden (-40 watt bij opladen en -2 watt bij ontladen).
Dynamisch NOM	⚠️ Let op: Alleen te gebruiken met Nordpool sensor. Wanneer sensor.dynamisch_goedkoopste_periode op JA staat zal er opgeladen worden indien sensor.dynamisch_spread_indicatie_nom hoger is dan input_number.dynamisch_minimale_spread. Wanneer sensor.dynamisch_goedkoopste_periode erg lang op JA staat zal hij pas weer gaan laden wanneer de batterij ontladen is tot 90%. Hij zal na laden constant 0 op de meter behouden (-40 watt bij opladen en -2 watt bij ontladen).
Alleen slim ontladen	Identiek aan Nul op de meter alleen zonder opladen.
Alleen slim opladen	Identiek aan Nul op de meter alleen zonder ontladen.
Opladen met 2400 watt	Snel opladen op maximaal vermogen.
Ontladen met 2400 watt	Snel ontladen op maximaal vermogen.

Aansturingslogboek

🔋 Aansturing - Zendure (voorheen Fireson) 🔋

Installatie	Github	https://github.com/Zendure/Zendure-HA
	Connectie	Lokaal en Cloud
	Soort	HACS integratie
Aansturing	Omvormer(s)	Geen maximum
	Type(s)	Hyper 2000, Solarflow 2400 AC en Solarflow 800 pro
	Soort	zenSDK en MQTT
Releasenotes	Github	https://github.com/Zendure/Zendure-HA/releases
Issues	Github	https://github.com/Zendure/Zendure-HA/issues

Informatie

Deze Home Assistant-integratie koppelt je Zendure-apparaten aan Home Assistant en maakt alle gerapporteerde parameters beschikbaar als entiteiten. Je kunt het batterijniveau, het energieverbruik en -opbrengst volgen, laadinstellingen beheren en je Zendure-apparaten opnemen in je thuisautomatiseringsroutines.

Daarnaast biedt de integratie een energiemanagerfunctie die kan helpen het energieverbruik te balanceren tussen meerdere apparaten wanneer een P1-meterentiteit wordt gebruikt.

Screenshots en uitleg aangeleverd door @martinvdm en @Tijgerkracht.

Modus opties

Uit	Zet in standby.
Handmatig Vermogen	Via number.zendure_manager_manual_power kun je zelf aangeven wat de batterij doet.
Slimme Matching	Constant 0 op de meter behouden.
Slim ontladen	Identiek aan Smart Matching alleen zonder opladen.
Slim opladen	Identiek aan Smart Matching alleen zonder ontladen.

Aansturingslogboek

🔋 Aansturing - zenSDK (zelfbouw) 🔋

Installatie	Github	https://github.com/Zendure/zenSDK
	Connectie	Lokaal
	Soort	Zelfbouw
Aansturing	Omvormer(s)	Geen maximum
	Type(s)	Solarflow 2400 AC en Solarflow 800 pro
	Soort	zenSDK

Informatie

Tijdens de ontwikkeling van ons vorige Device Data Report Project hebben we een sterke behoefte vastgesteld aan betere lokale controle. Als reactie hierop heeft het team het IoT-framework ZenSDK ontwikkeld

[ Voor 255% gewijzigd door gielz op 25-10-2025 14:22 ]

[gielz]

Klopt het is de mijn eigen NOM met 1 automatisering. Elke 4 seconden gaat hij starten of balanceren in de huidige modus. De NOM aansturing van Zendure was ik niet tevreden over omdat ik het liever in eigen beheer heb en lokaal. Bij het testen van de 3CT als het internet weg was deed hij ook niets meer. De restful API aansturing ziet er dan zo uit vandaag (afgerond is het, maar het is 0,06kwh);



Hij is nu geschreven voor 1 omvormer. Maar hij is in theorie eenvoudig aan te passen naar 2 of meerdere omdat bij iedere optie/uitkomst hij aan de api gaat doorgeven wat nodig is. Stel je hebt dan 2 omvormers dan heb je uiteindelijk 2 acties waarbij je bijvoorbeeld set factor = 1.00 kun aanpassen naar de helft per omvormer.

Ik zal adviseren om ze gewoon alle 3 één voor één te proberen en daarna een eigen keuze te maken; (volgorde van hoeveel werk) Zendure, Fireson en Restful API. Wil je 100% lokaal dan is de keuze beperkter.

JanHenk schreef op dinsdag 17 juni 2025 @ 13:56:
@gielz Mooi werk, is te volgen! Begrijp ik het nu goed dat je als het ware je eigen 'matching' (NOM) script hebt geschreven, dat iedere vier seconden wordt gedraaid om het vermogen van de batterij aan te passen?

Is het niet mogelijk om de NOM aansturing bij Zendure te laten en alleen te overschrijven als je 'iets anders' wil? Of werkt de NOM-aansturing van Zendure niet lokaal?

Werkt dit ook met meerdere batterijen? Of beter gezegd; omvormers?

[gielz]

Heb ik getest bij de 2400 AC met smartmode = 1. Hierbij word de ACmode niet meer in het flashgeheugen geschreven zoals Zendure heeft aangegeven. De aansturing is dan exact zoals de 3CT en P1. Fireson Integratie (las ik in deel1) en de Restful API doen dit op dezelfde manier voor NOM. Voor de Restful API heb ik dit getest daarbij werd inderdaad de ACmode niet onthouden bij het uitzetten van de omvormer.

Hoe dit bij de Hyper is heb ik geen idee van maar wat ik uit de tekst van Zendure op maak is dat dit gewoon Flash is voor de ACmode.

For the device, each time the output mode is switched, it will be written to the flash. Why is it written? It is designed to ensure that the device can maintain the last state after power failure. For the new 2025 products, you can find a property called smartMode. Once the value is 1, the ac mode setting will no longer be written to the flash, so the flash life will be much longer.
Therefore, for linkage in ct mode, smartmode will be 1, and acmode can be set repeatedly to achieve a balance in overall household energy input and output.

Met 10 jaar garantie op beide producten moet het wel goed komen verwacht ik.

geert1992 schreef op woensdag 18 juni 2025 @ 19:05:
[...]


Als ik het goed begrijp is het schrijven naar de flash nodig, zodat het apparaat verder gaat waar het gebleven is bij een onderbreking?
Kan je het dan niet testen? Een commando sturen, de ac2400 van de accu afhalen, en dan van de stroom, terug in het stopcontact en direct terug op de accu, en dan kijken wat hij doet?

[ Voor 19% gewijzigd door gielz op 18-06-2025 20:16 ]

[gielz]

Geen idee of dit binnen je eigen dashboard past maar hier gebruiken wij deze. De onderste grafiek is gemakkelijk over te nemen maar dan zonder de opkomst en ondergang lijn.

- Apexcharts
- 1 Sensor om P1 en de batterij te combineren.

avdwerf schreef op donderdag 19 juni 2025 @ 16:10:
Heb de entities aangemaakt via de ZenSDK. Werkt allemaal prima. Iemand die al een leuke fancy kaart heeft gemaakt voor op het dashboard? Ik blijf voorlopig alleen uitlezen, aansturen doe ik nog even in Zendure app zelf.

[gielz]

Hierbij de grafiek, ik heb het config-template-card gedeelte er even uitgehaald voor de zonsopkomst en ondergang. In de header heb ik 2 dagelijkse nutsmeters die ik ook elders gebruik maar die kan je eventueel ook weghalen.

Voor het P1 vermogen inclusief batterij hanteer ik de onderstaande template sensor;

code:

{{
            (states('sensor.p1_meter_power') | float +
            (states('sensor.zendure_2400_ac_vermogen') | float * -1)) | round(0)
          }}

code:

type: custom:apexcharts-card
cache: true
update_interval: 5min
stacked: true
header:
  show: true
  show_states: true
  title: ""
graph_span: 24h
span:
  start: day
series:
  - entity: sensor.zendure_2400_ac_vermogen
    name: Batterij
    group_by:
      func: avg
      duration: 15min
    type: area
    transform: return -x;
    stroke_width: 0
    opacity: 1
    extend_to: now
    color: "#f1b605"
    float_precision: 0
    yaxis_id: energy
    show:
      in_header: false
  - entity: sensor.p1_vermogen_met_batterij
    name: P1 met batterij
    group_by:
      func: avg
      duration: 15min
    type: area
    stroke_width: 0
    opacity: 1
    extend_to: now
    color: "#46474c"
    float_precision: 0
    yaxis_id: energy
    show:
      in_header: false
  - entity: sensor.zendure_2400_ac_laadpercentage
    name: Laadpercentage
    type: line
    color: "#fff"
    opacity: 0
    stroke_width: 2
    extend_to: now
    curve: straight
    group_by:
      func: min
      duration: 15min
    show:
      in_header: false
  - entity: sensor.zendure_2400_ac_import_dagelijks
    yaxis_id: header_only
    name: Vandaag (geladen)
    show:
      in_header: true
      in_chart: false
  - entity: sensor.zendure_2400_ac_export_dagelijks
    yaxis_id: header_only
    name: Vandaag (ontladen)
    show:
      in_header: true
      in_chart: false
  - entity: sensor.zendure_2400_ac_laadpercentage
    yaxis_id: header_only
    name: SOC
    show:
      in_header: true
      in_chart: false
apex_config:
  tooltip:
    x:
      format: HH:mm
      show: false
  xaxis:
    labels:
      show: false
      style:
        colors: grey
    axisTicks:
      show: false
    axisBorder:
      color: "#616269"
  yaxis:
    - title:
        text: ""
      decimalsInFloat: 0
      labels:
        style:
          colors: "#7b7c83"
  grid:
    strokeDashArray: 0
    borderColor: rgb(52,52,52)
    show: true
  chart:
    height: 270px
  legend:
    show: false
  markers:
    size: 0
    hover:
      size: 0

c0mplex1 schreef op dinsdag 24 juni 2025 @ 13:04:
@gielz Zou je de code van de onderste grafiek willen delen?
Dit bespaart om niet opnieuw het wiel te hoeven uitvinden.

[Taro]

pfwolbers schreef op dinsdag 24 juni 2025 @ 21:25:
Ik wil binnenkort zonnepanelen gaan aansluiten op de hyper. Nu heb ik de hyper via de integratie van @FireSon werkend op home assistant.
Echter hoe krijg ik de zonne opbrengst goed in het energy dashboard zonder dat dit dubbel geteld wordt?
Er is een "totaal zonne energie" maar als ik de energie gebruik welke ik heb opgewekt dan komt deze ook terug bij "totaal geleverd". Of klopt dit niet?

Je kunt hiervoor ook een Riemann helper op de DC/PV ingang waarde zetten en dat optellen. Zo heb ik het volgende overzichtje gemaakt:

[Taro]

Bra-Jo schreef op zondag 29 juni 2025 @ 12:34:
Ik had alles goed aan het draaien, dankzij een BT proxy. Nu heb ik mijn systeem uitgebreidmet een tweede Hyper en accu, en sindsdien heb ik weer freezes en moet ik Ha in zijn geheel herstarten om alles weer op de rit te krijgen. Nog niet echt onderzocht wat en hoe, doe ik binnenkort wanneer leven weer onder de 30 graden geleefd kan worden.

Wat ik me afvraag: hoe kan ik de maximale laadsnelheid begrenzen? Ivm veiligheid en C-waarde wil ik die op 500, maar krijg het niet voor elkaar. Input-limit lijkt niks te doen, maakt niet uit wat ik er instel. Ik kan het type cluster instellen, 800/1200/2400 enz. Dat lijkt ook niets te doen, heb ze nu beiden op 800 maar er wordt geladen op 900-1000. Wat doe ik verkeerd?

Wat gebruik je, de FireSon integratie of als toevoeging daarop nog de "Fake meter" variant van @Bikkelreal ?

Je kunt zowel manual charging qua limiet instellen, als smart mode begrenzen. Hier werkt het nu al weken stabiel met een combinatie van beide en 3 Hypers via local MQTT en BT.

Dus: FireSon integratie altijd op Smart Mode, een fake P1-meter maken die qua waarde verandert. En daar kan je dan het vermogen voor laden/ontladen mee sturen. Zoals je hieronder ook ziet: Een 2400AC en Hyper op 1 groep samen doen 2800 Watt, terwijl ze samen 3600 Watt zouden kunnen doen.

Hierbij zie je mooi hoe dat werkt, de fake meter is -0.1 Watt, maar er wordt op dit moment wel 7910 Watt ontladen

[ Voor 4% gewijzigd door Taro op 29-06-2025 20:35 ]

[wautah91]

Bra-Jo schreef op maandag 30 juni 2025 @ 06:46:
[...]
Misschien maar weer eens helemaal terug naar 0, zorgen dat communicatie blijft werken en da kijken wat er gebeurt met m'n aansturing.

Dat denk ik ook. Want op de manier hoe jij aanstuurt doe ik het ook. Gewoon een automation die het output limit op 270W zet 's nachts, ongeveer gelijk aan mijn sluipverbruik.




ik heb scripts aangemaakt die door de automation worden uitgevoerd.

Opladen met 1200 Watt, maar je kunt zelf de waarde kiezen.

code:

sequence:
  - action: select.select_option
    metadata: {}
    data:
      option: input
    target:
      entity_id: select.hyper2000_ac_mode
    alias: AC mode input
  - action: number.set_value
    metadata: {}
    data:
      value: "0"
    target:
      entity_id: number.hyper2000_output_limit
  - action: number.set_value
    metadata: {}
    data:
      value: "1200"
    target:
      entity_id: number.hyper2000_input_limit
  - action: select.select_option
    metadata: {}
    data:
      option: "off"
    target:
      entity_id: select.zendure_manager_operation
  - action: input_text.set_value
    metadata: {}
    data:
      value: Volle snelheid opladen
    target:
      entity_id: input_text.gekozen_accustrategie
  - action: automation.turn_off
    metadata: {}
    data:
      stop_actions: true
    target:
      entity_id: automation.handmatige_nom_2
alias: "Thuisaccu: volle snelheid opladen"
description: ""

[ Voor 60% gewijzigd door wautah91 op 30-06-2025 08:16 . Reden: plaatje toegevoegd ]

[TiBoD]

Ik heb wat zitten vibe coden en een Home Assistant integration gemaakt die de lokale API gebruikt. (Voor nu alleen reads; writes zijn nog TODO).

https://github.com/TimSoethout/home-assistant-zendure_local

Klik om via HACS te installeren:
https://my.home-assistant...ocal&category=integration

Wat vinden jullie er van? Nog doorontwikkelen? Ik weet niet of @FireSon de lokale API ook nog op de planning had staan, want dan voeg ik het liever samen natuurlijk.

[gielz]

Ik liep er hier vaak tegen aan dat je in de homewizard app niet makkelijk bijvoorbeeld even de laatste 15minuten kunt tonen met 5 seconden interval en daarbij aangeeft wat de import en export is en hoe deze aansluit op het huisvermogen (grijs gekleurd). Ik gebruik daarom nu de onderstaande Home Assistant apexchart.

Zijn hier nog andere tweakers met mooie dashboards om inspiratie op te doen?

[avdwerf]

Iemand dit dit voor me kan verduidelijken. Ik heb 2 (of eigenlijk 4, hetzelfde voor ontladen) waardes waartussen ik het verschil niet weet. Werk met de ZenSDK uit de openingspost.
Uit de json properties
inputLimit -> Zendure_2400_AC_Ingesteld_Oplaadvermogen



En
outputPackPower -> Vermogen (opladen)


Zou verwachten dat die laatste het actuele vermogen toont en die eerst een vaste waarde is, maar beiden veranderen tijdens het opladen zoals te zien in de screenshots.

[gielz]

Bij grafiek 1 geef je aan via de restapi wat je wilt dat hij gaat laden. Vervolgens bij grafiek 2 wat hij daadwerkelijk van dit laden overneemt en met een cap van 2400 watt.

Lijkt mij op zich duidelijk omdat het ingesteld oplaadvermogen variabel is (grafiek 1) gaat de batterij ook variabel opladen (grafiek 2)

avdwerf schreef op vrijdag 4 juli 2025 @ 09:54:
Iemand dit dit voor me kan verduidelijken. Ik heb 2 (of eigenlijk 4, hetzelfde voor ontladen) waardes waartussen ik het verschil niet weet. Werk met de ZenSDK uit de openingspost.
Uit de json properties
inputLimit -> Zendure_2400_AC_Ingesteld_Oplaadvermogen

[Afbeelding]

En
outputPackPower -> Vermogen (opladen)
[Afbeelding]

Zou verwachten dat die laatste het actuele vermogen toont en die eerst een vaste waarde is, maar beiden veranderen tijdens het opladen zoals te zien in de screenshots.

[ Voor 20% gewijzigd door gielz op 04-07-2025 10:17 ]

[gielz]

Voor de gene die nu een energy socket gebruiken en naar iets anders willen voor metingen buiten een KWH meter om. Ik ben nu de Shelly PM Mini Gen3 aan het testen;

https://www.bol.com/nl/nl...hAhA.4_13.14.ProductImage

code:

  - resource: http://192.168.0.227/rpc/PM1.GetStatus?id=0   # IP-adres van je Shelly PM Mini Gen3 voor API
    scan_interval: 1
    sensor:
      - name: "Shelly Zendure 2400 AC Vermogen Aansturing API"
        value_template: "{{ value_json.apower | float }}"
        unique_id: Shelly_Zendure_2400_AC_Vermogen_Aansturing_API
        unit_of_measurement: "W"
        device_class: power

[gielz]

Was ik ook benieuwd naar, en ja dat doet hij. Alleen voor de KWH import data heb je alleen een import+export en export. De import moet je even oplossen met een simpele template sensor.




Heb nu alles omgebouwd en zal deze week het doortesten.

Dolf_Tweakers schreef op zaterdag 5 juli 2025 @ 09:58:
[...]


Meet die bi-directioneel?

[gielz]

Dat was ook eerst hier het idee, waarom niet op een 4 seconden interval. Maar wanneer hij om de 4 seconden gaat kijken wat er moet gebeuren dan kan het zijn dat de P1 net nog zijn data moet verversen en je dus met oude data gaat werken. Hier ziet het er trouwens nu zo uit (laatste 30 minuten), dik tevreden;

*Batterij vermogen is omgedraaid in het dashboard - is laden + ontladen om gelijk te lopen met de P1.


De overige sensoren meer uitlezen doe ik zelf voorlopig niet omdat de batterij dan zal bevriezen. Dit is standaard 15 seconden bij de overige sensoren. Ik heb nog wel een vraag open staan wat de rate limiter is van de API.

Mocht je zelf tot iets komen wat beter werkt in de praktijk deel het vooral hier!

c0mplex1 schreef op zaterdag 5 juli 2025 @ 13:47:
@gielz Ik heb wat vragen betreffende de timing van de automatisering en hardware.

Dat je om de 4 seconden de automatisering (Zendure NOM 1.00) start snap ik, want bij een kortere tijd bevriest de 2400AC en bij een langere tijd gaat de automatisering te ver uit de pas lopen.

Maar waarom lees je (met REST) de 2400AC om de 30 seconden uit en niet om de 4 seconden, want als je geen scan_interval definieer is de interval tijd standaard 30 sec.
Moet dit dan ook niet eens in de 4 seconden zijn, dus gelijk aan de automatisering?

Waarom lees je de HWE-P1 en HWE-SKT iedere seconde uit en niet eens in de 4 seconden.
Je gooit 3 samples weg, die gebruik je toch niet, omdat de automatiseering er niets mee doet, want die werkt maar 1x per 4 seconden. Dus ook hier de HWE-P1 en HWE-SKT 1x per 4 seconden uitlezen lijkt mij logischer.

[Taro]

@Aziraphale Welke Nord Pool sensor je hebt hangt af van of je deze bijv. incl. of excl. BTW hebt aangemaakt. Heb je een andere dan kan je die prima gebruiken.

Als je mijn code hergebruikt heb je veel sensoren/entiteiten die inderdaad niet bekend zijn. Maar, als dat aangepast/hersteld is ziet het er in de WYSIWIG editor zo uit (2 bovenste delen, de rest herhaalt dit principe):




Waarbij dan de IF checkt in de 1e stap op:


En voor de 2e stap op:


Hopelijk helpt dat in het begrijpelijk maken?

[Taro]

Aziraphale schreef op maandag 7 juli 2025 @ 10:02:
@Taro Ik ben er mee aan het stoeien en begin het wat te doorgronden (en ik zal het aan de gang krijgen, al is het alleen maar om het te snappen ), maar ik vroeg me nog wel af wat het verschil is tussen de manier via HA en de Electricity Price Mode in HEMS. Komt die twee niet eigenlijk op hetzelfde neer?

Mijn automatisering vs HEMS bedoel je?

Heb 5 knoppen (booleans) gemaakt die te combineren zijn:

• Onder de 20 cent laden
• Goedkoopste 5 uren laden (op zondag: 6 ivm 100%)
• Duur ontladen
• EV laden uit de accu's
• NOM

En mijn automatisering houdt daar dan rekening mee. Bijv.:

• 5 duurste uren onder de 35 cent: Gemiddeld ontladen
• 5 duurste uren boven de 35 cent: Maximaal ontladen
• 5 goedkoopste uren: Maximaal laden
• Onder de 20 cent, maar niet de goedkoopste uren: Smart charging
• Boven de 20 cent, maar niet de duurste uren: Smart discharging
• Anders: NOM.

Waarbij 5 duurste uren betekent: 3 duurste in de avond en 2 duurste in de ochtend. Gemiddeld gezien zijn dat de duurste 5 van de dag én je zorgt ervoor dat je accu's de rest van de tijd voldoende kWh's hebben voor NOM én dat ze volledig leeg zijn voordat het laden begint.

Vandaag einde ochtend duur ontladen uitgezet, goedkoop inkopen uit, onder de 20 cent laden aan en draait nu NOM t/m morgen 13:00 als er weer een paar uur geladen gaat worden.


Paar dagen gelezen had ik wel goedkoop inkopen en duur ontladen aan (Y-as begint bij -7000 Watt):


Dus nee, niet (exact) hetzelfde als HEMS. Heb Zendure wel uitgebreide feedback gegeven over HEMS, dus hopelijk is dit spoedig ook native mogelijk

[gielz]

Sinds een week nu de Shelly PM Mini Gen3 ingebouwde energiemeter in plaats van de HW Energysocket. Ik zie nu vooral dat deze nauwkeuriger is dan de HW Energysocket. NOM via de Restful API in combinatie met Zendure NOM 1.00 automatisering werkt echt helemaal prima.


*800 watt laden/ontladen op één ab3000x.

Het enigste wat ik heb gedaan de afgelopen maand (deels HW Energysocket, deels Shelly PM Mini Gen3) is af en toe autistisch naar HA gekeken hoe het loopt.

Dat was eigenlijk ook het doel, niets doen met maximaal effect. En bij problemen in de aansturing het direct zelf kunnen oplossen. (nog niet nodig geweest)

[avdwerf]

Ik wilde ook gaan beginnen met de automatisering in HA maar krijg de cheapest hours niet werkend. Zou niet zo spannend moeten zijn lijkt me. Heb 2 entries in de config

code:

aio_energy_management:
    cheapest_hours:
      - nordpool_entity: sensor.nordpool_kwh_nl_eur_3_10_021
        unique_id: aio_cheapest_hours
        name: AIO Cheapest Hours
        first_hour: 0
        last_hour: 23
        starting_today: true
        number_of_hours: 5
        sequential: false
      - nordpool_entity: sensor.nordpool_kwh_nl_eur_3_10_021
        unique_id: aio_expensive_hours
        name: AIO Expensive Hours
        first_hour: 0
        last_hour: 23
        starting_today: true
        number_of_hours: 5
        sequential: false
        inversed: true

De nordpool sensor bevat gewoon de prijzen


Maar zowel cheapest als expensive blijven de hele dag op uit staan. Iemand een idee?

[DJN]

gielz schreef op zaterdag 5 juli 2025 @ 14:22:
Dat was ook eerst hier het idee, waarom niet op een 4 seconden interval. Maar wanneer hij om de 4 seconden gaat kijken wat er moet gebeuren dan kan het zijn dat de P1 net nog zijn data moet verversen en je dus met oude data gaat werken. Hier ziet het er trouwens nu zo uit (laatste 30 minuten), dik tevreden;

*Batterij vermogen is omgedraaid in het dashboard - is laden + ontladen om gelijk te lopen met de P1.
[Afbeelding]

De overige sensoren meer uitlezen doe ik zelf voorlopig niet omdat de batterij dan zal bevriezen. Dit is standaard 15 seconden bij de overige sensoren. Ik heb nog wel een vraag open staan wat de rate limiter is van de API.

Mocht je zelf tot iets komen wat beter werkt in de praktijk deel het vooral hier!


[...]

Ik heb deze gemaakt. Iemand anders nog interessante charts?

[Hieke]

@gielz Heb de smartmeter werkend in HA. Maak daarbij gebruik van DSMR Reader.

Is er dan nog een Zendure P1 meter of Zendure 3CT vereist om jouw applicatie te gebruiken voor NOM bij het gebruik van een 2400 AC? Al 75 dagen in afwachting daarvan.



En tweede vraag: blijft alle data zo lokaal dat je geen informatie meer kunt teruglezen in de Zendure-app op de smartphone?? Dat zou toch wel handig zijn als je buitenshuis bent en de boel wil volgen.

[ Voor 9% gewijzigd door Hieke op 14-07-2025 20:15 ]

[gielz]

Tijgerkracht schreef op donderdag 17 juli 2025 @ 09:21:
[...]


Jij hebt geen Quooker...

Wellicht in de toekomst wel maar hoe ziet de grafiek met een Quooker er uit? Hier heb ik alleen piekjes van 20 watt in de nacht die makkelijk op te vangen zijn. (180 watt gemiddeld sluipverbruik)

Ik gebruik deze grafiek om te kijken waar nog wat imports te hamsteren zijn;

[Tijgerkracht]

gielz schreef op donderdag 17 juli 2025 @ 09:30:
[...]


Wellicht in de toekomst wel maar hoe ziet de grafiek met een Quooker er uit? Hier heb ik alleen piekjes van 20 watt in de nacht die makkelijk op te vangen zijn. (180 watt gemiddeld sluipverbruik)

Ik gebruik deze grafiek om te kijken waar nog wat imports te hamsteren zijn;

[Afbeelding]

Heel veel korte spikes van 10-30 seconden....

[mrme12345]

Tijgerkracht schreef op donderdag 17 juli 2025 @ 09:34:
[...]


Heel veel korte spikes van 10-30 seconden....

[Afbeelding]

Ja wat dat betreft is een quooker een drama voor NOM, maar per saldo stelt het nog niet veel voor. Ik zit nu per saldo snachts tussen 00.00 en 07.00 op 0,05 kWh. Maar wat wel grotendeels door de quooker komt. En daar reageert de NOM dan weer (te laat) op, dus inderdaad spikes beide kanten op.

[Hieke]

Hèhè, eindelijk de 2400 AC na 79 dagen binnen!
Ziet er inderdaad wel leuk uit.
Configureren van de app met wifi en laden/ontladen via smartphone wijst zichzelf.

In de app wordt ook het door router toegewezen IP-address getoond.
Ik wil graag NOM met de Restful API zenSDK (lokaal) en daartoe getracht de handleiding in startpost uit te voeren.
Eerste stap in DOS-box curl -X GET "http://192.168.1.177/properties/report" gaat conform verwachting.

Sensoren aanmaken wordt al iets lastiger.. Ik heb namelijk geen Homewizard P1 en ook geen HW energy socket...

Laat ik beginnen met de vraag hoe ik de NOM kan realiseren.. Ik zie die waarde van de P1-meter tenslotte al in HA.
Hoe krijg ik die data verwerkt in de RESTfull api? Nu kan ik de installatie alleen handmatig bedienen..

[ Voor 64% gewijzigd door Hieke op 17-07-2025 16:36 ]

[Hieke]

gielz schreef op donderdag 17 juli 2025 @ 16:44:
[...]


Dan ben je er al bijna. Ik zou dan de configuration.yaml gebruiken zonder de P1 regel en dat werkend krijgen (data zien in HA). Hierna zit je alleen nog met je vermogen van je batterij, hoe wil je dat gaan oplossen? Via de Restful API kun je namelijk niet elke seconden het vermogen gaan opvragen zonder dat je mogelijk een freeze krijgt.

Zie je alle gegevens binnen komen dan is het alleen nog de dropdown maken en de automatisering even voorzien van je afwijkende sensoren.

Er bijna zijn is een kwestie van beleving..

Voor jouw duidelijkheid: Ik zie de historie van de verschillende Entiteiten wel als ik daar via Settings, Entities, Temperatuur op klik.

Maar ik weet niet hoe ik onderstaand totaaloverzicht kan opvragen zoals in je werkinstructie getoond wordt. Hoe krijg ik dat voor elkaar. Zie nergens mogelijkheid: Add to Dashboard.


Je merkt wel: geen ervaring met HA..

Hopelijk komen we er samen uit. Volgende stap wordt dan data P1-meter in configuratie opnemen.

Alvast dank.

[gielz]

Hieke schreef op donderdag 17 juli 2025 @ 17:05:
[...]

Er bijna zijn is een kwestie van beleving..

Voor jouw duidelijkheid: Ik zie de historie van de verschillende Entiteiten wel als ik daar via Settings, Entities, Temperatuur op klik.
[Afbeelding]
Maar ik weet niet hoe ik onderstaand totaaloverzicht kan opvragen zoals in je werkinstructie getoond wordt. Hoe krijg ik dat voor elkaar. Zie nergens mogelijkheid: Add to Dashboard.

[Afbeelding]
Je merkt wel: geen ervaring met HA..

Hopelijk komen we er samen uit. Volgende stap wordt dan data P1-meter in configuratie opnemen.

Alvast dank.

De entiteiten kun je makkelijk tonen via het dashboard via de standaard toe te voegen tegel;


Maar dit staat los van de werken van zenSDK, dit is meer je opmaak van je Home Assistant dashboard.

[gielz]

dennisdew16 schreef op donderdag 17 juli 2025 @ 19:41:
Ik ben sinds vanmiddag ook eindelijk bezitter van een 2400AC met twee batterijen Nu gebruik ik al een aantal uur de NOM automatisering van @gielz en die werkt voor 99% goed.
Nu is er in mijn geval een "bug" dat als ik alles stop en dus op standby zet dat mijn HW kWh meter een verbruik van -25 aangeeft. Dit zorgt er dan weer voor dat er geen enkele automatisering start. Zelfde gebeurd als de accu eerst gaat laden en dan moet ontladen. Dan komt ie ook in een "loop" terecht. De manier om dit op te lossen is door in de zendure app 100 watt in te stellen als laden/ontladen en dan pakt ie alles weer op. Iemand die soort gelijk gedrag heeft (gehad)?

Dit exacte probleem heb ik ook sinds ik ze uit de doos heb gehaald. Dit lijkt vergelijkbaar bij de HW batterij waar hij in een soort standby modus blijft draaien in die stand. Binnen de huidige NOM versie houd hij hier rekening mee en pakt hij het automatisch weer op zodra ontladen of laden nodig is. Bij optie 2 en 4 in de automatisering is hier een instelling voor.





PM mij anders even als het niet lukt.

[ Voor 17% gewijzigd door gielz op 17-07-2025 19:51 ]

[gielz]

TCMR schreef op vrijdag 18 juli 2025 @ 08:32:
[...]

Het gaat niet om de interval. Ik wist het ook nooit, maar CT-klem-based meters schijnen toch iets af te kunnen wijken van wat je slimme meter zelf aangeeft. De hoogste nauwkeurigheid komt uit je P1-poort. Hoeveel het afwijkt? Ik zou het niet kunnen zeggen. Zou mooi zijn om eens te meten...

Hier de verschillen, en dit was nog met een P1 interval van 10-15 seconden.

[gielz]

DaLass schreef op vrijdag 18 juli 2025 @ 08:42:
[...]

Is dat ook van toepassing op de Hypers via de Fireson integratie? Die heb ik nu zonder een extra plug draaien, dus ben wel benieuwd of het "strakker" kan met een extra meting ertussen.

Is het uberhaupt mogelijk om te testen? Ik geloof dat de Fireson alleen de P1 instelbaar heeft. Hoe ziet een 30 minuten lijn er nu uit op de P1 met Fireson?

Hier is het nu zo (zit een oplaadbuffer in, grijze gedeelte)

[Hieke]

gielz schreef op donderdag 17 juli 2025 @ 22:50:
[...]


Die 3CT werkt ook via REST maar is niet 100% nauwkeurig. Denk dat voor nu de simpelste oplossing is om een HW Energysocket te plaatsen bij de batterij want de P1 data heb je ook al per seconden.

Het is niet zo'n klus om de 3CT-meter in te bouwen of een P1-meter en socket van HW aan te schaffen. Maar in het eerste geval blijf ik toch met vraag van de juiste syntax in de configuration.yaml zitten..

Daar komt bij dat ik in HA via een helper (sensor template) met deze inhoud het actueel vermogen reeds beschikbaar heb.



En dit is jouw code in configuration.yaml

code:

  - resource: http://<IP-HOMEWIZARD-P1>/api/v1/data   # IP-adres van je P1 voor V1 API
    scan_interval: 1
    sensor:
      - name: "P1 Zendure Aansturing API v1"
        value_template: "{{ value_json.active_power_w | float }}"
        unique_id: P1_Zendure_Aansturing_API_V1
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

  - resource: http://<IP-HOMEWIZARD-ENERGYSOCKET>/api/v1/data   # IP-adres van je energysocket voor V1 API
    scan_interval: 1
    sensor:
      - name: "Zendure 2400 AC Vermogen Aansturing API v1"
        value_template: "{{ value_json.active_power_w | float }}"
        unique_id: Zendure_2400_AC_Vermogen_Aansturing_API_V1
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

Kun je me met bovenstaande informatie helpen bij het aanpassen van de configuration.yaml om het actueel vermogen van de slimme meter in de applicatie beschikbaar te maken?
Dat bespaart me een extra P1-meter in de meterkast.

Of denk ik helemaal verkeerd?

[Hieke]

Dank je voor je effort. Maar helaas schiet mijn kennis van scripting nog tekort. Met hulp en vallen en opstaan hoop ik er te komen.

Ik heb in de Helper de roundfunctie naar 0 gezet.

code:

{% set import = states('sensor.dsmr_reading_electricity_currently_delivered') | float %}
{% set export = states('sensor.dsmr_reading_electricity_currently_returned') | float %}
{{ (import - export) *1000| round(0) }}

Maar dan ga ik al de mist in..

Wat wordt in configuration.yaml de syntax voor de resource? Ik wil de waarde uit de Helper gebruiken toch?

Krijg ook meteen een foutmelding omdat je schrijft:

In de configuration.yaml kun je de P1 meter regel verwijderen.

[Hieke]

Beginners foutjes zie ik.

Die zullen vast nog meer volgen Dank voor je begrip.

Dit is de helper met entiteit:


Heb nu via Instellingen, Automatiseringen, Zendure NOM 1.00 in het script de entiteit aangepast.

Voor de zekerheid hierbij een stukje van het script Zendure NOM 1.00 zoals in regel 19:


De HW Energy socket zojuist besteld. . Morgen kijken of het allemaal werkt.
Of kan ik nu al een beeld krijgen of mijn aanpassingen correct zijn?

[ Voor 15% gewijzigd door Hieke op 18-07-2025 10:47 ]

[Hieke]

gielz schreef op vrijdag 18 juli 2025 @ 13:11:
[...]


Ik zou voor nu even wachten tot je compleet bent. Je kunt wel als je de selectielijst + automatisering hebt toegevoegd hem handmatig laden en ontladen. Dan weet je iig dat de batterij werkt.

Dat advies heb ik afgelopen tijd vaker gelezen; toen ik herhaaldelijk informeerde naar de status van levering van de 2400 AC. Dank voor uw geduld was dan de afsluitende phrase.. Inmiddels aardig getraind daarin. Volgens HW komt morgen mijn energy socket binnen.

Automatiseringen werken.
Ondertussen klik ik wat rond in HA. Dashboard wordt al beter. Vraag me af wat de bovenste instelling Pas Zendure 200 AC modus aan voor functie heeft.


Veel dank zover.

[Hieke]

dennisdew16 schreef op vrijdag 18 juli 2025 @ 16:22:
[...]

Volgens mij bedoel je de rest api commando's. Dit werkt out of the box met de NOM automatisering maar dan moet je nog even een dag wachten op je energ socket denk ik.

Inderdaad bedoel ik die, denk ik.
Ik zie in het pull-down menu onder Modus selecter helaas maar 6 commando's..


Ik mis Restful commando's die zichtbaar zijn bij Developer Tools, Actions. zoals Zendure_X_laden.
Ik heb wel gezien dat ik die in configuration,yaml nog wat nader moet definiëren.

Jij een idee hoe ik die 4 commando's in het pulldown-menu toegevoegd krijg? Het is een Helper, die ik ook kan bewerken. In de Startpagina van dit draadje staat dat ik ze één op één over moet nemen. Als een aapje uitgevoerd. Maar ik mis de achtergrondkennis om er zelf nog acties aan toe te voegen..

Ik zie geen relatie met Rest-commands in de configuration.yaml en Helper..

Het is allemaal erg out of the box. Ik streef inderdaad naar NOM. Maar wil HA ook een beetje naar mijn hand kunnen zetten.

[gielz]

Voor iemand die de 2400 AC RTE test uitvoert heb ik een handmatige optie gemaakt. Deze zou je in een normale situatie niet gebruiken denk ik omdat je voor dynamisch zelf aparte vermogen rest commands aanmaakt en als je gewoon lekker wilt NOMen gebruik je deze ook niet.

- 2 nieuwe rest commands die altijd in het RAM geheugen schrijven
- 1 helper met vermogen
- 1 automatisering

[Hieke]

gielz schreef op vrijdag 18 juli 2025 @ 22:49:

Startpost aanpassingen

Restful API zenSDK

2025-07-19 ❤︎ NEW - Modus handmatig is toegevoegd Wil je deze gebruiken in een bestaande configuratie dan zal je het volgende moeten doen wat in de TS beschreven staat; Extra modus toevoegen aan de keuzelijst, 1 helper toevoegen voor het handmatige vermogen, handmatige automatisering toevoegen, modus automatisering vervangen. Dit heeft geen invloed op de bestaande configuratie zoals de NOM.

Dank je voor je aanvulling. Maar helaas werkt Restful nog niet volledig. Hopelijk kun je me als beginner van HA de laatste hints geven?

Even een korte schets:
Vanochtend firmware van de 2400 AC geupgrade van V1.0.1 naar V1.0.4.
De 2400 AC is momenteel volledig opgeladen en staat in Standby.
HomeWizard Energy Socket geplaatst, geconfigureerd in de app, local api aangezet, IP-adres toegevoegd in configuration.yaml van HA.
In configuration.yaml je code m.b.t handmatig ontladen 250 W toegevoegd en settings aangepast.
Extra modus toegevoegd aan keuzelijst via Instellingen, Apparaten, Restful, Helpers, ACmodus selecteren en de optie toegevoegd.

Had nu de hoop dat ik NOM kon gaan draaien.
Maar accu's zijn bijna vol (99%) en zonopwek is overvloedig.
Dus dacht: ik kies voor ontladen op 2400 Watt. Maar dat blijkt nog niet goed (menugestuurd) te werken...

Als ik via Ontwikkelhulpmiddelen, Acties de commando's zoals Zendure_ontladen_250 geef.gaat het naar verwachting.
Bij Zendure 200 AC Modus Selecteren, keuze NOM echter gaat ie ontladen, in plaats van opladen. Terwijl actueel vermogen, opwek volgens P1-meter >4700 is..
Ook krijg ik bij keuze Standby ook geen response.. Hij blijft ontladen.

We zijn er dus bijna...
Maar ik moet bekennen dat je laatste berichtje voor mij iets te weinig concreet was om mee uit de voeten te kunnen. Met name de laatste aanwijzingen: Handmatige automatisering toevoegen, wat is de inhoud? Modus automatisering vervangen.. Waar c.q. hoe doe ik dat?



Met dank

[ Voor 12% gewijzigd door Hieke op 19-07-2025 16:24 . Reden: Screenshot toegevoegd ]

[TCMR]

gielz schreef op donderdag 17 juli 2025 @ 22:52:
[...]
De energysocket is voor het uitlezen van het vermogen van de batterij.

Oké, na het hele topic doorgelezen te hebben snap ik nu waarom: te vaak de API van de accu uitlezen kan leiden tot freezes. Vandaar jouw workaround via een alternatief meet-device. Jammer, want "outputHomePower" zou prima geschikt zijn.

Ik heb je oplossing draaiend, zoals ik schreef: een stuk eleganter zo, via de API. Hij trekt wel meer energie uit het net dan Firesons integratie. Die ging juist een beetje de andere kant op (duwde meer terug). Uiteindelijk is het allemaal marginaal, maar goed, je wilt het zo strak mogelijk hebben, dat is toch een beetje de sport

[gielz]

TCMR schreef op zaterdag 19 juli 2025 @ 22:39:
[...]

Oké, na het hele topic doorgelezen te hebben snap ik nu waarom: te vaak de API van de accu uitlezen kan leiden tot freezes. Vandaar jouw workaround via een alternatief meet-device. Jammer, want "outputHomePower" zou prima geschikt zijn.

Ik heb je oplossing draaiend, zoals ik schreef: een stuk eleganter zo, via de API. Hij trekt wel meer energie uit het net dan Firesons integratie. Die ging juist een beetje de andere kant op (duwde meer terug). Uiteindelijk is het allemaal marginaal, maar goed, je wilt het zo strak mogelijk hebben, dat is toch een beetje de sport

[Afbeelding]

Je zou met de offset dit strakker kunnen inregelen verwacht ik. Ziet er hier zo uit;


Zelf kijk ik nooit naar de NU weergave maar eerder naar mijn "Helaas Pindakaas" chart om te bepalen waar nog wat te halen valt;

code:

type: custom:apexcharts-card
cache: true
stacked: true
update_interval: 5sec
span:
  start: day
header:
  show: true
  show_states: true
  title: Helaas pindakaas
graph_span: 1d
series:
  - entity: sensor.p1_meter_energy_import
    name: Helaas pindakaas
    group_by:
      func: diff
      duration: 1h
    type: column
    stroke_width: 0
    opacity: 1
    extend_to: now
    color: "#f1b605"
    float_precision: 5
    yaxis_id: energy
    show:
      in_header: false
  - entity: sensor.p1_meter_energy_import
    yaxis_id: header_only
    name: Vandaag (import)
    float_precision: 3
    statistics:
      period: day
      type: change
      align: start
    show:
      legend_value: true
      in_header: true
      in_chart: false
apex_config:
  toolbar:
    show: true
    tools:
      download: true
      selection: true
      zoom: true
      zoomin: true
      zoomout: true
      pan: true
  tooltip:
    x:
      format: HH:mm:ss
      show: false
  xaxis:
    labels:
      show: false
      style:
        colors: grey
    axisTicks:
      show: false
    axisBorder:
      color: "#616269"
  yaxis:
    - title:
        text: ""
      decimalsInFloat: 3
      labels:
        style:
          colors: "#7b7c83"
  grid:
    strokeDashArray: 0
    borderColor: rgb(52,52,52)
    show: true
  chart:
    height: 270px
  legend:
    show: false
  markers:
    size: 0
    hover:
      size: 0

[gielz]

TCMR schreef op zaterdag 19 juli 2025 @ 22:59:
[...]

Ja hé, die feature zat er vanochtend nog niet in! In dit tempo loop ik altijd achter

Thanks, ik ga morgen de configuratie updaten.

In de NOM sinds de start van de TS heb je bij het laden en ontladen een correctie optie in de laatste stap (uitvoeren van het command). Onderstaande is de instelling nu hier. 20 watt minder meenemen bij het ontladen en 40 watt minder gaan laden dan mogelijk. Pas je de waarde aan en sla je de NOM op dan zal hij direct na 4 seconden daar gebruik van maken.

ONTLADEN {% set correctie = 20 %}
LADEN {% set correctie_export = 40 %}

Daarmee kun je dus makkelijk zelf je ideale NOM bepalen zonder extreme aanpassingen te doen.

*Laadgedrag aanpassing

[gielz]

Hieke schreef op zondag 20 juli 2025 @ 10:16:
@gielz Opnieuw dank voor het delen van je applicatie en support daarop!

Vanochtend, de eerste nacht met NOM als resultaat:
9 Watt afname van grid
145 Watt teruglevering aan grid

Een fantastische score, boven verwachting. Heel blij mee!

Uit de 4 accu's was ik van 90% naar 58% teruggezakt. Dat was iets meer verlies dan ik had ingeschat.

Die capaciteit moest dus weer gevuld worden.
Echter:
Toen de pv-productie op gang kwam ging de 2400 AC naar Standby.. In HA stond netjes NOM ingesteld..

Wat kan daar de oorzaak van zijn? Een instelling in de Zendure app op smartphone verwacht ik niet. Jouw applicatie is toch de baas? Hems staat uit.

Ik kan het even niet verzinnen. Jij suggesties?

Hij gaat iig niet ontladen dat is al een pluspunt.

Wat je kunt doen is even de automatisering NOM openen. En dan Tracering weergeven rechtsboven aanklikken. Als je dit even deelt (of wellicht zie je het zelf dan al). Hier zie je namelijk exact welke afslag hij neemt en waarom;

*Hier zie je dus 800 naar de 2400 AC. (ja, helaas nog maar 1 batterij dus op 800 watt)

[Hieke]

Ik heb daar niet veel staan...

Voor de zekerheid NOM aangezet in Drop-down-menu, want ik had handmatig laden op 2400 W ingeschakeld, en HA herstart..



Merkwaardig dat ie daar wel in de nacht mee kan NOMmen.

[gielz]

tweetyvogel schreef op zondag 20 juli 2025 @ 13:44:
@Taro en @gielz

Vraagje voor beide hoofdfrobeldozen,

Ik maak gebruik van de API aansturing met gebruik van de yaml's van Gielz.
Deze week alles binnen gekomen de SF2400AC en een 3tal accu's, voor zover ik kan zien werkt alles naar behoren, echter zit ik met het verhaal van de accu kalibratie.
Als ik rechtstreeks via "Gielz" menu het onderdeel "Opladen met 2400 watt" start begint de omvormer te laden tot de ingestelde 100% en dan stopt het laadproces.
Ondertussen is de SOC status op "goed" en deze gaat nergens naar "Kalibreren" binnen de app staat de SF2400AC op "standby".
Mijn vraag is simpel wanneer is kalibreren klaar en kan ik de optie NOM weer inschakelen.

Zolang jij hem op NOM laat draaien en hij gaat wekelijks naar 100% dan is er niets aan de hand. Wanneer hij vervolgens langdurig niet op 100% komt zal hij zelf gaan kalibreren. (in de winter bijvoorbeeld).

Taro wilt dit zelf in de hand hebben. Hij zegt dat hij tot maximaal 98% mag opladen standaard en 1x in de zoveel tijd tot 100%.

Wil je het gewoon simpel houden dan zou ik nu gewoon lekker NOMen en in de winter kijk je weer verder.

[ Voor 6% gewijzigd door gielz op 20-07-2025 14:09 ]

[Hieke]

gielz schreef op zondag 20 juli 2025 @ 10:40:
[...]


Ja dat komt omdat het ontladen andere afslagen zijn. Dat gaat dus prima, er is nu overschot dus die afslag zal hij niet nemen. Optie 4 heeft dus in eerste instantie problemen en dat zal ook zo zijn in optie 5.

- Controleer de kopjes binnen deze opties, niet de instelling maar de desbetreffende sensor
- Toch weer een afwijkende sensor ergens die niet in de TS genoemd staat

Als het werkt stuur ik je wel een tikkie

Ik had inderdaad één sensornaam over het hoofd gezien bij vervangen in het script Zendure NOM 1.00 bij de laatste sequence. Excuses

code:

          - data:
              inputLimit: >-
                {% set factor = 1.00 %} {% set cap = 2400 %} {% set
                correctie_export = 80 %}

                {% set p1 = states('sensor.p1_actueel_vermogen') |
                float(0) %} {% set zendure =
                states('sensor.zendure_2400_ac_vermogen_aansturing_api_v1') |
                float(0) %}

                {% set verschil = zendure - p1 - correctie_export %} {% set
                beperkt = verschil if verschil > 0 else 0 %} {% set beperkt =
                beperkt if beperkt < cap else cap %}

                {{ beperkt | int }}
            action: rest_command.zendure_x_laden_balanceren
            enabled: true
        alias: >-
          Tijdens opladen balanceren naar -80 watt (alleen tussen 2u na ☀︎ en 1u
          voor ☾) (100% van aanbod)

Alleen geen idee of dit stukje script gerelateerd is aan het opladen bij een pv-overschot. Gaan we morgen zien. Hij staat nu weer aardig te NOMmen.

Moet wel bekennen dat ik steile leercurve ervaar.. Maar een hele mooie case om me in te verdiepen in HA.

Mag ik langs deze weg dan misschien nog een vraag stellen m.b.t. tracering?
Je en de grafiek spreken over 5 acties. Maar ik tel 11 RESTful commands. Deze worden gebruikt in de Zendure 2400 AC Modus Aan (drop-down) menu alsmede in de NOM 1.00 automatisering.

Die gele lijn correspondeert mijns inziens met mijn actieve keuze NOM, maar ik zie in de naastgelegen route een rest_commando dat ik verwachtte. Hopelijk kan ik hier wat meer inzicht krijgen?

[TCMR]

gielz schreef op zondag 20 juli 2025 @ 09:48:
[...]
In de NOM sinds de start van de TS heb je bij het laden en ontladen een correctie optie in de laatste stap (uitvoeren van het command).

Ja, ik zie het. Ik was even in de war met "Modus handmatig" die je hebt toegevoegd gister, want ik zag dat de YAML heel anders eindigde. Maar dat was van de configuration.yaml, niet de automatisering.

Heb nu een correctie van 0, en krijg echt een mooi resultaat:

[pieterh78]

Sinds afgelopen vrijdag ook de trotse bezitter van een 2400AC met 2x AB3000X. HW Energy Socket besteld en aan de slag gegaan met de ZenSDK in HA van @gielz. Deze draaide vrij snel dankzij de duidelijke instructies en een beetje hulp van Google 😊. Ik heb de batterij ingesteld op max 1200 watt laden en ontladen. De NOM gaat nog niet helemaal zoals ik wil. Er wordt te veel teruggeleverd in mijn ogen.



Hoe zou dit kunnen komen?

Ik heb de scripts letterlijk overgenomen en alle namen hetzelfde gehouden.

[pieterh78]

dennisdew16 schreef op maandag 21 juli 2025 @ 09:59:
@pieterh78 Wat is je teruggeleverde energie afgelopen nacht? En je kan inderdaad een offset aanpassen maar dat hangt helemaal af van wat je huidige export snachts is.

Bedoel je de export van de Energy Socket?

[gielz]

@pieterh78 Er gaat iets niet goed in je configuratie. Want er is inderdaad een offset beschikbaar maar dan hebben wij het over afwijkingen van 0-30 watt. En niet -445 watt

Controleer als eerste je P1 en de Energysocket, zijn ze per seconden en hebben ze überhaupt data en staan ze goed in je NOM automatisering. (vervangen via kladblok, als het afwijkende sensoren zijn).

Zou er zo uit moeten zien;

[ Voor 43% gewijzigd door gielz op 21-07-2025 10:56 ]

[Devke]

Deze dus :

[gielz]

martinvdm schreef op dinsdag 22 juli 2025 @ 20:17:
@gielz prachtig topic, mooi topicstart.
Je code is gebaseerd op Homewizard p1 api?
Kan dit ook met de p1 meter van Zendure zelf? Of wellicht heb je dit al werkend. Deze wordt afgelopen tijd veelvuldig uitgeleverd door Zendure en ik meen dat @Taro een test ermee heeft gedaan.

Waarom zou je met Zendure NOM 1.0 code handmatig een automation maken om te ontladen bij bepaald verbruik? Dat doet de Zendure toch zelf aan de hand van de p1 info?
Of mis ik iets.

Heb je wellicht ook de tank van je mooie dashboard grafiek?

De standaard werking is gebaseerd op de P1 van Homewizard. Maar dit kan eigenlijk met alles werken zolang je de P1 data / CT klem data per seconden kunt uitlezen in Home Assistant. Met de Zendure CT en P1, Ecotracker, Shelly, KWH meter kan het ook. Ook niet onbelangrijk is dat je aan de batterij kant ook moet meten. De batterij zelf heeft een 3-4% afwijking op zijn eigen vermogen.

De handmatige vermogen automatisering is optioneel. Deze had ik specifiek voor @Devke gemaakt om de mogelijkheid te hebben om het optimale RTE punt te testen. Maar ik zie hem zelf ook wel bruikbaar wanneer je een extreem laag nachtverbruik hebt. Dan zou je hem in de nacht op handmatig kunnen zetten en overdag op NOM.

Dashboard grafiek kun je hier vinden, dit is wel een uitgeklede variant;
https://gathering.tweakers.net/forum/view_message/82759844

Hier ziet het er zo uit (stukje thuis dashboard);

[gielz]

martinvdm schreef op dinsdag 22 juli 2025 @ 20:40:
Thanks. Wil voorlopig ff beginnen, ondanks de 3 a 4% afwijking, is het in jouw code wel mogelijk de Zendure api te gebruiken ipv een tussenstekker of meter aan de batterij kant?

Het is het proberen waard, met firmware 1.03 kon het niet. Je zal dan het gecombineerde vermogen per seconden moeten uitlezen. Er kan trouwens niets mis gaan, je batterij kan bevriezen maar dat is makkelijk op te lossen als het een 2400 AC is.

Laat even weten wat de uitkomst is.

EDIT; heb hem even voor je erbij gepakt, suc6!

code:

  - resource: http://192.168.0.172/properties/report  # Omvormer kan bevriezen
    scan_interval: 1
    sensor:
      - name: "ZenSDK Zendure 2400 AC Vermogen Aansturing API"
        value_template: >
          {% set opladen = value_json['properties']['outputPackPower'] | int %}
          {% set ontladen = - (value_json['properties']['packInputPower'] | int) %}
          {% if opladen != 0 %}
            {{ opladen }}
          {% else %}
            {{ ontladen }}
          {% endif %}
        unique_id: ZenSDK_Zendure_2400_AC_Vermogen_Aansturing_API
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

*Verschil tussen Shelly meting direct bij het stopcontact VS het API vermogen

[ Voor 51% gewijzigd door gielz op 22-07-2025 21:02 ]

[gielz]

DaWizza schreef op dinsdag 22 juli 2025 @ 22:55:
Morgen komt de Home wizard plug binnen, verder is alles al aanwezig (hoewel ik liever de zendure p1 meter heb dan de home wizard p1, maar die komt eraan)

De installatie van zowel de batterij als de HA setup was een makkie, props voor de handleiding. Als het morgen zover is dan gaan NOM meteen aan, 9 maanden met minieme afname moet dan wel mogelijk zijn.

Ik merkte wel op dat met de dev settings in HA het aansturen meteen werkte (zoals in de handleiding staat) maar met het pulldown menu gebeurt er weinig als ik bijv. 2400 ontladen kies. Heb ik iets gemist?

Heb je in stap 4 de automatisering aangemaakt voor je selectielijstje? Zo ja dan kun je deze openen en even naar je tracering kijken welke optie hij heeft genomen bij het selecteren van 2400 watt.

[ Voor 22% gewijzigd door gielz op 22-07-2025 23:12 ]

[pieterh78]

gielz schreef op maandag 21 juli 2025 @ 10:31:
@pieterh78 Er gaat iets niet goed in je configuratie. Want er is inderdaad een offset beschikbaar maar dan hebben wij het over afwijkingen van 0-30 watt. En niet -445 watt

Controleer als eerste je P1 en de Energysocket, zijn ze per seconden en hebben ze überhaupt data en staan ze goed in je NOM automatisering. (vervangen via kladblok, als het afwijkende sensoren zijn).

Zou er zo uit moeten zien;
[Afbeelding]

Uitlezen P1 en socket op 10 sec gezet. De NOM automatisering op 11 sec. Dit is het resultaat van afgelopen nacht.



Zag er al een stuk stabieler uit. Vandaag wel gemerkt dat de NOM vaak stilstond waarbij de socket -25 watt aangaf. Vanavond viel het me op dat het afgegeven vermogen maar op bleef lopen ipv van gestabiliseerd.



Daarop alles een keer verwijderd en opnieuw aangemaakt.

Morgen nog eens kijken wat de nacht gedaan heeft. Hopelijk stabiel.

[geert1992]

Afgelopen nacht heeft NOM gedraaid(slim ontladen) in combinatie met drie Hypers en de Fireson-integratie. Helaas verliep dit niet zoals gehoopt. De hypers lijken alle kanten op te schieten; zowel in vermogen als in de hoeveelheid apparaten.

Het zou prettig zijn om meer mogelijkheden te hebben om zelf in te stellen hoe NOM wordt aangestuurd. Bijvoorbeeld door per apparaat een eigen Zendure Manager te koppelen, of juist door binnen één Zendure Manager meer gedetailleerde keuzes te kunnen maken.
Wat mij betreft mag alle energie gewoon uit 1 hyper komen, zolang het totale verbruik maar onder de 1200 watt blijft, tenzij er een verschil in SOC ontstaat van bijvoorbeeld 5 procent.
Grafiek batterijen:

Grafiek stroom totaal:


Wat mij opviel is dat de lokale mqtt bij 2 van de 3 hypers een tijd wegviel(let niet op eerdere gaten in de tijdlijn, dit heb ik zelf veroorzaakt):



Zijn er meer mensen met 3 hypers, en die hetzelfde ervaren? Of is het probleem te veel apparaten?
Of weet @FireSon raad?

[ Voor 22% gewijzigd door geert1992 op 23-07-2025 09:41 ]

[DaWizza]

gielz schreef op dinsdag 22 juli 2025 @ 23:02:
[...]

In de trace lijkt het prima te werken:


Ook de automations draaien:


Zojuist nog een keer HA herstart en opeens werkt het

Nu weer verder lezen in het topic, 800W laden is veel te weinig

[ Voor 31% gewijzigd door DaWizza op 23-07-2025 15:39 ]

[gielz]

Korvaag schreef op woensdag 23 juli 2025 @ 19:40:
Dit is weer typisch iets wat ik dan weer heb. Hoe lastig kan het zijn.

Ik heb de config uit de startpost netjes aangepast aan de SF 800 Pro, maar wat ik ook doe, ik krijg die rest_commands niet aan de praat. Ik heb de Docker container al zo'n 3 keer herstart. Via de GUI ook al een herstart of 8. Ik heb geen idee waar ik die dingen moet vinden. Entities werken prima overigens. Restful command is zichbaar in integrations, maar daaronder niets en bij Helpers ook niets. Wat gaat hier verkeerd.

De rest commands zijn alleen zichtbaar bij de Ontwikkelhulpmiddelen >> Acties. Ik heb wel eens via de GUI meer dan 10x moeten herstarten voordat dit permanent ging werken. De Docker zelf zou je niet aan hoeven komen.

[jordyc]

peterb13 schreef op woensdag 23 juli 2025 @ 21:46:
[...]

Super. Bedankt!

Zoek in visual studio naar het bestand genaamd solarflow2400ac.py. Daar moet je even zoeken naar de lap code uit het plaatje. Je moet dan de self.powerMin en Max aanpassen en iets verder naar beneden de self.number inputLimit en outputLimit aanpassen. In het plaatje heb ik ze gemarkeerd. Hier vul je de maximale waardes in waarmee je wilt werken.

Daarna HA opnieuw opstarten zodat alles goed wordt ingeladen en dan zou het moeten werken.

[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]

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.

[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?

[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]

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.

[Roedie84]

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

[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?

[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]

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 ]

[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?

[c0mplex1]

Volgens mij is die per 1 augustus overgegaan van fireson naar zendure.

[Taro]

Gaat maar net goed zo, of eigenlijk net niet.... Dit is dus zonder EV laden, wel met alle accu's, vaatwasser en wasmachine. Als ik bijv. 500 Watt minder wil laden in totaal schakelt er nu 1 apparaat uit, of schroeft 1 apparaat terug. Dan zou ik de clusters op max 2400 moeten zetten wat weer net te weinig is. Als je het netjes uitsmeert schalen ze dan allemaal iets terug. Fireson even gesproken, die gaat kijken wat ie kan doen.

De Hypers staan overigens in Local mode, 2 ervan geven niet aan dat ze wat doen, maar dat doen ze op de achtergrond wel, anders zou ik niet op 3x3600 uitkomen:



Ga hem nu maar iets terugschroeven...

Goed om te constateren: Op de 3e 2400AC ligt een 140 mm fan en op de 1e en 2e hangt ie erboven, direct erop scheelt dus nog 2 graden....

[ Voor 7% gewijzigd door Taro op 02-08-2025 11:51 ]

[Taro]

Oei oei oei... Heb de clusters op 2400 staan, vermogen teruggeschroefd, maar alles gaat naar die 2 apparaten... Zal er verder over ophouden, maar ik ga er dus nu maar een stekker uithalen, dit kan echt niet en is gevaarlijk.

[universum]

Eeven met zenSDK (gielz) lopen spelen

[avdwerf]

avdwerf schreef op vrijdag 1 augustus 2025 @ 21:22:
17 pagina's doorgespit, uiteindelijk gestart met alles dat in de TS staat. Ik heb best wat vragen die ik volgens mij niet tegen ben gekomen, alvast excuses als dat wel het geval is:
- De set correctie = X die overal gebruikt wordt, de waarde die in het voorbeeld staat is een standaard waarde? Of moet die per situatie specifiek aangepast worden? Zelfde vraag voor de set factor = 1.00. Moet ik daar specifiek iets voor aanpassen als ik 1 omvormer met 6 batterijen heb?
- Ik snap niet helemaal waarom er iets inzit dat hij pas zaken doet X uur na zonsopgang en X voor zonsondergang. Waarom niet gewoon als de accu nog niet helemaal vol hem elke zonnestraal mee laten pakken?
- Ik zou nog graag in willen stellen dat hij, als ik 1 van mijn 2 EV's laad, hij alleen maar oplaad mocht er iets over zijn maar iig niet ontlaad. Ik zal buiten dat om eigenlijk altijd de functie NOM aan hebben staan. Is het dan zo simpel als een nieuwe automatisering, trigger is EV 1 of 2 aan het laden, actie is functie aanpassen naar Smart Charging. Zodra EV stopt met laden, zet functie NOM weer aan?

Heb alles sinds gisteren draaien en lijkt erg goed te gaan! Ook de toevoegingen gedaan voor het EV laden en goedkope uren laden als er niet genoeg zonopbrengst is. Vraag me dan alleen bovenstaande 2 vragen nog af, waar de correcties precies voor zijn en of ik daar nog iets mee moet doen, en waarom er zaken zijn die dingen uitstellen met zonsopgang/-ondergang.

Nu dus de NOM automatisering
Een automatisering die zodra mijn laadpaal een auto aan het laden is de modus instelt op Alleen slim opladen
Een automatisering die checkt wat de voorspelde opbrengst van vandaag is. Als die beneden X is, zet hij hem tijdens de 5 goedkopste uren die dag op Opladen met X watt, en daarna gewoon weer terug naar Nul op de meter (als er geen auto geladen wordt, anders doet hij niets).



Hele dag dus zo goed als NOM. Om 12.00 de EV aangesloten ivm goedkope stroom. De accu gaat in standby (er is geen stroom over, maar hij trekt hem ook niet leeg naar de EV). Zodra hij zo klaar is gaat hij weer op NOM en zal de accu rest van de dag volladen

[gielz]

Hieke schreef op zondag 3 augustus 2025 @ 17:35:
[...]

Zou je daar wat meer uitleg over kunnen geven? De code daarvan is voor mij niet echt begrijpelijk.
Bij mij leeft momenteel de vraag wat wordt bedoeld met
{% set factor = 1.00 %}
en
{% set correctie_export = 80 %}

De {% set cap = 2400 %} = de maximale laadsnelheid, als ik het goed heb.
Draai NOM, met dank
Alternatief is om het starten van laden in de ochtend te verschuiven naar +3 uur. Maar of dat in het voor- en naseizoen ook haalbaar is wordt nog even afwachten..
Nog mooier is natuurlijk dit soort zaken tunen via de GUI, zoals ik hierboven zag

- Set factor hoef je niets mee te doen. Hij gebruikt dit om gefaseerd het vermogen te pakken bij het opstarten in de laad of ontlaadmodus.

- De correctie_export zegt nu 80 watt in de min blijven. Dus stel je levert 1280 terug aan het net dan gaat hij met 1200 opladen. Dit om een buffer te houden zoals in HEMS bij Zendure ook gebruikelijk is.

- Voor dat uitgesteld laden is het nu zo dat hij uitgesteld gaat laden maar niet in jan-mrt en okt-dec. Je wilt in die maanden echt alles er uit persen.

Ik heb er bewust niet voor gekozen om dit in sliders te zetten omdat je dit soort dingen eigenlijk eenmalig instelt en dan lekker laat draaien.


*op vakantie

[ Voor 12% gewijzigd door gielz op 03-08-2025 17:49 ]

[Hieke]

@gielz Dank je voor je toelichting.

Bijgaand mijn result of the day. Volle bak laden vanwege zonnig weer. En dan opeens een dipje vanwege verwarmingselement wasmachine..3000 Watt vraag.. Er zijn grenzen

[ Voor 46% gewijzigd door Hieke op 03-08-2025 21:52 . Reden: Attachment ]

[gielz]

Hieke schreef op zondag 3 augustus 2025 @ 19:55:
@gielz Bijgaand mijn result of the day.

Ziet er netjes uit!

Hier onder zie je duidelijk wat het uitgesteld laden doet. Tijdens het opwekseizoen en wanneer je met nog wat prik de ochtend in gaat wil je dat laden uitstellen omdat je anders met een laag vermogen gaat laden. Boven de 800 watt geeft altijd een mooi RTE resultaat.

Hier is dat 2 uur na zonsopkomst maar afhankelijk hoe de panelen liggen kan het ook later zijn.

[Roedie84]

Taro schreef op maandag 4 augustus 2025 @ 11:19:
[...]

De instellingen voor laden en ontladen zijn eenmalige instellingen, die worden door de integratie bijgestuurd. Je bent hier denk ik op zoek naar de regiogebaseerde veiligheidsinstellingen, max uitvoer, daarvoor moet je op het linkje onderin klikken op de AC laden/ontladen pagina.

Ik neem aan dat je deze instellingen bedoelt?

[Roedie84]

Taro schreef op maandag 4 augustus 2025 @ 15:27:
[...]

Nee, die op de apparaat pagina buiten HEMS, heb je als het goed is tijdens de installatie langs zien komen. Haal het apparaat even uit HEMS, ga naar het apparaat buiten HEMS, ga naar instellingen en kies voor: Netgekoppelde standaarden. Daar kan je die 2400 aanpassen naar bijv. 1200 of 800, maar dat geldt wel alleen voor uitvoer, niet voor invoer. Let op: Niet AC-invoer en AC-uitvoer aanpassen, maar echt de netgekoppelde standaarden.

Dat zie ik dus niet na opslaan op Nederland, komt niet die instelling.

[Taro]

Vanochtend Fireson pre17 geïnstalleerd, moest wel even de clusters -> fuse setting opnieuw doorvoeren zoals ook in de opmerkingen staat, maar blij met de voortgang

Heb nu Fireson op Slimme matching staan, de fake meter op 80-90% van het maximale vermogen ingesteld (om 3600 Watt op stopcontact 1 waar ook nog een Hyper op zit te voorkomen) en de load wordt netjes uitgesmeerd over alle devices en daarmee ook over de fases en groepen. De Hyper zit bewust op de fase waarop ook de 1-fase SolarEdge PV set zit om daar het voltage te verlagen en de fases gelijk te trekken. Zoals je kunt zien werkt dit nu veel mooier dan een aantal dagen geleden:


Dit betekent ook dat de EV's weer op 11 kW kunnen laden terwijl de accu's laden

Aansturing is via ZenSDK ingesteld voor de 2400AC's en via Cloud op de Hyper (in de vorige pre versies ging de Hyper weergave in local mode niet goed, moet ik nog ff opnieuw testen), dus dat kijk ik nog even aan. Maar als dit stabiel blijft zijn er mooie stappen gemaakt @FireSon

[ Voor 4% gewijzigd door Taro op 06-08-2025 10:34 ]

[Taro]

Hyper lokale aansturing werkt helaas nog niet goed. Met de vorige stable versie was dat perfect, nu werkt het niet goed.

Toont nu 99% en laden, maar staat al uren stil op 100% en laadt met 0, maar zou eigenlijk net als de 2400AC's maximaal aan het ontladen moeten zijn. Via Bluetooth zie ik een ander beeld dan hier:

[Taro]

geert1992 schreef op vrijdag 8 augustus 2025 @ 08:15:
Het is zo ver, Versie 1.1.0 is in de lucht! Hopelijk zijn de meeste fouten eruit!

Het zal wel aan mij liggen, maar ik ben vanuit productontwikkeling gewend dat je een pre release uitbrengt, dan kijkt of alles naar behoren werkt en dan die versie omdoopt tot stable. Nu zijn er dus in 1.1.0 nog ongeteste wijzigingen aangebracht sinds pre19 die hier compleet vastliep.

Ik ga het proberen, maar vind de gang van zaken maar vreemd met een dergelijk groot publiek én dus nu ook de eerste officiële Zendure release. Dat had ik zelf anders aangevlogen

Maar goed, uiteraard blij met de voortgang en deze mijlpaal.

[geert1992]

gielz schreef op vrijdag 8 augustus 2025 @ 09:29:
Als ik thuis ben zal ik de TS even een update geven. Heb nog wel een aantal vragen aan gebruikers van de 1.1.

Is deze versie nu 100% lokaal voor de Hyper en 2400ac en gaat de hyper via mqtt en 2400ac via zenSDK (zonder mqtt)? Wanneer je de batterijen van het internet afhaalt draait dus alles altijd door.

En is dit nu een integratie van Zendure zelf? Omdat ik Fireson zie als ontwikkelaar en mag ik dan aannemen dat hij in dienst is bij Zendure? Neem aan dat Zendure niet de verantwoordelijkheid legt bij 1 persoon.

Het lijkt erop dat hij wordt ondersteund door Zendure. Wat ergens natuurlijk absurd is om te lezen. Maar dat zegt denk ik veel over de inzet van @FireSon

[ Voor 4% gewijzigd door geert1992 op 08-08-2025 09:47 ]

[FireSon]

Op GitHub stelde iemand bij de release 1.1.0
– „Alleine ist man schneller, zusammen kommt man weiter.“ –

Dus iedereen die mee heeft gewerkt aan het testen, erg bedankt daarvoor

Deze release is niet 'speciaal' of zo, we zijn geswitched naar "Semantic versioning", wat inhoud dat het versienummer de vorm heeft van: MAJOR.MINOR.PATCH

Het is wel de eerste release samen met Zendure. Zij hebben mijn project 'geadopteerd', dat is erg leuk, en ook wel handig als je specifieke vragen hebt over communicatie en zo.

Alle opmerkingen over amateurisme, professionaliteit, testen, party poopers en dergelijk steek ik wel in mijn zak. De beste stuurrlui staan zoals altijd aan de wal. Ik sta niet plotseling op de payroll van een multinational, Zendure heeft mij enkel een aantal testapparaten ter beschikking gesteld.

Dus voorlopig blijf ik (af en toe) maar wat fouten maken

[gielz]

Ik lees best wel wat issues met betrekking tot de HACS integratie. Is de enigste reden om hiervoor te kiezen het hebben van een hyper of meerdere omvormers?

Hier al sinds ze uit de doos zijn 0 issues. Buiten uiteraard zelf gemaakte problemen.


*2,5kwh sluipverbruik

[mrme12345]

gielz schreef op zondag 10 augustus 2025 @ 22:23:
Ik lees best wel wat issues met betrekking tot de HACS integratie. Is de enigste reden om hiervoor te kiezen het hebben van een hyper of meerdere omvormers?

Hier al sinds ze uit de doos zijn 0 issues. Buiten uiteraard zelf gemaakte problemen.

[Afbeelding]
*2,5kwh sluipverbruik

Voor mij wel, inderdaad voor de hyper omdat de restapi niet werkt voor de hyper. Mijn 2400ac en SF800 pro heb ik wel volledig op restapi en node red.


En nom draait hier ook perfect via node red (full electric, quooker, ev enz).

[ Voor 22% gewijzigd door mrme12345 op 10-08-2025 22:28 ]

[Taro]

TheAnT schreef op maandag 11 augustus 2025 @ 16:54:
[...]


heb een p1 sensor van smartgateways, gaat dit ook?

Ik heb die ook, let op dat die teruglevering en afname apart registreert, je moet Consumed & Produced dus inderdaad in 1 sensor combineren:

[Jnaaazer]

Ik heb nu sinds een aantal dagen de zendure-solarflow-2400-ac binnen en hij werkt goed.



Ik gebruik de nom integratie momenteel van @gielz in homeassistant en dat werkt ook heel goed:


Maar ik ben zelf niet zo goed met automations maken in homeassistant maar heeft iemand misschien iets waarmee hij gaat opladen in bijvoorbeeld de 3 goedkoopste uren als je een dynamische contract hebt (ik heb tibber integratie in homeassistant) en dan ontladen in de 3 duurste uren? Is dit financieel nu niet slimmer inplaats van Nom draaien?

3e batterij is momenteel bijbesteld en onderweg

[mrme12345]

Goed idee @Sander

Mijn opstelling:
1 x Hyper 2000 (Fireson) incl 2kW PV gekoppeld, 8 kWh batterijen
1 x SF800 Pro (zenSDK) incl 1kW PV gekoppeld, 4 kWh batterijen
1 x 2400AC (zenSDK) , 9 kWh batterijen
Verder nog 9 kW PV niet gekoppeld. Totaal verbruik 6k kWh en opwek ca. 9k kWh.

Totaal 20 kWh batterijen, huis Full electric incl EV

Tot augustus 2026 nog vast contract zonder terugleverkosten en met redelijke vergoeding voor netto teruglevering €0,09.

Gebruik mijn batterijen voor NOM. Vanaf medio maart tot heden kleine 50 kWh van net verbruikt, rest van eigen panelen.

Alles zit in HA en de fireson/zendure integratie en de zenSDK gebruik ik om zelf mijn devices op mijn eigen manier aan te sturen via node red codes.

Strategieen:
NOM: via node red met 2 devices (Hyper en SF800 Pro). Deze batterijen worden elke dag perfect gevuld vanuit de zonnepanelen (capaciteit batterijen 11,5 kWh in totaal). Ook meer dan genoeg voor NOM. Strategie is om in eerste instantie de Hyper de NOM af te laten handelen (tot 1200w), indien load hoger springt de SF800 Pro bij. Dit doe ik vooral voor snelheid schakelen (zo weinig mogelijk switchen tussen de devices) en voor zo hoog mogelijke RTE (hogere load per device).

Dit is de belangrijkste node red. Daarnaast ook nog NOM node red voor de devices afzonderlijk en voor alle 3 bij elkaar.

PV Overschot:
Node red code die device laadt op basis van P1 meter surplus en dat elke paar seconde bijstelt. Ook voor alle devices apart en voor alle 3 tegelijk.

EV Laden:
Node red code die de EV nagenoeg volledig op zon productie laadt (loopt van 6A tot 20A). Easee charger.

Dus uitgangspunt is geweest devices in HA krijgen en daarna zelf via node red elke gewenste automatisering creeren.

Mijn capaciteit qua kWh'en batterijen is nu erg hoog maar is meer voorsorteren op situatie per 1-1-2027:
Dan wordt strategie maart-oktober NOM en overige maanden laden als tarief laag is voor eigen verbruik.

Voorbeeld van NOM strategie vanaf medio maart:

[Sicco92]

Mijn opstelling:
- 1x Hyper2000 + 3,84 kWh
- 2x EV en een laadpaal van 11 kW
- 6000 Wp zonnepanelen, niet gekoppeld aan de Hyper
- Gasloos, verwarmen met warmtepomp
- Zonneplan dynamische stroomprijzen

De Hyper2000 wordt aangestuurd met de integratie van FireSon. De strategieën voor het aansturen van de accu staan niet op zichzelf, maar vormen zoveel mogelijk een geheel met de aansturing van de hele stroomhuishouding hier in huis (op basis van voorspellingen).

Aansturing
Alles behalve de EV's wordt zoveel mogelijk aangestuurd door EMHASS. Dit is een add-on waarmee ik de meest optimale aansturing kan berekenen. De add-on kan je zo configureren dat die rekening houdt met de limieten waar je mee te maken hebt, bijvoorbeeld de grid-aansluiting (max 17 kW), de efficiëntie van de accu (heb ik op 90% gezet), de afschrijving per kWh (heb ik op €0,09 staan), de specificaties van de omvormer, een aantal grootverbruikers, en nog wat meer zaken.

Ik gooi er elk kwartier data in via de API, zoals de uurprijzen voor het kopen en het verkopen van stroom (die zijn niet 100% gelijk, omdat Zonneplan een 10% zonnebonus geeft voor verkoop), de verwachte opbrengst van de zonnepanelen (via de Solcast integratie), de huidige SoC van de accu, het 'standaardverbruik' thuis, etc.
Als response krijg ik parameters terug waarmee ik mijn apparaten kan aansturen in Home Assistant. Ik krijg een (ont)ladingswaarde voor de accu, een afschakelwaarde voor de zonnepanelen (voor als de zonnepanelen op NOM moeten draaien), een aan/uit parameter voor grootverbruikers, en nog wat andere waarden waar ik op kan sturen.

De EV's worden aangestuurd door EV Smart Charging. Deze vind ik beter toegespitst op slim laden, en gebruiksvriendelijker. De EV's altijd op de goedkoopste uren, maar vanaf 2027 wil ik deze veel meer met zonnestroom gaan laden (met behulp van EMHASS).
Het staat overigens nog wel op mijn roadmap om de EV-laad data te repliceren in EMHASS, omdat die dan beter om kan gaan met de maximale grid-aansluiting (van 17 kW) in combinatie met de andere grootverbruikers en het terugschroeven van de zonnepanelen. Bij de negatieve prijzen afgelopen maanden liep ik nogal tegen de 3x25A aan namelijk.

In de praktijk
- Accu ontladen en laden vanaf een prijsverschil van ongeveer €0,12 (precieze waarde weet ik niet, EMHASS berekent voor me of handelen uitkan)
- Accu en zonnepanelen gaan in NOM-stand als prijs_verkoop <= 0 && prijs_inkoop >= 0 && prijs_inkoop - prijs_verkoop >= 0 (t/m 2026 is dat alleen zo bij een prijs van precies €0,00 maar vanaf 2027 zal dit veel vaker voorkomen)
- Vanaf 2027 verwacht ik dat de accu's veel meer voor zelfverbruik gebruikt gaat worden en dus nog vaker in NOM staan
- EV's laden altijd op de goedkoopste uren voor zolang ze ingeplugd zijn

Ik ben nog bezig om meer grootverbruikers toe te voegen aan EMHASS, zodat de voorspelling beter aansluit bij de limieten die ik heb ingegeven. En om vanaf 2027 beter om te kunnen gaan met zelfverbruik van onze zonnestroom.

Hier een leuk grafiekje die elke dag laat zien wat de berekende strategie is vanuit EMHASS:

[mrme12345]

Sander schreef op woensdag 13 augustus 2025 @ 08:26:
[...]


Quooker blijft echt een irritant apparaat in die zin en iets van 'demping' daarop met laden maakt een groot verschil in NOM (zeker met een Hyper 2000 met maar 1200W). Gaat uitzetten via een powersocket (en weer aan) wel goed? En wat zie je dan voor piek in de ochtend als je hem weer aan zet?

Ja dat vind ik ook, met al die pieken van 10 sec. Daar kan een batterij niet tegen opwerken. Maar ja als je er eenmaal 1 hebt doe je die niet weg, want het is wel een handig apparaat natuurlijk. Wat ik nu dus doe is savonds via smart stekker uitzetten en dan smorgens weer aan en dan zorg ik met node red dat de zendure's minimaal 2000w geven voor 5 minuten. Het duurt precies 2 minuten na de nacht om het weer op temperatuur te krijgen en qua energieverbruik is het nagenoeg hetzelfde.

[gielz]

martinvdm schreef op woensdag 13 augustus 2025 @ 16:40:
[...]

Thanks, ga er ff mee stoeien. Wel mooi die apexcharts card imho, kende hem nog niet

Apex is echt heel mooi. Bijna alles is wel mogelijk. Alle grafieken draaien hier op apex.

[universum]

code:

{% if states('sensor.kwh_meter_power_2') | float(0) < 0 %}
  {{ states('sensor.kwh_meter_power_2') | float(0) | abs }}
{% else %}
  0
{% endif %}

[Sander]

martinvdm schreef op vrijdag 15 augustus 2025 @ 12:28:
[...]

Hoe herken je de freeze? Reageert de lokale Zendure API nog wel?

Entities in HA worden niet meer geüpdatet. Zendure app doet niks, hyper zelf reageert nergens meer op zelfs niet op de “IOT button” dus alles moet los van de stroom en opnieuw eraan.

Dit is een hyper 2000 dus geen lokale Zendure api vziw

En na een ochtend stabiel maar weer eens geprobeerd local MQTT aan te zetten, dat gaat even goed (ook in de debug logging) maar binnen 10 minuten is het alweer klaar:

[ Voor 28% gewijzigd door Sander op 15-08-2025 13:11 ]

[Taro]

wosp schreef op zaterdag 16 augustus 2025 @ 10:14:
[...]


Penibel in de zin dat ik van de week onverwachts weinig porrie in de wagen had waardoor ik zelfs even aan de snellader heb moeten staan (gebeurd me normaal eigenlijk nooit). Als ik de grafieken terugkijk heeft de Zappi zo te zien teruggeschakeld naar 1 fase omdat hij niet op alle 3 de fases hetzelfde vermogen kon pakken (op 1 fase stond de Zendure vol te laden). Als de Zendure vervolgens omschakelde naar de fase die de Zappi als eerste fase gebruikt ging die weer staan wachten op overschot. Zo ging het laden erg langzaam.

Heb je dynamische tarieven en welke laadpaal?

Ik hou er tegenwoordig rekening mee dat de accu's, vaatwasser, droger, wasmachine, kookplaat, afzuigkap, zandfilterpomp & WP zwembad, tosti-ijzer, etc. iedere dag invloed hebben op de laadsnelheid van de auto en de 3x25A als krap wordt ervaren. Zie geregeld 4-7 kW ipv 11 kW door de laadpaal loadbalancer, dus plan sowieso wat extra uren in om te laden. Daarnaast vullen we ieder weekend 2 EV's die op vrijdagavond gemiddeld met 10-25% voor de deur staan, dus knallen we er regelmatig 70-110 kWh in in het weekend. Voorheen deden we dat alleen op zondag toen dat nog met 11kW ging, tegenwoordig starten we gewoon op zaterdag al. Ook heb ik via Home Assistant de laadpaal nu automatisch zo ingesteld dat ie onder de 20 cent op 1-fase de auto laadt vanuit de zonnepanelen als de thuisaccu's vol zijn. Voor 16-18 ct/kWh terugleveren vind ik niet nuttig, dan heb ik liever dat ik met eigen opgewekte stroom heen en weer rijd. 1 van de 2 EV's is nu 92% (hogere SoC is niet nodig én niet wenselijk), de ander staat al op 73% en krijgt morgen om 15:00 nog 1 uurtje 11 kW, dan is die ook vol genoeg voor komende week.

Zo ziet dat er vandaag uit (volledig automatisch en Y-as onder nul):


En morgen om 15:00 pakken we het goedkoopste uurtje om 15:00 ook mee, dan hebben we weer genoeg peut voor de hele week:

[Devke]

Dashboard Celspanning Batterijen

Wil jij per batterij onder je Zendure omvormer een aantal dingen bij houden waarbij de kerntaak ligt op balanceren/celspanning? Misschien helpt onderstaande je daarbij.



Stap 1:
Maak een sensor aan die de attributen van je batterij bevat. Ik heb onderstaande sensor in configuration.yaml opgenomen. Zet dit wel onder je rest sectie.

YAML:

name: "Zendure Batterij Packs Status"
        value_template: "{{ value_json.properties.electricLevel }}"
        unit_of_measurement: "%"
        device_class: battery
        unique_id: Zendure_Batterij_Packs_Status
        json_attributes:
          - packData

Herstart HA en kijk of de sensor met attributen zichtbaar is.

Stap 2:
Neem ook de volgende code (sensoren) op in je configuration.yaml

YAML:

# Zendure 1 Pack 1
      - name: "Zendure 1 Pack 1 Min Volt"
        value_template: >
          {% set packdata = state_attr('sensor.zendure_batterij_packs_status', 'packData') %}
          {% if packdata and packdata|length > 0 %}
            {{ packdata[0]['minVol'] / 100 }}
          {% else %}
            0
          {% endif %}
        unit_of_measurement: "V"
        device_class: voltage
        unique_id: zendure1_pack1_min_volt

      - name: "Zendure 1 Pack 1 Max Volt"
        value_template: "{{ state_attr('sensor.zendure_batterij_packs_status', 'packData')[0].maxVol / 100 }}"
        unit_of_measurement: "V"
        device_class: voltage
        unique_id: zendure1_pack1_max_volt

      - name: "Zendure 1 Pack 1 Spread"
        value_template: "{{ (state_attr('sensor.zendure_batterij_packs_status', 'packData')[0].maxVol - state_attr('sensor.zendure_batterij_packs_status', 'packData')[0].minVol) / 100 }}"
        unit_of_measurement: "V"
        device_class: voltage
        unique_id: zendure1_pack1_spread

      - name: "Zendure 1 Pack 1 SoC"
        value_template: "{{ state_attr('sensor.zendure_batterij_packs_status', 'packData')[0]['socLevel'] }}"
        unit_of_measurement: "%"
        device_class: battery
        unique_id: zendure1_pack1_soc
      

Herstart wederom HA en kijk of je de sensoren hebt. Herhaal de code voor iedere batterij die je hebt.

Stap 3:
Maak een Kop Kaart aan met de volgende yaml. De laatste mdi symbolen geven de SoC en temperatuur van de betreffende batterij aan. De Fan die je als laatste ziet is voor mij een herkenning dat de fan de omvormer extra koelt. Een eigen gemaakte entiteit. Niet opgenomen in eerder genoemde code.

YAML:

type: heading
heading: Zendure 1 Batterij 1
heading_style: title
badges:
  - type: entity
    show_state: true
    show_icon: true
    entity: sensor.zendure_1_pack_1_soc
    color: amber
    icon: mdi:battery
    tap_action:
      action: more-info
  - type: entity
    show_state: true
    show_icon: true
    entity: sensor.zendure_2400_ac_batterij_1_temperatuur
    color: amber
    icon: mdi:battery
    tap_action:
      action: more-info
  - type: entity
    show_state: true
    show_icon: true
    entity: sensor.zendure_ventilator_power_3
    color: amber
    icon: mdi:fan
    tap_action:
      action: more-info

Stap 4:
Nu zal je voor iedere batterij de MinVolt, MaxVolt en Spread moeten opnemen in een Modern Circular Gauge Kaartconfiguratie. Deze stap herhaal je voor iedere batterij die je hebt. Let op dat je PackData[0] dan veranderd in PackData[1} voor je 2e batterij etc.

Voor MinVolt

YAML:

type: custom:modern-circular-gauge
entity: sensor.zendure_1_pack_1_min_volt
name: Batterij 1 Min V
min: 2
max: 3.8
needle: true
smooth_segments: false
adaptive_icon_color: true
header_position: bottom
grid_options:
  columns: 8
  rows: 3
segments:
  - from: 2
    to: 2.5
    color:
      - 200
      - 0
      - 0
  - from: 2.5
    to: 3.6
    color:
      - 159
      - 222
      - 23
  - from: 3.6
    to: 3.8
    color:
      - 200
      - 0
      - 0
secondary: {}
tertiary: {}

Voor MaxVolt

YAML:

type: custom:modern-circular-gauge
entity: sensor.zendure_1_pack_1_max_volt
name: Batterij 1 Max V
min: 2
max: 3.8
needle: true
smooth_segments: false
adaptive_icon_color: true
header_position: bottom
grid_options:
  columns: 8
  rows: 3
segments:
  - from: 2
    to: 2.5
    color:
      - 200
      - 0
      - 0
  - from: 2.5
    to: 3.6
    color:
      - 159
      - 222
      - 23
  - from: 3.6
    to: 3.8
    color:
      - 200
      - 0
      - 0
secondary: {}
tertiary: {}

En voor de spread

YAML:

type: custom:modern-circular-gauge
entity: sensor.zendure_1_pack_1_spread
min: 0
max: 0.25
needle: true
smooth_segments: false
adaptive_icon_color: true
header_position: bottom
grid_options:
  columns: 8
  rows: 3
segments:
  - from: 0
    to: 0.1
    color:
      - 0
      - 200
      - 0
  - from: 0.1
    to: 0.15
    color:
      - 255
      - 120
      - 0
  - from: 0.15
    to: 0.25
    color:
      - 200
      - 0
      - 0
secondary: {}
tertiary: {}
name: Batterij 1 Spread

[avdwerf]

Devke schreef op woensdag 20 augustus 2025 @ 09:17:
[...]

Afronding is op 0.01 V steeds. Hier gaat het goed, apart. Heb je het naar mV gezet?

Nee had verder niks aangepast. Hij werkt nu goed maar dit toonde hij gister nadat ik alles had aangemaakt.

[g00gle]

Ik heb een issue met homeassistant en snap niet waardoor dit komt. Veel gegevens blijven bij mij op unkown staan, maar een deel werkt wel. Ik weet niet goed waar ik het moet zoeken. Iemand een suggestie?

[g00gle]

Ja als het goed is wel, ik vermoed dat het daar ook fout gaat. Maar ik snap niet heel goed hoe HA werkt. Dus het is ongetwijfeld een config dingetje. Alleen ik weet niet goed waar.

Wat ik heb gedaan is dit installeren:


En de Zendure plugin. En tijdens de installatie lokale mqtt gekozen. En mijn HA credentials ingevuld. Zover kwam ik, kon ook verder niet echt een duidelijke how to vinden. Beetje gebrek aan HA ervaring denk ik.

[gielz]

De poll heb ik in de TS even een update gegeven. Draai je inmiddels via Home Assistant maar heb je dit nog niet aangegeven zou het fijn zijn als je dit even in de poll kunt aangeven. Dan is goed te zien waar iedereen nu op draait, lekker divers clubje!

https://strawpoll.com/05ZdzxXvmn6



Homey kan niet meer gekozen worden die hebben inmiddels een eigen topic
Zendure Batterijen Slim aansturen met Athom Homey

[martinvdm]

Ik probeer eigenlijk op een fatsoenlijke manier de dagelijkse RTE vast te leggen.
Ik heb dus een template sensor aangemaakt die de last_period vastlegt van beide utility_meter sensoren, zowel de import als de export van de batterij en de RTE berekent.

YAML:

sensor:
      - name: "Zendure 2400 Battery RTE Yesterday"
        device_class: energy
        state_class: measurement
        unit_of_measurement: "%"
        state: >
          {% set imp = state_attr('sensor.zendure_2400_ac_import_daily', 'last_period') | float(0) %}
          {% set exp = state_attr('sensor.zendure_2400_ac_export_daily', 'last_period') | float(0) %}
          {% if imp > 0 %}
            {{ (exp / imp * 100) | round(1) }}
          {% else %}
            0
          {% endif %}

Datgeen weer in een apexchart gezet.


Werkt op zich aardig, maar op een of andere manier lijkt de RTE, zeker wanneer er weinig input en weinig output geweest is af te wijken. Nog ff sleutelen dus, maar begin is er.