I was able to install the APP again. See link: 7e756847-a1cb-440f-bf75-1df024923688
If you have 5 devices, then the command can be transmitted 5 times, but it seems you only have one device. So, I don’t know why your tool is picking this up as 5 entries, since I only call the actual transmit function once (per battery device).
I have successfully assigned static IP addresses to both Marstek batteries using the IP values provided in the app.
Current Status & Observations
While the communication is established, I am encountering a specific validation issue within my Homey flows:
-
Visual Errors: All flow cards currently turn red and report an error.
-
Successful Execution: Despite the error status, the commands are actually being sent, received, and executed; the batteries do switch to the requested mode.
-
Root Cause Analysis: It appears the flow fails during the read-back/validation phase. The system likely attempts to verify the change immediately, but cannot yet read the updated values from the battery.
Proposed Solutions
To stabilize the integration and clear the “Red Card” errors, I am considering the following logic adjustments:
-
Read-Back Delay: Could a delay between the Send and Read commands resolve this? This would give the battery hardware enough time to update its status before the app tries to validate the change.
-
Sequential Staggering (Delta-Delay): To minimize the load on the Marstek units and prevent simultaneous request collisions, I suggest staggering the communication:
-
Step 1: Write Battery A.
-
Step 2: Wait X seconds.
-
Step 3: Read Battery A.
-
Step 4: Wait X seconds.
-
Step 5: Write Battery B.
-
Step 6: Wait X seconds.
-
Step 7: Read Battery B.
-
Indeed, I can confirm that I own one (1) Marstek battery
I personally don’t see this behaviour and the logs seem to confirm that the Homey device is called once per message. So why there are 5 messages, I can’t explain. So it is Homey or the tool you are using.
After a mode change command is transmitted, the Homey App waits 10 seconds for an expected reply. If the reply does not match the expected format, it retries for a maximum of 5 tries. Then it throws and error to Homey (your Red Card situation).
Can you send the diagnostics report after you’ve encountered the errors? I can check what replies are given by the battery in response to the commands.
I’ve implemented a 5-second delay between the batteries. While it may not solve the issue, it won’t cause any harm. Currently, switching modes twice on both batteries triggers a ‘red card’ error, even though both batteries actually updated their modes correctly.
-
Marstek Energy Storage v1.1.2
-
Marstek Firmware: 156.216
-
BMS: 215
-
Communication: 202501211626
log files: d0e1a8fb-c9a2-480b-a47c-c59581e75fcd
Not received the log files (yet), I’ll keep my eyes open!
Regenerated: 78a873a2-051e-43d6-843c-df9c431df20f
Thank you for the log. In the logs there are no replies from the batteries after the ‘ES.SetMode’ command is send. Normally this command should trigger a reponse where the property ‘set_result’ is set to true. I can’t tell you why, but probably firmware or UDP communication issues on the battery. If a system reset using BLE tool does not work, then probably firmware change… Unfortunately there is nothing at my end I can do.
1 Like
Hi and a huge thank you for the app 
Would it be possible to get a new “then” card? 
I would like to be able to set the grid charging to individual values according to the out put of my other PV system.(The batteries can only charge with 2.5kw, everything else is sent to the city grid 
But it would be great to use it for charging the Marstek battery 
Reporting this bug is a good thing. It would be helpful if every user in this forum thread contacted Marstek to urge them to fix this issue. In the meantime, I can live with these beta version errors, but I assume it’s not possible to disable the “getStatus“ call with a toggle in this test version.
I’m not trying to stir up trouble for no reason, but the current Marstek QA seems pretty broken. With proper automated testing or unit testing, this code should never have been released ‘into the wild.’
Overall, it’s frustrating to see this happen with multiple brands. They often have solid hardware, but the software is usually closed-source, lacks an API, and offers terrible functionality. It’s time for an open API standard for all battery systems… a man can dream.
In Manual Mode, the system already utilizes a variable to define the battery’s charge and discharge power. By allowing this variable to accept a dynamic input (the current desired value), the requested functionality could be implemented quite easily to match your other PV system’s output.
example of my charge card (sorry in dutch)
“Set battery mode to ‘Manual’ from 00:01 to 23:59 on Monday, Tuesday, Wednesday, Thursday, Friday, Saturday or Sunday with # battery.selfchargepower Watt and enable Yes”
Thanks for the fast reply 
Would be more than happy to see it 
Hi, what can you do with the Passive Mode function? I sometimes want to put my battery inactive, but what do you mean by passive mode, with a certain wattage for a certain number of seconds? Isn’t it possible to just put the Marstek in passive mode without specifying a wattage or duration? I also want to let you know that the API itself works quite well. I have v0.8.1.
Had to downgrade my Marstek firmware for the first time today (one of my two betteries). After reporting those @eniewold UDP errors (ibatteries aren’t replying to the ES.SetMode command. Usually, that command should trigger a response with set_result: true, but it’s just silent). Marastek moved one battery from 156.216 back down to 154.216.
