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

[Markus84]

@Garfonso Killroy2 hatte oben darauf hingewiesen, dass es wohl nur mit einem MDT Interface passiert. Hast du vielleicht kein MDT Interface? Ist das vielleicht der 2. Faktor der hinzutreten muss?

[lessthanmore]

Hallo zusammen,
ich habe zur Zeit Probleme mit dimmbaren Spots bzw. mit der Anzeige im Adapter.
Beim Helligkeitswert (%) wird bspw. beim Esszimmer korrekt die Prozentzahl zurückgegeben bzw. angezeigt. Bei der Küchen zum Beispiel bekomme ich lediglich den Wert "false %" bzw. "true %".

Weiß jemand zufällig woran das liegen kann?
In der ETS ist beides identisch konfiguriert.

Lieben Dank vorab

[Garfonso]

@markus84
Ja, das wird es dann wohl sein... hm...

[Garfonso]

@lessthanmore
Guck mal bei "Küche", ob da StatusGA und ActGA falsch verknüpft sind.

[lessthanmore]

@garfonso Jap, genauso war es. Er hat die Status GA teilweise falsch gesetzt. Hab es korrigiert und nach einem Neustart vom Adapter geht es nun
Jetzt ist nur noch der Punkt offen, warum ich in lovelace keinerlei custom cards anlegen oder verwenden kann. Aber das schreibe ich dir im anderen Thread

[killroy2]

@markus84 said in Test Adapter KNX v1.0.x:

Kannst du mir ein anderes empfehlen?

Ich besitze noch ein älteres Weinzierl 731, damit tritt das Problem nicht auf.
Das Problem habe ich nur mit meinem neuen MDT IP Interface SCN-IP000.03

[killroy2]

Ich habe mein Problem weiter analysiert:
Wenn ein Paket kein Acknowledge bekommt, zB weil es mit keinem Gerät verknüpft ist steigt mein MDT IP Interface aus, schickt einen DISCONNECT_REQUEST und ist für gewisse Zeit tot auf dem Bus so dass wichtige Informationen verloren gehen.

192.168.0.103 PC mit ETS, 192.168.0.10 KNX IP Interface, 192.168.0.8 IOBroker

Die ETS verhält sich korrekt, kein Disconnect, Message wird grün (problematisch) angezeigt:
Der CEMI l_data.con frame mit confirmation error vom Interface wird von der ETS Acknowledged

Der IOBroker Adapter quittiert Paket #10:47 nicht, es wird deswegen ein zweites mal geschickt. Und da es erneut nicht quittiert wird geht das Interface in DISCONNECT_REQUEST.

An der Stelle sieht das Log so aus, den Fehler sieht man nicht:

2021-06-26 03:47:12.892  - info: knx.0 (1581) ( 3.6b ) Received L_DATA.con  06 10 04 20 00 16 04 10 2b 00 2e 00 9c e0 11 fe 01 1c 02 00 80 00  was NOT processed by receiver !!
2021-06-26 03:47:13.892  - info: knx.0 (1581) Received DISCONNECT_REQUEST: 06 10 02 09 00 10 10 00 08 01 c0 a8 00 0a 0e 57  - ChannelID  16 SeqCntIN : 43 SeqCntOUT : 215 for 192.168.0.10:1487

Mein zweites KNX IP Interface hat keine Probleme weil es auch ohne Confirmation ein L_Data.ind schickt welches vom IOBroker quittiert wird.

Frage ist: Was fordert die Spec und kann ein ACK in den Adapter eingebaut werden?

06 10 04 20 00 15 04 01 63 00 29 00 bc e0 11 fe 02 0c 01 00 80 ChID: 1 L_Data.ind -> ok
06 10 04 20 00 16 04 10 2b 00 2e 00 9c e0 11 fe 01 1c 02 00 80 00 L_Data.con -> bad, nack

[Garfonso]

@killroy2
Das ist mal eine gute Analyse -> kannst du die bitte in ein issue packen (zu dem Problem gibt es schon eins, oder?) damit die nicht untergeht? Ich denke damit müsste man das Problem angehen können (hab leider für KNX immer noch kein ganz funktionierendes entwicklungssetup, muss ich mich nochmal dran setzen).

[Tobi68]

@garfonso

Ich wollte jetzt nach ner Zeit mal Rückmeldung geben.
Nach dem Neustart des RPIs habe ich keinerlei Probleme mehr, teste jeden Tag ein zwei mal ob die Buttons aus der Vis beim KNX rummzicken, nichts, keine Probleme.
Werde jetzt mal den Täglichen Neustart des Adapters wieder deaktivieren und weiter beobachten.
Evtl. ist aber auch ein Update der Vis aus den letzten Wochen hilfreich gewesen..
Gruss
Tobi

[killroy2]

@garfonso hast du einen Link wo? Ich habe noch keinen erstellt.

[killroy2]

Hallo, momentan funktioniert bei mir KNX nicht, wenn ich die Lizenz prüfe kommt:

" Service ist momentan nicht erreichbar oder keine Internetverbindung vorhanden. Bitte versuchen Sie später noch ein mal oder prüfen Sie die Internetverbindung."

[klee]

@killroy2

DAs gleiche Problem habe ich auch.
Hat dein Adapter den Status gelb oder grün dabei?

Ich habe da gerade nämlich auch einen Thread aufgemacht:
https://forum.iobroker.net/topic/46126/knx-adapter-status-gelb

[Garfonso]

@killroy2
Hier ist der Link: https://github.com/ioBroker/ioBroker.knx/issues
Am besten kurz gucken, ob eins passt. Ich meine sowas gab es da schon. Danke.

[killroy2]

War auch gelb. Seit heute morgen geht die Lizenz wieder. Aber ist es tatsächlich so dass meine Heimautomatisierung von einem Dienst im Web abhängt? Das ist beängstigend.

[TheBam]

@killroy2
Nur die licenz Abfrage. Diese wird bei jedem Neustart des Adapters abgefragt. Wenn der Adapter also durchläuft dann wird auch keine Abfrage gemacht. Alternativ kannst du dir auch die licenz kaufen. Dann wird nur einmal abgefragt und danach nie wieder

[killroy2]

@garfonso ist nur etwas wenig los auf Github, mein Problem scheinen andere auch zu haben und das seit einiger Zeit. Wird an dem Adapter überhaupt noch aktiv gearbeitet?

[tombox]

@killroy2 Der Adapter ist leider nicht open source, somit kann nicht jeder daran arbeiten der will.

[Garfonso]

@killroy2
perspektivisch: Ja.
chefkoch macht aktuell wenig. Bluefox fixt nur die bösesten Bugs (eher so organisatorisches, wenn sich im ioBroker was ändert).
Ich hab es bisher noch nicht geschafft mich tiefer einzuarbeiten, weil auch immer wieder andere Adapter dazwischen kommen (und KNX aktuell auch leidlich für mich funktioniert).

Trotzdem ist Github für "echte Bugs" der richtige Ort, da kann ich (oder jemand anders) dann nachgucken, wenn er/sie sich dran setzt und an dem Adapter entwickeln kann.

[killroy2]

@garfonso das scheint aber ein echtes organisatorisches Problem zu sein. Keiner hat Zugriff auf den Code und die wenigen die haben können nicht.
Mein Problem geht zurück auf Meldungen aus März 2020 und Github ist voll mit ähnlichen Meldungen. Das Problem ist schwerwiegend und häufig.
Also seit 1,5 Jahren ist das Problem bekannt, der Fehler lässt sich nachstellen und ist imo einfach behebbar.

[loverz]

Hallo zusammen,

ich habe das Problem, dass bei mir alle Versionen, welche neuer sind als 1.0.20 nicht richtig funktionieren.

Konkret sind es folgende Probleme, welche teilweise auch schon bekannt sind:
-Sporadische Fehlermeldung "State not connected" in Verbindung mit dem MDT IP Gateway
-Häufiges bis dauerhaftes "nicht registrieren" von Statusänderungen. Z.B. Werden die Positionen von meinen Rollläden nach Fahrtende nicht aktualisiert.

Wie gesagt: Mit Version 1.0.20 funktioniert alles tadellos. Irgendwas muss da geändert worden sein...

Nun habe ich zusätzlich das Problem, dass der neue ioBroker Admin mir aufgrund der alten Version die Logs vollschreibt:

knx.0
2021-09-01 21:59:53.222	info	State value to set for "knx.0.OG.Präsenz.Präsenz_OG_Nord" has to be type "boolean" but received type "number"

knx.0
2021-09-01 21:57:54.287	info	State value to set for "knx.0.OG.Präsenz.Präsenz_OG_Süd" has to be type "boolean" but received type "number"

knx.0
2021-09-01 21:57:43.726	info	State value to set for "knx.0.EG.Magnetkontakte.Wohnzimmer_Nord" has to be type "boolean" but received type "number"

knx.0
2021-09-01 21:57:36.982	info	State value to set for "knx.0.Dachgeschoss.Magnetkontakte.Fenster" has to be type "boolean" but received type "number"

knx.0
2021-09-01 21:56:39.594	info	State value to set for "knx.0.EG.Magnetkontakte.Küche_West-Süd" has to be type "boolean" but received type "number"

knx.0
2021-09-01 21:56:15.983	warn	Object of state "knx.0.Zentral.Zeit.Datum_Zeit" is missing the required property "common.type"

knx.0
2021-09-01 21:56:15.789	warn	Object of state "knx.0.Zentral.Zeit.Datum" is missing the required property "common.type"

knx.0
2021-09-01 21:56:15.583	warn	Object of state "knx.0.Zentral.Zeit.Uhrzeit" is missing the required property "common.type"

Wie soll ich hier vorgehen??