Zendure producten in Home Assistant integreren deel 2

[gielz]

fabudop schreef op donderdag 11 december 2025 @ 22:28:
@gielz , ik krijg sinds kort deze waarschuwing in HA:

[Afbeelding]

Het gaat om de p1_nul_import_actief sensor die je in de automation heb toegevoegd. Herken je dit?

NB: ik draai nu HA versie 2025.12.1

Niet een heel groot issue omdat het onderdeel is van de statistieken en niet de aansturing zal beïnvloeden vanaf HA 2026.6 (Juni 2026). Maar zal opgelost worden in de Januari update.

Ik heb hem al getest op HA OS 2025.12.2;
https://github.com/Gielz1...z1986-Januari-2026-update

[sjnelle]

Heb gielz integratie geinstallerd en nordpol sensor via hacs
Heb bij Nordpol sensor ingevuld
sensor.nordpool_kwh_nl_eur_3_10_021

Hoe weet dat het werkt, heb idee dat de gielz zendure integratie niks met sensor data doet.
Nordpool sensor heeft wel data

[gielz]

sjnelle schreef op vrijdag 12 december 2025 @ 12:57:
Heb gielz integratie geinstallerd en nordpol sensor via hacs
Heb bij Nordpol sensor ingevuld
sensor.nordpool_kwh_nl_eur_3_10_021

Hoe weet dat het werkt, heb idee dat de gielz zendure integratie niks met sensor data doet.
Nordpool sensor heeft wel data

Wat verwacht je dat hij doet? Op de Github in de readme staat alles wat hij wel doet;
https://github.com/Gielz1...-batterij-mag-aan-de-slag

[Freemann]

sjnelle schreef op vrijdag 12 december 2025 @ 12:57:
Heb gielz integratie geinstallerd en nordpol sensor via hacs
Heb bij Nordpol sensor ingevuld
sensor.nordpool_kwh_nl_eur_3_10_021

Hoe weet dat het werkt, heb idee dat de gielz zendure integratie niks met sensor data doet.
Nordpool sensor heeft wel data

Er zit een kleine leercurve in.
In een "NOM" modes doet hij zaken automagisch, verder moet je nog wel zelf wat zaken regelen.
Ik ben nu ook een klein weekje aan het testen/puzzelen.

Zelf maak ik nu gebruik van de volgende automatisering en die heb ik ook iets aangepast;
Zie de volgende post:
fabudop in "Zendure producten in Home Assistant integreren deel 2"

code:

alias: Batterij mode schakelen naar prijs en zon
description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.dynamisch_duurste_periode
    to: null
  - trigger: state
    entity_id:
      - sensor.dynamisch_goedkoopste_periode
    to: null
  - trigger: state
    entity_id:
      - sensor.energy_current_hour
  - trigger: state
    entity_id:
      - sensor.sb5_0_1av_41_684_grid_power
conditions: []
actions:
  - choose:
      - conditions:
          - condition: state
            entity_id: sensor.dynamisch_duurste_periode
            state:
              - Ja
        sequence:
          - action: input_select.select_option
            metadata: {}
            data:
              option: Ontladen met 2400 watt
            target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
        alias: "Dure periode: Max. ontladen met 2400 watt"
      - conditions:
          - condition: state
            entity_id: sensor.dynamisch_goedkoopste_periode
            state:
              - Ja
          - condition: numeric_state
            entity_id: sensor.dynamisch_nordpool
            below: input_number.dynamisch_laden_onder_prijs
          - condition: numeric_state
            entity_id: sensor.dynamisch_spread_indicatie
            above: input_number.dynamisch_minimale_spread
        sequence:
          - action: input_select.select_option
            metadata: {}
            data:
              option: Opladen met 2400 watt
            target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
        alias: "Goedkope periode en prijs laag/spread hoog: flink opladen"
      - conditions:
          - condition: or
            conditions:
              - condition: numeric_state
                entity_id: sensor.sb5_0_1av_41_684_grid_power
                above: 400
              - condition: numeric_state
                entity_id: sensor.energy_current_hour
                above: 750
        sequence:
          - action: input_select.select_option
            metadata: {}
            data:
              option: Alleen slim opladen
            target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
        alias: "Zonneopbrengst verwacht en niet duur: slim opladen"
    default:
      - action: input_select.select_option
        metadata: {}
        data:
          option: Standby
        target:
          entity_id: input_select.zendure_2400_ac_modus_selecteren
mode: single

Je moet nog wel een paar sensoren voor deze automatisering aanmaken.
Voor nu voldoet die prima, al had hij vannacht amper geladen. Bleek dat de minimale prijs op €0,25 stond en niet in alle gevallen de kwartier prijs <€0,25 was. Maar dat is weer een leerpunt.
Heb nu 2 sensoren aangemaakt die de delta in € weergeven tussen gemiddeld hoogste en laagste dynamische spread prijs. Het is (voor mij nu) veel belangrijke dat de spread delta in € grote is dan bijv. €0,07 dan dat de absolute kWh prijs <€0,25.
Dit moet ik nu nog in bovenstaande automatisering verwerken.
Sowieso moet ik hem voor 1-1-2026 nog aanpassen. Dit omdat wij nu, bij Tibber, nog geen terugleververgoeding betalen maar dat per 1-1 wel gaan doen. Dus dan moet de Dynamische Minimale Spread en Absolute Spread delta prijs ook hoger zijn om terug te leveren. Anders moet het NOM zijn.

Dit is hoe ik er nu na een ruime week tegenaan kijk. Grote kans dat het volgende week of medio Jan. weer anders is.

[sjnelle]

gielz schreef op vrijdag 12 december 2025 @ 13:33:
[...]


Wat verwacht je dat hij doet? Op de Github in de readme staat alles wat hij wel doet;
https://github.com/Gielz1...-batterij-mag-aan-de-slag

Denk dat ik me nog wat meer moet inlezen. Had hem op dynamisch nom gezet maar zie nog niks gebeuren:
Onderstaand stukje is me niet helemaal duidelijk

Wanneer je ook het Dynamisch Nordpool gedeelte in gebruik gaat nemen moet je voor dat je deze in gebruik neemt bij input_text.dynamisch_handmatige_periode en input_text.dynamisch_handmatige_periode_morgen even unknown weghalen. Hierna zal het dynamisch gedeelte werken. Alles wat in de forecast (morgen) gezet word zal overgenomen worden om 00:00 via de automatisering en verschijnen in vandaag.

Vervolgens kan de modus Dynamisch NOM gebruikt worden. Deze modus is ideaal in een periode met weinig zon maar wel met veel wind. Laad

[sjnelle]

Thx @Freemann je stukje heeft me geholpen.
Nu nog even zoeken of ik wat meer inzicht kan krijgen wat de goedkope en dure momenten zijn.
Zodat beter kan zien wanneer hij moet gaan laden / ontladen
Een nog wat meer spelen met de uren en spread

[CopyCatz]

Ik heb in HA een grafiek gemaakt op basis van de energie.theoxygent.nl voorspelling, maar die zit er vaak behoorlijk naast. Maakt op zich niet zoveel uit omdat het me om een indicatie gaat of ik zaken wat langer moet uitstellen. Heb sinds gister een grafiek op basis van deze integratie: https://github.com/BravoNLD/NED-forecast. Die geeft me wel een aardige indruk op wat ik qua prijzen kan verwachten de komende dagen.

[gielz]

ZenSDK (Gielz) - Kerst release

Niet echt noemenswaardig maar toch even de gebruikelijke post dat er een release is. Iets eerder door de aankomende feestdagen en vakantieperiode.

Release

https://github.com/Gielz1...DK/releases/tag/v20251215
https://github.com/Gielz1...are/v20251128...v20251215

[Jheroun]

Aardedraadje schreef op zaterdag 6 december 2025 @ 04:45:
[...]

Ik kan me niet herinneren dat ik iets in moest schakelen om ZenSDK werkend te krijgen. Wat krijg je te zien als je naar http://<Zendure IP>/properties/report gaat in de browser?

(let op dat je niet de serienummers volledig overneemt)

Dat levert {"timestamp":1765804829,"messageId":1,"sn":"1","version":2,"product":"solarFlow2400AC","properties":{"heatState":0,"packInputPower":0,"outputPackPower":216,"outputHomePower":0,"remainOutTime":2246,"packState":1,"electricLevel":53,"gridInputPower":216,"solarInputPower":0,"solarPower1":0,"solarPower2":0,"solarPower3":0,"solarPower4":0,"solarPower5":0,"solarPower6":0,"pass":0,"reverseState":0,"socStatus":0,"hyperTmp":2961,"gridOffPower":0,"dcStatus":1,"pvStatus":0,"acStatus":2,"dataReady":1,"gridState":1,"BatVolt":4983,"socLimit":0,"writeRsp":0,"acMode":1,"inputLimit":216,"outputLimit":0,"socSet":1000,"minSoc":500,"gridStandard":4,"gridReverse":1,"inverseMaxPower":800,"lampSwitch":1,"gridOffMode":2,"IOTState":2,"fanSwitch":1,"fanSpeed":0,"bindstate":0,"VoltWakeup":0,"OldMode":0,"OTAState":0,"LCNState":0,"factoryModeState":0,"ts":1765804824,"tsZone":13,"smartMode":1,"chargeMaxLimit":800,"phaseSwitch":1,"packNum":2,"rssi":-76,"is_error":0},"packData":[{"sn":"2","packType":5,"socLevel":52,"state":1,"power":94,"maxTemp":2881,"totalVol":4970,"batcur":19,"maxVol":331,"minVol":331,"softVersion":4106,"heatState":0},{"sn":"3","packType":5,"socLevel":54,"state":1,"power":99,"maxTemp":2871,"totalVol":4980,"batcur":20,"maxVol":332,"minVol":331,"softVersion":4106,"heatState":0}]}

@martinvdm

Dan doe ik wellicht iets fout, echt veel tijd om er mee te knutselen heb ik ook nog niet genomen.

Nu krijg ik overigens ook een melding dat een deel van de config niet meer werkt in een nieuwe HA versie, dus wellicht hangt het daar mee samen: "The legacy platform: template syntax for binary_sensor is being removed. Please migrate p1_nul_import_actief to the modern template syntax."

Ik zie hierboven dat er een nieuwe kerstrelease is, dus ik denk dat ik gewoon even helemaal opnieuw ga beginnen

[gielz]

Jheroun schreef op maandag 15 december 2025 @ 14:37:
[...]


Dat levert {"timestamp":1765804829,"messageId":1,"sn":"1","version":2,"product":"solarFlow2400AC","properties":{"heatState":0,"packInputPower":0,"outputPackPower":216,"outputHomePower":0,"remainOutTime":2246,"packState":1,"electricLevel":53,"gridInputPower":216,"solarInputPower":0,"solarPower1":0,"solarPower2":0,"solarPower3":0,"solarPower4":0,"solarPower5":0,"solarPower6":0,"pass":0,"reverseState":0,"socStatus":0,"hyperTmp":2961,"gridOffPower":0,"dcStatus":1,"pvStatus":0,"acStatus":2,"dataReady":1,"gridState":1,"BatVolt":4983,"socLimit":0,"writeRsp":0,"acMode":1,"inputLimit":216,"outputLimit":0,"socSet":1000,"minSoc":500,"gridStandard":4,"gridReverse":1,"inverseMaxPower":800,"lampSwitch":1,"gridOffMode":2,"IOTState":2,"fanSwitch":1,"fanSpeed":0,"bindstate":0,"VoltWakeup":0,"OldMode":0,"OTAState":0,"LCNState":0,"factoryModeState":0,"ts":1765804824,"tsZone":13,"smartMode":1,"chargeMaxLimit":800,"phaseSwitch":1,"packNum":2,"rssi":-76,"is_error":0},"packData":[{"sn":"2","packType":5,"socLevel":52,"state":1,"power":94,"maxTemp":2881,"totalVol":4970,"batcur":19,"maxVol":331,"minVol":331,"softVersion":4106,"heatState":0},{"sn":"3","packType":5,"socLevel":54,"state":1,"power":99,"maxTemp":2871,"totalVol":4980,"batcur":20,"maxVol":332,"minVol":331,"softVersion":4106,"heatState":0}]}

@martinvdm

Dan doe ik wellicht iets fout, echt veel tijd om er mee te knutselen heb ik ook nog niet genomen.

Nu krijg ik overigens ook een melding dat een deel van de config niet meer werkt in een nieuwe HA versie, dus wellicht hangt het daar mee samen: "The legacy platform: template syntax for binary_sensor is being removed. Please migrate p1_nul_import_actief to the modern template syntax."

Ik zie hierboven dat er een nieuwe kerstrelease is, dus ik denk dat ik gewoon even helemaal opnieuw ga beginnen

Waar loop je nu exact op vast? Dan help ik je even op weg.

[Jheroun]

@gielz Vooral op mezelf vermoed ik Ik ben net opnieuw begonnen vanuit je nieuwe versie. Voor mij is niet direct duidelijk waar ik de IP adressen in moet voeren, dus ik neem aan dat ik de string die je op github noemt moet find-and-replacen met het IP van de 2400AC.

Ik denk dat ik eerder het IP van de Zendure P1 op de HW P1 plek heb neergezet, maar die zal uiteraard wel bij de afwijkende P1 sensor moeten. Maar moet dan daar het IP adres, of de naam van die sensor? En moet het IP adres op de plek waar nu de HW P1 ip adres genoemd is? Ik ben totaal nog niet thuis in HA, en scripten van dingen is voor mij al een tijd geleden dus ik loop tegen een syntaxleercurve aan

[gielz]

Jheroun schreef op maandag 15 december 2025 @ 14:51:
@gielz Vooral op mezelf vermoed ik Ik ben net opnieuw begonnen vanuit je nieuwe versie. Voor mij is niet direct duidelijk waar ik de IP adressen in moet voeren, dus ik neem aan dat ik de string die je op github noemt moet find-and-replacen met het IP van de 2400AC.

Ik denk dat ik eerder het IP van de Zendure P1 op de HW P1 plek heb neergezet, maar die zal uiteraard wel bij de afwijkende P1 sensor moeten. Maar moet dan daar het IP adres, of de naam van die sensor? En moet het IP adres op de plek waar nu de HW P1 ip adres genoemd is? Ik ben totaal nog niet thuis in HA, en scripten van dingen is voor mij al een tijd geleden dus ik loop tegen een syntaxleercurve aan

Je hoeft iig niets te vervangen. Als je de configuration.yaml in gebruik neemt. Kun je vervolgens Home Assistant herstarten.

Hierbij een mooie hint!;
gielz in "Zendure producten in Home Assistant integreren deel 2"

[Jheroun]

gielz schreef op maandag 15 december 2025 @ 14:54:
[...]


Je hoeft iig niets te vervangen. Als je de configuration.yaml in gebruik neemt. Kun je vervolgens Home Assistant herstarten.

Ik was er dus blind vanuit gegaan dat het stuk tekst op de github over het invullen van ip adressen bij entiteiten in die config.yaml moest. Had ik al gezegd dat ik een HA noob ben? Ik zag net pas dat er een hele berg entiteiten in HA te vinden is (waaronder bijzonder veel HUE lampen, Google Homes en SONOS speakers, in mijn geval).

Waar ik nu onderstaand lijstje wel moet invullen is mij overigens nog steeds niet geheel duidelijk, maar met wat prutsen bij entiteiten heb ik wel wat in kunnen vullen. Vooral de afwijkende P1 krijg ik er volgens mij nog niet goed in.
input_text.zendure_2400_ac_ip_adres
input_text.homewizard_p1_ip_adres
input_text.afwijkende_p1_sensor

Ik ga er nog even op puzzelen, en misschien eens starten met het HA topic ipv het Zendure in HA topic...

Ik krijg inmiddels wel eea over de batterij te zien, maar de afwijkende P1 doet het nog niet (is een zendure P1 meter). Ik heb wel het IP adres van de meter ingevuld in het invulveld, die staat daar nu op dezelfde manier als het IP van de 2400AC, dus dat lijkt me dan goed. Maar statistieken van de P1 zie ik nog niet.

Hierbij een mooie hint!;
gielz in "Zendure producten in Home Assistant integreren deel 2"

Dank daarvoor, maar ik ben nog niet voldoende ingelezen om de hint ook te snappen

[ Voor 40% gewijzigd door Jheroun op 15-12-2025 17:08 ]

[Freemann]

Het virus is hier ingeslagen als een klein bommetje.
De tweede SolarFlow AC 2400 met 4 batterijen is onderweg en brengt het op 2x SF met ieder 3 batterijen.

Dit betekend dat ik al over ga stappen van "zenSDK" naar "Zendure".
Wordt, ook al ben ik pas 2 weken bezig, al een aardig klusje om direct weer alles om te bouwen.

Ondertussen ook een vraagje;
Aks ik het goed begrepen heb, is de "Fake Meter", om zaken buiten de NOM wilt houden?!
Zie veel berichten die over de "Fake Meter" gaat, maar ik kan niet vinden hoe die opgesteld en geïmplementeerd is/wordt. Heeft iemand hier een post of meer info voor/over?

[Taro]

Freemann schreef op maandag 15 december 2025 @ 18:20:
Het virus is hier ingeslagen als een klein bommetje.
De tweede SolarFlow AC 2400 met 4 batterijen is onderweg en brengt het op 2x SF met ieder 3 batterijen.

Dit betekend dat ik al over ga stappen van "zenSDK" naar "Zendure".
Wordt, ook al ben ik pas 2 weken bezig, al een aardig klusje om direct weer alles om te bouwen.

Ondertussen ook een vraagje;
Aks ik het goed begrepen heb, is de "Fake Meter", om zaken buiten de NOM wilt houden?!
Zie veel berichten die over de "Fake Meter" gaat, maar ik kan niet vinden hoe die opgesteld en geïmplementeerd is/wordt. Heeft iemand hier een post of meer info voor/over?

De fakemeter aanpak zet de P1-waarde om naar een alternatieve waarheid die je goed uitkomt. Je haalt er bijv. de waarde van de laadpaal af als je wil dat dat niet uit de accu's komt, of je zorgt voor Slim laden vs Slim ontladen als aanvulling op NOM. Of je neemt de waarde van een slimme stekker erin mee die op je koffiezetapparaat zit aangesloten om die pieken en het pingpongen ervan te voorkomen.

Die fakemeter geef je dan in de Fireson/Zendure integratie op als de meter om te gebruiken.

@Bikkelreal heeft er een aantal berichten over geschreven met uitleg.

Edit: Zie bijv. Bikkelreal in "Zendure producten in Home Assistant integreren"

[ Voor 4% gewijzigd door Taro op 15-12-2025 21:16 ]

[gast777]

Freemann schreef op maandag 15 december 2025 @ 18:20:
De tweede SolarFlow AC 2400 met 4 batterijen is onderweg en brengt het op 2x SF met ieder 3 batterijen.

Dit betekend dat ik al over ga stappen van "zenSDK" naar "Zendure".
Wordt, ook al ben ik pas 2 weken bezig, al een aardig klusje om direct weer alles om te bouwen.

Eventueel kun je gewoon de Gielz zenSDK (als je die gebruikte) blijven gebruiken als je van 1 naar 2 SF devices gaat. Kwestie van Node-Red als addon installeren en deze flow importeren. Dan nog de IP adressen en serienummers invullen, een paar aanpassingen in HA en klaar.

https://github.com/gast777/Zendure-zenSDK-proxy

Deze heb ik dus in elkaar geknutseld en draai het al een tijdje zonder problemen.

[Freemann]

gast777 schreef op maandag 15 december 2025 @ 21:45:
[...]


Eventueel kun je gewoon de Gielz zenSDK (als je die gebruikte) blijven gebruiken als je van 1 naar 2 SF devices gaat. Kwestie van Node-Red als addon installeren en deze flow importeren. Dan nog de IP adressen en serienummers invullen, een paar aanpassingen in HA en klaar.

https://github.com/gast777/Zendure-zenSDK-proxy

Deze heb ik dus in elkaar geknutseld en draai het al een tijdje zonder problemen.

Gaaf!
Node-Red draait hier in Docker, dus dat moet zo aan te slingeren zijn.

Had de hoop dat vandaag de set op de post ging en morgen bezorgd zou worden.
Helaas duurt het waarschijnlijk dagje langer.
Mooi de tijd om morgen even met NodeRed te klooien.

Zojuist uitbreiding voor de groepenkast besteld en hopelijk ook woensdag binnen.
Direct met de mogelijkheid om de boel uit te breiden naar 3x2400W.
Van het weekend de uitbreiding plaatsen en lekker met 2x2400W (ont)laden

[edit]
Flow geïmporteerd en ziet er netjes en duidelijk uit allemaal

[ Voor 3% gewijzigd door Freemann op 15-12-2025 22:18 ]

[gielz]

gast777 schreef op maandag 15 december 2025 @ 21:45:
[...]


Eventueel kun je gewoon de Gielz zenSDK (als je die gebruikte) blijven gebruiken als je van 1 naar 2 SF devices gaat. Kwestie van Node-Red als addon installeren en deze flow importeren. Dan nog de IP adressen en serienummers invullen, een paar aanpassingen in HA en klaar.

https://github.com/gast777/Zendure-zenSDK-proxy

Deze heb ik dus in elkaar geknutseld en draai het al een tijdje zonder problemen.

Bovenstaande heb ik nu ook opgenomen in de TS en Github. Nogmaals bedankt voor de bijdrage! De rest_commands zullen vanaf de Februari release ook al standaard het onderstaande bevatten.

code:

    headers:
      Content-Type: application/json
      Content-Encoding: identity

[gast777]

gielz schreef op maandag 15 december 2025 @ 22:33:
[...]


Bovenstaande heb ik nu ook opgenomen in de TS en Github. Nogmaals bedankt voor de bijdrage! De rest_commands zullen vanaf de Februari release ook al standaard het onderstaande bevatten.

code:

    headers:
      Content-Type: application/json
      Content-Encoding: identity

OK dat is mooi, bedankt!

@Freemann laat maar weten via DM mocht je ergens tegenaanlopen.

[remcoXP]

Thanks!

leuk voor op jou github

gielz schreef op donderdag 11 december 2025 @ 19:38:
[...]


Ik heb 2 Nutsmeters (helpers) aangemaakt die dagelijks de import en export verwerken. En 1 Template sensor (helper) met de volgende code;

p1_vermogen_met_batterij

code:

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

Vervolgens deze apex;

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_aansturing
    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

Hier ziet het er zo uit op de tablet aan de muur;
[Afbeelding]

[Freemann]

gast777 schreef op maandag 15 december 2025 @ 23:02:
[...]


OK dat is mooi, bedankt!

@Freemann laat maar weten via DM mocht je ergens tegenaanlopen.

Zojuist de headers toegevoegd en de Flow in NR geconfigureerd.
Voor beide devices dezelfde serienummers en IP's toegevoegd.
Hij lijkt het goed te doen en telt bijv. het beschikbare capaciteit in HA netjes op.

Hopelijk lukt het DPD toch nog om vandaag te leveren

[ Voor 112% gewijzigd door Freemann op 17-12-2025 10:33 ]

[stfn345]

Zou iemand me een pointer kunnen geven voor het volgende? Ik ben nog niet zo ervaren in HomeAssitant:

Ik heb momenteel ZenSDK actief op de Dynamisch NOM Modus. Daarnaast heb ik een Zappi Laadpaal. Deze heeft een sensor die Chargepower heet: Ik zou graag willen dat als charge power > 0 (dus de EV is aan het laden), dat de Zendure Modus naar "Alleen slim opladen" gaat (en dus geen ontlading richting EV) en dat wanneer deze 0 is, "Dynamisch NOM"

Op welke plek zou ik dit het beste in de zensdk automation kunnen zetten?

[jordyc]

Zoek even op mijn naam of die van @Taro , we hebben een sensor gemaakt die afhankelijk van een switch het ev oplaad vermogen van je p1 meter af haalt. Dan kun je het huis NOM laten draaien terwijl je auto staat te laden.

[Taro]

stfn345 schreef op woensdag 17 december 2025 @ 13:27:
Zou iemand me een pointer kunnen geven voor het volgende? Ik ben nog niet zo ervaren in HomeAssitant:

Ik heb momenteel ZenSDK actief op de Dynamisch NOM Modus. Daarnaast heb ik een Zappi Laadpaal. Deze heeft een sensor die Chargepower heet: Ik zou graag willen dat als charge power > 0 (dus de EV is aan het laden), dat de Zendure Modus naar "Alleen slim opladen" gaat (en dus geen ontlading richting EV) en dat wanneer deze 0 is, "Dynamisch NOM"

Op welke plek zou ik dit het beste in de zensdk automation kunnen zetten?

Zoals @jordyc al zegt: Gebruik even de zoekfunctie, is hier al heel vaak langsgekomen. Ik zou echter niet op basis van Chargepower aan de slag gaan, maar de "Status" entiteit kiezen. Beide zullen wel werken, maar Status is wat meer binair en dan kan je ook makkelijker op een wissel daarvan triggeren.

[Taro]

@FireSon heeft de SF800Plus aan de Zendure HA integratie toegevoegd, deze wordt bij de volgende release ondersteund.

[Taro]

@Bikkelreal of iemand anders: Er zit een bug in de Zendure HA integratie waarbij die rond 100% niet lekker NOM draait, maar pas vanaf 97% ofzo goed gaat lopen. Iemand had al een workaround gevonden door bij behalen 100% de ingestelde max SOC te verlagen en dan ging dat vanaf 100% naar beneden wel direct goed.

Zou iemand die dit probleem ervaart op dat moment de logging voor de integratie aan willen zetten en die log met Fireson willen delen? Ik zal dat de volgende keer dat 100% wordt aangetikt ook doen, maar dat kan wel weer enige tijd duren.

[Bikkelreal]

Ja dat was ik en is nog steeds,

Het gebeurt als de batterij vol is op de ingestelde SOC max, kan ook bv 80% zijn.
En daarna NOM gaat draaien, dan loopt deze niet goed je moet 3% verschil hebben met SOC max en de werkelijke waarde.

version 1.1.4 --- pre-release 10

[ppaulv]

Kan dit iets te maken hebben met wat ik gisteren zag gebeuren : handmatig opladen (op 100W) en dan stopt ie op 98%.

[Taro]

Bikkelreal schreef op zondag 21 december 2025 @ 11:19:
Ja dat was ik en is nog steeds,

Het gebeurt als de batterij vol is op de ingestelde SOC max, kan ook bv 80% zijn.
En daarna NOM gaat draaien, dan loopt deze niet goed je moet 3% verschil hebben met SOC max en de werkelijke waarde.

version 1.1.4 --- pre-release 10

Ok, kan je rondom dat moment de logging aanzetten en met @FireSon delen? Doe ik de volgende keer ook, constateer het hier helaas ook.

[Bikkelreal]

Taro schreef op zondag 21 december 2025 @ 14:56:
[...]

Ok, kan je rondom dat moment de logging aanzetten en met @FireSon delen? Doe ik de volgende keer ook, constateer het hier helaas ook.

Had het al gemeld op github lang geleden ook een ander persoon maar melding is weg, mischien bij de volgende release is het opgelost

[edjes]

Hallo allemaal, ik heb alle 66 pagina's doorgeworsteld.
Inmiddels de Gielz draaien (dank!).
De nordpol nog niet, ik kom er ook niet helemaal uit hoe nu verder met tibber.
Voorlopig zal ik wat handmatige automations maken, dat gaat prima.
Ik kwam wel wat tibber enthousiastelingen tegen, is er iemand die al tibber heeft kunnen integreren in het dynamische gedeelte?
dank!

[dennisdew16]

edjes schreef op maandag 22 december 2025 @ 21:14:
Hallo allemaal, ik heb alle 66 pagina's doorgeworsteld.
Inmiddels de Gielz draaien (dank!).
De nordpol nog niet, ik kom er ook niet helemaal uit hoe nu verder met tibber.
Voorlopig zal ik wat handmatige automations maken, dat gaat prima.
Ik kwam wel wat tibber enthousiastelingen tegen, is er iemand die al tibber heeft kunnen integreren in het dynamische gedeelte?
dank!

Jazeker hoor, ik maak ook gebruik van nordpool en tibber. Waar loop je tegen aan?

[edjes]

dennisdew16 schreef op maandag 22 december 2025 @ 22:24:
[...]

Jazeker hoor, ik maak ook gebruik van nordpool en tibber. Waar loop je tegen aan?

Ik schreef erg onduidelijk zie ik nu; ik bedoelde is het mogelijk om tibber te integreren zonder nordpol, dus rechtstreeks vanuit hun gegevens? Dat zou toch moeten kunnen. Ik heb nu alleen de actuele prijs, waar ik op zich ook wel wat mee kan. Ik lees in de afgelopen berichten van niet beschikbaar zijn van gegevens van nordpool en dan niet werkende automations.

Dank!!

[dennisdew16]

edjes schreef op dinsdag 23 december 2025 @ 08:46:
[...]


Ik schreef erg onduidelijk zie ik nu; ik bedoelde is het mogelijk om tibber te integreren zonder nordpol, dus rechtstreeks vanuit hun gegevens? Dat zou toch moeten kunnen. Ik heb nu alleen de actuele prijs, waar ik op zich ook wel wat mee kan. Ik lees in de afgelopen berichten van niet beschikbaar zijn van gegevens van nordpool en dan niet werkende automations.

Dank!!

Ah dat is wat anders inderdaad Dat zou ik eigenlijk niet weten. Mogelijk dat het werkt maar dan zal je handmatig dingen in de code moeten aanpassen denk ik. Aangezien nu alles via de nordpool sensor betekent wordt.
Al moet ik zeggen dat mijn nordpool sensor nog nooit problemen heeft opgeleverd. Ik zou als ik jou was het gewoon een kans geven.

[gielz]

@edjes De reden dat eigenlijk bijna iedereen de sturing via Nordpool HACS doet is omdat je dan niet afhankelijk bent van je leverancier.

Stel je gaat straks naar bijvoorbeeld zonneplan dan moet je dingen gaan ombouwen.

[edjes]

Okido! Dank!
@gielz Overigens dikke complimenten voor je code, zoveel meer controle dan de app.
@dennisdew16 Voeg je dan ergens de additionele kosten toe? ik zag ergens daar code van voorbij komen. Zodat je nog een beetje idee hebt wat de prijs is tov Tibber zelf. Of laat je 'm gewoon dynamisch laden op de nordpol omdat het toch nagenoeg overeen komt?

[Jheroun]

Ik ben de Github uitleg van @gielz aan het volgen. Daar loop ik nu vast na het maken van de automation. Ik heb de entiteit aan het thuisdashboard toegevoegd (na veel zoeken want wat een doolhof is HA voor een noob...)

Dat lijkt nog in niets op de screenshot op de Github. Bij mij ziet het er zo uit:

Wat niet helpt is dat de configuratieknop in HA bij ieder dashboard tot een andere popup lijkt te leiden, die er anders uitziet.

Misschien hangt het samen met: Ik zie de 2400AC nu wel in HA, maar de P1 meter niet. Ik heb de Zendure P1 meter. Als ik die entiteit aanklik staat in het veld wel het juiste IP adres, maar hij lijkt er niets mee te doen. Mijn energieoverzicht ziet er zo uit:


Iemand een idee wat ik hier verkeerd doe?

[edjes]

DJN schreef op woensdag 1 oktober 2025 @ 11:10:
Voor Tibber gebruikers: prijs per kwartier ipv per uur zodat de sensor.tibber_prices 96 datapoints krijgt ipv 24

YAML:

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

[Afbeelding]

YAML:

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

Is deze te vertalen naar de nieuwe PLATFORM commands van HA?
Iemand een voorbeeld?
Of beter de prijs berekenen in de config.yaml. Iemand daar de som al gemaakt (kan bij tibber niet de opbouw van de prijs vinden)
Of een voorbeeld van prijsberekening per 15 min voor Tibber?

Dank!

[ Voor 3% gewijzigd door edjes op 23-12-2025 17:53 ]

[Bart_Denon]

Hoi allemaal,
Ik ben relatief nieuw hier. Heb sinds oktober een SF800 pro.
Deze zit alleen op AC en als proef om te kijken hoe t wekt met HA en wat simpele automatiseringen.
Nu draaide die tot voor kort probleemloos tot 2 dagen geleden toen ik foutcode 25 communicatiefout kreeg.
Aansturing loopt via HA met de Zendure integratie via HACS.
Ik heb een vrij simpele automatisering die overdag na zonsopgang naar slim opladen gaat en rond zonsondergang naar slim ontladen. So far so good en de aansturing via de zogenaamde Zendure manager ging foutloos.
Helaas is dit opeens niet meer zo en kan ik de SF800 niet meer sturen met de commando’s uit de Zendure manager…
Ook blijft hierin de beschikbare capaciteit op 0,0kWh staan…
Zeer vreemd. Aansturing vanuit de bediening werkt wel maar ik wil graag nom slim laden en ontladen.


Heeft iemand een idee?
Heb de hele integratie in HA al 2x verwijderd en weer geïnstalleerd ook de vanuit de app verwijderd en weer toegevoegd zonder resultaat..
ik zoek eigenlijk een mayor reset maar wat is daarvan t procedé?

Alvast bedankt!

[Taro]

@Bart_Denon Heb je de logging van de integratie al aangezet en daar in gekeken? Grote kans dat je daar de oorzaak vindt. Bij een evt. bug kan je die op de GitHUB of met Fireson delen.

Workaround: Je kunt proberen de naam van je product in de Zendure App te veranderen en de integratie te herladen. Mogelijk wordt die dan als nieuw apparaat gezien. Maar het beste is de debug logging aan te zetten.

[dennisdew16]

edjes schreef op dinsdag 23 december 2025 @ 10:55:
Okido! Dank!
Overigens dikke complimenten voor je code, zoveel meer controle dan de app.
@dennisdew16 Voeg je dan ergens de additionele kosten toe? ik zag ergens daar code van voorbij komen. Zodat je nog een beetje idee hebt wat de prijs is tov Tibber zelf. Of laat je 'm gewoon dynamisch laden op de nordpol omdat het toch nagenoeg overeen komt?

Ik heb de nordpool sensor zo gemaakt dat de prijs exact gelijk is aan de tibber sensor. Je dient trouwens de custom nordpool integratie te gebruiken en niet de standaard vanuit HA. Ik weet even niet meer welke waarden ik heb aangepast maar dingen zoals btw etc kan je gewoon invoeren bij het configureren van de sensor.

[Hieke]

Jheroun schreef op dinsdag 23 december 2025 @ 11:41:
Ik ben de Github uitleg van @gielz aan het volgen. Daar loop ik nu vast na het maken van de automation. Ik heb de entiteit aan het thuisdashboard toegevoegd (na veel zoeken want wat een doolhof is HA voor een noob...)

Dat lijkt nog in niets op de screenshot op de Github. Bij mij ziet het er zo uit:
[Afbeelding]
Wat niet helpt is dat de configuratieknop in HA bij ieder dashboard tot een andere popup lijkt te leiden, die er anders uitziet.

Misschien hangt het samen met: Ik zie de 2400AC nu wel in HA, maar de P1 meter niet. Ik heb de Zendure P1 meter. Als ik die entiteit aanklik staat in het veld wel het juiste IP adres, maar hij lijkt er niets mee te doen. Mijn energieoverzicht ziet er zo uit:
[Afbeelding]

Iemand een idee wat ik hier verkeerd doe?

Met de informatie die je nu deel is het is nog niet helemaal duidelijk of je ook de Zendure omvormer zelf al hebt toegevoegd in HA...???
Dat doe je via Instellingen, Apparaten en diensten, Entiteiten.



Als je dan die entiteit hebt toegevoegd op het dashboard van je dashboard voor Zendure krijg je dan zoiets te zien:



Wat je energiedashboard betreft is mijn advies: laat dat even met rust en richt eerst een nieuw, afzonderlijk dashboard in waar je alle entiteiten op plaatst die met de Zendure te maken hebben..

Want zover ik het overzie er is geen directe relatie tussen die 2 voor een goede werking van de Zendure.
Hierbij een inkijkje in het dashboard dat je dan kunt bouwen met de entiteiten van Gielz;



Hopelijk kun je met deze info verder? Anders laat maar weten.

[edjes]

dennisdew16 schreef op dinsdag 23 december 2025 @ 19:43:
[...]

Ik heb de nordpool sensor zo gemaakt dat de prijs exact gelijk is aan de tibber sensor. Je dient trouwens de custom nordpool integratie te gebruiken en niet de standaard vanuit HA. Ik weet even niet meer welke waarden ik heb aangepast maar dingen zoals btw etc kan je gewoon invoeren bij het configureren van de sensor.

Kosten Tibber:

Gelukt met wat hulp van chatgpt.
https://support.tibber.co...5892-de-kosten-bij-tibber
hier staan de kosten (inclusief BTW)
de variabele opslag staat er niet bij, maar hier wel: https://eerlijkverbruik.nl/energie/tibber
voor 2026 komt dat neer op dit invullen bij 'template for additional costs': {{ 0.0248 + 0.1108 }} of {{ (0.0248 * 1.21) + 0.1108 }} als die 2 cent exclusief BTW is, boeie.
en dan klopt de prijs!!
Dank voor meedenken en sturen.

[ Voor 4% gewijzigd door edjes op 23-12-2025 21:30 ]

[Bart_Denon]

Taro schreef op dinsdag 23 december 2025 @ 17:38:
@Bart_Denon Heb je de logging van de integratie al aangezet en daar in gekeken? Grote kans dat je daar de oorzaak vindt. Bij een evt. bug kan je die op de GitHUB of met Fireson delen.

Workaround: Je kunt proberen de naam van je product in de Zendure App te veranderen en de integratie te herladen. Mogelijk wordt die dan als nieuw apparaat gezien. Maar het beste is de debug logging aan te zetten.

Dank je voor je reactie. De debug logging gebprobeerd alleen kan ik t bestand niet meer terugvinden
Ga ik nog maar een keer proberen.
Integratie herladen met een nieuwe benaming ook al geprobeerd maar werkt niet.
Ik vind t heel raar dat de ene sensor wel de beschikbare capaciteit aangeeft en die in de manager niet, dit zou toch van 1 en dezelfde bron moeten komen ?

[R.K]

Weet iemand hoe het kan dat ik voor verwijderde integraties steeds update meldingen krijg?

[Hieke]

R.K schreef op woensdag 24 december 2025 @ 11:20:
Weet iemand hoe het kan dat ik voor verwijderde integraties steeds update meldingen krijg?

Ik verwijder de mappen van die betreffende integraties handmatig via de file-editor van HA en geef vervolgens een reboot. Dan verdwijnt de melding na enige tijd.

Disclaimer: Alles op eigen risico!

[hapklaar]

Jheroun schreef op maandag 15 december 2025 @ 15:00:
[...]

Ik krijg inmiddels wel eea over de batterij te zien, maar de afwijkende P1 doet het nog niet (is een zendure P1 meter). Ik heb wel het IP adres van de meter ingevuld in het invulveld, die staat daar nu op dezelfde manier als het IP van de 2400AC, dus dat lijkt me dan goed. Maar statistieken van de P1 zie ik nog niet.


[...]

Hier ging ik ook de mist in, hier moet geen IP adres komen te staan. Bij afwijkende P1 sensor moet je een sensor entity invullen die het totaal van je P1 weergeeft in W volgens mij. (- bij teruglevering en + bij afname)
Toen ik dat had gedaan werd 'P1 Aansturing Vermogen' ook gevuld.

[hapklaar]

Aangezien ik geen DSMR5 meter heb, maar eentje die slechts 1x per 10 seconden de status doorgeeft, wil ik een andere stroomverbruiksmeter aanschaffen die dit 1x per seconde doet voor NOM.

Ik zie dat hier voornamelijk de Zendure 3CT of de Shelly 3EM voor worden gebruikt. De Shelly lijkt me wat breder toepasbaar en heeft zo te zien meer opties voor uitlezen, mijn voorkeur gaat dan ook uit naar deze. Wat is jullie idee hierover?

[Taro]

hapklaar schreef op donderdag 25 december 2025 @ 18:36:
Aangezien ik geen DSMR5 meter heb, maar eentje die slechts 1x per 10 seconden de status doorgeeft, wil ik een andere stroomverbruiksmeter aanschaffen die dit 1x per seconde doet voor NOM.

Ik zie dat hier voornamelijk de Zendure 3CT of de Shelly 3EM voor worden gebruikt. De Shelly lijkt me wat breder toepasbaar en heeft zo te zien meer opties voor uitlezen, mijn voorkeur gaat dan ook uit naar deze. Wat is jullie idee hierover?

Ga altijd voor de breed inzetbare optie, de Shelly (Pro) 3EM is veel breder inzetbaar dan de Zendure 3CT.

[geert1992]

Update voor Fireson zijn integratie is uit! 1.2.0!

What's Changed
New devices:
SF800 Plus
SuperBase v4600
AB2000X
New/updated entities:
Zendure manager total active power
Devices fan control
Off-grid entities
Autoheat
HEMS status
Improved power distribution in combination with solar panels
Improved bypass handling
Improved solaronly discharge
Optimize inverter working range
Improved FuseGroup distribution

[ Voor 78% gewijzigd door geert1992 op 27-12-2025 13:06 ]

[jordyc]

zie ik daar nou device fan control in de lijst staan......

[HeadHunter242]

k Heb gisteren de nieuwe firmware (1.0.15) op de zendure AC2400 geïnstalleerd en ook in home assistant de HACS Zendure integratie een update gegeven. Sindsdien stopt de batterij geregeld met ontladen. Dan moet ik de stekker uittrekken, weer insteken en dan werkt het weer.
Zijn er nog die dit probleem vaststellen? Ik draai de batterij met smart matching voor 0 op de meter.

Voorlopige fix bij mij is een slimme plug ertussen, in combinatie met een automatisatie in homeassistant om de reset op de batterij te forceren.

[Sander]

HeadHunter242 schreef op zondag 28 december 2025 @ 07:14:
k Heb gisteren de nieuwe firmware (1.0.15) op de zendure AC2400 geïnstalleerd en ook in home assistant de HACS Zendure integratie een update gegeven. Sindsdien stopt de batterij geregeld met ontladen. Dan moet ik de stekker uittrekken, weer insteken en dan werkt het weer.
Zijn er nog die dit probleem vaststellen? Ik draai de batterij met smart matching voor 0 op de meter.

Voorlopige fix bij mij is een slimme plug ertussen, in combinatie met een automatisatie in homeassistant om de reset op de batterij te forceren.

Hier krijg ik notificaties dat de actie niet kan worden uitgevoerd in Homeassistant. Als ik dan de integratie herlaad gaat het wel weer goed.

[HeadHunter242]

Sander schreef op zondag 28 december 2025 @ 08:20:
[...]


Hier krijg ik notificaties dat de actie niet kan worden uitgevoerd in Homeassistant. Als ik dan de integratie herlaad gaat het wel weer goed.

Heb inderdaad ook alles moeten herladen na de update van firmware op de batterij en HACS integratie. Heb dat gedaan met een volledige HA herstart. De batterij is voor het eerst vastgelopen 7u later en dan nog eens een kleine 2u na de stekker uit/in.

[mtimmerm]

Ik ben even aan het kijken of ik de laad uren en ontlaad uren automatisch kan bereken en laten invullen. Ik doe dit op basis van kosten. Zou dit handig zijn?

code:

{% set prijzen = state_attr('sensor.zonneplan_dagelijkse_prijzen', 'prices') or [] %}
{% set start_tomorrow = now().replace(hour=0, minute=0, second=0, microsecond=0) + timedelta(days=1) %}
{% set end_tomorrow = start_tomorrow + timedelta(days=1) %}
{% set start_ts = start_tomorrow | as_timestamp %}
{% set end_ts = end_tomorrow | as_timestamp %}

{% set soc = states('sensor.zendure_2400_ac_laadpercentage') | float(0) %}
{% set MAX_LAAD_UREN = [((95 - soc) / 30) | round(0, 'ceil') | int, 3] | min %}


{% set MIN_DIFF = 0.042 %}
{% set max_diff = 0 %}
{% set MAX_ONTLAAD_UREN = 6 %}

{% set ns = namespace(
  morgen=[],
  best_margin=5,
  best_diff=0,
  best_goedkoop=0,
  best_duur=0
) %}


{% for p in prijzen %}
  {% set ts = p.timestamp | as_timestamp %}
  {% if ts >= start_ts and ts < end_ts %}
    {% set ns.morgen = ns.morgen + [p] %}
  {% endif %}
{% endfor %}

{% if ns.morgen | length > 0 %}
  {% set sorted = ns.morgen | sort(attribute='price') %}
  {% set min_val = sorted[0] %}
  {% set max_val = sorted[-1] %}
{% else %}
  {% set min_val = none %}
  {% set max_val = none %}
{% endif %}

{% if min_val is not none and max_val is not none %}
  {% set max_diff = max_val.price-min_val.price %}
  {% if max_diff | float > MIN_DIFF %}
      {% for cheap_count in range(0, MAX_LAAD_UREN+1) %}
        {% for expensive_count in range(1, MAX_ONTLAAD_UREN+1) %}
      
          {% set goedkoop = sorted[0:cheap_count] %}
          {% set duur = sorted[-expensive_count:] %}
      
          {% if goedkoop | length == cheap_count and duur | length == expensive_count %}
            {% if cheap_count == 0 %}
              {% set min_avg = min_val.price * 1.01 %}
            {% else %}
              {% set min_avg = (goedkoop | map(attribute='price') | list | sum) / cheap_count %}
            {% endif %}
            {% set max_avg = (duur | map(attribute='price') | list | sum) / expensive_count %}
            {% set diff = max_avg - min_avg %}
            {% set margin = diff - MIN_DIFF %}
            {% set rendabel = diff >= MIN_DIFF %}
      
            {% if rendabel and margin < ns.best_margin %}
              {% set ns.best_margin = margin %}
              {% set ns.best_diff = diff %}
              {% set ns.best_goedkoop = cheap_count %}
              {% set ns.best_duur = expensive_count %}
            {% endif %}
          {% endif %}
        {% endfor %}
      {% endfor %}

      {% set laad_tijden = (sorted[0:ns.best_goedkoop] | map(attribute='timestamp') | list) %}
      {% set ontlaad_tijden = (sorted[-ns.best_duur:] | map(attribute='timestamp') | list) %}
      
      {% if ns.best_diff > 0 %}
        {{
          {
            "max_laad_uren" : MAX_LAAD_UREN,
            "laad_uren": ns.best_goedkoop,
            "laad_tijden": laad_tijden,
            "ontlaad_uren": ns.best_duur,
            "ontlaad_tijden": ontlaad_tijden,
            "prijsverschil": ns.best_diff | round(5),
            "max_prijsverschil" : max_diff | round(5),
            "rendabel": ns.best_diff >= MIN_DIFF
          }
        }}
      {% endif %}
  {% endif %}
{% endif %}
{% if ns.best_diff == 0 %}
        {{
          {
            "max_laad_uren" : MAX_LAAD_UREN,
            "laad_uren": 0,
            "ontlaad_uren": 0,
            "prijsverschil": 0,
            "max_prijsverschil" : max_diff | round(5)
          }
        }}
{% endif %}

[Leguan]

Mochten er mensen zijn die net als ik 3 Zendure Solarflow 2400 AC's hebben staan en de boel via Home Assistant aan willen (laten) sturen, ik heb de node-red flow van @gast777 aangepast zodat deze werkt met 3 omvormers. Draait nu een paar dagen en lijkt allemaal goed te gaan. Bij interesse kan ik het eventueel op Git zetten of via DM delen.

Zowel @gielz als @gast777 complimenten voor hun goede werk!

Volgende stap op deze integraties zou het automatisch berekenen van het aantal benodigde goedkope uren/kwartieren zijn, zodat als de zonnepanelen de accu's niet vol krijgen in de winter deze netjes met de voordeligste stroom wordt aangevuld (mits voldoende spread). Er zit nu nog wat werk aan om dagelijks/wekelijks de instelling zodanig goed te zetten dat de accu precies op de sweet spot draait.

[Leguan]

Ik probeer de fake p1 meter zo in te richten dat de quooker piek van kortstondig +2000W wordt genegeerd door de accu. De simpele variant door de quooker waarde van de p1 waarde af te trekken leidt tot timing issues. Daardoor heb ik tijdens het beginmoment nog steeds een piek en vlak na het eindmoment een negatieve piek. Heeft iemand het al voor elkaar om bij timing issues (het quooker vermogen wordt door de shelly stekker gemeten) de quooker alsnog uit te filteren? Chatgpt stelt een moving average sensor voor, en ik heb dat geprobeerd. Maar het is me tot op heden nog niet gelukt.... Ben benieuwd wat hierin de beste aanpak is.

[R.K]

Ik kan vanmorgen sinds de update van de Home Assistant Integration niet meer de resterende ontlaadtijd zien. Op zich niet zo'n groot probleem, maar hebben jullie dat ook?

[martinvdm]

Wat gebruik je? Gielz of ZendureSDK?

[ Voor 4% gewijzigd door martinvdm op 29-12-2025 18:31 ]

[R.K]

martinvdm schreef op maandag 29 december 2025 @ 18:31:
Wat gebruik je? Gielz of ZendureSDK?

Ik gebruik Gielz, maar heb wel de Zendure Home Assistant Integration in integraties staan.

[martinvdm]

R.K schreef op maandag 29 december 2025 @ 18:36:
[...]

Ik gebruik Gielz, maar heb wel de Zendure Home Assistant Integration in integraties staan.

Uh ja, maar welke sensor vanuit welke integrate werkt er niet? Je zult iets duidelijker moeten zijn wil iemand je kunnen helpen vrees ik.

[R.K]

[R.K]

Zie bij resterende ontlaadtijd

[R.K]

[xobdorp]

R.K schreef op maandag 29 december 2025 @ 21:36:
[Afbeelding]

Dat veld is hernoemd, bij mij heet ie nu

code:

 sensor.solarflow_2400_ac_remaining_time

.

[R.K]

Voordat ik de Gielz aansturing ging gebruiken had ik voor monitoring de Zendure integratie geinstalleerd in HA voor monitoring, toen ik overstapte op de Gielz aansturing is die Zendure Integratie in Ha blijven staan. Op zich is dat m.i. geen probleem maar bij het maken van mijn dashboard voor de Solarflow heb ik sensoren van zowel de restful integratie alswel de Zendure Integratie gebruikt, waar ik m.i. beter alleen maar de sensoren van de restful integratie had moeten gebruiken. Dat heb ik nu aangepast. Nu klopt alles weer.

[gielz]

jordyc schreef op zaterdag 27 december 2025 @ 15:30:
zie ik daar nou device fan control in de lijst staan......

Werkt dit ook? Laatste wat ik heb vernomen is dat deze controls read only zijn in de zensdk.

[martinvdm]

gielz schreef op dinsdag 30 december 2025 @ 22:16:
[...]


Werkt dit ook? Laatste wat ik heb vernomen is dat deze controls read only zijn in de zensdk.

Ik heb laatst de api nog eens getest met rest commands en kwam tot dezelfde conclusie, idd read only. Zo staat het ook in de docs meen ik. Mogelijk dat dit voor andere modellen geld? Ik heb het zelf nog niet getest iig

[Taro]

gielz schreef op dinsdag 30 december 2025 @ 22:16:
[...]


Werkt dit ook? Laatste wat ik heb vernomen is dat deze controls read only zijn in de zensdk.

Nee, is helaas nog steeds read-only.

[hapklaar]

Wat is jullie manier om in Home Assistant iedere seconde een update te krijgen van de Shelly Pro 3EM voor fijn NOM gedrag? In de Shelly integratie en via MQTT is dit nogal variabel, soms duurt het wel 15 secs voor er een update komt, terwijl er echt wel variatie is in het verbruik in die periode. WIFI connectie is dikke prima en in de webinterface heb ik geen opties kunnen vinden om dit vaker te publiceren.

[StarWing]

Geen shelly, maar ik lees de zendure P1 uit via rest, dit gaat iedere seconde.

[hapklaar]

hapklaar schreef op woensdag 31 december 2025 @ 19:02:
Wat is jullie manier om in Home Assistant iedere seconde een update te krijgen van de Shelly Pro 3EM voor fijn NOM gedrag? In de Shelly integratie en via MQTT is dit nogal variabel, soms duurt het wel 15 secs voor er een update komt, terwijl er echt wel variatie is in het verbruik in die periode. WIFI connectie is dikke prima en in de webinterface heb ik geen opties kunnen vinden om dit vaker te publiceren.

fyi, als iemand hier ook naar op zoek is. Heb dit kunnen fixen met een script in de Shelly Pro 3EM, die ervoor zorgt dat MQTT iedere seconde een bericht uitstuurt.

MQTT update rate

code:

let SHELLY_ID = undefined;
Shelly.call("Mqtt.GetConfig", "", function (res, err_code, err_msg, ud) {
  SHELLY_ID = res["topic_prefix"];
});

function timerHandler(user_data)
{
  let em = Shelly.getComponentStatus("em", 0);
         MQTT.publish(SHELLY_ID + "/status/em:0",JSON.stringify(em),1,false);
 }
Timer.set(1000, true, timerHandler, null);

En nog eentje voor autodiscovery in Home Assistant van MQTT entities (bron):

code:

let CONFIG = {
  
  temperature_unit: "C",            // C or F - Uppercase!!!
  disable_minor_entities: true,     // Some entities will be disabled by default (can be enabled later in HA), see DISABLED_ENTS 
  ignore_names: true,               // If true, device and channel names configured withing Shelly will not be used. Configure them in HA. It's less error prone approach
  
  report_ip: true,                  // create URL link to open Shelly GUI from HA
  fake_macaddress: "",              // for testing purposes, set alternative macaddress

  discovery_topic: "homeassistant",
  mqtt_publish_pause: 500,          // (milliseconds) discovery entities will are published to MQTT entry-by-entry with pause inbeetween

  components_refresh: ["wifi", "temperature:0"],
  components_refresh_period: 60     // (seconds) how often report components above to mqtt
};

const COMPONENT_TYPES = ["switch", "pm1", "wifi", "em", "em1", "emdata", "em1data", "temperature", "cover",];
const SUPPORTED_ATTRS = ["apower", "aprt_power", "voltage", "freq", "current", "pf", "aenergy", "ret_aenergy", "output", "rssi", "temperature", "tC", "tF", "state"];

const CAT_DIAGNOSTIC = ["rssi","temperature"];
const DISABLED_ENTS = ["pf", "voltage", "freq", "current", "ret_aenergy"];

const ALIASES = {
  "a_current": "current",
  "b_current": "current",
  "c_current": "current",
  "a_voltage": "voltage",
  "b_voltage": "voltage",
  "c_voltage": "voltage",
  "a_freq": "freq",
  "b_freq": "freq",
  "c_freq": "freq",
  "a_pf": "pf",
  "b_pf": "pf",
  "c_pf": "pf",
  "act_power": "apower",
  "a_act_power": "apower",
  "b_act_power": "apower",
  "c_act_power": "apower",
  "total_act_power": "apower",
  "a_aprt_power": "aprt_power",
  "b_aprt_power": "aprt_power",
  "c_aprt_power": "aprt_power",
  "total_aprt_power": "aprt_power",
  "total_act_energy": "aenergy",
  "total_act_ret_energy": "ret_aenergy",
  "a_total_act_energy": "aenergy",
  "b_total_act_energy": "aenergy",
  "c_total_act_energy": "aenergy",
  "a_total_act_ret_energy": "ret_aenergy",
  "b_total_act_ret_energy": "ret_aenergy",
  "c_total_act_ret_energy": "ret_aenergy",
  "total_act": "aenergy",
  "total_act_ret": "ret_aenergy",
  "tF": "temperature",
  "tC": "temperature"
}

const DEVCLASSES = {
  "apower": "power",
  "aprt_power": "apparent_power",
  "voltage": "voltage",
  "freq": "frequency",
  "current": "current",
  "pf": "power_factor",
  "aenergy": "energy",
  "ret_aenergy": "energy",
  "temperature": "temperature",
  "switch": "switch", // from docs: possible none, switch, outlet
  "rssi": "signal_strength",
  "light": "light",
  "state": null,
}

const NAMES = {
  "apower": "Active Power",
  "aprt_power": "Aparent Power",
  "voltage": "Voltage",
  "freq": "Frequency",
  "current": "Current",
  "pf": "Power Factor",
  "aenergy": "Active Energy",
  "ret_aenergy": "Returned Active Energy",
  "temperature": "Temperature",
  "output": "Switch",
  "rssi": "RSSI",
  "light": "Light",
  "state": "Cover",
}

const UNITS = {
  "apower": "W",
  "aprt_power": "VA",
  "voltage": "V",
  "freq": "Hz",
  "current": "A",
  "aenergy": "Wh",
  "ret_aenergy": "Wh",
  "tC": "°C",
  "tF": "°F",
  "rssi": "dBm"
}

const DOMAINS = {
  "apower": "sensor",
  "aprt_power": "sensor",
  "voltage": "sensor",
  "freq": "sensor",
  "current": "sensor",
  "aenergy": "sensor",
  "ret_aenergy": "sensor",
  "tC": "sensor",
  "tF": "sensor",
  "state": "cover", //(was binary_sensor but I don't where appplied)
  "output": "switch",
  "pf": "sensor",
  "rssi": "sensor",
  "temperature": "sensor"
  // switch and light matches domain name, not here to save memory
}

/**
 * Normalize MAC address removing : and - characters, and making the rest lowercase
 * @param {string} address MAC address
 * @returns {string} normalized MAC address
 */
function normalizeMacAddress(address) {
  return String(address).split("-").join("").split(":").join("").toLowerCase();
}

/**
 * Function creates and returns a device data in format requierd by MQTT discovery.
 *
 * Device name is built from its mac address and model name.
 *
 * @param {Object} deviceInfo - object with device information, including:
 * @param {string} deviceInfo.app - Device application/model name (e.g., "Plus 1PM")
 * @param {string} deviceInfo.model - Device model identifier (e.g., "SHPLG-S")
 * @param {string} deviceInfo.ver - Firmware version (e.g., "1.0.0")
 * @param {number|string} deviceInfo.gen - Device generation (e.g., 2)
 * @param {string} deviceInfo.mac - MAC address (e.g., "B8:D6:XX:XX:XX:XX")
 * @param {string} [deviceInfo.name] - Optional user-defined device name
 * @returns {Object} The device object with the following structure:
 */
function discoveryDevice(deviceInfo) {

  const macaddress = normalizeMacAddress(CONFIG.fake_macaddress ? CONFIG.fake_macaddress : deviceInfo.mac);

  let device = {};
  device.name = deviceInfo.name && !CONFIG.ignore_names ? deviceInfo.name : macaddress + "-" + deviceInfo.app;
  device.ids = [macaddress + ""];
  device.cns = [["mac", macaddress + ""]];
  device.mf = "Shelly"
  device.mdl = "Shelly " + deviceInfo.app;
  device.mdl_id = deviceInfo.model;
  device.sw = deviceInfo.ver;
  device.hw = "gen " + deviceInfo.gen;
  
  if (CONFIG.report_ip) {
    device.cu = "http://" + Shelly.getComponentStatus("wifi").sta_ip;
  }

  return device;
}

/**
  * Returns a template for value extraction from MQTT message.
  * The template is based on the attribute type and its device class.
  *
  * @param {object} info - attribute name for which the template is to be created
  * @returns {string} - template string for extracting value from MQTT message
  */
function getValTpl(info) {
  let devclass = getDeviceClass(info.attr);

  if (info.attr == "aenergy") return "{{ value_json." + info.attr + ".total }}";
  if (info.attr == "output") return "{{ 'on' if value_json.output else 'off' }}";
  if (info.attr == "temperature") return "{{ value_json." + info.attr + ".t" + CONFIG.temperature_unit + " }}";

  // switch (devclass) {
  //   case "energy":
  //     return "{{ value_json." + attr + ".total }}";
  //   case "switch":
  //   case "light":
  //     return "{{ 'on' if value_json.output else 'off' }}";
  //   case "temperature":
  //     return "{{ value_json." + attr + ".t" + CONFIG.temperature_unit + " }}";
  // }

  return "{{ value_json." + info.attr + " }}";
}

/**
 * Generates a unique identifier for the entity based on its MAC address, attribute, and index.
 * The identifier is formatted as "mac_address_attribute_index", where attribute is Shelly component name, and index is optional.
 * This way it never change even if you configure switch to be the light.
 * @param {object} info - Object containing information about the entity, including its MAC address, topic, and attribute
 * @returns {string} - Unique identifier for the entity
 */
function getUniqueId(info) {
  return info.mac + "_" + info.topic.split(":").join("") + "_" + info.attr;
}

/**
 * Returns the unit of measurement for the given attribute.
 * If the attribute is temperature, it appends the configured temperature unit (C or F).
 * If the attribute is not recognized, it returns null.
 * @param {string} attr - Attribute name for which the unit is to be retrieved
 * @returns {string|null} - Unit of measurement for the attribute, or null if not recognized
 */
function getUnits(attr) {
  if (attr == "temperature") attr = "t" + CONFIG.temperature_unit;
  if (UNITS[attr] === undefined) return null;
  return UNITS[attr];
}

/**
  * Returns a human-readable name for the entity based on its attribute and index.
  * Determines a user-friendly name for the entity based on its type and available information.
  * @param {Object} info - Object containing information about the entity, including its attribute, index, and name.
  * @returns {string} - Human-readable name for the entity
  */
function getName(info) {

  if ( info.name && (info.attr_common == 'switch' || info.attr_common == 'light' )) {
    return info.name;
  }

  let name;
  if (NAMES[info.attr_common]) name = NAMES[info.attr_common];
  else name = info.attr_common;

  if (info.name) name = info.name + " " + name;
  else if (info.ix >= 0 && !info.issingle) name = name + " " + (info.ix+1);

  if (info.attr != info.attr_common && (info.comp == "em" || info.comp == "emdata")) name = name + " " + info.attr.split("_")["0"].toUpperCase();
 
  return name;
}

/**
 * Retrieves the common attribute value for the specified attribute name.
 *
 * @param {string} attr - The name of the attribute to retrieve.
 * @returns {string} The value of the specified common attribute.
 */
function getCommonAttr(attr) {
  if (ALIASES[attr] === undefined) return attr;
  return ALIASES[attr];
}

/** 
 * Returns the device class for the given attribute.
 * If the attribute is not recognized, it returns the attribute name itself.
 * This is used to determine how the entity should be represented in Home Assistant.
 * @param {string} attr - Attribute name for which the device class is to be retrieved
 * @returns {string} - Device class for the attribute, or the attribute name if not recognized
 */
function getDeviceClass(attr) {
  if (DEVCLASSES[attr] === undefined) return attr;
  return DEVCLASSES[attr];
}

/**
  * Returns the entity domain for the given attribute.   
  * The domain is used to categorize the entity in Home Assistant.
  * If the attribute is not recognized, it returns the attribute name itself.
  * @param {string} attr - Attribute name for which the domain is to be retrieved
  * @returns {string} - Domain for the attribute, or the attribute name if not recognized
  */  
function getDomain(attr) {
  if (DOMAINS[attr] !== undefined) return DOMAINS[attr];
  return attr;
}


/**
 * Builds data of single entity to be published to MQTT discovery
 * @param {string} topic Object identifier used for preventing repeating discovery topic creation. Will be returned back in the result struct
 * @param {Object} info Data needed to build the MQTT discovery obejct
 * @param {string} info.attr Attribute of the entity reported by component status (also reported to MQTT), e.g. "apower", "voltage", a_voltage, b_voltage etc.
 * @param {string} info.attr_common Like `attr` but translated to common value, for example `a_voltage`, `b_voltage` translated to `voltage`
 * @param {string} info.comp Component type, e.g. "switch", "pm1", etc.
 * @param {number} info.ix Index of the entity within the component, used for components with multiple instances
 * @param {string} info.topic Topic name the component status data is reported to.
 * @param {string} info.altdomain Alternative domain for the entity, if applicable.
 * @param {string} info.mac MAC address of the device, used for unique identification
 * @returns {Object} Object with data for publishing to MQTT
 */
function discoveryEntity(topic, info) {
  let attr_orig = info.attr_common;
  
  if (info.attr == "output") {
    if (info.altdomain) info.attr_common = info.altdomain;
    else info.attr_common = info.comp
  }

  let domain = getDomain(info.attr_common);
  let pload = {};

  pload["name"] = getName(info);
  pload["uniq_id"] = getUniqueId(info);
  pload["stat_t"] = topic + "/status/" + info.topic;
  pload[info.attr_common == "light" ? "stat_val_tpl" : "val_tpl"] = getValTpl(info);
  pload.dev_cla = getDeviceClass(info.attr_common);
  
  if (pload.dev_cla == "energy") {
    pload["stat_cla"] = "total_increasing";
  } else if (domain == "sensor") {
    pload["stat_cla"] = "measurement";
  }

  switch (domain) {
    case "switch":
    case "light":
      pload["cmd_t"] = topic + "/command/" + info.topic;
      pload["pl_on"] = "on";
      pload["pl_off"] = "off";
      break;
    case "sensor":
      pload["unit_of_meas"] = getUnits(info.attr_common);
      break;
    case "cover":
      let slat = Shelly.getComponentConfig(info.topic).slat;
      let pos = Shelly.getComponentStatus(info.topic).pos_control;

      pload["cmd_t"] = topic + "/command/" + info.topic;
      pload["pl_open"] = "open";
      pload["pl_stop"] = "stop";
      pload["pl_cls"] = "close";
      pload["opt"] = false;

      if (pos) {
        pload["pos_t"] = pload["stat_t"];
        pload["pos_tpl"] = "{{ value_json.current_pos }}"
        pload["set_pos_t"] = pload["cmd_t"];
        pload["set_pos_tpl"] = "pos,{{ position }}";
      }
      
      if (pos && slat && slat.enable) {
        pload["tilt_cmd_tpl"] = "slat_pos,{{ tilt_position }}";
        pload["tilt_cmd_t"] = pload["cmd_t"];
        pload["tilt_cmd_t"] = pload["pos_t"];
        pload["tilt_status_t"] = pload["stat_t"];
        pload["tilt_status_tpl"] = "{{ value_json.slat_pos }}";
        pload["pl_stop_tilt"] = pload["pl_stop"];
        pload["tilt_opt"] = false;
      }

      break;
  }

  if (CAT_DIAGNOSTIC.indexOf(info.attr_common) != -1) {
    pload["ent_cat"] = "diagnostic";
  }


  if (CONFIG.disable_minor_entities && DISABLED_ENTS.indexOf(info.attr_common) != -1) {
    pload["en"] = "false";
  }

  return { "domain": domain, "subtopic": info.topic.split(":").join("") + "-" + info.attr, "data": pload }
}

let report_arr = [];
let report_arr_idx = 0;
let comp_inst_num = {};
let device;
let devicemqtttopic = Shelly.getComponentConfig("mqtt").topic_prefix;
let uidata = Shelly.getComponentConfig("sys").ui_data;

/**
 * Precollects input information needed for creation of MQTT discovery.
 * 
 * Data are stored into array, making it possible to track the progress and resume with subsequent Timer calls.
 */
function precollect() {
  let status;

  for (let t = 0; t < COMPONENT_TYPES.length; t++) {
    let comptype = COMPONENT_TYPES[t];

    // create data for single components
    status = Shelly.getComponentStatus(comptype);

    if (status !== null) {

      for (let datattr in status) {
        if (SUPPORTED_ATTRS.indexOf(getCommonAttr(datattr)) == -1) continue;
        if (datattr == "tC" && CONFIG.temperature_unit != "C") continue;
        if (datattr == "tK" && CONFIG.temperature_unit != "K") continue;
        report_arr.push({comp : comptype, ix: -1, attr: datattr, topic: comptype});
      }

      comp_inst_num[comptype] = 1;
    }
    else {
      let index = 0;

      while (true) {
        
        let scomp = comptype + ":" + index;
        status = Shelly.getComponentStatus(scomp);

        if (status === null) break;

        for (let datattr in status) {
          if (SUPPORTED_ATTRS.indexOf(getCommonAttr(datattr)) == -1) continue;
          if (datattr == "tC" && CONFIG.temperature_unit != "C") continue;
          if (datattr == "tF" && CONFIG.temperature_unit != "F") continue;
          report_arr.push({comp : comptype, ix: index, attr: datattr, topic: scomp});
        }

        index++;
        comp_inst_num[comptype] = index;
        
      }
    }
  }

}

/**
 * Processes the next entity in `report_arr` (using `report_arr_idx`), constructs its MQTT discovery payload, and publishes it to the appropriate MQTT discovery topic.
 * @returns 
 */
function mqttreport() {
  let info;

  if (report_arr[report_arr_idx] ) {
    info = report_arr[report_arr_idx];
    report_arr[report_arr_idx] = null;
    report_arr_idx++;
  } else {
    Timer.clear(discoverytimer);
    report_arr = null;
    report_arr_idx = null;
    comp_inst_num = null;
    device = null;
    devicemqtttopic = null;
    uidata = null;
    return;
  }

  if (!device) {
    let deviceInfo = Shelly.getDeviceInfo();
    device = discoveryDevice(deviceInfo);
    // Free memory as soon as possible
    deviceInfo = null;
  }
  
  if (!CONFIG.ignore_names) info.name = Shelly.getComponentConfig(info.topic).name;
  info.mac = device.cns[0][1];
  info.attr_common = getCommonAttr(info.attr);
  if (uidata.consumption_types && uidata.consumption_types[info.ix]) info.altdomain = uidata.consumption_types[info.ix];

  info.issingle = comp_inst_num[info.comp] == 1;

  let data = discoveryEntity(devicemqtttopic, info);
  let discoveryTopic = CONFIG.discovery_topic + "/" + data.domain + "/" + info.mac + "/" + data.subtopic + "/config";
  data.data.dev = device;

  MQTT.publish(discoveryTopic, "", 1, true);
  MQTT.publish(discoveryTopic, JSON.stringify(data.data), 1, true);

  data = null;
  info = null;
}

/**
 * MQTT Discovery timer object
 */
let discoverytimer;

/**
 *  Generate MQTT Discovery
 * Initial precollection of entities to be reported.
 * This will also set up a timer to publish one collected entity per per time-period.
 * @returns 
 */
function main() {
  precollect();
  discoverytimer = Timer.set(CONFIG.mqtt_publish_pause, true, mqttreport);
}

main();



/***************************************
* RSSI (WiFi) reporting
***************************************/

/**
 * Reports the WiFi configuration to MQTT.
 * Publishes the WiFi status to the MQTT topic defined in the Shelly component configuration.
 * The topic is constructed using the MQTT topic prefix and the "status/wifi" suffix.
 */
function reportWifiToMQTT() {
  let topic_prefix = Shelly.getComponentConfig("mqtt").topic_prefix;
  let components = CONFIG.components_refresh;

  for (let t = 0; t < components.length; t++) {
    let status = Shelly.getComponentStatus(components[t]);
    if (!status) continue;

    MQTT.publish(topic_prefix + "/status/" + components[t], JSON.stringify(status), 1, false);
  }
}

// Initial call to report WiFi status
// This will also set up a timer to report WiFi status every 60 seconds
reportWifiToMQTT();
let timer_handle = Timer.set(CONFIG.components_refresh_period * 1000, true, reportWifiToMQTT, null);

[edjes]

Mogelijk een domme vraag en ik heb deze draad vanaf pagina 14 tm 30 of zo doorgelezen, waar het wat wordt uitgelegd.

Nogmaals dank @gielz voor de prachtige code, ik heb er al veel omheen mogen bouwen ;-).

Nu ook aan de slag met de dynamische NOM, maar ik snap niet helemaal de werking ervan en kan het niet goed terugvinden in de README/FAQ. Wat is het doel van dynamische NOM? Ik heb nu in 15 min grafiek 8 en 18 goedkoop en dure periodes ingesteld. Dat komt prachtig terug in de grafieken met groen en rode tijden. Hij laadt ook keurig op groen, maar hij staat de hele dag op NOM en met veel gebruik is de batterij (8,5 kwh) leeg voordoor hij de dure periodes bereikt. Wat doet de automatisering dan anders dan NOM in de dure periodes? Is het een idee (dat werd al eerder geopperd) om er een routine bij te bouwen die ALLEEN in de groene periodes laadt en in de rode NOM doet en buiten deze periodes standby? Dat zou super zijn in deze tijd zonder zon. Dank voor het antwoord en sorry als het ergens stond uitgelegd wat ik gemist heb.

[martinvdm]

edjes schreef op vrijdag 2 januari 2026 @ 20:33:
Mogelijk een domme vraag en ik heb deze draad vanaf pagina 14 tm 30 of zo doorgelezen, waar het wat wordt uitgelegd.

Nogmaals dank @gielz voor de prachtige code, ik heb er al veel omheen mogen bouwen ;-).

Nu ook aan de slag met de dynamische NOM, maar ik snap niet helemaal de werking ervan en kan het niet goed terugvinden in de README/FAQ. Wat is het doel van dynamische NOM? Ik heb nu in 15 min grafiek 8 en 18 goedkoop en dure periodes ingesteld. Dat komt prachtig terug in de grafieken met groen en rode tijden. Hij laadt ook keurig op groen, maar hij staat de hele dag op NOM en met veel gebruik is de batterij (8,5 kwh) leeg voordoor hij de dure periodes bereikt. Wat doet de automatisering dan anders dan NOM in de dure periodes? Is het een idee (dat werd al eerder geopperd) om er een routine bij te bouwen die ALLEEN in de groene periodes laadt en in de rode NOM doet en buiten deze periodes standby? Dat zou super zijn in deze tijd zonder zon. Dank voor het antwoord en sorry als het ergens stond uitgelegd wat ik gemist heb.

Dynamisch NOM is exact hetzelfde als NOM maar dan met laden tijdens goedkope uren erbij. Ik ben het wel met je eens, zeker als de pieken en dalen vrij dicht bij elkaar liggen, dat ik juist wil ontladen tijdens de dure uren en dit niet altijd meer lukt als er al flink wat kWh in de uren ervoor uitgegaan zijn. Ik zou dus ook graag, zoals je schrijft, een Dynamisch Goedkoop/Duur zien, om alleen te laden tijdens goedkope uren en ontladen tijdens dure uren, rest alleen slim opladen (stand-by zou zonde zijn van de zon-uurtjes)

[Sander]

martinvdm schreef op vrijdag 2 januari 2026 @ 22:44:
[...]

Dynamisch NOM is exact hetzelfde als NOM maar dan met laden tijdens goedkope uren erbij. Ik ben het wel met je eens, zeker als de pieken en dalen vrij dicht bij elkaar liggen, dat ik juist wil ontladen tijdens de dure uren en dit niet altijd meer lukt als er al flink wat kWh in de uren ervoor uitgegaan zijn. Ik zou dus ook graag, zoals je schrijft, een Dynamisch Goedkoop/Duur zien, om alleen te laden tijdens goedkope uren en ontladen tijdens dure uren, rest alleen slim opladen (stand-by zou zonde zijn van de zon-uurtjes)

Uiteindelijk heb je alle data/controls om dit te doen, je hebt of het duur of goedkoop is en je hebt de mogelijkheid om de modi te beinvloeden. Wat ik zelf heb gedaan is dat nu omgezet in een automation die exact dit doet:
- Goedkope uren laden (als spread > 35%)
- Dure uren ontladen (als spread > 35%)
- Alles ertussen aan PV overschot (heel minimaal nu) de batterij in tot een limiet en daarna het net op.

Ik merk zelf dat ik met de Hyper nu te weinig kan terugleveren om de NOM modus relevant te maken. Eigenlijk zijn er op deze koude dagen weinig momenten dat NOM zinvol is met ~ 30 kWh per dag afname van het net. Merk nu ook duidelijk dat er met dynamische prijzen wel een moment in het jaar komt waarop de automations omgezet moeten worden van: Alles overdag en zoveel mogelijk PV naar alles in de goedkopere nachtelijke uren. Heb nog niet echt duidelijke manier van automatiseren daarvoor gevonden.

[ Voor 10% gewijzigd door Sander op 03-01-2026 08:18 ]

[martinvdm]

Sander schreef op zaterdag 3 januari 2026 @ 07:59:
[...]


Uiteindelijk heb je alle data/controls om dit te doen, je hebt of het duur of goedkoop is en je hebt de mogelijkheid om de modi te beinvloeden. Wat ik zelf heb gedaan is dat nu omgezet in een automation die exact dit doet:
- Goedkope uren laden (als spread > 35%)
- Dure uren ontladen (als spread > 35%)
- Alles ertussen aan PV overschot (heel minimaal nu) de batterij in tot een limiet en daarna het net op.

Ik merk zelf dat ik met de Hyper nu te weinig kan terugleveren om de NOM modus relevant te maken. Eigenlijk zijn er op deze koude dagen weinig momenten dat NOM zinvol is met ~ 30 kWh per dag afname van het net. Merk nu ook duidelijk dat er met dynamische prijzen wel een moment in het jaar komt waarop de automations omgezet moeten worden van: Alles overdag en zoveel mogelijk PV naar alles in de goedkopere nachtelijke uren. Heb nog niet echt duidelijke manier van automatiseren daarvoor gevonden.

Zeker, kan natuurlijk wel een automation maken die iets in die trant doet, ik denk alleen dat zowel ik als @edjes en wellicht anderen het mooi zouden vinden als het in de code van @Giel zou zitten en het daarom hier als suggestie geven

[edjes]

Sander schreef op zaterdag 3 januari 2026 @ 07:59:
[...]


Uiteindelijk heb je alle data/controls om dit te doen, je hebt of het duur of goedkoop is en je hebt de mogelijkheid om de modi te beinvloeden. Wat ik zelf heb gedaan is dat nu omgezet in een automation die exact dit doet:
- Goedkope uren laden (als spread > 35%)
- Dure uren ontladen (als spread > 35%)
- Alles ertussen aan PV overschot (heel minimaal nu) de batterij in tot een limiet en daarna het net op.

Ik merk zelf dat ik met de Hyper nu te weinig kan terugleveren om de NOM modus relevant te maken. Eigenlijk zijn er op deze koude dagen weinig momenten dat NOM zinvol is met ~ 30 kWh per dag afname van het net. Merk nu ook duidelijk dat er met dynamische prijzen wel een moment in het jaar komt waarop de automations omgezet moeten worden van: Alles overdag en zoveel mogelijk PV naar alles in de goedkopere nachtelijke uren. Heb nog niet echt duidelijke manier van automatiseren daarvoor gevonden.

Oh dat is slimme suggestie, dat lukt wel.
Toch, zou wel mooi zijn als extra optie in de @gielz keuzemenu ;-)

[Leguan]

Grappig dat jullie hier ook mee bezig zijn, heb toevallig sinds gister onderstaande automatisering draaien waardoor enkel in de groene gebieden wordt geladen (mits voldoende spread) en die stroom wordt bewaard tot de rode (dure) gebieden). De logica is als volgt:

Goedkoop = Ja > modus Dynamisch NOM (pas dit aan naar 'Opladen met 2400 watt' indien je de spread wilt negeren).
Duur = Ja > modus Dynamisch NOM
Goedkoop = Nee & Duur = Nee & het is tussen zonsondergang en zonsopkomst (geen kans op PV opwek) > modus standby
Goedkoop = Nee & Duur = Nee & het is tussen zonsopkomst en zonsondergang (kans op PV opwek) > modus Alleen slim opladen

Automation yaml:

code:

alias: Zendure 2400 AC - Modus op basis van dynamische periode
description: >
  Schakelt de Zendure 2400 AC modus afhankelijk van goedkope of dure dynamische
  periodes.
triggers:
  - entity_id:
      - sensor.dynamisch_goedkoopste_periode
      - sensor.dynamisch_duurste_periode
    trigger: state
  - event: sunset
    trigger: sun
  - event: sunrise
    trigger: sun
actions:
  - choose:
      - conditions:
          - condition: state
            entity_id: sensor.dynamisch_goedkoopste_periode
            state: Ja
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Dynamisch NOM
            action: input_select.select_option
      - conditions:
          - condition: state
            entity_id: sensor.dynamisch_duurste_periode
            state: Ja
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Dynamisch NOM
            action: input_select.select_option
      - conditions:
          - condition: state
            entity_id: sensor.dynamisch_goedkoopste_periode
            state: Nee
          - condition: state
            entity_id: sensor.dynamisch_duurste_periode
            state: Nee
          - condition: sun
            after: sunset
            before: sunrise
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Standby
            action: input_select.select_option
      - conditions:
          - condition: state
            entity_id: sensor.dynamisch_goedkoopste_periode
            state: Nee
          - condition: state
            entity_id: sensor.dynamisch_duurste_periode
            state: Nee
          - condition: sun
            after: sunrise
            before: sunset
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Alleen slim opladen
            action: input_select.select_option
mode: restart

[emielbf]

Ik zie sinds een paar dagen iets bijzonders. Ik heb een eigen HEMS ontwikkeld en dat werkte prima tot 2 dagen geleden. Geen veranderingen in mijn HEMS gemaakt.
Mijn 800Pro begint sinds 3 dagen spontaan rod 10 uur te laden van Grid. Hij trekt 1000W terwijl in mijn hems 800 watt het max is. De logging laat geen commando's zien die hier iets mee te maken hebben. Het is dus 'eigen gedrag' van de zendure. Hij zit niet in Zendure-HEMS.
Ik vermoed dat ik sinds 3 dagen versie 1.0.23 heb, wellicht zit daar een (bug) link? Overigens gaat ie rond 4 uur ontladen, op eigen houtje.

Is dit verklaarbaar?

[edjes]

Leguan schreef op zaterdag 3 januari 2026 @ 22:39:
Grappig dat jullie hier ook mee bezig zijn, heb toevallig sinds gister onderstaande automatisering draaien waardoor enkel in de groene gebieden wordt geladen (mits voldoende spread) en die stroom wordt bewaard tot de rode (dure) gebieden). De logica is als volgt:

Goedkoop = Ja > modus Dynamisch NOM (pas dit aan naar 'Opladen met 2400 watt' indien je de spread wilt negeren).
Duur = Ja > modus Dynamisch NOM
Goedkoop = Nee & Duur = Nee & het is tussen zonsondergang en zonsopkomst (geen kans op PV opwek) > modus standby
Goedkoop = Nee & Duur = Nee & het is tussen zonsopkomst en zonsondergang (kans op PV opwek) > modus Alleen slim opladen

Automation yaml:

code:

alias: Zendure 2400 AC - Modus op basis van dynamische periode

mode: restart

Heel interessant!!
Ik heb hem herschreven, hij werkt nu in de winter én in de zomer, met hulp van chatgpt.

Uitgangspunt:
In de winter: alleen laden/ontladen in de goedkoop/dure periodes bij spread>25%. Daarbuiten standby!
In de zomer: NOM + laden overdag, snachts NOM ontladen als batterij>90% bij zonsondergang.
Je hebt 2 nieuwe helpers nodig (eentje om te bepalen of snachts NOM mag in de zomer; de andere om het gedrag te zien, niet perse nodig als logger).
Voeg je eigen zonnepanelen opbrengst sensor in bij option 6 en 7
Alles draait bovenop en maakt gebruik van @gielz .

Schieten maar! Hij draait hier goed nu.
Zoiets inbouwen als extra optie in jouw prachtige code @gielz ?

Triggers

SOC: sensor.zendure_2400_ac_laadpercentage
PV: sensor.solaredge_current_power_kwh
Prijs: sensor.dynamisch_goedkoopste_periode / sensor.dynamisch_duurste_periode
Spread: sensor.dynamisch_spread_indicatie
Zon: sunrise / sunset voor zomernacht-helper

Logica per optie

1. Zomernacht-helper aan: Bij sunset, alleen als SOC ≥ 90% én helper uit. Zet helper aan. Status: “Zomernacht toegestaan”.
2. Zomernacht-helper reset: Bij sunrise, alleen als helper aan. Zet helper uit. Status: “Zomernacht reset”.
3. SOC-limieten: SOC < 15% → Standby (ontladen geblokkeerd). SOC > 99% → Standby (laden geblokkeerd).
4. Dure periode: SOC ≥ 15% → Ontladen → Nul op de meter.
5. Goedkope periode: PV < 0,2 kW én spread > 25% én SOC < 99% → Laden met 2400 W uit net.
6. Overdag PV ≥ 0,8 kW → Nul op de meter (overschot gebruiken).
7. Nacht + helper aan → Nul op de meter.
8. Fallback overdag → Alleen slim opladen.
9. Default → Standby.

Belangrijke principes

Helper voorkomt dat nacht-NOM overdag optreedt.
SOC-limieten beschermen batterij tegen over- of onderladen.
Spread-check voorkomt netladen bij minimale prijsverschillen.
PV-drempel 0,8 kW zorgt dat overdag batterij gevuld wordt met zonne-overschot.
Dure periodes ontladen altijd, zonder spread-check, voor maximaal financieel voordeel.

Nieuwe helpers / input helpers

input_boolean.zendure_zomernacht_nom_toegestaan → Houdt bij of nacht-NOM is toegestaan (zomernacht).
input_text.zendure_automation_status → Houdt een statusbeschrijving bij van wat de automatisering op dat moment doet, handig voor debugging

code:

alias: Zendure - zomer-winter-viagielz
description: >
  Stuurt Zendure 2400 AC met SOC-limieten, prijs, Nul op de meter,
  zomernacht-helper, PV-drempel bij goedkope periodes, spread-check en status
  feedback.
triggers:
  - entity_id:
      - sensor.dynamisch_goedkoopste_periode
      - sensor.dynamisch_duurste_periode
    trigger: state
  - entity_id: sensor.solaredge_current_power_kwh
    above: 0.8
    for:
      minutes: 10
    trigger: numeric_state
  - entity_id: sensor.solaredge_current_power_kwh
    below: 0.2
    for:
      minutes: 10
    trigger: numeric_state
  - entity_id: sensor.zendure_2400_ac_laadpercentage
    trigger: state
  - event: sunset
    id: sunset
    trigger: sun
  - event: sunrise
    id: sunrise
    trigger: sun
actions:
  - choose:
      - conditions:
          - condition: trigger
            id: sunset
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_laadpercentage
            above: 90
          - condition: state
            entity_id: input_boolean.zendure_zomernacht_nom_toegestaan
            state: "off"
        sequence:
          - target:
              entity_id: input_boolean.zendure_zomernacht_nom_toegestaan
            action: input_boolean.turn_on
          - target:
              entity_id: input_text.zendure_automation_status
            data:
              value: Zomernacht toegestaan – SOC ≥ 90% bij sunset
            action: input_text.set_value
      - conditions:
          - condition: trigger
            id: sunrise
          - condition: state
            entity_id: input_boolean.zendure_zomernacht_nom_toegestaan
            state: "on"
        sequence:
          - target:
              entity_id: input_boolean.zendure_zomernacht_nom_toegestaan
            action: input_boolean.turn_off
          - target:
              entity_id: input_text.zendure_automation_status
            data:
              value: Nieuwe dag – zomernacht reset
            action: input_text.set_value
      - conditions:
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_laadpercentage
            below: 15
          - condition: state
            entity_id: sensor.dynamisch_duurste_periode
            state: Ja
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Standby
            action: input_select.select_option
          - target:
              entity_id: input_text.zendure_automation_status
            data:
              value: SOC < 15% – ontladen geblokkeerd
            action: input_text.set_value
      - conditions:
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_laadpercentage
            above: 99
          - condition: state
            entity_id: sensor.dynamisch_goedkoopste_periode
            state: Ja
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Standby
            action: input_select.select_option
          - target:
              entity_id: input_text.zendure_automation_status
            data:
              value: SOC > 99% – laden geblokkeerd
            action: input_text.set_value
      - conditions:
          - condition: state
            entity_id: sensor.dynamisch_duurste_periode
            state: Ja
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_laadpercentage
            above: 15
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Nul op de meter
            action: input_select.select_option
          - target:
              entity_id: input_text.zendure_automation_status
            data:
              value: Dure periode – ontladen (nul op de meter)
            action: input_text.set_value
      - conditions:
          - condition: state
            entity_id: sensor.dynamisch_goedkoopste_periode
            state: Ja
          - condition: numeric_state
            entity_id: sensor.solaredge_current_power_kwh
            below: 0.2
          - condition: numeric_state
            entity_id: sensor.dynamisch_spread_indicatie
            above: 25
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_laadpercentage
            below: 99
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Opladen met 2400 watt
            action: input_select.select_option
          - target:
              entity_id: input_text.zendure_automation_status
            data:
              value: >-
                Goedkope periode – laden met 2400 W uit net (PV laag, spread
                >25%)
            action: input_text.set_value
      - conditions:
          - condition: sun
            after: sunrise
            before: sunset
          - condition: numeric_state
            entity_id: sensor.solaredge_current_power_kwh
            above: 0.8
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Nul op de meter
            action: input_select.select_option
          - target:
              entity_id: input_text.zendure_automation_status
            data:
              value: Goede zon overdag – Nul op de meter actief
            action: input_text.set_value
      - conditions:
          - condition: sun
            after: sunset
            before: sunrise
          - condition: state
            entity_id: input_boolean.zendure_zomernacht_nom_toegestaan
            state: "on"
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Nul op de meter
            action: input_select.select_option
          - target:
              entity_id: input_text.zendure_automation_status
            data:
              value: Zomernacht – Nul op de meter actief
            action: input_text.set_value
      - conditions:
          - condition: sun
            after: sunrise
            before: sunset
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Alleen slim opladen
            action: input_select.select_option
          - target:
              entity_id: input_text.zendure_automation_status
            data:
              value: Neutraal overdag – slim opladen
            action: input_text.set_value
    default:
      - target:
          entity_id: input_select.zendure_2400_ac_modus_selecteren
        data:
          option: Standby
        action: input_select.select_option
      - target:
          entity_id: input_text.zendure_automation_status
        data:
          value: Neutraal – standby
        action: input_text.set_value
mode: restart

[martinvdm]

edjes schreef op zondag 4 januari 2026 @ 11:21:
[...]

Heel interessant!!
Ik heb hem herschreven, hij werkt nu in de winter én in de zomer, met hulp van chatgpt.

Uitgangspunt:
In de winter: alleen laden/ontladen in de goedkoop/dure periodes bij spread>25%. Daarbuiten standby!
In de zomer: NOM + laden overdag, snachts NOM ontladen als batterij>90% bij zonsondergang.
Je hebt 2 nieuwe helpers nodig (eentje om te bepalen of snachts NOM mag in de zomer; de andere om het gedrag te zien, niet perse nodig als logger).
Voeg je eigen zonnepanelen opbrengst sensor in bij option 6 en 7
Alles draait bovenop en maakt gebruik van @gielz .

Schieten maar! Hij draait hier goed nu.
Zoiets inbouwen als extra optie in jouw prachtige code @gielz ?

Triggers

SOC: sensor.zendure_2400_ac_laadpercentage
PV: sensor.solaredge_current_power_kwh
Prijs: sensor.dynamisch_goedkoopste_periode / sensor.dynamisch_duurste_periode
Spread: sensor.dynamisch_spread_indicatie
Zon: sunrise / sunset voor zomernacht-helper

Logica per optie

1. Zomernacht-helper aan: Bij sunset, alleen als SOC ≥ 90% én helper uit. Zet helper aan. Status: “Zomernacht toegestaan”.
2. Zomernacht-helper reset: Bij sunrise, alleen als helper aan. Zet helper uit. Status: “Zomernacht reset”.
3. SOC-limieten: SOC < 15% → Standby (ontladen geblokkeerd). SOC > 99% → Standby (laden geblokkeerd).
4. Dure periode: SOC ≥ 15% → Ontladen → Nul op de meter.
5. Goedkope periode: PV < 0,2 kW én spread > 25% én SOC < 99% → Laden met 2400 W uit net.
6. Overdag PV ≥ 0,8 kW → Nul op de meter (overschot gebruiken).
7. Nacht + helper aan → Nul op de meter.
8. Fallback overdag → Alleen slim opladen.
9. Default → Standby.

Belangrijke principes

Helper voorkomt dat nacht-NOM overdag optreedt.
SOC-limieten beschermen batterij tegen over- of onderladen.
Spread-check voorkomt netladen bij minimale prijsverschillen.
PV-drempel 0,8 kW zorgt dat overdag batterij gevuld wordt met zonne-overschot.
Dure periodes ontladen altijd, zonder spread-check, voor maximaal financieel voordeel.

Nieuwe helpers / input helpers

input_boolean.zendure_zomernacht_nom_toegestaan → Houdt bij of nacht-NOM is toegestaan (zomernacht).
input_text.zendure_automation_status → Houdt een statusbeschrijving bij van wat de automatisering op dat moment doet, handig voor debugging

code:

alias: Zendure - zomer-winter-viagielz
description: >
  Stuurt Zendure 2400 AC met SOC-limieten, prijs, Nul op de meter,
  zomernacht-helper, PV-drempel bij goedkope periodes, spread-check en status
  feedback.
triggers:
  - entity_id:
      - sensor.dynamisch_goedkoopste_periode
      - sensor.dynamisch_duurste_periode
    trigger: state
  - entity_id: sensor.solaredge_current_power_kwh
    above: 0.8
    for:
      minutes: 10
    trigger: numeric_state
  - entity_id: sensor.solaredge_current_power_kwh
    below: 0.2
    for:
      minutes: 10
    trigger: numeric_state
  - entity_id: sensor.zendure_2400_ac_laadpercentage
    trigger: state
  - event: sunset
    id: sunset
    trigger: sun
  - event: sunrise
    id: sunrise
    trigger: sun
actions:
  - choose:
      - conditions:
          - condition: trigger
            id: sunset
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_laadpercentage
            above: 90
          - condition: state
            entity_id: input_boolean.zendure_zomernacht_nom_toegestaan
            state: "off"
        sequence:
          - target:
              entity_id: input_boolean.zendure_zomernacht_nom_toegestaan
            action: input_boolean.turn_on
          - target:
              entity_id: input_text.zendure_automation_status
            data:
              value: Zomernacht toegestaan – SOC ≥ 90% bij sunset
            action: input_text.set_value
      - conditions:
          - condition: trigger
            id: sunrise
          - condition: state
            entity_id: input_boolean.zendure_zomernacht_nom_toegestaan
            state: "on"
        sequence:
          - target:
              entity_id: input_boolean.zendure_zomernacht_nom_toegestaan
            action: input_boolean.turn_off
          - target:
              entity_id: input_text.zendure_automation_status
            data:
              value: Nieuwe dag – zomernacht reset
            action: input_text.set_value
      - conditions:
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_laadpercentage
            below: 15
          - condition: state
            entity_id: sensor.dynamisch_duurste_periode
            state: Ja
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Standby
            action: input_select.select_option
          - target:
              entity_id: input_text.zendure_automation_status
            data:
              value: SOC < 15% – ontladen geblokkeerd
            action: input_text.set_value
      - conditions:
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_laadpercentage
            above: 99
          - condition: state
            entity_id: sensor.dynamisch_goedkoopste_periode
            state: Ja
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Standby
            action: input_select.select_option
          - target:
              entity_id: input_text.zendure_automation_status
            data:
              value: SOC > 99% – laden geblokkeerd
            action: input_text.set_value
      - conditions:
          - condition: state
            entity_id: sensor.dynamisch_duurste_periode
            state: Ja
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_laadpercentage
            above: 15
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Nul op de meter
            action: input_select.select_option
          - target:
              entity_id: input_text.zendure_automation_status
            data:
              value: Dure periode – ontladen (nul op de meter)
            action: input_text.set_value
      - conditions:
          - condition: state
            entity_id: sensor.dynamisch_goedkoopste_periode
            state: Ja
          - condition: numeric_state
            entity_id: sensor.solaredge_current_power_kwh
            below: 0.2
          - condition: numeric_state
            entity_id: sensor.dynamisch_spread_indicatie
            above: 25
          - condition: numeric_state
            entity_id: sensor.zendure_2400_ac_laadpercentage
            below: 99
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Opladen met 2400 watt
            action: input_select.select_option
          - target:
              entity_id: input_text.zendure_automation_status
            data:
              value: >-
                Goedkope periode – laden met 2400 W uit net (PV laag, spread
                >25%)
            action: input_text.set_value
      - conditions:
          - condition: sun
            after: sunrise
            before: sunset
          - condition: numeric_state
            entity_id: sensor.solaredge_current_power_kwh
            above: 0.8
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Nul op de meter
            action: input_select.select_option
          - target:
              entity_id: input_text.zendure_automation_status
            data:
              value: Goede zon overdag – Nul op de meter actief
            action: input_text.set_value
      - conditions:
          - condition: sun
            after: sunset
            before: sunrise
          - condition: state
            entity_id: input_boolean.zendure_zomernacht_nom_toegestaan
            state: "on"
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Nul op de meter
            action: input_select.select_option
          - target:
              entity_id: input_text.zendure_automation_status
            data:
              value: Zomernacht – Nul op de meter actief
            action: input_text.set_value
      - conditions:
          - condition: sun
            after: sunrise
            before: sunset
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Alleen slim opladen
            action: input_select.select_option
          - target:
              entity_id: input_text.zendure_automation_status
            data:
              value: Neutraal overdag – slim opladen
            action: input_text.set_value
    default:
      - target:
          entity_id: input_select.zendure_2400_ac_modus_selecteren
        data:
          option: Standby
        action: input_select.select_option
      - target:
          entity_id: input_text.zendure_automation_status
        data:
          value: Neutraal – standby
        action: input_text.set_value
mode: restart

Leuk. Je kunt je helper vervangen door een conditon template en gewoon kijken of het zomer of winter is en of het dag of nacht is.

Bijv:

YAML:

- condition: template
  value_template: '{{ now().month >= 4 or now().month <= 10 }}'

Of je hebt zelfs een seizoen sensor
https://www.home-assistant.io/integrations/season/

[edjes]

martinvdm schreef op zondag 4 januari 2026 @ 11:36:
[...]

Leuk. Je kunt je helper vervangen door een conditon template en gewoon kijken of het zomer of winter is en of het dag of nacht is.

Bijv:

YAML:

- condition: template
  value_template: '{{ now().month >= 4 or now().month <= 10 }}'

Of je hebt zelfs een seizoen sensor
https://www.home-assistant.io/integrations/season/

Seizoen is niet perse boeiend, in april maak ik ook al vaak genoeg stroom. Het is meer de gedachtengang. De helper kan geen template, want zodra de batterij gaat leeglopen, zet de template de conditie weer op 'snachts niet laden'.

[gielz]

Echt mooie suggesties zie ik weer voorbij komen. Altijd mooi om te zien hoeveel er mogelijk is met deze batterij!

Voor de release van Februari heb ik een paar leuke aanpassingen gedaan die ik zelf aan het testen ben maar wellicht denk je. Goh laat ik ook eens testen, mocht je tegen problemen aanlopen DM mij dan even dan vervuilt dit topic niet.

Gielz Februari test

https://github.com/Gielz1...1986-Februari-2026-update
3 nieuw instelbare entiteiten

Oplaadmarge
Standaard in HEMS word er een marge aangehouden van 50 watt. Hierbij houd de huidige versie 40 watt aan wat dus vanaf nu instelbaar is van 0 tot 50 watt via deze entiteit. Handig in de winter als je alle prik binnen wilt halen.

Ontlaadmarge
Bij iedereen wel verschillend. De ene wilt net wat meer ontladen dan gevraagd word om echt 0 te importeren en de ander juist niet. Nu ook instelbaar van 0 tot 50 watt. In de huidige versie is dit 2 watt.

Standby vertraging
Een doorn in het oog. Ik zie bij andere aansturingen dat de Smartmode op 0 gezet word direct als het vermogen ook op 0 watt staat. Zelf was ik hier geen voorstander van en zie dit bijvoorbeeld ook niet terug bij de Homewizard PIB. Vandaar nu netjes instelbaar van 5-30 minuten. Zodra er dan xx minuten geen activiteit is zal hij smartmode op 0 zetten om de "waakvlam" zoals ik hem zelf noem uit te zetten. Hierna toont een KWH MID meter 0 watt maar uiteraard is er nog wat vermogen nodig intern voor de BMS.

De modus "Standby" wat handmatig was deed dit al correct en altijd direct wat ongewijzigd is. Nu doet de gehele aansturing mee zoals NOM, Slim Opladen etc.

[ Voor 4% gewijzigd door gielz op 04-01-2026 15:07 ]

[janssuhhh]

Ik heb nu ongeveer 2 maanden 4x 2400AC staan en lees al een tijdje mee in dit topic.

Hier gebruik ik de FireSon integratie en ben tot nu toe heel tevreden. Sinds de laatste update werkt ook het excluden van devices met een actieve off-grid poort, perfect. Keurig +/- 0kw!

Zelf probeer ik het een en ander te automatiseren, want het moet ook interessant blijven om met dit spul te werken en de boel steeds slimmer te maken 😉.
Daarvoor laad ik bijvoorbeeld in de goedkope uren met totaal 8400w (3x 2400w en 1x 1200w ivm C-ratings), verdeeld over de 3x25A fasen. Dat gaat allemaal goed, maar op 1 fase zitten 2 grote verbruikers, jacuzzi en vaatwasser, die samen met de 2400AC ruim 6800w trekken. Dat is voor 25A aansluiting een beetje veel van het goede (overschrijding van bijna 20%...).
De jacuzzi gaat verwarmen wanneer hij dat nodig acht en is niet te automatiseren helaas.
De vaatwasser probeer ik zelf goed te timen, maar niet iedereen in het huishouden heeft daar een boodschap aan. Dus soms gaat die aan, terwijl de accu's volle bak laden en dan ook de jacuzzi aanspringt.

Nu is de vraag, hoe ik ervoor kan zorgen dat Home Assistant met de FireSon integratie, samen met de gegevens van de P1-meter (HW), de laadsnelheid omlaag gooit wanneer beide grootverbruikers onverhoopt tegelijk aan gaan.

Zelf kan ik makkelijk een automatisering maken die het totale vermogen van 8400w naar beneden schroeft, maar dan ga ik op alle fasen inleveren.
Wat ik eigenlijk zou willen bereiken is dat ik alleen op de fase met de overschrijding, de laadsnelheid beperk.

Iemand van jullie daar al iets voor geschreven?
Of misschien zie ik gewoon een super simpele oplossing over het hoofd... Iets met; te lang blindstaren op 1 probleem..

[edjes]

gielz schreef op zondag 4 januari 2026 @ 15:05:
Echt mooie suggesties zie ik weer voorbij komen. Altijd mooi om te zien hoeveel er mogelijk is met deze batterij!

Voor de release van Februari heb ik een paar leuke aanpassingen gedaan die ik zelf aan het testen ben maar wellicht denk je. Goh laat ik ook eens testen, mocht je tegen problemen aanlopen DM mij dan even dan vervuilt dit topic niet.

Gielz Februari test

https://github.com/Gielz1...1986-Februari-2026-update
3 nieuw instelbare entiteiten

Oplaadmarge
Standaard in HEMS word er een marge aangehouden van 50 watt. Hierbij houd de huidige versie 40 watt aan wat dus vanaf nu instelbaar is van 0 tot 50 watt via deze entiteit. Handig in de winter als je alle prik binnen wilt halen.

Ontlaadmarge
Bij iedereen wel verschillend. De ene wilt net wat meer ontladen dan gevraagd word om echt 0 te importeren en de ander juist niet. Nu ook instelbaar van 0 tot 50 watt. In de huidige versie is dit 2 watt.

Standby vertraging
Een doorn in het oog. Ik zie bij andere aansturingen dat de Smartmode op 0 gezet word direct als het vermogen ook op 0 watt staat. Zelf was ik hier geen voorstander van en zie dit bijvoorbeeld ook niet terug bij de Homewizard PIB. Vandaar nu netjes instelbaar van 5-30 minuten. Zodra er dan xx minuten geen activiteit is zal hij smartmode op 0 zetten om de "waakvlam" zoals ik hem zelf noem uit te zetten. Hierna toont een KWH MID meter 0 watt maar uiteraard is er nog wat vermogen nodig intern voor de BMS.

De modus "Standby" wat handmatig was deed dit al correct en altijd direct wat ongewijzigd is. Nu doet de gehele aansturing mee zoals NOM, Slim Opladen etc.

[Afbeelding]

Dank! Benieuwd!
Moet je ook je config.yaml aanpassen of is deze ongewijzigd?

[ Voor 3% gewijzigd door edjes op 04-01-2026 18:43 ]

[martinvdm]

edjes schreef op zondag 4 januari 2026 @ 18:42:
[...]


Dank! Benieuwd!
Moet je ook je config.yaml aanpassen of is deze ongewijzigd?

Ja zie de github , diverse changes in zowel automation als config file.

[gielz]

edjes schreef op zondag 4 januari 2026 @ 18:42:
[...]


Dank! Benieuwd!
Moet je ook je config.yaml aanpassen of is deze ongewijzigd?

Dit zijn de exacte wijzigingen; https://github.com/Gielz1...1986-Februari-2026-update

Dit betreft nog wel een test dus eind Januari kan er wellicht nog iets gewijzigd zijn. Mocht je zelf geen aanpassingen hebben gedaan dan is het gewoon ctrl+c + ctrl+v. Bestaande sensoren worden bijna nooit aangepast, anders geef ik exact aan wat de wijziging is.

Mocht je wel aanpassingen standaard doen meld dit dan via DM dan kan het wellicht in de basis.

[JSven]

janssuhhh schreef op zondag 4 januari 2026 @ 16:17:
Ik heb nu ongeveer 2 maanden 4x 2400AC staan en lees al een tijdje mee in dit topic.

Hier gebruik ik de FireSon integratie en ben tot nu toe heel tevreden. Sinds de laatste update werkt ook het excluden van devices met een actieve off-grid poort, perfect. Keurig +/- 0kw!

Zelf probeer ik het een en ander te automatiseren, want het moet ook interessant blijven om met dit spul te werken en de boel steeds slimmer te maken 😉.
Daarvoor laad ik bijvoorbeeld in de goedkope uren met totaal 8400w (3x 2400w en 1x 1200w ivm C-ratings), verdeeld over de 3x25A fasen. Dat gaat allemaal goed, maar op 1 fase zitten 2 grote verbruikers, jacuzzi en vaatwasser, die samen met de 2400AC ruim 6800w trekken. Dat is voor 25A aansluiting een beetje veel van het goede (overschrijding van bijna 20%...).
De jacuzzi gaat verwarmen wanneer hij dat nodig acht en is niet te automatiseren helaas.
De vaatwasser probeer ik zelf goed te timen, maar niet iedereen in het huishouden heeft daar een boodschap aan. Dus soms gaat die aan, terwijl de accu's volle bak laden en dan ook de jacuzzi aanspringt.

Nu is de vraag, hoe ik ervoor kan zorgen dat Home Assistant met de FireSon integratie, samen met de gegevens van de P1-meter (HW), de laadsnelheid omlaag gooit wanneer beide grootverbruikers onverhoopt tegelijk aan gaan.

Zelf kan ik makkelijk een automatisering maken die het totale vermogen van 8400w naar beneden schroeft, maar dan ga ik op alle fasen inleveren.
Wat ik eigenlijk zou willen bereiken is dat ik alleen op de fase met de overschrijding, de laadsnelheid beperk.

Iemand van jullie daar al iets voor geschreven?
Of misschien zie ik gewoon een super simpele oplossing over het hoofd... Iets met; te lang blindstaren op 1 probleem..

Kan je niet het vermogen per fasen uitlezen van je fase op je P1 meter? Ik heb een homewizard P1 meter en ik heb volgende entiteit hiervoor
sensor.p1_meter_vermogen_fase_1
sensor.p1_meter_vermogen_fase_2
sensor.p1_meter_vermogen_fase_3

Het is nog niet een optimale oplossing, maar je zou dan wel kunnen kijken als het vermogen van een fase te hoog is, dat je dan je batterij lager schakelt of uitzet.

[janssuhhh]

JSven schreef op maandag 5 januari 2026 @ 09:58:
[...]


Kan je niet het vermogen per fasen uitlezen van je fase op je P1 meter? Ik heb een homewizard P1 meter en ik heb volgende entiteit hiervoor
sensor.p1_meter_vermogen_fase_1
sensor.p1_meter_vermogen_fase_2
sensor.p1_meter_vermogen_fase_3

Het is nog niet een optimale oplossing, maar je zou dan wel kunnen kijken als het vermogen van een fase te hoog is, dat je dan je batterij lager schakelt of uitzet.

Ja dat kan ik inderdaad ook op basis van die entiteiten en dat zie ik als een tussenoplossing.
Voor nu kan ik eenvoudig het totale laadvermogen verlagen, maar uiteindelijk wil je dat alleen inleveren wat echt noodzakelijk is en niet meer dan dat.
En juist dat laatste ben ik nog niet achter hoe ik dat op een elegante wijze kan bereiken.

[koboy]

janssuhhh schreef op maandag 5 januari 2026 @ 13:16:
[...]


Ja dat kan ik inderdaad ook op basis van die entiteiten en dat zie ik als een tussenoplossing.
Voor nu kan ik eenvoudig het totale laadvermogen verlagen, maar uiteindelijk wil je dat alleen inleveren wat echt noodzakelijk is en niet meer dan dat.
En juist dat laatste ben ik nog niet achter hoe ik dat op een elegante wijze kan bereiken.

De vermogens metingen op de verschillende fasen is de enige mogelijkheid om reactief te werken wat laadvermogen betreft. Pro-actief gaat erg lastig worden. Wat je mogelijk kunt doen is overdag het vermogen beperken om "ongelukjes" voor te zijn en 's nachts draaien op vol laadvermogen. Mocht je op de betreffende fase ook PV terugleveren, dan kun je het vermogen overdag reactief ophogen om NOM aan te kunnen houden.

N.B. Disclaimer: Ik ben geen electricien, dus ik heb geen idee of de meterkast intern langdurig hoger dan 25A op een fase aankan. Aangezien je ook een 1x40A aansluiting kunt hebben lijkt me van wel, maar kom niet bij mij klagen als er zaken misgaan.

[R.K]

Ik heb een automatisering gemaakt die mijn batterij onder een bepaalde spread op standby zet of niet. Maar het is mij niet geheel duidelijk of ik nu de 'dynamische spread indicatie' daar voor moet aanhouden of de 'dynamische spread indicatie NOM'

Ik zie in mijn dashboard dat er verschillende waardes staan bij de indicaties. Wie kan mij duidelijkheid geven welke ik het best als meetpunt kan gebruiken voor mijn automatisering?

[gielz]

R.K schreef op maandag 5 januari 2026 @ 15:00:
Ik heb een automatisering gemaakt die mijn batterij onder een bepaalde spread op standby zet of niet. Maar het is mij niet geheel duidelijk of ik nu de 'dynamische spread indicatie' daar voor moet aanhouden of de 'dynamische spread indicatie NOM'

Ik zie in mijn dashboard dat er verschillende waardes staan bij de indicaties. Wie kan mij duidelijkheid geven welke ik het best als meetpunt kan gebruiken voor mijn automatisering?

Dynamisch Spread Indicatie is de berekening van je goedkoopste en duurste uren. Pak je de NOM variant dan kijkt hij pas naar het duurste uur na de eerste goedkoopste uur. Hoe ga je de batterij exact laten draaien? Goedkoop laden, Duur NOM en daar tussen Standby?

[R.K]

gielz schreef op maandag 5 januari 2026 @ 15:13:
[...]


Hoe ga je de batterij exact laten draaien? Goedkoop laden, Duur NOM en daar tussen Standby?

Bij mij draait hij met een spread van 22% daaronder standby daarboven Dynamisch NOM. Daartussen niets. Dus wat is dan de beste optie? spread of spread NOM?

[gielz]

R.K schreef op maandag 5 januari 2026 @ 15:43:
[...]


Bij mij draait hij met een spread van 22% daaronder standby daarboven Dynamisch NOM. Daartussen niets. Dus wat is dan de beste optie? spread of spread NOM?

Ik zou dan voor de reguliere spread gaan omdat de ander specifiek bedoelt is om alle uren NOM te draaien en niet alleen op de duurste momenten.

Als het goed is zal er binnenkort ook een modus Dynamisch NOM (Duur) zijn. Die alles gewoon automatisch voor je doet. Op de goedkope momenten laden en laden van overschot en daarna op de duurste uren dit als NOM in zetten.

[R.K]

Bedankt voor je antwoord en uitleg

[gielz]

Gielz Februari test (deel 2)

Op de valreep toch maar even de 2 nieuwe modus opties toegevoegd voor de Februari test.
Dynamisch NOM (Duur) en Dynamisch Handelen

Voor de gene die dit willen testen; https://github.com/Gielz1...1986-Februari-2026-update

Graag alle bugs via DM of via Github. Intern zijn alle modus opties getest.

Releasenotes ruw

2 nieuwe modus opties

Dynamisch NOM (Duur) en Dynamisch Handelen

3 nieuw instelbare entiteiten

Oplaadmarge
Standaard in HEMS word er een marge aangehouden van 50 watt. Hierbij houd de huidige versie 40 watt aan wat dus vanaf nu instelbaar is van 0 tot 50 watt via deze entiteit. Handig in de winter als je alle prik binnen wilt halen.

Ontlaadmarge
Bij iedereen wel verschillend. De ene wilt net wat meer ontladen dan gevraagd word om echt 0 te importeren en de ander juist niet. Nu ook instelbaar van 0 tot 50 watt. In de huidige versie is dit 2 watt.

Standby vertraging
Een doorn in het oog. Ik zie bij andere aansturingen dat de Smartmode op 0 gezet word direct als het vermogen ook op 0 watt staat. Zelf was ik hier geen voorstander van en zie dit bijvoorbeeld ook niet terug bij de Homewizard PIB. Vandaar nu netjes instelbaar van 5-30 minuten. Zodra er dan xx minuten geen activiteit is zal hij smartmode op 0 zetten om de "waakvlam" zoals ik hem zelf noem uit te zetten. Hierna toont een KWH MID meter 0 watt maar uiteraard is er nog wat vermogen nodig intern voor de BMS.

De modus "Standby" wat handmatig was deed dit al correct en altijd direct wat ongewijzigd is. Nu doet de gehele aansturing mee zoals NOM, Slim Opladen etc.

Kleine aanpassingen

SOC bescherming
Gaat nu alleen aan de slag 2 uur na zonsopkomst en 2 uur voor zonsondergang

Handmatig modus
Bij aanpassing van vermogen alleen nog elke 4 seconden via de restapi. Dit was voorheen direct wat bij spammen de api om zeep hielp.

Restcommands
Aanpassing voor nodered doorgevoerd

[Leguan]

gielz schreef op maandag 5 januari 2026 @ 20:42:

Gielz Februari test (deel 2)

Op de valreep toch maar even de 2 nieuwe modus opties toegevoegd voor de Februari test.
Dynamisch NOM (Duur) en Dynamisch Handelen

Voor de gene die dit willen testen; https://github.com/Gielz1...1986-Februari-2026-update

Graag alle bugs via DM of via Github. Intern zijn alle modus opties getest.

Releasenotes ruw

2 nieuwe modus opties

Dynamisch NOM (Duur) en Dynamisch Handelen
[Afbeelding]

3 nieuw instelbare entiteiten

Oplaadmarge
Standaard in HEMS word er een marge aangehouden van 50 watt. Hierbij houd de huidige versie 40 watt aan wat dus vanaf nu instelbaar is van 0 tot 50 watt via deze entiteit. Handig in de winter als je alle prik binnen wilt halen.

Ontlaadmarge
Bij iedereen wel verschillend. De ene wilt net wat meer ontladen dan gevraagd word om echt 0 te importeren en de ander juist niet. Nu ook instelbaar van 0 tot 50 watt. In de huidige versie is dit 2 watt.

Standby vertraging
Een doorn in het oog. Ik zie bij andere aansturingen dat de Smartmode op 0 gezet word direct als het vermogen ook op 0 watt staat. Zelf was ik hier geen voorstander van en zie dit bijvoorbeeld ook niet terug bij de Homewizard PIB. Vandaar nu netjes instelbaar van 5-30 minuten. Zodra er dan xx minuten geen activiteit is zal hij smartmode op 0 zetten om de "waakvlam" zoals ik hem zelf noem uit te zetten. Hierna toont een KWH MID meter 0 watt maar uiteraard is er nog wat vermogen nodig intern voor de BMS.

De modus "Standby" wat handmatig was deed dit al correct en altijd direct wat ongewijzigd is. Nu doet de gehele aansturing mee zoals NOM, Slim Opladen etc.

Kleine aanpassingen

SOC bescherming
Gaat nu alleen aan de slag 2 uur na zonsopkomst en 2 uur voor zonsondergang

Handmatig modus
Bij aanpassing van vermogen alleen nog elke 4 seconden via de restapi. Dit was voorheen direct wat bij spammen de api om zeep hielp.

Restcommands
Aanpassing voor nodered doorgevoerd

Mooie toevoeging die nieuwe modus Dynamisch NOM (duur)! Hopelijk met dezelfde resultaten als de automatisering die ik hier gister heb gedeeld en vandaag (dag met veel spread) het volgende resultaat heeft opgeleverd:

[edjes]

Haha, @gielz , heb ik dat net allemaal bij elkaar zitten programmeren ;-)
Dank! ik ga het testen!!

[edjes]

@gielz Is het een idee om bij elke modus je bedoelde gebruik te benoemen?
Bijv:
- NOM voor de zomer, zonnepanelen vullen, altijd NOM bij geen zon-overschot of handmatig vullen
- Dyn NOM hybride NOM, waar alleen bijladen mogelijk is, verder zelfde als NOM, altijd NOM
- Dyn NOM duur; zomer met weinig panelen, of winter, en bij kleine batterij om het meeste eruit te halen; alleen laden op groene tijden, ontladen op rode tijden

Zoiets?
Ik begin het nu langzaam allemaal te snappen wat je geschreven hebt en ben zelf aan het bijschuren voor mijn eigen situatie, echter word door je ingehaald met dyn NOM duur; mooie toevoeging!

[ Voor 5% gewijzigd door edjes op 05-01-2026 21:41 ]

[gielz]

edjes schreef op maandag 5 januari 2026 @ 21:40:
@gielz Is het een idee om bij elke modus je bedoelde gebruik te benoemen?
Bijv:
- NOM voor de zomer, zonnepanelen vullen, altijd NOM bij geen zon-overschot of handmatig vullen
- Dyn NOM hybride NOM, waar alleen bijladen mogelijk is, verder zelfde als NOM, altijd NOM
- Dyn NOM duur; zomer met weinig panelen, of winter, en bij kleine batterij om het meeste eruit te halen; alleen laden op groene tijden, ontladen op rode tijden

Zoiets?
Ik begin het nu langzaam allemaal te snappen wat je geschreven hebt en ben zelf aan het bijschuren voor mijn eigen situatie, echter word door je ingehaald met dyn NOM duur; mooie toevoeging!

Zeker een goed idee, ik zal dit in de readme opnemen zodra de update op de release github staat.