Telegram Parse Error für Heizungs-Stellgrösse

[Tru]

Ich habe vor Kurzem HA aufgebaut und die KNX-Integration eingerichtet. Ich bin etwas verwirrt von diesen Warnungen, welche regelmässig auftreten

Can not process <Telegram direction="Incoming" source_address="1.1.27" destination_address="1/4/3" payload="<GroupValueWrite value="<DPTBinary value="63" />" />" /> for Gästezimmer Heizung - State: <CouldNotParseTelegram description="Payload invalid" device_name='Gästezimmer Heizung' feature_name='State' payload='<DPTBinary value="63" />'/>

Verstehe ich das richtig, dass an Stelle des erwarteten Bit-Wert ein Byte-Wert im Telegramm empfangen wird? Das kommt eigentlich für alle 6 RTH-Taster gleichartig vor.
Auf den RTH-Tastern ist allerdings "Schaltende PI-Regelung" eingestellt und die Stellgrösse hat ein KO 1bit eingerichtet.

grafik.png

Sowohl im ETS-Monitor wie auch mit dem knxtool vbusmonitor1 werden die Werte als 1bit Typ ausgewiesen.

grafik.png

Mir stellt sich jetzt die Frage wo das Problem liegt. Wird im Telegramm tatsächlich ein 1Byte Objekt verschickt und alle beteiligten KNX-Kompomenten (der Heizungsaktor und auch der ETS-Monitor) können irgendwie damit umgehen, weil es überall al 1bit Wert definiert ist? Oder liegt hier ein Parsingproblem der KNX-Integration vor?

Othmar

[Punker Deluxe]

Was da verschickt wird siehste in der ETS-Diagnose-Gruppenmonitor.

Wie sieht deine knx.yaml aus? Vermute mal da den "Fehler"

[Tru]

Was da verschickt wird siehste in der ETS-Diagnose-Gruppenmonitor.

Das müsste doch meinem zweiten Screenshot entsprechen, oder?

Wie sieht deine knx.yaml aus? Vermute mal da den "Fehler"

So sieht das entsprechende climate-Element aus:

    
    - name: "Gästezimmer Heizung"
      temperature_address: "1/4/9"
      target_temperature_address: "1/4/21"
      target_temperature_state_address: "1/4/15"
      temperature_step: 0.5
      on_off_state_address: "1/4/3"
​

[zenvy]

Hast du mal geschaut wer die 1.1.27 ist und ob die evtl fälschlicherweise ein KO an die 1/4/3 verknüpft hat welches eben nicht 1-Bit Werte sendet?

[Tru]

Hast du mal geschaut wer die 1.1.27 ist

Ja, die 1.1.27 ist der RTH-Taster von Screenshot 1, welcher den Kanal auf dem Heizungsaktor steuert. Da ist alles in Ordnung. Und bei den anderen 5 RTH-Tastern verhält es sich genau gleich.

[Punker Deluxe]

Das sollte doch state_address heißen und nicht on_off_state_address???

[Tru]

Nun, state_address gibt es gemäss Manual für climate nicht. Vielleicht müsste es stattdessen active_state_address sein. Die Bedeutung der einzelnen Parameter wird mir aus der Bechreibung nicht ganz klar.
Aber unabhängig davon handelt es sich bei beiden Varianten um DPT1 - daher ändert sich nichts am Problem dass für das Telegramm vom RTH-Taster ein Wert 63 gelesen wird obwohl der RTH-Taster einen DPT1 schickt.

[herr2d2]

Ich kann mir eigentlich auch nur vorstellen, dass die GA 1/4/3 noch an ein zweites Mal mit dem Taster verknüpft wurde und dieses KO die 63 versendet … solltest du in der ETS problemlos prüfen können…

[Tru]

Vielen Dank für die bisherigen Hinweise. Offensichtlich ist das nicht nur mir ein Rätsel.

Ich kann mir eigentlich auch nur vorstellen, dass die GA 1/4/3 noch an ein zweites Mal mit dem Taster verknüpft wurde und dieses KO die 63 versendet … solltest du in der ETS problemlos prüfen können…

Ich spiele zwar nur in der KNX-Amateur-Liga, aber einen solchen Fehler lässt die ETS doch gar nicht zu, oder? Wenn eine GA mal als 1bit Objekt auf ein KO gelegt wurde, dann kann sie doch nicht auch noch als ein anderer DPT verknüpft werden, oder?

Jedenfalls sieht das bei mir in der ETS meines Erachtens total korrekt aus. Es sind 6 RTH Taster und ein Heizaktor mit 6 Kanälen - hier mal die Darstellung der betroffenen 6 GAs:
grafik.png
Jede dieser Stellgrössen ist also genau 2 mal verknüpft, einmal auf dem jeweiligen Taster und auf je einem Kanal des Heizaktors.

Und hier noch die vollständigen Verknüpfungen eines einzelnen Tasters:
grafik.png

Der erwähnte Parsing Error in der KNX-Integration kommt für alle 6 GAs vor. Bisher noch nicht so häufig, weil noch kaum geheizt wird. Es handelt sich also um ein systematisches Problem und nicht um einen Einzelfall. Die betroffenen Telegramme werden dabei von 6 verschiedenen Tastern geschickt. Es handelt sich wohl kaum um einen Defekt einer Komponente.

Mittlerweile bin ich ziemlich stark überzeugt, dass auf der KNX-Seite alles in Ordnung ist (seit 2008 - so alt sind die Taster und der Heizaktor schon). Dann müsste der Fehler in der KNX-Integration liegen. Aber das kann ich mir eigentlich auch schlecht vorstellen.

Ich habe unterdessen in der YAML Definition den entsprechenden Parameter-Namen von on_off_state_address auf active_state_address umgestellt. Wie erwartet hat das an den Fehlermeldungen nichts geändert. Aber die Heizungskarte wird jetzt sinnvoller dargestellt. Während vorher ein Button zum Schalten der Heizung dargestellt wurde (was ja ohnehin keinen Sinn macht), wird jetzt effektiv der Zustand der Ventile dargestellt, normalerweise "Leerlauf (Heizung)"

Ich versuche mal ob ich Wireshark mit dem KNX-Modul zum Laufen kriege und probiere rauszufinden, was auf auf dem Raw-Level wirklich verschickt wird.

[herr2d2]

Ich nutze bei bei mir keine Heizungsregelung über KNX. Aber KO51 (Stellgröße) klingt nicht nach an/aus, sondern eher einem Wert zwischen 0-100 (z.B. 63 😉) und somit 1 Byte.

[Tru]

Ich nutze bei bei mir keine Heizungsregelung über KNX. Aber KO51 (Stellgröße) klingt nicht nach an/aus, sondern eher einem Wert zwischen 0-100 (z.B. 63 😉) und somit 1 Byte.

Da liegst du in diesem Fall falsch. Wie im Screenshot klar ersichtlich ist, ist KO51 vom Typ 1bit - das gibt ja die Applikation des Tasters vor und macht im Zusammenhang mit "Schaltende PI Regelung" auch Sinn, wo das Ventil während einer gewissen Zeit voll geöffnet und dann wieder geschlossen ist.

Mit Hilfe von Wireshark habe ich mein Rätsel zumindest im Grundsatz lösen können: Die betreffenden Telegramme haben tatsächlich 6bits auf 1 (x3F) gesetzt statt nur das letzte Bit. Die Fehlermeldungen der KNX-Integration sind also korrekt und ich werde sie halt einfach ignorieren.

Damit bin ich mit meinem Rätsel im falschen Subforum und ich lasse es damit auf sich beruhen.

Die Tasterapplikation hat offensichtlich eine Macke oder ein spezielles, mir unbekanntes Feature, wo (allerdings nur sporadisch) statt dem Wert x01 der Wert x3F geschickt wird, wo eigentlich der DPT1 definiert ist. Zur Steuerung der Kanäle im Heizaktor wird aber schon der Wert x01 geschickt.