Test Adapter OpenKNX 0.6.x

[netfriend]

@tontechniker Vielen Dank, hat geklappt!
Ich war schon auf Github, dort war aber immer nur die Version 0.5.3 zu lesen.
Ich wusste nicht, dass die Änderungen seit diesem Release als 0.6.0 laufen.

[killroy2]

Ich habe am 10.12.2023 die Version 0.6.3 veröffentlicht. Wenn nichts dagegen spricht wird das die neue stabile Version.
Neuerungen gibt es nichts relevantes zu dem was hier schon veröffentlicht wurde.

[killroy2]

Update: neue Testversion auf Github 0.7.0

Die Änderungen waren etwas umfangreicher.

• feature: adding support for DPT-28 and DPT-29
• for gas appearing in multiple objects severity lifted to warning
• feature: some more verbose failure outputs
• bugfix: do not report errors resulting from bad bus data to sentry #433
• bugfix: do not forward invalid bus data to iob object tree
• cleanup of DTP library

[netfriend]

@killroy2 Vielen Dank für Deinen unermüdlichen Einsatz!

[Hant0r]

Moin moin,

ich hatte gerade ein seltsames Verhalten.
Ich wunderte mich, warum einige Scripte auf Bewegung sehr träge reagiert haben und als ich ins Logs im ioBroker geschaut habe, kam ca. 4-5 mal die Sekunde folgende Meldung:

GroupValue_Write confirmation false received for 1/1/15 NameDerGA

Immer die selbe GA.
Einer eine Ahnung was da los ist?

Habe den Adapter einmal durchgestartet, seitdem ist wieder alles wie vorher und auch die Scripte reagieren wieder schneller.

Noch eine Frage:
Bei einem Neustart kommt für jede GA, die ich zwar erzeugt aber nicht belegt habe, folgende Meldung:

confirmation false received for 1/0/38 NameDerGA

Kann man das irgendwo deaktiveren?

[killroy2]

@hant0r said in Test Adapter OpenKNX 0.6.x:

Kann man das irgendwo deaktiveren?

Du kannst verhindern, dass es beim Start ausgelesen wird indem du

"autoread": false,

änderst.

[Hant0r]

@killroy2
Ist das diese Option beim Adapter?

Bringt das andere Nachteile mit sich?

[killroy2]

@hant0r
Nein ich meine hier, pro Objekt was auf Halde angelegt ist. In dem Zug kannst du die Objekte die nur von deiner Logik erzeugt werden gleich mit umstellen.

[Hant0r]

@killroy2 puh, das ist verdammt viel Arbeit.
Sind ja einige (hundert?) GAs... Dann leben ich lieber mit der Meldung beim Start.

Edit:
Was hat es denn mit der Fehlermeldung auf sich, weißt du das?

GroupValue_Write confirmation false received for 1/1/15 NameDerGA

[killroy2]

@hant0r

Probiere mal die Version 0.7.2 von NPM, ich habe ein paar Verbindungsprobleme verbessert.

die Log Info von dir kommt wenn vom IOB etwas auf den Bus geschickt wird und es von keinem Empfänger bestätigt wird. Dann ist keiner in der ETS konfiguriert oder er hat ein Problem.

[Hant0r]

@killroy2
Ist installiert.
Nach dem Start kommt das

Found 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.17

und dann ganz oft

Got confirmation flag false for x/y/z openknx.0.NameDerGA. Possibly no receiver available or missing ETS receiver configuration.

[tisp]

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]

@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]

@hant0r ok, dann ist ja alles gut, oder?

[Thomas Braun]

@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.
Per

iob nodejs-update

am besten.

[tisp]

@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.3

KNX:
Temperatur wird mittels Gira KNX Taster 116223 ermittelt
Funktion: Ist-Temperatur
Länge 2 Bytes

ETS
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"
  }

[Thomas Braun]

@tisp sagte in Test Adapter OpenKNX 0.6.x:

Nodejs: v18.16.0
NPM: 9.5.1

Veraltet, bring den Docker auf Stand.

[killroy2]

@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]

@thomas-braun

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.7                                   

Nach 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.

[Thomas Braun]

@tisp

Ist aber auch nicht der aktuelle Stand.
nodejs 18.19.0 und npm 10.x.x
wäre das.