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

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

[netfriend]

@killroy2, @Tontechniker : Bei euch funktionieren die Beleuchtungsaktoren ohne Probleme?
Ich hätte jetzt erwartet, dass der DPT 1.001 das Allereinfachste ist, irgendwie komisch.

[killroy2]

@chrischros said in Test Adapter OpenKNX 0.1.x:

Hast du mehrere Adapterinstanzen laufen? Was für ein KNX Gateway besitzt du?
Für mich sieht es so aus dass das Gateway ein recvTunnReqIndication schickt, noch bevor ein connect
erfolgt ist und davon einen event auslöst. Meine Logik vertraut aber auf diese Sequenz. Und ich seh auch nicht dass der connect nachgeholt wird. Die Library ist in einem inkonsistenten Zustand.

Ich kann es jetzt sogar nachstellen wenn ich 2 Adapterinstanzen laufen lasse. Ich teste einen Workaround oder Patche die Lib. Kommt dann in 0.1.21

[killroy2]

@netfriend Ich hab dich so verstanden dass bei dir garnichts ausgangsseitig geht. Wenn da outbound kommt, dann ist im IOB eigentlich alles io. Du kannst noch ein silly Log machen um zu sehen ob noch mehr kommt.

[netfriend]

@killroy2 Ich hab noch etwas probiert.
Also es ist wohl so:
Ich habe ein IP-Interface Weinzierl 732 secure (das secure-Feature ist aktuell deaktiviert). Dieses ermöglicht bis zu 8 Verbindungen gleichzeitig, über LEDs sieht man am Gerät welche Verbindungen belegt sind. Das passt alles soweit.
Verwende ich dieses Gateway mit dem KNX-Adapter, funktioniert auch das Licht schalten.
Mit dem openKNX-Adapter funktioniert das Schalten nicht. Im silly-Log sehe ich folgendes:

Allerdings sehe ich in der ETS -entgegen dem was ich vorhin geschrieben habe- tatsächlich das passende Telegramm:

Trotzdem schaltet der Aktor nicht wie gewünscht.

Nun habe ich noch ein altes (Reserve) Gateway Weinzierl 730. Nun habe ich dieses nochmal angeschlossen, kurz die IP im Adapter geändert und siehe da, der Aktor schaltet. Das Log zeigt folgendes:

Ich verstehe gerade nicht, was das mit der Hardware zu tun haben soll. Viel konfigurieren kann man da nicht. Mehrere Hundert GAs werden auch korrekt dargestellt (Zustände, Messwerte).

[ChrisChros]

@killroy2 said in Test Adapter OpenKNX 0.1.x:

Hast du mehrere Adapterinstanzen laufen? Was für ein KNX Gateway besitzt du?

Deinen openKNX-Adapter habe ich nur einmal laufen. Als KNX Gateway nutze ich das Enertex KNX IP Secure Interface.
Mit diesem kann habe ich die Möglichkeit 8 Tunnel anzulegen wovon ich 3 nutze. Den erste Tunnel nutze ich für die ETS, den zweiten für Edomi (Hausautomation) und den dritten für den openKNX-Adapter.

[killroy2]

@netfriend Wenn die Daten korrekt in der ETS ankommen dann kann es schon nicht am Adapter liegen. Mach mal einen Diff was in der ETS angezeigt wird. Im trace schickst du verschiedene Werte, nicht dass es daran liegt.

[netfriend]

@killroy2 Ich bin mir noch nicht sicher, ob die Daten korrekt ankommen. Im ersten Moment sah es so aus, jedenfalls im Gruppenmonitor.
Nun habe ich es nochmal probiert und mir auch in den Eigenschaften die Raw-Data angesehen. Diese sind tatsächlich unterschiedlich:

Weinzierl 732 secure:

Weinzierl 730:

Das würde ja mit mit den unterschiedlichen Daten im trace zusammenpassen. Nun stellt sich mir die Frage, warum schickt der openKNX-Adapter bei der gleichen Aktion (Aktor-Element Schieber auf "true" und bestätigen) unterschiedliche Telegramme, wenn man zwischendurch lediglich die IP des Gateways ändert und denn Adapter wieder startet? Ich versteh's nicht....