Wer also genauso blöd ist wie ich (war), so kann ich gerne auch ein paar Hilfestellungen beim Einrichten geben. Ich hab so ziemlich alle Fehler ausprobiert die möglich sind, aber es doch in 2 Tagen geschafft. Jetzt sollte es eigentlich in 15 Minuten reibungslos über die Bühne gehen.

Mein größeres Problem ist jetzt aber die Sicherheit. Es ist zwar sehr bequem, mal schnell den iobroker über google home mit Sprache zu steuern, aber wenn ich mal das Handy verlege?? Die ganze Sicherheit meines Hauses hängt dann von der Pin meines Smartphone ab, ansonsten kann jeder mein Garagentor öffnen... das Sicherheitskonzept muss man also schon noch gründlich überdenken. Auch die ganzen Befehle über die Cloud sind nicht das Gelbe vom Ei, ich werde also doch eher nach einer lokalen Lösung suchen. Hab schon genug Bauchweh beim Fernzugriff über iobroker.pro, aber bequem ist das schon, wenn man mal schnell vom Arbeitsplatz was daheim erledigen kann.

Ist zwar schon etwas älter, aber ich hatte dasselbe Problem wie @lossen .

Mein Fehler: ich hatte vergessen, in der iot Instanz neben Alexa auch die Einstellungen für google vorzunehmen, insbesondere dort google als zulässigen Dienst anzuwählen (neben anderen Dingen, die man dort noch machen sollte). Deshalb hat iobroker (iot-Adapter) auch korrekt die Versuche von google verhindert, hier illegal die Konten zu verknüpfen. DAs Anmelden bei iobroker-Account klappte also, dann wurde wohl versucht, die Konten zu verknüpfen, und dann wurde festgestellt, dass in iobroker google nicht vorgesehen ist und wurde dort dann wieder abgeblockt. Die Fehlermeldung war schon korrekt ...

Ich habe exakt das gleiche Problem: lovelace ist nicht über iobroker.pro erreichbar, obwohl im cloud adapter aktiviert. Lokal geht.
Und auch der seltsame zweite Eintrag mit Port 8090 ist bei mir vorhanden (und funktioniert natürlich nicht). Hab ich ausgeblendet (Kosmetik).
Warten wir halt auf eine Lösung, kenne noch einige andere denen es genauso geht.

Der Adapter findet auch in anderen foren Beachtung. Hier ein Zitat aus dem knx-user-forum.de:

https://knx-user-forum.de/forum/öffentlicher-bereich/knx-eib-forum/1628955-iobroker-knx/page3#post1722210

Du musst das "Beta (latest)" Repository aktiviert haben, dann findest du den openKNX Adapter.

Hier noch ein bissel Doku im ioBroker-Forum und github.
https://forum.iobroker.net/topic/503...-openknx-0-1-x

https://github.com/iobroker-communit...Broker.openknx

Konnte bisher ohne Probleme 898 GAs importieren. Du musst nur schauen das alle GAs die entsprechenden Datentypen gesetzt haben sonst werden die nicht importiert.

Das Problem mit dem fehlenden Import von GAs ohne DPT hat sich schon weitgehend rumgesprochen. Als Lösung empfiehlt sich, vor dem Import älterer Installationen eben passende DPT in der ETS zu ergänzen. Wenn das nicht gerade tausende Objekte sind, kann man das in ein paar Stunden Handarbeit auch erledigen. Automatisch wäre natürlich schöner, vielleicht kommt das noch.

@thorsten-missenberger
Ja natürlich gibt es für dieses Problem einige Lösungsmöglichkeiten. Allerdings werde ich auch nicht der einzige sein, der eine alte KNX-Installation am Laufen hat und dann erst mal vom vergeblichen XML-Importversuch frustriert ist. Für solche alten KNX-Installationen sollte es m.E. eben eine einfache Lösung geben (vielleicht auch nur einen Hinweis in der read.me). Am praktischsten wäre aber eine Checkbox, die eben einen raw Import zulässt (also ohne DPT) und trotzdem Objekte erzeugt (in Abhängigkeit von der Länge würde die Importprozedur halt bei 1 bit z.B. erst mal provisorisch Datentyp 1.000 erzeugen, das ist am einfachsten)

Letztlich kommen die alten KNX-Installationen sehr gut ohne DPT aus. Jedes Gerät interpretiert eben die Rohdaten so, wie ihm vom Hersteller vorgegeben. Die DPT sind natürlich für die Übersichtlichkeit besser. Probleme gibt es aber erst, wenn andere Programme wie iobroker ins Spiel kommen und dann natürlich nicht wissen, was sie mit diesen Rohdaten anfangen sollen.

Grundsätzlich muss man aber so oder so Hand anlegen:

• entweder manuell in der knxproj Datei (und danach importieren)
• oder eben später manuell im iobroker (wenn es eine checkbox gäbe, die Rohdaten-Import zulässt)
  Und grundsätzlich muss der user wissen, dass es bei alten KNX-Installationen dieses Problem geben kann und wie er es lösen muss.

@tdoc
DPTs bestehen aus einer
main number - mit dem Datentyp
und
subnumber (right) - mit Range + Unit

Zur Datenverarbeitung ist es notwendig den Datentyp zu kennen. Die subnumber ist optional.
Der ETS4 Export, sowohl im XML und CSV Format, erzeugt nicht die DPT Informationen.
Der Chefkoch Adapter nutzt ein proprietäres ETS Austauschformat und kann dort in den Tiefen nach den notwendigerweise Vorhandenen Informationen graben.
Gegen welche Konvention der openknx Adapter verstossen soll müsstest du schon aufzeigen denn ich sehe keine. Das Konzept der ETS4 wahr wohl eher keine externen Tools zu supporten.

Du sagst du kannst zu ETS5 konvertieren. Wie sieht der XML Export dort ins eigene Format aus warum nimmst du den Output nicht von dort?

Hier einfach mal ein Auszug aus meiner aktuellen ETS5, die ich auch für Änderungen,umparametrieren etc. benutze. Wie du siehst, fehlen fast überall die DPT. Das kommt vom ursprünglichen Projekt, damals gab es noch keine DPT. Es ist halt eine sehr alte Installation,hat ein Elektriker vor 20 Jahren gemacht. Konvertierung aus dem ursprünglichen Projekt in ETS5 liegt mir also vor und funktioniert auch völlig problemlos. Trotz der fehlenden DPT (die ich nur bei Bedarf mal nachträglich einpflege).

Es wäre also grundsätzlich schon eine große Hilfe für ALLE alten KNX-Installationen, wenn man auch ohne DPT deinen Adpater benutzen könnte. Insbesondere könnte man importieren, so geht es nicht ohne weiteres. Aber wie gesagt, ich hab trotzdem für mich eine Lösung gefunden und benutze deinen Adapter gerne. Er ist gut. Macht bitte weiter so!

nochmal zurück zur Problematik mit den DPTs (Datenpunkttpyen).

Aktueller Stand:

• Ältere KNX-Projekte (vor ETS5) können mit openknx zur Zeit nicht importiert werden. Das liegt daran, dass erst seit ETS5 DPT den Gruppenadressen zugeordnet werden (können, müssen).
• Ältere KNX-Projekte laufen aber natürlich weiterhin problemlos, KNX und ETS ist weitgehend abwärtskompatibel. ETS4 (und älter!) kann auch problemlos in ETS5 konvertiert werden und dort weiterbenutzt werden. Es fehlen dann halt die DTP.
• fehlende DPT sind per definitionem (KNX) somit zwar ärgerlich, aber durchaus zulässig.

Was bedeuten fehlende DPT (bei älteren KNX-Installationen) für die Praxis? Natürlich läuft das KNX-Projekt weiterhin, kann auch nach Konversion zu ETS5 ohne DPT weiterhin verwendet und programmiert und parametriert werden. Unschön ist lediglich, dass u.U. beispielsweise ein (ganz neues) Anzeigegerät nicht weiß, was es mit den Werten anfangen soll. Es ist ein 2-Byte-Wert, aber welche Einheiten z.B.? Trotzdem fließen natürlich die Daten in der Installation weiterhin. Und in der Praxis muss man dann bei Installation eines neuen Gerätes eben einen Datenpunkttyp ergänzen, falls die Geräteanzeige unsinnig aussieht.

Schlussfolgerung: Fehlende Datenpunkttypen sollten kein Ausschlusskriterium für den Import sein. Dort, wo es stört (wegen der Weiterverarbeitung der Daten) muss der Anwender halt selbst später den passenden DPT in iobroker (oder in der ETS) ergänzen. Aber doch bitte kein Zwang, das schon vorher bei vielleicht 1000 GAs machen zu müssen!

Der andere Adapter von Chefkoch in der Version 1.x hatte damit keine Probleme. Und der neue Adapter in Version 2.x ist nunmehr auch dementsprechend angepasst worden (siehe https://github.com/ioBroker/ioBroker.knx/issues/128#issuecomment-989205691
"Ich habe in V2.0.5 den Importfilter für ETS4 projekte überarbeitet/angepasst. damit sollte es laufen" (letzter Eintrag).

malotira created this issue in ioBroker/ioBroker.knx

closed KNX Import aus ETS 4 schreibt keine Datenpunkte (DPT) in den Adapter. #128

@tombox
Hat sich erledigt. Es kann nichts importiert werden, weil keine DPT definiert sind. Hab für dieses Problem ja eine Lösung gefunden (verwende die bisher erzeugten Objekte weiter). Ansonsten hätte ich mir halt die Arbeit machen müssen und extra für den Import die DPTs definieren müssen. Mach ich vielleicht auch mal. Wie gesagt, das war die Arbeit einer zertifizierten Elektrikerfirma, vor 22 Jahren.

Hier gab es mit dem anderen Adapter keine Probleme. Auch die ETS 5 meckert bei einem Prüflauf zwar einiges an, aber nicht die fehlenden DPTs.

@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

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