Test Adapter shuttercontrol v1.7.x
-
@simatec sagte in Test Adapter shuttercontrol v1.1.x:
Was passiert, wenn du den state deines Rollladen manuell auf 50% setzt?
Ehrlich gesagt hört hier schon mein bischen Wissen auf.......leider.
Über object----autolevel...?
Hast du noch ne Krücke für mich?
-
@FoxRo sagte in Test Adapter shuttercontrol v1.1.x:
Den FHEM und den FHEM Adapter kenne ich auch nicht. Weiss nur, dass der Adapter via Telnet Commands mit dem FHEM kommuniziert. Könntest evtl prüfen, ob Du via Telnet das Kommando mit 50% manuell direkt auslösen kannst. Damit könntest feststellen ob das Problem im FHEM oder im FHEM Adapter liegt.
Seltsam ist, dass IoBroker offensichtlich den Wert nicht schreiben kann dies aber ohne Fehlermeldung einfach übergeht. Könnte es sein, dass der Datentyp des Rollo Positionsobjekts vom FHEM Adapter nicht kompatibel ist? Bei mir ist die Rolloposition vom Typ "number". Du kannst dies im Objekt unter der Kartei RAW (nur Experten) einsehen.Ja wie oben geschrieben, dass geht für mich jetzt zu sehr ans Eingemachte. Sehr schade. Ich lass das aber mal auf mich wirken. Vielleicht findet sich hier nochmal ein FHEM-Experte ein, der mir u.U. helfen könnte.
Ich würde ja am liebsten ganz auf FHEM verzichten, nutze sowieso nur noch das "Rollo"Modul in FHEM, weil es anscheinend die einzige Möglichkeit bietet, meine Jarolift Funkschalter anzusteuern. Vielleicht gibt es ja mal jemanden hier in der iobroker Welt, der das "Rollo Modul" auf iobroker überträgt. Es gibt ja doch einige die die Jaros nutzen. Wäre toll.
Zunächst aber mal ganz lieben Dank euch Beiden für die Mühe
lg
tom -
Ich möchte euch beiden doch noch mal auf die Nerven gehen bevor ich mich dann vielleicht doch von diesem schönen Adapter verabschieden muss.....leider
Ich habe gerade nochmal meine ursprüngliche Einstellung genommen und probiert:
Also
Ok ich weiß es sollte 0 und 100 getauscht sein. Habe ich verstanden.
Aber mit dieser Einstellung fährt der Rollo auf jede Stellung die ich einstelle per Fensterkontakt, ganz sauber. Alles probiert!Allerdings ist dann close und open bei den Objects vertauscht. Zum Schließen muss ich dann bspw. "openSleep" zum öffnen nehmen. Wenn ich das nun per Option tauschen könnte, würde doch sicherlich auch die Zeitsteuerung funktionieren, oder denke ich da total falsch?
Und das heißt aber doch auch , dass die Kommandos zum "%fahren" der Rollos bei FHEM ankommen, oder?
Grüße
Tom -
@Tom-Haase
Deine Einstellungen sind noch immer falsch.
Bitte stelle es wie folgt ein
-
@Tom-Haase
Ich habe deine Konstellation mal simuliert und es funktioniert problemlos.
Bitte halte dich an meinen Screenshot bzw. meine markierten Änderungen -
@simatec said in Test Adapter shuttercontrol v1.1.x:
Hi,
das hatte ich ja schon eingestellt und damit fährt das Ding ja auch odentlich rauf und runter. Aber eben der Fensterkontakt mag diese Einstellung nicht und möchte es anscheinend lieber anders rum.2021-01-12 07:42:14.678 - debug: shuttercontrol.0 (29264) TriggerID changed: zigbee.0.00158d00053f428f.opened Value: true 2021-01-12 07:42:14.682 - debug: shuttercontrol.0 (29264) save trigger height: 100% for device: Buero1 pct 2021-01-12 07:42:14.683 - debug: shuttercontrol.0 (29264) save trigger action: down for device: Buero1 pct 2021-01-12 07:42:18.533 - debug: shuttercontrol.0 (29264) TriggerID changed: zigbee.0.00158d00053f428f.opened Value: false 2021-01-12 07:42:18.540 - debug: shuttercontrol.0 (29264) shutter trigger released Buero1 pct already in place: 100% 2021-01-12 07:42:18.541 - debug: shuttercontrol.0 (29264) save back trigger action: down for device Buero1 pctHattest du den Fensterkontakt auch simuliert?
-
@tom-haase
Den Fensterkontakt hatte ich auch simuliert.
Der Zigbee Kontakt opened ist ein ein state für die Meldung offen.offen = true
geschlossen = falseshuttercontrol benötigt in der Config den Wert des geschlossenen Zustandes.
Also musst du "false" einstellen. -
@simatec said in Test Adapter shuttercontrol v1.1.x:
Also musst du "false" einstellen.
Alles brav gemacht, das Biest macht nix.
-
@tom-haase said in Test Adapter shuttercontrol v1.1.x:
@simatec said in Test Adapter shuttercontrol v1.1.x:
Also musst du "false" einstellen.
Alles brav gemacht, das Biest macht nix.
habe auch nochmals im Code geschaut.
Die Log-Einträge von Dir oben passen leider auch zu einer Situation, wenn er nicht in den Ast geht, um effektiv zu fahren. Mit anderen Worten, wenn er das "Gefühl" hat, dass der Rollo schon korrekt offen steht, wenn das Fenster geöffnet wird. Dann kommt nämlich kein Fahr-Auftrag.
Kannst Du mal die Objekt-Werte von Shuttercontrol - shutters - autolevel - >Dein Rollo< hier posten, einmal bei Fenster zu und einmal während Du das Fenster offen hast?
zusätzlich wäre es, wie schon mal weiter oben geschrieben, interessant zu wissen, was im autoState drin steht, wenn das Fenster offen und wenn es zu ist. Könnte sein, dass sich hier der Zustand eben doch ändert.
Das gäbe evtl einen Hinweis, wo der Code in Deinem Fall effektiv durchläuft. -
@tom-haase
Ich denke du musst in den Extraeinstellungen die Überprüfung deiner Rollläden einschalten. Dein State wird sicher nicht sofort gesetzt.
Mit der Option wird der Status nach einer Minute noch einmal abgefragt -
Der Adapter steuert zuverlässig zwei neue Rollläden bei uns - vielen Dank!
Allerdings haben wir ein kleines Problem beim lüften am Morgen. Die "späteste Zeit für das hochfahren" ist auf 07:30h eingestellt. Das Fenster wird aber nun z.B. manchmal um 07:20h zum lüften geöffnet und der Rollladen fährt wie konfiguriert auf 50% hoch. 07:35h wird das Fenster wieder geschlossen, der Rollladen fährt wieder runter - bleibt aber zu da 07:30h bereits vorbei ist. Da hilft aktuell nur manuelle Betätigung
Konfiguration:
Hat jemand einen Tipp?
Danke! -
@zolpetol said in Test Adapter shuttercontrol v1.1.x:
Hat jemand einen Tipp?
Danke!Dazu kannst Du den "Aussperrschutz" verwenden der bei Dir aktuell auf Aus steht.
Die Option "Fahren, nachdem das Fenster geschlossen wurde" ist mit dem Aussperrschutz gekoppelt!
Verwende Aussperrschutz = "Schliessen" wenn der Rollo bei offenem Fenster mit den anderen Rollos Schliessen soll, beim öffnen aber erst fahren darf, wenn das Fenster geschlossen wurde.
Verwende Aussperrschutz = "Öffnen" wenn der Rollo zusammen mit den anderen öffnen soll, aber erst schliessen darf, wenn das Fenster geschlossen wurde.
Verwende Aussperrschutz = "Öffnen/Schliessen" wenn der Rollo bei offenen Fenster zusammen mit den anderen öffnen und schliessen darf/soll.
Viele Grüsse, Roli -
@foxro Danke für den Hinweis, probiere ich einmal aus!
-
@foxro said in Test Adapter shuttercontrol v1.1.x:
Kannst Du mal die Objekt-Werte von Shuttercontrol - shutters - autolevel - >Dein Rollo< hier posten, einmal bei Fenster zu und einmal während Du das Fenster offen hast?
zusätzlich wäre es, wie schon mal weiter oben geschrieben, interessant zu wissen, was im autoState drin steht, wenn das Fenster offen und wenn es zu ist.
Rollo oben:
und bei Rollo unten:
Rollo unten und Fensterkontakt auf:
Rollo oben und Kontakt auf:
@simatec
Habe die Option jetzt in den Extraeinstellungen gesetzt.Die Zeitsteuerung funzt wie gehabt super, Fensterkontakt leider keine Reaktion.
-
@tom-haase said in Test Adapter shuttercontrol v1.1.x:
Rollo oben:
und bei Rollo unten:
Rollo unten und Fensterkontakt auf:
Langsam kommen wir der Sache auf die Spur. Er geht wie vermutet in den falschen "Ast".
Welche Node.JS Version hast Du bei Dir installiert?
Das Problem liegt in dieser Zeile Code
if (typeof state != undefined && state != null && state.val != arrayChangeTrigger[i].triggerDrive && arrayChangeTrigger[i].triggerChange != 'off' && ((state.val < arrayChangeTrigger[i].triggerDrive && convertShutter == false) || (state.val > arrayChangeTrigger[i].triggerDrive && convertShutter == true))) {Diese checkt, nachdem das Fenster geöffnet wurde, ob der Rollo nicht auf der angeforderten Höhe steht, und der Rollo weiter unten steht als die angeforderte Höhe steht ..
Nun ist es im Java Script so, dass eine Prüfung mit (!=) nicht gleich der Prüfung (!==) ist. Und da ist im JS aus meiner Sicht völlig willkürlich, was man wann genau benutzen muss.
Ich würde behaupten, wenn man den Code so formulieren würdeif (typeof state !== undefined && state !== null && state.val !== arrayChangeTrigger[i].triggerDrive && arrayChangeTrigger[i].triggerChange !== 'off' && ((state.val < arrayChangeTrigger[i].triggerDrive && convertShutter == false) || (state.val > arrayChangeTrigger[i].triggerDrive && convertShutter == true))) {
Dann würde es wohl funktionieren.
Traust Du Dir zu, dies im File "triggerChange.js" testhalber zu ändern?@simatec : Das ich habe in meinem Fork auch schon ähnliches angepasst, da ich an einer anderen Stelle auch plötzlich solche Probleme bekam. Weiter habe ich da auch noch eine zusätzliche Funktion um das Öffen/Schliessen verzögern zu können eingebaut.
Soll ich dir dies mal auf Dein DEV pushen?
Viele Grüsse, Roli -
@foxro said in Test Adapter shuttercontrol v1.1.x:
Welche Node.JS Version hast Du bei Dir installiert?
v12.20.0
-
@foxro das ist nicht willkürlich, wenn man a == false abfragst, würde du zb. True zurückbekommen wenn a
Den Zustand false hat oder null oder undefined oder 0
Wenn du a === false abfragt bekommst du auch wirklich nur beim zustsnd false true zurück -
@foxro said in Test Adapter shuttercontrol v1.1.x:
if (typeof state !== undefined && state !== null && state.val !== arrayChangeTrigger[i].triggerDrive && arrayChangeTrigger[i].triggerChange !== 'off' && ((state.val < arrayChangeTrigger[i].triggerDrive && convertShutter == false) || (state.val > arrayChangeTrigger[i].triggerDrive && convertShutter == true))) {
Dann würde es wohl funktionieren.
Traust Du Dir zu, dies im File "triggerChange.js" testhalber zu ändern?Gesagt, getan (Notepad++)......leider nix
-
@foxro
Ja pushe ruhig mal.
Arbeite momentan viel an Backitup und komme gerade aus Zeitgründen nicht dazu -
@tom-haase
Beobachte mal bitte beim fahren deines Rollladens bitte den State im fhem Adapter.
Ich hab das Gefühl, dass dieser nicht sofort den Wert setzt
