Test Adapter OpenKNX 0.6.x

[ChrisChros]

@vogelsang bei mir sieht das ganze so aus wenn ich es mit der ETS 5.7.4 exportiere:

<GroupRange Name="Status aktuelle Position" RangeStart="11008" RangeEnd="11263">
      <GroupAddress Name="EG - Büro - Fenster 1 - Status aktuelle Position" Address="5/3/0" DPTs="DPST-5-1" />

[vogelsang]

@killroy2 So hätte ich das auch erwartet. ETS 5.7.6

Ich habe den Grund für den fehlerhaften Export gefunden. Es gibt Hersteller, bei denen die Objekte nicht eindeutig voreingestellt sind (z. B. Weinzierl KNX IO 530). Dann kann die ETS auch nicht eindeutig exportieren. Da ich meine GA immer manuell mit dem DPT einstelle, fällt das in der GA Ansicht auch nicht auf.

[ChrisChros]

@killroy2 mir ist eben noch eine Sache bezüglich Datum und Uhrzeit aufgefallen.
Von meiner Wetterstation bekomme ich die GPS Zeit und Datum für den Bus bereitgestellt. Hierzu habe ich auch extra 2 GAs angelegt und die entsprechenden Datentypen hinterlegt. Für das Datum DPT 11.001 und die Zeit DPT 10.001. Diese Datenpunkte werden auch in den Objekten in ioBroker angelegt:

{
  "_id": "openknx.0.Zentral.Wetter___Zeit___Datum.Datum",
  "type": "state",
  "common": {
    "desc": "Basetype: 3-byte date value",
    "name": "Datum",
    "read": true,
    "role": "date",
    "type": "number",
    "write": true
  },
  "native": {
    "address": "0/4/9",
    "answer_groupValueResponse": false,
    "autoread": true,
    "bitlength": 24,
    "dpt": "DPT11.001",
    "valuetype": "composite"
  },
  "from": "system.adapter.openknx.0",
  "user": "system.user.admin",
  "ts": 1640607178920,
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

Allerdings bekomme ich dann als Wert ein "Invalid Date" in den Objekten angezeigt.

Woran kann das liegen?

[killroy2]

@vogelsang

Ich habe mal eine GA angelegt und sie mit 2 Kommunikationsobjekte verbunden.
Das Gute ist ich kann den Subtype in den Kommunikationsobjekten selber umstellen, nur der Datapoint-Type ist vorgegeben.
Wenn ich an den 3 Stellen verschiedene Werte einstelle zB 1.005, 1.006, 1.007 nimmt er mir die kleinste Nummer 1.005
oder eben bei 1.005, 1.006, 1 den DPT-1

Warum die ETS das so macht ist mit nicht verständlich.
Also gilt die Regel: bei der ETS Konfiguration sicherstellen, dass der Datentyp in der GA und allen KOs identisch gesetzt ist.

[vogelsang]

@killroy2 Ja, so sehe ich das auch. Die ETS und ihre Rätsel...

[killroy2]

@chrischros
Bitte mal einen Wert von deiner Wetterstation hier posten der Probleme bereitet.
Was passiert wenn du einen DPT11.001 manuell mit der ETS schickst?

[killroy2]

@frankthegreat said in Test Adapter OpenKNX 0.1.x:

Import der GA's (ca. 700) erfolgt rasend schnell
hier hab ich festgestellt, das nach dem Import der Speicherbutton ausgegraut ist, ich kann also nur auf schließen drücken,
GA's werden aber trotzdem angelegt.

Ja das ist so gewollt. Der ist ausgegraut für neue Imports.
Nach dem Import bekommt der Adapter einen Reset und ist dann für Interaktionen mit dem Nutzer weg. Ich kenne keine Möglichkeit wie die Admin Oberfläche benachrichtigt wird wann der Adapter wieder da ist um die Buttons zu enablen.
Also muss der Nutzer schliessen und es wird nur wieder einmal bei Start geprüft.

[frankthegreat]

@killroy2 Ja, nee, alles gut.
Wenn das so funktioniert, ist es doch io. War nur im ersten Moment ungewohnt, weil man es bei anderen Adaptern so machen muß.

[vogelsang]

@killroy2 Nach der Änderung im Projekt werden nun auch die DPT richtig erkannt und importiert. Die unit wird allerdings immer noch nicht eingetragen.

[vogelsang]

Wie kann man bei diesem Adapter die Statusadresse mit der Schaltadresse koppeln? Die Schaltadresse wird ja nicht automatisch aktualisiert.

[frankthegreat]

@vogelsang sagte in Test Adapter OpenKNX 0.1.x:

@killroy2 Nach der Änderung im Projekt werden nun auch die DPT richtig erkannt und importiert. Die unit wird allerdings immer noch nicht eingetragen.

Das mit den Units wäre vl. eine Anregung für die Wunschliste
Hier als Anregung:

  "_id": "knx.0.Licht.Licht_Wert.Licht_Wert_-_EG_WC_Decke",
  "type": "state",
  "common": {
    "name": "Licht Wert - EG WC Decke",
    "type": "number",
    "role": "level",
    "read": false,
    "write": true,
    "unit": "%",
    "max": 100,
    "min": 0
  },
  "native": {
    "dpt": "DPT5.001",
    "address": "1/2/116",
    "addressRefId": "P-0495-0_GA-2136",
    "statusGARefId": "P-0495-0_GA-2265",
    "actGARefId": "",
    "update": false,
    "objRef": "O-393_R-576",
    "devName": "M-0002_A-A0AA-13-2B03",
    "devInst": "P-0495-0_DI-180",
    "objectSize": ""
  },
  "from": "system.adapter.knx.0",
  "user": "system.user.admin",
  "ts": 1621762100322,
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"

"unit": "%",

[killroy2]

@vogelsang hast du auch den Haken bei add only new objects raus bzw. kannst mal testen wenn das Objekt davor gelöscht wurde?

Falls es nichts bringt, wie sieht die Zeile in deinem XML Export aus?

Koppelung von Schalten und Status geht über IOB Alias. Automatisches Erzeugen kommt in der nächsten Version.

[ChrisChros]

@killroy2 Hat sich erledigt. Scheinbar wurden zu dem Zeitpunkt noch keine Werte über den Bus geschickt. Jetzt wird alles korrekt angezeigt.

[tdoc]

Prima. Bisher keine ernsthaften Probleme.
Bei jedem Neustart bekomme ich eine Meldung (Warnung) über Gruppenadressen ohne DP. Ist an sich korrekt und auch nicht störend. Vielleicht auch nur weil mein Protokoll Level "debug" ist.

Eine Warnung, die sich im Betrieb dauernd wiederholt, ist mir allerdings unklar:
openknx.0 2021-12-27 21:48:12.603 warn
[warn] "2021-12-27T20:48:12.603Z" 'DPT1.fromBuffer: buf should be 1 byte (got %d bytes)' 2

Da kann ich wohl nichts dran ändern?

Bei der Installation gab es keine Probleme. Allerdings hab ich danach nicht die ETS bemüht und einen XML-Export durchgeführt, sondern einfach mal die knx.0. exportiert und hier wieder eingelesen (weil ich dort seinerzeit einige Modifikationen machen musste, das Einlesen lief damals gar nicht rund). Also einfach die .json eingelesen und alles lief perfekt. Bis auf diese blöde dauernde Warnung ...

[vogelsang]

@killroy2

@vogelsang hast du auch den Haken bei add only new objects raus bzw. kannst mal testen wenn das Objekt davor gelöscht wurde?

Ich habe extra den Adapter gestoppt, alle Objekte gelöscht. Danach den Adapter gestartet und neu importiert.

[killroy2]

@vogelsang zeig nochmal deine Stelle mit dem neuen XML Export.
@tdoc Dein Ansatz mag funktionieren, erzeugt oder übernimmt viele Fehler. Du schreibst 2 byte auf einen Logikwert, das war vermutlich schon vorher so drin.

[vogelsang]

@killroy2 Guten Morgen und vielen Dank für diesen tollen Adapter und den tollen Support.

<GroupAddress Name="Flur Downlights Schalten" Address="1/0/1" DPTs="DPST-1-1" />
<GroupAddress Name="Flur Downlights Dimmen" Address="1/0/2" DPTs="DPST-3-7" />
<GroupAddress Name="Flur Downlights Dimmwert" Address="1/0/3" DPTs="DPST-5-1" />
<GroupAddress Name="Flur Downlights Schalten Status" Address="1/0/4" DPTs="DPST-1-1" />
<GroupAddress Name="Flur Downlights Dimmwert Status" Address="1/0/5" DPTs="DPST-5-1" />

[fritzke316]

@tombox
Habe heute den Adapter über GitHub installiert und jetzt werden auch bei mirdie Einheiten (Units) angezeigt!
Danke für den Tip!!

[tdoc]

@killroy2 said in Test Adapter OpenKNX 0.1.x:

@tdoc Dein Ansatz mag funktionieren, erzeugt oder übernimmt viele Fehler. Du schreibst 2 byte auf einen Logikwert, das war vermutlich schon vorher so drin.

Ich habe in unserer Zweitwohnung halt die ETS nicht zur Verfügung und wollte unbedingt deinen neuen Adapter ausprobieren. Werde dann natürlich dann mal auch den regulären Weg mit dem XML-Import beschreiten.

In der Tat hatte der alte Adapter zahlreiche Fehler beim Import produziert, die ich mühsam manuell korrigiert hatte. Ich habe also diese Baumstruktur mit den Objekten 1:1 übernommen (nur eben openknx.0.xxx genannt). Das funktionierte eigentlich gut.

Die Fehlermeldung ist in der DPT-Bibliothek für dpt1 hinterlegt:

exports.fromBuffer = (buf) => {
if (buf.length !== 1)
return log.warn(
'DPT1.fromBuffer: buf should be 1 byte (got %d bytes)',
buf.length
);
return buf[0] !== 0;
};

Da Datenpunkttypen nicht mit Telegrammen verschickt werden, so stimme ich dir zu, dass dies ebenfalls noch ein alter Fehler ist, den ich bisher nicht manuell korrigiert hatte. Ich fürchte allerdings, dass dieser Fehler in der KNX-Datei meines Elektrikers hinterlegt ist, muss das jetzt wohl nochmals durchforsten. - Beim Neueinlesen mittels XML-Import wird der Fehler vermutlich genauso auftauchen.

[tdoc]

@tdoc So, hab jetzt den Fehler lokalisiert. Es ist die Wetterstation (AlbrechtJung 20 Jahre alt!) die regelmäßig Helligkeit, Wind, Dämmerung und anderes sendet. Einiges mit 1 Bit, aber Sensor 1-3 auf die Gruppenadressen 0/0/9 0/0/10 und 0/0/26 eben mit einem 2 bytes Wert! Datentypen sind in meiner knxproj Datei nicht hinterlegt, sondern nur die Länge (hier eben 2 Bytes).

Der andere Adapter hat hier einfach beim Einlesen willkürlich DPT 1.001 hinterlegt, an dieser Stelle natürlich falsch. Mal sehen, ob dein Adapter beim Einlesen hier besser aufpasst und auch mit alten Projekt-dateien zurechtkommt, in denen nur die Länge in bit oder bytes hinterlegt ist, aber eben nicht der DPT. Das wird aber deinem Adapter möglicherweise auch Probleme bereiten.

Werde das erst mal manuell korrigieren und für Lux eben 9.004 vergeben usw.