Please provide a Diagnostic report. based on the screenshots it’s not possible to diagnose the issue.
Here you go:
9ad48ecc-9c61-4e46-a78b-22a117b71f27
Hi,
Thanks for sharing the log — this makes the problem very clear.
The app itself is working fine. The error you’re seeing is a network problem, not a Modbus or app issue:
Socket error: connect EHOSTUNREACH 192.168.1.152:502
EHOSTUNREACH means your Homey cannot reach the device at IP address 192.168.1.152 — the network has no route to it. Looking at the log, the device actually became unreachable shortly after the 18:14 restart and has been failing on every poll since then.
Thank you so much for the explanation! We had a brief power outage at my place today, and the SDongle was assigned the IP address 192.168.1.154. I completely missed that. I’ve now set up a static IP address for it on my router so this error won’t happen again. Thanks once again!
Smart Charger OCPP Driver integration testing
@yeshim or anyone using a Huawei Smart Charger: I’m looking for a few testers who’d like to try out some new features. Happy to have you onboard if you’re interested.
TEST: Huawei FusionSolar Manager | Homey
Good catch! Here’s the breakdown:
Modbus, EMMA Modbus, OCPP — completely unaffected. These run locally and have no dependency on Huawei’s cloud.
OpenAPI — the Northbound API endpoint will move to openapi.monitor.energyorb.com. Our app has a configurable Server URL field, so you can update it manually. Existing credentials (username + system code) should continue to work. The transition period runs until 15 November 2026, so there’s no rush, but I’ll test API compatibility after 15 July and release an update with the new default URL if everything is compatible.
Kiosk — Kiosk URLs will need to be regenerated from the new EnergyOrb Europe app after the transition. The Kiosk driver itself won’t need any code changes.
Bottom line: if you’re using Modbus you’re completely fine. If you’re using OpenAPI, expect a one-time Server URL update sometime before November.
Had something happening today. The app seam to have stopped wanting to set reg 47075 (modbus) Luna2000 S2 among other things. I had to restart the app a couple of times before it could set it. Every restart it reread the old 0 value. After restart 3 it decided to take the new value. Looks like something happened after my flow this morning was supposed to “empty” the batteri as a reset for the day. It didnt take the discharge flow card untill %. I did however upgrade the inverter and the sdongle the other day. Could be related. Anyone had simular problem? Going to keep an eye on it the comming days if it happens again ill trigger a diag before restart. If my memory aint wrong aint the reg value synced every 5 polls @Andi? Because it seam to not have done it in this case sins the changed value froze but i gues the reading dont override writing in the poll que?
// Teddy
Yes, control registers are read every 5 polls — and yes, that read overwrites the Homey-side value if the hardware returns something different.
What the code does:
- The main poll (
_fetchAndUpdate) runs on your configured interval and reads live battery data (SoC, power, etc.) - Every 5th main poll,
_fetchControlalso runs and reads the control registers: working mode, force charge/discharge, max charge power (reg 47075), discharge cutoff, etc. — then syncs those values back into Homey settings and capabilities. - During any write,
_writeInProgress = trueblocks the main poll from starting so reads and writes don’t collide. But once the write finishes, the next 5th-poll control read will read back whatever the hardware reports.
The behaviour you saw could be a firmware-update side-effect.
I had similar issues the last time I did an update. Some values were totally wrong for some hours.
For the future: If it happens again and you catch it before restarting, wait one full poll cycle and check if the value recovers on its own (5 polls × your interval). If it doesn’t recover after 2–3 sync cycles, then the hardware actually rejected the value rather than just temporarily reverting it.
Yea could be related to firmware and possibly point 3 in your list there maybe. It was supposed to have done the reset between 5-9 this morning depending on varius diff things. It did trigger on-grid and so on and i did get the emptying timeline message i have in the flow but it didnt do anything and considering i didnt notice it untill lunch today around 12-13 when i tried to surcomvent the flow and then the restarts it should have done a ton off 5 poll syncs between 8 and 12 ish. But ill keep an eye on it and see if it happens again. Huawei wont release a new fw for a litle while so could be a one off.
// Teddy
Found a bug it seam @Andi. As you know i have a reset cycle function for my batteri in a flow every morning. I have been somewhat complexed why it stopped doing what it is supposed to. It turns out the logical check against max change power isnt containing the correct value. There is a 15 min cycle where it checks a bunch of stuff and if they meet the right criterias it sets the max charge power to 0 and it do reflect this in the luna modbus device correctly. However the flow card variable for it remain the standard 10500 that i normaly have it set to. Wish cause the logic card to always think it is 10500 and as such trigger the set max charge power (0) card every time thinking it havent been set to 0.
