leodesigner / powmr4500_comm

PowMr 4500W/6500W Inverter communication protocol
GNU General Public License v3.0
12 stars 2 forks source link

ESPhome integration #1

Open lufton opened 11 months ago

lufton commented 11 months ago

Hi, I have similar but 6500W version of inverter. Is there any chance your protocol can be integrated with this project? I was trying to use that one, but it didn’t work for me. Now it’s clear why. Also, FYI, I found out that this inverter sold by different brand name:

And it looks like they all use DTU WBS1-V001 module for communication and Solar House (iOS)/Hy-Power (Android) application.

lufton commented 4 months ago

@G-Christ, sorry, no more ideas. I gave up and bought original DTU when I was where you are at right now.

G-Christ commented 4 months ago

@lufton,

All right. So, no body succeeded yet through esp8266 or esp32. Maybe as you mention in one of your posts, data is processed by the DTU. I have already got the DTU and will give it a try very soon,

I'll get back with an update on that.

G-Christ commented 4 months ago

@lufton I followed your instructions at https://github.com/lufton/esphome-inv-8851?tab=readme-ov-file and flashed the DTU. unfortunately I get same errors like with the esp8266 image

Haven't you done any modifications on your side to the local copy of the component files? If not, what else can be wrong?

I am compiling, flashing and connecting to it from Home assistant, Are you doing that too?

Would it be an idea that you compile a bin fil for me with hardcoded values:

and send it to ghassan@nahhas.dk?

Thanks :)

G-Christ commented 4 months ago

Hello again,

Now I started looking at the code:

I can see the error message comes from the Inv8851::loop() in inv_8851.cpp my responses vary in length (have seen values like 142, 148, 149 and 150) while the code expectes 154 or 100.

Could the reason be some trailing zeros are removed or something similar? or could it be difference in the firware version. Mine is running : 47.04

I am tryning to print the received response but dit not succced yet.

another thing, in inv_8851.h there is #include inv8851.h but this last file is not included, I see it is in @leodesigner rerpository. I wonder how the compilation does not fail or is that repository included indirectly somewhere?

We might need yo engage @leodesigner ! Can you probably assist here? we might need a new version of #include inv8851.h corrsponding to my firmware.

Thanks both :)

G-Christ commented 4 months ago

@leodesigner @lufton

I managed to get some messages out. Hope this helps figuring out what is going on and how to fix it.

[00:20:38][D][uart_debug:114]: >>> 88 51 00 03 00 00 00 00 4D 08 [00:20:38][W][inv_8851:064]: There was a message with length 120, that can't be parsed. [00:20:38][D][uart_debug:114]: <<< 88 51 00 03 00 00 94 00 55 30 85 0B 00 00 00 00 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60 12 00 00 00 00 00 00 00 00 00 00 00 00 F9 08 9E 00 88 13 6A 01 22 00 FA FF 0D [00:20:38][W][inv_8851:064]: There was a message with length 38, that can't be parsed. [00:20:38][D][uart_debug:114]: <<< 00 05 00 00 00 0F 00 00 00 EE FF 00 00 00 00 00 00 00 00 00 00 00 00 A9 14 FA FF 00 00 00 00 74 00 16 00 00 00 22 0F 00 00 AC FF 00 00 00 00 33 30 26 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 29 2B [00:20:43][D][uart_debug:114]: >>> 88 51 00 03 02 00 00 00 4C B0 [00:20:43][W][inv_8851:064]: There was a message with length 104, that can't be parsed. [00:20:43][D][uart_debug:114]: <<< 88 51 00 03 02 00 5E 00 20 14 EF C4 64 19 FC 08 88 13 00 00 00 00 B8 0B B8 0B B8 0B 50 0A 72 15 84 03 38 18 70 17 F8 11 5C 12 50 0A B8 0B F0 0A 7C 15 E0 15 18 15 C0 12 64 00 F4 01 64 00 00 00 00 00 3C FB 32 00 3C EC 32 F6 7C 15 88 13 F4 01 24 13 08 00 5A 5A 50 5A 5A 50 D0 16 3C 00 3C 00 1E 00 32 5F 14 00 B7 61 [00:20:48][D][uart_debug:114]: >>> 88 51 00 03 00 00 00 00 4D 08 [00:20:48][W][inv_8851:064]: There was a message with length 120, that can't be parsed. [00:20:48][D][uart_debug:114]: <<< 88 51 00 03 00 00 94 00 55 30 85 0B 00 00 00 00 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60 12 00 00 00 00 00 00 00 00 00 00 00 00 F9 08 9E 00 88 13 6A 01 22 00 FA FF 0D [00:20:48][W][inv_8851:064]: There was a message with length 38, that can't be parsed. [00:20:48][D][uart_debug:114]: <<< 00 05 00 00 00 0F 00 00 00 ED FF 00 00 00 00 00 00 00 00 00 00 00 00 A9 14 FA FF 00 00 00 00 74 00 16 00 00 00 22 0F 00 00 AC FF 00 00 00 00 33 30 27 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0B 85 [00:20:53][D][uart_debug:114]: >>> 88 51 00 03 02 00 00 00 4C B0 [00:20:53][W][inv_8851:064]: There was a message with length 104, that can't be parsed. [00:20:53][D][uart_debug:114]: <<< 88 51 00 03 02 00 5E 00 20 14 EF C4 64 19 FC 08 88 13 00 00 00 00 B8 0B B8 0B B8 0B 50 0A 72 15 84 03 38 18 70 17 F8 11 5C 12 50 0A B8 0B F0 0A 7C 15 E0 15 18 15 C0 12 64 00 F4 01 64 00 00 00 00 00 3C FB 32 00 3C EC 32 F6 7C 15 88 13 F4 01 24 13 08 00 5A 5A 50 5A 5A 50 D0 16 3C 00 3C 00 1E 00 32 5F 14 00 B7 61 [00:20:58][D][uart_debug:114]: >>> 88 51 00 03 00 00 00 00 4D 08 [00:20:58][W][inv_8851:064]: There was a message with length 120, that can't be parsed. [00:20:58][W][inv_8851:064]: There was a message with length 38, that can't be parsed. [00:20:58][D][uart_debug:114]: <<< 88 51 00 03 00 00 94 00 55 30 85 0B 00 00 00 00 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60 12 00 00 00 00 00 00 00 00 00 00 00 00 F9 08 9E 00 88 13 6A 01 24 00 FB FF 0E 00 05 00 00 00 10 00 00 00 ED FF 00 00 00 00 00 00 00 00 00 00 00 00 A8 14 F8 FF 00 00 00 00 75 00 16 00 00 00 22 0F 00 00 AC FF 00 00 00 00 34 2F 27 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00:20:58][D][uart_debug:114]: <<< 00 00 00 00 00 00 3E 8E [00:21:03][D][uart_debug:114]: >>> 88 51 00 03 02 00 00 00 4C B0 [00:21:03][W][inv_8851:064]: There was a message with length 104, that can't be parsed. [00:21:03][D][uart_debug:114]: <<< 88 51 00 03 02 00 5E 00 20 14 EF C4 64 19 FC 08 88 13 00 00 00 00 B8 0B B8 0B B8 0B 50 0A 72 15 84 03 38 18 70 17 F8 11 5C 12 50 0A B8 0B F0 0A 7C 15 E0 15 18 15 C0 12 64 00 F4 01 64 00 00 00 00 00 3C FB 32 00 3C EC 32 F6 7C 15 88 13 F4 01 24 13 08 00 5A 5A 50 5A 5A 50 D0 16 3C 00 3C 00 1E 00 32 5F 14 00 B7 61 [00:21:08][D][uart_debug:114]: >>> 88 51 00 03 00 00 00 00 4D 08 [00:21:08][W][inv_8851:064]: There was a message with length 120, that can't be parsed. [00:21:08][D][uart_debug:114]: <<< 88 51 00 03 00 00 94 00 55 30 85 0B 00 00 00 00 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60 12 00 00 00 00 00 00 00 00 00 00 00 00 F9 08 9E 00 88 13 6A 01 22 00 FB FF 0D [00:21:08][W][inv_8851:064]: There was a message with length 38, that can't be parsed. [00:21:08][D][uart_debug:114]: <<< 00 05 00 00 00 0F 00 00 00 ED FF 00 00 00 00 00 00 00 00 00 00 00 00 A8 14 F8 FF 00 00 00 00 75 00 17 00 00 00 22 0F 00 00 AC FF 00 00 00 00 34 2F 27 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 DB 80 [00:21:13][D][uart_debug:114]: >>> 88 51 00 03 02 00 00 00 4C B0 [00:21:13][W][inv_8851:064]: There was a message with length 104, that can't be parsed. [00:21:13][D][uart_debug:114]: <<< 88 51 00 03 02 00 5E 00 20 14 EF C4 64 19 FC 08 88 13 00 00 00 00 B8 0B B8 0B B8 0B 50 0A 72 15 84 03 38 18 70 17 F8 11 5C 12 50 0A B8 0B F0 0A 7C 15 E0 15 18 15 C0 12 64 00 F4 01 64 00 00 00 00 00 3C FB 32 00 3C EC 32 F6 7C 15 88 13 F4 01 24 13 08 00 5A 5A 50 5A 5A 50 D0 16 3C 00 3C 00 1E 00 32 5F 14 00 B7 61

G-Christ commented 4 months ago

My responses are 4 bytes longer each, Config: 104 bytes, Status: 158 bytes starts with same 8 bytes as yours like " 88 51 00 03 02 00 5E 00" but the data part is 4 bytes longer and very likely arranged in another order.

Is there a way we can get the official format then we can make a corresponding version of inv8851.h and the user can choose which suites the firmware of his inverter?

Otherwise, the config part can be figured out manually by changing one parameter at at time(directly on the inverter) and locate the change in the response, as we know the expected values. while I think it is more difficult with the status as many of these values are changing all the time.

It is geeting too late. Good night :)

lufton commented 4 months ago

@G-Christ, I remember I got similar “There was a message with length 120, that can't be parsed”. It was due to ESPHome default read buffer or something like that. I think I have managed to solve that by specifying rx_buffer_size of UART component. Also I think I remember that such a behavior was related to logging. Try disable logger component or increase uart_debug log level. It was something like if it prints received messages in the log then it can’t read the full message but splits it in parts. Then you get this 120 characters long and the rest 38 or whatever.

G-Christ commented 4 months ago

@lufton Thanks for the input. This explains the split, i will look into it. But still my resposes are 4 bytes longer each. I think this is due to firmware version. What version is running on your inverter?

And are you running esphome from Home Assistant?

lufton commented 4 months ago

@G-Christ if you are talking about version displayed on the screen, then mine is 00.05. But I doubt there should be a difference as protocol should be standard as DTU should be compatible with all revisions of inverter.

G-Christ commented 4 months ago

@lufton I have spent a lot of time trying to fix the package splittng i disbaled logging increased buffer size but did not succed. `logger: baud_rate: 0

uart: id: uart_0 baud_rate: 9600 tx_pin: GPIO4 rx_pin: GPIO5 rx_buffer_size: 3000 ` If i run the local package files I still get as earlier three different response sizes: 104, 120 and 38 bytes and I believe that the last two are one response split into two packages.

if I run the online packages, i get different response sizes; 104, 142 and 262, which sometimes is split into 224 and 38.

And I do have version 47.04 or just 4.
image

Did you upgrade yours somehow? I am quite convinced this could be the reason for different response sizes.

I might be missing something or something is different on your side.

It will be helpfull if you can compile a version for me with the following:

Then I can use your bin file to flash my DTU. please send it to ghassan@nahhas.dk

Thanks :)

G-Christ commented 4 months ago

@lufton ,

Break through :)

My status response is split into two packages 120 and 38 bytes, but the 38 part is always just zeros.

I made a local copy of inv8851.h where I adjusted the constant inv8851_state_pkt_len from 154 to 120, and commented/removed the last 34 bytes (17 variables) from the struct inv8851_state_s. . Compiled , flashed the DTU and then got status response to work. Luckelly there were no changes in the protocol, which values are stored where and in which format.

Now I have all status values integrated in my Home assistant, added these to a dashboard and most import I made an automation controlling when to turn the AC input on/off based on the battery voltage, as the SBU funtion in the inverter don't work

image

image

I will try a similar approach to the config part.

I am so happy and gatefull for the work you and @leodesigner have done.

Kind regards, Ghassan

lufton commented 4 months ago

@G-Christ glad to hear. It would be great to understand why your inverter’s communication protocol behaves differently.