Zendure producten in Home Assistant integreren deel 2

[Taro]

FireSon schreef op woensdag 6 augustus 2025 @ 20:05:
Je moet even kijken of de socStatus op auto-calibratie staat, dat heb ik nu ook! Is ook voor mij een nieuwe ervaring

Staat hier op "Actief", maar aangezien de rest van de data niet correct is vraag ik mij af of die waarde wel correct is. Hij was al 100% trouwens en gestopt met laden, dus zal niet aan het kalibreren zijn.

Stekker ligt ernaast, Hyper van de AB2000S'en af, even 10 minuten wachten

[Roedie84]

dennisdew16 schreef op woensdag 6 augustus 2025 @ 17:37:
[...]

Heb je wel het "rest" stukje overgenomen?

code:

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

Dit werkt bij mij al enkele weken stabiel. En soms moet je HA een extra keer opstarten voordat deze beschikbaar komt. Oja en je moet de lokale API functie aanzetten in HW:)

Het werkt inmiddels, iets met toe aan vakantie en een verkeerd IP adres

[Roedie84]

FireSon schreef op woensdag 6 augustus 2025 @ 20:05:
Je moet even kijken of de socStatus op auto-calibratie staat, dat heb ik nu ook! Is ook voor mij een nieuwe ervaring

Waar kun je dat instellen, bij mij geeft ie "Actief" als waarde terug. Of is dat de "auto calibratie"?

[Taro]

@FireSon Heb 3 fuse groups:

2400 AC 1 - 3600 Watt
2400 AC 2 + Hyper 2000 - 3600 Watt
2400 AC 3 - 3600 Watt

Als de Hyper 1200 gaat terugleveren stopt 2400 AC 2 er helemaal mee.
Zet ik de Hyper op Fuse group 3, dan stopt 2400 AC 3 er helemaal mee.

De 3600 Watt wordt dus nooit volledig gebruikt.

[Taro]

Fireson geeft aan het issue rondom de max limiet van de fusegroeps te hebben gevonden, wordt opgelost.

Draai nu wel even de Hyper via HEMS en 2400AC's via HA, dan werkt het prima.

[wosp]

@Taro Ik draai ook pre17 maar heb nog steeds dat er bij een load < 2400 Watt maar 1 omvormer tegelijk actief is. Hoe heb jij dat uitgezet? Ik vind het op zich een mooie functie om de RTE te verbeteren, maar ervaar nu ook wel wat onbalans issues op de fases. Dan maar een iets mindere RTE…

[geert1992]

wosp schreef op woensdag 6 augustus 2025 @ 23:10:
@Taro Ik draai ook pre17 maar heb nog steeds dat er bij een load < 2400 Watt maar 1 omvormer tegelijk actief is. Hoe heb jij dat uitgezet? Ik vind het op zich een mooie functie om de RTE te verbeteren, maar ervaar nu ook wel wat onbalans issues op de fases. Dan maar een iets mindere RTE…

Dat is nu een gegeven volgensmij(die releases gaan zo hard, harder dan ik volgen kan), hopelijk komt fireson met een keuze optie in een volgende release.

[ Voor 4% gewijzigd door geert1992 op 06-08-2025 23:34 ]

[martinvdm]

Als de percentages niet geheel kloppen kunnen we toch het voltage uitlezen wanneer die 100% is en wanneer die leeg is en op basis daarvan wellicht een beter percentage uitrekenen? In home assistant een formule zetten en het ‘werkelijke’ percentage laten zien.

code:

template:
  - sensor:
      - name: "Battery Percentage"
        unit_of_measurement: "%"
        state: >
          {% set voltage = states('sensor.zendure_battery_voltage') | float %}
          {% set min_voltage = XXX %}
          {% set max_voltage = YYY %}
          {% set percentage = ((voltage - min_voltage) / (max_voltage - min_voltage)) * 100 %}
          {{ [0, percentage, 100] | sort | first }}
        device_class: battery
        state_class: measurement
        availability: "{{ states('sensor.zendure_battery_voltage') | is_number }}"

Ik heb de batterij nog niet maar mogelijk helpt dit anderen.

[Taro]

Iemand anders ook pre19 geïnstalleerd? Lijkt hier helemaal niets meer te doen

[geert1992]

Taro schreef op donderdag 7 augustus 2025 @ 20:44:
Iemand anders ook pre19 geïnstalleerd? Lijkt hier helemaal niets meer te doen

Vervelend, dat is natuurlijk niet waar je op zit te wachten.
Hier lijkt alles naar behoren te werken, maar ik heb zelf geen 2400AC’s zoals jij.

[Taro]

Deze error komt langs:

File "/config/custom_components/zendure_ha/manager.py", line 241, in _p1_changed
self.update_power(self.setpoint, ManagerState.DISCHARGING if self.setpoint >= 0 else ManagerState.CHARGING)
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/zendure_ha/manager.py", line 266, in update_power
g = d.fusegroup
^^^^^^^^^^^
AttributeError: 'SolarFlow800' object has no attribute 'fusegroup'. Did you mean: 'fuseGroup'?

[Taro]

En nog wat andere meldingen ivm onbekend SolarflowPro device.

[c0mplex1]

Zal me niets verbazen als het een typfout in line 266 is.
Volgens mij moet line 266 g = d.fuseGroup zijn.
Die andere fouten weet ik niet.

[mrme12345]

Taro schreef op donderdag 7 augustus 2025 @ 20:44:
Iemand anders ook pre19 geïnstalleerd? Lijkt hier helemaal niets meer te doen

Ja bij mij ook problemen. Mijn node red aansturing van de hyper reageert ook niet meer. Bij beta 18 werkte dat nog prima.

[Aziraphale]

Bij mij bevriest de Hyper weer sinds Pre17 en de oorzaakt lijkt met de NOM te maken te hebben. @FireSon heb je daar iets aan veranderd?

@Taro Pre19 start bij mij ook met de Hyper, dus er zal een fout in zitten voor de 2400 of 800.

[ Voor 26% gewijzigd door Aziraphale op 07-08-2025 21:32 ]

[geert1992]

Taro schreef op donderdag 7 augustus 2025 @ 20:44:
Iemand anders ook pre19 geïnstalleerd? Lijkt hier helemaal niets meer te doen

Draait het intussen weer?

[Taro]

geert1992 schreef op donderdag 7 augustus 2025 @ 21:33:
[...]


Draait het intussen weer?

Ja, teruggegaan naar pre17

En heb de SF800's ieder even van Geen fusegroup (bewust), naar een andere optie gezet en weer terug naar Geen fusegroup, daardoor verdween nog een andere melding.

En ik heb dus een unknown device ineens....

En die spelfout, maar pre17 werkt weer even prima zo, upgrade morgenochtend wel naar pre20, heb Fireson de meldingen gestuurd.

[geert1992]

Taro schreef op donderdag 7 augustus 2025 @ 21:34:
[...]

Ja, teruggegaan naar pre17

En heb de SF800's ieder even van Geen fusegroup (bewust), naar een andere optie gezet en weer terug naar Geen fusegroup, daardoor verdween nog een andere melding.

En ik heb dus een unknown device ineens....

En die spelfout, maar pre17 werkt weer even prima zo, upgrade morgenochtend wel naar pre20, heb Fireson de meldingen gestuurd.

Fijn dat je het nu in ieder geval hebt opgelost, toevallig ook de vraag aan @FireSon gesteld wanneer de stable release komt? Hoe ziet dat unknown device eruit?

[Taro]

geert1992 schreef op donderdag 7 augustus 2025 @ 21:39:
[...]


Fijn dat je het nu in ieder geval hebt opgelost, toevallig ook de vraag aan @FireSon gesteld wanneer de stable release komt? Hoe ziet dat unknown device eruit?

Zou ik pas doen als het stable is

Het unknown device blijkt mijn Hyper - 1 te zijn, die ik dus al heb verkocht, niet meer in mijn Zendure account en niet in HA staat.

Fireson heeft inmiddels iets gevonden rondom de Unused fusegroups, dat is/wordt opgelost.

[Devke]

Suggestie: Berekenen hoeveel cycli je batterijen hebben gedraaid. Dit laat Zendure nu niet zien.

@FireSon @gielz en aan alle bouwers in HA. Just an idea.

[geert1992]

Het is zo ver, Versie 1.1.0 is in de lucht! Hopelijk zijn de meeste fouten eruit!

@Devke ik heb na updates regelmatig gehad dat sensoren opnieuw werden aangemaakt, dan zou Zendure dit zelf moeten inbouwen en naar hun server moeten pushen.

[ Voor 50% gewijzigd door geert1992 op 08-08-2025 08:16 ]

[Devke]

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

@Devke ik heb na updates regelmatig gehad dat sensoren opnieuw werden aangemaakt, dan zou Zendure dit zelf moeten inbouwen en naar hun server moeten pushen.

Dan moet je het denk ik los bouwen los van de officiële integratie. Het is maar een suggestie.

[Taro]

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

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

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

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

[wosp]

Voelt als een haast klus om per se een stable release uit te moeten brengen voor een bepaalde datum, of de software nou klaar is of niet. Hoewel erg veel potentie aanwezig is, is deze software simpelweg echt nog niet productie waardig. Het is zelfs zo erg dat in deze haast vergeten is om het versie nummer aan te passen onder Apparaten en dan de integratie. Daar staat nog steeds pre19.

Ik heb geen enkele moeite met problemen in pre-releases, maar in een stable horen niet nog zoveel bekende problemen te zitten. Doet mij erg twijfelen aan het blijven gebruiken van de @FireSon integratie, stabiliteit en betrouwbaarheid zijn schijnbaar geen zaken waar waarde aan gehecht wordt. Ik zou als verantwoordelijke heel snel deze release terugtrekken en opnieuw uitbrengen als pre20. Dit is erg amateuristisch.

[geert1992]

Taro schreef op vrijdag 8 augustus 2025 @ 08:40:
[...]

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

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

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

[Afbeelding]

[Afbeelding]

Daarom zei ik: hopelijk zijn de meeste fouten eruit, maar ik wilde het wel positief benaderen. Misschien krijgen we de stable release 1.1.1, 1.1.2, etc etc heel snel.
Maar goed, jij mag gewoon rustig op de wc zitten. Ik ga lekker testen en klop wel even aan als de party een echte party wordt.

[Mediacj]

wosp schreef op vrijdag 8 augustus 2025 @ 09:00:
Voelt als een haast klus om per se een stable release uit te moeten brengen voor een bepaalde datum, of de software nou klaar is of niet. Hoewel erg veel potentie aanwezig is, is deze software simpelweg echt nog niet productie waardig. Het is zelfs zo erg dat in deze haast vergeten is om het versie nummer aan te passen onder Apparaten en dan de integratie. Daar staat nog steeds pre19.

Ik heb geen enkele moeite met problemen in pre-releases, maar in een stable horen niet nog zoveel bekende problemen te zitten. Doet mij erg twijfelen aan het blijven gebruiken van de @FireSon integratie, stabiliteit en betrouwbaarheid zijn schijnbaar geen zaken waar waarde aan gehecht wordt. Ik zou als verantwoordelijke heel snel deze release terugtrekken en opnieuw uitbrengen als pre20. Dit is erg amateuristisch.

Ik ben als gebruiker al blij dat er iemand is die geheel vrijwillig de moeite neemt om zo’n complexe koppeling met Home Assistant te realiseren.

Als je ziet hoeveel uren @FireSon hier inmiddels in heeft gestoken, zouden we best wat positiever mogen reageren. @FireSon, nogmaals bedankt voor al je inspanningen!

[gielz]

Als ik thuis ben zal ik de TS even een update geven. Heb nog wel een aantal vragen aan gebruikers van de 1.1.

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

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

[geert1992]

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

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

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

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

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

[wosp]

Mediacj schreef op vrijdag 8 augustus 2025 @ 09:20:
[...]

Ik ben als gebruiker al blij dat er iemand is die geheel vrijwillig de moeite neemt om zo’n complexe koppeling met Home Assistant te realiseren.

Als je ziet hoeveel uren @FireSon hier inmiddels in heeft gestoken, zouden we best wat positiever mogen reageren. @FireSon, nogmaals bedankt voor al je inspanningen!

Zeker, maar dat betekent niet dat je niet kritisch mag zijn op bepaalde zaken.

[wosp]

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

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

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

Nee, niet 100% lokaal met zenSDK. Als de boel draait en internet valt weg is er niks aan de hand. Zodra HA herstart wordt heb je wel een probleem, want bij de start heeft ie nog steeds verbinding nodig met de Zendure Cloud (waarom is mij een raadsel). Volgens mij kan de 2400AC zowel via zenSDK als MQTT, maar dat weet ik niet zeker. Ik gebruik zenSDK, want veel simpeler en hoe minder lagen er tussen hoe beter.

[jordyc]

wosp schreef op vrijdag 8 augustus 2025 @ 10:03:
[...]


Nee, niet 100% lokaal met zenSDK. Als de boel draait en internet valt weg is er niks aan de hand. Zodra HA herstart wordt heb je wel een probleem, want bij de start heeft ie nog steeds verbinding nodig met de Zendure Cloud (waarom is mij een raadsel). Volgens mij kan de 2400AC zowel via zenSDK als MQTT, maar dat weet ik niet zeker. Ik gebruik zenSDK, want veel simpeler en hoe minder lagen er tussen hoe beter.

Ik heb met de 2400AC op ZenSDK ook dat wanneer ik de batterij van het internet af haal hij geen updates meer pushed naar HA.

[Taro]

wosp schreef op vrijdag 8 augustus 2025 @ 10:00:
[...]


Zeker, maar dat betekent niet dat je niet kritisch mag zijn op bepaalde zaken.

Wat hierin ook meespeelt: Het begint als een hobby project, wat early adopters, etc. Die mensen kunnen omgaan met regressie, bugs, etc. De Fireson integratie is al ver voorbij een hobby project, er zijn serieuze en grote stappen gezet en er zitten al enorm veel uren in en er is al een zeer mooi resultaat behaald. Ik spreek Fireson ook persoonlijk en heb echt alle respect voor hem, zijn inzet en wat er nu staat. Laat daar ook echt geen verkeerde indruk over bestaan, super tof wat hij heeft weten te realiseren.

Wat er nu echter wel gaat meespelen is dat Zendure als wereldwijde organisatie dit aankondigt als officiële Zendure Home Assistant integratie. Ik zie op verschillende plekken mensen langskomen die Zendure producten kopen met als doel ze in Home Assistant te gaan gebruiken. Het wordt als versie 1.0.0 aangekondigd.

In deze fase zit je niet meer aan tafel met early adopters en tech nerds, maar met een wereldwijd publiek dat software gaat gebruiken en verwacht dat het simpelweg goed werkt. De naam en reputatie van Zendure staat vanaf vandaag op het spel als er iets in de soep loopt. De supportmedewerkers kunnen overstelpt worden met honderden of duizenden meldingen per dag als de integratie een bug bevat. Het gaat niet meer om 5-25 mensen die even met een bug moeten leven en daar begrip voor hebben, het gaat om tienduizenden mensen waarbij hun energiemanagement system ineens niet meer werkt en daar boos over zullen worden. Ze hebben verwachtingen en die dien je goed te managen.

In deze nieuwe fase moet je echt strak op een releaseproces zitten, omdat de impact van een bug vanaf vandaag vele malen groter is dan die voorheen was. Het publiek is veranderd.

Ik ga al 20 jaar mee in de productontwikkeling als programmeur, manager, CTO, etc., heb bij multinationals gewerkt en ik heb servicedesks overspoeld zien worden door slechte releaseprocessen, kleine bugs, releases op vrijdag, etc. Daarom hamer ik er hier ook zo op, dat is goed bedoeld.

Tot vandaag was het een leuk project om aan mee te werken, vanaf vandaag is het een officieel door Zendure ondersteund project geworden en daar hoort ook een corporate benadering en aanpak bij. Je komt dan in strakkere releaseprocessen, je moet support leveren, op Facebook groepen gaan mensen hun frustratie uiten, etc. dat hoort er nou eenmaal bij.

En dan kan je niet van de ene op de andere dag een pre-release als stable versie releasen zonder te hebben gevalideerd bij een kleinere fast ring release groep dat het voor hen in ieder geval nu stabiel werkt. Grote kans dat het stabiel werkt, maar dat wil je verifiëren bij n>1.

Nogmaals: Dank aan Fireson, grote kans dat de stable versie goed werkt, maar professioneel gezien is dit wel een aandachtspunt. Het is geen hobby of early adopters product meer, maar een officieel Zendure product met een wereldwijde markt, grote klantengroep en bijbehorende verwachtingen en die moet je heel goed managen.

[wosp]

jordyc schreef op vrijdag 8 augustus 2025 @ 10:49:
[...]


Ik heb met de 2400AC op ZenSDK ook dat wanneer ik de batterij van het internet af haal hij geen updates meer pushed naar HA.

Even voor de zekerheid en misschien een stomme vraag; hoe haal jij de batterij van internet af? Want hier werkt dat namelijk wel (tenminste, van de week toen ik dit getest heb). Ik blokkeer in mijn router internet toegang voor de batterijen, ze blijven dus wel met wifi verbonden maar alles wat de default gateway op gaat wordt op de gateway dus tegengehouden dmv een firewall regel. Als je echt wifi ontkoppelt zou wat jij beschrijft uiteraard kloppen.

[gielz]

wosp schreef op vrijdag 8 augustus 2025 @ 11:16:
[...]


Even voor de zekerheid en misschien een stomme vraag; hoe haal jij de batterij van internet af? Want hier werkt dat namelijk wel (tenminste, van de week toen ik dit getest heb). Ik blokkeer in mijn router internet toegang voor de batterijen, ze blijven dus wel met wifi verbonden maar alles wat de default gateway op gaat wordt op de gateway dus tegengehouden dmv een firewall regel. Als je echt wifi ontkoppelt zou wat jij beschrijft uiteraard kloppen.

Het gaat mis bij het herstarten van HA. Hij heeft dan internet nodig. Staat inmiddels ook op de github.

[Aziraphale]

Wat voor versie vermeld hij onder Devices and Services na de update via redownload in HACS? Bij mij namelijk nog steeds 1.1.0-pre19, terwijl ik in HACS wel al gewoon 1.1.0 heb staan

[Taro]

Aziraphale schreef op vrijdag 8 augustus 2025 @ 13:22:
Wat voor versie vermeld hij onder Devices and Services na de update via redownload in HACS? Bij mij namelijk nog steeds 1.1.0-pre19, terwijl ik in HACS wel al gewoon 1.1.0 heb staan

1.1.0-pre19 inderdaad.

[mrme12345]

Bij mij lijkt de official release het goed te doen tot nu toe. Ik kan mijn node red scripts ook weer draaien via de integratie en alles loopt nog soepel :-) dus goed werk @FireSon Dank!

[FireSon]

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

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

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

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

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

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

[Aziraphale]

@FireSon Bij mij draait hij goed en ik hoop zonder bevriezingen, maar als die er nog wel komen dan krijg ik een melding, loop ik naar de kelder en til mijn Hyper even op. First world problems...

Het resultaat van je inspanningen is prachtig en helemaal mooi dat het nu in samenwerking met Zendure gaat. En te aanzien van de stuurlui: Ze doen het je zelf niet na, ik zeker niet!

[jordyc]

wosp schreef op vrijdag 8 augustus 2025 @ 11:16:
[...]


Even voor de zekerheid en misschien een stomme vraag; hoe haal jij de batterij van internet af? Want hier werkt dat namelijk wel (tenminste, van de week toen ik dit getest heb). Ik blokkeer in mijn router internet toegang voor de batterijen, ze blijven dus wel met wifi verbonden maar alles wat de default gateway op gaat wordt op de gateway dus tegengehouden dmv een firewall regel. Als je echt wifi ontkoppelt zou wat jij beschrijft uiteraard kloppen.

Ik zet de batterij in een family group die ik daarna de toegang tot het internet ontzeg. In dezelfde groep zit ook de HW P1 meter en die blijft wel waardes doorgeven, dus het is niet zo dat de groep ook van het lokale netwerk af wordt gehouden.

[CopyCatz]

Vooropgesteld dat ik al het werk aan deze integratie zeer op prijs stel en de medewerking van Zendure prima is; ik zou toch wel iets meer documentatie willen voordat ik dit ga installeren. Die is vrij summier voor software die toch wel hele riskante dingen kan doen en ik heb geen tijd om meerdere tweakers threads door te lezen. Er wordt nu gesproken over een api en token, maar de installatie handleiding heeft het nog steeds over mqtt. Aangezien een directe verbinding tussen HA en de lokale api van Zendure me wel de meest fail safe oplossing lijkt (zonder online verbindingen en mqtt servers) ben ik wel benieuwd hoe e.e.a. nu werkt.

[DJN]

@FireSon Ben echt heel tevreden met de integratie. Is inmiddels al heel lang (bijna altijd) zeer goed bruikbaar en wordt gaandeweg de tijd alleen maar beter! Gelukkig al heel lang geen freeze meer gehad. Dank voor al je werk!!

Werkt nu bij mij ook goed met 3 Hypers die ik lokaal aanstuur en 1 AC2400 via ZenSDK. Mooi dat je nu zelf makkelijk 1 of meerdere apparaten kunt uitschakelen en weer kunt betrekken bij welke taak dan ook door ze in de Device fusegroup op 'Niet gebruikt, apparaat heeft geen zekeringgroep' te zetten of weer een andere waarde te geven als je ze weer wil gebruiken. Makkelijk te gebruiken in scripts en automatiseringen.

Paar punten:
- AC2400 blijft na gebruik vaak zo'n 17-22 W terugleveren, daar is al eerder over geschreven. Daarbij eerst wisselende reactie op stoppen met laden of ontladen via ZenSDK opdracht maar blijkt bij mij altijd naar 0 te gaan indien ik eerst commando stop met ontladen (outputLimit 0) geef en kort daarna commando stop met laden (inputLimit 0). Hebben anderen ook deze ervaring en indien het geval zou je dan zo iets dergelijks in de integratie kunnen inbouwen zolang dit niet bij Zendure opgelost wordt, bv als AC2400 gedurende x tijd niet gebruikt wordt?

- Mijn AC2400 heeft aanzienlijk meer opslagcapaciteit dan de Hypers. Bij het opladen loopt de AC2400 percentueel behoorlijk achter. Kijk je in het algoritme ook naar opslagcapaciteit per device of vooral naar beschikbare energie per device oid? Zou voor mijn situatie handiger zijn als de AC2400 percentueel ongeveer evenveel oplaadt als de Hypers zodat ik altijd alle omvormers kan gebruiken als ik ze nodig heb.

[Taro]

CopyCatz schreef op vrijdag 8 augustus 2025 @ 23:05:
Vooropgesteld dat ik al het werk aan deze integratie zeer op prijs stel en de medewerking van Zendure prima is; ik zou toch wel iets meer documentatie willen voordat ik dit ga installeren. Die is vrij summier voor software die toch wel hele riskante dingen kan doen en ik heb geen tijd om meerdere tweakers threads door te lezen. Er wordt nu gesproken over een api en token, maar de installatie handleiding heeft het nog steeds over mqtt. Aangezien een directe verbinding tussen HA en de lokale api van Zendure me wel de meest fail safe oplossing lijkt (zonder online verbindingen en mqtt servers) ben ik wel benieuwd hoe e.e.a. nu werkt.

1 van de installatiehandleidingen is door mij beschreven, zal deze morgen aanpassen naar 1.1.0.

[Taro]

Heb https://iotdomotica.nl/tu...tant-integration-tutorial aangepast nav 1.1.0, feedback is welkom. Zal morgen nog wat screenshots toevoegen.

[ Voor 14% gewijzigd door Taro op 08-08-2025 23:57 ]

[Devke]

DJN schreef op vrijdag 8 augustus 2025 @ 23:24:
@FireSon Ben echt heel tevreden met de integratie. Is inmiddels al heel lang (bijna altijd) zeer goed bruikbaar en wordt gaandeweg de tijd alleen maar beter! Gelukkig al heel lang geen freeze meer gehad. Dank voor al je werk!!

Werkt nu bij mij ook goed met 3 Hypers die ik lokaal aanstuur en 1 AC2400 via ZenSDK. Mooi dat je nu zelf makkelijk 1 of meerdere apparaten kunt uitschakelen en weer kunt betrekken bij welke taak dan ook door ze in de Device fusegroup op 'Niet gebruikt, apparaat heeft geen zekeringgroep' te zetten of weer een andere waarde te geven als je ze weer wil gebruiken. Makkelijk te gebruiken in scripts en automatiseringen.

Paar punten:
- AC2400 blijft na gebruik vaak zo'n 17-22 W terugleveren, daar is al eerder over geschreven. Daarbij eerst wisselende reactie op stoppen met laden of ontladen via ZenSDK opdracht maar blijkt bij mij altijd naar 0 te gaan indien ik eerst commando stop met ontladen (outputLimit 0) geef en kort daarna commando stop met laden (inputLimit 0). Hebben anderen ook deze ervaring en indien het geval zou je dan zo iets dergelijks in de integratie kunnen inbouwen zolang dit niet bij Zendure opgelost wordt, bv als AC2400 gedurende x tijd niet gebruikt wordt?

- Mijn AC2400 heeft aanzienlijk meer opslagcapaciteit dan de Hypers. Bij het opladen loopt de AC2400 percentueel behoorlijk achter. Kijk je in het algoritme ook naar opslagcapaciteit per device of vooral naar beschikbare energie per device oid? Zou voor mijn situatie handiger zijn als de AC2400 percentueel ongeveer evenveel oplaadt als de Hypers zodat ik altijd alle omvormers kan gebruiken als ik ze nodig heb.

Dat stukje waarin je schrijft dat er altijd na actie nog ontladen wordt met 17-22 Watt is herkenbaar. Dit ligt niet aan de @FireSon integratie. Die gebruik ik niet en heb dezelfde issue. Ik heb het bij Zendure gemeld. Ze zijn het aan het uitzoeken. Ik had hier al een stukje in het hoofdtopic over gezet. To be continued. Loopt dus.

[wosp]

DJN schreef op vrijdag 8 augustus 2025 @ 23:24:
- AC2400 blijft na gebruik vaak zo'n 17-22 W terugleveren, daar is al eerder over geschreven. Daarbij eerst wisselende reactie op stoppen met laden of ontladen via ZenSDK opdracht maar blijkt bij mij altijd naar 0 te gaan indien ik eerst commando stop met ontladen (outputLimit 0) geef en kort daarna commando stop met laden (inputLimit 0). Hebben anderen ook deze ervaring en indien het geval zou je dan zo iets dergelijks in de integratie kunnen inbouwen zolang dit niet bij Zendure opgelost wordt, bv als AC2400 gedurende x tijd niet gebruikt wordt?

Ik ben er inmiddels achter dat dit alleen speelt indien de batterij niks staat te doen en de packState staat nog niet op 0 (Standby). De packState is alleen officieel een ReadOnly waarde, dus weet niet of je deze ook kan beschrijven om te forceren naar 0 te gaan. Je ziet dit sluipverbruik overigens alleen als je er een 3rd party meter tussen hebt zitten, de Zendure zelf zegt dat ie niks verbruikt op dat moment, maar doet dat dus wel. Als packState te beschrijven is, is dit simpel op te lossen. Overigens heeft ie die afwijking ook bij handmatig laden/ontladen, altijd per omvormer ongeveer 20 Watt afwijking naar beneden.

[mrme12345]

Ik heb steeds freezes van mijn hyper sinds de nieuwe release.....heb ik nooit gehad op deze manier. En hyper er af halen en er weer op helpt ook maar even daarna weer freeze..

@fireson ik kan hem ook niet weer online krijgen zoals in verleden met die mqtt knop en jij gaf aan dat dit om de vijf minuten automatisch gebeurt nu, maar er gebeurt niets en krijg steeds freezes. Suggesties om op te lossen?

[geert1992]

mrme12345 schreef op zaterdag 9 augustus 2025 @ 09:23:
Ik heb steeds freezes van mijn hyper sinds de nieuwe release.....heb ik nooit gehad op deze manier. En hyper er af halen en er weer op helpt ook maar even daarna weer freeze..

@fireson ik kan hem ook niet weer online krijgen zoals in verleden met die mqtt knop en jij gaf aan dat dit om de vijf minuten automatisch gebeurt nu, maar er gebeurt niets en krijg steeds freezes. Suggesties om op te lossen?

Hij heeft al toegezegd dat de knop terug komt. De 00:00 reset is er ook uit.
Wat hij nog wel doet dat hij bij 5 minuten geen communicatie een reset pushed.

De reset knop komt bij een volgende release, zag al in de code een 1.1.1 klaar staan.

[ Voor 6% gewijzigd door geert1992 op 09-08-2025 10:13 ]

[mrme12345]

geert1992 schreef op zaterdag 9 augustus 2025 @ 10:12:
[...]


Hij heeft al toegezegd dat de knop terug komt. De 00:00 reset is er ook uit.
Wat hij nog wel doet dat hij bij 5 minuten geen communicatie en reset pushed.

Ja alleen die reset na 5 minuten werkt ook niet. Als mijn hyper in freeze zit komt die er gewoon niet meer uit en moet ik de omvormer loskoppelen enz.

[geert1992]

mrme12345 schreef op zaterdag 9 augustus 2025 @ 10:13:
[...]

Ja alleen die reset na 5 minuten werkt ook niet. Als mijn hyper in freeze zit komt die er gewoon niet meer uit en moet ik de omvormer loskoppelen enz.

Klopt, heb ik meer mensen over gehoord intussen.
Als je de log wil aanzetten, en die wil delen met fireson, kan hij ermee aan de slag!

Hij heeft zelf ook een of meerdere hypers, en die runnen al een aantal weken zonder problemen. Dus waar het precies inzit wist hij mij niet te vertellen. En vroeg daarom een log, zodat hij het de fout eruit kan halen.

[mrme12345]

geert1992 schreef op zaterdag 9 augustus 2025 @ 10:21:
[...]


Klopt, heb ik meer mensen over gehoord intussen.
Als je de log wil aanzetten, en die wil delen met fireson, kan hij ermee aan de slag!

Hij heeft zelf ook een of meerdere hypers, en die runnen al een aantal weken zonder problemen. Dus waar het precies inzit wist hij mij niet te vertellen. En vroeg daarom een log, zodat hij het de fout eruit kan halen.

Tot en met beta 17 werkte het bij mij ook zonder freezes. Maar nu met die release 1 alleen maar freezes. Zal hem de log sturen!

probleem is wel dat die direct in de freeze schiet als ik hem weer een x toegevoegd krijg aan de app, soort loop

Update: ik heb hem weer aan de gang, wel met lokale toegang uit. Dus daar lijkt een verband te zitten.

[ Voor 14% gewijzigd door mrme12345 op 09-08-2025 12:14 ]

[wosp]

wosp schreef op zaterdag 9 augustus 2025 @ 01:12:
[...]


Ik ben er inmiddels achter dat dit alleen speelt indien de batterij niks staat te doen en de packState staat nog niet op 0 (Standby). De packState is alleen officieel een ReadOnly waarde, dus weet niet of je deze ook kan beschrijven om te forceren naar 0 te gaan. Je ziet dit sluipverbruik overigens alleen als je er een 3rd party meter tussen hebt zitten, de Zendure zelf zegt dat ie niks verbruikt op dat moment, maar doet dat dus wel. Als packState te beschrijven is, is dit simpel op te lossen. Overigens heeft ie die afwijking ook bij handmatig laden/ontladen, altijd per omvormer ongeveer 20 Watt afwijking naar beneden.

Dit inmiddels getest, maar ondanks dat ik als response een HTTP 200 krijg wordt de waarde niet aangepast, schrijven lijkt dus niet te mogen. Dan is het sluipverbruik niet op te lossen zonder hulp van Zendure lijkt mij.

code:

rest_command:
  zendure_2400_ac_1_stop_sluipverbruik:
    url: http://<IP>/properties/write
    method: POST
    payload: '{"sn":"<SN>","properties":{"packState": 0 }}'

[Aziraphale]

mrme12345 schreef op zaterdag 9 augustus 2025 @ 11:38:
[...]

Tot en met beta 17 werkte het bij mij ook zonder freezes. Maar nu met die release 1 alleen maar freezes. Zal hem de log sturen!

probleem is wel dat die direct in de freeze schiet als ik hem weer een x toegevoegd krijg aan de app, soort loop

Update: ik heb hem weer aan de gang, wel met lokale toegang uit. Dus daar lijkt een verband te zitten.

Bijzonder, want bij mij draait hij in 1.1.0 juist weer zonder freezes. In pre17 was het drama, maar nu weer goed.

[mrme12345]

Aziraphale schreef op zaterdag 9 augustus 2025 @ 12:39:
[...]


Bijzonder, want bij mij draait hij in 1.1.0 juist weer zonder freezes. In pre17 was het drama, maar nu weer goed.

En heb jij hem daarbij ook lokaal aanstaan of alleen cloud? Ja bij mij is het ook maanden goed gegaan, maar nu opeens allerlei problemen. Heel vreemd, alsof iets de hyper getriggerd heeft of zo.

[Aziraphale]

mrme12345 schreef op zaterdag 9 augustus 2025 @ 12:40:
[...]

En heb jij hem daarbij ook lokaal aanstaan of alleen cloud? Ja bij mij is het ook maanden goed gegaan, maar nu opeens allerlei problemen. Heel vreemd, alsof iets de hyper getriggerd heeft of zo.

Lokaal, voor zover ik weet. Hij werkt met de api en mqtt, maar @geert1992 heeft geholpen met de instellingen en hij weet exact hoe het zit.

[geert1992]

Aziraphale schreef op zaterdag 9 augustus 2025 @ 12:46:
[...]


Lokaal, voor zover ik weet. Hij werkt met de api en mqtt, maar @geert1992 heeft geholpen met de instellingen en hij weet exact hoe het zit.

Dat klopt, via de lokale MQTT. De P1-poort loopt via de API met een refreshrate van 1 seconde.
Toen @Aziraphale en ik aan het testen waren of het lokale verkeer daadwerkelijk lokaal verliep, kwamen we er in ieder geval achter dat het niet via Bluetooth werkte. Ik wil het nog eens testen zonder internet, maar dat kregen we niet direct voor elkaar, en toen was de avond te kort.

Is hier iemand die volledig lokaal aanstuurt zonder cloud(internet toegang ontnemen)?

[Aziraphale]

geert1992 schreef op zaterdag 9 augustus 2025 @ 14:01:
[...]


Dat klopt, via de lokale MQTT. De P1-poort loopt via de API met een refreshrate van 1 seconde.
Toen @Aziraphale en ik aan het testen waren of het lokale verkeer daadwerkelijk lokaal verliep, kwamen we er in ieder geval achter dat het niet via Bluetooth werkte. Ik wil het nog eens testen zonder internet, maar dat kregen we niet direct voor elkaar, en toen was de avond te kort.

Is hier iemand die volledig lokaal aanstuurt zonder cloud(internet toegang ontnemen)?

Binnenkort nog maar eens testen.

[geert1992]

Aziraphale schreef op zaterdag 9 augustus 2025 @ 14:03:
[...]


Binnenkort nog maar eens testen.

Lijkt mij een goed idee, thuis krijg ik het niet voor elkaar. Mijn DHCP is een zyxsel, en de kinder beveiliging kreeg ik niet aan de praat.

[gielz]

geert1992 schreef op zaterdag 9 augustus 2025 @ 14:01:
[...]
Is hier iemand die volledig lokaal aanstuurt zonder cloud(internet toegang ontnemen)?

Ja hier, maar dat is een totale ander pakket. 2400ac met de zenSDK (zelfbouw, niet van Fireson). Batterij zit alleen op het internet als ik langer dan een week weg ben. Mocht alles in de soep lopen.

[DJN]

wosp schreef op zaterdag 9 augustus 2025 @ 12:33:
[...]


Dit inmiddels getest, maar ondanks dat ik als response een HTTP 200 krijg wordt de waarde niet aangepast, schrijven lijkt dus niet te mogen. Dan is het sluipverbruik niet op te lossen zonder hulp van Zendure lijkt mij.

code:

rest_command:
  zendure_2400_ac_1_stop_sluipverbruik:
    url: http://<IP>/properties/write
    method: POST
    payload: '{"sn":"<SN>","properties":{"packState": 0 }}'

Zie mijn reactie eerder vandaag, daarmee lukt het wel

[wosp]

DJN schreef op zaterdag 9 augustus 2025 @ 15:09:
[...]


Zie mijn reactie eerder vandaag, daarmee lukt het wel

Dat werkt bij mij ook niet altijd, wel vaak, maar er zijn momenten dat ik commando’s kan blijven sturen en er gebeurd niks. Even met paar watt laden en ontladen en daarna nogmaals 0’s sturen doet dan ook niks.

[DJN]

wosp schreef op zaterdag 9 augustus 2025 @ 16:19:
[...]


Dat werkt bij mij ook niet altijd, wel vaak, maar er zijn momenten dat ik commando’s kan blijven sturen en er gebeurd niks. Even met paar watt laden en ontladen en daarna nogmaals 0’s sturen doet dan ook niks.

Ik kwam erachter dat deze specifieke volgorde bij mij wel altijd werkt: eerst commando stop met ontladen (outputLimit 0) en kort daarna commando stop met laden (inputLimit 0).

[martinvdm]

In de integratie kan ik kiezen voor Local MQTT. Hoewel ik meer met Mqtt doe is het wat verwarrend. Is het óf cloud connectie middels de token? Óf local mqtt? Of toch beide? En als je dat aanvinkt en communicatie verloopt via local MQTT dan werkt het uitsluitend lokaal?

[CopyCatz]

martinvdm schreef op zaterdag 9 augustus 2025 @ 22:12:
In de integratie kan ik kiezen voor Local MQTT. Hoewel ik meer met Mqtt doe is het wat verwarrend. Is het óf cloud connectie middels de token? Óf local mqtt? Of toch beide? En als je dat aanvinkt en communicatie verloopt via local MQTT dan werkt het uitsluitend lokaal?

Volgens mij werkt het zo dat de batterij normaal gezien communiceert met een mqtt server van zendure. Dat gaat op basis van een account. Je kunt de batterij ook laten communiceren met een eigen mqtt server (die van HA in feite). Blijkbaar is het nu zo dat er een "api key" is die de functie van inlog-account voor de mqtt overneemt omdat je er anders 2 moest hebben (1 voor app en 1 voor mqtt). Wat ik niet snap is:

- hoe de lokale api nu in dit geheel verwerkt is
- waarom de integratie nog steeds op basis van mqtt moet terwijl de api veel efficienter en robuuster is en er geen gedoe is met autorisaties met zendure accounts of "api keys".

Ik maak voorlopig wel gebruik van zelfgebouwde api calls.

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

[martinvdm]

CopyCatz schreef op zaterdag 9 augustus 2025 @ 22:21:
[...]


Volgens mij werkt het zo dat de batterij normaal gezien communiceert met een mqtt server van zendure. Dat gaat op basis van een account. Je kunt de batterij ook laten communiceren met een eigen mqtt server (die van HA in feite). Blijkbaar is het nu zo dat er een "api key" is die de functie van inlog-account voor de mqtt overneemt omdat je er anders 2 moest hebben (1 voor app en 1 voor mqtt). Wat ik niet snap is:

- hoe de lokale api nu in dit geheel verwerkt is
- waarom de integratie nog steeds op basis van mqtt moet terwijl de api veel efficienter en robuuster is en er geen gedoe is met autorisaties met zendure accounts of "api keys".

Ik maak voorlopig wel gebruik van zelfgebouwde api calls.

Oké bedankt. Ik vind het nog steeds verwarrend
Je zou verwachten óf een cloud connectie óf lokaal Mqtt. En als je dan nu lokaal Mqtt doet, werkt de cloud connectie dan niet meer? Ik krijg iig die duidelijkheid niet uit de integratie pagina.

[mrme12345]

martinvdm schreef op zaterdag 9 augustus 2025 @ 22:28:
[...]

Oké bedankt. Ik vind het nog steeds verwarrend
Je zou verwachten óf een cloud connectie óf lokaal Mqtt. En als je dan nu lokaal Mqtt doet, werkt de cloud connectie dan niet meer? Ik krijg iig die duidelijkheid niet uit de integratie pagina.

Local is aanvullende optie, als je die aanvinkt kun je daarna kiezen in HA of je communicatie via local mqtt of via cloud laat lopen.

[martinvdm]

mrme12345 schreef op zaterdag 9 augustus 2025 @ 22:43:
[...]

Local is aanvullende optie, als je die aanvinkt kun je daarna kiezen in HA of je communicatie via local mqtt of via cloud laat lopen.

Mmm oke. Ik kan me voorstellen dat local Mqtt snel zal zijn. Wat wordt door jou gebruikt?

[mrme12345]

martinvdm schreef op zaterdag 9 augustus 2025 @ 22:46:
[...]

Mmm oke. Ik kan me voorstellen dat local Mqtt snel zal zijn. Wat wordt door jou gebruikt?

Ik gebruik alleen mijn hyper met fireson en mijn andere devices (2400 ac en 800 pro) rechtstreeks met restapi en node red in ha. De hyper heeft het paar maanden goed gedaan met local en cloud, alleen mey laatste versie local problemen (freezes), dus nu voorlopig alleen cloud in combinatie met node red.

[R.K]

Na 2 weken handmatige aanpassingen om NOM te krijgen heb ik vandaag mijn Everhome P1 aan mijn Solarflow 2400 gekoppeld. Tot nu toe draait het aardig NOM. Maar nu vraag ik mij af, ik heb morgen ingesteld dat mijn auto op de goedkope uren gaat laden. Wat zal er dan in de praktijk gebeuren? Trekt mijn auto dan eerst de accu leeg die geladen is met stroom die duurder was dan dat de stroom morgenmiddag kost.

Is de software zo slim dat hij dat niet gaat doen, en als hij dat wel gaat doen kan ik dat op enige manier beïnvloeden?

[Taro]

R.K schreef op zaterdag 9 augustus 2025 @ 23:01:
Na 2 weken handmatige aanpassingen om NOM te krijgen heb ik vandaag mijn Everhome P1 aan mijn Solarflow 2400 gekoppeld. Tot nu toe draait het aardig NOM. Maar nu vraag ik mij af, ik heb morgen ingesteld dat mijn auto op de goedkope uren gaat laden. Wat zal er dan in de praktijk gebeuren? Trekt mijn auto dan eerst de accu leeg die geladen is met stroom die duurder was dan dat de stroom morgenmiddag kost.

Is de software zo slim dat hij dat niet gaat doen, en als hij dat wel gaat doen kan ik dat op enige manier beïnvloeden?

Met Home Assistant kan je dit zelf sturen en beïnvloeden. Met HEMS ben je afhankelijk van wat Zendure in de Zenki/HEMS AI mode heeft geprogrammeerd.

Je zit nu in het HA topic, dus dan kan je dit zelf sturen toch?

[R.K]

Taro schreef op zaterdag 9 augustus 2025 @ 23:48:
[...]

Met Home Assistant kan je dit zelf sturen en beïnvloeden. Met HEMS ben je afhankelijk van wat Zendure in de Zenki/HEMS AI mode heeft geprogrammeerd.

Je zit nu in het HA topic, dus dan kan je dit zelf sturen toch?

Sorry ik zit in het verkeerde forum

[pulsarz]

CopyCatz schreef op zaterdag 9 augustus 2025 @ 22:21:
[...]


Volgens mij werkt het zo dat de batterij normaal gezien communiceert met een mqtt server van zendure. Dat gaat op basis van een account. Je kunt de batterij ook laten communiceren met een eigen mqtt server (die van HA in feite). Blijkbaar is het nu zo dat er een "api key" is die de functie van inlog-account voor de mqtt overneemt omdat je er anders 2 moest hebben (1 voor app en 1 voor mqtt). Wat ik niet snap is:

- hoe de lokale api nu in dit geheel verwerkt is
- waarom de integratie nog steeds op basis van mqtt moet terwijl de api veel efficienter en robuuster is en er geen gedoe is met autorisaties met zendure accounts of "api keys".

Ik maak voorlopig wel gebruik van zelfgebouwde api calls.

Voor de SF800 reeks en de AC2400 heb je ook de optie om via ZenSDK te werken in de integratie. Deze mode moet je per device gaan instellen.

[Taro]

@FireSon Ik zie dat nu iemand anders dan jij 1.1.2 pre1 via Github beschikbaar maakt. Kunnen we jou nog steeds persoonlijk bijv. logs opsturen of vanaf nu liever alleen via Github zodat ook de andere developers het kunnen oppakken?

[Taro]

Upgrade naar 1.1.1 gedaan, Smart Discharging werkte niet meer, terug naar 1.1.0 en werkt weer. Ik wacht nog even af.

[mrme12345]

Taro schreef op zondag 10 augustus 2025 @ 17:34:
@FireSon Ik zie dat nu iemand anders dan jij 1.1.2 pre1 via Github beschikbaar maakt. Kunnen we jou nog steeds persoonlijk bijv. logs opsturen of vanaf nu liever alleen via Github zodat ook de andere developers het kunnen oppakken?

Ja ontvang nu al 5 mails van harrymyar met release 1.1.2 maar niet op hacs te vinden. Dus wacht wel even af.

[Aziraphale]

mrme12345 schreef op zondag 10 augustus 2025 @ 19:02:
[...]

Ja ontvang nu al 5 mails van harrymyar met release 1.1.2 maar niet op hacs te vinden. Dus wacht wel even af.

Bij redownload zie ik hem nu wel, maar twijfel of ik het moet doen...

[Taro]

1.1.0 werkt hier prima met 3x 2400AC, heb de Hyper nog steeds in HEMS omdat die via HA problemen bleef geven. Morgen worden de laatste 2x AB2000S opgehaald en dan heb ik 2 Hypers aan de zijlijn liggen die niet meer aangestuurd hoeven te worden. Valt er ook weer een stukje afhankelijkheid en gedoe weg. De 2400AC's draaien vooralsnog mooi stabiel met 1.1.0, dus upgraden doe ik pas weer als duidelijk is dat een nieuwe versie als stabiel wordt gezien.

[wosp]

1.1.1 en 1.1.2-pre2 doen hier helemaal niks op de 2400AC, in welke modus ik ze ook zet (behalve Standby dan, dat werkt prima )

Dus ook maar weer terug naar 1.1.0. Zie wel in de release informatie bij 1.1.1 staan dat de accu’s nu om de 0.5 kWh gaan schakelen. Maar schakelen zorgt elke keer voor een korte piek (actieve batterij gaat eerst naar 0 en dan pas start de nieuwe batterij), hoe vaker dat gebeurd hoe minder interessant wat mij betreft, zeker bij de wat grotere setups. Ik denk dus dat ik sowieso maar op 1.1.0 blijf totdat het een keuze is om de load door 1 device te laten afhandelen of altijd te laten verdelen over alle devices.

[pulsarz]

Ook op 1.1.0 blijf ik freezes krijgen op 1 hyper.
Grappige is dat het steeds bij de "oude" hyper is.

De 2e hyper is revisie 3.0 en die heeft sinds ik hem heb (2 weken geleden) nog geen enkele freeze gehad..

Master firmware is nochtans hetzelfde..

[mrme12345]

pulsarz schreef op zondag 10 augustus 2025 @ 22:00:
Ook op 1.1.0 blijf ik freezes krijgen op 1 hyper.
Grappige is dat het steeds bij de "oude" hyper is.

De 2e hyper is revisie 3.0 en die heeft sinds ik hem heb (2 weken geleden) nog geen enkele freeze gehad..

Master firmware is nochtans hetzelfde..

Ja ik ook al paar x op mijn hyper van januari 2025. En in de versies daarvoor geen last van gehad, heel vreemd. Maar hopelijk nu met de MQTT reset knop minder moeite om hem weer aan de gang te krijgen.

[martinvdm]

Taro schreef op zondag 10 augustus 2025 @ 20:31:
1.1.0 werkt hier prima met 3x 2400AC, heb de Hyper nog steeds in HEMS omdat die via HA problemen bleef geven. Morgen worden de laatste 2x AB2000S opgehaald en dan heb ik 2 Hypers aan de zijlijn liggen die niet meer aangestuurd hoeven te worden. Valt er ook weer een stukje afhankelijkheid en gedoe weg. De 2400AC's draaien vooralsnog mooi stabiel met 1.1.0, dus upgraden doe ik pas weer als duidelijk is dat een nieuwe versie als stabiel wordt gezien.

Stuur jij alles aan via fireson cloud integratie? Ik dacht dat jij volledig lokale zensdk had?

[Taro]

martinvdm schreef op zondag 10 augustus 2025 @ 22:11:
[...]

Stuur jij alles aan via fireson cloud integratie? Ik dacht dat jij volledig lokale zensdk had?

Ik gebruik de Fireson integratie met de 2400AC's ingesteld op ZenSDK, kan je per device instellen. En doe dan bijv. de min en max SoC via REST COMMAND's.

Op die manier hoef ik niet met eigen scripts, slimme stekkers per device, etc. aan de slag. De NOM-regeling van de Fireson integratie is episch

En dan pas ik daarnaast de Fake meter optie toe, dus Fireson's integratie staat altijd op Slimme Matching en ik manipuleer de "P1-meter" met een gestuurde waarde.

[gielz]

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

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


*2,5kwh sluipverbruik

[mrme12345]

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

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

[Afbeelding]
*2,5kwh sluipverbruik

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


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

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

[martinvdm]

Zou er dan nog meer redenen zijn om ZenSDK restapi te verkiezen boven de fireson integratie nu ook mqtt optie er is om eea lokaal af te handelen? Enige wat ik me kan bedenken is dat Fireson Bluetooth nodig heeft wat in sommige situaties een dingetje kan zijn.

[ Voor 3% gewijzigd door martinvdm op 10-08-2025 22:39 ]

[mrme12345]

Overigens werkte bij mij de combinatie van hyper, 2400ac en sf800 pro op zendure/fireson integratie ook niet optimaal. Ondanks dat ik die op handmatig vermogen had gezet begon die zich toch met mijn node red nom te bemoeien op de 2400ac/sf800 pro en vreemd gedrag te vertonen. Dus nu maar apart account voor de hyper en fireson en de 2400ac en sf800pro via apart zendure account op de zenSDK / restapi. En dat werkt voor mij beste.

[Taro]

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

Hier combinatie:

• Inderdaad Hyper (zojuist losgekoppeld en uit accounts verwijderd)
• Meerdere omvormers
• Niet hebben van een Energy Socket per omvormer
• Niet hebben (tijd & zin) van goed script voor verdelen load over meerdere omvormers

Nu de Hyper weg is zou ik een 3e HW Energy Socket kunnen kopen voor de 3e 2400AC en dan zonder Fireson integratie draaien en bijv. jouw en @wosp's scripts gebruiken. Wie weet... Maar vooralsnog werken de 2400AC's prima met Fireson 1.1.0 & ZenSDK.

[Devke]

Taro schreef op zondag 10 augustus 2025 @ 22:15:
[...]

Ik gebruik de Fireson integratie met de 2400AC's ingesteld op ZenSDK, kan je per device instellen. En doe dan bijv. de min en max SoC via REST COMMAND's.

Op die manier hoef ik niet met eigen scripts, slimme stekkers per device, etc. aan de slag. De NOM-regeling van de Fireson integratie is episch

En dan pas ik daarnaast de Fake meter optie toe, dus Fireson's integratie staat altijd op Slimme Matching en ik manipuleer de "P1-meter" met een gestuurde waarde.

Misschien even gemist maar jij stel andere SoC grenzen in dan 10-100%?

[Taro]

Devke schreef op maandag 11 augustus 2025 @ 07:53:
[...]

Misschien even gemist maar jij stel andere SoC grenzen in dan 10-100%?

Ja, heb een automatisering die ma t/m za 10-98% aanhoudt en deze op zondag om 00:05 naar 5-100% zet. In de ochtend wordt altijd tijdens de 2 duurste uren nog ontladen, dus iedere zondag - de dag met gemiddeld gezien de meeste uren met de laagste tarieven - vindt dan altijd de SoC kalibratie & balanceren plaats en wordt er van 5->100% geladen.

[TheAnT]

Ben sinds een paar dagen trotse eigenaar van de Zendure 2400 met 2 batterijen.

Nu zou ik die graag in home assistent krijgen.

Heb een p1 meter van smartgateways alsook de shelly pro 3em in men kast

Heb nu de zendure integratie van Fireson gedownload en nu moet ik daar een sensor invullen van de p1 meter...
"P1 sensor for smart matching*"
Welke sensor moet daar precies ingevuld worden?

[mrme12345]

TheAnT schreef op maandag 11 augustus 2025 @ 16:31:
Ben sinds een paar dagen trotse eigenaar van de Zendure 2400 met 2 batterijen.

Nu zou ik die graag in home assistent krijgen.

Heb een p1 meter van smartgateways alsook de shelly pro 3em in men kast

Heb nu de zendure integratie van Fireson gedownload en nu moet ik daar een sensor invullen van de p1 meter...
"P1 sensor for smart matching*"
Welke sensor moet daar precies ingevuld worden?

De P1 sensor die je in Home Assistant hebt zitten en data ontvangt, zoals een Homewizard, maar kan ook met de P1 van Zendure zelf in HA.

[TheAnT]

mrme12345 schreef op maandag 11 augustus 2025 @ 16:46:
[...]

De P1 sensor die je in Home Assistant hebt zitten en data ontvangt, zoals een Homewizard, maar kan ook met de P1 van Zendure zelf in HA.

heb een p1 sensor van smartgateways, gaat dit ook?

als ik manual volg vanop www.twoenter.nl moet ik een aparte sensor hiervoor aanmaken?

[mrme12345]

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


heb een p1 sensor van smartgateways, gaat dit ook?

als ik manual volg vanop www.twoenter.nl moet ik een aparte sensor hiervoor aanmaken?

Moet je even googelen of daar een HA integratie voor is. Die ken ik niet. En dan inderdaad sensor voor aanmaken.

1e hit
https://smartgateways.nl/...eter-with-home-assistant/

[ Voor 14% gewijzigd door mrme12345 op 11-08-2025 17:15 ]

[Taro]

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


heb een p1 sensor van smartgateways, gaat dit ook?

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

[Jnaaazer]

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



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


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

3e batterij is momenteel bijbesteld en onderweg

[CopyCatz]

Jnaaazer schreef op dinsdag 12 augustus 2025 @ 10:03:

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

3e batterij is momenteel bijbesteld en onderweg

Zo te zien heb je zonnepanelen, dus dan is het handiger om zoveel mogelijk surplus zonnestroom op te vangen in de batterij. De goedkope uren komen sowieso nu overeen met de zonne-uren, dus mijn 3 batterijen worden gewoon in de smart meter stand opgeladen. In de herfst/winter ga ik wel kijken naar laden in de goedkope uren.

[ Voor 3% gewijzigd door CopyCatz op 12-08-2025 10:28 ]

[Jnaaazer]

CopyCatz schreef op dinsdag 12 augustus 2025 @ 10:28:
[...]


Zo te zien heb je zonnepanelen, dus dan is het handiger om zoveel mogelijk surplus zonnestroom op te vangen in de batterij. De goedkope uren komen sowieso nu overeen met de zonne-uren, dus mijn 3 batterijen worden gewoon in de smart meter stand opgeladen. In de herfst/winter ga ik wel kijken naar laden in de goedkope uren.

Die integratie van gielz begint met laden rond 9/10 uur terwijl de prijzen rond 13:00 het laagst zijn (ook het meeste zon)

Je bedoel de smart meter stand van de zendure app?

[avdwerf]

Jnaaazer schreef op dinsdag 12 augustus 2025 @ 10:54:
[...]


Die integratie van gielz begint met laden rond 9/10 uur terwijl de prijzen rond 13:00 het laagst zijn (ook het meeste zon)

Je bedoel de smart meter stand van de zendure app?

Heb je aan de zonneopwek niet genoeg om de accu op een dag vol te krijgen?
Of gaat het je puur om het ontladen? Opladen zou dan namelijk niet uit moeten maken of de stroom goedkoop of duur is als je gewoon alles uit je panelen kunt halen.

[ Voor 17% gewijzigd door avdwerf op 12-08-2025 13:55 ]

[Jnaaazer]

avdwerf schreef op dinsdag 12 augustus 2025 @ 13:21:
[...]


Heb je aan de zonneopwek niet genoeg om de accu op een dag vol te krijgen?
Of gaat het je puur om het ontladen? Opladen zou dan namelijk niet uit moeten maken of de stroom goedkoop of duur is als je gewoon alles uit je panelen kunt halen.

Jawel meer dan genoeg dus dan is het toch slimmer om rond 13:00 de accu vol te gooien dan krijg ik het minst terug voor me zonnestroom want dat is de prijs laag bij dynamisch

[bert pit]

Jnaaazer schreef op dinsdag 12 augustus 2025 @ 10:03:
Ik heb nu sinds een aantal dagen de zendure-solarflow-2400-ac binnen en hij werkt goed.

[Afbeelding]

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

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

3e batterij is momenteel bijbesteld en onderweg

Het klopt inderdaad wat je zegt. Het meest economische, als je dynamische prijzen hebt, is je accu laden op de voordeligste uren en ontladen op de duurste. Met de TLV die je tot 2027 krijgt is dat de meest economische strategie. Met NOM laat je een paar tientjes liggen per maand in de zomer.
En het geeft je nog anderhalf jaar de tijd om de NOM te implementeren die vanaf 2027 het voordeligst wordt. Het makkelijkst is opladen om 12.00 uur en ontladen om 19.00 uur. dan zit je in 90% van de gevallen goed de afgelopen 4 maanden in elk geval. Soms kun je nog een stuiver extra verdienen door de laadtijd een uurtje aan te passen.
Al ik binnenkort tijd heb ga ik ook de cheapest hours startegie toepassen in HA.