Test Adapter OpenKNX 0.6.x

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

[killroy2]

@tdoc Das darf nicht funktionieren, dem Adapter fehlen relevante Informationen wie die 2 Byte zu interpretieren sind. Du bekommst aber eine präsente Fehlermeldung.

[killroy2]

@vogelsang probiere mit der nächsten Version wenn sie herauskommt. Das ist ein Fehler in .10, der wurde mittlerweile implizit gefixt

[Bachl]

@killroy2
Vielen Dank für den Adapter.
Habe diesen kurz getestet. Funktioniert bisher fehlerfrei.

Viele Grüße!

[tdoc]

@killroy2 said in Test Adapter OpenKNX 0.1.x:

@tdoc Das darf nicht funktionieren, dem Adapter fehlen relevante Informationen wie die 2 Byte zu interpretieren sind. Du bekommst aber eine präsente Fehlermeldung.

Hm, verstehe deine Antwort nicht ganz. "DAS" darf nicht funktionieren? Was darf nicht funktionieren?
Natürlich funktioniert es prima, wenn ich manuell einen DPT 9.004 in das iobroker-Objekt eingebe. Jetzt weiß der Adapter ja, wie die 2 Byte zu interpretieren sind. Und alle Warnungen sind weg und ich bin glücklich und zufrieden. Hab die Wetterdaten halt früher nie verwendet und deshalb nie gesehen, dass im ioBroker Objekt nur Unsinn steht. Dank deiner Warnungen ist mir jetzt der Fehler aufgefallen.

Noch ein paar Hintergrundinformationen: natürlich sind heute DPTs in KNX vorgeschrieben. Unsere Installation stammt aber noch aus EIB-Zeiten. D.h. es gab allenfalls EIS (EIS = EIB Interworking Standard), Vorläufer und ähnlich den DPTs von heute. Unser zertifizierter Elektriker hat jedenfalls entweder nie EIS benutzt (war damals explizit zulässig, damals wie heute wird bei fehlendem Datentyp lt. KNX ein definierter Standardwert für die gegebene Länge gesetzt)) und nur mit Länge gearbeitet, oder aber die Konvertierung (von EIS in DPTs) ist an dieser Stelle schiefgelaufen. Kann ich heute nicht mehr nachvollziehen. Die damalige Installation im Haus funktioniert natürlich, und die heute mir vorliegende ETS5 Datei muss eben eingelesen werden. Das hat mit dem anderen KNX-Adapter sogar leidlich geklappt, Gott sei Dank. Nur ein bisschen Handarbeit (auch noch beim Read und Write). Schalten und Status- Zuordnung hat dort aber gut geklappt.

Hingegen klappt beim Einlesen mit deinem Adapter (über XML) gar nichts (bin also froh, dass ich den anderen Weg gegangen bin). Die Fehlermeldung hat auch nichts zu tun mit den fehlenden DPTs, sondern das Einlesen scheitert bei deinem Adapter durchgängig am Zuordnen der Schaltadressen zu den Statusadressen. Im Endergebnis werden genau 0 Objekte erzeugt.

Wie gesagt, ich werde trotzdem deinen Adapter verwenden, er funktioniert ansonsten gut und ich halte ihn schon jetzt für die besere Alternative. Aber das Paaren von Schalten mit Status klappt nicht, Ergebnis war Null Objekte.

Mein Rat an alle: Jeder, der neu anfängt, sollte natürlich den XML-Weg gehen. Jeder, der ein gut funktionierendes System hat und Angst hat, hier zu verschlimmbessern, sollte aber durchaus mal vergleichen, ob er mit dem iobroker-json Export der Objekte (und Import nach openknx nach vorherigem suchen-und-ersetzen der entsprechenden Einträge von "KNX" durch "openknx") nicht besser fährt.

freundliche Grüße
Thomas

[killroy2]

@tdoc Ich meinte es ist gut dass der Adapter die unterdefinierten GAs bemängelt.
Was funktioniert denn beim Einlesen der XML nicht?
Die Zuordnung zu Status GA wertet der Adapter nicht anhand der alten Konfiguration aus. Das geht jetzt seit v0.1.11 über Alias. Wenn du das meinst mit es werden 0 Objekte erzeugt dann kann das an deiner Benamung liegen und der nicht passend eingestellten Filterregel

[tombox]

@tdoc
kannst du mir mal die XML schicken. Vielleicht können wir das problem beheben
tombox2020@gmail.com

[wizard2010]

Hi,

I'm getting this error when importing:

Ignoring Corredor.Aquecimento.PRE_COR_SWITCH_COUNTER because no DPT is assigned to 1339. The GA is not connected to a KO in ETS
Ignoring Corredor.Aquecimento.PRE_COR_SWITCH_COUNTER_REACHED because no DPT is assigned to 1340. The GA is not connected to a KO in ETS
Ignoring Corredor.Aquecimento.PRE_COR_SET_POINT_LOWER_HYSTERESIS because no DPT is assigned to 1342. The GA is not connected to a KO in ETS
Ignoring Corredor.Aquecimento.PRE_COR_SET_POINT_UPPER_HYSTERESIS because no DPT is assigned to 1343. The GA is not connected to a KO in ETS
Ignoring Corredor.Aquecimento.PRE_COR_OVERHEAT_TEMP because no DPT is assigned to 1344. The GA is not connected to a KO in ETS
Ignoring Corredor.Aquecimento.PRE_COR_AVG_TEMP because no DPT is assigned to 1345. The GA is not connected to a KO in ETS
Ignoring Cozinha.Luzes.IN_COZ_LUZES_FAIL_STATUS because no DPT is assigned to 2054. The GA is not connected to a KO in ETS
Ignoring Cozinha.Aquecimento.PRE_COZ_ON_OFF because no DPT is assigned to 2361. The GA is not connected to a KO in ETS
Ignoring Cozinha.Aquecimento.PRE_COZ_ON_OFF_STATUS because no DPT is assigned to 2364. The GA is not connected to a KO in ETS
Ignoring Cozinha.Aquecimento.PRE_COZ_SWITCH_COUNTER because no DPT is assigned to 2365. The GA is not connected to a KO in ETS
Ignoring Cozinha.Aquecimento.PRE_COZ_SWITCH_COUNTER_REACHED because no DPT is assigned to 2366. The GA is not connected to a KO in ETS
Ignoring Cozinha.Aquecimento.PRE_COZ_RIGHT_TEMP because no DPT is assigned to 2367. The GA is not connected to a KO in ETS

Any idea what is wrong here?

Thanks