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

[chefkoch009]

Vielen Dank für eure Mühen. Tritt es nur bei "Schalten" oder auch bei "dimmen Wert" auf?

VG
chefkoch009

[schmid_no1]

@chefkoch009 kann ich bestätigen mit admin 6.
Verzögerungen geschaltet über die vis kommen bis zu 7 Sekunden später an

[Garfonso]

@chefkoch009
bei dimmen bin ich mir nicht 100% sicher, ich meine aber auch das schon gesehen zu haben. Sicher gesehen habe ich es schon bei farbtemperatur und bei rolladen position (also 0-100, müsste dann ja der gleiche Datentyp sein) (Rolladenposition ließ sich gerade reproduzieren).

[leachim200]

Hallo ich verzweifle gerade an der Iobroker-KNX verbindung.
Ich habe in der ETS mein MD Ip Interface 0003 Secure mit der physicalischen Adresse 1.1.1 ausgestattet Tunnel 1-4 liegen dann auf 1.1.2-5
Die physikalische Adresse der verbindung ist 1.0.250. Wenn ich nun 1.1.4 als physikalische Adresse eintrage bekomme ich keine Geräte verbindung zu stande.

Ich hab im Interface bereits auf Set gedrück somit sollte er die Adressen ausgerollt haben. Wo liegt mein Gedanken fehler?

logauszug:
2022-07-12 19:40:52.079 - info: knx.0 (27588) Debuglevel: 2 3
2022-07-12 19:40:52.085 - info: knx.0 (27588) Event : UDP - listening
2022-07-12 19:40:52.092 - info: knx.0 (27588) Connected - local UDP Server listening on xxxxxxxxxxxxxxx:51181
2022-07-12 19:40:52.096 - info: knx.0 (27588) Send : UDP Connection Request : 06 10 02 05 00 1a 08 01 c0 a8 58 fc c7 ed 08 01 00 00 00 00 c7 ed 04 04 02 00 sent to 192.168.88.240:3671
2022-07-12 19:40:52.104 - info: knx.0 (27588) Connection persists.....closing now
2022-07-12 19:40:52.106 - info: knx.0 (27588) ... not able to close connection, because already closed
2022-07-12 19:40:52.108 - info: knx.0 (27588) STATE_NOT_CONNECTED : Try to connect / reconnect : STATE_CONNECTION_STATE_REQUEST(5) to STATE_NOT_CONNECTED(0).
2022-07-12 19:40:54.104 - info: knx.0 (27588) STATE_CONNECTION_STATE_REQUEST : Not acceptable step... disconnecting
2022-07-12 19:40:54.114 - info: knx.0 (27588) ( END ) Sending DISCONNECT_REQUEST : 06 10 02 09 00 10 00 00 08 01 c0 a8 58 fc c7 ed ChID : 0 SeqCntIN : 0 SeqCntOUT : 0 msgCode : [object Object]
2022-07-12 19:40:54.117 - info: knx.0 (27588) STATE_DISCONNECT_REQUEST : no defined handling for transition from State: STATE_CONNECTION_STATE_REQUEST(5) to STATE_DISCONNECT_REQUEST(15).
2022-07-12 19:40:54.118 - info: knx.0 (27588) Connection persists.....closing now

[leachim200]

So ich bin weiter es dürfte an der physikalischen Adresse liegen.
Wenn ich das Interface auf werkseinstellungen setzte und die physikalische Standart IP nehme funktioniert alles. Sobald ich Secure darüber spiele geht nix mehr.
Wenn ich das ganze Ohne IP-Secure aufspiele funktioniert alles fehlerfrei.
Unterstützt der Adapter IP-Secure?

[leachim200]

@schmid_no1 Kann ich bestätigen. Ich habe direkt am Objekt Befehle abgesätzt, egal ob Tag/Nach umschaltung oder Rolläden Positionen die Befehle kommen oft bis zu 7 Sekunden später an.

[leachim200]

Hallo,
ich bin auf ein weiteres Problem gestoßen und wäre echt froh über Hilfe.
Ich versuche einen Text über iobroker an den MDT Glastaster in form eines Statustextes zu senden.

GA ist angelegt und auch im iobroker hinterlegt. Schalten und prozentwerte senden funktioniert aber der Text nicht. Was mache ich falsch?

Hier noch die Screenshots

[leachim200]

Ich bin einen Schritt weiter. Wenn ich das Ganze am Gruppenmonitor in der ETS durchführe wird der Wert ohne Probleme geschrieben. Daher gehe ich davon aus, dass es am Iobroker liegt. Logfile zeigt bei einer Wertänderung keine Regung das hier etwas gesendet wurde.

[Weissnicht]

@chefkoch009
Habe diesen Verzögerungseffekt zB auch beim Senden von Datum / Uhrzeit aus ioBroker an KNX. In Version 2.0.13 passiert das nicht.

[JojoS]

eine neue Version 2.0.16. Soll das delay da behoben sein? Habe langsam keine Lust mehr auf Betatester wenn ich schon so viel Geld für den Adapter bezahle.

[mikah111]

@jojos Ist bei mir mit der 2.0.16 nicht besser geworden. Bin und bleibe nun wohl auf der 2.0.13

[Tobi68]

@jojos ich hatte letztes Jahr immer wieder Verzögerungen.
Hatte den IOBroker sogar einmal die Woche neu gestartet, das half zu 90%
Dann musste ich den IOBroker wegen Absturz kpl. neu installieren.

Danach waren die Verzögerungen weg.
Es hatte bei mir teilweise schon mal 30sec. Gedauert bis ne Lampe über die vis geschaltet wurde. War nur bei Knx objekten so, Meross oder Tasmota hatte das Problem nicht.
Erst nach IOBroker neuinstallation und backup aufspielen was das Problem behoben.

[chefkoch009]

@tobi68 Danke für die Info. Ist eventuell bei "irgendwelchen" Updates etwas schief gelaufen?

VG
chefkoch009

[Tobi68]

@chefkoch009

Keine Ahnung, ist ja nicht mehr nachvollziehbar..
Hatte im letzten Jahr halt wegen ner anderen Sache Support bei mir auf der Kiste, der hatte sich über einige Sachen in meiner Iob Installation bei mir gewundert.
Nach dem neu Aufsetzen des IOBs waren auch die Verzögerungen im KNX Geschichte..

[Alex4]

@chefkoch009 Seit dem Update auf 2.0.17 läuft der knx.1 adapter nicht mehr, er kann keine Verbindung zum knx.1 aufnehmen. Installiere ich aber openknx und verbinde mich darüber auf die zweite IP Gateway, läuft das ohne Probleme. Davor bei 2.0.14 waren auch beide Instanzen Verbunden.

[peer69]

@chefkoch009
Ich habe ebenfalls Verzögerungen, die reproduzierbar mit 2.0.17 auftreten. Mit 2.0.13 habe ich keinerlei Verzögerungen. Wurde zwischenzeitlich etwas an der Gateway-Kommunikation geändert? Mir kommt es so vor, als würde der Adapter auf irgendetwas warten oder in einen timeout laufen, bevor der Befehl ans Gateway geht. Hab’s nicht weiter intensiv getestet, denn der 2.0.13 läuft einwandfrei.

[mpl1338]

Ich habe leider auch die Verzögerungen, nervt extrem. Des weiteren habe ich mich in einem "Adapter Neustart loop" eingefangen gehabt, Ausweg war ein Backup.

Problem ist der Direktlink gewesen, hatte Direktlink-Zustände von TUYA nach KNX gelinkt, beim neu verbinden des Tuya Adapters in der Cloud ging das Tuya Gerät verloren inkl. Objekte. KNX Adapter konnte das Objekt nicht finden und hat sich in einer Dauerschleife festgefangen. habe die KNX Instanz angehalten, jedoch erschien der GA-Tools Reiter nicht. KNX Objekt gelöscht -> ging immer noch nichts. Hier sollte eine Notfalllösung eingebaut werden. Ein blockieren bzw. Dauer neu starten des ganzen Adapters ist nicht toll.

[ahennies]

@chefkoch009 Auch auf die Gefahr in, dass ich gleich eins auf die Mütze bekomme, aber ich benötige das update auf 2.0.17, wegen des Passwort Importproblems aus der ETS 6.0.6, kann aber nicht updaten, weil mir der iobroker nur die Version 2.0.13 anbietet. Auch npm i iobroker.knx hat leider nicht zum Erfolg geführt. Der iobroker ist auf dem neuesten Stand. Welche Möglichkeiten habe ich denn noch?

Ich habe es rausgefunden. Manchmal ist es gut, wenn man noch mal eine Nacht darüber schläft

[NightRacer]

Moinsen,

ich bin komplett neu hier. Versuche grade den iobroker auf ner Syno im docker in Betrieb zu nehmen.
Aktuell bin ich soweit das ich die erste Lampe über KNX in der vis schalten kann.

Folgendes Problem: in den Instanzeinstellungen: knx.0 > GA Properties sind nach dem .knxproj import alle
"schalt"GAs nicht als "schreiben", sondern als "lesen/aktualisieren" und als "indikator" anstatt als "switch" abgebildet.
Bei "GA-Zustand - Aktuator-Beziehung" stehen die GAs unter State und nicht unter Actor GA drin.

Wenn ich das händisch korrigiere passt soweit alles.
Nur ist da ja nicht zielführend.
Ich denke in der ETS ist alles richtig konfiguriert?
Wo liegt der Fehler?!

Die Rückmeldeobjekte wurden richtig erstellt und funktionierten sofort.

beste Grüße

Michael

[Yunkie]

@peer69 said in Test Adapter KNX v2.x:

@chefkoch009
Ich habe ebenfalls Verzögerungen, die reproduzierbar mit 2.0.17 auftreten. Mit 2.0.13 habe ich keinerlei Verzögerungen. Wurde zwischenzeitlich etwas an der Gateway-Kommunikation geändert? Mir kommt es so vor, als würde der Adapter auf irgendetwas warten oder in einen timeout laufen, bevor der Befehl ans Gateway geht. Hab’s nicht weiter intensiv getestet, denn der 2.0.13 läuft einwandfrei.

Ich kann bei mir selbiges Verhalten beobachten. Habe vor ein paar Monaten mal ein Update des Adapters durchgeführt und seit dem starke und unvorhersehbare Verzögerungen gehabt. Dann habe ich gestern wie oben beschrieben ein Downgrade auf 2.0.13 gemacht und die Verzögerungen waren weg.