…while charging/discharging/idling completely normally the whole time. Stijn’s list above has a couple of extra bits (Hardware Trans Overcurrent, High Voltage Bus Overvoltage/Undervoltage) that mine doesn’t - looks like it could be a range of adjacent alarm-bitmask registers rather than just one, which combined with Stijn’s “IllegalDataAddress” points more toward a register misread than an actual hardware fault. Both our batteries keep working fine physically the whole time, which is hard to reconcile with a real overvoltage/overcurrent condition firing continuously.
Current settings on b2/b3: Poll Interval 10000ms (raised from default 5000ms per your earlier advice in this thread), Force Mode Delay 1000ms, Connection Timeout 5000ms, Max Errors Before Unavailable 6.
Since this is showing up on two different gateway types (EW11 and DR134) it seems like it’s probably on the app/register-mapping side rather than a specific-hardware-adapter issue.
Happy to send a diagnostic report from b2 and/or b3 if useful - let me know what would help.
Marstek has this annoying thing that they release minor changes to their modbus register use between devices and versions. So it is probably that for those FW those registers are no longer alarms or something like that.
Ill give a short research
Please use the settings page of the app (do this for each of your batteries)
read register 36000/36100/36101/36102/36103/36104
Please report the hex values it returns, and let me know what battery refers to what data set
Update on Test (will publish if no issues)
Vensu E: For V3 skip hardware fault detection registers and clear warnings
Venus D: rewire all regiters as they where know to work before the 149 firmware.
Here are the register reads you asked for. All three batteries are Venus E (not Venus D):
Dataset A - b1: VenusE 2.0, firmware V158.1 - does NOT show the alarm
Dataset B - b2: Venus 3.0, firmware V149 - shows the continuous alarm
Dataset C - b3: VenusE 3.0-newest, firmware V149 - shows the continuous alarm (identical hardware/firmware to b2)
Register
b1 (V158.1, no alarm)
b2 & b3 (V149, alarm)
36000
0x0000
0x0000
36100
0x0000
0x0000
36101
0x0000
0x0000
36102
0x0000
0x0000
36103
0x0000
0x0940 (2368)
36104
Illegal data address (exc 2)
Illegal data address (exc 2)
b2 and b3 returned identical values, so I’ve merged them into one column.
Two things stand out:
Register 36103 is the only difference between the alarming and non-alarming batteries: 0x0000 on b1 (which never alarms) vs 0x0940 on both V149 units (which alarm continuously). 0x0940 = bits 6, 8 and 11 set - which would line up with the app reporting several alarms at once (Hardware Bus Overvoltage, Output Overcurrent, Inverter Soft Start Timeout, etc.) even though the batteries are charging/discharging/idling completely normally the whole time. So it looks like on V149, whatever 36103 now holds is being interpreted as an alarm bitmask when it probably isn’t one anymore - matching your note about Marstek shifting register meanings between firmware versions.
Register 36104 returns Illegal data address (Modbus exception 2) on all three batteries, including b1. So that register doesn’t seem to exist on any of my firmware. This is the same exception another user (Stijn) reported.
Note: on the very first read of 36000 on b1 I got a single ‘Timeout after 10000ms’, but a re-read returned 0x0000 cleanly, so that was just a transient.
Let me know if you’d like me to read any other registers, or send a diagnostic report.
I have major issues with both 3.0 Venus E freezing randomly. I have flow to force them to the Homey control ~30s. Then separate flow setting the power for each of them with variable what I have made the program scripts. I use DR134 to Marstek RS485 with ethernet cable.
Any suggestions how to keep properly the Venus E 3.0 alive, not freezing to some output or zero? They can be full or half empty, it seems not to matter.
I try to solve this with faster flow: Force Homey mode for all of them like 1s apart: 27s, 28s, 29s. Let’s see!
This is very much the issue that was reported earlier, seems to be a firmware issue, I tried to build this type of recovery in, but that got us to hanging and failing communication.
So the unstable version of the last month where exactly my attempts to bypass the drop to 0 problems people are getting with latest firmwares
So what you can try is this:
To confirm its not my app causing this, disable the app and see if the behavior in these modes conitunes.
If that is the case it is the same bug as the @TKroon up this thread.
If the issue stops then we can investigate again.
But it seems like the new firmwares are cause freezes even on the operation side just like they dont respond on the UTP side anymore cause errors on our side.
@Marko_Alanko and if you spot a freeze, please create a diagnostic report for me, I want to see what we read during those freezes.
I was a bit too quick to judge; it’s working again now, 40 minutes after the update. I was probably a bit hasty, given that the previous update had caused it to stop working. Thanks for your quick response and your work on this great app.
Version update 1.5.8 breaks my 3x Venus E V3 monitoring. V1.5.7 was working well but the automatic update to 1.5.8 today seems to work a few seconds (showing accu percentage etc.) and then it falls back to “Onbeschikbaar”.. whatever I do (reboot HomeyPro 2018, restart app) nothing works. Pls help and get me back the previous version.
Miraculously after a long time they’ve re-appeared in HomeyPro one by one… at the moment they seem to be working again. (Be advised they are connected through Ethernet so it can’t be a bad WiFi signal connecting to HomeyPro/CT/LAN). L3 battery shows “OFF” in Homey while it actually is “ON” and working in “0-op de meter/Zelfconsumptie” modus according to the control panel/Marstek android app. I manually switched to ON in Homey and checked on premises that it stays on. Apparantly the readings in Homey may appear incorrect.
the On/Off is a virtual capability primairly based on active modes. So I use self written logic to conclude of it is on or off to make it more aligned to the Homey control modes.
Its weird, your the second that it took some time after a new install for them to show up.
I must say I’m pleased that your app is there to keep an eye on the batteries as the Marstek Android app is a disaster: It does not show reliable statistics or no statistics at all. I use your app to register the daily “Laad/ontlaad” numbers. After about 45 minutes 1 came up, 10 minutes later the 2nd and another 12 minutes later the 3rd one… I guess I must be more patient. Overall I’m happy with it so keep up the good work
Hi Kaoh! I’ve been busy with my Waveshare RS485 to ethernet to check the registers for the Marstek Venus D. This is a working configuration. Please note that I use positive values when the Marstek charges and negative values when the Marstek discharges.
Edit: one correction: AC POWER is now inverted and the DC POWER calculation is changes from - AC to + AC
Thanks, ill rewrok them in the venus d driver. But it surprises me that there also already a high match on the ones I am reading in that driver.
DId you try the current version with the waveshare also? Because it starts to look to me that the D UTP modbuss support is just broken while the serial → waveshare clearly gives better results.
But expect a version with the gaps (solar parts etc) on test
No I didn’t try the newest version. I’ve been testing with the waveshare for the last couple of days, which replaced the only available UTP connection When I have some spare time I will try the (future) latest version. Might be after the holidays.
One thing to note: I’m still experiencing the 0W drops and those are more frequent. But way shorter. Only with a nearly full battery (98%+) the power is stable.
Blue is target power. Magenta is actual power (negative = discharge). The first part is a full battery with excess solar power. At 19:49 the frequent drops of power occur again. I still have no clue why and will ask Marstek. I have detailed proof that it’s not due to my own settings. I’ve tried CT + Self Consumption, local api, manual mode, modbus over UTP, modbus via the RS485 port and on any mode I see the power-drops in a different form.
Is there anybode else here with Venus D with PV connected?
When I have some spare time I will try the (future) latest version. Might be after the holidays.
