Test Adapter Somfy Tahoma v0.3.x GitHub
-
Übrigens hat Somfy für den 21.1. ein großes Tahoma-Update angekündigt inkl. Updates am Server. Ich hoffe, danach funktioniert alles wie gewohnt, allerdings wird der Adapter wohl in der Zeit von ca. 10 - 12 Uhr keinen Zugriff auf den Server haben. Also nicht wundern, falls nix gehen sollte
-
@StrathCole sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
@blackeagle998 sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
Wenn ich den "commands" einen true / false Wert zuweise, bekomme ich folgende Meldung im LOG:
Ich werd die Typen auf boolean ändern. 0 und 1 ergibt für mich bei Commands nicht viel Sinn.
@blackeagle998 sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
Bisher war mein Problem immer, dass ich nur Befehle für 9 Rollläden auf einmal senden konnte und danach einen Timeout einbauen musste, um die restlichen zu steuern.
Ich habe jetzt einen eigenen "retry" eingebaut, wenn der Fehler 400 kommt. Müsste im Git schon online sein, ich mache aber gleich noch weitere Updates, also am besten etwas warten.
Ich habe gerade auf Version 0.2.0 aktualisiert:
-
die Warnmeldungen bezüglich 0/false und 1/true kommen noch (nur als Hinweis, weiß nicht ob du das schon gefixt hattest)
-
mehr als 9 Rollläden lassen sich nicht gleichzeitig steuern, dann kommt der 400er Fehler mit Payload.
--> Hast du den automatischen Retry jetzt schon eingebaut? Wenn ja mit welchem Zeitintervall?
Das soll nicht ungeduldig klingen, wusste jetzt nur nicht genau, was schon in Version 0.2.0 drin sein sollte.
-
-
@blackeagle998 Kein Problem
Klingt nicht ungeduldig.Also, den Typ auf boolean habe ich geändert. Kann aber sein, dass du die Objekte einmal löschen müsstest, bevor das funktioniert. Ich glaube, da gibt es kein Update, sondern nur beim Anlegen die boolean Types.
Der Retry kommt eigentlich automatisch nach 5 Sekunden. Hat das bei dir nicht geklappt?
-
Oh, ich sehe gerade, die 5 Sekunden scheinen nicht zu reichen. Bei mir hatte ich das Problem auch gerade. Ich überlege mir noch eine Lösung.
-
@StrathCole sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
Oh, ich sehe gerade, die 5 Sekunden scheinen nicht zu reichen. Bei mir hatte ich das Problem auch gerade. Ich überlege mir noch eine Lösung.
Genau, ich hatte im Skript auf 15 Sekunden gestellt, das ging immer. Wo da genau die Grenze ist, weiß ich auch nicht.
-
@blackeagle998 sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
@StrathCole sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
Oh, ich sehe gerade, die 5 Sekunden scheinen nicht zu reichen. Bei mir hatte ich das Problem auch gerade. Ich überlege mir noch eine Lösung.
Genau, ich hatte im Skript auf 15 Sekunden gestellt, das ging immer. Wo da genau die Grenze ist, weiß ich auch nicht.
Ich habe gerade noch ne ganz andere Idee. Muss ich aber erst testen.
-
@StrathCole sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
@blackeagle998 Kein Problem
Klingt nicht ungeduldig.Also, den Typ auf boolean habe ich geändert. Kann aber sein, dass du die Objekte einmal löschen müsstest, bevor das funktioniert. Ich glaube, da gibt es kein Update, sondern nur beim Anlegen die boolean Types.
Der Retry kommt eigentlich automatisch nach 5 Sekunden. Hat das bei dir nicht geklappt?
Die Typ-Änderung hat funktioniert, nachdem ich die States alle gelöscht hatte und diese neu geschrieben wurden.
Was jetzt irgendwie nicht mehr angelegt wird, ist der "moving" state.
Habe gerade einen Rollladen runter und hoch fahren lassen, aber es ist kein "moving" state da
-
@blackeagle998 sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
Was jetzt irgendwie nicht mehr angelegt wird, ist der "moving" state.
Habe gerade einen Rollladen runter und hoch fahren lassen, aber es ist kein "moving" state daDer State ist nur verfügbar, wenn der Befehl auch via ioBroker gegeben wurde. Wenn man manuell einen Schalter oder so drückt, bekommt Tahoma die Info nicht.
-
@StrathCole Hm, bei mir erscheint moving jetzt hier:
Und dafür nicht mehr unter den devices. -
@integer63 sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
@StrathCole Hm, bei mir erscheint moving jetzt hier:
Und dafür nicht mehr unter den devices.Jap exakt so ist es auch bei mir.
-
Und es (moving) war in einer vorherigen Version ja schon mal richtig. Aber dafür, dass ich jetzt endlich alles problemlos steuern kann, spiele ich sehr gerne den Beta-Tester
-
@integer63 sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
Und es (moving) war in einer vorherigen Version ja schon mal richtig. Aber dafür, dass ich jetzt endlich alles problemlos steuern kann, spiele ich sehr gerne den Beta-Tester
Ach testen macht ja auch irgendwie Spaß und wenn man dann quasi sofort Support bekommt, ist das schon was feines
-
Äh bin gerade etwas verwirrt.
Als ich alles eingerichtet habe, musste ich im iQontrol (Visualisierung) angeben, dass das Level invertiert werden soll, also 0% = offen, das lief auch super.
Jetzt sind die Rollläden geschlossen und der Level State steht bei 0%
Hat sich das von Version 0.1.0 zu 0.2.0 geändert? -
@blackeagle998 sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
Äh bin gerade etwas verwirrt.
Als ich alles eingerichtet habe, musste ich im iQontrol (Visualisierung) angeben, dass das Level invertiert werden soll, also 0% = offen, das lief auch super.
Jetzt sind die Rollläden geschlossen und der Level State steht bei 0%
Hat sich das von Version 0.1.0 zu 0.2.0 geändert?Bitte den obigen Text vergessen, keine Ahnung wo ich hingeschaut habe, aber bei geschlossen ist das Level bei 100%, so wie es vorher auch war.
-
Der Adapter schmeißt seit einigen Minuten folgende Warnmeldungen:
tahoma.0 2020-01-17 18:07:08.145 warn (4327) refresh device state failed tahoma.0 2020-01-17 18:07:08.144 warn (4327) error during tahomalink request: 503: null, request path: /setup/devices/states/refresh with payload:{}Was steckt dahinter?
-
So, es hat eine Weile gedauert. Musste einiges umstellen.
Es sollte nun funktionieren, dass man Befehle gleichzeitig an mehr als 9 Rollläden sendet. Ich habe eine Befehlskette eingeführt, das heißt, wenn innerhalb von 500ms ein weiterer Befehl eingeht, wird der vorherige Befehl noch nicht an Tahoma gesendet, sondern mit dem neuen Befehl zusammengeführt. Sobald 500ms lang keine neuen Befehle kommen, sendet er alles an Tahoma.
Dadurch umgehe ich das Problem, dass Tahoma zu viele Anfragen hintereinander erhält. Zumindest ist nach der Umstellung das Problem bei mir nicht mehr aufgetreten.Außerdem prüfe ich in dieser Kette nun auch, ob ein Device mehrfach angefragt wurde. Das führt nämlich ebenfalls zu einem Fehler. Dazu kommt es beispielsweise, wenn man zweimal dasselbe Gerät in den Objekten hat, mit derselben DeviceURL aber unterschiedlichen Namen. Bei mir ist das passiert, als das Problem mit den Leerzeichen zu _ behoben wurde.
Das moving Objekt ist bei mir auch (wieder oder immer noch) an der richtigen Stelle vorhanden.
-
@blackeagle998 sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
Der Adapter schmeißt seit einigen Minuten folgende Warnmeldungen:
tahoma.0 2020-01-17 18:07:08.145 warn (4327) refresh device state failed tahoma.0 2020-01-17 18:07:08.144 warn (4327) error during tahomalink request: 503: null, request path: /setup/devices/states/refresh with payload:{}Was steckt dahinter?
503 heißt: Tahoma Server überlastet oder nicht erreichbar.
-
@blackeagle998 sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
@blackeagle998 sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
Äh bin gerade etwas verwirrt.
Als ich alles eingerichtet habe, musste ich im iQontrol (Visualisierung) angeben, dass das Level invertiert werden soll, also 0% = offen, das lief auch super.
Jetzt sind die Rollläden geschlossen und der Level State steht bei 0%
Hat sich das von Version 0.1.0 zu 0.2.0 geändert?Bitte den obigen Text vergessen, keine Ahnung wo ich hingeschaut habe, aber bei geschlossen ist das Level bei 100%, so wie es vorher auch war.
Der Wert springt erst bei dem nächsten Polling (Statusanfrage bei Tahoma) auf den aktuellen Wert. Vorher steht da der vom Skript oder manuell eingetragene Wert drin (mit ack = false).
-
Update auf 0.2.1 gemacht, der Adapter wirft folgende Fehler:
tahoma.0 2020-01-17 18:26:03.532 error at Object.onceWrapper (events.js:286:20) tahoma.0 2020-01-17 18:26:03.532 error at IncomingMessage.<anonymous> (/opt/iobroker/node_modules/request/request.js:1083:12) tahoma.0 2020-01-17 18:26:03.532 error at Request.emit (events.js:198:13) tahoma.0 2020-01-17 18:26:03.532 error at Request.<anonymous> (/opt/iobroker/node_modules/request/request.js:1161:10) tahoma.0 2020-01-17 18:26:03.532 error at Request.emit (events.js:198:13) tahoma.0 2020-01-17 18:26:03.532 error at Request.self.callback (/opt/iobroker/node_modules/request/request.js:185:22) tahoma.0 2020-01-17 18:26:03.532 error at Request._callback (/opt/iobroker/node_modules/iobroker.tahoma/lib/tahoma.js:174:5) tahoma.0 2020-01-17 18:26:03.532 error at /opt/iobroker/node_modules/iobroker.tahoma/lib/tahoma.js:581:20 tahoma.0 2020-01-17 18:26:03.532 error at Tahoma.updateDeviceStateFromEvent (/opt/iobroker/node_modules/iobroker.tahoma/lib/tahoma.js:594:18) tahoma.0 2020-01-17 18:26:03.532 error at Tahoma.updateDeviceState (/opt/iobroker/node_modules/iobroker.tahoma/lib/tahoma.js:793:17) tahoma.0 2020-01-17 18:26:03.532 error (30688) TypeError: Cannot read property 'indexOf' of undefined tahoma.0 2020-01-17 18:26:03.531 error (30688) uncaught exception: Cannot read property 'indexOf' of undefined -
@blackeagle998 Sorry, da scheint er bei dir ein Device nicht zu finden. Habe die Logmeldung mal erweitert und den Fehler abgefangen.
