Need help decoding RS232 data from Mastervolt inverter/charger

[Lomax]

I've got this Mastervolt combined inverter/charger that I would like to poll for data, but I'm struggling to make sense of the returned bytes. The device has a "quasi" RS232 port (QRS232) operating at TTL levels. I've made my own cable using an FTDI USB > TTL converter, and I can communicate with the device using Mastervolt's own software (running in a WinXP VM).



This software seems to work by doing bursts of polling in blocks of 49 requests, returning 49 responses. I used my scope to capture the raw TX/RX data in hex and interleaved these in a spreadsheet, with each request (in red) followed by the response (in black):



Studying this told me a few things about the requests:

• Requests are usually 9 bytes in length, though a few are 8 or 7.
• A request always begins with C1 F0
• This is followed by what appears to be a register address made up of two bytes (the second byte is sometimes 00)
• The following three bytes of the request are always 00, and the fourth one either 00 or 01 (read/write?)
• The last byte is a modulo 256 checksum of the preceding bytes

And the responses:

• Responses are always 9 bytes in length
• A response always begins with F0 C1
• The next two bytes repeat the address given in the request, though the second byte differs if 00 was requested
• The following four bytes contain the requested data
• The last byte is a modulo 256 checksum of the preceding bytes

I wrote a simple Python program (attached) to replay some of the queries and see if I could get some meaningful numbers out of the responses. First I tried a little endian sum of the four bytes, but nothing stands out as an expected value:



To see which responses might contain data I'm interested in, I tried disconnecting from the mains and letting the inverter kick in for a few seconds, before restoring mains power again:



Much more interesting. I can see several values which drop dramatically as mains power is removed, only to increase again once restored. One of these might be battery charger current & voltage, mains voltage, battery voltage, etc, but the numbers are clearly wrong. Other values don't change at all, or very little - perhaps things like serial number, firmware revision, system or battery temperature, usage counters, etc.

Since I can't make sense of any of the numbers, I removed the integer conversion and printed the data bytes raw:



Ok, so it's clearly not big-endian; that would result in ridiculously high values. And it's probably not two values by two bytes each. I tried looking at it as an ASCII blob, to see if there was any text in there, but there was none. Feels like I'm close, but I've become completely stuck. This is the first time I'm trying to reverse-engineer an unpublished serial protocol, so it's likely I've overlooked something obvious - but what might that be? Grateful for any suggestions!

[Lomax]

Side note: why can I no longer insert attached images inline? 

Edit: Added the images manually, sorry for the large size of some of them!

[Lomax]

Here is the raw sample data from when mains power was removed and restored:

 f1002000 f5061a00 00050000 05370000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000
 f1002000 f4061a00 00050000 05370000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000
 f1002000 f5061a00 00050000 05370000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000
 f1002000 f4061a00 00050000 05380000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000
 f1002000 f3061a00 00050000 05370000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000
 f1002000 f2061a00 00050000 05370000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000
 f1002000 f3061a00 00050000 05370000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000
 f1002000 f2061a00 00050000 05370000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000
 f1002000 f3061a00 00050000 05370000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000
 f1002000 f4061a00 00050000 05370000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000
 f1002000 f4061a00 00050000 05280000 00040000 0000f404 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 f3002500 ec061400 00010000 05000000 00020000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 f3002500 e6061400 00000000 05000000 00030000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 f3003500 e6061400 00000000 05000000 00030000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e3003500 e6061400 00000000 05000000 00030000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e3003500 e6061400 00000000 04000000 00030000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e3002000 e6061c00 00000000 04000000 00030000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e3002000 eb061c00 00000000 04000000 00030000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e3002000 f2061c00 00000000 04000000 00030000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e3002000 f3061c00 00000000 04000000 00030000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 91002000 f4031a00 00030000 05000000 00010000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 91002000 f4051a00 00040000 050c0000 00010000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 91002000 f4051a00 00040000 05250000 00010000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 91002000 f4051a00 00040000 053c0000 00010000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 81002000 f3081a00 00070000 05550000 00050000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 81002000 f30a1a00 00080000 056b0000 00070000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 81002000 f30b1a00 00090000 05810000 00080000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 81002000 f30c1a00 000b0000 059a0000 000a0000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30d1a00 000b0000 059f0000 000b0000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f20d1a00 000b0000 05970000 000a0000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30d1a00 000b0000 05910000 000a0000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30c1a00 000a0000 058c0000 00090000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30c1a00 000a0000 05880000 00090000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30c1a00 000a0000 05840000 00090000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30c1a00 000a0000 05800000 00090000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30c1a00 000a0000 057c0000 00080000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30b1a00 00090000 05780000 00080000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30b1a00 00090000 05740000 00080000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30b1a00 00090000 05710000 00080000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30b1a00 00090000 056e0000 00080000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30b1a00 00090000 056b0000 00080000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30a1a00 00080000 05690000 00070000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30a1a00 00080000 05660000 00070000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30a1a00 00080000 05630000 00070000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30a1a00 00080000 05610000 00070000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30a1a00 00080000 055e0000 00070000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30a1a00 00080000 055c0000 00070000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30a1a00 00080000 055a0000 00060000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f30a1a00 00080000 05580000 00060000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f3081a00 00070000 05550000 00060000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f3081a00 00070000 05540000 00060000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000
 e1002000 f3081a00 00070000 05520000 00060000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000

The third and fourth values appear to be the most interesting.

[ledtester]

Since you seem to have a good idea of what the protocol is you could use an Arduino to replay modified versions of the replies to see how the numbers in the UI change.

[Lomax]

Thanks, that's a nice idea - I will keep it in mind!

Right now I'd like to try with the bits all flipped; I've got a suspicion their data may use the opposite levels, but just how to do this in Python eludes me for the moment.

[ledtester]

Maybe you're looking for the bitwise xor operator:

https://python-reference.readthedocs.io/en/latest/docs/operators/bitwise_XOR.html

XOR-ing with 0xFFFF will invert the lower 16-bits, for instance.

[Lomax]

Thanks! Alas, that gave me far too large numbers, also with big-endian order, and pairs of bytes showed nothing that could be relevant. I must have missed something very basic!

[Lomax]

Some further digging. I noticed that the high frequency polling (all 49 requests repeat roughly every 0.5s) is interrupted if I change a value in the GUI. This makes sense since there needs to be time to update the device and read the value back for confirmation. I thought I'd take a look at this data, and managed to capture four presses of the increment button for one of the values ("Transfer Switch Min. AC Voltage"), increasing the value by 1 with each click. It looks on the scope as if each press generates two requests, each with a corresponding response, which seems reasonable. BUT. The data makes no sense whatsoever. For example I would have expected to see some value that incremented by the same amount with each click, but here's what I get (again, requests are in red, followed by the response in black - and grouped for each press):



The first two bytes again can probably be ignored; that's not where the data is, but a command of some sort. The value should be contained in some combination of the following bytes, but I certainly can't see it (should be between 180-200 in decimal, or possibly 1800/18000 depending on precision). Instead I find it in the last byte - which was clearly a checksum in the big chunks of polling data I looked at in my first post (I carefully double checked this on a number of records, both TX & RX - they all matched). The first responses for each press (rows 2,7,12,17) end with BC, BD, BE, BF, which corresponds to 188, 189, 190 and 191 in decimal - the correct values. Whoa.

What kind of oddity am I dealing with here, sometime checksums sometimes not? Why do these four clicks produce such different looking requests? Why aren't the responses always the same length? Does the command sent tell the device to increment the value rather than set it to X?

Here's what the four clicks look like on the scope, overview followed by zoomed in view of one request/response (TX in blue, RX in red):

[RoGeorge]

Have you checked if the protocol is MODBUS?  It's one of the most common protocols when it comes to RS232 or 485 serial devices.

Just out of curiosity, I've searched for "mastervolt" serial protocol and it looks like others tried to decode the protocol, not sure if any of these applies to your charger:  https://github.com/langemeijer/mastervolt-php

https://download.copadata.com/fileadmin/user_upload/Downloads/Dokumentation/760SP0/ENGLISH/Driver/Masterbus32.pdf

[Lomax]

Have you checked if the protocol is MODBUS?  It's one of the most common protocols when it comes to RS232 or 485 serial devices.

Good point, but I'm pretty sure it isn't: I would expect to see 0x01 to 0x16 in the first few TX bytes, these being the Modbus "commands". And I don't think you see much Modbus over RS232; Modbus handles multiple slaves while RS232 can only be connected between two devices. The whole "which slave am I talking to?" part of Modbus would be wasted here. It does have some similarities in how it seems to read consecutive registers though (see the lines beginning C1 F0 26).

Just out of curiosity, I've searched for "mastervolt" serial protocol and it looks like others tried to decode the protocol, not sure if any of these applies to your charger:  https://github.com/langemeijer/mastervolt-php

https://download.copadata.com/fileadmin/user_upload/Downloads/Dokumentation/760SP0/ENGLISH/Driver/Masterbus32.pdf

Yeah, I've looked at those. The "mastervolt-php" protocol has some similarities, but uses different commands and seems less granular. For example, a "get status" command begins B6 00 00 00 and returns a whole bunch of parameters (ten in fact). My "read" commands all begin with C1 F0 and each one only returns four bytes of data (so could hardly contain more than one or two numerical parameters). The "mastervolt-php" protocol runs at 9600 baud, mine at 19200 baud.

The other protocol you mention, "MasterBus", is Mastervolt's current standard. Like so many other manufacturers of this kind of equipment they've switched to a CANBus based network which is totally different from what my older device uses. Unfortunately it seems Mastervolt like changing their mind on this stuff, because I've seen them use several different physical layers and a handful of different protocols, adding to the confusion (yet another example is the protocol used by their "Soladin" PV controllers). The interface and protocol that I have ("PC-Link") is only used on the following devices:

• IVO smart chargers
• Magic DC/DC converters
• Mass chargers
• Mass Combi charger/inverters
• Dakar Generator controls
• BTM-I battery monitors
• BTM-III battery monitors

Interestingly, I see now that the "MasterAdjust" software supports all MasterBus devices as well as those I listed above, although they use a completely different physical layer (CANBus vs RS232). Perhaps this is a hint that my protocol is similar to the MasterBus protocol after all. Hmmm.

[Lomax]

Some things I think I know about the TX data:

It always starts with "C1", followed by either "F0" (read?), "31" (unknown), "42" (write?) or "1B" (unknown). These appear to be the commands, with the first two seen in the polling data and the second two when I alter a setting in the GUI.

The next two bytes in the polling requests very much look like an address, as they can be seen increasing by four bytes with each request in the polling data (see rows 12 to 42). This is followed by four bytes which presumably would be the actual data - usually "00 00 00 00", but sometimes "00 00 00 01", both of which could make sense when you're just doing a read. Following the four data bytes there's a checksum byte, which I have verified to be correct for a dozen requests and responses - the chance that it could be anything else is basically zero.

When changing a setting in the GUI (i.e. doing a "write") there are fewer data bytes, and each change results in two TX packets. The first starts "C1 42" followed by four bytes of something - with no checksum at the end. I know the last byte isn't a checksum here because none of the 16 TX/RX packets I looked at validate using any common checksum algorithm. This strikes me as rather odd, since the "read" commands have checksums, and I'd be interested in hearing your thoughts on this.

The second TX packet, which is sent after the device has replied to the first, is always "C1 1B 00 00 CC", to which the device will also reply. Could this be some kind of acknowledgment?

 

[Lomax]

Following the idea that PC-Link and MasterBus may use a similar structure (since the software supports both), I dug around in someone's reverse engineering effort on GitHub and found the following dictionary:

Code: [Select]

const uint16_t MastervoltDictionary::INVERTER_DC_VOLTAGE_IN=0x06;
const uint16_t MastervoltDictionary::INVERTER_DC_AMPS_IN=0x07;
const uint16_t MastervoltDictionary::INVERTER_AC_AMPS_OUT=0x0b;
const uint16_t MastervoltDictionary::INVERTER_LOAD_PERCENT=0x11;
const uint16_t MastervoltDictionary::INVERTER_AC_VOLTAGE_OUT=0x0a;
const uint16_t MastervoltDictionary::INVERTER_SHORE_FUSE=0x13; //4 Amp offset
const uint16_t MastervoltDictionary::INVERTER_MODE=0x14; //1.0=On 0.0=Off 3==Standby?
const uint16_t MastervoltDictionary::INVERTER_POWER_STATE=0x38; //1.0=On 0.0=Off
const uint16_t MastervoltDictionary::CHARGER_STATE=0x3a; //1.0=On 0.0=Off
const uint16_t MastervoltDictionary::INVERTER_INPUT_GENSET=0x0e; //1.0=On 0.0=Off
Perhaps this will get me a little further.

[Lomax]

No, I think that's a red herring - tried a few but the register numbers don't seem to match. So looking at MasterBus will probably not help much. But I've had one significant break through: I've got the first 100% definite query and the first 100% definite response!

With this query request:

C1     F0         26 94      00 00 00 00          6B
^       ^          ^  ^      ^  ^   ^  ^           ^
??    Read     Register         n/a             Checksum

I get the response:

  F0      C1     26 94      00 00      EA 04         59
  ^       ^       ^  ^       ^  ^       ^  ^          ^
Read     ??    Register     Data        Data     Checksum

"EA 04", or 1258 in little-endian decimal, happens to match exactly the value for "Lowest DC Voltage" on the "History" tab of the MasterAdjust software (12.58 V). If I "clear history" this value defaults to 18.00 V, and a subsequent request for the "26 94" register's data returns "00 00 08 07", with the two last bytes now reading 1800 in little endian decimal. If I disconnect mains input and let the inverter take over the value will start to fall, eventually following the declining battery voltage. There is no doubt whatsoever, this parameter is nailed. One down, 48 to go

[Lomax]

I won't bore you with the gory details, but after tinkering on and off with this for a couple of weeks, some progress has been made:



Still many unknowns - most importantly I haven't been able to extract the battery voltage, which is probably the value I'm most interested in. I've also found quite a few curious quirks, such as not being able to check whether the inverter or charger are switched on without changing their state, forcing me to store state on the application side. Which byte(s) the data arrives in, and what multiplier it uses varies wildly between parameters. PM me if you have one of these units and want to know more; at some point I'll turn my (copious) notes into something others can understand, but that's some way off still...

[james_s]

I think I'd start by trying to identify which blocks represent specific parameters. Find one you can control easily such as the load on the inverter and watch the data coming out as you vary the load, or connect it to a variac and vary the mains voltage. Once you know which group of data represents that value you can capture a series of them representing known values and try to work out how it's encoded. It probably is not anything very complicated, encrypted or deliberately obfuscated.

[Lomax]

I think I'd start by trying to identify which blocks represent specific parameters. Find one you can control easily such as the load on the inverter and watch the data coming out as you vary the load, or connect it to a variac and vary the mains voltage. Once you know which group of data represents that value you can capture a series of them representing known values and try to work out how it's encoded. It probably is not anything very complicated, encrypted or deliberately obfuscated.

This is precisely what I have been doing. Also graphing all the unknowns and changing the conditions, then looking at which values change, when, and by how much. At the same time I try to look at it from the engineer who designed it's perspective, finding patterns, concepts. It is not very complicated, encrypted or deliberately obfuscated, but it's also clearly not designed with third party use in mind. Reeks of "internal tool".

Edit: Forgot to mention that I've also spent a lot of time capturing and analysing the data sent/received by the official application - very useful to be able to look at this, but difficult to capture the right snippets since the app fires off bursts of 40+ queries every second (this cannot be turned off or slowed down), burying the needle I'm looking for in a hexadecimal haystack. Only by diffing parts of repeated captures have I been able to figure out the more involved parts, such as how to alter the state of the device and its configuration parameters.

[james_s]

It is not very complicated, encrypted or deliberately obfuscated, but it's also clearly not designed with third party use in mind. Reeks of "internal tool".

That's to be expected, my guess is that it's designed to interface with a remote panel. I remember my dad had a very similar inverter/charger on his sailboat and it used some kind of digital link to a control panel mounted next to the nav station alongside the AC and DC electrical panels and radio gear. It's also possible that it's just for a factory test fixture, but either way it makes sense that they would design it without any regard to 3rd party use.

[Lomax]

my guess is that it's designed to interface with a remote panel

100% correct, and very obvious when looking at the data; for some responses individual bits directly represent different LEDs on the panel. Once I saw this pattern a lot of stuff came falling out. But it meant I had to look at each 4-byte response in binary to see it. Tedious!

Edit: It really helps that I have an actual remote panel, so I can compare what it shows with the data I see. It's a pretty basic panel though, and there's a lot more data to be fetched from the device itself.

[Lomax]

Here's a snippet from my notes - only covering two out of 40+ queries/commands seen in the wild:

Code: [Select]

37 (0x25) - state:

  sample response [data]:
   240  193   37  [240  193    0    0    0]  135
  0xF0 0xC1 0x25 [0xF0 0xC1 0x00 0x00 0x00] 0x87

first byte (payload[3])

  11 11100 0  252 discharged?
  11 11010 1  245 Error mode?

  11 11111 0  254  100% DC-load (also when switched off)
  11 11110 0  252   75% DC-load
  11 11100 0  248   50% DC-load
  11 11000 0  240   25% DC-load
  11 10000 0  224    5% DC-load
  11 00000 0  192    0% DC-load

  01 00000 0   64  Charger off, inverter off

  00 11111 0   62  100% on inverter?
  00 11110 0   60   75% on inverter?
  00 11100 0   56   50% on inverter
  00 11000 0   48   25% on inverter
  00 10000 0   32    5% on inverter
  00 00000 0    0    cut off / inverter off

second byte (payload[4])

  1111 0011    243

  1111 0001    241  100%

  1110 0011    227   75% inverter soc
  1100 0011    195   50% inverter soc
  1000 0011    131   25% inverter soc
  0000 0011      3    5% inverter soc
  0000 0010      2    0% blinking

  1111 0001    241    charging (float, 17:29, 0.5 Ampere)
  1110 0001    225    charging (absn 2, 16:44,  6 Ampere)
  1100 0001    193    charging (absn 1, 15:41, 32 Ampere)
  1000 0001    129    charging (bulk 2, 15:21, 34 Ampere)
  0000 0001      1    charging (bulk 1, 14:26, 34 Ampere)

  0010 0100     36    low voltage error (inverter)


third byte (payload[5])

  0000 0000
  0100 0000      64    cut off, alarm output?


fourth byte (are these warnings/errors?) (payload[6])

  0011 0101      53    inverter error?
  0010 0101      37    low voltage error?
  0001 0101      21    shore power off? (it's still 21 when inverter off & no shore power)
  0000 0101       5   
  0000 0000       0    shore power on?

fifth byte - unexplored! (payload[7])

  0000 0000

========================================================================

50 (0x32) - change (cannot read without write):

0x06 = both off
0x04 = inverter off
0x02 = charger off
0x00 = ???

first byte (payload[4]) output voltage?
            241               after sending 0x00 or 0x04
            240               after sending 0x00
  1110 1111 239 ???           after sending 0x00 or 0x02
  0000 0000   0 ???           after sending 0x04 or 0x06

second byte (payload[5]) output current?

  0010 0100  36 ???           after sending 0x00
  0001 1100  28 ???           after sending 0x02 (charger off)
  0001 1011  27               after sending 0x00 or 0x04
  0000 0000   0 ???           after sending 0x04 or 0x06

third byte (payload[6])

  0001 1010  26 ???           after sending 0x02 (charger off) or 0x04 or 0x00
  0001 1000  24 AC present?   after sending 0x04 or 0x06 or 0x02

fourth byte (payload[7]) state?

  0000 0110   6 both off
  0000 0100   4 charger on
  0000 0010   2 inverter on
  0000 0000   0 both on

[james_s]

Edit: It really helps that I have an actual remote panel, so I can compare what it shows with the data I see. It's a pretty basic panel though, and there's a lot more data to be fetched from the device itself.

It might be interesting to try going the other direction and connect the panel to your PC and see how it responds to data you send it and what it sends when you operate controls on the panel. It ought to be easier to determine exactly what it will send since you aren't relying on parameters measured by the inverter.