NEWS
Test Adapter shuttercontrol v2.0.x
Test Adapter shuttercontrol v2.0.x
-
@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 -
@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 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 -
@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:
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
-
@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:
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
@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 -
@foxro
Ja pushe ruhig mal.
Arbeite momentan viel an Backitup und komme gerade aus Zeitgründen nicht dazu@simatec said in Test Adapter shuttercontrol v1.1.x:
@foxro
Ja pushe ruhig mal.
Arbeite momentan viel an Backitup und komme gerade aus Zeitgründen nicht dazuDas war ein "Pfuschversuch" mit dem Vorschlag an @Tom-Haase .
Er offenbart auch, dass ich bei @Tom-Haase nun am Ende meines Lateins bin. Ohne Debugger komme ich da nicht mehr weiter.
Es wird wohl, wie Du sagst, mit dem State zu tun haben.
PS. Das mit dem PR halte ich noch ein wenig zurück. Grund: das mit der von mir veränderten Abfrage der Stati bei mir passt mir noch nicht, da ich es noch nicht 100% verstehe, obwohl es funktioniert.
@Tom-Haase : Bitte meinen "Pfusch-Vorschlag" wieder zurück stellen. Das bringt nichts. Sorry, lag da daneben.Viel Erfolg euch!
Viele Grüsse, Roli -
@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@simatec said in Test Adapter shuttercontrol v1.1.x:
@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 setztbeim runterfahren:
2021.01.17 10:21:07 3 : Testname: SD_Keeloq_AC6000 set down 9 2021-01-17 10:21:07 ROLLO Friedhelm command: pct-100 2021-01-17 10:21:07 ROLLO Friedhelm desired_pct: 100 2021-01-17 10:21:07 ROLLO Friedhelm last_drive: drive-down 2021-01-17 10:21:07 ROLLO Friedhelm drive-down 2021-01-17 10:21:07 ROLLO Friedhelm drive-type: modul 2021-01-17 10:21:07 SD_Keeloq SD_Keeloq_AC6000 button: down 2021-01-17 10:21:07 SD_Keeloq SD_Keeloq_AC6000 channel: 9 2021-01-17 10:21:07 SD_Keeloq SD_Keeloq_AC6000 counter_send: 9686 2021-01-17 10:21:07 SD_Keeloq SD_Keeloq_AC6000 send down 2021-01-17 10:21:07 SD_Keeloq SD_Keeloq_AC6000 LastAction_Channel_09: down 2021-01-17 10:21:07 SD_Keeloq SD_Keeloq_AC6000 channel_control: no 2021.01.17 10:21:34 3 : Testname: SD_Keeloq_AC6000 set stop 9 2021-01-17 10:21:34 ROLLO Friedhelm pct: 100 2021-01-17 10:21:34 SD_Keeloq SD_Keeloq_AC6000 button: stop 2021-01-17 10:21:34 SD_Keeloq SD_Keeloq_AC6000 channel: 9 2021-01-17 10:21:34 SD_Keeloq SD_Keeloq_AC6000 counter_send: 9687 2021-01-17 10:21:34 SD_Keeloq SD_Keeloq_AC6000 send stop 2021-01-17 10:21:34 SD_Keeloq SD_Keeloq_AC6000 LastAction_Channel_09: stop 2021-01-17 10:21:34 SD_Keeloq SD_Keeloq_AC6000 channel_control: no 2021-01-17 10:21:34 ROLLO Friedhelm closedbeim hochfahren:
2021.01.17 10:22:39 3 : Testname: SD_Keeloq_AC6000 set up 9 2021-01-17 10:22:39 ROLLO Friedhelm command: pct-0 2021-01-17 10:22:39 ROLLO Friedhelm desired_pct: 0 2021-01-17 10:22:39 ROLLO Friedhelm last_drive: drive-up 2021-01-17 10:22:39 ROLLO Friedhelm drive-up 2021-01-17 10:22:39 ROLLO Friedhelm drive-type: modul 2021-01-17 10:22:39 SD_Keeloq SD_Keeloq_AC6000 button: up 2021-01-17 10:22:39 SD_Keeloq SD_Keeloq_AC6000 channel: 9 2021-01-17 10:22:39 SD_Keeloq SD_Keeloq_AC6000 counter_send: 9688 2021-01-17 10:22:39 SD_Keeloq SD_Keeloq_AC6000 send up 2021-01-17 10:22:39 SD_Keeloq SD_Keeloq_AC6000 LastAction_Channel_09: up 2021-01-17 10:22:39 SD_Keeloq SD_Keeloq_AC6000 channel_control: no 2021.01.17 10:23:08 3 : Testname: SD_Keeloq_AC6000 set stop 9 2021-01-17 10:23:08 ROLLO Friedhelm pct: 0 2021-01-17 10:23:08 SD_Keeloq SD_Keeloq_AC6000 button: stop 2021-01-17 10:23:08 SD_Keeloq SD_Keeloq_AC6000 channel: 9 2021-01-17 10:23:08 SD_Keeloq SD_Keeloq_AC6000 counter_send: 9689 2021-01-17 10:23:08 SD_Keeloq SD_Keeloq_AC6000 send stop 2021-01-17 10:23:08 SD_Keeloq SD_Keeloq_AC6000 LastAction_Channel_09: stop 2021-01-17 10:23:08 SD_Keeloq SD_Keeloq_AC6000 channel_control: no 2021-01-17 10:23:08 ROLLO Friedhelm openHabe den Fensterkontakt mal im geschlossenen (und auch mal geöffneten) Zustand geöffnet und geschlossen, zeigt aber leider keine Reaktion im FHEM Log
Der shuttercontrol Befehl (openSleep, closeSleep) wird ohne Zeitverzögerung sofort in FHEM angezeigt und auch direkt ausgeführt.
@FoxRo
Danke für das ausprobieren und deine Geduld -
@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@dirkhe said in Test Adapter shuttercontrol v1.1.x:
@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ückDanke für Dein Feedback. Ich bin da noch am lernen und bei den "truthy" Werten bin ich unterdessen bei Dir.
Bei einer Prüfung auf "falsy" bin ich noch echt verwirrt.
Einige einschlägige Foren widersprechen sich, wie man auf 'undefined' und 'null' prüfen soll.
Was ich im IoBroker auch schon erlebt habe ist:
if (typeof state != undefined && state != null => liefert false
if (typeof state !== undefined && state !== null => liefert true
Die Erklärung für dieses Verhalten habe ich bis heute noch nicht gefunden, wenn doch eigentlich beide das gleiche Resultat liefern sollten, ausser dass bei der ersten, wenn möglich, vorab eine allfällige Typ-Konvertierung durchgeführt wird.
.. deshalb ist das für mich aktuell schon ein wenig "willkürlich" um es etwas provokativ auszudrücken.
Vielleicht hast Du dazu eine gute Erklärung die mir etwas "Erleuchtung" bringt?
Viele Grüsse, RoliPS. Sorry, ist eigentlich Off-Topic hier.
-
@dirkhe said in Test Adapter shuttercontrol v1.1.x:
@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ückDanke für Dein Feedback. Ich bin da noch am lernen und bei den "truthy" Werten bin ich unterdessen bei Dir.
Bei einer Prüfung auf "falsy" bin ich noch echt verwirrt.
Einige einschlägige Foren widersprechen sich, wie man auf 'undefined' und 'null' prüfen soll.
Was ich im IoBroker auch schon erlebt habe ist:
if (typeof state != undefined && state != null => liefert false
if (typeof state !== undefined && state !== null => liefert true
Die Erklärung für dieses Verhalten habe ich bis heute noch nicht gefunden, wenn doch eigentlich beide das gleiche Resultat liefern sollten, ausser dass bei der ersten, wenn möglich, vorab eine allfällige Typ-Konvertierung durchgeführt wird.
.. deshalb ist das für mich aktuell schon ein wenig "willkürlich" um es etwas provokativ auszudrücken.
Vielleicht hast Du dazu eine gute Erklärung die mir etwas "Erleuchtung" bringt?
Viele Grüsse, RoliPS. Sorry, ist eigentlich Off-Topic hier.
@foxro typeof musst du mit Anführungszeichen abfragen, also typeof x === 'undefined'
https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/undefined
Sollten jetzt aber wirklich aufhören, hier den Thread zu sprengen -
-
@simatec
habe auf die 1.1.4 aufgerüstet und auch alles andere auf den neuesten Stand gebracht. Leider keine Veränderung. Möchte aber trotzdem kurzfristig auf deinen shuttercontrol wechseln. Müsste ich leider die Fensterkontakte eben anders steuern. -
@simatec
habe auf die 1.1.4 aufgerüstet und auch alles andere auf den neuesten Stand gebracht. Leider keine Veränderung. Möchte aber trotzdem kurzfristig auf deinen shuttercontrol wechseln. Müsste ich leider die Fensterkontakte eben anders steuern.@tom-haase
In der Version 1.1.4 gibt es dort noch keine Änderungen. Die Änderungen beziehen sich aktuell auf den neuen js-controller.Soweit ich weiß, ist aber @FoxRo an den Anpassungen dran.
-
@tom-haase
In der Version 1.1.4 gibt es dort noch keine Änderungen. Die Änderungen beziehen sich aktuell auf den neuen js-controller.Soweit ich weiß, ist aber @FoxRo an den Anpassungen dran.
@simatec said in Test Adapter shuttercontrol v1.1.x:
@tom-haaseSoweit ich weiß, ist aber @FoxRo an den Anpassungen dran.
Da muss ich euch beiden wohl eine schlechte Nachricht überbringen. Meine Anpassungen sind für eine kleine Erweiterung "einstellbares delay" für das Fenster auf/zu Verhalten geplant. Ich sehe im Moment keinen Einfluss meiner Modifikationen auf das Verhalten bei @Tom-Haase - Sorry tut mir leid.
Da ich nicht weiss, an was es bei Dir liegt, kann ich diesbezüglich auch keine Verbesserung vornehmen. (zumal mein "Pfusch Vorschlag" ebenfalls nichts gebracht hatte.)
Ich überlege mir noch, ob ich das Logging an dieser Stelle etwas verbessern könnte, damit wir mehr Rückmeldung bekommen. Mehr geht aktuell leider nicht.
@Tom-Haase : Wenn wir da einen Schritt weiterkommen wollen, sehe ich im Moment nur noch eine Remote Session (zb. Teamviewer), wo wir uns das mal gemeinsam anschauen können. Alles andere ist "Basteln" und wird Deine Geduld unnötig auf die Probe stellen.
Wie siehst du das?
Viele Grüsse, Roli -
Hallo IoBroker Gemeinde,
da ich hier im Forum immer mal wieder gelesen habe, dass es Fragen nach einer Lösung für die automatische Rollladensteuerung gab, habe ich mich mal bei gemacht und einen Adapter dafür geschrieben.
An dieser Stelle ein riesengroßes Dankeschön an alle Dev's für die Unterstützung bei einigen Fragen dazu.Aktuell befindet sich der Adapter in der latest Repro und kann ganz einfach über den Tab "Adapter" in eurem iobroker installiert werden.
Die aktuelle Dokumentation findet ihr unter folgenden Links:
Hier der Link zum Github-Projekt:
https://github.com/simatec/ioBroker.shuttercontrol.git
ioBroker.shuttercontrol
Shuttercontrol ist ein Adapter zur automatischen Steuerung von Rollläden und Markisen.
Viel Spaß beim testen ...
@simatec sehr cool.
Doofe Frage aber funktioniert der Adapter auch mit den nachgerüsteten Bluetooth AM43 blind Drives ?
-
@simatec said in Test Adapter shuttercontrol v1.1.x:
@tom-haaseSoweit ich weiß, ist aber @FoxRo an den Anpassungen dran.
Da muss ich euch beiden wohl eine schlechte Nachricht überbringen. Meine Anpassungen sind für eine kleine Erweiterung "einstellbares delay" für das Fenster auf/zu Verhalten geplant. Ich sehe im Moment keinen Einfluss meiner Modifikationen auf das Verhalten bei @Tom-Haase - Sorry tut mir leid.
Da ich nicht weiss, an was es bei Dir liegt, kann ich diesbezüglich auch keine Verbesserung vornehmen. (zumal mein "Pfusch Vorschlag" ebenfalls nichts gebracht hatte.)
Ich überlege mir noch, ob ich das Logging an dieser Stelle etwas verbessern könnte, damit wir mehr Rückmeldung bekommen. Mehr geht aktuell leider nicht.
@Tom-Haase : Wenn wir da einen Schritt weiterkommen wollen, sehe ich im Moment nur noch eine Remote Session (zb. Teamviewer), wo wir uns das mal gemeinsam anschauen können. Alles andere ist "Basteln" und wird Deine Geduld unnötig auf die Probe stellen.
Wie siehst du das?
Viele Grüsse, Roli@foxro sagte in Test Adapter shuttercontrol v1.1.x:
Wenn wir da einen Schritt weiterkommen wollen, sehe ich im Moment nur noch eine Remote Session (zb. Teamviewer), wo wir uns das mal gemeinsam anschauen können. Alles andere ist "Basteln" und wird Deine Geduld unnötig auf die Probe stellen.
Wie siehst du das?Hi Roli,
ja das wäre super, bin da auch zeitlich ganz flexibel. Gibt es hier PN oder was ähnliches?
Grüße
Tom -
@foxro sagte in Test Adapter shuttercontrol v1.1.x:
Wenn wir da einen Schritt weiterkommen wollen, sehe ich im Moment nur noch eine Remote Session (zb. Teamviewer), wo wir uns das mal gemeinsam anschauen können. Alles andere ist "Basteln" und wird Deine Geduld unnötig auf die Probe stellen.
Wie siehst du das?Hi Roli,
ja das wäre super, bin da auch zeitlich ganz flexibel. Gibt es hier PN oder was ähnliches?
Grüße
Tom@tom-haase auf username klicken, dann biste im profil. rechts die 3 punkte: start new chat with ...
Support us
334
Online32.4k
Users81.3k
Topics1.3m
Posts