search

RalfOGit / libspeedwire

SMA Speedwire(TM) access library written in C++
MIT License
14 stars 6 forks source link

Support for Home Manager data stream #3

Closed danieltwagner closed 1 year ago

danieltwagner commented 1 year ago

In an effort to make sense of the SMA Sunny Home Manager 2.0's data stream towards the SMA EV Charger (and trying to convince it to modulate its output accordingly) I did some data logging and spelunking in https://github.com/danieltwagner/speedwire-parse

Now that that's complete I realize that it's largely overlapping with what you already determined for the energy meter, though there are some additional messages and I haven't determined any addressing, as seems to be referenced in your repo. I do see a sender ID (maybe susy id?) and serial number but nothing to determine the recipient... unless I'm missing something.

Anyhow, long story short, would you accept a PR that adds some relevant constants? I haven't yet looked closely at what would be required but figure it can't be too bad based on what I'm seeing here https://github.com/RalfOGit/libspeedwire/blob/023ef5772581e79bdac3e641d52470044e85c0de/src/ObisData.cpp#L221

RalfOGit commented 1 year ago

Hi Daniel, from what I read in your repo, there is another protocol ID and collection of obis data fields for the communication between SMA HM and the SMA wallbox. Is this done by multicast or by unicast? Just send me what you need and together we can find a way to fiddle it in.

RalfOGit commented 1 year ago

... can you please check if some of the hex numbers in bold are serial ids or susyids of either the shm or ev? The b3 56e7ff is 3008817151 in decimal and looks a bit like a serial number. The hex 174 is 372 in decimal and looks a bit like a susyid. The hex digits in italics could be the timestamp coded as the lower 32-bit of the unix epoch time:

0000 53 4d 41 00 00 04 02 a0 00 00 00 01 02 4e 00 10 len = 024e 0010 60 81 00 03 01 74 b3 56 e7 ff 80 b5 28 a3 00 01 protocol serial? Susyid? Timestamp? posactpowtotal 0020 04 00 00 00 00 00 00 01 08 00 00 00 00 0e af 23

danieltwagner commented 1 year ago

My bad, I missed your previous response. It's unicast and if 0x174 looks like a susyid then it is. I went by the "meter id" shown in the Home Manager UI which says 174-3008817151. I take it this means it's a susyid and then the serial number (of the home manager). See here for my way to parse the packets: https://github.com/danieltwagner/speedwire-parse/blob/main/parse.py#L98-L126

I'll prepare a patch with the new fields I found.

danieltwagner commented 1 year ago

Having had a closer look, it appears that there is in fact no new data that I uncovered, and that the packets are identical to the emeter protocol... that could have saved a lot of time. Alas. Somewhat interestingly, they are being sent as unicast, whereas based on your emeter simulater I gather that actual meters are sending them using multicast?

RalfOGit commented 1 year ago

… then they just reused the emeter HW and SW of their emeter and put it in the EV charger. I will adapt the header class to be able to deal with the new protocol id and header. As they are using unicast for the communication, there must be a device discovery. Do you have packet captures of this process?

danieltwagner commented 1 year ago

Yeah, sounds like they just made the Home Manager send the same package structure to the EV charger. This is a remote setup so I'm afraid I can't interrupt the existing setup, but during regular operation there were no broadcast or multicast messages in the course of several hours. It could be that the EV Charger sends a broadcast request when it doesn't know a Home Manager, or it could even be done manually.

Good catch about the new protocol id. I typed up https://github.com/danieltwagner/sma-emeter-simulator this morning but forgot to modify the header!

danieltwagner commented 1 year ago

I'm noticing that the packets I captured had the full 610 byte length, not the shortened 608. So it's not identical but very similar.

RalfOGit commented 1 year ago

… there is a short conversation here that sheds some light on the protocol id topic: https://www.photovoltaikforum.com/thread/117118-sunny-home-manager-2-0/?pageNo=51 I added protocol id 6081 to the sma-emeter-simulator and checked what the Energy Meter app is showing. Using your susyid it is presented as a shm 20 device and the measurement data is correctly decoded. I will rework my latest commit and reference the Extended Energy Meter Protocol.

danieltwagner commented 1 year ago

Thank you for adding support for the data stream! :)