Test Adapter Somfy Tahoma v0.3.x GitHub
-
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.
-
@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.
Na ja, irgendetwas hat sich schon geändert. Bei meinen devices, die DeploymentState als Höhenangabe haben, passiert plötzlich folgendes: ich steuere z. B. 60% in DeploymentState an, er fährt aber auf 40% und zeigt dann auch 40% in DeploymentState an - das war vorher anders. Ich gebe 100% ein, er fährt ganz rein und zeigt dann 0% an. Kann man das wieder rückgängig machen?
Bei den devices mit ClosureState stimmt es nach wie vor überein. Mir war schon mal aufgefallen, dass Somfy offensichtlich Markiesen und Rollläden unterschiedlich behandelt. -
@integer63 sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
@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.
Na ja, irgendetwas hat sich schon geändert. Bei meinen devices, die DeploymentState als Höhenangabe haben, passiert plötzlich folgendes: ich steuere z. B. 60% in DeploymentState an, er fährt aber auf 40% und zeigt dann auch 40% in DeploymentState an - das war vorher anders. Ich gebe 100% ein, er fährt ganz rein und zeigt dann 0% an. Kann man das wieder rückgängig machen?
Bei den devices mit ClosureState stimmt es nach wie vor überein. Mir war schon mal aufgefallen, dass Somfy offensichtlich Markiesen und Rollläden unterschiedlich behandelt.
Den DeploymentState hatte ich vorher ja nicht drin. An der Behandlung hab ich eigentlich nichts geändert, aber dann muss ich da die Logik mal umkehren, ist ja kein Problem das auf 100 - Wert zu setzen. -
@StrathCole Strange, denn als ich geschrieben hatte, dass jetzt auch mit DeploymentState alles super funktioniert, war 100 noch 100 und 0 noch 0
Aber egal, Hauptsache es passt am Ende ... -
@integer63 sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
@StrathCole Strange, denn als ich geschrieben hatte, dass jetzt auch mit DeploymentState alles super funktioniert, war 100 noch 100 und 0 noch 0
Aber egal, Hauptsache es passt am Ende ...
Kein Problem. Aber du hast schon recht, ich verstehe gerade nicht, wieso das nicht funktioniert. Eigentlich müsste, wenn du 100 eingibst, sie auch auf 100 rausfahren.Edit: Gerade noch mal geschaut, habe am Deployment-Code nichts geändert an der Funktionsweise
Änderst du den Wert direkt in der Objektansicht? -
@StrathCole Nun, ich steuere den Datenpunkt über ein Widget in VIS an. So sieht es aus, wenn ich 100 wähle und er fertig ist:
Bis dahin steht 100 drin. -
Ich könnte das ja alles entsprechend anpassen, wenn 100 als Eingabe auch 100 als Ergebnis hat, aber wenn aus 100 dann am Ende 0 wird, dann wird es mystisch.
-
@integer63 sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
Ich könnte das ja alles entsprechend anpassen, wenn 100 als Eingabe auch 100 als Ergebnis hat, aber wenn aus 100 dann am Ende 0 wird, dann wird es mystisch.
Könntest du mal bitte zum Testen den Wert direkt in das Feld bei core:DeploymentState eingeben und Enter drücken? Also nicht via Vis Widget. Closed = 0 ist ja korrekt für Deployment (deploy -> ausfahren).
-
@StrathCole Hatte ich schon probiert, ist genau das gleiche. Wenn ich unter command deploy auslöse, fährt sie ganz raus und in DeploymentState steht zwischendurch mal ein Zwischenwert und dann am Ende 100. Wenn ich dann 0 eingebe, passiert gar nichts und die 0 bleibt drin stehen. Wenn ich dann 100 eingebe, fährt er wieder rein und am Ende steht 0 drin
-
@integer63 sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
@StrathCole Hatte ich schon probiert, ist genau das gleiche. Wenn ich unter command deploy auslöse, fährt sie ganz raus und in DeploymentState steht zwischendurch mal ein Zwischenwert und dann am Ende 100. Wenn ich dann 0 eingebe, passiert gar nichts und die 0 bleibt drin stehen. Wenn ich dann 100 eingebe, fährt er wieder rein und am Ende steht 0 drin
Wirklich erstaunliches Verhalten
Ich schaue mir das noch mal an. Habe leider selbst keine Geräte mit DeploymentState. -
@StrathCole Um die Verwirrung noch etwas zu erhöhen, im ham/tahoma Adapter werden die States umgekehrt (aber eigentlich einleuchtend) angewendet:
- bei senkrechten Screens/Rollläden - Behanghöhe: 100% ganz oben, 0% ganz unten
- bei waagerechten Markisen - Ausfahrweite: 0% eingefahren, 100% ganz ausgefahren
Aber wenn das so von Somfy angewendet wird, warum funktionieren dann die ClosureStates richtg? Es wird immer verwirrender ...
-
@StrathCole Hier noch zwei Screenshots der Datenpunkte im ham Adapter:
Markise ganz reingefahren:
Screen ganz hochgefahren:
-
@integer63 sagte in Test Adapter Somfy Tahoma v0.1.x GitHub:
Aber wenn das so von Somfy angewendet wird, warum funktionieren dann die ClosureStates richtg? Es wird immer verwirrender ...
Ich denke, es liegt daran, dass die Logik eine andere ist. ClosureState gibt ja den Zustand des Schließens an, also 100% = ganz geschlossen. DeploymentState gibt den Zustand des Öffnens, bzw. Rausfahrens an, also 100% = ganz "geöffnet". Ich vermute, dass Somfy beim Deployment dann intern die Logik umkehrt, ich sie also wieder umkehren muss beim Senden der Änderung. Das schau ich mir aber gerade an.
-
@integer63 Kannst du mit dem aktuellen Git noch einmal probieren?
-
@StrathCole Leider keine Veränderung, 20 eingeben, er fährt aber auf 80 und zeigt dann auch 80 an. Woran sehe ich, ob ich auch wirklich die neue Version verwende?
-
@StrathCole kannst du mir denn noch mal diese Version zur Verfügung stellen:
Denn damit bin ich mir sicher, hat es funktioniert. Und wenn Somfy jetzt nicht plötzlich andere Werte zurück liefert, müsste es ja damit dann ja wieder gehen - nur zum testen.
