UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[killroy2]

Hallo @netfriend,

eine Information zum Logging findest du zB im Readme auf NPM. Link dazu im Eingangspost.

DPT 12.1200 wird bis Version 0.1.19 nicht unterstütz, nur sein Basistyp DPT12. Vom Konzept können alle Telegramme unabhängig vom DPT gesendet und empfangen werden. Wenn ein DPT nicht nativ unterstütz wird gibt es eine Logeintrag. In deinem Beispiel fehlt dir die Einheit als Metainformation, was keine gravierende Einschränkung sein dürfte. Alle DPTs zu unterstützen ist eine Sisyphusaufgabe und einige davon sind mir noch nicht untergekommen. Die Erstellung passiert nach und nach. Die von dir beschriebenen nehme ich ins nächste Release auf.
Dass DPT 12.1200 bei dir nicht geht ist tatsächlich ein Fehler den ich bei mir reproduzieren konnte! Der Fehler ist im nächsten Release behoben.

Bitte lass dich hier nicht durch unqualifizierte Falschaussagen von Projektunbeteiligten verwirren.

[netfriend]

@killroy2 Danke für Deine Rückmeldung!
Prima, dass Du dich der Sache annimmst und dies im nächsten Release nachziehen möchtest! Das ist nicht selbstverständlich, ich weiß den Zeitaufwand, der darin steckt (Testen, versuchen nachzustellen, analysieren, beheben, wieder testen) sehr zu schätzen! Herzlichen Dank!
Prinzipiell hast Du Recht, dass die fehlenden Einheiten nicht sehr störend sind. Allerdings ist es bei mir (und wahrscheinlich bei den meisten) so, dass ich ein funktionierendes KNX-Projekt habe. Hier habe ich versucht, alles GAs ordentlich zu benennen und alles GAs und KOs die entsprechenden DPTs zuzuweisen (auch mit Einheiten, sofern von KNX vorgesehen).
Nun importiere ich mein xml in z.B. openknx und stelle fest, dass was nicht so angezeigt wird wie erwartet. Ich könnte damit leben, dass Einheiten fehlen, wenn die Werte korrekt angezeigt werden. Das war jetzt leider bei der 12.1200 nicht der Fall, damit musste ich mein KNX-Projekt anpassen und habe diese entsprechend auf 12.001 umgestellt. Ich wollte eigentlich vermeiden, dass ich am KNX-Projekt rumspiele war aber neugierig ob es dann funktioniert. Von daher wäre es mir persönlich am liebsten, wenn nicht implementierte DPTs dahingehend funktionieren indem der Basistyp verwendet wird und beim Import der xml-Datei ein enstsprechender Hinweis angezeigt wird. Damit würde ich mein KNX-Projekt unverändert lassen und warten/hoffen, dass dies mit einem künftigen Update in openknx behoben sein könnte.

Noch eine kurze Frage zum DPT 14.076. Den nutze ich für meinen Gaszähler. Wenn ich in der ETS dort z.B. den Wert 7,4 [m³] sende, sehe ich im Gruppenmonitor auch diesen Wert. In openknx wird aber 7,40000001 [m³] angezeigt.
Ist das hier ein Rundungsfehler oder woran liegt das? Parallel dazu habe ich noch den ioBroker-KNX-Adapter installiert, dort wird richtigerweise 7,4 [m³] angezeigt. Also gehe ich davon aus, dass am Bus der richtige Wert verfügbar ist.

Danke für Deine Hilfe!

[killroy2]

@chrischros
Kannst du die Stelle vom Log zeigen an dem die Fehler beginnen? Gibt es eine Möglichkeit den Fehler nachzustellen?
Du schreibst dass sich die Fehlermeldungen häufen wenn das Ereignis eintritt.
Annahme ist, dass der Adapter in einem inkonsistenten Zustand ist, und es nicht an äusseren Ereignissen liegt. Annahme ist auch, das Problem ist erst mit einer Änderung in der 0.1.19 Version sichtbar und bestand schon davor, die Auswirkung war aber weniger sichtbar. Mehr kann ich dazu noch nicht sagen.

[ChrisChros]

@killroy2 said in Test Adapter OpenKNX 0.1.x:

Kannst du die Stelle vom Log zeigen an dem die Fehler beginnen?

Das ist der erste Log-Auszug. Das war direkt nach dem Restart des RPi über die Console.

@killroy2 said in Test Adapter OpenKNX 0.1.x:

Gibt es eine Möglichkeit den Fehler nachzustellen?

Ich werde nachher noch mal einen Reboot vom RPi machen und schauen ob es sich dann genauso verhält.

@killroy2 said in Test Adapter OpenKNX 0.1.x:

Du schreibst dass sich die Fehlermeldungen häufen wenn das Ereignis eintritt.

Ja, es werden dann fast sekündlich die gleichen Zeilen in der Log geschrieben.

@killroy2 said in Test Adapter OpenKNX 0.1.x:

Annahme ist, dass der Adapter in einem inkonsistenten Zustand ist, und es nicht an äusseren Ereignissen liegt. Annahme ist auch, das Problem ist erst mit einer Änderung in der 0.1.19 Version sichtbar und bestand schon davor, die Auswirkung war aber weniger sichtbar.

Ich denke auch das der Adapter dann irgendwie hängen bleibt. Vor 0.1.19 hatte ich zumindest keine solchen Einträge im Log. Allerdings hätte mir das auffallen müssen da der Adapter dann nicht auf grün ist. Laut der Ansicht in den Instanzen ist der Adapter mit dem Host verbunden und bekommt ein Lebenszeichen, beide haben einen grünen Harken.
Nur Verbindung mit Gerät oder Dienst besteht dann nicht.

[ChrisChros]

Habe eben noch mal einen Neustart über die Console vom RPi ausgelöst und alles ist ganz normal gestartet. Keine Ahnung was heute morgen anders war.

[killroy2]

@netfriend said in Test Adapter OpenKNX 0.1.x:

Noch eine kurze Frage zum DPT 14.076. Den nutze ich für meinen Gaszähler. Wenn ich in der ETS dort z.B. den Wert 7,4 [m³] sende, sehe ich im Gruppenmonitor auch diesen Wert. In openknx wird aber 7,40000001 [m³] angezeigt.
Ist das hier ein Rundungsfehler oder woran liegt das? Parallel dazu habe ich noch den ioBroker-KNX-Adapter installiert, dort wird richtigerweise 7,4 [m³] angezeigt. Also gehe ich davon aus, dass am Bus der richtige Wert verfügbar ist.

Auf dem Bus liegt der Wert 0x40eccccd der interpretiert werden muss.
7.4 lässt sich mit Float nicht exakt darstellen, der nächste Wert ist 7.400000095367431640625. Die ETS schneidet oder rundet vermutlich den Wert der Mantisse. Ich habe dazu aber keine Doku gefunden. In der Spec wird nur auf IEEE 754 Single Precision verwiesen.

[tombox]

@killroy2

Welche zusätzliche Informatione als

Cannot read property 'current_value' of undefined
(/opt/iobroker/node_modules/iobroker.openknx/main.js:505:64)

brauchst du noch? Dürfen Projektunbeteiligten den undefined check einbauen?

Warum ist es eine Sisyphusaufgabe, wenn die KNXUltimate Engine schon alle DPTs unterstützt. Warum fixst du Fehler und DPTs die in der Engine, auf die du Mitte 2022 wechseln, willst schon behoben sind? Du hast doch ganz klar gesagt deine Timeline ist fix.

[killroy2]

@tombox Nein, ich habe den Fehler nicht vollständig durchdrungen. Aber du wirst sicher die Güte haben uns zu erklären wie der Fix geht.

[tombox]

@killroy2

const dp = this.gaList.getDpById(id);
if (!dp) {
 this.log.warn("Ignoring " + evt + " cannot find DP for id: " + id);
//this.log.info("DP size:" + this.gaList.dp.size
// add more log to show the current state of the adapter
return
}

[killroy2]

@tombox Du hast den Fehler nicht verstanden, was du schreibst ist Mist.
Die Daten sind in einem inkonsistenten Zustand, nicht mehr vertrauenswürdig! Du schlägst ernsthaft vor ich soll den Fehler degradieren und so tun als wäre es alles gut. Später kommen dann versprengte Meldungen von sporadischen Fehlern wo keiner weiss was lost ist weil du mir das Errorreporting kurzgeschlossen hast.

Schau dir die KNX Ultimate an, wenigstens einmal genau. Du wirst erkennen dass dort längst NICHT alle DPTs unterstützt werden.

Ich mag den beleidigten und vorwurfsvollen Ton nicht den du hier anschlägst. Du hast schon massiv auf Github gestört und trollst hier weiter. Du zweifelst permanent meine Entscheidungen an und forderst von mir öffentlich Rechtfertigung, auf die du keinen Anspruch hast. In diesem Thread geht es um den Test des Adapters. Ich werde ab jetzt die Admins beten off Topic Themen konsequent zu löschen.

[tombox]

@killroy2
Danke für konstruktive Antwort ohne vorwursvollen Ton
Es geht nur darum das der Adapter nicht mehr crasht und man plausible Logs bekommt als den Adapter immer wieder crashen zu lassen. Ich denke mit guten Logs kann man immer nachvollziehen was los. Ich sehe nicht wo das Error reporting "kurzgeschlossen" ist mit einem zusätzlichen undefined check.
Aber am Ende wieder deine Entscheidung kein Check einzubauen und zu hoffen das man das Problem ohne zusätzliche Logs irgendwann findet.

Es sind nicht alle DPs zu untersützen aber 90% und doppelt soviel wie jetzt enthalten sind.
Bitte schaue dir doch die Engine genau an
https://github.com/Supergiovane/KNXUltimate/tree/main/src/dptlib
Am Ende wieder deine Entscheidung DPs selber zu pflegen anstatt die bestehende Arbeit zu nutzen, bzw. sie ab Mitte 2022 zu nutzen..

[killroy2]

in zwei deiner Zitate:
"wenn die KNXUltimate Engine schon alle DPTs unterstützt"
" Also für mich sieht die Codestelle nicht gut aus und der Fehler ist eigentlich klar weil es vorher kein check gibt"
hast du dir damit nachweislich selbt widersprochen. An anderer Stelle hast du ebenso Unwarheiten verbreitet und dir Dinge angemasst. Das sind einfach zugängliche Fakten, die kann jeder sehen und überprüfen.

Jetzt forderst du wieder mal Dinge die man machen sollte und müsste und ohne die deiner Meinung ein Makel besteht. Für aussenstehende sind das schwer zu überprüfende Behauptungen und haben hier nichts verloren. Das hier ist das falsche Forum um technische Umsetzungen zu diskutieren. Hier sprechen wir über Validierung und Verifikation des Adapters.

Durch dieses Verhalten bringst du ständig das Projekt in diskredit. Ich werde ständig genötigt auf deine Halbwahrheiten einzugehen. Das interessiert hier keinen. Mittlerweile ist ein Punkt überschritten wo ich das nicht mehr tolerieren kann.

[tombox]

@killroy2
Entschuldige wenn dich meine unpräzisen Aussagen provozieren
KNXUltimate unterstützt alle DPT außer 200-212 und 214-220
Die Codestelle für den Adapterabsturz ist klar und da ein Programm niemals unkontrolliert abstürzen sollte ist die Behebung des Problems auch klar. Entschuldige wenn ich dich mit meinem Codebeispiel auf undefined check provoziert habe.

Meiner Meinung nach sollte auch das Programm Informationen zu einem Absturz bereistellen anstatt das der Nutzer Informationen liefern soll warum das Programm abstürzt. Aber es ist deine Entscheidung wie du mit Adapterabstürzen umgehst.

Ich wußte nicht dass hier nicht der Ort für Verbesserungsvorschläg und Problembehebungen ist und nur durch den Projektbeteiligten geantwortet werden darf. Mir war nicht klar auf welche Beiträge du eingehen möchtest und welche du tolerierst.

[maxx8888]

@killroy2

Hi,

Das mit der 150% Buslast passiert im Moment immer beim Neustarten des Adapters.
Sehen kann man das im Busmonitor...
Denke da werden ja alle GAs mal gelesen, oder?
Das passiert mit Vollgas, so das der Bus bei mir mal ne Minute zu ist ...
Deshalb wollte ich fragen ob hier das Frames Delay nicht greift, aber vielleicht verstehe ich den Parameter auch falsch.

Zum 2. Problem bin ich noch selbst am suchen, bin mir noch nicht sicher ob die ganzen Reads dann irgendeine Logik im Aktor auslösen. Könnte sein das ich hier selbst den "Hund" reingebastelt habe. Wollte eigentlich nur mal fragen ob sowas ähnliches wer anders schon bemerkt hat...

[killroy2]

@maxx8888 Bei mir funtioniert das Delay, setze ich zb auf 1000 kommen die Abfragen nur sehr gemächlich.
Ich sehe bei dir viel Gelb. Woher kommt das? Setze den Wert mal auf sehr hoch und berichte dann nochmal wie es sich verhält.

[netfriend]

@killroy2 Ich habe noch etwas mit dem openKNX-Adapter gespielt. Nun ist mir aufgefallen, dass ich keine Aktoren schalten kann. Ich sehe zwar die beiden GAs für den Aktor und den Status korrekt angezeigt, wenn ich z.B. das Licht über den Schalter oder die ETS schalte. Möchte ich aber von openKNX den Aktor schalten, passiert nichts - weder am Aktor noch in der ETS.

Die beiden "Outbound ..." Einträge war der Versuch mittels openKNX das Licht zu schalten - erfolglos.
Bei den beiden "Inbound ..." Einträgen wurde das Licht mit dem Lichtschalter geschaltet.

Hier die Objekte im openKNX:

{
  "_id": "openknx.0.OG_-_Licht.34_1_-_Büro.34_1_:_Licht_Büro_EIN-AUS",
  "type": "state",
  "common": {
    "type": "boolean",
    "read": true,
    "write": true,
    "desc": "Basetype: 1-bit value",
    "name": "34.1 : Licht Büro EIN-AUS",
    "role": "switch"
  },
  "native": {
    "address": "10/5/0",
    "answer_groupValueResponse": false,
    "autoread": true,
    "bitlength": 1,
    "dpt": "DPT1.001",
    "valuetype": "basic"
  },
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  },
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1645536079995
}

Hast Du ne Idee?

[killroy2]

@netfriend said in Test Adapter OpenKNX 0.1.x:

Hast Du ne Idee?

Nein, nicht. Kannst du ein Log machen mit Wireshark?

[Tontechniker]

@killroy2 Muß da nicht bei "from": "system.adapter.openknx.0" stehen? Im Listing steht "from": "system.adapter.admin.0".

[netfriend]

@tontechniker sagte in Test Adapter OpenKNX 0.1.x:

@killroy2 Muß da nicht bei "from": "system.adapter.openknx.0" stehen? Im Listing steht "from": "system.adapter.admin.0".

Gute Frage. Ich habe die anderen Beleuchtungs-Aktoren angesehen. Bei manchen steht tatsächlich openknx, bei den anderen admin. Funktioniert aber beides nicht. Auch wenn ich diese händisch ändere, beim nächsten Öffnen steht wieder admin drin.

[netfriend]

@killroy2 sagte in Test Adapter OpenKNX 0.1.x:

@netfriend said in Test Adapter OpenKNX 0.1.x:

Hast Du ne Idee?

Nein, nicht. Kannst du ein Log machen mit Wireshark?

Hmm, mit Wireshark kenne ich mich nicht aus.