No i havent i saw another one called Passive and then how long in Seconds. SO the one you suggest is better.
But my battery doesnt give me any info.
I did the following: re-add the batteries, but use the cloud function this time! That way, you will see the reasonably current status. Next, set the ‘Enable (periodic polling)’ option to no.
Edit:
The only drawback is that the batteries are duplicated, but you are now able to create flows! And the commands are received successfully.
I am working with the test version, The app is receiving irregular the Energy (kWh) and Temperature values (via the Bat.GetStatus API request?). A timer is incremented every 5 seconds. No other values are shown in the APP. Listening the 30000 port I noticed a large number of API Bat.GetStatus requests from the APP not answered by the battery.
Hi Jack, just curious. how did you manage to change the port nr to 30000? I can’t get it changed with the BLE tool, also not with the older version.
Awaiting your reply, regards
Dennis
I tried it and after that it’s still says it’s on the old port but I tried finding it and it showed up. So maybe luck?
Also when I trie now it says package is to small so I don’t see it anymore
The polling optie voor cloud right?
No the polling option in the api battery
Thanks will do that
1 Like
Hello, I’m new to Homey and want to use it to control my two Marstek batteries intelligently. I’m frustrated that I can’t get Modbus and Lilygo to work. A good alternative would be this local API method. However, I’ve read that the connection to the CT003 is lost with the local API. How does the Marstek charge/discharge in AUTO mode?
What doe you mean wil lost with Local API?
The connection between ct002/3 and marstek is lost (or not stable) when you use local API as I read in the openingpost as known issue. Or is this solved already?
Without stable ct003 connection the marsteks (I’ve 2) wil not work in auto mode.
What are you trying to do maybe I can test do you have the v3 model
The Marstek communication module is not always too stable when using multiple forms of communication. Like stated in the readme, using the local API together with the Marstek mobile app or CT002/003 causes communication collisions where more messages remain unanswered. Although this is in the nature of UDP, it is a bit too often to blame the protocol. Higher firmware seems to solve more issues. Different users and use cases have different results.
Polling less means less collisions; so reducing the polling frequency helps. Personally I use one Local API device and a cloud device in Homey (for the same battery) so I can safely read some battery stats (from cloud) and use flows to change the mode (through local API).
1 Like
Waar log je trouwens in op de Marstek cloud? iemand een adres?
via
kom ik op onderstaand uit (die het niet doet, onduidelijk of m’n ww oke is, kan je nergens resetten)
As far as I know there is no web access, only through the mobile app of Marstek are you able to create an account and log in.
I have the impression that the API communication isn’t very stable. For a few days now, I have noticed that API communication stops when the battery is full or empty (a battery restart is necessary to restart API communication). I have also noticed that the connector APP sends the Bat.GetStatus API request twice in quick succession. Is this disrupting API communication? I am using the test version.
Thank you for the feedback, but unfortunately your issues seems to be a recurring issue for the Marstek battery communication module. Hopefully Marstek is able to fix the issues with the Local API communication in a future firmware update. If you keep the interval at 5 or 10 minutes, things will not disrupt too much when using multiple methods of communication. More messages means the responses will degrade over time… Please check the readme under troubleshooting!
The two messages are probably because you have two batteries; a unique message is transmitted for each battery (in the current TEST version). This TEST was setup for V3 batteries, but did not solve the problems with that firmware being stuck on a fixed port number.
When you use cloud version you should make a second account to be able to keep using the marstek app
The API version I asked to activate it via the marstek support (inside the marstek app) it was made available in the marstek app within a day
Communication is not lost with the CT003. Just make sure to not send double commands. Don’t ask the battery to do the thing what it is already doing. Since I figured that out I almost have no problems anymore. (Only after an update of the marstek app like today). Other wise very stable
