-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Payload length is too big - VKW Vorarlberg #2
Comments
Can you send me the full packet + decryption key to the mail address on my profile? |
i can't see a mail adress at your profile. |
i sent you an email. this was the serial paket Debug Paket |
@color86 Something seems garbled here, your packet is too long and starts with the wrong byte. Can you try logging over a longer period (like 10 or 20 packets) and posting the log here? edit: I also commited a fixed log_packet method in case you want to use that. |
Hello, here is the new log. [16:12:58][D][api.connection:735]: Home Assistant 2021.9.6 (192.168.1.139): Connected successfully |
It seems like your data is getting cut off for some reason. Can you make sure that the following line is present in your yaml? https://github.com/DomiStyle/esphome-dlms-meter/blob/master/meter01.example.yaml#L37 If yes, can you try increasing the read timeout to 200 and uploading again? https://github.com/DomiStyle/esphome-dlms-meter/blob/master/espdm.h#L34 |
hmm, buffersize is set correct i also set the read timeout to 200 but no change :( |
Is it a Kaifa MA309M? |
Yes a new Kaifa MA309M |
That's strange, do you have an USB to UART adapter available which you can connect to the Mikroe board and a PC to read out the raw data? That would make it easier to see if the ESP is reading incorrect data or the Mikroe board. |
I have orderd one on amazon. i will try it on friday. |
Hello, how should i record the data or is it ok for you? |
Yes, the raw data is ok for me. For some reason there is no header at all in your data (68 FA FA 68), which is unlikely to happen in over 1 minute of capturing. Can you do another longer capture for like 10 minutes? |
here is a longer capture |
I am having the same problem with the tinetz kaifa MA309M. I tried the possible fixes in this thread but no luck. I am using the ESP32 v2 Nodemcu with GPIO 4 & 36 like in the documentation. |
Here is a snippet of the log if it helps, i can send you the decrypt key if you need it [14:05:15][D][espdm:040]: Handling packet |
I'm not using this project, but I'm playing around with a MA309 myself. The serial connection uses even parity, you could try adding this to the
|
@color86 I didn't notice previously that you changed your serial port, please use the port like in the documentation or disable the serial logger:
@Exolor Your packets look good but they're too short, can you post your yaml config? @dbeinder The UART settings depend on which M-Bus to UART adapter is used. |
Sure thing:
|
68 FA FA 68 53 FF F0 C1 67 DB |
I did try it with these settings but sadly no luck. |
https://www.mikroe.com/m-bus-slave-click I am using this converter. |
Afaik the mikroe device just passes the parity bit through. Did the data change after the setting parity to even? |
This is the data with parity even, doesnt seem to change anything |
So one thing i did test was setting the tx_buffer_size in the logger component, now i get longer packets but also "took a long time for an operation". From what i´ve read the packet should end with 16, right? That would be the complete packet then?
|
@Exolor Your packet looks complete now, yes. |
The data has the exact correct length, but there are bitflips in some bytes. One of those mangled bytes encodes the frame length, and decoding fails because the code now expects more data than is actually there. |
I can rule out the ESP32 for now, tested it with different board (d1 mini but esp32) and i get the excact same reading. So either its the meter, the converter or the software. I will rule out the converter later and report back. |
Alright, so with a simple voltage divider 100k/10k i get the correct readings. So the converter was def the problem. |
@Exoler Awesome, so in order to get things working you had to add the voltage divider and add My converter is connected directly to an ESP32 with PoE, so there might be some hardware difference or interference. |
If my hunch about repeated 0 bits is correct, it may help to make the sampling capacitor larger (C2 on the mikroe board) https://www.ti.com/lit/ds/slas222b/slas222b.pdf |
So right now i am using just 2 resistors between the mbus + and - without any other components. It works with both It´s an hardware issue for sure, i will give the C2 a try like @dbeinder suggested, as i get the 68 FA FA 68 53 FF 00 01 packet now. |
@DomiStyle |
Könnt ihr mir bitte sagen, wie genau ich diese 100k und 10k Widerstände einbauen muß, damit das funktionieren könnte? |
Hello,
i have an ESP32 with ESPHome running.
I entered the correct key but I get the following debug messages.
[22:15:25][D][espdm:040]: Handling packet
[22:15:25][E][espdm:062]: Payload length 1 is too big
[22:15:40][D][espdm:040]: Handling packet
[22:15:40][E][espdm:062]: Payload length 1 is too big
[22:15:55][D][espdm:040]: Handling packet
[22:15:55][E][espdm:062]: Payload length 1 is too big
[22:16:10][D][espdm:040]: Handling packet
[22:16:10][E][espdm:050]: Payload length is too big for received data
[22:16:25][E][espdm:036]: Received packet with invalid size
[22:16:25][E][espdm:036]: Received packet with invalid size
[22:16:40][D][espdm:040]: Handling packet
[22:16:40][E][espdm:062]: Payload length 1 is too big
[22:16:55][D][espdm:040]: Handling packet
[22:16:55][E][espdm:050]: Payload length is too big for received data
[22:17:10][D][espdm:040]: Handling packet
[22:17:10][E][espdm:062]: Payload length 1 is too big
[22:17:25][D][espdm:040]: Handling packet
[22:17:25][E][espdm:050]: Payload length is too big for received data
[22:17:40][D][espdm:040]: Handling packet
Do you have any idea whats wrong? Thanks
The text was updated successfully, but these errors were encountered: