Unacked data from Nibe VVM225 - Modbus Alarm

[bgarderhagen]

Hi.

As mentioned in other posts, i have struggled with modbus alarms from time to time. I thought i have resolved it by replacing my M5Atom RS485 with a LillyGo CANRS485.

However i got a new alarm this morning precisely 07:00.

I did not fully trust this ESP replacement so i had a Modbus logger running on the same bus.

07:00 5c 0 20 68 50 44 9c 15 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 0 0 0 0 0 0 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 d5 6 8c 2 c 80 0 0 0 07:00 5c 0 20 69 0 49 0 0 0 0 0 0 0 c0 88 17 63 a4 17 0 0 47 15 0 0 2 f5 0 78 0 0 0 0 e2 31 6 0 0 0 87 6 07:00 5c 2 d8 6 07:00 5c 0 20 6b 0 4b 6 0 0 0 0 0 0 6 07:00 5c 2 27 2 c 2 07:00 5c 2 84 6 07:00 5c 15 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 d5 0 0 0 0 0 0 0 15 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 d5 6 0 0 0 0 0 0 0 07:00 5c 0 20 69 0 49 0 0 0 0 0 0 0 c0 88 17 63 a4 17 0 0 47 15 0 0 2 f8 0 78 0 0 0 0 e2 31 6 b 0 0 81 6 07:00 5c 2 db 6 07:00 5c 0 20 6e 1 1 4e 0 0 0 0 0 0 6 07:00 5c 2 27 2 e 2 07:00 5c 2 86 6 07:00 5c 15 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 d5 0 0 0 0 0 0 0 15 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 d5 6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 07:00 5c 2 27 2 e 2 07:00 5c 2 86 6 07:00 5c 0 20 69 0 49 6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 46 15 0 0 2 f8 0 78 0 0 0 0 e2 31 6 6 0 0 8d 6 07:00 5c 2 27 2 c 2 07:00 5c 2 84 6 0 0 0 0 0 0 0 8a 6 07:00 5c 0 20 68 50 44 9c 15 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 0 0 0 0 0 0 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 d5 c9 8c 2 c 80 0 0 15 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 0 0 0 0 0 0 0 0 ff ff 0 0 ff ff 0 0 ff ff 0 0 d5 6

So.

5C 02 27 02 0E 02

This is not acked.

Can anyone tell me what this code is, and is it possible to expand the NibeGW code to do so ? I do not have the skills to patch the code myself.

Thanks a lot :-)

Best regards Bjørn Tore Garderhagen

[elupus]

5c 02 is your extra climate system controller (ECS). This should know be acked by nibegw.

So either your extra climate system have some problem, or by connecting the nibegw you break communication with that system.

[elupus]

Actually no. I don't know what that is. The address is 2 bytes long, so it is sent to 0x0227 which is unknown at this time. You also have data going to 0x0284 and 0x0286 which is unknown too.

I sort of think something is breaking the bus.

[elupus]

Could you spy on the bus without the nibegw connected? You should note, the bus is not modbus, so im not sure what tool you are using to look at it.

Also would be interesting to know what accessories you have.

[bgarderhagen]

Hi.

I have no accessory. I have enabled the Modbus option to activate the bus. Nothing else.

The tool is some simple c# code i made myself just to log what is going on. Windows 11 laptop connected with a USB-RS485 interface together with the LillyGo CANRS485.

Disabeling the Modbus option on VVM225 makes the system run without these alarms.

[bgarderhagen]

This device on my laptop and just dumping the bytes recieved on the com port.

[elupus]

The bus is always active, so could you disable modbus40, disconnect the nibegw in your pump an log the data. Connect he nibegw and log (dont enable modbus40).

[bgarderhagen]

Ok.

I have deactivated the modbus option on the menu. I see that the data on the bus have been reduced alot now. I can make a new log and publish.

However i do see that i have accessory X22 enabled on the menu.

[bgarderhagen]

This is some logs with Modbus option disabled.

15:48 5c 15:48 5c 2 19 6 15:48 5c 41 c9 8c 2 4 80 82 6 15:48 5c 41 c9 55 1 0 dc 6 15:48 5c 41 c9 8b 14 80 10 84 0 81 10 77 0 83 10 78 0 87 10 80 0 11 0 0 0 8 6 15:48 5c 41 c9 88 0 0 c0 88 17 6d b0 1a 0 0 32 0 0 0 0 0 0 78 0 0 0 0 0 30 6 0 0 0 e4 6 15:48 5c 41 c9 89 0 1 c0 89 5 ff ff ff ff 0 4c 6 15:48 5c 41 c9 88 0 0 c0 88 17 6d b1 1a 0 0 32 0 0 0 0 0 0 78 0 0 0 0 0 30 6 1 0 0 e4 6 15:48 5c 41 c9 89 0 1 c0 89 5 ff ff ff ff 0 4c 6 15:48 5c 41 c9 65 0 ed c0 65 9 7f 2 60 2 a7 1 15:48 5c 15:48 5c 2 17 6 15:48 5c 41 c9 8c 2 4 80 82 6 15:48 5c 41 c9 55 1 0 dc 6 15:48 5c 41 c9 8b 14 80 10 84 0 81 10 77 0 83 10 78 0 87 10 80 0 11 0 0 0 8 6 15:48 5c 41 c9 55 1 0 dc 6 15:48 5c 41 c9 8b 14 80 10 84 0 81 10 77 0 83 10 77 0 87 10 80 0 11 0 0 0 7 6 15:48 5c 41 c9 88 0 0 c0 88 17 6d b1 1a 0 0 32 0 0 0 0 0 0 78 0 0 0 0 0 30 6 2 0 0 e7 6 15:48 5c 41 c9 89 0 1 c0 89 5 ff ff ff ff 0 4c 6 15:48 5c 41 c9 65 0 ed c0 65 9 7f 2 60 2 a7 1 15:48 5c 15:48 5c 2 17 6 15:48 5c 41 c9 8c 2 4 80 82 6 15:48 5c 41 c9 88 0 0 c0 88 17 6d b1 1a 0 0 32 0 0 0 0 0 0 78 0 0 0 0 0 30 6 9 0 0 ec 6 15:48 5c 41 c9 89 0 1 c0 89 5 ff ff ff ff 0 4c 6 15:48 5c 41 c9 65 0 ed c0 65 9 7f 2 60 2 a7 1 15:48 5c 15:48 5c 2 17 6 15:48 5c 41 c9 8c 2 4 80 82 6 15:48 5c 41 c9 55 1 0 dc 6 15:48 5c 41 c9 8b 14 80 10 84 0 81 10 77 0 83 10 77 0 87 10 80 0 11 0 0 0 7 6 15:48 5c 41 c9 88 0 0 c0 88 17 6d b1 1a 0 0 32 0 0 0 0 0 0 78 0 0 0 0 0 30 6 b 0 0 ee 6 15:48 5c 41 c9 89 0 1 c0 89 5 ff ff ff ff 0 4c 6 15:48 5c 41 c9 65 0 ed c0 65 9 7f 2 60 2 a7 1 15:48 5c 15:48 5c 2 17 6 15:48 5c 41 c9 8c 2 4 80 82 6 15:48 5c 41 c9 55 1 0 dc 6 15:48 5c 41 c9 8b 14 80 10 84 0 81 10 77 0 83 10 77 0 87 10 80 0 11 0 0 0 7 6 15:48 5c 41 c9 88 0 0 c0 88 17 6d b1 1a 0 0 2e 0 0 0 0 0 0 78 0 0 0 0 0 30 6 5 0 0 fc 6 15:48 5c 41 c9 89 0 1 c0 89 5 ff ff ff ff 0 4c 6 15:48 5c 41 c9 65 0 ed c0 65 9 7f 2 60 2 a7 1 15:48 5c 15:48 5c 2 17 6 15:48 5c 41 c9 8c 2 4 80 82 6 15:48 5c 41 c9 55 1 0 dc 6 15:48 5c 41 c9 8b 14 80 10 84 0 81 10 77 0 83 10 77 0 87 10 80 0 11 0 0 0 7 6 15:48 5c 41 c9 88 0 0 c0 88 17 6d b1 1a 0 0 2e 0 0 0 0 0 0 78 0 0 0 0 0 30 6 6 0 0 ff 6 15:48 5c 41 c9 89 0 1 c0 89 5 ff ff ff ff 0 4c 6 15:48 5c 41 c9 65 0 ed c0 65 9 7f 2 60 2 a7 1 15:48 5c 15:48 5c 2 17 6 15:48 5c 41 c9 8c 2 4 80 82 6 15:48 5c 41 c9 55 1 0 dc 6

No difference in the log at this point regardless of the LillyGo connected or not.

Could the Address 02 27 be related to X22 option that the VVM225 expected the Modbus40 adapter to ack ?

btg

[elupus]

That log is weird. You have single 5c`s in there without data. Those will confuse the nibegw.

[elupus]

Do you do any parsing in your c# code or just break on 5c?

[bgarderhagen]

Don't put to much into it. Just wipped something together to start each line with 5c.

Let me check...

[bgarderhagen]

Yes. The empty start is from a few lines of code used to filter away address 41 c9 previously.

Cleaned up log. No difference with or without the nibegw connected.

16:47:56 5c 41 c9 8c 02 04 80 82 06 16:47:57 5c 41 c9 55 01 00 dc 06 16:47:57 5c 41 c9 8b 14 80 10 75 00 81 10 3d 00 83 10 2f 00 87 10 75 00 11 00 00 00 11 06 16:47:57 5c 41 c9 88 00 00 c0 88 17 72 c5 1f 00 00 14 01 00 00 00 00 00 78 00 00 00 00 00 30 06 01 00 00 ad 06 16:47:57 5c 41 c9 89 00 01 c0 89 05 ff ff ff ff 00 4c 06 16:47:57 5c 41 c9 65 00 ed c0 65 08 33 03 83 02 f0 00 88 02 66 06 16:47:57 5c 41 c9 8c 02 04 80 82 06 16:47:57 5c 41 c9 55 01 00 dc 06 16:47:58 5c 41 c9 8b 14 80 10 75 00 81 10 3d 00 83 10 2f 00 87 10 75 00 11 00 00 00 11 06 16:47:58 5c 41 c9 88 00 00 c0 88 17 72 c5 1f 00 00 14 01 00 00 00 00 00 78 00 00 00 00 00 30 06 02 00 00 ae 06 16:47:58 5c 41 c9 89 00 01 c0 89 05 ff ff ff ff 00 4c 06 16:47:58 5c 41 c9 65 00 ed c0 65 08 33 03 83 02 f0 00 88 02 66 06 16:47:58 5c 41 c9 8c 02 04 80 82 06 16:47:58 5c 41 c9 55 01 00 dc 06 16:47:58 5c 41 c9 8b 14 80 10 75 00 81 10 3d 00 83 10 2f 00 87 10 75 00 11 00 00 00 11 06 16:47:59 5c 41 c9 88 00 00 c0 88 17 72 c5 1f 00 00 14 01 00 00 00 00 00 78 00 00 00 00 00 30 06 05 00 00 a9 06 16:47:59 5c 41 c9 89 00 01 c0 89 05 ff ff ff ff 00 4c 06 16:47:59 5c 41 c9 65 00 ed c0 65 08 33 03 83 02 f0 00 88 02 66 06 16:47:59 5c 41 c9 8c 02 04 80 82 06 16:47:59 5c 41 c9 55 01 00 dc 06 16:47:59 5c 41 c9 8b 14 80 10 75 00 81 10 3d 00 83 10 2f 00 87 10 75 00 11 00 00 00 11 06 16:48:00 5c 41 c9 88 00 00 c0 88 17 72 c5 1f 00 00 14 01 00 00 00 00 00 78 00 00 00 00 00 30 06 06 00 00 aa 06 16:48:00 5c 41 c9 89 00 01 c0 89 05 ff ff ff ff 00 4c 06 16:48:00 5c 41 c9 65 00 ed c0 65 08 33 03 83 02 f0 00 88 02 66 06 16:48:01 5c 41 c9 8c 02 04 80 82 06 16:48:01 5c 41 c9 55 01 00 dc 06 16:48:01 5c 41 c9 8b 14 80 10 75 00 81 10 3d 00 83 10 2f 00 87 10 75 00 11 00 00 00 11 06 16:48:01 5c 41 c9 88 00 00 c0 88 17 72 c5 1f 00 00 14 01 00 00 00 00 00 78 00 00 00 00 00 30 06 09 00 00 a5 06 16:48:01 5c 41 c9 89 00 01 c0 89 05 ff ff ff ff 00 4c 06 16:48:01 5c 41 c9 65 00 ed c0 65 08 33 03 83 02 f0 00 88 02 66 06 16:48:02 5c 41 c9 8c 02 04 80 82 06 16:48:02 5c 41 c9 55 01 00 dc 06 16:48:02 5c 41 c9 8b 14 80 10 75 00 81 10 3d 00 83 10 2f 00 87 10 75 00 11 00 00 00 11 06 16:48:02 5c 41 c9 55 01 00 dc 06 16:48:02 5c 41 c9 8b 14 80 10 75 00 81 10 3d 00 83 10 2f 00 87 10 75 00 11 00 00 00 11 06 16:48:02 5c 41 c9 88 00 00 c0 88 17 72 c5 1f 00 00 14 01 00 00 00 00 00 78 00 00 00 00 00 30 06 0b 00 00 a7 06 16:48:02 5c 41 c9 89 00 01 c0 89 05 ff ff ff ff 00 4c 06 16:48:03 5c 41 c9 65 00 ed c0 65 08 33 03 83 02 f0 00 88 02 66 06 16:48:03 5c 41 c9 8c 02 04 80 82 06

[elupus]

Okey that looks more like i expected. Now turn on modbus40. First log with no nibegw connected. The pump will alarm, but will keep on sending data. Then hook up the nibegw again and post these two logs.

[bgarderhagen]

Reset the alarm before connecting nibegw ?

[bgarderhagen]

.. or keep alarm active while logging with nibegw connected ?

[elupus]

Doesnt matter. I do see something additionally strange here. The length field is messed up for: 5c 41 c9 88 Xx 5c 41 c9 89 Xx 5c 41 c9 65 xx

This will cause parser to reset. Weird.

[bgarderhagen]

ok.

Here are two logfiles.

I found out what the single 5c line was. My code to detect start frame is not that advanced and breakes a message if 5c is part of the data part of the frame.

modbus-enabled-connected-nibegw.log modbus-enabled-no-nibegw.log

[bgarderhagen]

17:19:10 5c 41 c9 65 00 ed c0 65 09 8f 02 17:19:10 5c 17:19:10 5c 02 c7 01 8f 02 68 06

Supposed to be

17:19:10 5c 41 c9 65 00 ed c0 65 09 8f 02 5c 02 c7 01 8f 02 68 06

[bgarderhagen]

This logfile is from this morning when i got the alarm. Timestamp on the alarm is 07:00 in Nibe Uplink app.

This logfile is made with my fist version of 5c detection.

How does the nibegw code detect start frame ? Can it be that 5c as part of the data messes with nibegw ?

logfile from this morning when i got the modbus alarm.txt

[elupus]

We expect 5c's to be repeated, so that looks to make sense.

[elupus]

Okey..I still can't make sense of the morning log file, it is very hard to understand what is real weird ness and what as due to the parsing

The other logs do look as expected.

Could you turn modbus40 back on again now that the logs looks good. Then see if you can catch a an error again. Also if you have not done so, make sure you update the component, and keep log level in esphome at default levels. Logging adds cpu load, which can break things.

[bgarderhagen]

The component where build when i switched out the M5 with LillyGo on thursday. All settings are default. Expect that to be ok.

I will run my improved logger and post next time i get Modbus error.

[bgarderhagen]

My Yaml file.

lillygo.yaml.txt

[bgarderhagen]

ok. New error. 23:27

new error 2327.log

A few log items look really suspicus 23:27:28 5c 02 84 06 23:27:28 5c 41 c9 8c 02 0c 80 8a 06 23:27:28 5c 41 c9 55 01 00 dc 06 23:27:28 5c 41 c9 8b 14 80 10 84 00 81 10 83 00 83 10 9b 00 87 10 95 00 11 03 20 00 29 06 23:27:28 5c 00 20 6b 00 4b 23:27:28 5c 00 20 6b 00 4b 23:27:29 5c 00 20 6b 00 4b 23:27:29 5c 00 20 69 00 49 23:27:29 5c 00 20 69 00 49 23:27:29 5c 00 20 69 00 49 23:27:29 5c 41 c9 88 00 00 c0 88 17 62 9e 15 00 00 50 16 00 00 03 20 00 78 00 00 00 00 e2 31 06 02 00 00 7c 06 23:27:29 5c 41 c9 89 00 01 c0 89 05 ff ff ff ff 00 4c 06

[elupus]

It completely stops responding from 23:27:26. It could have something to do with the 5c sent from the external compressor.

Ps. Really usefull log

[bgarderhagen]

Do we have uptime from ESP32 that can be monitored ? To see if it crashes ?

[elupus]

Its standard esphome, so you should be able to add it

[elupus]

Can you upgrade the component again to https://github.com/elupus/esphome-nibe/releases/tag/v2.2.0. I made a extra fix for handling the case of multiple 5c's in other nodes transmissions.

[bgarderhagen]

Thanks.

Installed :-)

[bgarderhagen]

Hi again. Looked very promising.

New alarm 10:09 (timestamp from Nibe Uplink)

Debug log - Alarm 10-09.log

[elupus]

Something is very fishy with that log. Look at: 10:08:20 5c 41 c9 88 00 00 c0 88 17 70 a8 18 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 f6 41 c9 8c 02 0c 80 8a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 63 13 00 00 02 e1 00 78 00 00 00 00 e1 31 06 01 00 00 a3 06

That very much looks like its some parts inter compressor communication and some parts modbus40 comms from the pump.

5c
# First we have some stuff going to a compressor
41 c9 88 00 00 c0 88 17 70 a8 18 00

# These very probably modbus parameter lists requested (of which you have none set)
ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 f6

# Then we again have some inter pump com
41 c9 8c 02 0c 80 8a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 63 13 00 00 02 e1 00 78 00 00 00 00 e1 31 06 01 00 00 a3 06

It sort of again feels like a cabling problem. Looks weird though

[bgarderhagen]

Cabeling:

10 cm from terminal to LillyGo, then 70 cm to USB-RS485 adapter. No termination resistors.

Last eavening, i enabled quite a lot of Diagnostic values in Home Assistant "Nibe Heatpump" device.

[elupus]

You must also have cables between your compressor and control unit or external fan unit. They may be on different connectors on the hardware, but its the same bus.

[bgarderhagen]

I expect there already are proper comms cables between the outdoor F2050 unit and the Indoor VVM225 since the installer started up my heating system this summer. Everything works fine, and most data are available in Nibe Uplink.

I am only struggling with these modbus alarms from time to time after enabling the Modbus option from the menus. I have a feeling that the occurrence of these alarms was reduced after your latest fix. I will monitor more over a few more days.

I have a Modbus40 device here that I have borrowed from a friend, if you like me to use this and log. We might learn what this device does differently compared to NibeGW ack-ing the VVM225.

[bgarderhagen]

My heating system dashboard in Home Assistant.

[elupus]

Sure could be interesting. I just meant its the same bus line. So if something with termination is bad on that line it may work just fine when its just that connected , but break when something else is connected.

[bgarderhagen]

Do you know where any termination resistors is supposed to be ?

[elupus]

Wrong button.. would have to look at the installation manual for the pump. They may be built into the devices too.

[bgarderhagen]

:-)

I will reduce the length of the cables even more, and test over more days.

[bgarderhagen]

Hi.

Here is an update. I have sporadically received new errors. Four in total during the last 4 days. First alarm where after 32 hours of perfect operation. Then two alarms with only minutes apart.

I think this is related to detection of frame start. 5C can in some cases be part of the data of an on-going frame together with combination of matching addresses and ack from the previous frame. I will investigate further. My plan for this weekend is to try to build a better logger to understand even better what happens. Then try to log traffic between my VVM225 and the borrowed Modbus40 device.

Will post more later.

[elupus]

I think you analysis is correct. I tried to solve the 5c inside other data case. So i thought i had that fixed. Feel free to double check https://github.com/elupus/esphome-nibe/commit/2f415529b73c3513d6c79954611c2869f4cbc715 is in place in what you build.

[bgarderhagen]

Yes.

Found that change, and it's included in my running code that stills enters alarm from time to time.

Question: Does the NibeGW have to respond to any frames not starting with 5C 00 20 ?

My plan is now to try to create a logger using two RS-485 interfaces on a computer. I will try to be "man in the middle" between VVM225 and orginal Modbus40.

This would hopefully shed some light on who is sending and responding to what. Not sure if code can quickly relay received serial data from interface 1 to interface 2 and the other way without breaking anything.

Something like this:

But.. My wife forces me to drink beer now. Have to nerd more tomorrow :-) Have a nice weekend

[elupus]

Hehe, still haven't gotten to the 🍺 yet. Still at my day (night?) job.

In theory it should only ever need to ack things starting with 5c 00 20. That is a message targeted at modbus40

[bgarderhagen]

Update to my alarms.

I got a lot of alarms this weekend. Ended up with connecting the Modbus40 device now and i am doing logging to file in paralell.

Working theory:

When 0x5c is part of data, it's repeated. It seems like NibeGW code is not doing that. Look at this log, NibeGW to heatpump:

16.11 18:00:17:19 5c 00 20 6b 00 4b 00 5c 00 20 69 00 49 c0 69 02 88 9c bf 06 06

Log from heatpump to NibeGW: 16.11 17:52:37:39 5c 00 20 6a 07 ec 9f 5c 5c f0 ff ff ce 06

Any thoughts on this?

[elupus]

Your first line is two message series 5c00206b004b 00 5c0020690049 c06902889cbf0606

First a request for write from heat pump, invalid 00 as ack response and then a read with a proper response from gw,

Then you get a response on this read request from the pump.

Only wrong thing i can see at a glance is that 00 at end of my line 1.

Ps above by memory, not parsed it fully.

[bgarderhagen]

hmm... i am currently logging data to original modbus40 device. The log file from 16/11 migth be from a logger version with bugs.

I will run logging on the modbus40 for another day or two, just to be sure that i do not have any new modbus alarms with only nibe components.

Here are the logfile until now.

PS. I am replacing frame start 5C with START in the log file, to make me able to search for 5c in other bytes than frame start.

serial_log_2023-11-21.log

I will be back in a few days with same logger version, but with the latest nibegw connected instead of Modbus40

[bgarderhagen]

Hi.

So, running the orginal Modbus 40 adapter was no fun :-) No alarms for more than 24 hours. I replaced it with the LillyGo a few hours ago and running the ChatGPT improved logger.

21:07, new alarm.

This time, i am quite imressed with the logs. Please have a look at 21:07:53.

It looks like the LillyGo has frozen up or something. It's not sending ACK or NACK

serial log alarm 21-07-53.txt

[elupus]

Well your parser get confused here: START 00 20 6B 00 4B 5C 00 20 6B 00 4B 5C 00 20 6B 00 4B 5C 00 20 69 00 49 5C 00 20 69 00 49 5C 00 20 69 00 49 5C 41 C9 88 00 00 C0 88 17 7A C1 1E 00 00 6F 23 00 00 03 66 00 78 00 00 00 00 0F 31 06 02 00 00 91 06

That is actually: START 00 20 6B 00 4B 5C 00 20 6B 00 4B 5C 00 20 6B 00 4B 5C 00 20 69 00 49 5C 00 20 69 00 49 5C 00 20 69 00 49 5C 41 C9 88 00 00 C0 88 17 7A C1 1E 00 00 6F 23 00 00 03 66 00 78 00 00 00 00 0F 31 06 02 00 00 91 06

But yes, the gw is not responding there and again we have double 5c on the line before: START 41 C9 8B 15 80 10 BD 00 81 10 BD 00 83 10 D6 00 87 10 CF 00 11 03 5C 5C 00 18 06

The old code would get confused at that. But the new code should not. Strange.

[bgarderhagen]

My logger detects start frame by looking for the 06 from the frame before. Without this ack it does not write new frame start. This is why i am suspecting the LillyGo to freze and not ack. Missing ack (or nack) will fire the modbus alarm on the vvm225.

Here is my c# code running the logger. Program.cs.txt

[bgarderhagen]

How can we find out why the frames are not ack'ed ?

I have made an UDP listner on my network just to see if any other network traffic is messing up the gw. Nothing so far.