Well, I asked for it. After months of perfect behaviour I noticed that I started to have CT drops after enabling the local API (through Bluetooth or the app) . Disabling and resetting the Venus solved the problem. So I logged a call to report this and requested an update. I received it and isntalled on all 3 batteries (also an update on the CT003)
Since then the CT dropouts seemed to have improved but the behaviour on the APP is a little different.
No problem to run the test. Just tell me how.
Battery State and Power always have a dash. Is that right?
No, that should not happen. According to the API the value should be received in the ‘bat_power’ property of the ‘ES.GetStatus’ message. On my system (Venus2/v153) things are fine. If possible, can you install the latest TEST version, let it run for a while, and send a diagnostics report from within Homey? That should contains detailed logs and responses from your battery so that I can perhaps try to understand why it happens and apply a fix.
I have already installed the latest test version. Will look tomorrow and perform a diagnosis.
c462d010-e76f-4171-b4ab-ff6962d1156f
not the test version, will send those in the morning
Firmware was “pushed” by marstek, the app sugested to update my venus E. Considering your remark its seems 153 is more common.
Test version installed: manual activted the cards, but same responce: mode set with older (or incorrect) values
Running the cards:
Battery results show the values i set manually this morning (as quick fix) trough the marstek app
The test version does include Dutch translations? 
After installing the TEST version the battery did charge in the nightly hours, so i will do some testing tonight if this version resolves the issue.
Hello everyone,
I wanted to share my current setup for controlling my battery charging.
The Problem: My Marstek AI defaults to a full load of 2800W (on its own dedicated group). This causes the internal fans to run at maximum speed, creating a loud humming sound that disturbs everyone at night.
The Solution: I have bypassed the “AI” mode to manually cap the charging power at 2000W. This reduction keeps the fan speed—and the resulting noise—to a much more manageable level.
I’ve detailed my (dutch) setup below and would love to hear your feedback or suggestions for improvement!
I have installed the latest version 0.8.10. After this the temperature of the battery dropped to 2.3 degC. I am using firmware V144.
What happen when you deleted the manual 03:-06:00 plan and then run the flow?
After running a flow and pushing a manual program to the MT it’s not listed in the overview but it’s running. (MT on v155)
Why did you not use one manual set for loading the battery each with a timestamp from 00:01 till 23:59 for all days. And a separate step (flow) for stop loading the battery at a battery level of >95% to switch off the manual loading. The same for discharging the battery.
I’ve been doing some testing with the latest version, and it has been a bit of a frustrating process—though that might just be down to it being a test build.
Charging Configuration Error: While trying to manually set the charging time, day, and power via the device card, I kept receiving errors. It appeared the connection was completely broken.
Hardware Reset Required: To resolve the connection issues, I performed a hardware reset on both batteries and reconfigure them within Homey.
Script Repairs: Since the re-pairing process changed the device IDs, all my existing scripts/flows broke. I’ve spent some time today getting everything back up and running.
Following the suggestion from @Cees_Krijnen , I’ve implemented a “slimmed down” version of the flow to keep things more efficient. For now, everything is working correctly—fingers crossed that the next test update is a bit more stable!
Feature Suggestion: IP Visibility
Could we make the IP address of the battery visible in the Homey device settings?
I’ve have a difficult time managing these Marstek devices because they don’t seem to appear in my network’s DHCP server list. Even when searching by the MAC addresses provided on the units, I can’t find them on my network. Having the IP address directly visible in Homey would be a massive help for troubleshooting connectivity. i’m able to see something that could be the battry: wlan0 /Quectel Wireless Solutions
I am still experiencing issues with my setup. A few hours after performing a full system re-initialization, the errors have returned. Specifically, the power flow is failing to reach the batteries.
Also the CT configuration was reset on both battery’s while this was correctly set 3 hours ago.
I have attached the diagnostic files below for your review. Please let me know if you can identify the bottleneck or a specific component failure
d68e6aad-a69d-4829-903e-3e6c8f90257d
flows used:
I have the same problem: I cannot find the Marstek battery at my network. I am using a network cable, not Wi-Fi. Wi-Fi is less reliable and more prone to connection issues. I looked up the IP address in the app, and there I saw the name of the Marstek battery listed at the IP address.
I have successfully re-integrated the batteries with Homey. Notably, the devices were not detectable until a hardware reset was performed. The full process was as follows:
Device Removal: Removed the battery from Homey.
Initial Attempt: Attempted to re-assign, but the app could not find any batteries.
Hardware Reset: Performed a hardware reset on both batteries (this resolved the detection issue).
Marstek Setup: Re-assigned the batteries within the Marstek app and enabled the API.
Homey Integration: Added the devices to Homey (the app was now able to locate them).
Flow Update: Adjusted the cards in my flows.
Result: “Load” and “Unload” tests were successful.
Ran into a glitch after about an hour—one battery wouldn’t change modes. The flow card turned blue like the command went through, but the Marstek app didn’t update. I managed to fix it for now by restarting the app and replacing the card in the flow.
I’ve been in contact with Marstek regarding several tickets. Here is the current status of my suggestions and some critical issues I’m facing after the latest firmware update. Also the update broke the Marstek Venus Connector functionality.
The support team confirmed they have passed the following two suggestions to the development team, though I suspect these may be treated as low priority:
Adjustable Power Limits in AI Mode: Currently, the power limits (800W / 2500W) are fixed. I requested that these be made fully adjustable (0–800 / 0–2500), similar to how Manual Mode works.
Manual Phase Override: The “Auto Phase Detect” often fails when there is a high load on a specific phase, and there is currently no way to correct it manually. I suggested a manual override to force the battery to the correct phase (A, B, or C) instead of relying on the faulty detection.
On marstek request: updated to the latest versions
System Firmware: 156.216
BMS: 215
Communication: 202501211626
Whats new: max discharge setting 30-88%?
The Problem: After updating and factory restore, I removed and re-detected the batteries and updated the cards in my dashboard. However, all devices and cards have turned red, indicating a communication failure.
The Strange Part: Despite the “red” status and errors in my dashboard, my first Marstek battery (86) seems to be receiving some data. The second battery (b1) refuses any change of mode.
My first battery (86), reproduced several times with succes
The system was in “Self” mode.
I attempted to set it to “AI” mode via my flow card.
I received a communication error, but when I checked the Marstek App, the mode had successfully changed to “AI.”
It seems the outbound commands are reaching the unit, but the status feedback loop is broken in this firmware version.
update 17:46 Extended log files: 737098a4-3b04-4e24-8a66-53d1ea6695d9
Thank you for the elaborate details; most of them are recognizable as firmware issues due to the less-than-ideal UDP implementation on the Marstek batteries. Resetting the battery solves a lot (for a while). You are on firmware v156, I’ve not seen before, so not sure what is changed…
I’ve not found any updates on their API documentation, so I’m not sure why this new firmware now acts differently on those API calls. And with this new version, the communication errors are not solved by a battery reset?
I have not received a diagnostics report with the mentioned ID on any of the Homey App versions, so I can’t check those logs. Can you try again please?
Hi Cees, have you tried the procedure as described in the README here in the topic? Check if local API is enabled and set to port 30000 and try a reset before discovery.
If this does not help, let us know what hardware and firmware version you are running. You can also try the latest TEST version of the Homey App, try again, and send a diagnostics report.
