Goedeavond!
Ik heb een vraag.
Momenteel 1 marstek v2 in gebruik in combinatie met de p1 meter van homewizard.
Ik wil een 2de accu gaan aanschaffen. En dus automatiseren.
Is het mogelijk om met jouw software de batterijen zo aan te sturen dat eerst batterij 1 vol laad? en daarna 2?
En is het mogelijk als ik mijn EV ga laden dat de marsteks dan stoppen met ontladen?
Hoor het graag.
Hi! Just trying to build this flow for my own, but can you give me some more info on your logic card: #powerbankdrempel?
This threshold was a price, and when the dynamic price for that our was below that price, the battery would always start charging. I no longer use this part, it was set to a price below my providers kWh delivery cost.
Hi, I will answer in English if you don’t mind. You can send commands to the batteries using Homey flows, so if you have trigger details available in Homey, then it should be possible. Keep in mind that the flows are limited to the API of Marstek; but I’ve found that setting the battery mode to ‘Manual’ with a timeframe of whole day and also ‘disabled’ will stop any charging or discharging of the battery. If you have EV details in Homey, then you can combine the two!
Please keep in mind that the Marstek battery does not like to share communication with other devices, so don’t poll data from the battery too much when you have a P1 link active with the Marstek battery. I’ve not tried with the HomeWizard P1, so it might be okay, it might not be… let us know!
Thank you for the report; I’ve taken a look at it, and it seems you battery is ignoring all messages that try to retrieve the Energy System status. “ES.GetStatus”. The format of the message seems to be correct; so I don’t know why it is ignoring it. I’ve released a new TEST version that includes some additional debugging for edge cases where source configuration mismatch might occur. If you have the time; please send a report when you’ve updated at your convenience. Thanks!
Hi Edward,
I added a new diagnostic file with experimental version 8.6:
8ffbf953-26c0-4a1f-9b05-292f1898c92a
Hopefully you can find the cause, with kind regards
Dennis
Hi Dennis, thank you for the report, I’ve take a closer look and I see you have three batteries responding to the “Bat.GetStatus” broadcast, but none of the batteries are responding to the “ES.GetStatus” call. I don’t understand why though, the format of the broadcast message is according to the specifications. It might be that the “ES.GetStatus” call does not support broadcasting, so I will try to create a new version that will initiate calls directly targetting the batteries; so a separate call for each battery. I will report back once finished!
A new TEST version has been released where the “ES.GetStatus” message is no longer broadcast to all devices but transmitted to each individial device separately. For users with multiple devices or Venus 3.0 devices; please check if data is being received as expected.
(since I only have a single device, it is difficult to test concurrency on message handling)
Hi Edward, still no data is received unfortnuate. Please find enclosed the latest diagnostics from test version 8.7:
2dc65b1d-d395-4c40-8ca1-b0dd15d2f87f
Hopefully you can find something in the data.
Kind regards Dennis
That is unfortunate, it seems only one of your batteries is responding, and only to the “Bat.GetStatus” broadcast. All others are not responding at all. Not sure if you mentioned it, but you have tried to reset the batteries using the BLE tool? (Note that the batteries also don’t play well together when using CT002/CT003).
Hi Edward,
Just tested and performed a restart of all 3 batteries through the BLE tool. Seems data is still missing. Diagnostics are added vor test version 8.7 :
5555fc1a-3432-4394-a8fd-ae750b1e04c8
Made also a screenshot from the BLE tool, maybe it gives you a lead
Data from screenshot is from battery 05c6.
Hopefully you can find something else please let me know if more data is needed.
Kind regards
Dennis
Thank you for the screenshot, it seems the port number for the local API has been configured to 28416. Are you able to change this to 30000, since that is currently the only port number that is supported by the Homey App… There is a request to have this configurable, but I’ve not been able to implement that yet. You can use the BLE tool (not sure what version) to configure the port number. If you don’t want to tamper with this number, you will need to wait until I’ve implemented that change.
Hi Edward, I tried already several times to change the Local API port to 30000 through the BLE tool (BLE–> connect to battery –> system –> Enable Local API (30000) but this does not seem to change anything as it stays fixed at port 28416. I’m afraid this could be/is the problem. Hopefully you have some time to be able to make it configurable.
Awaiting your reply, kind regards
Dennis
It seems that version 2.x.x of the tool does not change the API port nummer, but version 1.x.x (stable version) does.
At least in my (very limited) experience.
It doesn’t help me though, still the v3 isn’t found. Back to modbus for now.
Thank you for the feedback! I’m getting a clearer picture of the problems, but not yet able to explain why some messages are working on batteries with a port number other than 30000…
Since I currently don’t have physical access to my battery (I’m working abroad) I’m not able to configure the port number through BLE to test alternative port configurations (but I will try). For all Venus 3.0 users; please keep me updated when something changes! Thank you again.
Hi Edward/Dick (from previous post),
I tried also to change the port nr with the older version of the BLE tool (1.x.x) but still it won’t change. I guess we need to wait till your back from abroad Edward.
Anyway thanks for all the effort thus far.
Kind regards Dennis
I got the API working and my charging test for 1500 W for 5 minutes is succefull. Please add more flows. Like only charging , Not for specified time.
I have A Venus V3 with firmware 139 and port number changed to 30000
One last remark, WHen i open the Marstek APP on my phone. The connection is then lost and will not exicute
Good to hear that you’ve managed to get it working! The Homey App is bound to the possibilities of the Marstek Battery API, and the current flows are the only API calls that are supported by the battery. I use a flow with time period set 00:00 to 23:59 in combination with the (dis)charge and enabled properties for maximum flexibiliy. You should be able to use them for all possibilites…
Note that the battery does not like to communicate with multiple applications over local API at the same time. That includes the mobile app and P1 meters. This is a (major) limitation of the Marstek products (and makes my life a bit harder 
.)
How do you force the battery to stop Charging / Discharging. This is needed when my EV is charging
