If nothing changed and stopped working since 2 day using an older app version, how can it be this app then? Is your Homey overloaded? Does it have enough resources free? Did you try a reboot of your Homey 2019?
You can try latest test version but that mainly focuses on the battery policy device feature which is something you dont have as per your commited log.
Because HW app is the only one giving trouble with unreachable devices since the last days (having 103 devices with multiple apps) and memory usage increase (after the update), so that’s why I ended up here
I got nothing to work with based on your log, there is no crash info or memory/cpu warning listed. Homey purely complains about unable to reach your wifi devices. Interval / polling is fine with 10s as per log you shared so that is not the case either.
I really feel you are now hitting your max of your Homey 2019 where this app seems the first signal showing this.
I suggest a reboot of your Homey. Further check other apps on your Homey that may have increased memory size as well making it hard to work properly.
I will release 3.18.0 soon as impoved cpu and memory but that is battery policy focused but perhaps it does something for you.
Hmm, thanks for the effort and quick replies,.. I’m aware of the limits of the HP19. A reboot seems like to have calmed down the HW app. Hopefully everything will go back to normal.
Good to hear, no problem. But I cant support this any longer. I would have a full mailbox if it was the app with crashes and (unasked) diagnostics.
Beta/test v3.19.0
Settings:
Selection for meteosat or solcast. Will drop solcast if meteosat proofed itself. The free key with 10-12 updates is a problem (ratelimit / other sources use same key).
The total current is not shown. The P1 meter API V1 Json contains active_current_a but the shown Current is same as Current Amp phase 1.
{
"wifi_ssid": "SSDINAME",
"wifi_strength": 100,
"meter_model": "ADN9 7534",
"unique_id": "GID_3",
"total_power_import_kwh": 180.281,
"total_power_import_t1_kwh": 180.281,
"total_power_export_kwh": 0,
"total_power_export_t1_kwh": 0,
"active_power_w": 325,
"active_power_l1_w": 130,
"active_power_l2_w": 152,
"active_power_l3_w": 45,
"active_voltage_l1_v": 237.5,
"active_voltage_l2_v": 238,
"active_voltage_l3_v": 237.4,
"active_current_a": 1.6,
"active_current_l1_a": 0.7,
"active_current_l2_a": 0.8,
"active_current_l3_a": 0.1,
"external": []
}
Edit: The firmware version is 6.0305.
Looks like you are on an old firmware of your P1 as active_current_a is not w valid datasource anymore so removed it. But let me make it somehow backwards compatible again.
I updated my P1. The version is now 6.0503. active_current_a is still there.
{
"wifi_ssid": "SSDINAME",
"wifi_strength": 100,
"meter_model": "ADN9 7534",
"unique_id": "GID_4",
"total_power_import_kwh": 180.558,
"total_power_import_t1_kwh": 180.558,
"total_power_export_kwh": 0,
"total_power_export_t1_kwh": 0,
"active_power_w": 415,
"active_power_l1_w": 130,
"active_power_l2_w": 240,
"active_power_l3_w": 45,
"active_voltage_l1_v": 237.8,
"active_voltage_l2_v": 237.5,
"active_voltage_l3_v": 237.5,
"active_current_a": 2.1,
"active_current_l1_a": 0.7,
"active_current_l2_a": 1.3,
"active_current_l3_a": 0.1,
"external": []
}
Strange as api documentation stripped or will soon.
Anyway I added the backward compatible replacement. Will come with next release v3.19.1 so it will either pull that datapoint (if it exists) else it will add up all 3 currents and populate the main one.
Test version (v3.19.1)
@Jeroen_Tebbens, I have a question; I am using the not-connected trigger card for the P1 meter (APIv1). I didn’t see this trigger in the API v2 version, is that correct?
I use the P1 meter for charging station load balancing, and for that, it is important to know that the P1 meter has a continuous connection. Wi-Fi is never perfect, so I have built in rules that reduce the charging speed after a certain amount of time offline, just to be safe. The not-connected trigger worked perfectly for this. But I want to switch to the API v2 to reduce load on Homey.
Otherwise, I will look into Smart Presence/ Net Scan like solutions, no problem.
Good catch, Will be fixed in next release. Working on the post 2027 salderen code at this moment but your request is included.
Work in progress for 2027 (end of “salderen”).
Further tested export prices being negative. This is speculation based on dynamic prices today and deducted “energiebelasting”.
The developed code and trigger card makes the solar inverter step down its power to minimize its production and match up household usage and battery needs.
Next step is to improve it to fully cut it off but that is not supported to every inverter.
EDIT: fixed for both import and export negative. Real test would be in 2027. 
Is het ook mogelijk van een Goodwe inverter die is toegevoegd in de Homewizard app te zien in Homey?
Hi @Francois_Pauwelsen, this is the english section here so please translate your query to english or post it the dutch section. But…regarding your query, I doubt if this the right direction to ask me to add solar inverters that are managed via HW Cloud directly. There risk of delay and gaps is very high, a slight change in the cloud based integration from GoodWe makes this fail easily as you might have noticed with their latest changes. Check the other GoodWe apps here on the platform that are already aiming this issue and be a better fit to make it work for you then asking me to incorporate this cloud based “GoodWe” solar inverter via Homewizard online.
It is not about I can’t do, but the complexity and risk of problems are bigger rather having the other GoodWe apps here on the platform giving you a better result.
Possible issue with Plug-in Battery measure_battery_threshold_below Flow Card – v3.19.9
Hi Jeroen,
I am using HomeWizard app v3.19.9 on a Homey Pro 2023 with two HomeWizard Plug-in Batteries.
During an API-based validation of the Homey Flow Card catalogue, I found a reproducible issue affecting both Plug-in Batteries.
For both devices Homey exposes the trigger:
measure_battery_threshold_below
The raw Homey Web API shows the trigger argument as:
name: "threshold"
type: "number"
placeholder: "%"
title: null
Both batteries generate the same result independently.
The batteries themselves are working normally and their SoC is reported correctly. The Condition and Action Flow Card catalogues also validate correctly. Only the Trigger catalogue fails schema validation on the generated battery-threshold cards.
The Homey integration consuming the Web API expects the Flow Card metadata title to be a string and therefore rejects the Trigger catalogue when these null values are encountered.
I realise this might be generated automatically by Homey from the measure_battery capability rather than being an issue in your app itself.
Could you please advise whether the Plug-in Battery driver explicitly adds measure_battery, and whether this null metadata can be prevented at app/driver level? If this is entirely generated by Homey, I can report the issue further upstream instead.
I have deliberately not removed/re-paired the batteries or changed their capabilities, as everything else is functioning correctly.
If useful, I can provide the exact Flow Card IDs and additional API/diagnostic output.
Thanks in advance.
Hi Johan, thanks for the report.
measure_battery is a standard Homey capability that our driver adds, but the measure_battery_threshold_below trigger isn’t defined in our app. Homey generates it, including the threshold argument with title: null. On my own Homey the same null title appears on 60 cards from 17 different apps, so we can’t change it at app level. Best to report it to Athom, and have the client tolerate a null title.
While checking I did find a real issue in our own “Battery state changed” trigger: its dropdown values also had a null title. That’s fixed and will be in the next release. I’m not sure it’s the card your validation hit, since you mentioned the threshold card
