So I guess I can’t stay behind with some policy based modes for the battery.
What I’ve been working (still locally here) is a virtual device/driver that links to your P1 (apiv2).
The HW Plugin Battery is not a proper fit to play with the market prices and deal with cheap buy and sell when prices are high, yet controlling the behavior a bit during these cheap or expensive timeslots can help.
Capabilities
It will get weather forecast based on your city (indication of solar, but can be overridden with a flow card).
It will take DAP (dynamic prices with + ~ 0.11 to closely match the prices)
Timeslots (normal, peak 16:00-21:00, off peak 23:00-07:00, super off peak 02:00-05:00)
Is the P1 still online? Click the settings icon (top right corner) and click Devices. If it’s offline, a power cycle of the P1 dongle might help (I also had the offline issue once)
Auto‑Apply is OFF by default → enable it if you want automatic control
Quick Setup: Dynamic vs Fixed Mode
Dynamic Mode
Choose Dynamic if your electricity price changes every hour.
Use this when you have a dynamic contract (e.g. Tibber, Zonneplan, ANWB etc.)
Any hourly dynamic pricing (not set for 15min)
NOTE: I do not use any of the specific settings of dynamic contracts as this app has no rights/priveleges to access other Homey components other that Homewizard devices itself in this app.
I pull DAP prices myself, add a generic 0.11 euro and 21%VAT which roughly comes close the actual prices found with these dynamic contracts.
Dynamic mode uses:
hourly prices
weather forecasts (sun calculation specific to hold back if sun is expected, not all sources are trusted so I added 2 other sources to support the calculation / confidence)
battery limits
You will need to set:
Weather Location (put city here or if you want be specific long/lat details)
Max Charge Price (set your lower limit when you want to force charging)
Min Discharge Price (set your upper limit to avoid losing money)
Choose Fixed if your electricity price does not change during the day.
Use this when you have:
a normal fixed tariff
a simple peak/dal tariff
Fixed mode uses:
your Peak Hours
grid load
battery power
In the application settings you can find a tab specific on Battery Policy and the reasoning on what criteria are taken in to account on battery state, export (sun?), prices high/low, sun score (GFS/ICON weather sources to add confidence). Scores show how confident it wants to either charge (0% no reason to charge), discharge (30%) or preserver (45%). In the battery police settings you can control the minimal confidence level it needs to flick the switch and either charge, discharge or preserve (i.e. idle/standby do nothing).
Experimental version of P1 that is cloud based. You add device, use your homewizard username and password and it connects to https://hwenergy.app webpage.
This a potential solution for users that have their P1 not in their own locakbwifi network (apartment/flat?).
But refresh rate is about every 40s, not realtime. And if your internet drops or has issues it will not update. Not perfect but potentially a solution for the usecase I describe above.
Hi @Jeroen_Tebbens may i ask a feature request? I am making a flow to switch of multiple devices if the grid connection is lost, so the home battery system that i have last longer.
But there is no activation trigger for the variabel “Stroomstoring” or “Net dip”. Is this something that could be add to the app?
Thanks is there also a option to make a restore flow trigger card So i know that the grid connection is restore and all devices can be turn on back again?
There is no extra datapoint on restore.It is just an increase of an counter sadly.
You can track with a flow what the value is and if your measure_power is changing on your P1 as that one is static/null.
Today I added a HWE-KW3 energymeter to my main powernet . Successfully added to the HomeWizard app and the meter is visible in my network. Now I wanted to add to my homey pro 2023 and it finds the meter (APIV2) but then it hangs and is waiting for a button to be pressed. On the P1 poort U’ve got the homey dongle. Taking this one down makes no difference. Any suggestions would be welcome
I’ve been trying the new battery policy. And I’ve noticed a few things:
It didn’t do anything for days, took me a while to notice that I had to turn on “beleid ingeschakeld”
Yesterday it went to “full_charge” for a few hours when prices were low, but then it stayed on “standby” for the rest of the day, even though there were hours that were expensive enough to compensate for the RTE-loss. Is this because I only managed to start it during the day, or related to the settings (see screenshot). I’d say that the max price for charging and min-price for discharging are not necessary with the third parameter already there?
Still not perfect and still testing here locally as well. Even today to_full and zero_discharge_only or standby is a thin line of calculating if there is profit or not and looking ahead later the day if there are expensive hours to use instead. I will update the latest version I have now to see if it improves for you.
But thanks for testing/trying, still a learning curve here. The Homewizard Plugin Battery is not the perfect battery for dynamic tariffs as we can do a full charge with 800w per unit but the release (discharge) is limited to your own household usage which is different to the other brand plugin batteries out there. So dont expect magic and high profits. It will be more of reducing costs with charging cheap or when sun forecasts are there wait till you can charge for free.
Yes agreed, I was mostly wondering what the three settings “Maximale laadprijs”, “Minimale ontlaadprijs” and “Minimale arbitragewinst” do. Does the “Mininale ontlaadprijs = 0.25” stop the PiB from going to zero / zero_discharge when the energy price is below 0.25?
I’ll try with the settings you just posted.
Personally I’m still working on an app of my own to do this, where I want to take into account feed-in and usage tariffs for each hour. Because of the Zonneplan “zonnebonus” it can be more profitable to send PV-power to the net sometimes, but only when there is still “salderingsruimte”.
Hi, I am planning to move in june to zonneplan as well for the extra “zon” margin but the current code doesnt cater for this. Current aim was to be ok for any dynamic, not specific for Zonneplan.
As I dont have the custom markup (which differs per energy contract, ANWB, Zonneplan, Budget Energie, Frank etc. etc.). I picked an avarage of 0.11 and use that to be generic.
Explanation of the three settings
1. Maximum charge price (€ / kWh)
This is the upper limit for grid‑charging. The battery will only charge from the grid when:
the current price is below this value, and
charging is profitable according to the dynamic threshold (dynamicMaxCharge).
If the price is higher → no grid charging. PV charging is always allowed because it’s free.
2. Minimum discharge price (€ / kWh)
This is the lower limit for discharging.
If the price is above this value → discharging is allowed (as long as SoC > min_soc).
If the price is below this value → the battery will not discharge and stays in standby or zero_charge_only.
So yes: If you set “Minimum discharge price = 0.25”, the battery will NOT go to zero/zero_discharge when the price is below €0.25.
It will only discharge when the price is ≥ 0.25.
3. Minimum arbitrage profit (€ / kWh)
This defines the minimum spread needed to make a charge → discharge cycle worthwhile after accounting for:
round‑trip efficiency
conversion losses
price difference between cheap and expensive hours
Example: If MIN_PROFIT_MARGIN = 0.01, the spread must be at least 1 cent per kWh after losses.
This prevents unnecessary micro‑cycles.
As this app has no “power” privileges (control your homey to access other devices) you can improve the solar production with a flow this way. So instead of the app pulls the information you can sent your curent watt production to the battery policy. There is some estimate PV detection but if you can feed it with real watt data from your solar it should improve the actions:
I cannot make a flow where the current power check is in the ‘AND’ part of the flow so meaning if I want to check during a flow what is the power consumption I cannot.