Unfortunately still the same behavior:
54b17a16-b8f9-47ff-b6de-177785d7413a
New one incomming.
The problem is that in force mode (any) the marstek has a timer that start to count down and safeguards itself by shutting the force mode down. In case the modbus controller (homey) became disconnected. I had a âbugâ before that I kept spamming the marstek with our state, but it kept the control mode alive. I fixed that bug but now this timer is cause this bevaior by design. SO I need to figure out ho to kick the timer back without spamming the device again.
But new attemot, I build in a keep alive monitoring service that should recover a wrong state from code, similar to your flow but hopefully faster.
Thanks again! First observations (will try again tomorrow)
I have a part where the charging was interrupted again, but also a part where it continued as it should. Will test again tomorrow afternoon.
Still the same 
I only use the âset powerâ-card when the target has changed, which it didnât in this timeframe.
In your app settings, I tried to check the âdevice state dumpâ, but I get this result:
Error: connect ECONNREFUSED 10.0.0.110:502
Work mode event buffer:
[
{
âseqâ: 1,
âtsâ: â2026-06-01T18:01:53.238Zâ,
âtypeâ: âforce_revert_detectedâ,
âexpectedâ: 2,
âobservedâ: 0,
âage_msâ: 3686325
},
{
âseqâ: 2,
âtsâ: â2026-06-01T18:01:53.538Zâ,
âtypeâ: âforce_recoveredâ,
âreassertedâ: 2,
âmodeâ: âtarget_powerâ,
âregisterâ: 42010
},
{
âseqâ: 3,
âtsâ: â2026-06-02T04:57:07.097Zâ,
âtypeâ: âforce_revert_detectedâ,
âexpectedâ: 0,
âobservedâ: 0,
âage_msâ: 151
},
{
âseqâ: 4,
âtsâ: â2026-06-02T10:29:52.175Zâ,
âtypeâ: âforce_revert_detectedâ,
âexpectedâ: 1,
âobservedâ: 0,
âage_msâ: 889909
},
{
âseqâ: 5,
âtsâ: â2026-06-02T10:29:52.476Zâ,
âtypeâ: âforce_recoveredâ,
âreassertedâ: 1,
âmodeâ: âtarget_powerâ,
âregisterâ: 42010
}
]
Diagnostics: 57cb6ba5-d620-4acf-906e-b4c2c98000d2
Is there anything else I can do to help? And you still wonât accept a beer 
?
New test version ready for tomorrow, the recovery process now monitors more values.
I dont want to accept gifts because they can stack to the level it becomes a taxable income.
Version .10 is not stable. It often fails to fetch the data, and it also fails to set target power. Restoring the last stable app version worked, and after trying .10 again it resulted in the same errors.
3e12a8a3-c906-4ae5-a718-b057e95f1d05
Immediately after restoring version 1.3.6 the device becomes unavailable again:
9207f052-2a1c-4df6-8992-dd3e8cbc6b24
It also started charging at 1.5 kW, which was not instructed. After resetting some stuff it went back to normal.
Here also connection problems with latest test version. No data from Venus e3.
Installing version 1.3.6 didnât help. I restarted Homey pro, no luck. Data in app isnât refreshing, is from yesterday I think.
Update: after a while data is refreshed.
Installed version 1.3.11, app doesnât get data from and to the battery. When changing charge status a time out received.
Diag: a51617f5-c28a-482c-8b27-1f6a318bac69
Sorry if not nescessary.
OK it seems the protection for reverting to 0 by the demon in the battery is overloading the modbus on some devices. How did you both connect? V3 with modbus over utp? Or using a gateway on the modbus port? Like the v2 I have only supports?
I also see the problems now in 1.3.6. Modbus over UTP on Venus D. Just connected solar panels directly to the Venus D. Might be a coincidence, but 1.3.6 has been stable before.
bffca38b-badf-482c-9550-2bc3f43323b4
If you canât see anything in the diagnostics, I can try to unplug the PV to check if that caused the issue.
Edit: it took a while, but now it works again. I didnât do anything.
But I donât see anything PV-related in the modbus capabilities. The charging power is exactly the same as the grid output. Is there a way to get the PV-measurements?
I have a new version on the test, if this doesnt work stable we revert back to .6 altogether.
@TKroon I dot have de registers for those values, so I dont know
How can I retrieve those registers?
Find documentation that lists them, Marstek isnt that open so far. People have been polling registers (can be done in my test page) to see if they match their vales to confirm. But some are multi register etc. so⊠reverse engineering or good online searches
I use V3 over modbus over utp. I will try the new version
After installation I waited a while. Tried to change charge modus: time out.
I made a diag: 9aac84fb-31e7-4103-83cf-1fe5af227284
Update 10:32: reverted back to 1.3.6, communication works again, data updated from battery.
Started using this integration yesterday to optimize battery activity by writing strategy code myself. So far works great!
Today I also noticed some unexpected power dips as seen in previous posts. I am running 1.3.6 of the app. I also noticed in the message window of the batteries there are a lot of battery idle, battery active messages while I am just setting tragetPower of the batteries. Is this the same issue with the keepalive / watchdog function? Or am I doing something wrong?
Same issue, you can try the test version. I am still trying to figure out why this happens with some models
Understood. If there is anything I can do to provide additional information or testing please let me know 
I put a new test version up, it has device settings to disable to guard alltogether if it keeps cause timeouts, and you cna reduce the guard check speed, turn it down until your connection is stabel, will increase the time your device might hang on 0.
Lets see if that solves your problems
Yesterday I ran into a issue where a accidentally pulled the power to the switch where te batteries were connected to. This is where everything went worng for some reason. The batteries worked fine on a dynamic EMS control for 36 hours but after this power cut of the switch I had massive issues getting everything back online.
Looked like I the app is able to connect to the Modbus server of the battery as it did not show any connection errors but all values remained old ones. So Modbus polling did not appear to be active. Eventually I got it back working after restarting everything multiple times.
This mornign when instelling the new test version of the app the same seemed to be going on. Batteries seem to be online but no new values en no control. When I tried to use a tool like Modbus poll the batteries appear to be funtional and responsive.
If you need any more information I am happy to provide
