P1 Meter firmware 6.0201 has been released as beta

[DCSBL]

Important

📣 6.0203 has been released to production!

New in P1 Meter 6.0200

• We have added a /api/batteries API in the v2 API, which allows you read information about the Plug-In Battery control system and set the control mode. With this you can automate how and when your batteries are active. Read more about this in the documentation.
• We have introduced a lot of changes to handle internal memory more efficient which should result in a more stable experience.

New in P1 Meter 6.0201

• When you have the mode set to to_full and all batteries are fully charged, the mode will now transition to standby instead of zero. This change allows the automation itself to choose what to do next. This only happens when you set the mode to to_full through the API. When you do this through the app, the mode will revert to zero.
• We’ve also made more improvements to memory-related code, which should further enhance the overall system stability.

New in P1 Meter 6.0203

6.0202 has not been released as beta

• We have solved some issues related to new connections not being accepted.
• The control logic for steering batteries has been tweaked to reduce fast switching between charging and discharging during low demand periods.

Feedback

Leave your feedback as a comment below this announcement during the beta period. We accept both English and Dutch.

[DCSBL]

Hello 👋!

I am going to start this discussion as we want to explain something important. We have added the option to change the mode of the battery group settings. I think this is a great step, as you can make cool things like "Delay charging until better moments" and "Stop the batteries when you charge your car", but we understand that this may not be enough for everybody.

Due to current and upcoming safety and grid regulations, we cannot easily add a 'set target' option. That’s why we’d love to hear what you actually want to achieve with the current modes, and what you'd like us to add, but most importantly, why and how you want to use those features.

A comment like "I want full control" doesn't help us much. But something like "I want to charge my battery only when my solar production exceeds X because my dynamic contract gives me low returns during the day" gives us clear insight.

So please let us know your real-life use cases and ideas, the more concrete, the better!

[Devke1972]

De PIB terugverdienen. Kan dit? Ik heb de PIB gekocht om eens ervaring op te gaan doen met een thuisbatterij. Wat is het? Wat kan het? Wat kan niet? Is dit wat bij ons past voor nu en in de toekomst? Vele vragen die ik mezelf stelde. Doel ons zo goed mogelijk voor te bereiden op het afschaffen van de salderingsregel. Ik had een variabel stroomcontract met een terugleverboete (TLB). Voordat ik een batterij aanschafte had ik al simulaties gedraaid een jaar lang in HA. Met een RTE van 80% kwam daaruit dat de Plug-in Battery (PIB) in mijn geval iedere cyclus geld zou gaan kosten. Ik kan me een cent of 6 per cyclus herinneren. Terugverdienen lag voor ons niet binnen handbereik. Dom gezegd, de TLB was te laag.

Wij zitten nu bijna 2 maanden op een dynamisch contract. Dat is een hele andere belevenis. Altijd op de goedkoopste uren verbruiken (wasjes, vaatwasser en natuurlijk de batterij laden) en op de duurste uren de batterij inzetten om zo inkoop van duurdere stroom te besparen. Toch is altijd de wens blijven bestaan om de batterij terug te verdienen. Binnen het tweakers topic zijn daar al heel veel discussies over geweest. De 1 doet het voor het milieu, de ander voor de fun en weer een ander voor het geld. Last but not least heb je ook genoeg mensen die een combi wensen. Een dynamisch contract is flexibeler. Dat vergt wel een iets andere kijk op de PIB maar maakt het er ook leuker op. Wat als je de PIB voor meer doelen kunt inzetten? De dynamische markt is groeiende. Steeds meer mensen stappen over en zijn al dat gezeur met boetes uitdelen wel beu. Ik zie voor de PIB daar kansen. Terug even naar terugverdienen. Wat hebben we daar toch mee als het gaat om thuisbatterijen? Ik denk dat het ingegeven wordt door zonnepanelen. We investeren om geld terug te verdienen. De panelen. Een laadpaal bij huis. We investeren om deze terug te verdienen. De PIB we investeren om deze terug te verdienen. Zodra het onze energievoorziening gaat lijkt dit heel erg bij mensen te leven. Als ik iemand spreek over de PIB dan is het ook altijd : "wanneer heb je hem terugverdiend?". Uhhh nu niet maar........ Ik wil kunnen zeggen : "Over x jaar". Eerlijk gezegd lukt dat mij niet in de contract vorm die ik had. Wellicht bij jullie wel. Andere voorwaardes.

Duco gaf in de openingspost al aan om zoveel mogelijk info te delen. Bij deze doe ik een extra bijdrage.

Ik geef een voorbeeld:

Ik heb in HA een aantal meters lopen. Deze meters samen combineren levert mij op wat de netto kosten van de batterij zijn. Een plus betekend dat de batterij tot nu toe geld heeft gekost een min betekend dat de batterij al zijn kosten zijn gedekt en dat er zelfs een winstje overblijft. Dat laatste is het doel. Terugverdientijd haalbaar maken en zo kort mogelijk. We zijn immers Hollanders.

Wat zie je in bovenstaande grafiek? De netto kosten van de batterij. Op 15 mei om net na 7 uur heeft de PIB vanaf het begin dat deze teller lopen zichzelf kostendekkend gemaakt en zit er zelfs een klein winstje op. Hoe komt dat? Eerlijk gezegd door vorige week zondag. Toen kreeg je geld toe bij iedere kWh die je verbruikte. Met die 46 cent winstje gaan we de dag van de 16e in. De batterij moet geladen worden. Dat kost stroom en dus geld waardoor je de winst langzaam weer ziet verdampen. Onderstaand zie je dat na het laden er nog 19 cent winst over is.

De kunst is dus nu om na het ontladen op een hogere winst uit te komen dan de 46 cent waar we gestart zijn. Is dat gelukt?

Nee net niet. Deze cyclus heeft een 1 ct van de winst afgesnoept, wat dus betekend dat deze cyclus niet kostendekkend was. Wat had ik nou kunnen doen als de mogelijkheid daartoe er was?

Terug leveren aan het net? Ja ik denk het wel. In de ochtend zijn de prijzen hoger en in de avond. De restcapaciteit had ik vanmorgen dus kunnen inzetten voor netondersteuning. Tarief hoog, dan moet er een tekort zijn. We ondersteunen het Net ook met opladen door de batterij op te laden met onze zonnestroom. Dynamisch of in een andere vorm. Dan was de batterij weer leeg aan de dag begonnen en had het wellicht gelukt de winst vast te houden of zelfs uit te bouwen. Een realistische terugverdientijd realiseren.

In onderstaande grafiek houd ik mijn laad en ontlaadkosten (NOM) bij. Je ziet dat het al aardig goed lukt om duurder te NOMMEN.

Dit plaatje geeft een weekoverzicht weer. Hoe verder ze uitelkaar komen te liggen des te beter.

Een laatse inkijkje in de tarieven van gister. Er moet dus wel een beetje spread zijn. Dit is nodig om het verlies van omvormen en de afschrijving van de batterij te kunnen dekken.

De kosten voor de afschrijving liggen vast. De omvormingsverliezen is een knop om aan te draaien. De restcapaciteit inzetten voor netondersteuning als de nieuwe dag begint is een knop om aan te draaien en een mogelijkheid om de terugverdientijd aan te pakken.
Daarmee denk ik dus dat de PIB nog interessanter gemaakt kan worden voor een groeiende doelgroep. Dynamische contract klanten. Ik zou dit heel graag testen met als doel, RTE omhoog en kunnen spreken over een terugverdientijd. Niks leuker om op die vraag wel een antwoord te kunnen geven :-)

Wellicht is er zelfs een teruggave van de BTW mogelijk door de belastingdienst dan. Ik houd hier wel even een slag om de arm. Dat zou ik moeten uitzoeken. Ik ken enkele voorwaarden. Dynamisch contract, factuur PIB op naam van degene die belasting terug gaat vragen en er moet een vorm zijn van terug leveren. Pin me er even niet helemaal op vast.

Edit : Voor de duidelijkheid.... het winstje is je start van de terugverdientijd.

Hopelijk een duidelijk verhaal, anders vraag gerust.

[Gielz1986]

Eigenlijk is het hier gewoon een kwestie van afkijken bij de concurrent (Zendure). Daar noemen ze modes Off (Standby), Manual power (niet bestaand bij HW) en Smart matching (Zero).

Als Homewizard een mode "Manueel" toevoegd en target_power_w een write optie geeft ben je er al deels. Vervolgens max_consumption_w en max_production_w een write optie geven en je kunt vervolgens alles zo via de api bouwen als je zelf wilt;

• Wil je niet dat ze gaan ontladen op dit moment? Write max_production_w naar 0
• Wil je niet dat ze gaan opladen op dit moment? Write max_consumption_w naar 0
• Staat de mode op Manueel, dan bepaal jij zelf target_power_w via de API.
• Wil je een hogere RTE? Write max_consumption_w naar een lagere waarde dan 800 watt om op een optimaal vermogen te laden

[Mausy5043]

Wil je een hogere RTE? Write max_consumption_w naar een lagere waarde dan 800 watt om op een optimaal vermogen te laden...

Ik vind dit toch een bijzondere uitspraak. In discussies over EV batterijen wordt vaak geopperd dat laadverliezen lager worden naarmate je met een hoger vermogen op AC kunt laden (DC is weer een ander verhaal). M.i. is RTE het resultaat van die laadverliezen. Dus hoe kun je nu dan stellen dat een lager vermogen tot een hogere RTE gaat leiden?

om op een optimaal vermogen te laden...

EN als een lager vermogen inderdaad leidt tot een betere RTE wat is dan dat optimale vermogen waar jij het over hebt?

[DCSBL]

Let er op dat we hier niet te veel afdwalen van het “beta” en “firmware” onderwerp 😉. Dit voelt alsof dit thuishoort op Tweakers.

[Devke1972]

Een update m.b.t. de PIB en dynamische tarieven. In een eerder verzoek van @DCSBL een situatie beschreven m.b.t. de PIB en dynamische tarieven. Zelf de wens uitgesproken een TVT te kunnen koppelen aan de batterij. Ik draai nu 27 cycli met tellers binnen HA om te kunnen kijken of de PIB terug te verdienen is.

Kort Resumé: In mijn variabel contract kostte de PIB mij 6 ct per cyclus. Inclusief afschrijving en de huidige RTE.

Op het moment van schrijven heb ik dat terug kunnen dringen naar 2 ct per cyclus. Ik heb de afgelopen periode 27 cycli gedraaid en geladen op de goedkoopste uren. De duurdere uren proberen te gebruiken om NOM te draaien. Soms leverden de panelen op de duurdere uren nog terug aan het net, dus dan geen inzet van de PIB.

Onderstaand 2 afbeeldingen. De 1e laat zien waar ik begonnen ben (vorige x gestopt ben, zie vorige post). De 2e afbeelding waar we nu staan. De min is omgezet in een plus. Van een winstje van 43 ct naar kosten van 13 cent.

Is het mogelijk om weer onder de streep te komen? In 2 situaties. De 1e is als de prijzen zo negatief zijn dat er geld betaald wordt aan mensen met een dynamisch contract. Dit pas 1x meegemaakt in voorbije 2 maanden. De 2e situatie is als er verbetering in laad en ontlaad efficiency aan te brengen is. De RTE. Ook een veel besproken onderwerp op tweakers. Gaat het binnenkort mogelijk worden deze zelf aan te sturen? Kijken of de positieve draai van dynamisch tov variabel/vast en TLB een voortzetting krijgt? Ik zie naast efficiënter laden en ontladen nog een mogelijkheid. Het overschot die achter blijft in de PIB dynamisch te verkopen op het moment dat het net er het meest om vraagt. Dure uren.

De volledig open API zijn in het p1 intercept topic al eens bevestigd, daar er tweakers waren/zijn die de p1 meter "voor de gek" willen houden om e.a. te bewerkstelligen en dit zeer afgeraden werd.

Hopelijk zien we dit in de beta terug nog om het onderzoek weer een stap verder te brengen.

[mireckv]

Installed! although i'm only using the ZERO option. Does the memory management improvements have any impact on how many connections with batteries are stable? I hear a lot about maximum 4 connections (4 batteries or 3 batteries and for example 1 HA intergration) ?

[Devke1972]

Oke. Thnx. It's working here also. I am made little mistakes in my configuration. Stupid one's 🙈

[DCSBL]

Maybe you can share the important mistakes so we can all learn from them? 🫣 I just got a mention that I had a syntax error in the “zero” action as well 🤦‍♂️

[Devke1972]

Sure no problem. The first thing is better read the documentation. Sometimes i got overexcited and misses than important information. The IP adress must be filled in in the configuration.yaml. I filled in the IP off the battery. The P1 is talking to the battery.

I had an bearer code in the configuration.yaml. i copied it into the syntax you gave. It was the wrong code. Again battery and not the p1.

So my conclusion is to carefull read.

Great Job and compliments to Homewizard. I am glad the first steps are taken and i can make my house more automated with energystorage and prepairing for 2027. My further suggestions are allready reported.

[DCSBL]

Great that you figured that out 💪! This also could mean the documentation is not clear enough.

One other thing, I've just had a situation where the standby mode automatically restored to zero which should not happen. We have to investigate this.

[Devke1972]

Okey. Clear. You know what was the cause? Logfiles? Maybe we can create the same situation here to see if it here also happens in another setting. Standby works today fine. I just used the modus "to_full". Within a very short time the battery got into charging mode.

[vanelsberg]

Still waiting for delivery of my first battery. So not much handson experience but have been looking at energy/solar statistics for the past 4 years and do some experimenting with battery sim.

If the system performs as expected I plan to add an extra battery shortly after. The second battery will initially be restricted to 800W (dis)charging due to home restrictions My config then will look as follows:
(A) 1 x HomeWizard Battery (dis)charging at 2000W
(B) 1 x HomeWizard Battery (dis)charging at 800W

Because charging too full at 800W will take considerably longer. I think the system could benefit from giving priority on charging the 800W battery when solar production is positive - trying to get the 800W fully charged as soon as possible.

Example, when my solar system is producing 1500W
(A) Charges slowly at 800W
(B) Charges slowly at 700W until batter (A) is fully charged, then switches (b) to 1500W fast charging

Unless HomeWizard Battery's logic itself is smart enough to handle this (?) would much help if API could be used to do this kind of prioritizing?

[DCSBL]

Thanks! First of all, to prevent any further confusion:

(A) 1 x HomeWizard Battery (dis)charging at 2000W

The HomeWizard Plug-In Battery is only capable of charging and discharging at 800W. You can combine multiple units to increase capacity. For example, a setup of 4 batteries can charge up to 3200W and discharge up to 800W as a group. You can disable the 800W discharge safety limit if you know what you're doing with your electrical installation, allowing up to 3200W discharge.

We do not (yet) support multiple battery groups. All (up to 4) batteries will act as one.

That said, the P1 Meter includes a control system to manage charging and discharging as efficiently as possible. It prioritizes charging to store as much solar energy as possible. There are too many details to cover here, but if you have your battery or batteries, please review your setup to see if any changes could improve your situation. We can always explore adjusting the control system or offering customization options.

[vanelsberg]

Clear, Thanks!
Didn't realize. I'm just starting / newbe on the product specs but learning fast ;-)

[shthpnz]

@DCSBL hier nog geen 6.0200 mogen ontvangen, ofschoon ik wel aangesloten ben bij de bètatestgroep.

[DCSBL]

Wil je voor de zekerheid deze nog een keer invullen? https://github.com/homewizard/beta?tab=readme-ov-file#product-firmware

[shthpnz]

Ingevuld, dank👍

[DCSBL]

Als het goed is is hij nu beschikbaar voor je.

[shthpnz]

Aangekomen, dank👍

[shthpnz]

@DCSBL: na dik 50 uur met de nieuwe versie kan ik melden dat de P1-meter afscheid genomen heeft van zijn zwervend bestaan langs onvermoede access points. De 4 PiB’s blijven dus goed aangestuurd. Erg fijn!

[Gielz1986]

Bedankt voor de update wat ik graag zou willen zien is dat max_consumption_w en production instelbaar is via een write option. Hierdoor kunnen wij gaan testen of het iets langzamer opladen ontladen tot een betere RTE kan leiden. Maar voor nu al een prima update ondanks dat ik (nog) geen beta tester ben! Je zou nu al met standby, zero en opladen mooie automations maken.

[Gielz1986]

Op dit moment kan ik niets bedenken buiten de RTE. Dit zou ook alleen een vinkje kunnen worden waarbij hij voor de maximale rte gaat en niet voor 800 watt laden en ontladen. Zelf weet ik ook niet of dit effect heeft als je bijvoorbeeld een cap zet op 700 watt laden. Dit heeft bij sessy iig wel effect en hier verwacht ik het eigenlijk ook.

Welllicht eens een langere beta met deze write opties? Dan kan ik en devke dit volledig tot in den treuren testen.

@Devke1972 heb jij nog ideeen?
@DCSBL ik heb trouwens het beta formulier inmiddels ingevoerd voor 2 batterijen en de p1.

[Devke1972]

Ik heb deze optie.... zoeken naar een betere RTE met als doel minder stroom te verliezen ook benoemd. Dan kijken hoe dit past in mijn situatie. De andere optie rondom dynamische tarieven heb ik onder de openingspost van @DCSBL geplaatst.

P.s. hopelijk zijn mijn opmerkingen goed leesbaar. Ik zie dat na plaatsen er soms wat woorden vervangen worden.

[Hassio02023]

Ik denk manueel laad/ontlaad schema's kunnen instellen zou al heel fijn zijn voor veel mensen i.c.m. vrijheid van vermogen bij het schema.

Tevens XOM zou welkom zijn of NOM + X waarde om vaak overschakelen te voorkomen.

[Devke1972]

Ik zou me nog een modus kunnen bedenken. Discharge only. Ik denk dat dit nu ook wel te bouwen is in HA met deze set aan modi. Dynamische toepassing. 1 maal geladen goedkoop mag de batterij nog alleen maar helpen bij ontladen.

[Devke1972]

Nog een modus ipv geen modus

[Gielz1986]

@DCSBL Hierbij de eerste feedback. Vanavond ga ik even door met testen.

• https://gist.github.com/DCSBL/c005a865a02491ae814932627c5a218a Bij de rest_commands onderdelen mist Bearer na authorization:
• Standby mode geef een foutmelding in de app. Logisch de app is productie maar wellicht wel goed om te weten;
  
• target_power_w is mij een beetje onduidelijk wat is deze waarde precies?
  

[Devke1972]

Ik doe mee met een gokje. Op welk vermogen wil je laden / ontladen 😜🙈

[Hassio02023]

Ik moet er nog even induiken. Maar ik verwacht dat native support vanuit de community niet heel lang gaat duren.

[DCSBL]

native support vanuit de community

Sorry, native support voor..?

[Hassio02023]

In Homeassistant voor het veranderen van Zero naar Standby en terug.

[Gielz1986]

Moest weer even andersom denken dus bij die target_power_w. staat er een + watt dan wil hij gaan laden dit is ook ingevuld als de batterij op idle staat omdat hij vol is. Wanneer het een - watt is dan moet hij dit gaan leveren dit kan ook vele malen hoger zijn wat hij maximaal aan kan.

Helemaal duidelijk niets meer aan doen. ;)

[Gielz1986]

Hier zal vannacht de eerste API test via 1 automatisering draaien maar ik verwacht aan de API kant eerlijk gezegd 0 problemen. Wat nu wel duidelijk word is dat je de max_production_w write optie eigenlijk mist. Als je wilt gaan uitstellen bij zonsopkomst en je hebt een vrij hoge SOC wil je nog wel een tijdje ontladen maar dat kan niet via standby. Je zou dus de max_production_w naar 0 willen zetten en zodra wenselijk op xxxx watt willen zetten als de zonnepanelen liggen te bakken.

Onderstaande is een leuke tussen optie iig;

• Naar standby bij een SOC van onder de 5% na zonsondergang en voor zonsopkomst
• Vervolgens naar zero na zonsopkomst en er -700 watt via de P1 gaat. Mocht dit 2 uur na zonsopkomst niet het geval zijn gaat hij alsnog naar zero.

[Gielz1986]

API heeft goed gewerkt zonder errors, weergave app of terugschakeling. Ook nu zie je weer de beperking van alleen mode write. Je wilt het opladen uitstellen om te voorkomen dat hij niet alle opbrengst gaat hamsteren in zeer lage watt waardes in de ochtend. Maar je wilt wel nog lekker door ontladen want dat is anders zonde. Voor nu maakt het hier niet zo uit, ik mis dan 0,150kwh ontlading. 6:00 zon op, 7:00 al 700 watt van het dak. Maar dat is natuurlijk alleen als het helder is.

Dit zou dus te behalen zijn met een write actie op max_production_w en max_consumption_w. Je write dan in de nacht de juiste waarde van 800 naar 0 en zet deze weer om naar 800 zodra je wilt in de ochtend afhankelijk van de P1 of iets anders. Dit is 1 van de meerdere pluspunten om daar een write actie op te zetten.

@DCSBL deze write acties in de api, is dit iets voor een (mogelijke) latere beta of kan dit ook nog meegenomen in deze test cyclus?

*waarde zijn anders, door vertraging en opmaak

[DCSBL]

We weten nog niet of we het instellen van max production en max consumption meenemen in deze beta.

[Devke1972]

Dank voor de terugkoppeling. Ik denk dat de wens groot is maar dat zal je niet ontgaan zijn. Wel tof dat er over nagedacht wordt. Ook goed om te zien dat de mogelijkheid al wel in de API zit. 😊👌

[Devke1972]

Een reactie m.b.t. mijn ervaringen. Ik heb even een paar buttons aangemaakt in HA om te kijken of de acties naar de batterijen werken. Automatisering maken volgt. Als ik de batterij op standby zet middels de button dan blijft de boel mooi in rust, behalve de 6 a 9 watt standby verbruik. Was gisteren even naar 0 gezakt maar komt toch op. Al was dit voor deze beta continue 6 a 9 watt. De button om direct te gaan laden activeert de batterij direct. Ik heb hem vol geladen en gekeken of de NOM automatisch wordt opgepakt. Dit gaat goed.

Waar ik denk ik tegen aan ga lopen is na volledig opladen dat NOM leuk is maar niet als de batterij aan het ontladen is geweest en dan bij een duurdere stroomprijs door NOM weer gaat inkopen (laden). Je zou dan naar een discarge_only situatie moeten springen (bij dynamische contracten als voorbeeld). Bij vraag uit de woning springt de batterij bij maar mag niet duur inkopen.

Eigenlijk is dit dus een wens op basis van de mogelijkheden die nu ontstaan. Een batterij met restcapaciteit zou evt ook nog tegen een hogere nettarief ontladen mogen worden. Het is mij even niet duidelijk of dat zou kunnen met de optie die @Gielz1986 net beschrijft.

[Gielz1986]

Zeker, mijn verwachting is dat als je een write actie kunt uitvoeren op max_production_w en max_consumption_w je hiermee hem als het waren gaat knijpen bij laden en ontladen. Je geeft dan bijvoorbeeld aan maximaal mogen ontladen met 0 watt etc etc. Of in mijn geval maximaal laden met 0 watt totdat ik vind dat er genoeg opwek is.

Groot voordeel daarvan is ook dat je kunt gaan kijken wat de RTE verbetering is met bijvoorbeeld 90% van vermogen laden zoals bij de sessy al als grafiek aangetoond is wat de verschillen zijn.

---

Langzamer laden (bij een lager vermogen) kan de batterij iets minder belasten, waardoor de interne weerstand minder invloed heeft en er minder warmte wordt geproduceerd.

[Devke1972]

Dat zou dus mooi zijn om eventueel mee te nemen in de beta. Benieuwd hoe @DCSBL hierin zit. Ik denk dat de velden er niet zijn om sws niets mee te doen. Dus ik verwacht dat hier best al over nagedacht is door HW. Met betrekking tot wat ik eerder beschreef... de discharge_only functie. Misschien iets meer toelichting. Deze functie beschrijft zich beter met discharge_only_NOM_mode. Na het opladen van de batterij zou je dus kunnen zeggen dat de batterij alleen maar mag ontladen als de woning stroom nodig heeft en de panelen niet genoeg opwekken. Is er wel weer voldoende opwek dan gaat hij in deze stand eigenlijk niks doen. Niet laden. De gewone NOM mode dus maar het laden eruit gelaten.

[DCSBL]

We zijn aan het onderzoeken of en hoe we deze functie gaan implementeren, uiteraard zitten aan deze 'simpele' functie weer afhankelijkheden die dit lastig maakt. Maar we zijn er mee bezig!

[jtebbens]

Begrijp ik hier uit dat wellicht deze JSON payload nog kan veranderen?

{
"mode": "zero",
"power_w": -404,
"target_power_w": -400,
"max_consumption_w": 1600,
"max_production_w": 800
}

Zit al te grasduinen in de P1 (apiv2) Homey code om de get/set status verwerken en concentreer mij nu allen op de mode:zero/stable/to_full aangezien de andere zaken (voor nu) geen meerwaarde bieden.

[rvangeijtenbeek]

I don't have HA or Homey and I don't plan to get one of those for now. But using Postman I could use the new (and the old) API. I've succesfully changed the battery mode in all directions. I have to be on the local network for this, so it's not a solution for handling the battery when I'm away from home.

If anyone wants to try, here's the Postman collection I made for this:
Homewizard P1-edited.postman_collection.json
You'll have to create your own local user & token of course, using the first POST request. Send once - get error - click button on P1 - send again - get token - save the token in an environment variable named token.

Would be nice to get an update soon of the Energy app, so I can actually use the app to change from 'standby' mode to one of the two modes offered in the app.

[johnvanderster]

Gisteren e.e.a. in HA opgenomen v.w.b. de sensors. Het viel me op, dat o.a. de mode status maar met tussenpozen beschikbaar was.

Vanochtend nog even gekeken naar de batterij grafiek (zie foto's) en het ontladen van de 2 batterijen in de nacht was erg onregelmatig, normaliter veel regelmatiger (zie foto's). @DCSBL Kan dat te maken hebben met de HA integratie?

Zo net hadden de batterijen de verbinding met de P1 meter verloren, ik heb in HA de sensoren er even uitgehaald en de batterijen via de app opnieuw verbinding laten maken. Bij 1tje gelukt, de andere heb ik even moeten uitzetten. Beide nu weer aan de slag.

[Devke1972]

Automatisering gemaakt voor laden van de batterij. Dat ging vanmiddag dynamisch goed. Morgen nog een x testen. Na het laden gaat de batterij de NOM stand in. Voor dynamisch is dat net niet handig. Opgeladen op goedkope stroom. Als de batterij wat ontlaad 2 uur later bijvoorbeeld dan zal hij daarna bij voldoende opwek weer wat bij laden. Laat dan net de prijs hoger zijn. Een discharge only NOM zou dan beter passen. Niet meer laden die dag. Ik moet even uitvogelen of dat kan op de manier zoals er nu write mogelijkheden zijn.

[Devke1972]

Aanvulling: Zojuist was de zon hier weg. Woning vraag 200 Watt. De batterij komt in. Tarief 25 ct / kWh. Batterij is vanmiddag geladen rond de 14 ct / kWh. Na een tijdje komt de zon terug. Ruim 600 Watt teruglevering. Batterij wil dus gaan laden tegen die 25 ct. Handmatig even tegen gehouden. Nu lever ik liever terug aan het net. Misschien een leuke usercase dit.

[johnvanderster]

wat vreemd, jou zou even een ping kunnen laten lopen om te kijken of de P1 gewoon wegvalt. Wat hier wellicht wel anders is is dat ik in HA heel veel sensoren van HW uit heb staan die ik toch niet gebruik (less is more). Daar buiten zou je battery group mode rest_command weg kunnen laten om te kijken of het daar niet gewoon fout gaat ergens in de communicatie. Niet echt wenselijk maar om dingen uit te sluiten.

Ping laten lopen, alleen bij opnieuw inladen sensor en configuration bestanden even de verbinding weg. Na toevoegen van de sensoren en de commands, of, na meerdere keren een curl command gegeven te hebben verloren de batterijen hun verbinding. Mee gestopt, reconnect en weer oké.

Overigens, via curl commando krijg ik wel de info maar bij put opdrachten een fout mbt de json. Ben er nog niet achter waarom, al veel geprobeerd, met en zonder quotes etc.
curl https://192.168.1.22/api/batteries --insecure -H "Authorization: Bearer A********" -H "X-Api-Version: 2" -->
{"mode":"zero","power_w":1478.557,"max_consumption_w":1600,"max_production_w":800,"target_power_w":1406}

curl https://192.168.1.22/api/batteries --insecure -X PUT -H "Authorization: Bearer A*********" -H "X-Api-Version: 2" -d '{"mode": "zero"}' --> {"error":"json:invalid-json"}

[Gielz1986]

@johnvanderster hij moet zo, token is niet mijn juiste token. Je kunt 1 van deze 2 codes gewoon in CMD plakken

curl -X PUT https://192.168.0.192/api/batteries --insecure ^
-H "Authorization: Bearer 1603CDD193DE32083BEF578E503A8" ^
-H "X-Api-Version: 2" ^
-H "Content-Type: application/json" ^
-d "{""mode"": ""standby""}"

curl -X PUT https://192.168.0.192/api/batteries --insecure ^
-H "Authorization: Bearer 1603CDD193DE32083BEF578E503A8" ^
-H "X-Api-Version: 2" ^
-H "Content-Type: application/json" ^
-d "{""mode"": ""zero""}"

[johnvanderster]

Dank, het werkt. Eerst weer dezelfde error, na overschakelen naar cmd ipv power shell wel oké.

[Devke1972]

@DCSBL wederom dezelfde foutmelding als gisteren mbt p1 meter. Handmatige reset nodig. Vanmorgen de batterij vanuit de NOM stand naar standby gezet.

[DCSBL]

Ik kan het even niet terugvinden, maar welke "dezelfde foutmelding als gisteren" 🤔?

[ReneVanDeVen]

Ik krijg nu via de websocket (/api/ws) een bericht binnen dat helemaal niet beschreven staat (https://api-documentation.homewizard.com/docs/v2/websocket), namelijk:
{"type":"batteries","data":{"mode":"zero","power_w":0,"max_consumption_w":800,"max_production_w":800,"target_power_w":-253}}

Ik ben subscribed op alles (*)

Ik heb ook helemaal geen batterijen.

[DCSBL]

Bedankt voor de melding! Dit zou op zich geen kwaad kunnen maar het is wel 'zonde' van de resources. We nemen dit mee!

Wat zou je verwachten te ontvangen als je geen batterijen hebt?

[ReneVanDeVen]

Ik had helemaal geen bericht verwacht. Er komt nu ook maar 1 bericht, terwijl via het /api/batteries endpoint wel steeds een andere waarde te zien is. Dat is nu dus niet consistent.
Misschien als je het /api/batteries endpoint aanroept dat je ook een andere json of responsecode wilt teruggeven indien je geen batterijen hebt.

[ReneVanDeVen]

De measurements van alle submeters had ik ook in apart bericht verwacht, dit is logischer, het is gewoon een andere meting. Meter type 'gas_meter' hoeft zeker niet elke seconde binnen te komen want wordt toch maar per 5 minuten geupdate. Onnodig om deze elke keer mee te sturen.

[kvanbiesen]

@DCSBL

Firmware 6.02 werkt niet met Sagecom XS212. (5.1902 ook niet trouwens).
Getest met 3 verschillende meters HWP1 meters. Allemaal met voeding, aangesloten op HWP1 poort om te testen)

Iemand anders met oudere XS212 -> Geen probleem. Mijne gaat niet. Uitlezen met zelfbouw P1 meter zie ik toch paar verschillen.

Werkend  (via HW P1)                           |        Niet werkende meter (via zelfbouw P1)
Datum op meter 10/2024                     |        Datum op meter = 15/2024
SMR versie : 50                                     |        SMR: 50221
DSMR ID: Fluvius 253972606_B            |       FLU5\253972606_G

[DCSBL]

Wat 'werkt niet'? Krijg je een foutmelding of iets wat je niet verwacht?

[kvanbiesen]

Geen leesbare P1 data. Ondertussen al 4e HW P1 RJ21 die ik van HW krijg. Altijd zelfde, rode ring die blijft branden. (Ook zonder splitter en

P1 thermostaat en P1 esp32 reader werken zonder problemen.

[DCSBL]

Duidelijk. Dit probleem is niet gerelateerd aan de software of deze beta. Wil je hiervoor (nogmaals) contact opnemen met de helpdesk en duidelijk aangeven welke stappen je tot nu toe hebt vernomen? Helaas komen problemen niet altijd bij de zelfde collega's terecht waardoor zaken langs elkaar heen kunnen lopen.

[kvanbiesen]

Opgelost, volgens helpdesk foute Batch in laatste levering bij productie. Dus never mind mijn opmerking.

[kegge13]

Zojuist mijn PiB uitgepakt en aangesloten. De P1-meter deed daarna een update naar v6.0112. Helaas heeft de PiB zichzelf uitgeschakeld vanwege "Water in de behuizing. Neem contact op." Het is mij ook niet duidelijk of ik nu in het beta-programma zit.

[DCSBL]

Hiervoor kan je het best contact opnemen met de helpdesk op https://helpdesk.homewizard.com/nl/

[JvHummel]

Running 6.0201 on my P1 here. Using 4 batteries and the Home Assistant integration made it impossible to even request a token. It kept giving me the "connection reset by peer" error. I then disabled the P1's cloud connection which was apparently just enough to get my token and then read the sensors. However this constant API connection for the sensors stops me from sending commands to the P1. So since my priority right now is to send commands to the P1, I've removed the sensors from the example YAML.

So in short, I now have:

• 4 Batteries
• Home-assistant integration connection
• Cloud disabled

And the ability to send commands seems to now work.

[Devke1972]

Ook ik draai deze versie. Ik zag vanmiddag ook dat de automatisering om de batterij te laden niet startte. Connectiefout ook met de p1. Na de p1 meter even van de stroom gehaald te hebben kon ik laden. Ik dacht even dat dit aan mij lag. Sinds gister is er een nieuwe meterkast geïnstalleerd en is de p1 meter door de electriciën netjes opgehangen. Ik had deze middels een HW splitter voorheen op de unit van de stadsverwarming liggen (ondergrond wordt niet warm). Voor nu werkt het weer. Als dit morgen weer het probleem is ga ik eerst de p1 meter weer op zijn oude positie terug leggen.

[JvHummel]

Ik kan nu wel met zekerheid zeggen dat het goed werkt zo. Zoals hier al eerder aan is gegeven, mis ik i.c.m. dynamisch tarief de optie om één richting op NoM te draaien, dus uitsluitend laden of uitsluitend ontladen van de batterijen. Zeker op dit soort grijze dagen waar de prijzen toch laag zijn, merk je dat een volledige NoM niet ideaal is. Accu ontlaadt veel maar dat is zonde.

[Devke1972]

De automatisering is net weer gestart m.b.t. het laden op de goedkoopste uren. Geen foutmeldingen rondom de p1. Niets veranderd aan de setting t.o.v. gister. Ik houd het op een 1 malige misser.

Uitsluitend laden kan. De optie "to_full" gebruiken. De vorm van ontladen die je aangeeft kan niet direct. Je zou willen dat je nadat de batterij vol is er alleen ontladen kan worden. Komt de zon weer door dan niets doen. Is er een tekort dan weer ontladen. Een discharge only NOM. Ik had hem al eens genoemd.

Een stapje verder zou zijn om dat alleen te doen bijvoorbeeld vanaf x Watt of op X Watt. Zowel laden als ontladen om een meer efficient systeem te hebben (RTE). Ook bij dynamisch zie ik dat spread belangrijk is maar (nog) niet voldoende. RTE verbetering zou kunnen helpen. Dan doel ik meer op een TVT.

[johnvanderster]

uurtje gelden ook de laadsessie van de 2 batterijen via HA (nog even handmatig) gestart tbv goedkopere stroom. Tijdelijk daarvoor even op pauze t.b.v. laden auto. Werkt weer oké. Ik heb afgelopen week de integratie en acties uitgezet in HA, geen verbindingsproblemen gezien. Nu weer aangezet, dus kijken wat er gebeurt. Ik ga morgen de P1 meter weer connecten met Homey en daar aan de slag met testen beta versie Homewizard.

[johnvanderster]

Edit: nieuwe verise 3.6.32 Homewizard in Homey getest, flows met aanpassingen van de 3 modes werken zo te zien. Ik ga nog verder testen. Ook een goede check mbt capaciteit connecties op de P1. Al 1x melding geen connectie mogelijk maar eea draait nu nog op volledig opladen.

[kegge13]

On my Fibaro HC2 the https call fails, it seems that the option "checkCertificate = false", which should be the curl equivalent of "--insecure" does not work. This was also reported by other users. It did change something however: the "success" response was "user:unauthorized". The equivalent curl works fine however. In the long run I will probably replace the HC2 with something else, but for now: is it possible to ask for a "less secure" interface for the P1/PiB?

[Lupindakaas]

Hey, @kegge13. Has this issue been resolved?

[kegge13]

@Lupindakaas
Helaas is dat nog niet opgelost. Ik heb zojuist een medewerker van Fibaro een bericht gestuurd.
Inmiddels heb ik de accu nu 22 dagen in gebruik. Een eerste evaluatie.

Dankzij de logging (met de v1-api) van de P1 (en de panelen) heb ik nu al ruim twee jaar dagelijkse data. Daaruit bereken ik het percentage van de zonnestroom die ik zelf benut en het percentage van mijn stroombehoefte dat ik kan afdekken met de panelen zonder accu. Als ik dat plot als functie van het dagnummer krijg je bovenstaande curves. Het benuttingspercentage (blauw) is ruim 20% in de zomer en tegen de 100% in de winter. De behoefte-afdekking is 50% in de zomer en 10% in de winter.
Nu, vroeg in de zomer, met de accu gedurende 22 dagen is het benuttingspercentage 50%-60% en de behoefte-afdekking rond de 90%.
Dat ziet er dus mooi uit.
De RTE (Round Trip Efficiency) is een zware tegenvaller: 70%. Ik had véél meer verwacht. Gemiddeld heb ik dagelijks 1.7 kWh uit de accu gehaald, waarbij deze enkele keren helemaal leeg ging. Ten opzichte van de capaciteit is dat passend. Een tweede lijkt mij niet nodig.
Hoewel de RTE dus een teleurstelling is, kan ik wel mijn terugleverboete verlagen door minder terug te leveren. Dat is nog een poos afwachten hoe dat uitpakt. Maar met die lage RTE zie ik niet in wat "handelen met dynamische tarieven" zou kunnen opleveren.
In de periode november-januari leveren mijn panelen minder dan 2 kWh/d die ik ook zonder accu grotendeels zelf kan benutten. De verliezen (opladen en management) in de accu leveren dan alleen maar een negatief resultaat op. Dus ik wil de accu komende winter in winterslaap-modus zetten. Dat zou ik nu moeten doen met een curl commando om naar 50% te laden en vervolgens de accu fysiek uit te schakelen. Het liefst zou ik die optie in de app zien verschijnen. Waarvoor alvast mijn dank.

[Lupindakaas]

Dank voor de doordachte review! In de maanden met weinig zon hebben thuisaccu's soms weinig te doen inderdaad. Om de onze accu op te laden voor langdurige opslag heeft de app al een functie ingebouwd. Als je op het scherm van de desbetreffende accu op de drie puntjes bovenin drukt verschijnen er een aantal knoppen. Een hiervan is 'Opladen voor opslag (60%)'. Deze zal de accu zoals verwacht tot 60% opladen (ideale laadpercentage voor langdurige opslag) en hierna uitschakelen. Je kan de accu nu veilig langdurig afschakelen van het net.

[kegge13]

Hier nog wat extra waarnemingen van dagen dat de accu ingeschakeld is.

De blauwe punten geven de opbrengst van de panelen als functie van de levering aan het net (in kWh). Bij een opbrengst van 4 kWh wordt niets meer geleverd en pakweg 1.5 kWh direct in huis geconsumeerd. De accu pakt de resterende 2.5 kWh op en levert iets minder dan 2 kWh verspreid over het etmaal. Mijn voorlopige conclusie hieruit is dat de accu in elk geval zeker uitgeschakeld moet worden in de periode dat de verwachte opbrengst van de panelen 2 kWh of minder is. Dat is voor mij november-januari maar mogelijk zelfs een ruimere periode.

[vanelsberg]

Ik kan je berekeningen en/of redenatie niet helemaal volgen?
In mijn geval (gebaseerd op de cijfers van de afgelopen 5 jaar) wordt er ook in de wintermaanden terug geleverd aan het net, al is dat minimaal. Zeker wanneer ik niet thuis ben en dus mijn verbruik overdag laag is. Zodra de saldering stopt is wat mij betreft elke kWh die niet wordt terug geleverd winst (zelf met inachtneming van de efficiëntie)?

(Denk ook niet dat de levensduur van de batterij merkbaar toeneemt door deze in de winter uit te schakelen?)

[ErikTbk]

Goedemorgen allen,

Ik zou heel graag beta firmware willen gaan draaien op de homewizard P1 en PiB. Ik heb hier al tweemaal het formulier ingevuld, maar nu bijna een week verder heb ik nog geen reactie. Hebben jullie nog ideeën? Wil graag de nieuwe functies van de pib gaan toepassen.

[eovermeer]

Zover ik heb begrepen worden de formulieren eenmaal per maand verwerkt, even geduld dus.

[ErikTbk]

Dank voor je antwoord. We wachten af.

[crryp]

Goedemorgen,

Ik en of mijn vader zijn beide geen beta testers, echter heeft mijn pa sinds afgelopen week 4 accu's waar hij er voorheen 2 had. (toen werkte het vlekkenloos) Sinds hij er 4 heeft is het een grote ellende met de p1 meter. Elke dag moet hij wel 5x een accu opnieuw koppelen. Vervolgens is de veiligheids-restrictie er weer op etc. Is dit iets wat bekend is bij jullie in de p1 software dat het bij 4 batterijen kritiek is?

Ook hebben we de lokale API (die hij niet gebruikt) uitgezet, had ook geen effect.

Ik heb hem nu gevraagd er even 1 uit te gaan zetten om te kijken of het met 3 batterijen ook zo is. (het is btw steeds een random accu die zich los koppelt niet constant dezelfde)

Ook hebben we wifi problemen uitgesloten door het volledige mesh netwerk uit te kleden zodat er maar 1 accesspoint is om zo te zorgen dat we zeker weten dat het niet komt door het verspringen van de apparaten op een ander accesspoint helaas bleven de problemen.

Ik lees hier iets over geheugen optimalisaties in de laatste firmware van de p1 meter hopelijk heeft dit een relatie tot het bovenstaande.

[Velo1901]

Deze klachten had ik in het begin, heb maar 2 accu's. Op voorhand het netwerk aangepast voor de accu's etc. Maar sinds een paar weken alles terug gebracht naar het oude, dus een volledig werkend mesh netwerk (Sonos en Home Assistant weer blij) en totaal geen problemen meer. Moet er wel bij zeggen dat zowel de P1 als de batterijen meedoen aan het beta programma. Het enige wat ik wel gedaan heb is de home wizard item een vast IP-adres gegeven.

[Lupindakaas]

Deze betarelease van de P1 meter bevat inderdaad veel verbeteringen mbt de stabiliteit van een vier accu systeem. Hier kan je je voor inschrijven door de readme op de hoofdpagina van deze repo te volgen. Als je terughoudend bent voor beta firmware kan je ook even met drie batterijen doorgaan, en als deze update naar alle P1 meters doorgevoerd is de vierde weer aansluiten. Hier is helaas nog geen datum voor vastgezet.

[crryp]

@Lupindakaas helder, voor nu draait het even op 3!

[JvHummel]

Het is me opgevallen dat als ik de API gebruik en wissel van Standby naar Zero, de batterij meestal begint te oscilleren.

Dit is nu al een aantal keer gebeurd bij een verder constante vraag in het huis.

Het stabiliseert uiteindelijk wel en blijft daarna netjes stabiel, zoals ik van de PiB gewend ben. Op Tweakers even nagevraagd maar het lijkt iets specifiek aan mijn setup te zijn. Ik wilde het toch hier ook even kenbaar maken.

[DCSBL]

Firmware 6.0203 is now available for beta testers. See opening post for details.

[thecodingmike]

For me, the API has been working well so far. I'm still experimenting with an automation in Home Assistant to determine which of the three modes should be active based on electricity price, sunrise, SOC, etc. It's a lot of fun to play around with, and I'll be keeping an eye on it over the coming period to see what the best solution is. Great work!

[DCSBL]

Just a quick update: we have enabled automatic rollout. All bèta testers will receive the latest firmware in the coming days.

[JvHummel]

Dank voor de melding @DCSBL en hopelijk weer fris en fruitig na een welverdiende vakantie. Toevallig mijn melding van vorige week onder 6.0201 nog voorbij zien komen?

Ik ervaar bijna altijd oscillatie als ik 's ochtends via de API wissel van standby naar Zero modus. Vraag in het huis is verder constant. Het stabiliseert uiteindelijk wel en blijft daarna ook stabiel.

@Devke1972 heeft op Tweakers ook meegekeken en heeft hier geen last van. Ik heb een DSMR4-meter. Wellicht dat er een regelaar wat van slag raakt door de start-impuls en door de trage meter wat na-ijlt?

[DCSBL]

Hallo @JvHummel.

Wil je voor mij nagaan of dit probleem ook actief is met de laatste versie? Kan je daarnaast een bericht sturen naar onze helpdesk, dan kunnen we wat logjes uitlezen. Doe dat op https://helpdesk.homewizard.com/nl/ (groene knop rechtsonder). Het makkelijkste is om aan te geven dat je een medewerker wilt spreken en te verwijzen naar dit bericht, benoem daarbij mijn naam (Duco).

[JvHummel]

Dank voor de terugkoppeling @DCSBL ! Ik neem aan dat mijn P1 cloudverbinding moet hebben voordat jullie de logs binnenkrijgen? Ik zit met 4 batterijen aan de max van wat de P1 aankan, dus ik heb cloudverbinding uitstaan zodat er een slot vrij is voor de commando's van de V2-API. Ik denk dat ik dan een batterij even uit zet.

Ik ga hier (ik denk van het weekend) even voor zitten, dan hebben jullie (neem ik aan?) na het weekend logs om naar te kijken.

[JvHummel]

Goeiemorgen @DCSBL,

Ik heb hier weer naar gekeken maar sinds de nieuwe versie 6.0203 niet meer gezien. Ik hou het verder in de gaten.

[DCSBL]

Bedankt voor de update! Dan ga ik er van uit dat dit probleem is opgelost met de aanpassing in 6.0203

[mireckv]

Ik weet niet of ik dit bij de P1 meter firmware moet zetten of bij de firmware van de Plugin battery. Het is mij opgevallen dat sinds 3-4 weken de 0 op de meter performance verslechtert is van 0,1 Kw gebruik import per dag naar minimaal 0,3 tot 0,4 Kw import per dag. Hier bedoel ik mee dus de stroom die ik inkoop van de energiemaatschappij. Ik zie ook af en toe bij de live weergave dat het laden van de accu's of schakelen van laden naar ontladen veel trager verloopt, waardoor ik dus misschien veel stroom inkoop van de energiemaatschappij. en met ruim 13Kw aan zonnepanelen heb zelfs met bewolkt weer tussen de 2900-3500 watt aan energie dus daar kan het niet aan liggen.
Iemand ook deze ervaring?

[StarckNL]

Versie P1: 6.0203
Versie Batterij: 1.0108

Vannacht stopte de accu met leveren voor ongeveer 20 minuten. Is dit iets van de nieuwe firmware? Of kan ik dit beter oppakken met support?

[DCSBL]

Stuur voor de zekerheid even een mail naar beta@homewizard.com. Zet hierin het serienummer van je batterij, je P1 Meter en het e-mailadres dat je gebruikt voor je HomeWizard account. Dan kijk ik even of we iets in de logs kunnen vinden.

[StarckNL]

@DCSBL

Vandaag zag ik de thuisbatterij weer dit gedrag vertonen (ik zat nu toevallig in de buurt van de batterij, dus zag het gebeuren):

8:36 relais paar keer snel klikken (van ontladen naar inactief) daarna ledjes op voorkant uit.
status in app inactief (wel voldoende zonne-energie om te kunnen laden.

Nu de hele tijd geen activiteit en leds zijn uit.

9:47 relais klikt, ledjes op voorkant springen aan op wit, daarna op paars.
status in app op opladen

[diedvdyk]

Ik weet niet wat er misgaat maar ik heb nu al 2x mijn p1 meter en mijn derde batterij opgegeven voor het beta programma maar ze zijn nog niet toegevoegd. Ik heb het 2 maanden geleden en 1 maand geleden gedaan via het formulier.

[anniusgroenink]

Net als veel anderen heb ik dagelijks een grafiek waarbij de batterij voor 12 uur 's middags is opgeladen, en ik vanaf een uur of 12 vol ga terugleveren.

De mogelijkheid om te schakelen naar Standby is al een belangrijke stap, maar ik voel meer voor het aanpassen van target en/of maximale laad/ontlaadvermogens gedurende de dag. Of misschien zelfs beperken van het maximale laadvermogen tot 400W gedurende de hele dag, nog eenvoudiger. Zou er graag proefondervindelijk achter komen wat handig is.

Ik heb één batterij. Begrijp dat sommige dingen moeilijk zijn vanwege de mogelijkheid om meerdere batterijen te stapelen, maar misschien zijn deze mogelijkheden dan wel beschikbaar te maken bij een enkelvoudige opstelling?

[jtebbens]

Ok en wat vind je bij de betreffende devices in de history? Zie je regelmatig verbinding verliezen?

[Remco2001]

Niet schokkend veel. In ieder geval 1 ervan is een bewuste disconnectie, vanwege afkoppelen en aankoppelen P1-meter.

[jtebbens]

Wat de moeite van het proberen waard is is de DTIM van je 2.4Ghz netwerk waarop ze verbinden zijn te verhogen van 1 naar 3.

[Remco2001]

Gedaan. Wat zou dat moeten verbeteren?

[jtebbens]

In sommige gevallen de stabiliteit van een wifi connectie en vooral voor 2.4Ghz. Mocht je geen verschil merken dan zet je het weer terug naar default (1).

[DCSBL]

Hello everyone 👋,

We’ve released firmware 6.0203 for all P1 Meters paired with a Plug-In Battery. It will be installed automatically over the next few weeks, but you can also update manually following these steps.

I know some of you haven’t yet received individual replies. Our team has been quite busy with vacations, the kWh Meter firmware launch, and other projects I can’t share just yet. I’ll address as much of your feedback here as I can:

• We’ve started to work on zero_discharge_only and zero_charge_only modes. It’s a bit more complex than expected, so we won’t include them in this beta. They’ll appear in a future release.
• We’re investigating issues related to random disconnects (both Wi-Fi and the battery → P1 Meter connection), which seem tied to poor Wi-Fi conditions, interference, or mesh handovers. A fix is in progress, but since 6.0203 doesn’t touch those components, we’re rolling it out now.

Thanks for your patience and all the feedback!

[JvHummel]

"We’ve started to work on zero_discharge_only and zero_charge_only modes. It’s a bit more complex than expected, so we won’t include them in this beta. They’ll appear in a future release."

Very excited for these features, thank you for the continued work and letting us know 👍🏻

[fobrs]

Why the 'zero_' prefix?

[DCSBL]

It will be named to something like "Zero mode (discharge only)". If we call it just discharge_only it may look like the inverse of to_full.

[visioncvg]

Beste DCSBL,
Fijn te vernemen dat jullie ondanks alle drukte en wensen aan de mode discharge only werken.
Zelf nu met hulp van mede tweaker via HA mogelijkheid gemaakt om tussen 7:00 en 11:00 op twee PiB op standby te zetten.
Vanaf 11:00 pas mode NOM i.v.m. dynamisch contract.
Een win win situatie voor terug lever tarief en ondersteuning van het net bij veel vraag.
Op deze zomer dagen in de ochtend nog SOC van 50 % dus een discharge only mode tussen 7:00 en 11:00 zou nog mooier zijn.

Dus dank nogmaals voor jullie mooie product de Plug-In Batterij !

[anniusgroenink]

Great to see new things are being added steadily. So then there are 5 modes, standby, zero, to_full, zero_discharge_only and zero-charge_only. I am missing a logical sixth mode to_empty (or discharge only without the zero). Useful when you want to return to the grid when price is highest and pv is offline? Op ma 23 jun 2025, 12:07 schreef JvHummel ***@***.***>:

…

"We’ve started to work on zero_discharge_only and zero_charge_only modes. It’s a bit more complex than expected, so we won’t include them in this beta. They’ll appear in a future release." Very excited for these features, thank you for the continued work and letting us know 👍🏻 — Reply to this email directly, view it on GitHub <#9 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BMQJPQTC6NZDIBAMSMTFNET3E7GWHAVCNFSM6AAAAAB4HWX3L2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNJUHE2TCOA> . You are receiving this because you commented.Message ID: ***@***.***>

[Remco2001]

It has never been the case of this PIB, to earn money for trading on the imbalance market. Therefore you have other manufactures. This PIB is made for selfconsumption only.

[Devke1972]

Heeft niks met onbalansmarkt te maken. Ik zie hier 2 mogelijkheden. Net ondersteuning bij een tekort maar ook een RTE verbeter mogelijkheid.

[Remco2001]

Ik doel ook op de aangegeven, niet aangekondigde optie to_empty. Dat is puur om geld te vangen tijdens hogere dynamische prijzen.

[DCSBL]

To confirm, the Plug-In Battery is not supposed to be used for trading; it is used to increase self-consumption. This is one of the reasons why we also do not add a manual target mode (besides grid and safety regulations).

A to_empty mode is never useful for self-consumption.

[Devke1972]

Mijn inziens kun je daar op verschillende manieren tegen aan kijken. Met to_full heb je de mogelijkheid het net te helpen op het moment dat het net "vol" raakt. Het voordeel is dat je goedkoper stroom inkoopt en dus het net helpt. 2 vliegen in 1 klap. Op de terug weg kan het ook met een eventueel overschot in de ochtend of ander moment. Het net helpen als er te weinig stroom is (Nederland komt thuis). Persoonlijk zie ik dan liever een in te stellen vermogen. Daarmee vang je 3 vliegen in 1x denk ik. Net support, betere RTE als je de batterij op een gunstiger vermogen ontlaad en je krijgt er een "minimale" vergoeding voor. Misschien handiger om deze discussies op tweakers te doen. @DCSBL heeft al eens aangegeven hier de suggesties graag te lezen en ze zo uitgebreid mogelijk dan toe te lichten. Discussie is wellicht voor tweakers beter.

[Remco2001]

Dan heb ik een verkeerde definitie van de onbalansmarkt in ogen denk ik.

[DCSBL]

See #9 (reply in thread)

[fobrs]

Nu ik 2 batterijen heb, kom ik er achter dat de mode instellingen niet per batterij gegeven kunnen worden. Ik zou graag 1 batterij in standby willen zetten, maar dat kan niet met de huidige API....