Alexander Grau

Update: the alarms are completely gone - and I don't know why 🙂 Maybe because I temporary disconnected the smart meter from the grid... or because of the firmware combinations. I now have these versions installed: hmi 1001-c037 main 2005-1128-1807 Regarding enabling the "time of use", it's odd but I have to enable it (with the individual times disabled) - otherwise the battery is never discharged (only charged). And I cannot use the CT meter because then the inverter is always working full power (it's making DC from grid AC, then making AC from that DC: grid AC->DC->AC house) without any reason. So there is yeet definitively something odd ongoing here...

So, I have added the CT coils as well. And came across the next 'bug': If you have activated the gen/grid charge timetable (even with no selected entries), the inverter will go (without active PV) the unnecessary way via AC->DC->AC for the load. Once the timetable is deactivated (unchecked), the Deye inverter behaves as with the Watt-meter. Maybe this is also effecting the alarm bug... Also, I noticed that the alarm is gone now (I have activated the Watt-meter again). Another reason could be that I temporary switched off the AC grid connection (to the Watt-meter) yesterday.

No, it does not fit (but it shows there are issues with decoding values correctly). I don't use CT coils. The alarms are probably increasing as the Watt-meter values (importedWh, exportedWh) are accumulating since Wattmeter-reset and the higher values seem to be more affected by the decoding bug... PS: The alarms still appear in the updated firmware (hmi: 1001-c037, main: 200x-1140-0824)

If you tap on the grid symbol and then on 'energy' at the display, you should see something like above. And probably your charts looks odd too. This clearly shows this is not a cable or data transmission issue (because not transmitted or wrong transmitted data would be simply ignored and skipped). This is an IEEE 754 binary-to-float decoding issue at the Deye side (incorrect data interpretation).

I have updated the inverter firmware and HMI firmware (as described here), and hopefully the alarms are gone 😉 ... hmi: 1001-c031 --> 1001-c037 main: 2005-1128-1807 --> 200x-1140-0824

...and this looks odd to me (more than 12 KW peak power?? ) - This shows that the Deye inverter is definitively decoding the Watt-hours-in-out meter data incorrectly (like I did before)...

Having a closer look shows: I did the IEEE 754 binary-to-float decode calculation wrong (will correct it) - and I'm 99% sure the Deye firmware does it wrong too (because the alarm is exactly at the times where my wrong calculation counts backwards ;-)... (if decoded correctly, there is no counting backwards anymore) 4535B502 -> should be decoded as: 2907.31298828125 ( verify here: https://cs.lmu.edu/~ray/demos/ieee754.html ) ... 4535D3F0 -> should be decoded as: 2909.24609375 4535D3F4 -> should be decoded as: 2909.2470703125 4535D3FC -> should be decoded as: 2909.2490234375 4535D404 -> should be decoded as: 2909.2509765625

I'm sorry, I have to correct myself - I see something strange at the alarm times (15:12 and 15:42): 15:10:28.345 -> 2923,2578,104,164,415 Ans: dt=31 (2079) err=14 f=04 pkt:01 04 0C 42 CF 9F C6 43 23 C1 42 43 CF 80 5C 96 CB 104,164,415, 15:10:28.677 -> 2923,2578,104,164,415 Req: dt=340 (2079) err=14 f=10 pkt:AB 10 01 1E 00 02 04 01 F7 00 00 ED 6B 15:10:28.744 -> 2923,2578,104,164,415 Req: dt=65 (2079) err=14 f=04 pkt:01 04 00 48 00 04 71 DF addr=72,cnt=4 15:10:28.777 -> 2907,2578,104,164,415 Ans: dt=29 (2079) err=14 f=04 pkt:01 04 08 45 35 B5 02 45 20 F3 37 F7 44 2907,2578, 15:10:29.175 -> 2907,2578,104,164,415 Req: dt=405 (2079) err=14 f=04 pkt:01 04 00 0C 00 06 B0 0B addr=12,cnt=6 15:10:29.208 -> 2907,2578,140,153,3809 Ans: dt=41 (2079) err=14 f=04 pkt:01 04 0C 43 0B E4 79 43 19 22 A8 45 6D A3 70 A9 C2 140,153,3809, 15:10:29.574 -> 2907,2578,140,153,3809 Req: dt=340 (2079) err=14 f=10 pkt:AB 10 01 1E 00 02 04 01 F7 00 00 ED 6B .......... 15:42:21.057 -> 2923,2579,168,189,4218 Req: dt=337 (2079) err=16 f=10 pkt:AB 10 01 1E 00 02 04 02 59 00 00 8C CE 15:42:21.123 -> 2923,2579,168,189,4218 Req: dt=65 (2079) err=16 f=04 pkt:01 04 00 48 00 04 71 DF addr=72,cnt=4 15:42:21.157 -> 2924,2579,168,189,4218 Ans: dt=29 (2079) err=16 f=04 pkt:01 04 08 45 35 D3 F0 45 20 F3 4C 87 74 2924,2579, 15:42:21.555 -> 2924,2579,168,189,4218 Req: dt=417 (2079) err=16 f=04 pkt:01 04 00 0C 00 06 B0 0B addr=12,cnt=6 15:42:21.588 -> 2924,2579,159,193,4724 Ans: dt=32 (2079) err=16 f=04 pkt:01 04 0C 43 1F 8A 26 43 41 CD 17 45 92 AC FB 98 AC 159,193,4724, 15:42:21.721 -> 2924,2579,159,193,4724 Req: dt=128 (2079) err=16 f=10 pkt:AB 10 01 1E 00 02 04 02 59 00 00 8C CE 15:42:21.787 -> 2924,2579,159,193,4724 Req: dt=65 (2079) err=16 f=04 pkt:01 04 00 48 00 04 71 DF addr=72,cnt=4 15:42:21.821 -> 2924,2579,159,193,4724 Ans: dt=29 (2079) err=16 f=04 pkt:01 04 08 45 35 D3 F4 45 20 F3 4C 76 B4 2924,2579, 15:42:22.120 -> 2924,2579,159,193,4724 Req: dt=305 (2079) err=16 f=04 pkt:01 04 00 0C 00 06 B0 0B addr=12,cnt=6 15:42:22.153 -> 2924,2579,121,187,935 Ans: dt=32 (2079) err=16 f=04 pkt:01 04 0C 42 F1 BE C4 43 3A FE 20 44 69 A8 52 1E 79 121,187,935, 15:42:22.551 -> 2924,2579,121,187,935 Req: dt=383 (2079) err=16 f=10 pkt:AB 10 01 1E 00 02 04 02 11 00 00 0C D8 15:42:22.618 -> 2924,2579,121,187,935 Req: dt=64 (2079) err=16 f=04 pkt:01 04 00 48 00 04 71 DF addr=72,cnt=4 15:42:22.651 -> 2924,2579,121,187,935 Ans: dt=29 (2079) err=16 f=04 pkt:01 04 08 45 35 D3 F8 45 20 F3 4C 66 B5 2924,2579, 15:42:23.083 -> 2924,2579,121,187,935 Req: dt=451 (2079) err=16 f=04 pkt:01 04 00 0C 00 06 B0 0B addr=12,cnt=6 15:42:23.116 -> 2924,2579,154,188,4055 Ans: dt=32 (2079) err=16 f=04 pkt:01 04 0C 43 19 74 A2 43 3B C8 B5 45 7D 2E 4B C3 BE 154,188,4055, 15:42:23.514 -> 2924,2579,154,188,4055 Req: dt=383 (2079) err=16 f=10 pkt:AB 10 01 1E 00 02 04 02 11 00 00 0C D8 15:42:23.581 -> 2924,2579,154,188,4055 Req: dt=65 (2079) err=16 f=04 pkt:01 04 00 48 00 04 71 DF addr=72,cnt=4 15:42:23.581 -> 2924,2579,154,188,4055 Ans: dt=29 (2079) err=16 f=04 pkt:01 04 08 45 35 D3 FC 45 20 F3 4C 97 75 2924,2579, 15:42:23.913 -> 2924,2579,154,188,4055 Req: dt=312 (2079) err=16 f=04 pkt:01 04 00 0C 00 06 B0 0B addr=12,cnt=6 15:42:23.946 -> 2924,2579,167,191,4560 Ans: dt=32 (2079) err=16 f=04 pkt:01 04 0C 43 27 63 88 43 3F 25 C7 45 8D 8F F6 8C 1C 167,191,4560, 15:42:24.278 -> 2924,2579,167,191,4560 Req: dt=337 (2079) err=16 f=10 pkt:AB 10 01 1E 00 02 04 02 57 00 00 ED 0D 15:42:24.344 -> 2924,2579,167,191,4560 Req: dt=65 (2079) err=16 f=04 pkt:01 04 00 48 00 04 71 DF addr=72,cnt=4 15:42:24.377 -> 2909,2579,167,191,4560 Ans: dt=29 (2079) err=16 f=04 pkt:01 04 08 45 35 D4 04 45 20 F3 4C 37 16 2909,2579, 15:42:24.776 -> 2909,2579,167,191,4560 Req: dt=408 (2079) err=16 f=04 pkt:01 04 00 0C 00 06 B0 0B addr=12,cnt=6 => The Eastron meter seem to be counting (importWh, first number) backwards at the alarm times 🙂 - That should not happen

OK, here's another log file. The warnings appeared at 15:12 and 15:42. And at those times, there is no issue in the log file (no CRC error, no timeouts, no wrong decoded data, everything is fine). The alarm is fully random. log_6_2_2024.txt

My sniffer can now decode the data (first shown values are: importWh, exportWh, phase1Power, phase2Power, phase3Power). It looks like there might be an issue at the Deye side with interpretation of this data (maybe with the sign). The error seem to happen here only when the PV panels are starting (or stopping) generating power... I'll further monitor this...

Thanks. I will start decoding the transmitted data now as I wanted to show the transmitted grid data anyways at another location here (and maybe I can find something in it)...

The error appeared again at 11:49 (the previous errors are due to restarting the sniffer) and I have the full sniffing log available. Nothing special there (no delays above 500ms, no CRC errors)... I think the Deye firmware is complaining without a good reason... log.txt

I have improved my sniffer tool, and the CRCs seem to be always correct. I noticed some messages are answered with a delay (up to 500ms or maybe sometimes longer) by the Eastron meter. It could be that the Deye is not tolerant enough for this long delay... (e.g. if it exceeds 500ms)

Maybe the Deye inverter is sending some message packets with incorrect checksum (CRC) to the Eastron... I'll further debug this using my DIY RS485 Modbus RTU sniffer (Arduino code attached)...

I have replaced the cable now (now it's a shielded twisted pair cable, before it was just a twisted pair cable). And this time, I have connected pins 1,8 and pins 2,7 and pins 3,6 at the Eastron meter side too (each pair connected together). Last time I just connected pins 1,2,3 however this could be the problem (because those unconnected pins are connected at the Deye side, and then you have 'open wires' in the cable - basically those act likes antennas and then may receive noise signals...) Addendum: The error just appeared again (also with replaced cable)... 🤣