NEWS
Test Adapter OpenKNX 0.6.x
-
Hallo zusammen,
Wenn ich Temperaturangaben vom Bus lese, werden mir diese nicht korrekt angezeigt. Das ist mir erst jetzt bei den niedrigen Außentemperaturen aufgefallen, da im ioBroker immer was um die 20° angezeigt wurden.
Der Datentyp in der ETS ist 9.001 Temperatur, da wird soweit im ioBroker Objekt auch angezeigt:
"bitlength": 16, "dpt": "DPT9.001", "valuetype": "basic"Wenn ich die Werte in der ETS (z.B. 2,28°C) mit denen in ioBroker (z.B. 17,85 ) vergleiche ist das schon ein deutlicher Unterschied. Ich gehe davon aus, dass die Umrechnung des Hex-Wertes aus der ETS nicht richtig ist.
Ist das ein Bug, ein fehlendes Feature oder ein Anwenderfehler?
-
Hallo zusammen,
Wenn ich Temperaturangaben vom Bus lese, werden mir diese nicht korrekt angezeigt. Das ist mir erst jetzt bei den niedrigen Außentemperaturen aufgefallen, da im ioBroker immer was um die 20° angezeigt wurden.
Der Datentyp in der ETS ist 9.001 Temperatur, da wird soweit im ioBroker Objekt auch angezeigt:
"bitlength": 16, "dpt": "DPT9.001", "valuetype": "basic"Wenn ich die Werte in der ETS (z.B. 2,28°C) mit denen in ioBroker (z.B. 17,85 ) vergleiche ist das schon ein deutlicher Unterschied. Ich gehe davon aus, dass die Umrechnung des Hex-Wertes aus der ETS nicht richtig ist.
Ist das ein Bug, ein fehlendes Feature oder ein Anwenderfehler?
-
@killroy2
Ist installiert.
Nach dem Start kommt dasFound 510 valid KNX objects of 514 objects in this adapter. Connected! Connecting to knx gateway: 10.1.1.15:3671 with phy. Adr: 1.1.1 minimum send delay: 50ms debug level: info starting. Version 0.7.2 in /opt/iobroker/node_modules/iobroker.openknx, node: v18.17.1, js-controller: 5.0.17und dann ganz oft
Got confirmation flag false for x/y/z openknx.0.NameDerGA. Possibly no receiver available or missing ETS receiver configuration. -
@killroy2
Ist installiert.
Nach dem Start kommt dasFound 510 valid KNX objects of 514 objects in this adapter. Connected! Connecting to knx gateway: 10.1.1.15:3671 with phy. Adr: 1.1.1 minimum send delay: 50ms debug level: info starting. Version 0.7.2 in /opt/iobroker/node_modules/iobroker.openknx, node: v18.17.1, js-controller: 5.0.17und dann ganz oft
Got confirmation flag false for x/y/z openknx.0.NameDerGA. Possibly no receiver available or missing ETS receiver configuration.@hant0r sagte in Test Adapter OpenKNX 0.6.x:
node: v18.17.1
Und wie immer...
Dringend vom obsoleten Repo absteigen und auf das aktuelle wechseln.
Periob nodejs-updateam besten.
-
@tisp relativ unwahrscheinlich dass ein genereller Fehler mit Temperatur bisher nicht aufgefallen wäre. Bei mir zB ist es plausibel. Falls du es nicht lösen kannst poste bitte mehr Daten z.B. SW Version, Werte von Signalen an den Schnittstellen etc.
@killroy2 Ich konnte es bisher noch nicht lösen. Ich versuche mal alle aus meiner Sicht vielleicht relevanten Daten zu schreiben. Sollte etwas fehlen, gerne kurz melden, ich liefere gerne alles um dieses Problem zu lösen.
ioBroker:
Version 6.12.0
Platform: docker
Architecture: x86
Nodejs: v18.16.0
NPM: 9.5.1
OpenKNX Adapter Version: 0.6.3KNX:
Temperatur wird mittels Gira KNX Taster 116223 ermittelt
Funktion: Ist-Temperatur
Länge 2 BytesETS
Datentyp: 9.001 (Temperatur °C)Wenn ich den aktuellen Wert in der ETS auslese wird folgendes angezeigt: 02 27 | 5,51°
(bei dem Wert 02 27 handelt es sich um einen hexadezimal Wert). Das kommt der tatsächlichen Temperatur sehr nahe.Im ioBroker steht gleichzeitig ein Wert von 17,85°
Im ioBroker hat das Objekt folgende Eigenschaften (etwas gekürzt):
{ "_id": "openknx.0.Sensoren.Temperatur.Außen_Terrasse_Temperatur", "type": "state", "common": { "desc": "Basetype: 16-bit floating point value", "name": "Außen Terrasse Temperatur", "read": true, "role": "state", "type": "number", "unit": "°C", "write": false, } }, "native": { "address": "7/5/1", "answer_groupValueResponse": false, "autoread": true, "bitlength": 16, "dpt": "DPT9.001", "valuetype": "basic" } -
@killroy2 Ich konnte es bisher noch nicht lösen. Ich versuche mal alle aus meiner Sicht vielleicht relevanten Daten zu schreiben. Sollte etwas fehlen, gerne kurz melden, ich liefere gerne alles um dieses Problem zu lösen.
ioBroker:
Version 6.12.0
Platform: docker
Architecture: x86
Nodejs: v18.16.0
NPM: 9.5.1
OpenKNX Adapter Version: 0.6.3KNX:
Temperatur wird mittels Gira KNX Taster 116223 ermittelt
Funktion: Ist-Temperatur
Länge 2 BytesETS
Datentyp: 9.001 (Temperatur °C)Wenn ich den aktuellen Wert in der ETS auslese wird folgendes angezeigt: 02 27 | 5,51°
(bei dem Wert 02 27 handelt es sich um einen hexadezimal Wert). Das kommt der tatsächlichen Temperatur sehr nahe.Im ioBroker steht gleichzeitig ein Wert von 17,85°
Im ioBroker hat das Objekt folgende Eigenschaften (etwas gekürzt):
{ "_id": "openknx.0.Sensoren.Temperatur.Außen_Terrasse_Temperatur", "type": "state", "common": { "desc": "Basetype: 16-bit floating point value", "name": "Außen Terrasse Temperatur", "read": true, "role": "state", "type": "number", "unit": "°C", "write": false, } }, "native": { "address": "7/5/1", "answer_groupValueResponse": false, "autoread": true, "bitlength": 16, "dpt": "DPT9.001", "valuetype": "basic" }@tisp sagte in Test Adapter OpenKNX 0.6.x:
Nodejs: v18.16.0
NPM: 9.5.1Veraltet, bring den Docker auf Stand.
-
@killroy2 Ich konnte es bisher noch nicht lösen. Ich versuche mal alle aus meiner Sicht vielleicht relevanten Daten zu schreiben. Sollte etwas fehlen, gerne kurz melden, ich liefere gerne alles um dieses Problem zu lösen.
ioBroker:
Version 6.12.0
Platform: docker
Architecture: x86
Nodejs: v18.16.0
NPM: 9.5.1
OpenKNX Adapter Version: 0.6.3KNX:
Temperatur wird mittels Gira KNX Taster 116223 ermittelt
Funktion: Ist-Temperatur
Länge 2 BytesETS
Datentyp: 9.001 (Temperatur °C)Wenn ich den aktuellen Wert in der ETS auslese wird folgendes angezeigt: 02 27 | 5,51°
(bei dem Wert 02 27 handelt es sich um einen hexadezimal Wert). Das kommt der tatsächlichen Temperatur sehr nahe.Im ioBroker steht gleichzeitig ein Wert von 17,85°
Im ioBroker hat das Objekt folgende Eigenschaften (etwas gekürzt):
{ "_id": "openknx.0.Sensoren.Temperatur.Außen_Terrasse_Temperatur", "type": "state", "common": { "desc": "Basetype: 16-bit floating point value", "name": "Außen Terrasse Temperatur", "read": true, "role": "state", "type": "number", "unit": "°C", "write": false, } }, "native": { "address": "7/5/1", "answer_groupValueResponse": false, "autoread": true, "bitlength": 16, "dpt": "DPT9.001", "valuetype": "basic" }@tisp
schalte mal um auf loglevel alles und berichte. So in der Art:openknx.0 2024-01-21 22:14:44.097 silly States user redis pmessage openknx.0.*/openknx.0.Umwelt.Umwelt_Temperatur.Aussentemperatur_Dach:{"val":3.3,"ack":true,"ts":1705871684096,"q":0,"from":"system.adapter.openknx.0","user":"system.user.admin","lc":1705871564381} openknx.0 2024-01-21 22:14:44.050 silly [trace] 2024-01-21 21:14:44.050 (idle): UDP sent OK: TUNNELING_ACK 06100421000a04121400 openknx.0 2024-01-21 22:14:44.050 debug Inbound GroupValue_Response from 1.1.240 GA 4/0/1 to Object openknx.0.Umwelt.Umwelt_Temperatur.Aussentemperatur_Dach value: 3.3 dpt: DPT9.001 openknx.0 2024-01-21 22:14:44.050 debug [debug] 2024-01-21 21:14:44.050 (idle): zzzz... openknx.0 2024-01-21 22:14:44.050 silly [trace] 2024-01-21 21:14:44.050 (recvTunnReqIndication): Sending TUNNELING_ACK ==> {"header_length":6,"protocol_version":16,"service_type":1057,"total_length":10,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunnstate":{"channel_id":18,"tunnel_endpoint":"192.168.0.10:3671","seqnum":20}} openknx.0 2024-01-21 22:14:44.050 silly [trace] 2024-01-21 21:14:44.049 (idle): Received TUNNELING_REQUEST_L_Data.ind message: {"header_length":6,"protocol_version":16,"service_type":1056,"total_length":23,"tunnstate":{"header_length":4,"channel_id":18,"seqnum":20,"rsvd":0},"cemi":{"msgcode":41,"addinfo_length":0,"ctrl":{"frameType":1,"reserved":0,"repeat":1,"broadcast":1,"priority":3,"acknowledge":0,"confirm":0,"destAddrType":1,"hopCount":6,"extendedFrame":0},"src_addr":"1.1.240","dest_addr":"4/0/1","apdu":{"apdu_length":3,"apdu_raw":{"type":"Buffer","data":[0,64,1,74]},"tpci":0,"apci":"GroupValue_Response","data":{"type":"Buffer","data":[1,74]}}}} openknx.0 2024-01-21 22:14:44.049 debug [debug] 2024-01-21 21:14:44.049 Inbound message: 061004200017041214002900bce011f02001030040014a openknx.0 2024-01-21 22:14:44.006 debug Inbound GroupValue_Read from 1.1.134 GA 4/0/1 to openknx.0.Umwelt.Umwelt_Temperatur.Aussentemperatur_Dach -
@tisp sagte in Test Adapter OpenKNX 0.6.x:
Nodejs: v18.16.0
NPM: 9.5.1Veraltet, bring den Docker auf Stand.
Hmm... wenn's tatsächlich daran lag, kann ich nur sagen "selber Schuld".
root@iobroker:/opt/iobroker# node -v v18.17.1 root@iobroker:/opt/iobroker# npm -v 9.6.7Nach der Aktualisierung scheinen die gelieferten Temperaturwerte in ioBroker plausibler zu sein. Ich werde das heute Abend zu Hause mal überprüfen, habe gerade keine Zugriff auf die ETS.
-
Hmm... wenn's tatsächlich daran lag, kann ich nur sagen "selber Schuld".
root@iobroker:/opt/iobroker# node -v v18.17.1 root@iobroker:/opt/iobroker# npm -v 9.6.7Nach der Aktualisierung scheinen die gelieferten Temperaturwerte in ioBroker plausibler zu sein. Ich werde das heute Abend zu Hause mal überprüfen, habe gerade keine Zugriff auf die ETS.
Ist aber auch nicht der aktuelle Stand.
nodejs 18.19.0 und npm 10.x.x
wäre das. -
Ist aber auch nicht der aktuelle Stand.
nodejs 18.19.0 und npm 10.x.x
wäre das. -
@thomas-braun Dann muss ich noch mal schauen. Das ist das, was mir bei einem apt-get update; apt-get upgrade installiert wurde.
iob stop iob fix iob nodejs-updateBzw. beim docker auch irgendwie anders. Musst du dir anschauen, wie das da geht.
-
Moin zusammen, ich erhalte im Log immer wieder die Meldung
openknx.0 2024-02-29 17:56:44.939 warn Ignoring GroupValue_Write of of unknown GA 2/0/11 openknx.0 2024-02-29 17:56:44.894 warn Ignoring GroupValue_Write of of unknown GA 2/0/10Beim Import wurden die beiden DPs nicht angelegt.
Was kann ich hier tun? -
Moin zusammen, ich erhalte im Log immer wieder die Meldung
openknx.0 2024-02-29 17:56:44.939 warn Ignoring GroupValue_Write of of unknown GA 2/0/11 openknx.0 2024-02-29 17:56:44.894 warn Ignoring GroupValue_Write of of unknown GA 2/0/10Beim Import wurden die beiden DPs nicht angelegt.
Was kann ich hier tun? -
@hant0r habe das gleiche Problem. Müllt mir leider mein Log zu
Ist aber erst seit dem Update auf 0.7.2 so -
@mhuber said in Test Adapter OpenKNX 0.6.x:
hab mal ein Issue aufgemacht auf github
danke ... bin zurück auf die 0.70
-
Aktuelle Testversion v0.7.3-alpha.1 Stabile Version: 0.6.3 Erstveröffentlichungsdatum 16.12.2021 Github Link https://github.com/iobroker-community-adapters/ioBroker.openknx/ NPM Link https://www.npmjs.com/package/iobroker.openknx Issues Board in GitHub https://github.com/iobroker-community-adapters/ioBroker.openknx/issues Installation der Testversion
"Adapter", "Expertenmodus", "Octocat", "Benutzerdefiniert" und diesen Link:
https://github.com/iobroker-community-adapters/ioBroker.openknx.gitAdapter Beschreibung, Changelog etc.
Hier ist die erste öffentliche Testversion des Open KNX Adapters. Der Adapter kommuniziert über ein IP Interface mit dem KNX Bus. Verschiedene KNX Telegrammtypen (GroupValue_Read, GroupValue_Write, GroupValue_Response) in Sende- und Empfangsrichtung werden in, dem IOB Anwender vertrauten Interaktionen mit IoBroker Objekten übersetzt.Motivation
Ich habe den Adapter aus einer Not heraus erstellt, da der verfügbare Adapter nicht fehlerfrei lief und nicht kompatibel zu meinen IP Interfaces ist. Debuggen war aufgrund Closed Source nicht möglich. Da Adapter läuft so gut, dass ich ihn der Öffentlichkeit übergeben möchte.
Der Adapter ist Quelloffen, Code kann gerne von Jedermann inspiziert und Pull Requests eingestellt werden.
Eine Beschreibung des Adapters und dessen Verwendung ist auf den verlinkten Seiten zu finden.Ziel
Der Adapter soll:- Stabil laufen und sich Standardkonform verhalten
- möglich einfach und verständlich sein
Thema umgesetzt ab Version Erwartung Release 0.1.x Release im stable repository Installation 0.1.6 Adapter lässt sich fehlerfrei über NPM installieren Installation 0.1.9 Adapter lässt sich über IOB Bordmittel installieren Betrieb 0.1.6 Adapter zeigt den Betriebszustand (rot,gelb,grün) korrekt an, bei Verbindungsabbrucht wird der Adapter gelb, keine Warnungen im Log die nicht zum Zustand passen Betrieb 0.1.8 keine Warnungen im Log die nicht zum Zustand passen Übersetzung 0.1.8 Admin Dialoge in alle Sprachen übersetzt, Logs nicht Alias 0.1.11 Generierung von Alias zur Zusammenbringen von Status und Ausgabe-GA zu einem Objekt eingebaut, noch nicht fehlerfrei Ich erhoffe mir Feedback zB zu
- Bugs, Error Logs;
- Verständlichkeit und Vollständigkeit der Doku
- Verwendbarkeit des Adapters, sind die Features brauchbar, was fehlt essentielles
- Code Reviews
- Erfahrungen aus dem Betrieb
- Ideen zur Geschäftslogik, zB werden aktuell Szenen DPTs von der Autoread Abfrage bei Start ausgeschlossen; gibt es bessere Filter?
- Verbesserungsvorschläge am Interface, z.B. welche State roles eignen sich für welche DPTs, sind die Datentypen passend gewählt, ...
Feature Anfragen, Fehlermeldungen dürfen gerne in GitHub erstellt werden. Umsetzung erfolgt immer nach Beschlusslage.
-
Version 0.8.0 ist jetzt verfügbar. Änderungen sind:
feature: put KNX interface name into log
bugfix: #419 wait for connection complete before data processing in case of receiving data before
bugfix: #457 Ack missing after changing IOB object value@killroy2 Habe gestern die 0.9.0 installiert. Läuft soweit ohne Probleme!
Danke! -
@123brokerei
Die Übersetzung aus dem Englischen ist nicht verständlich.Sending a group value read can be triggered by writing a communicaton object with comment.Details stehen unter Api call
c: comment, // optional, set it to value GroupValue_Read to trigger a bus group value read to this object, given StateValue is ignoredIch passe die Hilfe an damit keiner an der Stelle stecken bleibt.
Hi, auch wenn die Frage schon eine weile zurück liegt anbei wie ich es letztlich gelöst habe eine GroupValue_Read über Blockly auf den Bus zu bekommen.
Blockly (Am Beispiel Status für das Garagentor)
Code der Funktion
setState('openknx.0.Tür_Tor.Garagentor.K2-M1_Torposition_STATUS_(0_zu__100_offen)', { val: 50, ack: false, q: 0x10 });Auf den Code wird übrigens auch in der Hilfe verweisen und dass es mit comment in Jacascript wohl nicht funktioniert.
-
Hallo,
ich bin heute von dem anderen KNX Adapter auf diesen umgestiegen. Nach etlichen Änderungen in der ETS habe ich nun meine Datenpunkte alle importiert bekommen.
Mein Größtes Problem ist jetzt, dass der Adapter sehr lange benötigt zum schalten.
openknx.0 2024-10-08 21:36:25.009 silly States user redis pmessage openknx.0.*/openknx.0.info.messagecount:{"val":1665,"ack":true,"ts":1728416185008,"q":0,"from":"system.adapter.openknx.0","user":"system.user.admin","lc":1728416185008} openknx.0 2024-10-08 21:36:24.928 silly States user redis pmessage openknx.0.*/openknx.0.info.busload:{"val":1,"ack":true,"ts":1728416184926,"q":0,"from":"system.adapter.openknx.0","user":"system.user.admin","lc":1728416179924} openknx.0 2024-10-08 21:36:23.100 silly States user redis pmessage openknx.0.*/openknx.0.schalten_status.EG.licht_wc_spiegel_schalten_status:{"val":false,"ack":true,"ts":1728416183099,"q":0,"from":"system.adapter.openknx.0","user":"system.user.admin","lc":1728416183099} openknx.0 2024-10-08 21:36:23.097 debug Inbound GroupValue_Write from 1.2.3 GA 6/1/5 to Object openknx.0.schalten_status.EG.licht_wc_spiegel_schalten_status value: false dpt: DPT1.001 openknx.0 2024-10-08 21:36:22.941 silly States user redis pmessage openknx.0.*/openknx.0.schalten.EG.licht_wc_spiegel_schalten:{"val":false,"ack":true,"ts":1728416182939,"q":0,"from":"system.adapter.openknx.0","user":"system.user.admin","lc":1728416174434} openknx.0 2024-10-08 21:36:22.937 debug Inbound GroupValue_Write confirmation true received for 1/1/5 openknx.0.schalten.EG.licht_wc_spiegel_schalten openknx.0 2024-10-08 21:36:22.937 debug A receiver confirmed reception of our message for 1/1/5 openknx.0.schalten.EG.licht_wc_spiegel_schalten openknx.0 2024-10-08 21:36:21.429 silly States user redis pmessage openknx.0.*/openknx.0.aktoren.Spannungsversorgung.spannungsversorgung_1_3_14_Busstrom:{"val":84,"ack":true,"ts":1728416181427,"q":0,"from":"system.adapter.openknx.0","user":"system.user.admin","lc":1728416181427} openknx.0 2024-10-08 21:36:21.385 debug Inbound GroupValue_Write from 1.3.14 GA 9/5/4 to Object openknx.0.aktoren.Spannungsversorgung.spannungsversorgung_1_3_14_Busstrom value: 84 dpt: DPT9.021 openknx.0 2024-10-08 21:36:21.367 silly States user redis pmessage openknx.0.*/openknx.0.zentral.Wetterdaten.windgeschwindigkeit:{"val":0.87,"ack":true,"ts":1728416181365,"q":0,"from":"system.adapter.openknx.0","user":"system.user.admin","lc":1728416181365} openknx.0 2024-10-08 21:36:21.362 debug Inbound GroupValue_Write from 1.1.11 GA 0/0/12 to Object openknx.0.zentral.Wetterdaten.windgeschwindigkeit value: 0.87 dpt: DPT9.005 openknx.0 2024-10-08 21:36:20.007 silly States user redis pmessage openknx.0.*/openknx.0.info.messagecount:{"val":1662,"ack":true,"ts":1728416180006,"q":0,"from":"system.adapter.openknx.0","user":"system.user.admin","lc":1728416180006} openknx.0 2024-10-08 21:36:19.926 silly States user redis pmessage openknx.0.*/openknx.0.info.busload:{"val":1,"ack":true,"ts":1728416179924,"q":0,"from":"system.adapter.openknx.0","user":"system.user.admin","lc":1728416179924} openknx.0 2024-10-08 21:36:18.933 silly States user redis pmessage openknx.0.*/openknx.0.aktoren.Zähler.Zählerstand_Wärmepumpe2:{"val":15537,"ack":true,"ts":1728416178931,"q":0,"from":"system.adapter.openknx.0","user":"system.user.admin","lc":1728400868654} openknx.0 2024-10-08 21:36:18.930 debug Inbound GroupValue_Write from 1.1.62 GA 9/2/21 to Object openknx.0.aktoren.Zähler.Zählerstand_Wärmepumpe2 value: 15537 dpt: DPT13.013 openknx.0 2024-10-08 21:36:16.879 silly States user redis pmessage openknx.0.*/openknx.0.aktoren.Spannungsversorgung.spannungsversorgung_1_3_14_Busstrom:{"val":178.88,"ack":true,"ts":1728416176878,"q":0,"from":"system.adapter.openknx.0","user":"system.user.admin","lc":1728416176878} openknx.0 2024-10-08 21:36:16.877 debug Inbound GroupValue_Write from 1.3.14 GA 9/5/4 to Object openknx.0.aktoren.Spannungsversorgung.spannungsversorgung_1_3_14_Busstrom value: 178.88 dpt: DPT9.021 openknx.0 2024-10-08 21:36:15.008 silly States user redis pmessage openknx.0.*/openknx.0.info.messagecount:{"val":1660,"ack":true,"ts":1728416175006,"q":0,"from":"system.adapter.openknx.0","user":"system.user.admin","lc":1728416165005} openknx.0 2024-10-08 21:36:14.926 silly States user redis pmessage openknx.0.*/openknx.0.info.busload:{"val":0,"ack":true,"ts":1728416174924,"q":0,"from":"system.adapter.openknx.0","user":"system.user.admin","lc":1728416169924} openknx.0 2024-10-08 21:36:14.435 debug Outbound GroupValue_Write to " 1/1/5 value: false from openknx.0.schalten.EG.licht_wc_spiegel_schalten openknx.0 2024-10-08 21:36:14.435 silly States user redis pmessage openknx.0.*/openknx.0.schalten.EG.licht_wc_spiegel_schalten:{"val":false,"ack":false,"ts":1728416174434,"q":0,"from":"system.adapter.admin.0","user":"system.user.admin","lc":1728416174434}vom auslösen des Schaltbefehls bis tatsächlichen schalten, vergehen ca. 8 Sekunden. Am MDT IP Router wird es wohl kaum liegen. Mit dem anderen KNX Adapter klappt es. Woran kann das liegen?
Node.js: v20.17.0
NPM: 10.8.2
openknx: 0.9.0
Support us
752
Online32.4k
Users81.4k
Topics1.3m
Posts