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.
The root cause: max_charge_power is stored as a device setting, not a capability, so there was no flow card to read its current value directly. Your logic condition was comparing against a Homey variable (which you’d set to 10500 manually), but nothing in the app ever updated that variable back to 0 after the action ran — so the condition always saw 10500 and kept re-triggering.
Fix in 1.1.79 (TEST): two new condition cards for the Luna2000 Modbus device:
- “Max charge power is above [threshold] W”
- “Max charge power is below [threshold] W”
These read directly from the synced register 47075 value, so they always reflect what the inverter actually has.
How to update your flow: Replace the Homey variable comparison with:
IF Max charge power is NOT below 1 W → Set max charge power to 0
The “below 1” threshold is the idiomatic check for “has it already been zeroed?” — since the inverter’s minimum is 1 W, anything ≥ 1 means the limit is still active.
Could you please let me know if it works for you?
I did a temp solution when i noticed the problem. But yes ill test the new cards.
// Teddy
Hi @Andi
When i use the start discharge with xxx W until xx%
For some reason when i check in fusionsolar app it have set to discharge for 10 min instead.
// Teddy
Hi Teddy,
Thanks for reporting this — The bug is confirmed and already fixed.
Root cause: The flow action “Start force discharge until X%” was writing the target SOC to register 47101 — but that register is “Force Charge Target SOC” only. When the inverter is in discharge mode, Huawei firmware interprets register 47101 as a duration in minutes instead. So setting 10% would result in the firmware seeing “10 minutes” of discharge.
Fix: The discharge cutoff SOC is now correctly written to register 47082 (Discharge Cutoff Capacity), which is what Huawei actually uses to stop the discharge at the target SoC. This will be available in the next app update (v1.1.82).
Andi
Well the problem is i use that card in 2 diff flows and both fail. One discharge to 50% and the other to 2% both set it to 10 min. Looks like it did that this morning again when it was supposed todo the 2% soc target discharge. Running latest test version. 1.1.83 going to be more vigilant this evening when it run the 50% one. Ill send you a diag on it right after should be starting between 19-20 this evening based on the price table for SE4 and the other requirement conditions in the flow for it to trigger.
Hey @Andi
Well i found out what happens. It does a timeout on the flowcard. Check the diag at 19:30. The one at 19:41 is me running the flow manualy you will probably see a object error.
// Teddy
Hi Teddy. I ran a flow today to charge my Luna2000 to a specific percentage using a 5000 W setpoint, and it worked perfectly.
The timeout issue appears to be resolved after updating to the latest TEST version: Huawei FusionSolar Manager | Homey
New Test Version v1.1.93
EMS — Energy Management System Driver
Automatic solar-surplus optimisation for EV chargers, heat pumps, boilers, pool pumps & home batteries — fully Flow-based, fully configurable.
What is it?
The EMS is a new virtual device type in the FusionSolar for Homey app that acts as the brain between your solar installation and your energy consumers. It reads solar production, battery state of charge, and grid power every 15 seconds and decides which devices should run — without ever pulling energy from the grid or draining the battery below the minimum you configure.
The key design principle: the EMS never sends direct commands to your devices. Instead, it fires Homey Flow trigger cards which you link to whichever device app you use. This makes it compatible with virtually any charger, heat pump, or smart switch brand already installed.
What’s implemented
Automatic surplus optimisation
EV Charger — continuous current control
Adjusts charge current 6–16 A every 15 s (1- or 3-phase) to match available solar surplus. An anti-oscillation filter prevents rapid ramping. Supports multiple chargers in priority order.
Heat Pump — on/off solar control
Starts the heat pump when solar surplus exceeds a configurable threshold, stops it when the battery needs priority. Measured power (W) is used for anti-oscillation on stop.
Boiler & Pool Pump — same logic, separate controls
Independent start/stop trigger cards for boiler and pool pump. Each follows the same surplus-first, battery-min logic with the same anti-oscillation protection.
Home Battery — Min SOC & SOC triggers
All EMS optimisations pause when any battery drops below the configured minimum SOC. Two SOC-level trigger cards fire automatically:
EMS: battery is fullEMS: battery is low
Priority order — configurable
Define which consumer gets solar surplus first. Example: EV charger → heat pump → boiler. Lower-priority devices only receive what remains after higher-priority ones are satisfied.
Off-peak charging
EV chargers charge at full power during cheap overnight tariff windows, independent of solar surplus. Configure start/end time and optional separate weekend schedule.
Potential — not yet implemented
The current implementation covers the main solar-surplus use cases. There are several natural extensions that could make the EMS even more powerful:
- Time-of-Use (TOU) battery scheduling — auto force-charge at cheap tariffs, auto discharge at expensive hours (direct integration without manual flows)
- Dynamic export limits — automatically set inverter feed-in limit based on grid tariff or surplus, avoiding export penalties
- Battery-to-EV coordination — use battery SOC as a condition to enable/disable EV charging, beyond the simple min-SOC pause
- Washing machine / dishwasher start delay — delay appliance start until enough solar surplus is available
- Multi-phase load balancing — dynamic phase assignment for 3-phase chargers based on house load imbalance
- Forecast-based pre-charging — integrate with a PV forecast API to pre-charge the battery before a cloudy day
- Support for non-Huawei batteries and inverters via generic capability mapping
How to try it
Test version — not yet on the stable channel.
The EMS is available now in the test / beta channel of the FusionSolar app. Install via the Homey App Store test link: Huawei FusionSolar Manager | Homey
After installation, add an EMS device, open its settings, assign your devices, click ✓ Create / Update Flows in each section (if needed!), and link the generated flows to your devices in the Homey app.
Feedback welcome
The EMS is actively developed. If you run into issues, have ideas for additional use cases, or want to share how you’ve set up your flows — please reply below. Every setup is slightly different and real-world feedback directly shapes what gets built next.
Awesome. Would mean i can stop doing it “manually” in fusionsolar app again. Ill see how it goes in the new version.
// Teddy
