P1 Meter firmware 6.0201 has been released as beta

[DCSBL]

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.

This release replaces 6.0200.

Important

For this release we have not enabled the automatic rollout. Follow the steps in "How to update to the latest software" to install the update.

This release includes significant memory management improvements designed to enhance stability. We anticipate these updates to perform seamlessly, but as a beta release, unforeseen issues may arise. Please update to the latest firmware only if you wish to actively test the new API features.

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!

[adekloet]

Ik heb hetzelfde probleem op de laatste beta:

Het sensor deel werkt prima, alle sensors komen binnen zonder problemen. zoals je al zei de Rest_command had je nog niet getest, deze geeft een error zoals hze hier no staan geconfigureerd:

rest command uitgevoerd via de action in de developer tools:
uiitkomst:

Client error occurred when calling resource "https://192.168.178.57/api/batteries"

configuration.yaml:

mode_zero:
url: https://192.168.178.57/api/batteries
method: PUT
headers:
authorization: Bearer token
accept: "application/json"
payload: '{"mode": "zero"}'
verify_ssl: false
content_type: 'application/json'
mode_to_full:
url: https://192.168.178.57/api/batteries
method: PUT
headers:
authorization: Bearer token
accept: "application/json"
payload: '{"mode": "to_full"}'
verify_ssl: false
content_type: 'application/json'
mode_standby:
url: https://192.168.178.57/api/batteries
method: PUT
headers:
authorization: Bearer token
accept: "application/json"
payload: '{"mode": "standby"}'
verify_ssl: false
content_type: 'application/json'

logfile error:

2025-05-09 11:51:05.156 ERROR (MainThread) [homeassistant.components.rest_command] Error fetching data: Cannot connect to host 192.168.178.57:443 ssl:default [Connection reset by peer] 2025-05-09 11:51:05.157 ERROR (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Error executing script. Error for call_service at pos 1: Client error occurred when calling resource "https://192.168.178.57/api/batteries"

--> Een reboot van de P1 meter zelf lost het probleem niet op (dit zag in een een eerdere post met eigenlijk hetzelfde probleem).

is dit een https probleem? maar dit staat op verify_ssl: false in jou code..

Bedankt en groeten

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

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

[adekloet]

Het sensor deel werkt prima, alle sensors komen binnen zonder problemen. zoals je al zei de Rest_command had je nog niet getest, deze geeft een error zoals hze hier no staan geconfigureerd:

rest command uitgevoerd via de action in de developer tools:
uiitkomst:

Client error occurred when calling resource "https://192.168.178.57/api/batteries"

configuration.yaml:

mode_zero:
url: https://192.168.178.57/api/batteries
method: PUT
headers:
authorization: Bearer token
accept: "application/json"
payload: '{"mode": "zero"}'
verify_ssl: false
content_type: 'application/json'
mode_to_full:
url: https://192.168.178.57/api/batteries
method: PUT
headers:
authorization: Bearer token
accept: "application/json"
payload: '{"mode": "to_full"}'
verify_ssl: false
content_type: 'application/json'
mode_standby:
url: https://192.168.178.57/api/batteries
method: PUT
headers:
authorization: Bearer token
accept: "application/json"
payload: '{"mode": "standby"}'
verify_ssl: false
content_type: 'application/json'

logfile error:

2025-05-09 11:51:05.156 ERROR (MainThread) [homeassistant.components.rest_command] Error fetching data: Cannot connect to host 192.168.178.57:443 ssl:default [Connection reset by peer] 2025-05-09 11:51:05.157 ERROR (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Error executing script. Error for call_service at pos 1: Client error occurred when calling resource "https://192.168.178.57/api/batteries"

--> Een reboot van de P1 meter zelf lost het probleem niet op (dit zag in een een eerdere post met eigenlijk hetzelfde probleem).

is dit een https probleem? maar dit staat op verify_ssl: false in jou code..

Bedankt en groeten

[Gielz1986]

Altijd even een simpele write actie via cmd doen om te kijken of het dan wel werkt. 9/10 keer is het een ha probleem of de code die je gebruikt is foutief

[adekloet]

Ik zit op 6.0201, vanmorgen erop gezet, ook even een harde reboot gedaan van de P1. Als ik de Curl run vanaf een een linux Bash krijg ik de error:

~$ curl -X PUT "https://192.168.178.57/api/batteries" --insecure
-H "Authorization: Bearer "
-H "X-Api-Version: 2"
-H "Content-Type: application/json"
-d '{"mode": "standby"}'
curl: (35) Recv failure: Connection reset by peer

Het is niet het token want de read van de parameters werkt wel.

[DCSBL]

Wat vraagjes:

1. Hoeveel batterijen heb je?
2. Zijn er andere programma's die de API (v1 en/of v2) gebruiken, zoals de Home Assistant integratie?
3. Kan je proberen bovenstaande (tijdelijk) uit te schakelen en te zien wat er gebeurd met je YAML actie?

[adekloet]

Natuurlijk hierbij de antwoorden:

1. 1 Battery
2. Ja, de "normale integratie staat ook de p1 meter te pollen inderdaad voor mijn energie dashboard
   2a. en de HomeWizard app staat ook aan de er wordt daar ook polling gedaan, dus potentieel vanaf 3 (inclusief de rest sensors nu) systemen connecties
3. Ik kan de integratie disablen en dan proberen, of wil je liever allebij? hoe zet ik de polling uit van de APP, die deleten of?

Hoeveel is nu ingesteld als maximum connecties die gemaakt kunnen worden naar de P1 meter? Of zijn we al bij de grenzen van de waarschijnlijk ESP32 memory o.i.d. ?

[adekloet]

Oke duidelijk, ik heb 1 systeem (de HA integratie uitgezet want dat was het makkelijkst) nu krijg ik de data wel terug en het commando wordt uitgevoerd, misschien kan er nog iets slimmer omgegaan worden met de TCP connecties of ietsje extra toestaan als de hardware het toelaat.

nu dus

1 battery
rest(command) sensoren
1 x active app op telefoon en een actieve app op een tabet

Ik weet niet precies hoeveel connecties dat opleverd, maar jij wel :-)

Bedankt voor alle harde werk en fijn weekend!

[Gielz1986]

Hier draait het allemaal prima en heb eigenlijk geen storingen gehad met deze nieuwe P1 api.

@DCSBL verwachten jullie van uit HW nog een nieuwe beta of zal deze as is over gaan naar productie?

[Devke1972]

Ook hier geen rare dingen. Ik hoop dat het schrijven van laad en ontlaad vermogens mogelijk wordt nog. Om niet in herhaling te vallen... usercases zijn op verzoek al netjes onder de post van @DCSBL geplaatst bij het vrijgeven van deze beta. Ook ik ben benieuwd.

[RTVMAN]

Allereerst leuk dat er een Beta kanaal is om vooruit te lopen op de ontwikkelingen
Uiteinderijk hier ook werkend gemaakt.
Was even een uitdaging om de juiste token te krijgen. De instructie in de beschrijving kwam niet helemaal overeen voor CMD onder windows.
Deze werkt voor de dospromt onder windows;
C:\Windows\System32>
curl https://192.168.1.21/api/user --insecure -X POST -H "Content-Type: application/json" -d "{"name": "local/cool-new-app"}"
response;
{"name":"local/cool-new-app","token":"06E39E53F3Axxxxxxxxxxxxx2863DD"}

Verder ook af en toe dat de API hangt, maar na reboot weer ok.
Ik denk dat door de PIB op Standby te kunnen zetten en de LIMIT functie van de Solaredge PV en een optimale automation gemaakt kan worden in HA in combinatie met een dynamisch energiecontract. In de ochtend zet ik nu de SSID uit van de PIB om laden te voorkomen. Dit kan nu anders en netter opgelost worden.

@DCSBL Bedankt voor het delen en je interactie in dit kanaal.

[kegge13]

Ik was erg aan het ploeteren met de quotejes. Homewizard suggereert de standaard unix-methode: enkele en dubbele quotejes afwisselen ( -d '{"name": "local/fibaro_user"}' ). Op windows klaagt curl dan dat de laatste accolade niet goed is. Uiteindelijke werkte voor mij: -d "{"name": "local/fibaro_user"}". De backslash beschermt tegen interpretatie door curl.
Ik zag ook hierboven al voorbeelden met meerdere dubbele quotejes achter elkaar:-d "{""name": "local/fibaro_user""}". Dat werk blijkbaar ook. Afijn, ik heb mijn token.

[JanSmart93]

[DCSBL]

Hey @JanSmart93, Kan je hiervoor even een mailtje sturen naar het bekende beta e-mail adres met daarin

• serienummer(s) van de batterijen
• serienummer van je P1 Meter
• e-mail adres die je gebruik voor je HomeWizard account.

Thanks! Dan kijken we er even naar.

[janhenk102]

@JanSmart93 Ik zou niet mijn e-mailadres zo hier neer gooien, maar even een echt mailtje sturen in plaats van hier te plaatsen...

[DCSBL]

Hi all, just a quick update:

I'm on holiday for the coming weeks. My colleague @Lupindakaas (Lucas) will handle any important questions during this time.

We don't expect any P1 Meter beta updates in the coming weeks and will use this opportunity to perform a long-term test of the current beta.

Please continue to share your findings and ideas! We'll continue to read and try to respond to your feedback.

[Devke1972]

``Hopelijk staat de write optie op eerder genoemde suggestie van o.a. mij en @Gielz1986 nog op de agenda de komende weken (na de vakantie).
Ik wens je een welverdiende fijne vakantie toe! Geniet ervan. Lucas welkom hiero.

[johnvanderster]

Bedankt voor de heads up, fijne vakantie. Wij testen verder :-)

[RTVMAN]

Enjoy your holiday, sometimes humans also needs to get in ballans (ZERO) :)

[jtebbens]

Kan er iemand met een Homey de beta/test versie proberen van mijn Homewizard app (3.6.18)?
Ik wil even weten of die actie en conditie flows al werken. Er is ook bij instellingen van de P1(apiv2) een optie/settings om de modus van de accu toegevoegd maar ik heb geen plugin battery dus kan niet testen.

Op de Homey moet de P1 als (apiv2) toegevoegd zijn en minimaal firmware (6.0201).

bedankt

[jtebbens]

Nieuwe test versie v3.6.20.

[shthpnz]

Jeroen, ik heb niet meer getest de afgelopen dagen, omdat de batterijen ‘afwisselend’ geen verbinding maken met de P1-meter. Om uit te sluiten dat dit komt door overbelasting van de P1-meter, heb ik diens verbinding met Homey uitgeschakeld.

[jtebbens]

Geeft niet, ik loop nu vast op een bug in mijn code die actie kaartje weigert te registreren in de Homey.

[jtebbens]

Nieuwe test versie v3.6.30

[jtebbens]

Wat bug fixes v3.6.32 zou nu wel moeten werken.

[kegge13]

Ik heb de PiB nu pas enkele dagen in huis. Het is mij wel al gelukt een token te scoren via cmd en curl op het Windows-platform. Alleen de enkele quotjes uit het voorbeeld mislukten. Daarom heb ik deze constructie gebruikt "{"name":\üser_name"}" De backslash beschermt teken interpretatie door curl.
Voor mij is levensduur van de accu een belangrijke factor. Zou het mogelijk zijn (het liefst via de app) om een ondergrens in te stellen voor het ladingspercentage? Ik zit te denken aan 20%. Het is veel meer gedoe als je het zelf via een HA-script bij moet houden.
De P1-meter lees ik nu routinematig dagelijks uit via het v1 protocol vanaf mijn Fibaro HC2. Komende week ga ik een poging doen met v2 commando's.

[Lupindakaas]

Goedemorgen! Bedankt voor de tip voor cmd curl requests. Met betrekking tot zijn levensduur draagt de Plug in Battery draagt hier zelf zorg voor. Dit is van veel factoren afhankelijk, niet alleen de diepte waarop deze wordt ontladen. In al deze factoren hebben we een ideale balans gevonden tussen levensduur en performance. Het is dus niet nodig om zelf de ontladingsgrens of andere dergelijke optimalisaties in te stellen.

[Velo1901]

Hier gaat het met de dag slechter met de verbinding. Moet dagelijks de P1 meter resetten en vandaag nadat de batterijen op 100% staat knipperen ze beide rood. Maar ook de watermeter heeft nu ook kuren. Of dit met de wifi verbinding te maken heeft weet ik niet omdat beide batterijen tussen 80 en 100% sterkte aangeven.
Zie net dat de batterijen zijn geüpdatet naar 07

[Lupindakaas]

Goedemorgen, bedankt voor het melden. We zijn bezig met onderzoeken waar het fout gaat. Als jullie problemen ervaren met een meshnetwerk, welk merk mesh AP's gebruiken jullie? Alvast bedankt.

[johnvanderster]

Ik gebruik ze van Ziggo, wifi6 pods 3x

[shthpnz]

Hier
• 4 keer Deco BE65;
• met mesh- verbindingsmogelijkheid uitgeschakeld voor alle HW-producten;
• alle HW producten toegewezen aan hun dichtstbijzijnde AP.
• Alleen het 2.4 netwerk mag gebruikt worden.
• Alle HW producten zitten op hetzelfde 2.4 IoT-netwerk en
• ieder IP-adres is vastgezet.

[shthpnz]

en 4 PIB’s.

[visioncvg]

Beste DCSBL en Lupindakaas,

Ter info hier Fritzbox 7390 met Fritz 1750E in wifi mesch netwerk.
Sinds één week beta versie probleemloos draaiend, maar daarvoor ook GEEN problemen met netwerk.
2x PiB HW en P1 met fixed ip adres, lees de PiB beide ook continue (5 sec) uit via node-red om deze zichtbaar te maken in domoticz.
Circa 9 apparaten verbonden met 2,4 GHz.

Vooral beta gebruiker geworden i.v.m. dynamische tarieven hier.

[adekloet]

Met een unifi mesh, 1 batterij geen probleem gezien. Wel gezien dat de p1 meter eigenlijk alleen stabiel is met max. 3 clients die verbindingen opzetten naar de p1. Dus mocht je meedere batterijen hebben, een home assistant (of misschien zelf 2) de app op je telefoon en tablet? En misschien nog een andere home automation? Veel te veel. De p1 kan dat niet hebben nu en dropped dan tcp connections en zal op dat moment even in een soort blocking gaan en geen andere sessies accepteren. Curl etc. Werkt dan niet en geeft op de commandline netjes een error dat het niet kan connecten.Zou er als test iemand met b.v. twee batterijen eens de hoeveel clients die data schrijven of lezen kunnen beperken tot max. 3? Is het dan wel stabiel? -------- Original message --------From: Lucas Dekker ***@***.***> Date: 19/05/2025 11:11 (GMT+01:00) To: homewizard/beta ***@***.***> Cc: Alex de Kloet ***@***.***>, Manual ***@***.***> Subject: Re: [homewizard/beta] P1 Meter firmware 6.0201 has been released as beta (Discussion #9) Goedemorgen, bedankt voor het melden. We zijn bezig met onderzoeken waar het fout gaat. Als jullie problemen ervaren met een meshnetwerk, welk merk mesh AP's gebruiken jullie? Alvast bedankt. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Velo1901]

Ik gebruik een combinatie van 3x Deco BE65 en 3x Deco XE75 op 2.4, 5 en 6 Ghz maar heb ik het MLO-netwerk, Snelle roaming en Beamforming uitgeschakeld staan. Hier stonden ze tot een week geleden op een IoT-netwerk, maar daar heb ik ze weer uitgehaald. Wel IP-adres vastgezet, mesh uitgezet, 2.4 voorkeur en verwezen naar dichtstbijzijnde AP op alle HW producten. 2 PiB's

[Devke1972]

Ik zie in mijn HA Logfile deze melding voorbij komen. Heb het IP adres even naar xxx.xxx.xxx.xxx gezet. Ik merk aan de batterij niets.

Logger: homeassistant.components.rest.data
Bron: components/rest/data.py:120
integratie: RESTful (documentatie, problemen)
Eerst voorgekomen: 16 mei 2025 om 01:44:25 (10 gebeurtenissen)
Laatst gelogd: 09:58:54

Error fetching data: https://xxx.xxx.xxx.xxx/api/batteries failed with All connection att empts failed
Error fetching data: https://xxx.xxx.xxx.xxx/api/batteries failed with

EN

Logger: homeassistant.components.rest.data
Bron: components/rest/data.py:114
integratie: RESTful (documentatie, problemen)
Eerst voorgekomen: 16 mei 2025 om 01:44:07 (2 gebeurtenissen)
Laatst gelogd: 18 mei 2025 om 14:57:45

Timeout while fetching data: https://xxx.xxx.xxx.xxx/api/batteries

[RTVMAN]

🧪 Bèta-update 21 mei: ZERO / STANDBY / FULL-aansturing via cURL

Met de recente uitbreiding van de aansturingsmogelijkheden van de PIB is het nu mogelijk om de batterijmodus te schakelen tussen ZERO, STANDBY en TO_FULL via cURL of Home Assistant-integraties. Deze functionaliteit werkt uitstekend en biedt veel meerwaarde voor geavanceerde energieregeling.

❗ Huidige beperking in de app

Bij het openen van de settings van de PIB verschijnt de volgende foutmelding:

"Settings not available in current mode."

Deze fout ontstaat door een mismatch tussen de bèta-functionaliteit en de huidige versie van de HomeWizard app. Concreet betekent dit dat:

• Je de instellingen van de PIB niet kunt wijzigen wanneer deze in STANDBY staat.
• De app (versie 1.25.1 (115)) mogelijk achterloopt t.o.v. de beschikbare bèta-functionaliteiten.

Het is op dit moment onduidelijk of dit een tijdelijke beperking is of structureel wordt aangepakt. Graag hoor ik of er een workaround of oplossing is, anders dan het vooraf handmatig instellen van een ondersteunde modus.

---

✅ Wat werkt er al goed?

De mogelijkheid om via Home Assistant de batterij actief aan te sturen op basis van prijs, tijd of restcapaciteit is zeer waardevol.

Voorbeeldtoepassing:

• ’s Avonds automatisch schakelen naar STANDBY om bijv. 25% restcapaciteit te behouden tot de ochtend.
• Overdag automatisch terug naar ZERO of TO_FULL, afgestemd op Tibber-uurprijzen.

Dit stelt de gebruiker in staat om het maximale uit de PIB te halen, volledig geautomatiseerd — mits er voldoende kennis is van Home Assistant en het gebruik van rest_command.

---

🙋‍♂️ Vragen aan HomeWizard / @DCSBL

• Wat is de visie van HomeWizard met betrekking tot deze geavanceerde aansturing?
• Wordt het schakelen tussen modi een blijvende functie voor gebruikers?
• Komt er een UI-ondersteuning in de app voor deze functies?

Het spreekt voor zich dat het flexibel kunnen aansturen van batterijmodi via integraties als Home Assistant een essentiële functie is voor geavanceerde gebruikers. Het zou mooi zijn als deze functionaliteit permanent ondersteund en verder uitgebreid wordt. 👍

---

Tot zover deze update.
Met vriendelijke groet,
Johan
Bèta-tester HomeWizard-integratie

[Lupindakaas]

Bedankt voor het melden. Problemen met de app kunnen inderdaad voorkomen als er nieuwe features in de beta komen, we zijn intern aan het kijken hoe we dit gaan oplossen.

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

Do you pass your token as parameter on the HC2? user:unauthorized is the expected response when the request is performed with an invalid bearer token.

[kegge13]

Today I tested the curl:
curl https://192.168.178.xx/api/measurement --insecure -H "Authorization: Bearer 39..my_token..AB" -H "X-Api-Version: 2"
with response:
{"energy_import_kwh":35.378,"energy_export_kwh":25.072,"power_w":-80.263,"voltage_v":238.443,"current_a":0.629,"frequency_hz":49.991,"state_of_charge_pct":30,"cycles":11}

In my HC2 I translated that as:

function HandleDataPiB(_data,aurl)
fibaro:debug("success for " .. aurl)
fibaro:debug('received data: '..string.len(_data['data'])..' bytes')
fibaro:debug('received data: '.._data['data'])
end


function PiBv2()
local urlp=set_url(_shared.ip.PiB).."/measurement"
log("url",urlp)
http:request(urlp,{
		success = function(response)
			HandleDataPiB(response,urlp)
			end,
		error = function(message)
			fibaro:debug("Error: " .. message)
			end,
		options={method="GET", checkCertificate= false},
		headers= {"Authorization: Bearer 39..my_token..AB","X-Api-Version: 2"}
		})
end

As output the url is reported as:
https://192.168.178.xx/api/measurement

Then the success function is called:
success for https://192.168.178.xx/api/measurement
received data: 17 bytes
received data: user:unauthorized

The ip is masked here as xx, the token was copied from the curl command. Adding the checkCertificate=false option did make a difference. When set to true, the error function was triggered with text "certificate verify failed". The only thing that comes to my mind is a wrong use of the header.

[jtebbens]

Its a selfsigned certificate so it is expected to fail upon verify cert.

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