The devices are based on the Energy | Homey Apps SDK and I think there is no other option ![]()
For the battery, could be interesting to have as a display indicator option the SOC % so we could see in a glance at what percentage the battery is. Maybe something easy to add as the capability is already displayed.
I’m still waiting for my installer to activate the modbus on the charger, they are suppose to come tomorrow, so after I will also test and do some reverse engineering to find the API calls it does. I see the updates are more frequent (once per minute) or immediate when you connect/disconnect a cable or stop/start charging than the information of PV consumption etc on the FusionSolar app. Maybe it’s a viable option until more commands/controls are made available via ModBus.
For the battery SoC indicator on the device tile: I looked into this and unfortunately it’s not straightforward in Homey SDK v3. Devices with class: "battery" already get the standard battery icon rendered automatically by Homey — but there’s no supported way in SDK v3 to additionally display the numeric percentage as a text label directly on the tile. The mobile.components approach that allowed this in SDK v2 is ignored in v3, and there’s no documented replacement for it yet.
The Battery Status widget already shows the SoC as a large number with a colour-coded bar.
You are right, I remember now I had the same issue on the Bosch ebike app ![]()
I have a different Solutions now with custom capabilities which are not shown on the device itself:
New hidden capabilities on power meter and battery drivers: powermeter_state_string (e.g. ‘1234 W Import’ / ‘1234 W Export’) on DTSU666 and Power Meter EMMA, and battery_state_string (e.g. ‘1234 W Charging (73%)’) on LUNA2000 Modbus and LUNA2000 EMMA Modbus. Both are fully localised and not shown in the app UI — intended for use as indicator:
Hello @Andi
It took me quite some time but at the end I’ve managed to make the app work!
At first disabling the other app didn’t work and power-cycling seemed too difficult but then, some app versions later, using the modbus scan/test tool I’ve been able to check that the connection was actually working and I therefore managed to add the devices to the app.
Now it’s working perfectly, much better than the previous app I used
Great work and thanks a lot!
Will send you some beers
![]()
Hey SFX,
Really glad you got it working in the end!
The Modbus scan/test tool was built exactly for situations like yours — it’s great to hear it made the difference.
Appreciate the kind words, and thanks for the beers — cheers! ![]()
![]()
![]()
Enjoy having all your devices running smoothly now!
Cheers,
Andi
Hi @Andi et al, been using this now for quite a while and it’s just brilliant! There is one trigger that I’ve noticed is missing, when battery storage mode changes - which it might if you’re signed up for a balancing service and want to keep track of whenever that happens. You can set battery storage working mode in the app, so hopefully a trigger can be added as well.. Thanks!
Hi, thanks for the kind words and the great suggestion! ![]()
A “Storage working mode changed” trigger is definitely a useful addition — especially for anyone on a balancing/grid service where an external system changes the mode automatically.
Technically it’s straightforward: the driver just needs to poll the working mode register on every cycle and fire the trigger when the value differs from the previous one. The action card to set the mode already writes that same register, so the plumbing is mostly there.
I’ll add it to the next release for both LUNA2000 (Modbus) and LUNA2000 (EMMA Modbus). The trigger will carry the new mode as a token (e.g. "Self-consumption", "TOU", "Full feed-in" etc.) so you can branch on it in a flow.
@micke_011 Please test the new Version and let me know if it works: Huawei FusionSolar Manager | Homey
Phenomenal service level here @Andi - installing now, testing and reporting back shortly!
@Andi new v1.4.5 update did not work well. I had to manually re-install it and after a couple of restarts it recovered
@peter7 i have reinstalled it from the homey portal (without uninstalling it) and is running since
v1.1.46 (TEST) — Stability Fix
addCapability() calls in all 12 drivers are now wrapped in a try/catch. Previously, if Homey’s API was temporarily unavailable during app startup (e.g. right after an update), the device could get stuck in an unavailable state. Now the error is logged and the device continues initialising normally — it will pick up the capability on the next restart.
This is especially relevant for users who reported devices going unavailable after updating the app without uninstalling first.
Please send me the log files or Diagnostic Reports - otherwise It’s hard to troubleshoot such issues.







