Issue with Parameter integration

[pschimik]

I followed all docs an implemented a firmware template for my Hargassner Nano PK15
Type: Nano.2(.3) 15
Firmware V14.1HAR.q
Home Assistant Version: OS 17.1
HA Core: 2026.4.1

I ended up in nearly all values correct, but sadly only nearly.
Main issue (as far as i can assume and understood everything):
daq_parser.py extracts following from my DAQ:
Statistics:

• Analog Parameters: 143
• Digital Parameters: 116
• Expected Message Length: 151

But Telnet delivers 155 values :(
Message length mismatch: expected 151, got 155

I'm stuck now how to fix this and to identify why Hargassner is delivering more than expected :(
Sample message from telnet:
pm 1 1.1 8.1 67.7 0 70.1 32 14 69.9 0 0 68.5 69.1 67.8 100 5 0 0 0 68 0 0 30 100 30 30 54 93.5 98 3 0 0 7 2 0 0 0 99 38 0 1838 3006 4814 0.00 0.00 -3 50.9 24208 140.0 119.3 37 -20.0 -20.0 0.0 5.2 8.8 0.0 1 3 0 0 -20.0 0 20.0 20.0 0 1 0 34.7 0 20.9 21.1 4 1 32 120.0 0 20.0 20.0 0 1 0 31.3 0 26.2 21.0 4 1 32 120.0 0 20.0 20.0 0 1 0 -20.0 0 20.0 20.0 0 1 0 -20.0 0 60.3 0 0 0 71.8 0 0 0 -20.0 0 0.0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2.5 2.5 0.0 70.8 120.0 62.2 100 0 5 0 0 0 0 0.00 406 0 0 0 1 0 0 0

I'd appreciate any help on that.
Where i want to go to:
I'm operating an influx DB locally at home and want to collect and interpret the heating data on my own.
Your integration helped me very much to understand where to start.
Now I'm just investigation on "how to interpret the delivered values in a right way"

Attachments:
DAQ-JSON-TXT.zip
home-assistant_2026-04-06T21-31-28.789Z.log

[github-actions]

AI Analysis

Technical Summary of GitHub Issue: Issue with Parameter Integration

Technical Requirements and Constraints

1. Hardware and Firmware:

   • Device: Hargassner Nano PK15, Type Nano.2(.3) 15, running Firmware V14.1HAR.q.
   • Communication via Telnet delivering real-time telemetry data.
   • Expected data message length: 151 parameters.

2. Software:

   • Home Assistant OS Version: 17.1, Core Version: 2026.4.1.
   • DAQ parsing via daq_parser.py.
   • Local InfluxDB for data storage and analysis.

Implementation Considerations

1. Telnet Data Mismatch:
   • The daq_parser.py is designed to parse and expect 151 parameters, but Telnet provides 155. This discrepancy results in unparsed values and incomplete integration.
   • Identification of the discrepancy requires investigation into the firmware's telemetry

---

This summary was automatically generated by AI to help with triage and may not be 100% accurate.

[pschimik]

Ich habe jetzt etwas in den vorhandenen Issues herumgeschmökert.
Schaut aus als ob Ich auch irgendwelche Dummy Einträge im Template benötige.
Wäre für Hilfe sehr dankbar.
Das mapping der analogen Kanäle ist mir relativ klar, aber mit den Digitalen stehe ich noch etwas auf Kriegsfuss.
Ich verstehe noch nicht ganz, wo ich erkenne welcher der gelieferten die Digitalen sind und wie die auf Bits zerlegt werden.

[pschimik]

P.S.: SUPERTOLLE INTEGRATION - flexibel konfigurierbar und sehr aufschlussreich zum monitoring der Heizung !!

[karlspace]

Hallo @pschimik,

erstmal vielen Dank für das ausführliche Issue und das nette Feedback zur Integration — freut mich wirklich, dass sie dir beim Monitoring weiterhilft! 🙏

Warum 155 statt 151?

Das ist kein Bug, sondern ein bekanntes Muster: Deine Nano.2(.3) 15 sendet im Live-Telnet-Stream mehr Parameter, als in deiner DAQ-Datei exportiert wurden. Typische Ursachen:

1. Aktive Zusatzhardware/Boards – z.B. zusätzliche Heizkreise, Solar, WMZ oder Ascheaustragung senden Werte im Stream, auch wenn die DAQ-Struktur sie nicht auflistet
2. Firmware-Sub-Varianten – V14.1HAR.q existiert in leicht unterschiedlichen Builds, abhängig von der Hardware-Konfiguration

Ein sehr ähnliches Problem hat @tvieider in #11 gelöst. In seiner Nano.2 fehlten 3 Platzhalter-Channels (59, 89, 90) — daraus ist das Template V14_1HAR_q1_solar entstanden. Bei dir sind es 4 Extra-Werte.

Aufbau deiner Telnet-Nachricht

Aktuell erwartet der Parser folgende Struktur:

Positionen  0–142  →  143 Analog-Parameter
Positionen  143–150 →  8 Digital-Words (je 16 Bit = 116 Digital-Channels gepackt)
───────────────────────────────────────────────
Summe: 151 Werte  (tatsächlich gesendet: 155)

Die 4 Extra-Werte liegen mit hoher Wahrscheinlichkeit am Ende (neue Analog-Parameter in der Firmware) oder zwischen den bekannten Parametern (wie bei tvieider). Dein Sample-Wert an Position 3 (67.7) passt gut zu TK = Kesseltemperatur, also sind die frühen Positionen korrekt aligniert — die Extras liegen weiter hinten.

Lösung: Dummy-Channels

Der saubere Weg ist, die 4 unbekannten Positionen als Platzhalter in dein XML-Template aufzunehmen, damit die nachfolgenden Parameter-Indices wieder stimmen. Je nach Position:

Fall A — Extras am Ende (nach den Digital-Words):

<ANALOG>
  <!-- ... deine 143 bekannten Analog-Parameter ... -->
</ANALOG>
<DIGITAL>
  <!-- ... deine 116 Digital-Channels verteilt auf 8 Words (id 143–150) ... -->
</DIGITAL>

Hier müsste man den Parser leicht erweitern, da 4 Analog-Werte nach den Digitals nicht dem aktuellen Schema entsprechen.

Fall B — Extras mitten zwischen den Analog-Parametern (wahrscheinlicher):

<CHANNEL id='143' name='Dummy 1' />
<CHANNEL id='144' name='Dummy 2' />
<CHANNEL id='145' name='Dummy 3' />
<CHANNEL id='146' name='Dummy 4' />
<!-- dann schieben sich die Digital-Words auf id 147–154 -->

So findest du die richtige Position

Beobachte deine Nachricht über ein paar Minuten und prüfe, wo die Werte unplausibel werden:

1. Nimm deine erwarteten Parameter (aus der DAQ) und vergleiche sie mit den aktuellen Werten im Stream
2. Wo Temperaturen plötzlich als Drehzahlen erscheinen oder -20.0 an einer falschen Stelle auftaucht → dort liegt die Verschiebung
3. Immer-0-Werte oder konstante -20.0-Werte sind typischerweise inaktive Hardware-Slots (= gute Dummy-Kandidaten)

Zu den Digital-Parametern

Die Digitalen funktionieren so:

1 Digital-Word = 1 Integer-Wert im Stream = 16 Bit = max. 16 Digital-Channels
116 Digital-Channels ÷ 16 = 8 Words (gerundet)

Jedes Word ist ein einziger Zahlenwert in der Telnet-Nachricht (z.B. 406 gegen Ende deiner Message). Die einzelnen Bits werden per Bitmask extrahiert:

# Beispiel: Bit 2 aus einem Digital-Word mit Wert 406 (binär: 0b110010110)
int_value = 406
bit_mask = 1 << 2    # = 4
result = bool(int_value & bit_mask)  # → True (Bit 2 ist gesetzt)

Im XML-Template mappt man das über die Attribute id (= Word-Position im Stream) und bit (= Bit-Position 0–15 innerhalb des Words):

<DIGITAL>
  <CHANNEL id='143' bit='0'  name='M1_Kessel_Geblaese'/>
  <CHANNEL id='143' bit='1'  name='M2_Saugzug'/>
  <CHANNEL id='143' bit='2'  name='M3_Ruettler'/>
  <!-- alle 16 Bits eines Words teilen sich dasselbe id -->
  <CHANNEL id='144' bit='0'  name='Stoerung_XYZ'/>
  <!-- neues Word → neues id -->
</DIGITAL>

Der Parser-Code dazu steht in message_parser.py — falls du es im Detail nachlesen willst.

Konkreter Vorschlag

Du hast ja bereits die DAQ-JSON-TXT.zip angehängt — super! Wenn du magst:

1. Beobachte die letzten ~10 Werte deiner Telnet-Nachricht über 15–30 Minuten (Kessel in Betrieb + Standby)
2. Schick mir eine Liste, welche Werte sich verändern und welche konstant bleiben
3. Dann kann ich dir helfen, die Dummy-Positionen exakt zu bestimmen und wir bauen ein sauberes Template V14_1HAR_q_nano2 (oder ähnlich), das dann Teil der Integration wird — so müssen auch andere Nano.2(.3)-Nutzer in Zukunft nichts mehr manuell anpassen

Lese-Tipps

• 📖 docs/ADDING_FIRMWARE_DE.md — kompletter Workflow für neue Firmwares
• 🔍 Dummies in der Firmware #11 — der tvieider-Fall mit Dummies und Solar-Extension (gleiches Grundmuster)
• 🛠️ tools/daq_parser.py — falls du nochmal eine frische DAQ generieren willst

Meld dich gerne mit den Messwerten, dann bauen wir das zusammen sauber fertig! 🔧

[pschimik]

Hallo Karl,

Danke für Dein Angebot.
Ich habe mittlerweile zur Analyse bei mir eine InfluxDB hochgezogen und befüttere die über NodeRed mit den Telnetdaten.
Eine Tabelle mit den Rohdaten aus dem Telnet Telegramm und eine andere Tabelle gemappt, soweit ich die Werte plausible zuordnen konnte.
Leider reisst mir ab der Mitte der Faden und ich blick nicht durch wo ich die Dummys einfügen sollte.

Ich habe einen XLS Export der letzten 6 Stunden angehängt und wäre Dir für Unterstützung bei der Identifizierung der Dummies sehr dankbar.

Mit freundlichen Grüßen, Peter

query.xlsx

[pschimik]

Noch eine letzte Erkenntnis meinerseits.
Wie Du vermutest liegt der Mismatch irgendwo hinten begraben.
Ich habe einen Zusatzpuffer der auf der Hargassner Seite als HKM1 angezeigt wird.
Zufällig habe Ich heute gesehen dass die Zusatzpufferpumpe um 18:30 gelaufen ist.
Mit dem Temperaturvergleich lande Ich hinten bei p133 und folgenden.

Also TPO_ZusPuf1 TPM_ZusPuf1 sind immer gleich 😳
-> Laut Heizung gibt es aber nur Temperatur Oben und unten, der hat keinen Fühler in der Mitte.
p140 schaut vom Werteverhalten nach Zusatzpuffer Pumpe aus.
Also irgendwie Kuddelmuddel und ich kann den Knopf irgendwie nicht auflösen 😩

query.xlsx

[karlspace]

Hallo Peter,

vielen Dank für die zweite Datenrunde mit der InfluxDB — das ist genau die Art von Beobachtung, die wir brauchten, um den Knoten zu lösen! Mit deinem Hinweis auf p133+ und dem TPO_ZusPuf1 == TPM_ZusPuf1-Effekt konnte ich dein Telegramm sauber durchrechnen.

Strukturanalyse deines Telegramms

Ich habe deine 155 Werte aus dem Issue-Body durchnummeriert (0-indexiert, weil der Parser intern so arbeitet — also zähl ggf. +1 zu deiner UI-Nummerierung):

p120-p131  →  0 0 0 0 0 0 0 0 0 0 0 0          (Anf. HKR-Slots, alle leer)
p132       →  1                                  ← Status/Marker
p133       →  2.5                                ← Wasserdruck (bar)
p134       →  2.5                                ← du nennst das "TPO_ZusPuf1"
p135       →  0.0                                ← "TPM_ZusPuf1" (immer = TPO!)
p136       →  70.8                               ← TPU_ZusPuf1 (echte Temp)
p137       →  120.0                              ← Soll/Max-Grenze (Sicherheitswert)
p138       →  62.2                               ← Pufferanforderung/TFW
p139       →  100                                ← Füllgrad % o.ä.
p140       →  0                                  ← du nennst das "ZusPuf-Pumpe"
p141       →  5
p142       →  0
p143-p146  →  0 0 0 0.00                         ← weitere Analog-Slots
p147       →  406                                ← 1. Digital-Word ★ Anker!
p148-p154  →  0 0 0 1 0 0 0                      ← Digital-Words 2-8

Die Schlüssel-Erkenntnis: Alle 4 Extras sind Analog

Der Wert 406 an p147 ist der eindeutige Beweis: Das ist binär 0b110010110 und matcht perfekt auf den Digital-Word-0-Block (Störung/Stb/Füllstand/...). Damit gilt:

Digital-Block:  p147 - p154   (8 Words, identisch zur Standard-Struktur)
Analog-Block:   p0   - p146   (147 Analog-Werte)

→ 147 Analog + 8 Digital = 155 ✓

Dein DAQ erwartet:
→ 143 Analog + 8 Digital = 151

Differenz: 4 Extra-Analog-Parameter im Bereich p131-p146

Die Extras stecken NICHT mittendrin und auch nicht hinter den Digitals, sondern als zusätzlicher Analog-Block direkt vor den Digitals. Das ist gute Nachricht — der Parser braucht keine Code-Änderung, nur ein erweitertes Firmware-Template.

Warum TPO_ZusPuf1 == TPM_ZusPuf1?

Das ist kein Bug — das ist die Hargassner-Firmware. Die Schema-Tabelle in V14.1HAR.q hat drei Slots für den Zusatzpuffer (oben/mitte/unten), aber die Hardware-Erkennung deaktiviert den Mittel-Sensor automatisch und füllt den Slot mit dem Nachbarwert (typisches Default-Verhalten beim Hargassner-Schema, wenn ein Sensor fehlt).

→ Daraus folgt: Genau einer dieser beiden ist der echte "Dummy-Channel", den wir im Template als Platzhalter markieren müssen.

Konkreter Template-Vorschlag

Auf Basis von V14_1HAR_q1 (kein Solar bei dir) und mit dem Zusatzpuffer-Block am Ende, hier mein Vorschlag für ein neues Template V14_1HAR_q_nano2_zuspuf:

<!-- p0-p111: identisch zu V14_1HAR_q1 (deine 112 Standard-Analog-Channels) -->
<!-- p112-p131: identisch zu V14_1HAR_q1_solar HKR-Block (Anf. HKR0-15 etc.) -->

<!-- NEU: ZusPuf/HKM1-Block ab p132 -->
<CHANNEL id='132' name='HKM1 Status'           dop='0'/>           <!-- p132: 1 -->
<CHANNEL id='133' name='Wasserdruck'  unit='bar' dop='2'/>          <!-- p133: 2.5 -->
<CHANNEL id='134' name='TPO_ZusPuf1'   unit='°C'/>                  <!-- p134: 2.5 (echter Wert) -->
<CHANNEL id='135' name='Dummy_TPM_ZusPuf1' unit='°C'/>              <!-- p135: 0.0 (Phantom) -->
<CHANNEL id='136' name='TPU_ZusPuf1'   unit='°C'/>                  <!-- p136: 70.8 -->
<CHANNEL id='137' name='TPO_ZusPuf1_soll' unit='°C' dop='0'/>       <!-- p137: 120.0 -->
<CHANNEL id='138' name='TFW_ZusPuf1'   unit='°C'/>                  <!-- p138: 62.2 -->
<CHANNEL id='139' name='ZusPuf1_Fuellgrad' unit='%' dop='0'/>       <!-- p139: 100 -->
<CHANNEL id='140' name='HKM1 PuffZustand'  dop='0'/>                <!-- p140: 0 -->
<CHANNEL id='141' name='HKM1 Programm'    dop='0'/>                 <!-- p141: 5 -->
<CHANNEL id='142' name='HKM1 Reserved_1' dop='0'/>                  <!-- p142: 0 -->
<CHANNEL id='143' name='HKM1 Reserved_2' dop='0'/>                  <!-- p143: 0 -->
<CHANNEL id='144' name='HKM1 Reserved_3' dop='0'/>                  <!-- p144: 0 -->
<CHANNEL id='145' name='HKM1 Reserved_4' dop='0'/>                  <!-- p145: 0 -->
<CHANNEL id='146' name='HKM1 Reserved_5' dop='0'/>                  <!-- p146: 0.00 -->

Die Namen für p134 und p135 hängen davon ab, welcher der echte Sensor ist — und das können wir aus deinen InfluxDB-Daten ableiten.

Zwei Validierungs-Checks aus deiner InfluxDB

Damit ich das Template final korrekt bauen kann, brauche ich noch zwei kurze Auswertungen aus deiner Influx (jeweils über mind. 6h Heizbetrieb):

Check 1 — Welcher von p134/p135 ist der echte TPO?

SELECT MIN(p134), MAX(p134), STDDEV(p134),
       MIN(p135), MAX(p135), STDDEV(p135)
FROM raw_telnet WHERE time > now() - 6h

→ Der Slot mit größerer Streuung ist der echte Sensor. Der mit STDDEV ≈ 0 (oder konstant 0.0) ist der Dummy.

Check 2 — Welche Slots in p140-p146 ändern sich überhaupt?

SELECT MIN(p140), MAX(p140), 
       MIN(p141), MAX(p141),
       MIN(p142), MAX(p142),
       ... bis p146
FROM raw_telnet WHERE time > now() - 24h

→ Slots mit MIN == MAX sind definitiv Dummies/Reserved und kriegen den Namen HKM1_Reserved_X. Slots mit Veränderung sind echte Werte und kriegen einen sprechenden Namen.

Bonus: Wenn du noch parallel im Hargassner-Webinterface beobachten kannst, was sich am Zusatzpuffer gerade ändert (Pumpe an, Soll-Temp verschoben, etc.) und das mit der Influx korrelierst — perfekt. Dann können wir die Slots auch sprechend benennen statt nur "Reserved".

Nächster Schritt

Wenn du mir die zwei Checks oben schickst (oder einen frischen XLSX-Auszug mit den Roh-Werten p131-p147 über 6+h, breit genug für eine Pumpenschalt-Episode), baue ich:

1. Neues Template V14_1HAR_q_nano2_zuspuf in firmware_templates.py
2. Parameter-Beschreibungen (DE/EN) für die ZusPuf/HKM1-Slots in PARAMETER_DESCRIPTIONS
3. Eintrag in const.py + config_flow.py, damit du es in der UI auswählen kannst
4. Release als Patch-Version, damit andere Nano.2(.3)-User mit HKM1+Zusatzpuffer auch davon profitieren

So ersparen wir nicht nur dir das Manuelle, sondern allen, die genau diese Konfiguration fahren.

Tipp für die Zwischenzeit: Wenn du in deinem lokalen Template einfach 4 Dummy-Channels mit id='143' bis id='146' ergänzt (vor dem </ANALOG>-Closer), läuft die Integration sofort durch — die nachfolgenden Digitals werden dann korrekt erkannt. Damit hast du eine funktionierende Übergangslösung, bis die saubere Variante ausgerollt ist.

Vielen Dank für deine Geduld und vor allem für die saubere Diagnose-Arbeit mit InfluxDB+NodeRed — das ist Gold wert für künftige Nano.2-Nutzer! 🔧

Beste Grüße,
Karl

[pschimik]

Hallo Karl ,
Ich danke Dir für deine Geduld!
Mittlerweile habe Ich neue Erkenntnisse und muss mich entschuldigen, dass Ich Dich auf eine falsche Fährte gelotst habe 😒
Meine Hargassner Konfig:

• ohne Solarerweiterung
• Zusatzpuffer 1000 Liter
• Pelletsraum mit 3 Ansaugstellen !

Und da lag mein Fehler -> Parameter p134 und p135 haben mit der Stellung der Ansaugung zu tun.
Zufälligerweise hatte Ich ein Problem im Pelletsraum (Prallschutzmatte abgefallen und hatte eine Ansaugstelle verlegt).
Dadurch hat das Gerät vor dem Pelletsraum (AUP -> Was auch immer das heisst) die STellung gewechselt.
Und plötzlich stand da 132,5 statt 67,5 drinnen:

Also habe ich jetzt p132 bis p135 jetzt diesem AUP Dings zugeordnet (Position, Pos soll, pos ist, strom)
Obwohl die im DAQ eigentlich p129 bis 132 sein sollten.

Ich hänge hier jetzt noch einmal einen 5-Tages Export als XLS an.
In der obersten Zeile stehen die "Behauptungen" aus dem DAQ.
In der zweiten Zeile sind die Telenet Positionen der Werte.

Ich bin mir mittlerweile ziemlich sicher , dass p132 bis p135 für das AUP Teil sind
p136 bis p140 sind für den HKM1 Zusatzpuffer (Temp Oben, Mitte immer 120, Temp unten, Füllgrad, Pumpe ZusPuff)

Mit diesen Annahmen hab Ich jetzt die "Löcher" p067 , p108 , p131 , p146 - ??
Die 8 Digitalen Werte hinten habe ich Spasses halber hinten in Binär umgewandelt.
Mit denen komme Ich aber überhaupt nicht zurande 😄.
Bin zwar seit 30 Jahren in der IT, aber ich begreif's nicht.
Laut DAQ gibt des da den digitalen Kanal 6 mit 27 bits 😮 -> Wie soll ich 27 bit in einem 16 bit DWORD darstellen ?

Wenn Ich die Heizkreispumpen für mich richtig identifiziert habe (HKP1 Status auf p074 und HKP3 Status auf p088),
dann sind mir die Werte 7,25,32 und 59 schleierhaft (welcher Wert soll was bedeuten?)

Ich bin jetzt schon relativ knapp dran, dass Ich alle für mich wichtigen Werte habe.
Eine ganz saubere Integration wäre natürlich für andere mit gleicher Konfig sicher interessant.

Ich bastle einfach aus Neugier aktuell an eigenen Auswertungen per Grafana Boards aus der Influx herum.
Primär geht es mir um die historischen Werte meines Zusatzpuffers HKM1,
weil Hargassner das in deren Web-Seite noch immer nicht anbietet.
Man hat zwar historische Daten zu vielen Werten, aber nicht alle und meinen HKM1 gar nicht 🥹

Warum Ich so sehr an den Daten meines Zusatzpuffers interessiert bin:
Die Heizung mit dem 315l Puffer steht bei den Schwiegereltern und bedient Heizkreis 1.
Der 100l Puffer steht in meinem Hausteil und bedient mich Heizkreis 3.
In unserem Hausteil wird der Zusatzpuffer auch von einer eigenen (nicht an Hargassner angebunden) Solar-Regelung aufgeheizt.
Und Ich möchte einfach gerne sehen -> Wann hat unsere Solar zu wenig geliefert und die Hargassner musste aushelfen.

Dazu brauch ich aber den Temperaturverlauf des Zusatzpuffers und wann die Zusatzpufferpumpe gelaufen ist.

Solltest Du als noch Interesse haben an meinen Daten weiterzuforschen, dann bin Ich Dir SEHR SEHR dankbar.
Solltest aber an dieser Sonderkonfig die Lust und Laune verloren haben, verstehe Ich das auch vollkommen.

Den XLS-Export zippe ich, damit dieser Thread nicht explodiert.

Danke und liebe Grüße,
Peter

Hargassner_telnet_query.zip

[karlspace]

Hallo Peter,

das ist eine fantastische Detektivarbeit — und du brauchst dich für gar nichts zu entschuldigen! Im Gegenteil, du hast zwei Dinge gefunden, die ich falsch hatte:

Korrektur 1: Es sind 32-Bit DWORDs, nicht 16-Bit Words

Du hast völlig recht mit deiner Frage zu id='6' bit='27' — das geht in 16 Bit nicht. Mein Fehler in der vorherigen Erklärung: Hargassner verwendet 32-Bit Integer (DWORDs) für jedes Digital-Wort, nicht 16-Bit. Die Theorie:

1 Digital-Word = 1 Integer im Stream = 32 Bit = bis zu 32 Boolean-Flags
8 Words × 32 Bit = max. 256 Digital-Channels (mehr als die ~116 nötigen)

Schauen wir uns das mit deinem 406 an:

406 dezimal
= 0b00000000_00000000_00000001_10010110 (32-bit)
        ^               ^
        Bits 16-31      Bits 0-15

Bit-Positionen, die in deinem 406 gesetzt sind: 1, 2, 4, 7, 8 → das wären laut Standard-Mapping (Word 0):

• Bit 1 = Stb (Standby)
• Bit 2 = Füllstand
• Bit 4 = RLm_auf
• Bit 7 = Akt. Code
• Bit 8 = ?

Im Parser-Code (message_parser.py:135) steht bit_mask = 1 << param_bit — das funktioniert dank Pythons unbegrenzter Integer-Arithmetik für jedes Bit von 0 bis 31. Also kein Code-Bug, nur meine vorherige Erklärung war ungenau. Sorry!

Korrektur 2: Du hast recht — p132-p135 ist AUP, nicht Wasserdruck

Deine Beobachtung mit dem Pelletsraum-Vorfall (Prallschutzmatte, Wert sprang von 67.5 auf 132.5) ist genau die Art Validierung, die uns das nailt. Schau:

p132 = 1     ← AUP-Position (1 von 3 Ansaugstellen aktuell aktiv)
p133 = 2.5   ← AUP Soll (Ziel-Position)
p134 = 2.5   ← AUP Ist (aktuelle Position) — matcht Soll → System ruht
p135 = 0.0   ← AUP Strom (0 mA → Motor steht)

Das matcht perfekt mit dem AUP-Block aus V14_1HAR_q1_solar, wo bereits AUPSoll/AUPIst/AUPStrom (id=128-130) existieren — bei dir kommt noch eine AUP-Position-Variable hinzu, weil du 3 Ansaugstellen hast statt der üblichen 1-2. Das ist eine schöne Erweiterung, die wir sauber im Template abbilden können.

Was bedeutet AUP überhaupt? Wahrscheinlichste Interpretation: Antrieb Umschalt-Position oder Ansaug-Umschalt-Punkt. Bei 3 Ansaugstellen schaltet ein Servo die aktive Saugleitung um — die Position ist physikalisch in mm/Schritten messbar (daher die Float-Werte 2.5).

Bestätigte Map-Tabelle deiner Stream-Positionen

Mit deinen Daten ist das Bild jetzt komplett:

Stream-Pos	DAQ-Pos	Wert	Bedeutung
p059	—	(Dummy)	Board-Offset 1 (wie tvieider)
p089	—	(Dummy)	Board-Offset 2
p090	—	(Dummy)	Board-Offset 3
p132	p129	1	AUP Position (1/2/3)
p133	p130	2.5	AUP Soll
p134	p131	2.5	AUP Ist
p135	p132	0.0	AUP Strom (mA)
p136	p133	70.8	ZusPuf TPO (oben)
p137	p134	120.0	ZusPuf TPM (Soll/Max — siehe unten)
p138	p135	62.2	ZusPuf TPU (unten)
p139	p136	100	ZusPuf Füllgrad (%)
p140	p137	0	ZusPuf Pumpe (0/1)
p146	—	0.00	(Dummy 4 / Reserved)

→ 3 Board-Offset-Dummies + 1 Reserved am Ende = 4 Extras ✓

Zur "Mitte = immer 120" Beobachtung

Das ist Absicht in der Hargassner-Firmware, kein Sensor:

• Bei einem Schichten-Puffer mit nur Oben/Unten-Sensorik füllt die Firmware den Mittel-Slot mit der Sicherheits-Maximaltemperatur (typisch 120°C — das ist der Notabschalt-Wert, oberhalb dessen der Wärmetauscher Schaden nehmen würde)
• Du siehst daher konstant 120.0 weil dein Puffer keinen Mittel-Sensor hat → die Firmware setzt den Wert auf MaxTemp_Default
• Im Template behandeln wir das als echten Slot mit Sondersemantik, nicht als Dummy — Name z.B. TPM_ZusPuf1_Max

Zu den Löchern p067, p108, p131, p146

Wenn du diese im DAQ als 0-Slots siehst, sind das inaktive Channel-Slots, die Hargassner für nicht-bestückte Hardware-Optionen reserviert:

• p067 — vermutlich TVL_1-Slot in einer Konfig ohne ersten regulären Heizkreis (du hast HK1 bei den Schwiegereltern, aber im Wohnungs-Hargassner-Slave-Modul evtl. anders)
• p108 — irgendwo im Anf. HKR0-15-Block — Hargassner hat 16 Slots reserviert, du nutzt nur 2-3 davon (für HK1 + HK3)
• p131 — wahrscheinlich Wasserdruck (id=131 in q1_solar) — wenn dein Kessel keinen Drucksensor hat, ist der Slot 0
• p146 — der letzte Reserved-Slot vor den Digitals (wahrscheinlich für eine Hardware-Erweiterung, die du nicht hast)

Diese alle als Dummy_X zu markieren ist völlig OK — der Parser ignoriert sie dann sauber.

Zu den HKZustand-Werten 7, 25, 32, 59

Das sind State-Machine-Codes der Heizkreis-Zustandsmaschine (HKZustand_X). Hargassner dokumentiert die nicht öffentlich, aber aus Reverse-Engineering anderer Projekte sind folgende bekannt:

Code	Bedeutung
0	Aus / nicht aktiv
1	Standby / Wartezustand
4	Heizen aktiv (Tag-Modus)
7	Heizen aktiv (Übergang zu Senken)
25	Senken / Nachtabsenkung
32	Frostschutz
59	Sommer-Aus / Saisonabschaltung
120	Reservewert / Anfangswert (wie deine TPM=120)

Das 4 und 1 in deinem Beispiel-Telegramm bei p072 / p073 sind also "Heizen aktiv" und "Standby" — passt zu zwei verschiedenen Heizkreisen mit unterschiedlichen Anforderungen. Wenn dir Codes über 60 unterkommen → bitte melden, dann erweitern wir die Liste.

Deine Use Case ist genau das, wofür diese Integration gemacht ist

"Wann hat unsere Solar zu wenig geliefert und die Hargassner musste aushelfen."

Das ist eine klassische Solar-Bivalenz-Auswertung — und ich freue mich riesig, dass du mit Grafana arbeitest. Genau dafür gibt es die Integration: dass man eigene Auswertungen bauen kann, ohne auf das Hargassner-Webportal angewiesen zu sein. Dein HKM1-Zusatzpuffer ist ein perfektes Beispiel für einen Sensor-Block, den Hargassner selbst nicht historisch ausspielt.

Mein Vorschlag für das nächste Release

Mit deinen Daten kann ich jetzt ein funktionsfähiges Template bauen, das du sofort testen kannst:

Template-Name: V14_1HAR_q_nano2_zuspuf_aup3 (Nano.2 + Zusatzpuffer + 3-Ansaugstellen-AUP)

Bevor ich das committe, eine letzte Frage damit ich die Namen richtig setze:

1. Hast du Zugriff auf die DAQ-XML-Datei (nicht die JSON, sondern die rohe *.daq von Hargassner)? Wenn ja, ein Auszug der letzten 30 Channels reicht — daraus kann ich exakte Hargassner-Original-Namen übernehmen.
2. Falls nein: Geht's für dich in Ordnung, wenn ich die Channel-Namen wie folgt benenne?

   AUPosition, AUPSoll, AUPIst, AUPStrom    ← AUP-Block
   TPO_HKM1, TPM_HKM1_Soll, TPU_HKM1,       ← ZusPuf-Block
   ZusPuf1_Fuellgrad, P_ZusPuf1
   

   (angelehnt an die Hargassner-Webportal-Bezeichnungen)

Wenn du mir das bestätigst, baue ich das Template, schreibe DE/EN-Beschreibungen, registriere es im config_flow.py und mache einen Patch-Release. Du kannst dann einfach in den Integrations-Settings auf das neue Template umstellen — ohne lokale Anpassungen.

Und falls du Lust hast, kann ich dir später auch ein Beispiel-Grafana-Dashboard für die Solar-Bivalenz-Auswertung im Repo bereitstellen — als examples/grafana/solar-bivalenz.json. Dein Use Case ist exakt der, den ich auch beschreiben würde, wenn ich erklären müsste warum diese Integration existiert.

Vielen Dank für deine wirklich hervorragende Mitarbeit! 🙏

Liebe Grüße,
Karl

[pschimik]

Hier mein DAQ:
DAQ00001.zip

mfg,
Peter

[pschimik]

Hallo Karl,
Diese Binary hab Ich noch immer nicht kapiert 😆
Also p147 bis p154 nehmen wir jetzt mal als die 8 binären Kanäle an (Channel 0 -7)
Dein zerlegen vom 406 decimal ist mir nicht klar.
Ich vermute dort HEX Werte!
Beispiel:

In Binär zerlegt schaugt das bei mir so aus:

Liege Ich da jetzt richtig?
Liest man dann die Binary von links nach rechts oder umgekehrt?

Danke nochmals für Deine Hilfe !
Das ist super Teamwork die man heute nur noch selten sieht 👍

[pschimik]

Für die firmware_templates.py
"V14_1HAR_q_nano2_zuspuf_aup3": """<DAQPRJ><ANALOG><CHANNEL id='0' name='ZK' dop='0'/><CHANNEL id='1' name='O2' unit='%'/><CHANNEL id='2' name='O2soll' unit='%'/><CHANNEL id='3' name='TK' unit='°C'/><CHANNEL id='4' name='TKsoll' unit='°C'/><CHANNEL id='5' name='TRL' unit='°C'/><CHANNEL id='6' name='TRLsoll' unit='°C' dop='0'/><CHANNEL id='7' name='Spreizung' unit='°C'/><CHANNEL id='8' name='TRG' unit='°C'/><CHANNEL id='9' name='SZist' unit='%' dop='0'/><CHANNEL id='10' name='SZsoll' unit='%'/><CHANNEL id='11' name='TPo' unit='°C'/><CHANNEL id='12' name='TPm' unit='°C'/><CHANNEL id='13' name='TPu' unit='°C'/><CHANNEL id='14' name='Puff Füllgrad' unit='%' dop='0'/><CHANNEL id='15' name='Puffer_soll oben' unit='°C' dop='0'/><CHANNEL id='16' name='Puffer_soll unten' unit='°C' dop='0'/><CHANNEL id='17' name='PuffZustand' dop='0'/><CHANNEL id='18' name='Max Anf Kessel' dop='0'/><CHANNEL id='19' name='TFW' unit='°C' dop='0'/><CHANNEL id='20' name='Leistung' unit='%' dop='0'/><CHANNEL id='21' name='ESsoll' unit='%'/><CHANNEL id='22' name='min.Leist.TRG' unit='%'/><CHANNEL id='23' name='max.Leist.TRG' unit='%'/><CHANNEL id='24' name='max.Leist.Fuell' unit='%'/><CHANNEL id='25' name='max.Leist.TPO' unit='%'/><CHANNEL id='26' name='ESRegler' unit='%' dop='0'/><CHANNEL id='27' name='Regler K'/><CHANNEL id='28' name='KeBrstScale' unit='%' dop='0'/><CHANNEL id='29' name='Programm' dop='0'/><CHANNEL id='30' name='Störungs Nr' dop='0'/><CHANNEL id='31' name='Max Anf ZenPuf' unit='°C' dop='0'/><CHANNEL id='32' name='I Es' unit='mA' dop='0'/><CHANNEL id='33' name='I Ra' unit='mA' dop='0'/><CHANNEL id='34' name='I Aa' unit='mA' dop='0'/><CHANNEL id='35' name='I Sr' unit='mA' dop='0'/><CHANNEL id='36' name='I Rein' unit='mA' dop='0'/><CHANNEL id='37' name='LZ ES seit Füll.' unit='Min' dop='0'/><CHANNEL id='38' name='LZ ES seit Ent.' unit='Min' dop='0'/><CHANNEL id='39' name='Anzahl Entasch.' dop='0'/><CHANNEL id='40' name='Anzahl SR Beweg.' dop='0'/><CHANNEL id='41' name='Lagerstand' unit='kg' dop='0'/><CHANNEL id='42' name='Verbrauchszähler' unit='kg' dop='0'/><CHANNEL id='43' name='Heiz P Lambda' unit='W' dop='2'/><CHANNEL id='44' name='Heiz U Lambda' unit='V' dop='2'/><CHANNEL id='45' name='Heiz I Lambda' unit='mA' dop='0'/><CHANNEL id='46' name='U_Lambda' unit='mV'/><CHANNEL id='47' name='U Netzteil' unit='mV' dop='0'/><CHANNEL id='48' name='T Spülung' unit='°C'/><CHANNEL id='49' name='BRT' unit='°C'/><CHANNEL id='50' name='Tplat' unit='°C' dop='0'/><CHANNEL id='51' name='TVG' unit='°C'/><CHANNEL id='52' name='TVG2' unit='°C'/><CHANNEL id='53' name='AIN17' unit='V'/><CHANNEL id='54' name='Taus' unit='°C'/><CHANNEL id='55' name='TA Gem.' unit='°C'/><CHANNEL id='56' name='Effizienz' unit='%'/><CHANNEL id='57' name='Programm HKM1' dop='0'/><CHANNEL id='58' name='ExtHK Solltmp.' unit='°C' dop='0'/><CHANNEL id='59' name='ExtHK_2 Solltmp.' unit='°C' dop='0'/><CHANNEL id='60' name='TVL_A' unit='°C'/><CHANNEL id='61' name='TVLs_A' unit='°C' dop='0'/><CHANNEL id='62' name='TRA_A' unit='°C'/><CHANNEL id='63' name='TRs_A' unit='°C'/><CHANNEL id='64' name='HKZustand_A' dop='0'/><CHANNEL id='65' name='FRA Zustand' dop='0'/><CHANNEL id='66' name='HKPA Status' dop='0'/><CHANNEL id='67' name='dummy1' dop='0'/><CHANNEL id='68' name='TVL_1' unit='°C'/><CHANNEL id='69' name='TVLs_1' unit='°C' dop='0'/><CHANNEL id='70' name='TRA_1' unit='°C'/><CHANNEL id='71' name='TRs_1' unit='°C'/><CHANNEL id='72' name='HKZustand_1' dop='0'/><CHANNEL id='73' name='FR1 Zustand' dop='0'/><CHANNEL id='74' name='HKP1 Status' dop='0'/><CHANNEL id='75' name='TVL_2' unit='°C'/><CHANNEL id='76' name='TVLs_2' unit='°C' dop='0'/><CHANNEL id='77' name='TRA_2' unit='°C'/><CHANNEL id='78' name='TRs_2' unit='°C'/><CHANNEL id='79' name='HKZustand_2' dop='0'/><CHANNEL id='80' name='FR2 Zustand' dop='0'/><CHANNEL id='81' name='HKP2 Status' dop='0'/><CHANNEL id='82' name='TVL_3' unit='°C'/><CHANNEL id='83' name='TVLs_3' unit='°C' dop='0'/><CHANNEL id='84' name='TRA_3' unit='°C'/><CHANNEL id='85' name='TRs_3' unit='°C'/><CHANNEL id='86' name='HKZustand_3' dop='0'/><CHANNEL id='87' name='FR3 Zustand' dop='0'/><CHANNEL id='88' name='HKP3 Status' dop='0'/><CHANNEL id='89' name='TVL_4' unit='°C'/><CHANNEL id='90' name='TVLs_4' unit='°C' dop='0'/><CHANNEL id='91' name='TRA_4' unit='°C'/><CHANNEL id='92' name='TRs_4' unit='°C'/><CHANNEL id='93' name='HKZustand_4' dop='0'/><CHANNEL id='94' name='FR4 Zustand' dop='0'/><CHANNEL id='95' name='HKP4 Status' dop='0'/><CHANNEL id='96' name='TVL_B' unit='°C'/><CHANNEL id='97' name='TVLs_B' unit='°C' dop='0'/><CHANNEL id='98' name='TRA_B' unit='°C'/><CHANNEL id='99' name='TRs_B' unit='°C'/><CHANNEL id='100' name='HKZustand_B' dop='0'/><CHANNEL id='101' name='FRB Zustand' dop='0'/><CHANNEL id='102' name='HKPB Status' dop='0'/><CHANNEL id='103' name='TBA' unit='°C'/><CHANNEL id='104' name='TBs_A' unit='°C' dop='0'/><CHANNEL id='105' name='TB1' unit='°C'/><CHANNEL id='106' name='TBs_1' unit='°C' dop='0'/><CHANNEL id='107' name='BoiZustand_1' dop='0'/><CHANNEL id='108' name='dummy2' dop='0'/><CHANNEL id='109' name='TB2' unit='°C'/><CHANNEL id='110' name='TBs_2' unit='°C' dop='0'/><CHANNEL id='111' name='BoiZustand_2' dop='0'/><CHANNEL id='112' name='TBB' unit='°C'/><CHANNEL id='113' name='TBs_B' unit='°C' dop='0'/><CHANNEL id='114' name='HKR Anf' unit='°C'/><CHANNEL id='115' name='Anf. HKR0' unit='°C' dop='0'/><CHANNEL id='116' name='Anf. HKR1' unit='°C' dop='0'/><CHANNEL id='117' name='Anf. HKR2' unit='°C' dop='0'/><CHANNEL id='118' name='Anf. HKR3' unit='°C' dop='0'/><CHANNEL id='119' name='Anf. HKR4' unit='°C' dop='0'/><CHANNEL id='120' name='Anf. HKR5' unit='°C' dop='0'/><CHANNEL id='121' name='Anf. HKR6' unit='°C' dop='0'/><CHANNEL id='122' name='Anf. HKR7' unit='°C' dop='0'/><CHANNEL id='123' name='Anf. HKR8' unit='°C' dop='0'/><CHANNEL id='124' name='Anf. HKR9' unit='°C' dop='0'/><CHANNEL id='125' name='Anf. HKR10' unit='°C' dop='0'/><CHANNEL id='126' name='Anf. HKR11' unit='°C' dop='0'/><CHANNEL id='127' name='Anf. HKR12' unit='°C' dop='0'/><CHANNEL id='128' name='Anf. HKR13' unit='°C' dop='0'/><CHANNEL id='129' name='Anf. HKR14' unit='°C' dop='0'/><CHANNEL id='130' name='Anf. HKR15' unit='°C' dop='0'/><CHANNEL id='131' name='dummy3' dop='0'/><CHANNEL id='132' name='UsePos' dop='0'/><CHANNEL id='133' name='AUPSoll' unit='mm'/><CHANNEL id='134' name='AUPIst' unit='mm'/><CHANNEL id='135' name='AUPStrom' unit='mA'/><CHANNEL id='136' name='TPO_ZusPuf1' unit='°C'/><CHANNEL id='137' name='TPM_ZusPuf1' unit='°C'/><CHANNEL id='138' name='TPU_ZusPuf1' unit='°C'/><CHANNEL id='139' name='Pfg_ZusPuf1' unit='%' dop='0'/><CHANNEL id='140' name='Pumpe_ZusPuf1' dop='0'/><CHANNEL id='141' name='ZusPuf1_soll oben' unit='°C' dop='0'/><CHANNEL id='142' name='ZusPuf1_soll unten' unit='°C' dop='0'/><CHANNEL id='143' name='ZusPuf1 Zustand' dop='0'/><CHANNEL id='144' name='Max Anf ZusPuf1' unit='°C' dop='0'/><CHANNEL id='145' name='Wasserdruck' unit='bar' dop='2'/><CHANNEL id='146' name='dummy4' dop='0'/></ANALOG><DIGITAL><CHANNEL id='0' bit='0' name='Störung'/><CHANNEL id='0' bit='1' name='Stb'/><CHANNEL id='0' bit='2' name='Fuellstand'/><CHANNEL id='0' bit='3' name='RLP/PuffP'/><CHANNEL id='0' bit='4' name='RLm_auf'/><CHANNEL id='0' bit='5' name='RLm_zu'/><CHANNEL id='0' bit='10' name='WS freig.'/><CHANNEL id='0' bit='11' name='Akt. Code'/><CHANNEL id='0' bit='14' name='FW Freig.'/><CHANNEL id='0' bit='15' name='gFlP'/><CHANNEL id='0' bit='16' name='gFlM auf'/><CHANNEL id='0' bit='17' name='gFlM zu'/><CHANNEL id='0' bit='18' name='gFl2P'/><CHANNEL id='0' bit='19' name='gFl2M auf'/><CHANNEL id='0' bit='20' name='gFl2M zu'/><CHANNEL id='1' bit='0' name='L Heiz.'/><CHANNEL id='1' bit='1' name='Z Heiz.'/><CHANNEL id='1' bit='2' name='Z Geb.'/><CHANNEL id='1' bit='3' name='AA Run'/><CHANNEL id='1' bit='4' name='AA Dir'/><CHANNEL id='1' bit='5' name='ES Run'/><CHANNEL id='1' bit='6' name='ES Dir'/><CHANNEL id='1' bit='7' name='AS Saug'/><CHANNEL id='1' bit='8' name='AS RA Run'/><CHANNEL id='1' bit='9' name='AS RA Dir'/><CHANNEL id='1' bit='10' name='Rein En'/><CHANNEL id='1' bit='11' name='Rein Run'/><CHANNEL id='1' bit='12' name='Es Rein Endl'/><CHANNEL id='1' bit='13' name='sAS Anf Füll'/><CHANNEL id='2' bit='0' name='HKPA'/><CHANNEL id='2' bit='1' name='MAA'/><CHANNEL id='2' bit='2' name='MAZ'/><CHANNEL id='2' bit='3' name='HKP1'/><CHANNEL id='2' bit='4' name='M1A'/><CHANNEL id='2' bit='5' name='M1Z'/><CHANNEL id='2' bit='6' name='HKP2'/><CHANNEL id='2' bit='7' name='M2A'/><CHANNEL id='2' bit='8' name='M2Z'/><CHANNEL id='2' bit='9' name='HKP3'/><CHANNEL id='2' bit='10' name='M3A'/><CHANNEL id='2' bit='11' name='M3Z'/><CHANNEL id='2' bit='12' name='HKP4'/><CHANNEL id='2' bit='13' name='M4A'/><CHANNEL id='2' bit='14' name='M4Z'/><CHANNEL id='2' bit='15' name='HKP5'/><CHANNEL id='2' bit='16' name='M5A'/><CHANNEL id='2' bit='17' name='M5Z'/><CHANNEL id='2' bit='18' name='HKP6'/><CHANNEL id='2' bit='19' name='M6A'/><CHANNEL id='2' bit='20' name='M6Z'/><CHANNEL id='2' bit='21' name='HKPB'/><CHANNEL id='2' bit='22' name='MBA'/><CHANNEL id='2' bit='23' name='MBZ'/><CHANNEL id='2' bit='24' name='HK-P Poolp'/><CHANNEL id='2' bit='25' name='HK-P Primp'/><CHANNEL id='2' bit='26' name='HK-P MA'/><CHANNEL id='2' bit='27' name='HK-P MZ'/><CHANNEL id='3' bit='0' name='BPA'/><CHANNEL id='3' bit='1' name='BP1'/><CHANNEL id='3' bit='2' name='BP2'/><CHANNEL id='3' bit='3' name='BP3'/><CHANNEL id='3' bit='4' name='BPB'/><CHANNEL id='3' bit='5' name='BZPA'/><CHANNEL id='3' bit='6' name='BZP1'/><CHANNEL id='3' bit='7' name='BZP2'/><CHANNEL id='3' bit='8' name='BZP3'/><CHANNEL id='3' bit='9' name='BZPB'/><CHANNEL id='4' bit='0' name='Aschebox'/><CHANNEL id='4' bit='1' name='Netztrafo'/><CHANNEL id='4' bit='2' name='Netzrelais'/><CHANNEL id='4' bit='4' name='Lagerraum'/><CHANNEL id='4' bit='6' name='FLP'/><CHANNEL id='4' bit='8' name='ATW'/><CHANNEL id='4' bit='9' name='Entasch gesp.'/><CHANNEL id='4' bit='13' name='HKV'/><CHANNEL id='4' bit='14' name='Spülung Aktiv'/><CHANNEL id='4' bit='15' name='ExtHK vorh'/><CHANNEL id='4' bit='16' name='ExtHK_2 vorh'/><CHANNEL id='4' bit='17' name='ExtHK_3 vorh'/><CHANNEL id='6' bit='0' name='ExtHK Anf'/><CHANNEL id='6' bit='2' name='ExtHK_2 Anf'/><CHANNEL id='6' bit='3' name='ExtHK_3 Anf'/><CHANNEL id='6' bit='4' name='ExtHK Pumpe'/><CHANNEL id='6' bit='6' name='ExtHK_2 Pumpe'/><CHANNEL id='6' bit='7' name='ExtHK_3 Pumpe'/><CHANNEL id='6' bit='8' name='KASK1 MinLeist'/><CHANNEL id='6' bit='9' name='KASK2 MinLeist'/><CHANNEL id='6' bit='10' name='KASK3 MinLeist'/><CHANNEL id='6' bit='11' name='KASK4 MinLeist'/><CHANNEL id='6' bit='12' name='KASK1 MaxLeist'/><CHANNEL id='6' bit='13' name='KASK2 MaxLeist'/><CHANNEL id='6' bit='14' name='KASK3 MaxLeist'/><CHANNEL id='6' bit='15' name='KASK4 MaxLeist'/><CHANNEL id='6' bit='16' name='KASK1 Run'/><CHANNEL id='6' bit='17' name='KASK2 Run'/><CHANNEL id='6' bit='18' name='KASK3 Run'/><CHANNEL id='6' bit='19' name='KASK4 Run'/><CHANNEL id='6' bit='20' name='KASK1 OK'/><CHANNEL id='6' bit='21' name='KASK2 OK'/><CHANNEL id='6' bit='22' name='KASK3 OK'/><CHANNEL id='6' bit='23' name='KASK4 OK'/><CHANNEL id='6' bit='24' name='Kask KWK Out'/><CHANNEL id='6' bit='25' name='Kask FW Out'/><CHANNEL id='6' bit='26' name='KASK KWK OK'/><CHANNEL id='6' bit='27' name='KASK FW OK'/><CHANNEL id='7' bit='0' name='DReg P2'/><CHANNEL id='7' bit='1' name='DReg P3'/><CHANNEL id='7' bit='2' name='DReg Mi auf'/><CHANNEL id='7' bit='3' name='DReg Mi zu'/><CHANNEL id='7' bit='5' name='DReg2 P2'/><CHANNEL id='7' bit='6' name='DReg2 Mi auf'/><CHANNEL id='7' bit='7' name='DReg2 Mi zu'/><CHANNEL id='7' bit='9' name='DReg3 P2'/><CHANNEL id='7' bit='10' name='DReg3 P3'/><CHANNEL id='7' bit='11' name='DReg3 Mi auf'/><CHANNEL id='7' bit='12' name='DReg3 Mi zu'/></DIGITAL></DAQPRJ>""",

Die Analog Werte schauen schon gut aus.
Bei den Digitalen bin Ich noch nicht ganz sicher. Heizkreispumpe 1 und 3 passt.
Aber folgende springen dauernd zwischen true und false hin und her:

[karlspace]

Hallo @pschimik,

danke für das fertige Template — und Entschuldigung für die lange Funkstille von meiner Seite.

Dein Template ist gemerged: 42db181, Key V14_1HAR_q_nano2_zuspuf_aup3. Es steht in firmware_templates.py und in der Firmware-Auswahl.

Verifikation gegen deinen Mitschnitt

Ich habe dein Template gegen die pm-Zeile aus deinem ersten Post durch den echten Parser laufen lassen:

Analog-Kanäle	147 (id 0–146)
Digital-Words	8 (id 0–7)
Erwartete Länge	155
Werte in deiner Nachricht	155

Exakter Treffer, kein Rest. Stichproben aus der Dekodierung (Kessel war zu dem Zeitpunkt aus, ZK=1):

Parameter	Wert
TK (Kessel)	67.7 °C
TRG (Rauchgas)	69.9 °C
Taus (Außen)	5.2 °C
Lagerstand	3006 kg
Verbrauchszähler	4814 kg
AUPIst	2.5 mm
TPO_ZusPuf1	70.8 °C

Die passen alle zusammen — die Analog-Seite sitzt.

Zusätzlich habe ich 12 Parameter-Beschreibungen (DE/EN) für die Zusatzpuffer- und HKP3/4-Kanäle ergänzt, damit im FULL-Set lesbare Namen statt Protokoll-Keys stehen.

Zu den flackernden Digital-Werten

Zwei Dinge, die dir beim Weitersuchen helfen sollten.

1. Der DIGITAL-Block deines Templates ist identisch mit dem aus V14_1HAR_q1. Du hast ihn übernommen, was für den Einstieg genau richtig war — aber es heißt eben auch, dass er noch nicht an deine Hardware angepasst ist. Deine Anlage hat einen Zusatzpuffer und ein AUP-Board mehr; dass die Bit-Belegung dann 1:1 passt, wäre Zufall.

2. In deinem Mitschnitt ist Word 0 = 406. Das sind gesetzte Bits 1, 2, 4, 7 und 8. Die Bits 7 und 8 sind im Template gar nicht benannt — deine Steuerung nutzt dort also Bits, die das q1-Layout nicht kennt. Das ist der konkreteste Hinweis darauf, dass in Word 0 etwas verschoben ist.

Zum Nachmessen: die Digital-Words stehen in deiner Nachricht an den Positionen 148–155 (nach pm gezählt), also die letzten acht Werte — bei dir 406 0 0 0 1 0 0 0. Wenn du zwei, drei pm-Zeilen in verschiedenen Betriebszuständen mitschneidest (tools/telnet_tester.py) und dazuschreibst, was die Anlage währenddessen wirklich gemacht hat — Pumpe läuft / Mischer fährt auf / Entaschung aktiv — lässt sich Bit für Bit zuordnen. Ein Mitschnitt "Kessel aus" gegen "Leistungsbrand" trennt schon eine Menge.

Nebenbei behoben

Dein ursprüngliches Symptom — "nearly all values correct, but sadly only nearly" — war schwerer zu finden als nötig. Der Parser hat die Längenabweichung nur auf DEBUG geloggt und trotzdem weitergeparst. Das ist jetzt anders (c3bcc2e):

• WARNING beim ersten Auftreten und bei jeder Änderung der Länge
• Der Verbindungs-Sensor zeigt firmware_template, expected_length und last_message_length als Attribute — Template-Passung ist damit direkt in der UI prüfbar

Und tools/parameter_validator.py lief überhaupt nicht mehr (veralteter src/-Import) und hat, wäre er gelaufen, wegen eines vertauschten Arguments nur ein einziges Template geprüft. Auch repariert (ceadbfc).

Ich lasse das Issue offen, bis die Digital-Seite sitzt. Wenn du die Mitschnitte hast, schau ich mir die Zuordnung gern konkret an.

Für dein InfluxDB-Vorhaben: die Analog-Kanäle kannst du ab jetzt als verlässlich betrachten.