NEWS
Shelly States im ioBroker Root Verzeichnis ? ?
-
@mickym Ah ok ! Das sind alles gute Denkansätze... Ich bin gerade von Conbee2 + deConz Adapter auf CC26X2R1 + Zigbee Adapter umgestiegen ( weil ich dachte die Unzuverlässigkeit liegt am Conbee2) - und nun muss ich mich erstmal mit den neuen states aus dem Zigbee Adapter anfreunden :-)
@martink Jo schmeiss er mal die Timer aus Deinem Blockly und schau - ob das dann zuverlässig funktioniert und dann den Timer über occupancy-timeout nutzen. Wenn nichts drin steht, wird glaub nach 60s wenn keine Bewegung erkannt wurde occupancy auf false gesetzt.
-
@martink Jo schmeiss er mal die Timer aus Deinem Blockly und schau - ob das dann zuverlässig funktioniert und dann den Timer über occupancy-timeout nutzen. Wenn nichts drin steht, wird glaub nach 60s wenn keine Bewegung erkannt wurde occupancy auf false gesetzt.
-
@mickym Aber ich möchte ja, wenn wieder Bewegung zwischenzeitlich erkannt wird, das der Timer wieder von vorne anfängt... ? wenn occupancy dann auf false geht ist ja nach 3min das licht aus .. oder ?
@martink Nein der Timer wird zurückgesetzt wenn innerhalb von 3 min eine Bewegung erkannt wurde - wird der Timer automatisch zurückgesetzt - das heisst occupancy wird nur dann auf false gesetzt, wenn der BWM 3 Minuten keine Bewegung mehr erkannt hat.
@mickym Aber ich möchte ja, wenn wieder Bewegung zwischenzeitlich erkannt wird, das der Timer wieder von vorne anfängt... ? wenn occupancy dann auf false geht ist ja nach 3min das licht aus .. oder ?
Er geht nicht auf false. ;) Den Parameter kann man bis auf 1800s stellen - das heisst man kann auch 10 Minuten aus dem Zimmer gehen. ;)
-
@martink Nein der Timer wird zurückgesetzt wenn innerhalb von 3 min eine Bewegung erkannt wurde - wird der Timer automatisch zurückgesetzt - das heisst occupancy wird nur dann auf false gesetzt, wenn der BWM 3 Minuten keine Bewegung mehr erkannt hat.
@mickym Aber ich möchte ja, wenn wieder Bewegung zwischenzeitlich erkannt wird, das der Timer wieder von vorne anfängt... ? wenn occupancy dann auf false geht ist ja nach 3min das licht aus .. oder ?
Er geht nicht auf false. ;) Den Parameter kann man bis auf 1800s stellen - das heisst man kann auch 10 Minuten aus dem Zimmer gehen. ;)
-
@martink Nun da muss Dir ein Blockly Spezi wie @paul53 helfen. ;) - Ich nutzte ja eine andere Logik-Maschine.
Was man aber daraus schon sehen kann ist, dass es nichts mit dem Shelly Adapter zu tun hat, sondern eher mit Deinem Skript.Die Reihenfolge zwischen 2 und 3 ist wahrscheinlich so - keine Ahnung - aber es sieht doch so aus, als ob Deine Bedingung
occupancy = true && illuminace <=40 nicht immer ausgewertet wird und deshalb nicht geschaltet wird.
Also liegt hier die Ursache - warum das Blockly das nicht lesen kann, muss ein Blockly Freak lösen - ich nutze es wie gesagt nicht.
Vielleicht kommen 2 Trigger durch - kannst ja mal schauen - ob sich was ändert, wenn Du mal alle trigger durchlässt - mach mal Auslösung durch "Bestätigt" anstelle von egal.
Ich würde das Lampen ausschalten sowieso nicht über das Blockly machen - sondern über den occupancy_timeout im Zigbee arbeiten.
Das da ein Timer rumfuhrwerkt ist in meinen Augen nicht optimal. Also die grüne Klammer weg und wenn occupancy = false - sofort ausschalten. Wenn Dir das zu früh ist, und erst nach 3 Minuten willst, dann eben occupancy_timeout bei dem Zigbee BWM auf 180s setzen.
Ich lass den BWM erst nach 5 Minuten false melden:

Da muss man dann im Blockly auch keine Timer stoppen - da der Sensor bei jeder neuen Bewegung automatischen den Timer wiedr resetted..
Vielleicht sind es auch diese Timer - die keine zuverlässige Abarbeitung des Skriptes erlauben. Ich würde sie rausschmeissen.
Vielleicht kommen 2 Trigger durch - kannst ja mal schauen - ob sich was ändert, wenn Du mal alle trigger durchlässt - mach mal Auslösung durch "Bestätigt" anstelle von egal.
...also daran hat es schonmal nicht gelegen ... bei bestätigt ist es das gleiche verhalten... Löst erst nach der 3. Bewegung das schalten aus ;-)
-
@martink sagte in Shelly States im ioBroker Root Verzeichnis ? ?:
@mickym Alles klar! Vielen Dank ! Ich probiere das ganze Morgen mal aus :-)
Ja dann schlaf mal gut. :) - Jedenfalls würde ich nun die Ursache eher im Blockly und nicht im Shelly Adapter suchen.
-
@martink sagte in Shelly States im ioBroker Root Verzeichnis ? ?:
@mickym Alles klar! Vielen Dank ! Ich probiere das ganze Morgen mal aus :-)
Ja dann schlaf mal gut. :) - Jedenfalls würde ich nun die Ursache eher im Blockly und nicht im Shelly Adapter suchen.
-
Vielleicht kommen 2 Trigger durch - kannst ja mal schauen - ob sich was ändert, wenn Du mal alle trigger durchlässt - mach mal Auslösung durch "Bestätigt" anstelle von egal.
...also daran hat es schonmal nicht gelegen ... bei bestätigt ist es das gleiche verhalten... Löst erst nach der 3. Bewegung das schalten aus ;-)
@martink Ja für mich ist es dann ggf. der Adapter - vielleicht musst Du die Timer auch bei jedem Trigger löschen. Also stop Lampensausschaltung bevor Du die Abfrage machst.
Aber wie gesagt ich würde auf die Timer verzichten. Das solltest Du schnell umsetzen können und schauen, ob es dann keine Verzögerung mehr gibt, wenn Du alles Grüne aus Deinem Blockly emlimierst.
-
@martink Ja für mich ist es dann ggf. der Adapter - vielleicht musst Du die Timer auch bei jedem Trigger löschen. Also stop Lampensausschaltung bevor Du die Abfrage machst.
Aber wie gesagt ich würde auf die Timer verzichten. Das solltest Du schnell umsetzen können und schauen, ob es dann keine Verzögerung mehr gibt, wenn Du alles Grüne aus Deinem Blockly emlimierst.
-
@martink Wie gesagt ich bin kein Blockly Fan oder Spezi aber von der Logik würde ich es so machen:

Damit wird bei hell immer ausgeschaltet und sonst anhand des BWM.
Ich weiß nicht ob das 100% so richtig ist, aber so wäre mein Logikverständnis. Man muss natürlich den Schwellenwert so wählen, dass dieser bei künstlichem Licht nicht überschritten wird.
-
@martink Wie gesagt ich bin kein Blockly Fan oder Spezi aber von der Logik würde ich es so machen:

Damit wird bei hell immer ausgeschaltet und sonst anhand des BWM.
Ich weiß nicht ob das 100% so richtig ist, aber so wäre mein Logikverständnis. Man muss natürlich den Schwellenwert so wählen, dass dieser bei künstlichem Licht nicht überschritten wird.
@mickym Ja ich habe es gerade mit dem Occupancy Timeout getestet, aber dann wird einfach das Licht ausgeschaltet nach der Occupancy Timeout zeit... Diese Occupancy ist ja im Prinzip die Zeit, in der der BWM wieder auf eine neue Bewegung reagieren soll. Das war beim deConz der Duration Wert. Ich denke ich werde über den Last Motion State das abschalten bei Bewegung unterbinden ;-)
-
@mickym Ja ich habe es gerade mit dem Occupancy Timeout getestet, aber dann wird einfach das Licht ausgeschaltet nach der Occupancy Timeout zeit... Diese Occupancy ist ja im Prinzip die Zeit, in der der BWM wieder auf eine neue Bewegung reagieren soll. Das war beim deConz der Duration Wert. Ich denke ich werde über den Last Motion State das abschalten bei Bewegung unterbinden ;-)
@martink sagte in Shelly States im ioBroker Root Verzeichnis ? ?:
Diese Occupancy ist ja im Prinzip die Zeit, in der der BWM wieder auf eine neue Bewegung reagieren soll.
Nein das ist nicht ganz korrekt - der BMW reagiert mit jeder Bewegung sofort in der er den Timer zurücksetzt - das spielt also keine Rolle.
Sprich wenn er nach dem occupancy timeout also nach 3 Minuten auf false stellt, reagiert er sofort auf neue Bewegung und ist nicht 3 Minuten inaktiv. Das ist also falsch, wenn Du sagst der Parameter hat was mit der Registrierung von Bewegung zu tun oder Inaktivität des BWM zu tun.
Es ist das was occupancy_timeout von Begriff sagt, es ist der Timeout - also das Auslaufen des Occupancy Status nachdem die letzte Bewegung erkannt wurde. Hat mit der Reaktion des BWM null und nichts zu tun.Ich hab Dir ja mal ein Blockly Vorschlag von meiner Logik gesendet, wie ich das als Laie umsetzen würde.
-
@martink sagte in Shelly States im ioBroker Root Verzeichnis ? ?:
Diese Occupancy ist ja im Prinzip die Zeit, in der der BWM wieder auf eine neue Bewegung reagieren soll.
Nein das ist nicht ganz korrekt - der BMW reagiert mit jeder Bewegung sofort in der er den Timer zurücksetzt - das spielt also keine Rolle.
Sprich wenn er nach dem occupancy timeout also nach 3 Minuten auf false stellt, reagiert er sofort auf neue Bewegung und ist nicht 3 Minuten inaktiv. Das ist also falsch, wenn Du sagst der Parameter hat was mit der Registrierung von Bewegung zu tun oder Inaktivität des BWM zu tun.
Es ist das was occupancy_timeout von Begriff sagt, es ist der Timeout - also das Auslaufen des Occupancy Status nachdem die letzte Bewegung erkannt wurde. Hat mit der Reaktion des BWM null und nichts zu tun.Ich hab Dir ja mal ein Blockly Vorschlag von meiner Logik gesendet, wie ich das als Laie umsetzen würde.
-
@martink Du kannst sogar den no_motion DP verwenden, indem bekommst Du bis zu 1800s mitgeteilt, wie lange es her ist, seit dem der BWM auf false gestellt hat. Sprich den DP kannst DU auch nutzen, um beispielsweise ein schrittweises Herunterfahren zu programmieren.
-
@martink Du kannst sogar den no_motion DP verwenden, indem bekommst Du bis zu 1800s mitgeteilt, wie lange es her ist, seit dem der BWM auf false gestellt hat. Sprich den DP kannst DU auch nutzen, um beispielsweise ein schrittweises Herunterfahren zu programmieren.
@mickym Ich konnte auch den Übeltäter des verzögerten Schaltvorgangs ausfindig machen, es lag nicht an den installierten Timeout Blöcken, sondern es ist die Zeitgleiche abfrage des Occupancy und des Lux Wertes. ;-) .. ich habe den Eindruck, wenn ich in der "und" Logik die Eingänge von extern auf intern umstelle - dann wird die Zuverlässigkeit des schaltens schon besser... Wenn ich die Lux Überprüfung weg lasse funktioniert es (gefühlt) immer
.... kann das sein? Ist da ausser der Optik der Blöcke noch ein technischer Aspekt bei der Umstellung von intern auf externe Eingange dahinter ?? - Ich habe im Netz noch nichts dazu gefunden :-) .... vielleicht liest ja auch ein Blockly Spezi hier mit ;-) -
@mickym Ich konnte auch den Übeltäter des verzögerten Schaltvorgangs ausfindig machen, es lag nicht an den installierten Timeout Blöcken, sondern es ist die Zeitgleiche abfrage des Occupancy und des Lux Wertes. ;-) .. ich habe den Eindruck, wenn ich in der "und" Logik die Eingänge von extern auf intern umstelle - dann wird die Zuverlässigkeit des schaltens schon besser... Wenn ich die Lux Überprüfung weg lasse funktioniert es (gefühlt) immer
.... kann das sein? Ist da ausser der Optik der Blöcke noch ein technischer Aspekt bei der Umstellung von intern auf externe Eingange dahinter ?? - Ich habe im Netz noch nichts dazu gefunden :-) .... vielleicht liest ja auch ein Blockly Spezi hier mit ;-)@martink Ich bin zwar kein "Spezialist" aber meiner bescheidenen Meinung nach liegt es nicht am Blockly, sondern wie Du schon erkannt hast, ist einfach die zweite Bedingung nicht erfüllt, nämlich der luminance Wert nicht unter 40, warum auch immer.
-
@martink Ich bin zwar kein "Spezialist" aber meiner bescheidenen Meinung nach liegt es nicht am Blockly, sondern wie Du schon erkannt hast, ist einfach die zweite Bedingung nicht erfüllt, nämlich der luminance Wert nicht unter 40, warum auch immer.
@joergh sagte in Shelly States im ioBroker Root Verzeichnis ? ?:
@martink Ich bin zwar kein "Spezialist" aber meiner bescheidenen Meinung nach liegt es nicht am Blockly, sondern wie Du schon erkannt hast, ist einfach die zweite Bedingung nicht erfüllt, nämlich der luminance Wert nicht unter 40, warum auch immer.
Na das hab ich ja unten schon gesagt, dass man aufpassen muss, dass durch das eingeschaltete Licht der Schwellenwert nicht überschritten werden darf.
-
@martink Ich bin zwar kein "Spezialist" aber meiner bescheidenen Meinung nach liegt es nicht am Blockly, sondern wie Du schon erkannt hast, ist einfach die zweite Bedingung nicht erfüllt, nämlich der luminance Wert nicht unter 40, warum auch immer.
@joergh naja, ich habe so die Vermutung, wenn das Licht nach der eingestellten Zeit ausgeschaltet wird, behält der BWM den letzten Lux wert als State...(das ist natürlich mehr als 40, weil das Licht ja an geschaltet ist war ;-) ) und bei der nächsten Bewegungsauslösung kommt er scheinbar nicht so schnell an den aktuellen Lux Wert ran... So meine Vermutung ;-) .... Aber dann ist auf jeden fall der BWM dran schuld! Und ich brauche nicht meinem Zigbee Coordinator oder dem ioBroker die Schuld geben :-D ... Die Frage ist nur, wie bekomme ich das besser hin mit der Lichtmessung ?
Die Aqara Motion sind so schön klein, und ich will nicht überall so Rieeesen Klopper von BWM in den Zimmern haben ;-) -
@joergh naja, ich habe so die Vermutung, wenn das Licht nach der eingestellten Zeit ausgeschaltet wird, behält der BWM den letzten Lux wert als State...(das ist natürlich mehr als 40, weil das Licht ja an geschaltet ist war ;-) ) und bei der nächsten Bewegungsauslösung kommt er scheinbar nicht so schnell an den aktuellen Lux Wert ran... So meine Vermutung ;-) .... Aber dann ist auf jeden fall der BWM dran schuld! Und ich brauche nicht meinem Zigbee Coordinator oder dem ioBroker die Schuld geben :-D ... Die Frage ist nur, wie bekomme ich das besser hin mit der Lichtmessung ?
Die Aqara Motion sind so schön klein, und ich will nicht überall so Rieeesen Klopper von BWM in den Zimmern haben ;-)@martink Einfach die Schwelle muss höher sein, als bei eingeschaltem Licht - also einfach mal Licht anlassen und sich paar mal bewegen und den höchsten Wert + Puffer als Auslöseschwelle nehmen. Tageslicht ist oft vielfach höher - weil der Blaulichtanteil höher ist - ansonsten würde ich mir zu dem BWM Melder noch einen Helligkeitssensor anschaffen und den in die Nähe des Fensters plazieren.
-
@joergh naja, ich habe so die Vermutung, wenn das Licht nach der eingestellten Zeit ausgeschaltet wird, behält der BWM den letzten Lux wert als State...(das ist natürlich mehr als 40, weil das Licht ja an geschaltet ist war ;-) ) und bei der nächsten Bewegungsauslösung kommt er scheinbar nicht so schnell an den aktuellen Lux Wert ran... So meine Vermutung ;-) .... Aber dann ist auf jeden fall der BWM dran schuld! Und ich brauche nicht meinem Zigbee Coordinator oder dem ioBroker die Schuld geben :-D ... Die Frage ist nur, wie bekomme ich das besser hin mit der Lichtmessung ?
Die Aqara Motion sind so schön klein, und ich will nicht überall so Rieeesen Klopper von BWM in den Zimmern haben ;-)
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden
