Inteference with 'TimeMode' schedules

[DeveloperRob]

Good Afternoon all,

Last week, I installed an Elfin EW11A adapter to my AC1-5-E (G1) inverter; to be able to monitor/control it via Home Assistant. I also made the silly mistake of at the same time installing an extra battery and updating the main/master/battery firmwares (which means the issues I am having are much harder to pin to a particular cause).

Since doing all of the above, I have been having some strange behaviour with the scheduler (the 8-slot time version) functionality of the inverter. I have a personal template set up to match the times for Octopus Cosy (two force charge windows). While the work mode and min SoC always changes correctly, However the inverter changing from 'normal' to 'force charge' isn't working correctly, such as reaching 100% charge and then defaulting to the normal (self-use) behaviour; or only charging at the full rate for 20-60 minutes. I can confirm the schedule is being actioned, as I have set it to a min SoC of 100% during the time slot and when it stops charging at the full inverter capacity, it drops to charging at 1kwh (the same as when it drops a certain percentage under the min SoC during the day).

Earlier today, I unplugged the Elfin adapter, and during the force charge window this afternoon (13:00 - 16:00 BST), it quite happily charged at 5kwh until at 100% SoC and then maintained the battery at 100% until 16:00.

I'll continue to monitor to see if it continues to behaviour with the adapter not connected overnight, and if it works correctly I'll reconnect it and see if it then misbehaves again. If it does:

• Does anyone have any idea what the issue might be? I have done a search but not seen anything similar
• If not, does anyone have any suggestions for debugging the issue?

One potentially important point is that the WiFi signal isn't particularly strong in the loft, and the adapter has dropped off the wifi sometimes. This might be part of the root cause (and I am waiting on some kit to extend the WiFi signal); however I would still like to get a resolution that means if WiFi drops out, the inverter doesn't then misbehave.

Thanks,
Robert

[FozzieUK]

If you haven't added any automation to your home assistant that sets charge periods, minsocs etc.. then the integration should only be reading the registers, so you can probably rule out the modbus integration as being involved but lets go one step at a time.

The first thing is to double check you haven't added any home assistant automations, and you aren't changing the work modes or charge periods, also you haven't installed Nathan's Energy Management integration (which does change minsoc and charge period settings).

It would be useful if you could post what your current Inverter firmware versions are (Master & Slave), also which batteries you have along with their current firmware Master/Slave versions as well.

And which version of the Foxess Modbus integration you have installed.

As the Elfin is disconnected at the moment, probably best to leave it that way for 24 hours and double check that your schedules are doing what you expect them to be doing - after that if you re-connect the Elfin and again monitor it for 24 hours to confirm the behaviour.

[DeveloperRob]

Hey FozzieUK,

If you haven't added any automation to your home assistant that sets charge periods, minsocs etc.. then the integration should only be reading the registers, so you can probably rule out the modbus integration as being involved but lets go one step at a time.
The first thing is to double check you haven't added any home assistant automations, and you aren't changing the work modes or charge periods, also you haven't installed Nathan's Energy Management integration (which does change minsoc and charge period settings).

I haven't added anything on that nature yet. The only related integration I have is the FoxESS Cloud integration enabled still (v0.39).

It would be useful if you could post what your current Inverter firmware versions are (Master & Slave), also which batteries you have along with their current firmware Master/Slave versions as well.
Inverter
Master: 1.64
Slave: 1.02
Manager: 1.71

Batteries (4x HV2600 v2)
Master: 1.011
Slave: 1.10
These are not the very latest versions, but currently while I was able to update the batteries to 1.10, updating the batteries to 1.15 or the master to 1.013 fails with the error 'failed 41206' at the moment.

And which version of the Foxess Modbus integration you have installed.
v1.10.1 (via HACS as opposed to by direct download / upload)

As the Elfin is disconnected at the moment, probably best to leave it that way for 24 hours and double check that your schedules are doing what you expect them to be doing - after that if you re-connect the Elfin and again monitor it for 24 hours to confirm the behaviour.
Aye - this makes sense. I'll report back tomorrow morning on if the scheduled behaved as expected overnight.

Thanks for your help so far :)

[FozzieUK]

Ok, thanks for confirming that - the cloud integration is read only to the Fox OpenAPI so we can eliminate that and without any automations you aren’t writing to the inverter. 👍

Inverter firmware versions are all the latest. 👍

On your batteries the HV2600V2 slave version 1.15 is (despite the v2 name) meant for V1 packs when used in a mixed pack system, so the latest slave(BMU) is correct at 1.10 👍

So just the Master(BCU) that would benefit from being on 1.013 if it will let you do it.

The v1.10.1 integration is the latest ‘clean’ release; it does contain force charge/discharge via work mode, which are different to the cloud schedules as they aren't accessible over modbus - the integration manages the remote control registers to implement these ‘work modes’ (I can’t see why that would interact but lets keep an open mind on that for now)

See how it goes overnight with it disconnected, and assuming it’s all ok tomorrow, then re-connect it, but keep a close eye on it and post back how it’s going.

[DeveloperRob]

Hey @FozzieUK,

As well as carrying out the above, I have done some further tests and found the cause of the issue.

First of all - thanks for confirming on the 1.15 battery firmware; I missed it specified V1 in the filename. I was able to upgrade the BCU to 1.013, so everything is now on the latest firmware.

The core issue is that the invertor's time-based force charge /force discharge) is interrupted by the inverter losing WiFi signal OR HomeAssistant restarting. I can now replicate this at will, if I wait for one of the force charge time slots, and then restart home assistant, at the point that everything is resumed the inverter changes to its normal work mode behaviour instead of force charge. Turning off the Pi running home assistant, and disconnecting the Elfin from the WiFi / reconnecting it causes no issues.

Setting to capture debug logs and then reviewing them, the only register write is below. Importantly, I have copied from one of the ones where I cut WiFI to device (although this was outside of a force charge window - I wanted to test if it would affect the next window; which it doesn't:

2024-04-10 16:04:34.443 INFO (MainThread) [custom_components.foxess_modbus.modbus_controller] tcp://192.168.1.232:502 247 - poll succeeded: now connected
2024-04-10 16:04:34.454 DEBUG (MainThread) [custom_components.foxess_modbus.modbus_controller] Writing registers for tcp://192.168.1.232:502 247: (44000, [0])

The first info message is caused by modbus_controller.py:314, when the integration has been disconnected and now is connected. Importantly, this calls self._notify_is_connected_changed(is_connected=True), which in turn calls await self._remote_control_manager.became_connected_callback(). This sets self._remote_control_enabled = None which triggers the write. The same write occurs on initial home assistant boot/load.

---

From the above chain, my suspicion is that setting 44000 to 0 is stopping the in progress force charge/discharge. Using the developer tools to manually write to the register confirms it. Manually sending a 1 seems to restart it; although I will need to wait until outside the normal time window to double check if sending a 1 to 44000 would start the last action it was running or not. I'll provide a further update then.

Thanks,
Robert

[FozzieUK]

Great, that’s a nice bit of debugging, thanks 👍

I did wonder if it may have been something to do with this - the question now is how to handle it, we’re going to need @canton7 for this - Antony, looks like remote_enable being reset at startup or re-connection is breaking any currently running ‘web based‘ schedules (exacerbated here as the wifi signal isn’t good to the Elfin so it happens more often).

@DeveloperRob for now if you drop back to version v1.9.0 this behaviour should stop as the 44xxx remote control registers were only introduced in v1.10.x - you won’t get any kind of remote control (force discharge/charge) in that version, but you should be safely able to run schedules and modbus together.

[DeveloperRob]

Just tested now I am out of my charge window; and writing 1 to register 44000 doesn't do anything once the web-based schedule has completed - so at least where the modbus remote control isn't in use, it seems it can be safe to set up an automation that resends 1 if SoC is higher/lower than expected AND battery charge is the opposite of what is expected / less than expected.

[canton7]

Oh interesting. So charge windows actually set the remote control registers. I hadn't realised that.

Yes we can be a bit smarter here, and be more sympathetic to what state the inverter's in.

See #588.