mletenay

... and of course some values are signed. In C you should do something like this: #include <stdint.h> // 2 byte values (int16_t)((uint8_t) incomingPacket[0] << 8 | (uint8_t) incomingPacket[1]) // 4 byte values (int32_t)((uint8_t) incomingPacket[0] << 24 | (uint8_t) incomingPacket[1] << 16 | (uint8_t) incomingPacket[2] << 8 | (uint8_t) incomingPacket[3])

Bit shift by 8, but it is a big endian encoding so the most significant byte is on the left. Plus be aware some values need some (sign) conversion magic "if value > 32768 then value = value - 65535". Look at the python sources, they are pretty self descriptive.

It seems various inverter models and/or firmware versions slightly differ in the response data (resp. their lengths). So I've replaced the primitive response length check with proper checksum and response type validation. Now it should be more robust in respect to different inverters.

Can you run the inverter_test.py (with your modified expected lengths) and provide the raw data responses ? I'll take a look at the differences of the data between the firmware versions and adjust the code accordingly.

There's no real need for udp traffic sniffing anymore, I believe we have managed to understand most of the protocol. The python library is still being tweaked here and there, but it is close to being stable. Although java (which Openhab is written in) is my "native" language, to be honest, I don't have much intention (or time to be more precise) to port it there at the moment. I was selecting between Home Assistant and OpenHab, decided for the HA and I'm happy so far.