Test Adapter OpenKNX 0.6.x

killroy2

@chrischros ich brauche Logs, Daten, ... wie ich den Fehler reproduzieren und analysieren kann. An der Codestelle ist erstmal nichts auffälliges und wird auch permanent durchlaufen.

tombox

@killroy2 Also für mich sieht die Codestelle nicht gut aus und der Fehler ist eigentlich klar weil es vorher kein check gibt

Cannot read property 'current_value' of undefined
(/opt/iobroker/node_modules/iobroker.openknx/main.js:505:64)

netfriend

Hallo,
ich habe den openknx 0.1.15 über iobroker installiert. Das xml-File der ETS5 konnte ich nahezu fehlerfrei importieren. Ging relativ schnell, es waren 574 GAs, die 3 angemeckerten Fehler waren nachvollziehbar. Hatte die Zuweisung von DPTs zur GA vergessen. Nach einer Korrektur war der Import fehlerfrei möglich und der Adapter startet auch! Sieht schon mal sehr gut aus.
Wenn man nun den Bus im Gruppenmonitor beobachtet und in openknx kontrolliert, füllen sich auch langsam die Objekte.

Allerdings habe ich bei meinen Verbrauchszählern ein Problem. Über ein mdt-Tasterinferface, das als Verbrauchszähler konfiguriert ist, bekomme ich Impulse von meinem Wasserzähler.
Das KO im Gerät ist als "DPT 12.1200 (4-Byte vorzeichenlos) Volumen Flüssigkeit (l)" parametriert.
Im Gruppenmonitor wird mir dies auch korrekt angezeigt und ich sehe Werte.

Im XML steht folgendes:

<GroupAddress Name="Wasserzähler : Zähler" Address="1/5/10" DPTs="DPST-12-1200" />

Im openknx-Objekt steht folgendes:

{
  "_id": "openknx.0.Zentralfunktion.Verbrauchszähler.Wasserzähler_:_Zähler",
  "type": "state",
  "common": {
    "desc": "Basetype: 4-byte unsigned value",
    "min": 0,
    "max": 4294967295,
    "name": "Wasserzähler : Zähler",
    "read": true,
    "role": "state",
    "type": "number",
    "write": true
  },
  "native": {
    "address": "1/5/10",
    "answer_groupValueResponse": false,
    "autoread": true,
    "bitlength": 32,
    "dpt": "DPT12.1200",
    "valuetype": "basic"
  },
  "from": "system.adapter.openknx.0",
  "user": "system.user.admin",
  "ts": 1645115985826,
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

Einerseits fehlt die unit (bei anderen GAs funktioniert das einwandfrei) und andererseits erhalte ich keine Werte.
Wer kann helfen?
Kann man beim openknx ein Log einschalten? In den Adaptereinstellungen habe ich dazu nichts gefunden (oder übersehen) und im Protokoll des iobroker taucht als "Quelle" kein "openknx" auf.

Danke für Eure Unterstützung!

tombox

@netfriend Der DPST-12-1200 ist nicht eingefügt.
Eine Diskussion bezüglich Updates von DPT und anderen Fehlern findest du hier
https://github.com/iobroker-community-adapters/ioBroker.openknx/issues/101#issuecomment-1022657106

TA2k created this issue in iobroker-community-adapters/ioBroker.openknx

closed Switch to KNXEngine from node knx ultimate #101

netfriend

@tombox Danke für den Link. So wie ich das verstehe, sind die DPTs nur prinzipiell vorhanden, also der Datentyp wird interpretiert, aber die zahlreichen Unter-DPTs mit allen möglichen Einheiten nicht, richtig?

Ich habe nun den DPT von 12.1200 auf 12.001 (Counter pulses ohne Einheit) umgestellt. Nun bekomme ich Werte. Find ich schon einmal gut.
Was mich allerdings wundert: Bei meinem Gaszähler-Counter ist DPT 14.076 (Volumen m³) eingestellt. Lt. dem Link ist diese DPT auch nicht implementiert, ähnlich wie bei 12.1200. Aber hier bekomme ich Werte?

tombox

@netfriend
DPT 14.076 ist nicht enthalten. Ein Update ist für Mitte 2022 geplant.
Es ist außerdem nicht gewünscht das der Nutzer die Werte empfangen kann, wenn das DPT nicht vorhanden ist.

netfriend

@tombox sagte in Test Adapter OpenKNX 0.1.x:

@netfriend
DPT 14.076 ist nicht enthalten. Ein Update ist für Mitte 2022 geplant.

Ok, das klingt gut!

Es ist außerdem nicht gewünscht das der Nutzer die Werte empfangen kann, wenn das DPT nicht vorhanden ist.

Ich hätte auch erwartet, wenn der xml-Import problemlos klappt, dass alle DPTs aus dem xml vorhanden sind und korrekt verwendet werden. Andernfalls hätte ich eine Fehlermeldung erwartet (z.B. DPT 14.076 nicht implementiert). Das würde so manchen Selbstzweifel und Fehlersuche sparen.

ChrisChros

Hallo,
nach einem Restart des Raspberry über die Console bekomme ich wieder folgende Fehlermeldungen im Log:

2022-02-19 09:05:41.851  - [32minfo[39m: host.raspberrypi instance system.adapter.openknx.0 started with pid 688
2022-02-19 09:05:44.832  - [32minfo[39m: openknx.0 (688) starting. Version 0.1.19 in /opt/iobroker/node_modules/iobroker.openknx, node: v14.19.0, js-controller: 4.0.8
2022-02-19 09:05:44.870  - [32minfo[39m: openknx.0 (688) Connecting to knx gateway:  10.10.20.2:3671   with phy. Adr: 1.1.253 minimum send delay: 50 ms
2022-02-19 09:05:44.872  - [32minfo[39m: openknx.0 (688) /opt/iobroker/node_modules/iobroker.js-controller
2022-02-19 09:05:45.213  - [31merror[39m: openknx.0 (688) [error] 2022-02-19 08:05:45.157 (idle): Incomplete/unparseable UDP packet: TypeError: Cannot read property 'current_value' of undefined
    at fsm.event (/opt/iobroker/node_modules/iobroker.openknx/main.js:505:64)
    at fsm.<anonymous> (/opt/iobroker/node_modules/machina/lib/webpack:/src/emitter.js:27:1)
    at arrayEach (/opt/iobroker/node_modules/lodash/lodash.js:530:11)
    at Function.forEach (/opt/iobroker/node_modules/lodash/lodash.js:9410:14)
    at fsm.emit (/opt/iobroker/node_modules/machina/lib/webpack:/src/emitter.js:25:1)
    at fsm.emitEvent (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:602:10)
    at fsm._onEnter (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:552:14)
    at fsm.transition (/opt/iobroker/node_modules/machina/lib/webpack:/src/BehavioralFsm.js:175:1)
    at fsm.Fsm.<computed> [as transition] (/opt/iobroker/node_modules/machina/lib/webpack:/src/Fsm.js:80:1)
    at fsm.inbound_TUNNELING_REQUEST_L_Data.ind (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:340:16): 0610020800089300
2022-02-19 09:05:45.222  - [31merror[39m: openknx.0 (688) [error] 2022-02-19 08:05:45.220 (idle): Incomplete/unparseable UDP packet: TypeError: Cannot read property 'current_value' of undefined
    at fsm.event (/opt/iobroker/node_modules/iobroker.openknx/main.js:505:64)
    at fsm.<anonymous> (/opt/iobroker/node_modules/machina/lib/webpack:/src/emitter.js:27:1)
    at arrayEach (/opt/iobroker/node_modules/lodash/lodash.js:530:11)
    at Function.forEach (/opt/iobroker/node_modules/lodash/lodash.js:9410:14)
    at fsm.emit (/opt/iobroker/node_modules/machina/lib/webpack:/src/emitter.js:25:1)
    at fsm.emitEvent (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:602:10)
    at fsm._onEnter (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:552:14)
    at fsm.transition (/opt/iobroker/node_modules/machina/lib/webpack:/src/BehavioralFsm.js:175:1)
    at fsm.Fsm.<computed> [as transition] (/opt/iobroker/node_modules/machina/lib/webpack:/src/Fsm.js:80:1)
    at fsm.inbound_TUNNELING_REQUEST_L_Data.ind (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:340:16): 061004200019049301002900bce011fe240805008040f9999a
2022-02-19 09:05:45.236  - [31merror[39m: openknx.0 (688) [error] 2022-02-19 08:05:45.234 (idle): Incomplete/unparseable UDP packet: TypeError: Cannot read property 'current_value' of undefined

Scheinbar hat der Adapter ab und zu Probleme sich bei einem Neustart des RPi richtig zu verbinden. Wenn ich den Adapter dann manuell über die WebPage neu starte gibt es anschließend keine Probleme mehr und der Adapter läuft ohne Probleme.

2022-02-19 09:54:02.013  - [32minfo[39m: host.raspberrypi "system.adapter.openknx.0" disabled
2022-02-19 09:54:02.029  - [32minfo[39m: host.raspberrypi stopInstance system.adapter.openknx.0 (force=false, process=true)
2022-02-19 09:54:02.059  - [31merror[39m: openknx.0 (688) [error] 2022-02-19 08:54:02.058 (idle): Incomplete/unparseable UDP packet: TypeError: Cannot read property 'current_value' of undefined
    at fsm.event (/opt/iobroker/node_modules/iobroker.openknx/main.js:505:64)
    at fsm.<anonymous> (/opt/iobroker/node_modules/machina/lib/webpack:/src/emitter.js:27:1)
    at arrayEach (/opt/iobroker/node_modules/lodash/lodash.js:530:11)
    at Function.forEach (/opt/iobroker/node_modules/lodash/lodash.js:9410:14)
    at fsm.emit (/opt/iobroker/node_modules/machina/lib/webpack:/src/emitter.js:25:1)
    at fsm.emitEvent (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:602:10)
    at fsm._onEnter (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:552:14)
    at fsm.transition (/opt/iobroker/node_modules/machina/lib/webpack:/src/BehavioralFsm.js:175:1)
    at fsm.Fsm.<computed> [as transition] (/opt/iobroker/node_modules/machina/lib/webpack:/src/Fsm.js:80:1)
    at fsm.inbound_TUNNELING_REQUEST_L_Data.ind (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:340:16): 06100420001504936f002900bce011fe244d010080
2022-02-19 09:54:02.086  - [32minfo[39m: openknx.0 (688) Got terminate signal TERMINATE_YOURSELF
2022-02-19 09:54:02.087  - [32minfo[39m: host.raspberrypi stopInstance system.adapter.openknx.0 send kill signal
2022-02-19 09:54:02.088  - [32minfo[39m: openknx.0 (688) terminating
2022-02-19 09:54:02.090  - [32minfo[39m: openknx.0 (688) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2022-02-19 09:54:02.687  - [32minfo[39m: host.raspberrypi instance system.adapter.openknx.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)
2022-02-19 09:58:10.065  - [32minfo[39m: host.raspberrypi "system.adapter.openknx.0" enabled
2022-02-19 09:58:10.346  - [32minfo[39m: host.raspberrypi instance system.adapter.openknx.0 started with pid 1625
2022-02-19 09:58:12.435  - [32minfo[39m: openknx.0 (1625) starting. Version 0.1.19 in /opt/iobroker/node_modules/iobroker.openknx, node: v14.19.0, js-controller: 4.0.8
2022-02-19 09:58:12.475  - [32minfo[39m: openknx.0 (1625) Connecting to knx gateway:  10.10.20.2:3671   with phy. Adr: 1.1.253 minimum send delay: 50 ms
2022-02-19 09:58:12.476  - [32minfo[39m: openknx.0 (1625) /opt/iobroker/node_modules/iobroker.js-controller
2022-02-19 09:58:13.319  - [32minfo[39m: openknx.0 (1625) Connected!
2022-02-19 09:58:13.788  - [32minfo[39m: openknx.0 (1625) Found 934 valid KNX objects of 936 objects in adapter.

killroy2

Hallo @netfriend,

eine Information zum Logging findest du zB im Readme auf NPM. Link dazu im Eingangspost.

DPT 12.1200 wird bis Version 0.1.19 nicht unterstütz, nur sein Basistyp DPT12. Vom Konzept können alle Telegramme unabhängig vom DPT gesendet und empfangen werden. Wenn ein DPT nicht nativ unterstütz wird gibt es eine Logeintrag. In deinem Beispiel fehlt dir die Einheit als Metainformation, was keine gravierende Einschränkung sein dürfte. Alle DPTs zu unterstützen ist eine Sisyphusaufgabe und einige davon sind mir noch nicht untergekommen. Die Erstellung passiert nach und nach. Die von dir beschriebenen nehme ich ins nächste Release auf.
Dass DPT 12.1200 bei dir nicht geht ist tatsächlich ein Fehler den ich bei mir reproduzieren konnte! Der Fehler ist im nächsten Release behoben.

Bitte lass dich hier nicht durch unqualifizierte Falschaussagen von Projektunbeteiligten verwirren.

netfriend

@killroy2 Danke für Deine Rückmeldung!
Prima, dass Du dich der Sache annimmst und dies im nächsten Release nachziehen möchtest! Das ist nicht selbstverständlich, ich weiß den Zeitaufwand, der darin steckt (Testen, versuchen nachzustellen, analysieren, beheben, wieder testen) sehr zu schätzen! Herzlichen Dank!
Prinzipiell hast Du Recht, dass die fehlenden Einheiten nicht sehr störend sind. Allerdings ist es bei mir (und wahrscheinlich bei den meisten) so, dass ich ein funktionierendes KNX-Projekt habe. Hier habe ich versucht, alles GAs ordentlich zu benennen und alles GAs und KOs die entsprechenden DPTs zuzuweisen (auch mit Einheiten, sofern von KNX vorgesehen).
Nun importiere ich mein xml in z.B. openknx und stelle fest, dass was nicht so angezeigt wird wie erwartet. Ich könnte damit leben, dass Einheiten fehlen, wenn die Werte korrekt angezeigt werden. Das war jetzt leider bei der 12.1200 nicht der Fall, damit musste ich mein KNX-Projekt anpassen und habe diese entsprechend auf 12.001 umgestellt. Ich wollte eigentlich vermeiden, dass ich am KNX-Projekt rumspiele war aber neugierig ob es dann funktioniert. Von daher wäre es mir persönlich am liebsten, wenn nicht implementierte DPTs dahingehend funktionieren indem der Basistyp verwendet wird und beim Import der xml-Datei ein enstsprechender Hinweis angezeigt wird. Damit würde ich mein KNX-Projekt unverändert lassen und warten/hoffen, dass dies mit einem künftigen Update in openknx behoben sein könnte.

Noch eine kurze Frage zum DPT 14.076. Den nutze ich für meinen Gaszähler. Wenn ich in der ETS dort z.B. den Wert 7,4 [m³] sende, sehe ich im Gruppenmonitor auch diesen Wert. In openknx wird aber 7,40000001 [m³] angezeigt.
Ist das hier ein Rundungsfehler oder woran liegt das? Parallel dazu habe ich noch den ioBroker-KNX-Adapter installiert, dort wird richtigerweise 7,4 [m³] angezeigt. Also gehe ich davon aus, dass am Bus der richtige Wert verfügbar ist.

Danke für Deine Hilfe!

killroy2

@chrischros
Kannst du die Stelle vom Log zeigen an dem die Fehler beginnen? Gibt es eine Möglichkeit den Fehler nachzustellen?
Du schreibst dass sich die Fehlermeldungen häufen wenn das Ereignis eintritt.
Annahme ist, dass der Adapter in einem inkonsistenten Zustand ist, und es nicht an äusseren Ereignissen liegt. Annahme ist auch, das Problem ist erst mit einer Änderung in der 0.1.19 Version sichtbar und bestand schon davor, die Auswirkung war aber weniger sichtbar. Mehr kann ich dazu noch nicht sagen.

ChrisChros

@killroy2 said in Test Adapter OpenKNX 0.1.x:

Kannst du die Stelle vom Log zeigen an dem die Fehler beginnen?

Das ist der erste Log-Auszug. Das war direkt nach dem Restart des RPi über die Console.

@killroy2 said in Test Adapter OpenKNX 0.1.x:

Gibt es eine Möglichkeit den Fehler nachzustellen?

Ich werde nachher noch mal einen Reboot vom RPi machen und schauen ob es sich dann genauso verhält.

@killroy2 said in Test Adapter OpenKNX 0.1.x:

Du schreibst dass sich die Fehlermeldungen häufen wenn das Ereignis eintritt.

Ja, es werden dann fast sekündlich die gleichen Zeilen in der Log geschrieben.

@killroy2 said in Test Adapter OpenKNX 0.1.x:

Annahme ist, dass der Adapter in einem inkonsistenten Zustand ist, und es nicht an äusseren Ereignissen liegt. Annahme ist auch, das Problem ist erst mit einer Änderung in der 0.1.19 Version sichtbar und bestand schon davor, die Auswirkung war aber weniger sichtbar.

Ich denke auch das der Adapter dann irgendwie hängen bleibt. Vor 0.1.19 hatte ich zumindest keine solchen Einträge im Log. Allerdings hätte mir das auffallen müssen da der Adapter dann nicht auf grün ist. Laut der Ansicht in den Instanzen ist der Adapter mit dem Host verbunden und bekommt ein Lebenszeichen, beide haben einen grünen Harken.
Nur Verbindung mit Gerät oder Dienst besteht dann nicht.

ChrisChros

Habe eben noch mal einen Neustart über die Console vom RPi ausgelöst und alles ist ganz normal gestartet. Keine Ahnung was heute morgen anders war.

killroy2

@netfriend said in Test Adapter OpenKNX 0.1.x:

Noch eine kurze Frage zum DPT 14.076. Den nutze ich für meinen Gaszähler. Wenn ich in der ETS dort z.B. den Wert 7,4 [m³] sende, sehe ich im Gruppenmonitor auch diesen Wert. In openknx wird aber 7,40000001 [m³] angezeigt.
Ist das hier ein Rundungsfehler oder woran liegt das? Parallel dazu habe ich noch den ioBroker-KNX-Adapter installiert, dort wird richtigerweise 7,4 [m³] angezeigt. Also gehe ich davon aus, dass am Bus der richtige Wert verfügbar ist.

Auf dem Bus liegt der Wert 0x40eccccd der interpretiert werden muss.
7.4 lässt sich mit Float nicht exakt darstellen, der nächste Wert ist 7.400000095367431640625. Die ETS schneidet oder rundet vermutlich den Wert der Mantisse. Ich habe dazu aber keine Doku gefunden. In der Spec wird nur auf IEEE 754 Single Precision verwiesen.

tombox

@killroy2

Welche zusätzliche Informatione als

Cannot read property 'current_value' of undefined
(/opt/iobroker/node_modules/iobroker.openknx/main.js:505:64)

brauchst du noch? Dürfen Projektunbeteiligten den undefined check einbauen?

Warum ist es eine Sisyphusaufgabe, wenn die KNXUltimate Engine schon alle DPTs unterstützt. Warum fixst du Fehler und DPTs die in der Engine, auf die du Mitte 2022 wechseln, willst schon behoben sind? Du hast doch ganz klar gesagt deine Timeline ist fix.

killroy2

@tombox Nein, ich habe den Fehler nicht vollständig durchdrungen. Aber du wirst sicher die Güte haben uns zu erklären wie der Fix geht.

tombox

@killroy2

const dp = this.gaList.getDpById(id);
if (!dp) {
 this.log.warn("Ignoring " + evt + " cannot find DP for id: " + id);
//this.log.info("DP size:" + this.gaList.dp.size
// add more log to show the current state of the adapter
return
}

killroy2

@tombox Du hast den Fehler nicht verstanden, was du schreibst ist Mist.
Die Daten sind in einem inkonsistenten Zustand, nicht mehr vertrauenswürdig! Du schlägst ernsthaft vor ich soll den Fehler degradieren und so tun als wäre es alles gut. Später kommen dann versprengte Meldungen von sporadischen Fehlern wo keiner weiss was lost ist weil du mir das Errorreporting kurzgeschlossen hast.

Schau dir die KNX Ultimate an, wenigstens einmal genau. Du wirst erkennen dass dort längst NICHT alle DPTs unterstützt werden.

Ich mag den beleidigten und vorwurfsvollen Ton nicht den du hier anschlägst. Du hast schon massiv auf Github gestört und trollst hier weiter. Du zweifelst permanent meine Entscheidungen an und forderst von mir öffentlich Rechtfertigung, auf die du keinen Anspruch hast. In diesem Thread geht es um den Test des Adapters. Ich werde ab jetzt die Admins beten off Topic Themen konsequent zu löschen.

tombox

@killroy2
Danke für konstruktive Antwort ohne vorwursvollen Ton
Es geht nur darum das der Adapter nicht mehr crasht und man plausible Logs bekommt als den Adapter immer wieder crashen zu lassen. Ich denke mit guten Logs kann man immer nachvollziehen was los. Ich sehe nicht wo das Error reporting "kurzgeschlossen" ist mit einem zusätzlichen undefined check.
Aber am Ende wieder deine Entscheidung kein Check einzubauen und zu hoffen das man das Problem ohne zusätzliche Logs irgendwann findet.

Es sind nicht alle DPs zu untersützen aber 90% und doppelt soviel wie jetzt enthalten sind.
Bitte schaue dir doch die Engine genau an
https://github.com/Supergiovane/KNXUltimate/tree/main/src/dptlib
Am Ende wieder deine Entscheidung DPs selber zu pflegen anstatt die bestehende Arbeit zu nutzen, bzw. sie ab Mitte 2022 zu nutzen..

killroy2

in zwei deiner Zitate:
"wenn die KNXUltimate Engine schon alle DPTs unterstützt"
" Also für mich sieht die Codestelle nicht gut aus und der Fehler ist eigentlich klar weil es vorher kein check gibt"
hast du dir damit nachweislich selbt widersprochen. An anderer Stelle hast du ebenso Unwarheiten verbreitet und dir Dinge angemasst. Das sind einfach zugängliche Fakten, die kann jeder sehen und überprüfen.

Jetzt forderst du wieder mal Dinge die man machen sollte und müsste und ohne die deiner Meinung ein Makel besteht. Für aussenstehende sind das schwer zu überprüfende Behauptungen und haben hier nichts verloren. Das hier ist das falsche Forum um technische Umsetzungen zu diskutieren. Hier sprechen wir über Validierung und Verifikation des Adapters.

Durch dieses Verhalten bringst du ständig das Projekt in diskredit. Ich werde ständig genötigt auf deine Halbwahrheiten einzugehen. Das interessiert hier keinen. Mittlerweile ist ein Punkt überschritten wo ich das nicht mehr tolerieren kann.

NEWS

Test Adapter OpenKNX 0.6.x

closed Switch to KNXEngine from node knx ultimate #101

Support us

701
Online

31.6k
Users

79.5k
Topics

1.3m
Posts

NEWS

Test Adapter OpenKNX 0.6.x

closed Switch to KNXEngine from node knx ultimate #101

Support us

701Online

31.6kUsers

79.5kTopics

1.3mPosts

701
Online

31.6k
Users

79.5k
Topics

1.3m
Posts