Closed danieltwagner closed 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.
... 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
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.
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?
… 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?
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!
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.
… 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.
Thank you for adding support for the data stream! :)
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