NEWS
Test Adapter shuttercontrol v2.0.x
Test Adapter shuttercontrol v2.0.x
-
@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 abgefragtDer 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! -
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 -
@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 -
@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.@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.
-
@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 -
@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.
Support us
105
Online32.4k
Users81.3k
Topics1.3m
Posts