Venus 3.0 Local API turns off

[bertsmelik]

I have 2 Venus 3.0 firmware v144. Tested on one with local API and this integration and that worked well.
So I joined the second Venus 3.0 (also v144). Now the second one works for some time, and then turns off Local API by itself. Sofar this occurs one a day.
I turn on charging with a script setting the Venus to Passive mode with power -2500, then return to Auto by a push button script.

Today I saw in the script traces the error at 13:15 (when charging should start)

Error: Failed to set passive mode: Device rejected passive mode configuration (power=-2500W, duration=14400s)

I seems that after that Local API has turned off and the battery can no longer be seen by the integration.

The first Venus works without problems.
Has anybody else here seen this problem and, hopefully, knows how to fix this?

[schauveau]

Same issue for me. During the last 24h, the Local API as turned off and the CT was disconnected 3 times on my Venus E with firmware 144.

While playing with the local api, I also noticed that a few requests fail with error -32700 Parse Error:

{
	"id":	0,
	"src":	"VenusE 3.0-bc2a33601ff9",
	"error":	{
		"code":	-32700,
		"message":	"Parse error",
		"data":	403
	}
}

My test script always send the same ES.GetStatus request {"id":11,"method":"ES.GetStatus","params":{"id":0}} with an increasing id number so a parsing error is quite unexpected. A short UDP request like that one can be lost but it should not be corrupted. There is definitely something wrong in their local api implementation.

As a side note, I also noticed that after sending an empty request (0 bytes), the local api stops responding to any further requests. In the Marstek app, the Local API is still marked as enabled but turning it OFF and ON is enough to make it work again.

[schauveau]

I just noticed that most of the settings are also lost (CT, Local Api, Power 800/2500, DOD, ...), when I turn the battery OFF and ON using the power button (about 3s).

The user manual does not describe the power button behavior. Is it supposed to reset the settings like that?

[bertsmelik]

Meanwhile Marstek pushed V146-111 to both which I installed. Problem still remains and I got a new problem: Venus does not discharge when running in "Auto" mode (nul op de meter).
Marstek support advised to power down and disconnect for approx. 4 hours. That is taking place right now.

[schauveau]

I just switched from WiFi to RJ45. My test script has been running for about 20 minutes and does not show any missing or Parse Error responses after hundreds of UDP requests.
I willreactivate the Marstek integration to see if that is enough to solve the problem.

[schauveau]

Switching to RJ45 did not help. The UDP connection was obviously a lot better but it failed after a few hours.

I will try modbus. The Venus 3 can do it on port 502. I already have a small python script that can successfully read some registers.

[ShodanOne]

I’m using this project for my own integration (Jeedom). I’m only using the api.py class in a similar way as it is done in test_tool.py.
In my integration, the polling sequence is different :

• every cycle : es.mode
• every 3 cycles : bat.status
• every 5 cycles : em. Status and pv.status (if applicable)
• every 10 cycles : es.status
  I do not poll WiFi.status and ble.status, I just get it once at battery discovery.

My battery is a Venus E 3.0, on firmware 146.116.110, comm module is at 202506241541.
My CT is a Shelly pro 3EM, both the Shelly and battery are connected using WiFi.

I was facing a lot of battery crash too (loosing CT, going to manual & idle, disconnecting API).
After upgrading to this fw and an on/off of the battery, things seems better now. My plugin is working since 5 days in a row without any crash of the battery.

My polling period is currently 15sec, with a timeout of 3sec and 3 retry max.

EDIT : Battery just crashed after 6 days, and now keep crashing after a few time when polling through local api …

[notz]

Also happens to Venus A with FW Version 144.

Switching off for 4 Hours only helped for one day.

I don't know exactly when this issue was introduced. Either it was v144 or it is my script that is switching operation mode.

I use passive mode for charging, auto for discharge and in-between manual mode.

Are you all using the passive mode for charging? Since it mostly happens over night, it may be related to that.

[schauveau]

I switched to https://github.com/fonske/MarstekVenusV3-modbus-TCP-IP.

Everything works out of the box except for a small issue with some select entities for which I already have a solution (see my ticket fonske/MarstekVenusV3-modbus-TCP-IP#6 )

I only tried it with RJ45 but since this is using TCP-IP I assume that it also works with WiFi.

I might try the local api in a few month after they solve the bugs but so far that alternative using ModbusTCP seems almost perfect.

[schauveau]

As a side note, I was upgraded from v144 to v146 soon after I switched from WiFi to RJ45. Not sure if that is related.

[bertsmelik]

My 2 Venus V3.0's were at firmware 146(-111?) and I had 2 problems:

1. Batteries dropped "Local API" several times a day (batteries no longer visible in integration)
2. Auto (self initiated etc.) would not discharge
   I reported this to Marstek support, who came up with a "solution": completely shutdown the batteries for 4 hours.
   Although I was skeptical, I still went ahead (what can I loose?)

As advised by Marstek support I brought down both Venus V3.0's:

• disconnected from grid
• turned off battery
• waited 4 hours
• then reconnected and turned on
  I found that all settings were still there. Only thing is that I had to put them in Discharging mode (using Passive, se below) again. Btw: Auto worked again after this!

Since that, both batteries are working without a problem for 24 hours now.

I am using Passive mode for charge and discharge. Built a loop in the corresponding scripts to check if the battery has indeed started charging ("Grid power" below 0) or discharging ("Grid power" above 0). That works well so far.

I will let you know how it went after these first 24 hours.

[bertsmelik]

I switched to https://github.com/fonske/MarstekVenusV3-modbus-TCP-IP.

Everything works out of the box except for a small issue with some select entities for which I already have a solution (see my ticket fonske/MarstekVenusV3-modbus-TCP-IP#6 )

I only tried it with RJ45 but since this is using TCP-IP I assume that it also works with WiFi.

I might try the local api in a few month after they solve the bugs but so far that alternative using ModbusTCP seems almost perfect.

Are you using the Marstek Local API directly or did you implement a modbus solution also ?

[schauveau]

This is using modbus so no local api. The Venus3 provides modbus via TCP-IP on port 502 so it does not require any additional hardware.
Really, it takes 2 minutes to install as explained in https://github.com/fonske/MarstekVenusV3-modbus-TCP-IP/blob/main/README.md

[schauveau]

if you use the provided MENU file, you should get a dashboard that looks more or less like that

[bertsmelik]

Looks very interesting!
Before I start digging: how can I use Nord Pool pricing in here? I would like to control charge/discharge/idle based on prices (grossed up with taxes etc.).

[schauveau]

Well, the Work Mode select in the top right corner contains an ai option but you will have to configure the energy provider in the Marstek app. I see that NordPool is in the list of supported energy providers so that should work.

There is just a small annoying. We know how to enable IA mode by writing 2 the modbus register 43000 but that register contains 1 when it is read again and that corresponds to anti-feed (i.e. autoconsomation with a CT). In practice, that means that the select entity will incorrectly show anti-feedwhen IA mode is enabled. That can be verified in the Marstek app.

There might be some modbus registers that contains relevant 'ia' information but they have not yet been identified.