[Bug]: Nano-PK/Nano.2 20 with version V14_0HAR_q shows incorrect values

[pattycoder01]

Pre-flight checklist

• I have searched existing issues and confirmed this is not a duplicate.
• I am using a supported and reasonably current version.
• This report contains no secrets, credentials or personal data.

Description

When using the integration with my Nano-PK (UI says Nano.2 20) there are some definitely-not-possible values shown. (e.g. it says that the burner temperature is at ~24000°C; this has been disproven, as firstly this thing should absolutely not be reaching 24000°C and secondly the DAQ dump says that that value is showing the power supply voltage in mV) Generally most, if not all, values are wrong, although I used the right firmware template.

Steps to reproduce

1. install & configure (with firmware template V14_0HAR_q and FULL values)
2. own a Hargassner Nano-PK (Nano.2 20?) or buy it, if you want
3. see, that stuff is weird (or it shows correct values, depending if you have the "right" heating)

NOTE: I attached the relevant screenshots here, as I can't add them in the last section; I intentionally chose those examples, because they really show the issue

Expected behavior

correct mappings (burner temperature should not be at 24000°C)

Severity

High — major functionality broken

Affected version / commit

latest (v0.4.0)

Environment

• Home Assistant OS on Raspberry Pi 5
• Hargassner heating with software version V14_0HAR_q; Type Nano.2 20

Relevant logs or screenshots

attached in "Steps to reproduce", because I couldn't add screenshots here;
also I got this log from Home Assistant:

Logger: custom_components.bauergroup_hargassnerintegration.message_parser
Quelle: custom_components/bauergroup_hargassnerintegration/message_parser.py:189
Integration: BAUERGROUP Hargassner Integration (Dokumentation, Probleme)
Erstmals aufgetreten: 03:23:48 (1 Vorkommnis)
Zuletzt protokolliert: 03:23:48
Message length mismatch for firmware template 'V14_0HAR_q': expected 120 values, boiler sent 124. Parameter values may be assigned to the wrong entities. Pick a matching template in the integration options, or report the raw message so a template can be added

(shows a similar error when using my custom patch with the apparently correct mappings, but at least it works correctly; with my patch it can only parse 121/124 values, but the last 3 are apparently not used for anything)

[pattycoder01]

I want to add that my fork is publicly available on my profile (although I think that V14_0HAR_q_pattycoder is not a really fitting firmware name)

[karlspace]

Thanks for the report — and particularly for the observation that the 24000 "°C" is the supply voltage in mV. That was the decisive clue, and it turned out to be exactly right.

Root cause

It is not your configuration, and not your boiler. The V14_0HAR_q template is missing two channels that the manufacturer's channel list has: BLDC_ES ist and BLDC_ES soll, at positions 37 and 38. Everything after them is therefore read two positions early.

Concretely, for the channel you noticed:

	position of U Netzteil	position of BRT
manufacturer's list	49	51
V14_0HAR_q	47	49

So BRT reads position 49, which actually carries U Netzteil — the 24 V supply rail, in mV. Hence a burner temperature of roughly 24000. Every channel from 37 onward is shifted the same way, which matches your "most, if not all, values are wrong".

This is independently confirmed by the capture in #21, from a different machine on V14.1HAR.q: position 47 there reads 24107, i.e. ~24.1 V.

About your fork

I read it, and it deserves a better commit message than "no clue why" — your template is the manufacturer's own channel list with BoiZustand_1 inserted after TBs_1, and nothing else. That is a correct reconstruction, and it independently agrees with what #21's capture proves from completely separate data. The reason it works is that it restores the two BLDC_ES positions the stock template drops.

Two things I would not want to merge as-is, though:

1. Your boiler sends 124 values; the template accounts for 121. The parser tolerates the surplus and the leading values still line up, so it works — but it leaves a permanent length-mismatch warning in the log and three channels undescribed. If those three are real (and on the machines I have seen, trailing channels usually are — auxiliary buffer, pellet-scale or cleaner boards), they are worth having rather than discarding.
2. I would rather verify against a raw telegram than accept a template on plausibility. The method used in [Bug]: V14_1HAR_q1 template: wrong analog/digital split — Nano PK Plus (V14.1HAR.q) sends 113 analog + 8 digital words, template defines 112 + 9 #21 is mechanical: the dop attribute declares decimal places, and the firmware follows it without exception (dop='0' never prints a decimal point, dop='2' always prints exactly two), so a wrong position shows up as a formatting contradiction rather than as a merely odd-looking value.

What would settle it

A raw capture, from the repository's tool:

python tools/telnet_tester.py <boiler-ip> --count 15

Fifteen pm lines is plenty. Two things make it much more useful:

• if you can, capture once with the boiler idle and once while it is firing — channels that stay constant in both are placeholder positions, and that is what disambiguates the tail
• a note on what the boiler was actually doing (which pumps ran, whether a heating circuit or DHW boiler is fitted), because uninstalled components emit a fixed signature that pins their block exactly

With that I can determine where the extra three values sit, and ship a template that matches 124 exactly rather than 121-of-124.

Meanwhile

V14_1HAR_q1 was corrected in 634a6d6 — it had its own, different defects (see #21). Please do not switch to it as a workaround: your machine is not that layout, and it would move your values around again without fixing them. Staying on your fork until we have the capture is the better option.

Two notes for when you do switch: the connection sensor now exposes firmware_template, expected_length and last_message_length as attributes, so template fit is checkable in the UI without reading logs. And V14_0HAR_q itself is still unfixed — I have deliberately left it alone, because I have no capture from a machine that genuinely uses it and I would rather not repeat the mistake of correcting a template by inference.

[karlspace]

Correction to one paragraph of my previous comment.

I wrote that V14_1HAR_q1 had been corrected in 634a6d6. That change has been reverted in 0.5.1. Redefining a template key that installations already use moves their values between entities, and an HG-PK32 in the field turned out to read plausible heating-circuit values with the original order and implausible ones with the manufacturer's. So two channel orders exist under the same V14.1HAR.q1 firmware string, and the manufacturer's DAQ documents one machine rather than the firmware as such. That order now lives in its own key, V14_1HAR_q1_nano2_32.

What this does not change: the explanation of your symptom. V14_0HAR_q omits BLDC_ES ist and BLDC_ES soll relative to the manufacturer's channel list, so on a boiler that does send them everything from position 37 is read two positions early, and BRT at index 49 picks up U Netzteil — the 24 V rail in mV. That is still the best explanation for the ~24000 reading, and it is corroborated by your own fork: your template includes the two BLDC_ES channels, and it works.

What I would soften is the conclusion I drew from it. I said V14_0HAR_q "is still unfixed". Given that channel order demonstrably varies between machines on one firmware string, I no longer assume V14_0HAR_q is simply wrong — it may be right for some installations and wrong for yours. Either way the fix is the same and it is additive: a new key for your layout, leaving V14_0HAR_q alone.

For that I still need the raw capture:

python tools/telnet_tester.py <boiler-ip> --count 15

Ideally once idle and once firing, with a note on what the boiler was doing. Your boiler sends 124 values and your template accounts for 121; with a capture I can place the remaining three and ship a template that matches exactly, under its own key.

[pattycoder01]

Actually I did some testing before creating a bug report here (including directly connecting to the heating over telnet, manually parsing the values and trying to reverse-engineer the values based on pictures I took from the UI).

When I couldn't completely match all the values, I remembered that your repo had some instructions for adding new firmware templates, so I also took the DAQ dump according to the instructions and just read it. (As the DAQ part is just plain XML, it was relatively easy to understand.) Comparing the DAQ dump mappings and the actual packets, I conclude that all the mappings are correct. But as we don't have reasonable data from the heating that explains the last 3 values not having proper mappings, I assume that those are just dummy values reserved for later use or internal debugging purposes that have no documentation available.

I ran the telnet_tester.py script as you advised, but you probably unintentionally made it truncate the messages. I also fixed that in my fork. Currently it is summer, so it would be economically unwise to start my heating just to check if the values change, so the heating was turned off while I got all the telnet messages. Anyways, I can assure you that the last 3 unmapped values were always (in every single packet) 0 0 0.

I also connected to the heating over telnet and got you a sample packet; while this was recorded, the heating was idle; this is to show that the last 3 values are zeroes:
pm 1 1.3 7.3 19.1 0 19.4 36 5 25.8 0 0 43.9 41.4 31.5 40 5 0 0 0 44 0 0 30 100 85 85 77 85.7 88 4 0 0 0 3 6 0 0 0 0 32 0 0 8460 6590 26758 0.00 0.00 -3 49.7 24179 140.0 107.8 29 -20.0 -20.0 0.0 19.5 18.1 0.0 0 0 -20.0 0 20.0 20.0 0 1 0 20.4 0 20.0 20.0 5 1 30 120.0 0 20.0 20.0 0 1 0 -20.0 0 20.0 20.0 0 1 0 -20.0 0 47.9 0 0 0 0 -20.0 0 0.0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.00 406 0 0 40 7 0 0 0