search

tomquist / b2500-meter

GNU General Public License v3.0
6 stars 0 forks source link

Smartmeter recognized by B2500 but .... #2

Open Lexx3D opened 4 months ago

Lexx3D commented 4 months ago

Hi,

as owner of a Marstek Smartmeter i'm glad you came with this, as i hope soon working solution.

To test your script i made a small bash script that just outputs 21W of powerconsumption expecting the B2500 to send +- 20W into the grid. But all i got where spikes of about 600W , rest of the time 0 output. That's btw is also happening every now and then when the smartmeter.py is not running and adaption is selected but less frequently.

Ok, i thought maybe too low values for the B2500 so i changed it to send 85W, same result. "Maybe too fast with 1s pause?", so i slowed smartmeter.py's output down to send only every 10 sec, same result, i guess not an overload of information though.

I use to program different languages from time to time, never used py before but i guess i get along to do some minor changes not disturbing the workflow of your original source :)

Keep up the good work, i'm really looking forward to get this up and running... :)

Jörg

My "script":

#!  /bin/bash

echo "25
25
35
"

That's what smartmeter.py does with it:

Testing powermeter configuration...
Successfully fetched powermeter value: 25W | 25W | 35W
TCP server is listening...
TCP connection established with ('192.168.1.125', 10000)
Received 'hello'
Sent message: HM:85|0|0
Sent message: HM:85|0|0
Sent message: HM:85|0|0
...
Connection with ('192.168.1.125', 10000) broken. Waiting for a new connection.
TCP connection established with ('192.168.1.125', 10000)
Received 'hello'
...

and so on....

Some more Info: Marstek B2500 210 Py 3.9.2 Raspbian x86

Snotmann commented 4 months ago

Got the same issue ... the storage powers out what it can, and then the output went down to 0, i will slow down the output too ... did this help you??? @Lexx3D ... all 10 seconds will be enough i think !

tomquist commented 4 months ago

The original smart meter also sends a measurement every second so I don’t think slowing down would help. The issue most likely is caused by the firmware, which needs an update. Right now unfortunately the adaptive regulation of the storage seems to be quite unusable.

Lexx3D commented 4 months ago

@Snotman

Got the same issue ... the storage powers out what it can, and then the output went down to 0, i will slow down the output too ... did this help you??? @Lexx3D ... all 10 seconds will be enough i think !

Nope sadly does not help.

@tomquist

The original smart meter also sends a measurement every second so I don’t think slowing down would help. The issue most likely is caused by the firmware, which needs an update. Right now unfortunately the adaptive regulation of the storage seems to be quite unusable.

Yes my opinion as well. Marstek ( Hametech ) support told me Firmware version 200 does not solve the CT001 adaptation problem. The technical team would be working on a new firmware version to address this issue.

My guess with the new batterymodels coming these days this issue may last long ....

just curious, with which version of fw & brand are you using the script and does it work as it should?

tomquist commented 4 months ago

I’m not really using the script because I have a Hoymiles Inverter and am using HoymilesZeroExport for zero export. I tried the adaptive mode with my script on v163 but it was not working at all.

olympic1337 commented 4 months ago

I can confirm the same for firmware v212. Worst is that my battery completely deactivates input from pv panels when adaptive mode is selected. Did you also experience this? Support told me that they'll investigate, but no further reply up to now.

Snotmann commented 3 months ago

@Lexx3D did you try 214 version ? Seems much better for me but the bc2500 dont regulate down the power only up ... dont get why

Lexx3D commented 3 months ago

@Snotmann Running the 214 atm, working like the 210 did for me as well. Smartmeter functionality is still a mess. Original CT001 also behaving like this. I now decided to go the Hoymiles/OpenDTU on battery way. We bought an Anker Solix 2 Pro version when the Marstek was ordered, works like a charm and i highly recommend it. I wish i had bought 2 of them instead of trying out a less expensive system and only buy 1.

@olympic1337 212 is a mess, it deactivates the pass through until the battery level drops to 95% i read somewhere, the reason that was given for this behaviour was to extend battery life. I really doubt that. I rolled back to 210 when i tried 212 and am now at 214 which "works as expected", 0:00-1:29 195w, 1:30-17:29 85w, 17:30-23:59 205w, pass though atm starting around 14:00.

LagaV commented 1 month ago

Updated to 2.16 yesterday,

I can get the script to run for a short amount of time, but then it disconnects the the TCP connection and takes some time to reconnect, often complaining that the message was not reconized.

Already dialed down the interval to 2 seconds....

Any further advice to get this working reliably?

tomquist commented 1 month ago

@LagaV Could you please attach some logs? I didn’t test it with any of the newer firmwares so far.

LagaV commented 1 month ago

Had some challenges to get this going again. In the end I rebooted the B2500 with no progress and had to restart the Marstek mobile App (that helped finally).

Before that in the app (when switching to "Auto" I only got updates like: "CT001 Not disposed" "CT001 dispose preparing" "CT001 disposing" "CT001 channel disposing"

This is the log output similar to what I had seen before, only difference was, that # of "Sent messages" differs:

Testing powermeter configuration...
Successfully fetched powermeter value: 92W | 151W | 32W
TCP server is listening...
Received 'hame' from ('192.168.1.147', 10000), sent 'ack'
Received 'hame' from ('192.168.1.147', 10000), sent 'ack'
TCP connection established with ('192.168.1.147', 10000)
Received 'hello'
Sent message to ('192.168.1.147', 10000): HM:161|138|43
Sent message to ('192.168.1.147', 10000): HM:161|141|43
Sent message to ('192.168.1.147', 10000): HM:161|141|43
Sent message to ('192.168.1.147', 10000): HM:94|140|43
Sent message to ('192.168.1.147', 10000): HM:360|140|43
Sent message to ('192.168.1.147', 10000): HM:551|144|44
Sent message to ('192.168.1.147', 10000): HM:161|379|44
Sent message to ('192.168.1.147', 10000): HM:160|383|43
Sent message to ('192.168.1.147', 10000): HM:160|383|43
Sent message to ('192.168.1.147', 10000): HM:160|379|43
Connection with ('192.168.1.147', 10000) closed
Exception in thread Thread-3 (handle_tcp_client):
Traceback (most recent call last):
  File "C:\Users\me\AppData\Local\Programs\Python\Python311\Lib\threading.py", line 1038, in _bootstrap_inner
    self.run()
  File "C:\Users\me\AppData\Local\Programs\Python\Python311\Lib\threading.py", line 975, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Users\me\OneDrive\GIT\b2500-meter\b2500\b2500.py", line 135, in handle_tcp_client
    conn.send(message.encode())
ConnectionAbortedError: [WinError 10053] An established connection was aborted by the software in your host machine
TCP connection established with ('192.168.1.147', 10000)
Received 'hello'
Sent message to ('192.168.1.147', 10000): HM:160|378|45
Sent message to ('192.168.1.147', 10000): HM:161|378|44
Sent message to ('192.168.1.147', 10000): HM:159|379|44
Sent message to ('192.168.1.147', 10000): HM:159|376|44
Sent message to ('192.168.1.147', 10000): HM:161|381|43
Sent message to ('192.168.1.147', 10000): HM:160|381|43
Sent message to ('192.168.1.147', 10000): HM:160|378|43
Sent message to ('192.168.1.147', 10000): HM:161|381|44
Sent message to ('192.168.1.147', 10000): HM:160|377|43
LagaV commented 1 month ago

Just some more observations here:

image