Protocol documentation

[tomkcook]

Excuse me leaving a question that's not an issue with software, but is there some documentation on this protocol that this work is based on? Or is it reverse engineered?

[Rincewind76]

Hello! I am in no relation to the company SMA and I did not get any information or documentation from SMA. Therefore I had to reverse engineer the protocol and make assumptions. And looking at the results, some of my assumptions were incorrect, but together with the community of FHEM I think we came pretty close to a documentation.

[tomkcook]

Okay, thank you.

[sbf-]

Therefore I had to reverse engineer the protocol

Really?

[Rincewind76]

? I don't get it... To answer your question: yes.

Maybe we have a different understanding of reverse engineering, see also: https://en.wikipedia.org/wiki/Reverse_engineering Quote:

Reverse engineering, also called back engineering, is the process by which a man-made object is deconstructed to reveal its designs, architecture, or to extract knowledge from the object. ... There are two components in reverse engineering: redocumentation and design recovery.

I am not aware of any public available documentation or design documents. Therefore I created SMA_Data_2plus.xlsx to explain the design and structure.

[tomkcook]

Thanks for your hard work on this. Feel free to tell me to go away if you don't want to answer questions, but I hope I can pick your brains a bit.

The byte at position 18 is described as "longwords". From what I can make out, this is the number of 4-byte dwords in the packet, starting at position 18 and not including the 4-byte terminating zero - does that sound right?

And do you know what the three Ctrl numbers mean? In the data I've captured, ctrl2 and ctrl3 seem to frequently, but not always, cycle through the numbers 0, 1, 2 and 3 - but there are a number of other values that turn up with no apparent rhyme or reason. I can't see any meaning at all in ctrl1.

[Rincewind76]

No problem, I try to answer as much as I can! I have to excuse myself - It has now been some time passed, I need to rethink some topics. In some fields my interpretation might be wrong (happened also on some spots, since I only have access to some systems)

I evaluate the length of the request/response at position 13 - length excluding header. But I think you can also use this.

For CTRL I initially thought, this is some sort of index of combined answers, but as you also saw - somethings did not fit. In the end I anyway throw away these bytes in evaluation.

[tomkcook]

When you make a request, does it matter what the ctrl bytes are?

[Rincewind76]

I am using for the length and CTRl the value 0xA009. CTRL2 I set constant to 0x0000. I saw this once and never changed it, I use this for all requests. I have to say, I do not send multiple commands in one request (which should be possible). I send separate requests for each command, the speed advantage is neglectible (we are speaking anyway of a PV system).

[tomkcook]

Thank you for all your help. As I say, tell me to go away when this gets boring!

I can successfully request all values available on the inverter by eg sending command 0x51000200, first address 0x00000000 and last address 0xffffffff. The response comes back with seven 32-bit integers per field. The first is the field ID, the second is a Unix timestamp (SMA don't expect these to be still working in 2038, it seems) and the rest are 5 values for the field. The scaling is pretty easy to guess for most of these. But do you know why there are five values for each field?

In SMA_logon, you use command 0xFFFD40C0 / 0x00000007 / 0x00000384, and the comment says this is for "Logon command + User group "User" + (maybe) Timeout". Do you know how to change this for the user group "Installer"?

[tomkcook]

Never mind about the user/installer thing - I found another bit of code that shows how to do it (userid 0x0000000A instead of 0x00000007, and add 0xBB to password bytes instead of 0x88 - are they really using ROT0x88 to "hide" passwords?)

[tomkcook]

I'm still interested if you've any idea what the multiple values returned for each data ID are - or how to tell how many there are for each data ID in a packet. It seems to be always the same in each packet, but it's not obvious how to tell how many that is.

[Rincewind76]

A explanation of some commands you can find in the excel file, the commands are more or less self explaining what to expect. I did compare the data with values I saw directly at the device to see how the numeric values should be decoded. Also the tool sbfspot delivers quite some information.

[sbf-]

This is what I figured out for e.g. Internal Temperature. The 4 values are Minimum, Maximum, Sum and Average. It seems Sum is the actual value.

01 77 23 40 237700 Coolsys.TmpNom --> Operating condition temperatures
10 2A 29 42 5/03/2005 4:40:00
15 11 00 00 Min: 4373
DD 11 00 00 Max: 4573
65 11 00 00 Sum: 4453 (44.53 deg Celcius)
65 11 00 00 Avg: 4453
01 00 00 00 1

The 5th DWORD is unknown - In all cases I saw only 0 and 1 It is also unknown in what timespan the min/max is measured (Every 5min?)

[tomkcook]

Thanks. I'm still working on this. Would you be interested in contributions back, even if it's just more detailed protocol documentation?

FYI, this guy has done a wireshark decoder which has quite a bit of detail on how the protocol works. In particular, the data ID word in each record is broken down into three components:

class = dataid & 0xff # 10 => string value, anything else => 32-bit integers
code = (dataid & 0xffff00) >> 8 # This is the data ID selector
index = (dataid & 0xff000000) >> 24 # Meter index - seems to be where one inverter has multiple meters attached