Integration stopped working yesterday: Received message has unexpected length. (expected: 113 got: 114) (2584) #24
Comments
|
I had a look in my cellar: The heating unit made an update yesterday... Here the new DAQ string, which got the integration working again:
|
|
Does anybody know how to disable the automatic updates? |
|
I had the exact same issue, the firmware was updated and the integration stopped working without any previous (or subsequent) notification from Hargassner. I also had to manually update the DAQ string in the config file to get it working again. Maybe it helps to disable the "Maintenance by Hargassner" option in their web portal? Might be worth a try. |
Add "NANO_V141O3" (V14.1 HAR o3) from our own heater and "NANO_V14O4" from @iamthe1st from issue TheRealKillaruna#24
|
Added my own NANO_V141O3 now and the one @iamthe1st mentioned :) |
|
I'm not sure what the technician did today, but I somehow have a different format after his visit today even tho I'm on the same exact firmware version as before... This has been added afterwards now. I'll add this as |
Yes. To disable the automatic update:
btw: Its not possibe (at least at the moment), to disable automatic updates inside the app |
|
Hi, The problem persists again after the heating system has been updated. Reading out the msgformat again did not resolve the error. Hargassner: 2024-08-30_15:12:17 KD=Hargassner HA-Version: Core 2024.8.3 I also thought that the msg format had changed again but after reading and saving again the error persists: HargassnerBridge._update(): Received message has unexpected length. Has anyone already found a solution to the problem? |
|
For me too. The "...p1" update seems to make something different. I have no time to look deeper into this at the moment. As a workaround I disabled the length check in hargassner.py. really ugly, I know, but the system keeps running at least for the most values, till a real fix is available |
|
Sad to hear that the update breaks the integration :-/ - I was too dumb and lazy to deactivate the Hargassner update, while It was possible... Now it is also stopped working for me. I hope somebody is able to fix it :-) |
|
In my last daq string, I replaced the Umlaute with ae or ue and ß with ss. - maybe this would help? Without that, it did not work for me. |
|
Umlauts were never a problem for me... weird... But what I noticed when quickly comparing my two data sets "...p" vs. "...p1" is that the "...p" had three more channels (CHANNEL 119, 120 and 121) than the "...p1". The p1 data set seems to be complete, the differences are in the middle of the data. |
|
Please fix @TheRealKillaruna |
|
I added a possible fix yesterday. Also we should debug here more, see my issue from yesterdayand the corresponding pull request... |
Thanks for the customisation. If I change this accordingly, the error changes to this error message: Nano-PK 15 HargassnerBridge.async_update(): Unexpected message length. Expected: 114, Actual: 116 HargassnerBridge.async_update(): Unexpected message length. Expected: 114, Actual: 116 HargassnerBridge.async_update(): Unexpected message length. Expected: 114, Actual: 116 Unfortunately, I can't make heads or tails of the false report either. |
|
NanoPK 20: HargassnerBridge.async_update(): Unexpected message length. Expected: 140, Actual: 142 HargassnerBridge.async_update(): Unexpected message length. Expected: 140, Actual: 142 HargassnerBridge.async_update(): Unexpected message length. Expected: 140, Actual: 142 HargassnerBridge.async_update(): Unexpected message length. Expected: 140, Actual: 142 HargassnerBridge._update(): Received message has unexpected length. |
|
Absolutely nuts.... you both have different message-lengths - or even better, we three have this! Hargassner doesn't like us... i guess they want to sell there gateway and App. The telnet is no documented interface, as far as I know. You both could do this: Add two dummy-entries in your msg-format, I suggest you to place them in front of the digital channels. In my example position 119 and 120. But then check your values carefully, especially if you use automations with them. Incorrect values in an automation could cause damage in some individual cases - I can't give you any guarantee... |
|
Hey @anderl78 - can you describe this in some more detail or give an example? I don't get it fully. I just read out the data, so there should be no damage. |
|
ok, i will try.... The data set or better the data from the SD card (msgformat) consists of two parts. It begins with an "ANALOG" part, followed by a "DIGITAL" part. In both parts, each block is marked by a numbered CHANNEL. The digital part is, at least as far as I have seen so far, made up of 8 channels (CHANNEL 0 to 7, but the digital values are special because several BIT values are defined for each channel, each encodes a different value. So each digital channel contains several values, depending on CHANNEL-number and BIT). So what you can do: start at the end of your msgformat and loock backwards in the data set until you reach the first digital "CHANNEL id=0". Before this value you will see the DIGITAL marking and before the DIGITAL-marking you will see that, ANALOG ends with "/ANALOG". In concrete terms, it looks something like this: the last analog value is defined (btw, for analog channels each channel has only one value, no BIT):
To stay within this example, you would have to insert two additional analog channels (here 106 and 107). That would look like this:
you don't have to change the digital part, let it unchanged. insert your new msgformat in homeassistant, restart and it should work (perhaps with a few false values...) |
|
...at least as far as I could figure out here... my biggest problem is, that I don't known the TELNET output from earlier firmware nor from other heaters. Would be greate,if everybody would give us firmware, name of heater and msgformat-info (number of channels in msgformat and corresponding values from telnet - as done now with new debugging-line in the code) |
|
@anderl78- Thank you very much for this explanation and now I understand more how the whole thing is structured. Values are now displayed again after the two dummy entries. I have connected to my heating system via Telnet: Nano-PK 15 KT=Nano.2(.3) 15 `pm 1 1.1 7.5 33.1 0 34.6 32 13 36.8 0 0 53.9 120 51.8 75 5 0 0 0 54 0 0 30 100 100 100 0 86.4 82 3 0 0 10 3 0 2 0 38 0 0 3109 5246 4866 0.00 0.00 -3 50.4 24145 140.0 113.5 34 -20.0 -20.0 0.0 28.2 26.2 1 0 -20.0 0 20.0 20.0 0 1 27.7 0 20.0 22.0 5 1 140.0 0 20.0 20.0 0 1 -20.0 0 20.0 20.0 0 1 -20.0 0 53.8 0 0 1 -20.0 0 0.0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.00 6 0 0 0 1 0 0 0 pm 1 1.1 7.5 33.1 0 34.6 32 13 36.9 0 0 53.9 120 51.8 75 5 0 0 0 54 0 0 30 100 100 100 0 86.4 82 3 0 0 11 1 0 3 0 38 0 0 3109 5246 4866 0.00 0.00 -3 50.4 24145 140.0 111.6 34 -20.0 -20.0 0.0 28.2 26.2 1 0 -20.0 0 20.0 20.0 0 1 27.8 0 20.0 22.0 5 1 140.0 0 20.0 20.0 0 1 -20.0 0 20.0 20.0 0 1 -20.0 0 53.8 0 0 1 -20.0 0 0.0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.00 6 0 0 0 1 0 0 0
I hope this is the edition you wanted. |
|
@mkaufmann0983 : can you send me your "new" msgformat please? |
This is now with the dummy line that @anderl78- mentioned:
After restart HA values are displayed again. |
|
Sounds good :-) But the circumstances are not pleasant. I ask everyone to publish their data here, perhaps we can see somithing there... interesting that such different data sets exist. Especially since Hargassner seems to keep a list of the registers for the modbus. Here from the ioBroker community is an (older) PDF about an operating manual for the ModBus interface: https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://forum.iobroker.net/assets/uploads/files/1615657901472-bedienungsanleitung_modbus_de_v06_11058240-002.pdf&ved=2ahUKEwiW0P6DoqeIAxWQBNsEHYAhGrgQFnoECAYQAQ&usg=AOvVaw2U3GXqfWjTqICegsfsqrNJ Really, Hargassner should give a little bit more support to the open source community! |
|
I added to dummies, some sensors are missing, just checking now. Output from my side:
2024-09-03_20:56:56 KD=Hargassner Telnet-Output:
|
|
Hello, I am not able to adjust my msg format. Here the original msg format
Can you help me please? |
|
In this line
must be entered here before the
The complete line then looks like this:
|
|
Thank you for the quick respons and for your time. I will try it without the Internet gateway over the course of the week, maybe it will work that way. |
|
@naklar25 What happens with errors in the log? Can you name them? |
|
@naklar25 It should make no difference, if there is a gateway or not. The telnet data comes from the heater. Look into your config, if there is the IP from the heater or from gateway. It should not work, if you configured the gateway there, because the gateway doesn't send telnet from port 23 (my gateway has no open port, I scanned for all ports on my gateway with no success for nothing) |
|
Hallo zusammen, Ich musste auch zu den "Analog-Channels" am Ende zwei Dummy channels hinzufügen. Aufgefallen ist mir, dass sich dieser Sensor Wert verschoben hat: Hier das Original MSG Format für meine Nano PK 12
|
Hi, you can find my logs in the txt. |
|
ich musste 3 Dummys hinten ansetzen. TYP Nano.2(.3) 15 |
Wie sieht das in etwa aus? Bzw. was muss ergänzt werden? |
Bei einigen reichten wohl 2 Dummys ich brauchte 3 |
|
Logger: custom_components.nano_pk.hargassner
Quelle: custom_components/nano_pk/hargassner.py:196
Integration: Hargassner Nano-PK (Dokumentation)
Erstmals aufgetreten: 09:31:57 (2586 Vorkommnisse)
Zuletzt protokolliert: 10:22:47
Received message has unexpected length. (expected: 113 got: 114) (2584)
Received message has unexpected length. (expected: 113 got: 114) (2585)
Received message has unexpected length. (expected: 113 got: 114) (2586)
Received message has unexpected length. (expected: 113 got: 114) (2587)
Received message has unexpected length. (expected: 113 got: 114) (2588)
Does anybody have the same issue?
The text was updated successfully, but these errors were encountered: