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

[chefkoch009]

@jojos Auf meinem Dev-System und Produktionssystem habe ich den 5er Admin laufen.

Wenn das der einzige Unterschied ist, dann möchte ich einmal in die Runde fragen, ob jemand das bestätigen kann, oder so etwas beobachtet hat.

Hast Du dieses Verhalten auch, wenn Du direkt über den Objektbaum schaltest oder nur über die Visu?

VG
chefkoch009

[JojoS]

@chefkoch009 Verzögerungen gab es auch bei Logik über Node Red. Beim Schalten über den Objektbaum gibt es die Verzögerung auch.
Den Admin habe ich bis 5.4.8 zurück installiert, die Verzögerung tritt trotzdem nur bei KNX 2.0.15 auf. Reproduzierbar, mehrmals verschiedene Versionen installiert.
Garfonso hat das doch auch beobachtet?

jojo@iobroker-prod:~$ iob info
Platform       : linux
os             : linux
Architecture   : x64
CPUs           : 1
Speed          : 2600 MHz
Model          : Intel(R) Core(TM) i3-10110U CPU @ 2.10GHz
RAM            : 4 GB
System uptime  : 17d. 23:07:09
Node.js        : v14.19.3
time           : 1655378041359
timeOffset     : -120
adapters count : 501
NPM            : v6.14.17
Disk size      : 15.6 GiB
Disk free      : 7.3 GiB
jojo@iobroker-prod:~$ iobroker v
4.0.23

[Garfonso]

@jojos
ja, hab das mit Admin 5.x und auch Admin 6 beobachtet. Schalten per Javascript, Visu (Lovelace) oder Objektbaum macht keinen Unterschied, kann alles verzögert sein.

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