Thanks for the warning, that would have been a disaster.
Fortunately the TLS switch is next to the MODBUS enable switch. 
And I still have contact to the system via the Android app. 
Hi Andi
Really excited about your app. My device install seems to be good, all devices reporting values that look OK
My first flow did not seem to do anything though.
The system was set to “maximize self consumption” (msc) through the android fusionsolar app, but the flow did not seem to change anything when run. Is there something else I need to do?
One difference is that on Homey, msc is a parameter on the battery, in the android app, I go to the dongle parameters to toggle between msc and tou.
And out of curiosity, a ‘storage working mode’ called adaptive. What is that?
best regards,
Arnar
Hi Arnar,
Thanks — and the good news first: your install is fine, and your screenshot proves more than
it looks. Reads and writes go over the same connection and the same Modbus unit, so a flow
writing to the inverter reaches exactly the device those readings come from. Whatever is
going on, it is not addressing.
The likely cause — and you can check it in ten seconds
Your LUNA2000 device has a capability called Remote Charge/Discharge Mode. Look at what
it says right now. Huawei has two layers here, and the app exposes both:
| register | what it is | |
|---|---|---|
| Storage Working Mode | 47086 | the local mode — this is what the flow card sets |
| Remote Charge/Discharge Mode | 47589 | the layer above: Local Control, or one of five remote modes (Max Self-Consumption, Fully Fed to Grid, Time of Use, AI Control, Three-party Scheduling) |
If the second one is not “Local Control”, a remote scheduler owns the battery and the
local working mode is cosmetic. The write lands, and nothing changes — which is exactly
what you are seeing.
Your own observation is what makes me think this. You said that in the Android app you
go to the dongle parameters to switch between msc and tou, while in Homey it sits on the
battery. That difference is real, not a quirk of my app: the local working mode lives on
the inverter, and the remote-control layer sits above it. There is a fair chance that the
“maximize self consumption” you set in the app is the remote setting rather than the
local one — which would explain both the symptom and why you found it in a different place.
One log line settles it
The action cards are fire-and-forget: a flow step reports success even when the Modbus
write failed. The only place the truth appears is the app log (Homey Developer Tools →
Apps → this app). Run the flow, then look for one of these:
Write OK [luna2000_set_working_mode → reg 47086]
Write failed [luna2000_set_working_mode → reg 47086]: <message>
Write failed— the inverter refused the write. Then it is not the remote mode and
I would like to see the message.Write OK, but the Storage Working Mode capability flips back to “Maximise
Self-Consumption” on the next poll — the write arrived and was overridden. That is the
remote-control layer, confirmed.
If you could send me those three things — the value of Remote Charge/Discharge Mode,
that one log line, and whether the working mode flips back — I will know which of the two
it is.
And “Adaptive”
That is Huawei’s value 0 for register 47086, and the label is theirs rather than mine: the
app passes the manufacturer’s modes straight through instead of inventing names for them.
I do not have anything solid on what it actually does on a LUNA2000, so I would leave it
alone unless Huawei’s documentation for your firmware says otherwise.
One thing that may put it in context: Adaptive, Fixed Charge/Discharge and TOU (LG) are not
offered at all on EMMA-based systems — which suggests they are legacy or battery-specific
modes rather than something you are missing out on.
best,
Andi
Hi everyone! 
In a few days, I’ll be getting my new Huawei FusionSolar system installed, and I’m really looking forward to integrating it with Homey. I can’t wait to set everything up, create some useful Flows, and get the FusionSolar widgets running on my tablet.
Hopefully, the integration goes smoothly and everything works as expected! 
Hi again.
I was unable to find where to access the logs. My developer tools page has these:
But it seems that perhaps I was mistaken when I said nothing was happening. I was just having a hard time seeing something happen!
I noticed today that the system was set to MSC, but I was pretty sure I had left it in TOU yesterday.
So today I have done some further testing. And for a clear indicator, I set up a TOU schedule where the battery would charge at 1kW from grid. And since solar production is low, the battery would then maybe charge at 100W when on MSC. Then I did the following:
While testing, I am watching the homey output on a PC
FS is the Fusionsolar Android App
-
in FS app: changed from MSC to TOU
Result: Within 15 seconds I saw Luna2000 change from MSC to TOU
And within about a minute I saw the battery being charged @ 1kW -
in FS app: changed back to MSC
Result: Within 15 seconds Luna2000 changed from TOU to MSC
And about a minute later, Luna2000 stopped charging -
in FS app: from MSC to TOU
Result: Within 15 seconds I saw Luna2000 change from MSC to TOU
And within about a minute I saw the battery being charged @ 1kW -
in Homey Luna2000: from TOU to MSC
Result: After 67 seconds, the Luna2000 stops charging!!! -
in Homey Luna2000: from MSC to TOU
Result: Battery charges again at 1kW
So it seems all is good anyway 
Hi Andi.
After discovering this app, I am like a kid in a candystore… what to try first.
And there are a lot of cards to choose from and not always sure what do choose.
I would like to compare it to me getting access to a traffic lights control box and being afraid I might cause the cars to crash 
For example, I want to take the system from an MSC state and charge the battery, including 1500W from the grid. What is the best way to do that?
So while in MSC mode, is this enough?
or is it more like:
and does it return to MSC after the time specified?
Hope you can shed some light on this.
best regards,
Arnar
Hi Arnar,
First, an apology: I sent you to the wrong place. Homey’s Developer Tools does not show logs
for installed apps — that view only exists for apps running from a developer machine. The
way to get logs to me is More → Apps → FusionSolar → Submit App Logs in the Homey app,
which gives you a Log ID to paste into a post or issue.
But your testing made that unnecessary. Steps 4 and 5 are the answer: Homey changed the mode
and the battery stopped charging 67 seconds later, then started again. The write was always
arriving — the effect was just hard to see. Thank you for building a test where it was
visible; that was the right instinct.
One thing worth watching: you found the system on MSC when you had left it on TOU. Nothing in
this app changes the working mode on its own — only a flow card or a capability change does.
So that was either a TOU schedule in FusionSolar itself, or the FusionSolar app. Worth
knowing before you build flows on top of it.
Charging from the grid while in MSC
Short answer: your first flow is not enough, and your second does more than it needs
to. The two cards you want are:
Set charge from grid → Enable
Start charging for minutes → 1500 W, N minutes
Here is why.
“Set charge from grid” (register 47087) does not charge anything. It permits the
battery to take energy from the grid at all. Without it, everything below can only use
whatever the panels are making.
“Set grid charge power” (register 47242) is the set point a schedule uses — it sizes
grid charging for TOU. In MSC there is no schedule to execute, so setting it changes nothing
on its own. That is exactly what you observed. (You had the order right, by the way: 47242
is ignored unless 47087 is already enabled.)
“Start charging for minutes” (registers 47247, 47083, 47100) is the one that acts. It is
Huawei’s forcible-charge function: it overrides the working mode for as long as it runs,
charges at the power you give it, and the inverter’s own timer ends it — no flow of
yours has to stop it.
And to your third question: yes, it returns to MSC — because it never leaves it. Forced
charge sits on top of the working mode rather than replacing it, so when the timer expires
the battery simply carries on in MSC. That is why I would drop the “Set storage working mode
to Time of Use” card from your second flow: it is not needed, and it leaves your system in
TOU afterwards, which is the kind of thing you spend the next morning puzzling over.
If you would rather charge to a level than for a time, use “Start charging until SoC %”
instead — same idea, with register 47101 as the target.
To stop early: “Set force charge/discharge” → Stop.
Two ceilings that will silently clip you
- “Set max power charge from grid” (register 47244) is a hard cap that applies at all
times, and Huawei’s default is 2000 W. Your 1500 W fits underneath it. If you ever want
3 kW from the grid, raise this first or you will quietly get 2. - The device setting “Max charge power” (register 47075) caps forced charge too — the
card clamps your value to it rather than failing, so if that setting is below 1500 W you
will get less than you asked for with no error.
You are not going to make the cars crash. The registers that could actually misconfigure
something are the cutoff SoCs and the grid-tied power limit; charge commands are transient
and the battery falls back to its working mode on its own.
best,
Andi
FusionSolar test version, please test before it goes live
Hi all,
a new test version of the FusionSolar app is ready: Most of it is fixes and polish. Some changes affect how you work with the app and your existing flows, above all:
- the LUNA2000 forced charge/discharge cards, which were rebuilt, and
- the battery and feed-in modes, which moved from the device tile to the device settings.
Please install the test version and run your flows as soon as you can, before it goes live for everyone: 
Huawei FusionSolar Manager | Homey
Please test first
1. LUNA2000 (Modbus): forced charge/discharge rebuilt
Why: register 47246 decides whether a forced run ends after a duration or at a target SoC. No card wrote it, so every card ran in whatever mode the battery happened to be in. On a battery set to “target SoC”, “Start charging for minutes” ignored its minutes. And if writing the power or the minutes failed, the run started anyway, on old values.
Now every card writes its values, then the mode, then the start command. Each step only goes out after the one before succeeded:
| Card | Writes, in this order |
|---|---|
| Start charging / discharging for minutes | power → minutes → mode “duration” → start |
| Start charging / discharging until SoC % | target SoC → power → mode “SoC” → start |
| Stop force charge/discharge (new) | stop → clear discharge power, minutes and mode |
If a step fails, nothing starts, and the timeline says which value could not be written (“Force charge NOT started — …”).
Retired: these cards are now hidden for new flows as they are not needed anymore. Existing flows with them keep running - PLEASE REMOVE THESE CARDS FROM YOUR FLOWS
- Set force charge/discharge
- Set force charge target percentage
- Set force charge power
- Set force discharge power
Two changes for existing flows with “Set force charge/discharge”:
- “Charge” and “Discharge” now always run to the target SoC that is already set. Before, this depended on the mode the battery was in.
- “Stop” now also clears the discharge power, the minutes and the mode, so the next run starts from known values. A “Discharge” with this card afterwards needs a discharge power again, so use a start card for that.
Please test:
- Run each of your forced charge/discharge flows once. Does the battery start, run as long or as far as expected, and stop?
- With the minute cards: does it really stop after the minutes?
- If you still use the retired cards, try replacing them with the start cards and “Stop force charge/discharge”.
2. Modes moved from the device tile to the device settings
The tiles showed each mode as a scroll wheel that wrote whatever it landed on, without asking. Just opening the inverter and scrolling could switch a feed-in limit off, and for an installation whose main fuse depends on that limit, that means a house without power.
The tiles now only show the modes. You change them in the device settings:
| Device | Where in the device settings | Setting |
|---|---|---|
| LUNA2000 (Modbus) | Change battery mode | Storage working mode · Excess PV energy (Time of Use) · Remote charge/discharge mode |
| LUNA2000 (Modbus) | Peak shaving | Peak shaving |
| LUNA2000 (Modbus) | State of charge limits | Backup power SoC (%) — its tile is hidden; flows and Insights keep working |
| EMMA battery | Change battery mode | Storage working mode · Excess PV energy (Time of Use) |
| SUN2000 (Modbus) | Feed-in Power Control | Active power control mode |
- Each mode is a dropdown that lists every value and is written only when you press Save.
- A dropdown can be saved once the app has read the current value from the device. Until then the save is refused with a message, so the app never writes a default into your battery.
- The (i) next to each dropdown explains every option.
- Forced charge/discharge has no dropdown: it is a command, not a setting, and stays with the flow cards.
- Flow cards for the modes work as before.
Please test: open the device settings, change a mode, press Save, and check that the tile shows the new mode.
3. SUN2000 (Modbus): “Disable zero export” restores the previous limit
Before, “Disable zero export” always switched the inverter to Unlimited, which removed any standing feed-in limit (main fuse, 60/70 % rule) every time a flow around negative prices ran.
Now “Enable zero export” remembers the mode and limit it replaces, and “Disable zero export” puts them back: the watt limit first, then the mode. Only if nothing was remembered, for example because zero export was switched on outside Homey, does it fall back to Unlimited, and the log says so.
Please test: if you use the zero-export pair, run “enable”, then “disable”. Are the feed-in mode and limit in the inverter’s settings what they were before?
4. Two inverters or batteries of the same kind
With two devices of the same kind, for example two inverters on one dongle, an action card could act on the other device and still report success. Now every action card acts on the device chosen in the flow. Five conditions (working mode, excess PV, remote mode, inverter status, meter status) now check the chosen device too. With one device of each kind nothing changes.
Please test if you have two: does each flow act on the right device?
5. FusionSolar cloud (OpenAPI) devices
- Inverter status words are now the same as on the Modbus inverter (1.2.294), for example “On-grid” instead of “Grid-connected” and “Starting” instead of “Start”. A flow that compares the status text needs the new words. The efficiency tile is gone; Huawei always reported 100 %.
- Cloud battery status now uses the same capability as the Modbus battery, so “Battery unit status changed” and “Battery unit status is” now work for it. “Faulty” is now “Fault”, and “Hibernating” is now “Sleep mode”. A flow that used the old status as a token needs the new one.
- “Meter status changed” and “Battery unit status changed” now fire only for the status chosen in the card.
- The poll interval setting now works. Until now every plant was polled every 5 minutes, whatever was set. With 30 minutes set, you now really get updates every 30 minutes. The shortest interval of any device of the plant applies.
- Homey Energy solar now follows the inverter’s own DC energy counter, and only while the panels produce. No more solar “before sunrise”. Expect the daily figure a few per cent above FusionSolar’s, because it is measured on the DC side, before conversion losses.
6. Smaller behaviour changes
- “Set backup off-grid switch” (LUNA2000) is retired and no longer sends anything. Use “Switch to off-grid operation” instead; it only runs with its confirmation box ticked.
- Forced charge/discharge cards refuse to run when the battery’s max charge/discharge power is 0 W. Before, they assumed 5 kW.
- Inverter status now says “Standby: battery empty” instead of “Unknown (0x030c)”, and six more codes have names. This matters if a flow compares the status text.
- OCPP: “Set max charging current (OCPP)” with 0 A now pauses the session instead of being refused. “Car is plugged in” stays true while the charger reports Finishing.
- Energy management: when a meter, inverter or battery is unavailable, it now holds instead of steering on frozen values.
- Kiosk device and SDongle A: both show a warning while they are not excluded from Homey Energy, because Homey would otherwise count them twice. If you excluded the device before this version, switch “Exclude from Energy” off and on once.
New, please try
Time of Use windows in the LUNA2000 settings (1.2.307)
Device settings → Change battery mode → Charge/discharge windows (Time of Use). One line per window: start-end/days/+ or -. Days are 1 = Monday … 7 = Sunday; + means charge, - means discharge.
03:00-07:00/12345/+
03:00-07:00/67/-
07:00-23:59/1234567/-
00-03:00/1234567/-
- Written to the inverter (register 47255) when you press Save. A save replaces all windows.
- At most 14 windows, no two overlapping on the same day. A window over midnight is two lines; end the first one at 23:59, not 00:00.
- A line that does not fit refuses the save and names the line.
- The field shows what the inverter holds, including what was set in the FusionSolar app.
- The windows only apply in the working mode “Time of Use (LUNA2000)”.
- Outside the windows the battery does not discharge.
- A charge window at night charges from the grid only with “Charge battery from grid” switched on, and only up to “Grid charge cutoff SoC (%)”.
- This field is for the LUNA2000 over Modbus only. Through an EMMA, the windows are still set in the FusionSolar app.
Please test:
- Save your windows and look for
Write OK [tou_periods → reg 47255]under App Settings → Logs. - Wait a few minutes and check that the field still shows your windows.
- Does the change show up in the FusionSolar app? Please tell me either way.
Also new
- Battery settings: “Grid charge power limit (W)” and a “Peak shaving” group.
- Change log: every settings change, every action card and every change made on the device itself is kept per device across restarts, under App Settings → Logs → Changes.
- Most-used cards highlighted at the top of the card list.
- All twelve widgets reworked:
- Wrong figures fixed: self-sufficiency counted battery charging as consumption, the grid status was wrong at night, and the sensor chart’s 48 H / 72 H / 7 D ranges did not show what they said.
- They follow Homey’s widget style, and numbers appear in your dashboard language.
- Data that is no longer fresh is dimmed instead of shown as live.
Fixes and polish
- device icons render properly on the phone, and the modes have icons of their own.
- the log notes every mode change: once after each app start, and whenever the device reports a different mode.
- every device’s settings are sorted into groups (Connection first, Notifications last).
- duplicate read-only boxes removed from the battery settings. “Max grid charge power” is now “Grid charge power”, because it sets register 47242, not the limit.
- the backup power SoC is shown as a value, no longer as a second, empty battery. It is only written to the settings when it changes.
- cloud devices: a short gap no longer takes a device offline, and a device missing from the plant is marked unavailable with the reason.
- Registers tab: the EMMA’s seven energy totals can be read.
- every tooltip, in the settings and on the flow cards, was checked against the code and Huawei’s manuals. The SDongle’s Modbus port is 502; 6607 is the inverter’s WLAN access point.
- OCPP: an SCharger-22KT-S0 wired single-phase can be saved.
- cloud meter: the “Export/Import … W” line appears from the first update.
- the midnight baseline fires at midnight on both clock-change days.
- the software version is shown last on the device tile again.
- the working-mode tooltip is half as long. The excess PV cards say “in TOU mode” in their title, because the setting only takes effect there. [/details]
Thanks a lot for testing! Andi
I am thinking about connecting my charger to Homey over OCPP.
As I understand I need the installer credentials to retrive necessary information.
Will connecting Homey to the charger disconnect it from EMMA?
Hi Anders,
Good question — and worth settling before you change anything on the charger, because this step is hard to undo.
Installer access: The OCPP settings are in the charger’s local commissioning, not in the normal owner view: FusionSolar → Services → Commission Device → connect to the charger’s WLAN → log in with the charger’s installer password. If your installer set the charger up and changed that password, you’ll need them for this step, or ask them to enter the values for you. The values are shown when you add the Smart Charger (OCPP) device in Homey: Homey’s IP address as domain name, a Station ID of your choice as path, port 8887.
Firmware: OCPP needs charger firmware V100R023C10SPC220 or newer. SPC231 is reported to fix several OCPP issues, so I’d update first.
EMMA: Huawei’s documentation doesn’t say, as far as I could find. But one owner reports that once OCPP is configured on the charger, the EMMA’s PV surplus charging stops working, and the only way back is a factory reset of the charger — the firmware can’t be downgraded either. I couldn’t verify whether the charger still shows its data in FusionSolar afterwards.
So in practice: with OCPP, Homey takes over the charging control rather than sharing it with the EMMA. The app’s Energy Management System device can then do the surplus charging the EMMA did before (plus price windows, battery protection and a grid limit), but I wouldn’t plan on having both.
If you only want to see the charger in Homey without touching its configuration, the Smart Charger (EMMA Modbus) device reads it through the EMMA. It is read-only, but it leaves the charger exactly as it is.
Here are some screenshots how it looks like: [BUG] Smart Charger connecting · Issue #27 · andiwirz/com.huawei.fusionsolar
Thanks for the info, it was very good to know.
Maybe I will stick to MODBUS, even if it would be nice to be able to control the charger.
But not worth the risk.
If still interested, you’ll find more information here: smart-charger-ocpp
Thanks!
