As I am getting the 0x3c2 messages very frequently I am trying to get some sense out of it. Maybe it's useful. Maybe you'd like to help a bit here?
This is what I already found out:
the option consists of a payload of 59 bytes
bytes 0-3 are always 0x00 0x00 0x33 0x00
bytes 4-7 are a UNIX timestamp in seconds
bytes 8-11 are always zero
bytes 12-15 have some "interesting data", see later
bytes 16-19 are an exact copy of bytes 12-15
bytes 20-51 are always the sequence 0xff 0xff 0x7f 0xff, repeated eight times, BUT, when bytes 12-15/16-19 are zero, the bytes 28-31 are zero too
bytes 52-59 are always zero
The bytes 12-15 are interesting because they have zero inside whenever there is no solar yield (checked with historical data fetched using tcp modus). So I'd say they are something related to yield. I cannot, however, find a factor that makes the value into either a power or a current value that would be related to that moment. So I already checked if they might be two 16 bits values actually, but then the values really don't make sense at all, the first two bytes are all over the place, which would be typical for LSB's. The field makes more sense as a 32 bit value, in my opinion.
It's interesting that if the value is not zero, the last byte (MSB) is always 0x40 or greater. I suspect the first few bits may be flags. I am now trying while masking various high bits.
Do you know any other interesting things I might try?
Also, where did you get the list of commands from (e.g. PROT_CMD_SERVER_POST_DATA = 0x500). Maybe there is more from where that come from, in the meantime?
Regarding the issues I reported earlier, yes I do see that I am frequently missing some received bytes, making the messages corrupt. I have been using various ways of interfacing, so I am starting to think it's either a hardware issue on the inverter's side, but a bit unlikely, as I tried both RS485 interfaces, or maybe even a firmware bug? Manually adding pull up resistors did not help (and the built-in ones, using the DIP switches) are very hard to reach and operate, I'd rather not touch them.
I am on the track that the error recovery might work like TCP, where absence of an ack, after a timeout, results in a retransmission. Problem is the timeout is way too long. So I'ld like to try what happens if I send an (additional) ack about the previous sequence, when I receive a corrupt packet, maybe that will, like TCP, trigger an immediate re-send of the data.
Hi,
As I am getting the 0x3c2 messages very frequently I am trying to get some sense out of it. Maybe it's useful. Maybe you'd like to help a bit here?
This is what I already found out:
The bytes 12-15 are interesting because they have zero inside whenever there is no solar yield (checked with historical data fetched using tcp modus). So I'd say they are something related to yield. I cannot, however, find a factor that makes the value into either a power or a current value that would be related to that moment. So I already checked if they might be two 16 bits values actually, but then the values really don't make sense at all, the first two bytes are all over the place, which would be typical for LSB's. The field makes more sense as a 32 bit value, in my opinion.
It's interesting that if the value is not zero, the last byte (MSB) is always 0x40 or greater. I suspect the first few bits may be flags. I am now trying while masking various high bits.
Do you know any other interesting things I might try?
Also, where did you get the list of commands from (e.g. PROT_CMD_SERVER_POST_DATA = 0x500). Maybe there is more from where that come from, in the meantime?
Regarding the issues I reported earlier, yes I do see that I am frequently missing some received bytes, making the messages corrupt. I have been using various ways of interfacing, so I am starting to think it's either a hardware issue on the inverter's side, but a bit unlikely, as I tried both RS485 interfaces, or maybe even a firmware bug? Manually adding pull up resistors did not help (and the built-in ones, using the DIP switches) are very hard to reach and operate, I'd rather not touch them.
I am on the track that the error recovery might work like TCP, where absence of an ack, after a timeout, results in a retransmission. Problem is the timeout is way too long. So I'ld like to try what happens if I send an (additional) ack about the previous sequence, when I receive a corrupt packet, maybe that will, like TCP, trigger an immediate re-send of the data.
Thanks! Erik.