@guergen said in [Neuer Adapter] LinkedDevices:
Zur Not kanst Du das mit einem Blockly-Script und eigenen Datenpunkten realisieren
Danke, genau so habe ich es jetzt gemacht (war auch ein Tipp aus dem Script Bereich).
@guergen said in [Neuer Adapter] LinkedDevices:
Zur Not kanst Du das mit einem Blockly-Script und eigenen Datenpunkten realisieren
Danke, genau so habe ich es jetzt gemacht (war auch ein Tipp aus dem Script Bereich).
Hab noch ein wenig „ausprobiert“.
Dabei hab ich festgestellt, dass das Problem nur mit der 1.3.2 Version vorkommt.
Mit Downgrade auf 1.3.1 (und auch kleiner - bis 1.2 getestet) funktioniert das ganze.
@mischroe Per Fhem wurde auch Level 3 gesetzt. Habe die Steuerung neugestartet, danach war der Fehler weiterhin da. Nach ein paar mal auf/zu ist der Fehler jetzt aber weg, puhh, juhu :-).
Zusammenfassend läuft jetzt eigentlich alles, bis auf die Rückmeldung vom Status, dass das Tor nur auf Fußgängermodus offen ist. Ich werde hier bzgl. den Log Daten noch mal schauen.
Ich hatte irgendwie das Gefühl, das es an meiner ioBroker Maschine liegt. Ich habe daher dieses aus einem Backup restored und siehe da, nur der eine Flügel fährt nun mit 55303 auf und verweilt dort dann auch. Grundsätzlich funktioniert nun das gewünscht. (Was auch immer da vorher quer lief...)
Jetzt habe ich nur noch zwei kleine Probleme.
Sende ich 55303 per targetPositionRaw fährt das Tor wie gesagt auf die richtige Position. Danach bleibt aber als Wert bei currentPositionRaw = 63487 (also "kein Wert zurückgemeldet"). Daher weiß ich so nicht, steht das Tor im "Fußgängermodus" oder liegt ein Fehler am Tor vor.
Bei ganz auf/zu wird am Ende ja auch 0 bzw. 51200 zurückgemeldet.
Bekommt man das noch hin, das also nach einer 55303 Fahrt, am Ende als aktuelle Position 55303 gemeldet wird?
Bedarf es dafür die von dir gewünschten Logs, oder helfen die hier nicht für?
Zweites Problem; Wenn ich mich jetzt per TahomaBox/App auf das Tor schalte, steht dort nun, das der Motor im "manuellen Modus" ist und nur vor Ort gesteuert werden kann. Das muss man dann immer erst bestätigen und dann kann man das ganze steuern. Gleiches gilt auch für die Alexa Anbindung vom Tor - diese lässt eine Steuerung jetzt auch nicht mehr zu.
Das muss irgendwie durch die ganzen Tests passiert sein. Hast du eine Idee, wie ich diese Warnung/Modus wieder weg bekomme?
Nebenfrage, gibt es bei dem Adapter die Funktion "priorityLevel"? Könnte es was damit zu tun haben? (das gab es bei Fhem, daher komme ich darauf)
Ich habe jetzt noch weiter getestet und dabei den Adapter noch mal neu installiert.
Nun passiert was, wenn ich bei targetPositionRaw = 55303 eingebe - nur der eine Flügel fährt auf, juhu.
ABER, nachdem er aufgefahren ist, fährt er direkt ca. 30% wieder zurück/zu (geschätzt).
Im Feld targetPositionRaw fällt auf, dass der Wert hin und her springt. Ich gebe 55303 ein, danach springt es automatisch auf 63487, 51200, 63487, 51200 und dann zu letzt auf 63487.
51200 ist ja „zu“, das erklärt ja vielleicht warum das Tor wieder Richtung zu fährt und dann noch mal 51200 stopp es vielleicht?!
Die Frage ist, woher das kommt?
Bei der Fernbedienung fährt der Flügel nur auf (der eine Flügel) und bleibt dann auf der Position.
Nachtrag: Wenn der Flügel dann nach der 30%igen Rückfahrt stehengeblieben ist und man dann noch mal 55303 sendet, dann fährt der Flügel wieder ganz auf und bleibt dort auch stehen, ohne erneute Rückfahrt.
Vielleicht hilft das noch - ich hatte das ganze mal vor Jahren mit fhem und dem klf200 am laufen, da funkionierte es, nur ein Flügel zu öffnen. Ich habe dazu noch Infos gefunden, wie man damals den Weg zur Funktion gefunden hat.
Diese Daten hatte ich ausgelesen
Fußgänger offen (ein Flügel auf)
2022-03-06_08:03:59 Velux_9 updateCurrentPosition
2022-03-06_08:03:59 Velux_9 sessionID: 361
2022-03-06_08:03:59 Velux_9 MP: 55303
2022-03-06_08:03:59 Velux_9 FP8: 55303
2022-03-06_08:03:59 Velux_9 FP16: 55303
2022-03-06_08:03:59 Velux_9 MP: 63487
Beide Flügel auf
2022-03-06_08:09:52 Velux_9 updateCurrentPosition
2022-03-06_08:09:52 Velux_9 sessionID: 377
2022-03-06_08:09:52 Velux_9 FP8: 0
2022-03-06_08:09:52 Velux_9 FP16: 0
Tor (beide) zu
2022-03-06_08:12:32 Velux_9 updateCurrentPosition
2022-03-06_08:12:33 Velux_9 sessionID: 385
2022-03-06_08:12:33 Velux_9 FP8: 51200
2022-03-06_08:12:33 Velux_9 FP16: 51200
Und daraus ergab sich dann folgender Befehl, womit nur der eine Flügel auf ging:
set Velux_9 raw MP=55303
Wenn ich jetzt aber unter "targetPositionRaw" -> "55303" eingebe, passiert nichts - springt dann erst auf 63487 und dann auf 51200.
Wenn ich refreshProduct klicke (egal bei welchen Produkt), bekomme ich im Log -> Couldn't set state klf200.0.products.9.refreshProduct to value true: Timeout error
So komm ich aktuell leider wohl nicht an den Wert.
Hier das Log - es geht um Produkt 9, vielleicht sieht man hier mehr?
Hallo, ich hätte da jetzt noch ein kleines Problem/Wunsch.
Ich habe ein Hoftor (Category Gate opener) von Somfy an das KLF-200 verbunden, per iO.
Öffnen und schließen funktioniert wunderbar; auch der Status wird wunderbar ausgegeben.
Mir fehlt jetzt nur die Funktion, nur einen Flügel von dem Doppelflügeltor zu öffnen.
Unter targetPositionRaw bzw. currentPositionRaw gibt es folgende Werte, welche auch als Status unter Objekte angezeigt werden, wenn ich das Tor per Fernbedienung bewege:
Gebe ich nun bei "targetPositionRaw" -> 0 -> ein, fährt das Tor auf.
Gebe ich -> 51200 -> ein, fährt es zu.
Wenn ich aber -> 63487 -> eingebe, wechselt der Wert wieder auf 51200 (100%).
Kann man die Werteliste zur Eingabe in diesem Feld vielleicht ergänzen?
Wäre top, wenn ich über ioBroker beim Tor auch nur einen Flügel steuern könnte.
Danke für die Hilfe!
Ja, nun sind die Warnungen weg, und bei mir alle 22 Produkte da.
Das alles bei Version v1.3.5.
Danke für die schnelle Umsetzung!!!
Danke dir!
Es kommt im Log vorher auch die Info -> "Reading limitations for product 1..." und das für alle Produkte bis 21 bei mir.
Ich meine, diese Meldung gab es ja vorher auch nicht. Oder ist die nach 1.3.1 dazu gekommen?
Hab bei mir das gleiche Verhalten. Auch die Warnung für 20 + 21.
Es werden aber trotzdem alle Produkte über 20 gefunden.
Hab noch ein wenig „ausprobiert“.
Dabei hab ich festgestellt, dass das Problem nur mit der 1.3.2 Version vorkommt.
Mit Downgrade auf 1.3.1 (und auch kleiner - bis 1.2 getestet) funktioniert das ganze.