Shelly States im ioBroker Root Verzeichnis ? ?
-
@martink Und wurde die DP nun unter dem Shelly Adapter wieder angelegt?
Wenn Du es wieder umstellst, dann halt den Haken wieder rausmachen und dann wieder Browser refresh.
Wie gesagt - mach ein Issue auf - wenn man den Weg auf den Admin4 nicht mehr zurück hat - dann hat man in Zukunft die A....karte gezogen und kann solche DP nicht mehr löschen. Ich sag da inzwischen nichts mehr, weil ich glaub hier im Forum schon zur Genüge als Kritiker des Admin5 bekannt bin und meine Liste von Einschränkungen inzwischen ziemlich lang ist.
@mickym Ja, vielen Dank für deine Hilfe !
ich werde es mal testen.
Wenn ich jetzt auch noch dem Problem auf die schliche komme, warum die Zigbee Sensoren States nicht sofort beim ersten mal geschaltet werden... dann bin ich zufrieden ;-) ... die Aquara Motion liefern den state sofort - aber irgendwie werden sie erst beim zweiten mal der Änderung an den Shelly Adapter zum schalten weiter gegeben.... :-/ sehr komisch das ganze... hat vor einem halben Jahr noch zu 99% immer geklappt... sind auch keine weiteren Sensoren dazu gekommen.... sind nur 6 Aqara Motion...konnte ich helfen ? Dann würde ich mich über ein Voting freuen ! (rechts unten)...
-
@mickym Ja, vielen Dank für deine Hilfe !
ich werde es mal testen.
Wenn ich jetzt auch noch dem Problem auf die schliche komme, warum die Zigbee Sensoren States nicht sofort beim ersten mal geschaltet werden... dann bin ich zufrieden ;-) ... die Aquara Motion liefern den state sofort - aber irgendwie werden sie erst beim zweiten mal der Änderung an den Shelly Adapter zum schalten weiter gegeben.... :-/ sehr komisch das ganze... hat vor einem halben Jahr noch zu 99% immer geklappt... sind auch keine weiteren Sensoren dazu gekommen.... sind nur 6 Aqara Motion@martink sagte in Shelly States im ioBroker Root Verzeichnis ? ?:
die Aquara Motion liefern den state sofort - aber irgendwie werden sie erst beim zweiten mal der Änderung an den Shelly Adapter zum schalten weiter gegeben...
Nun das machen ja nicht den Sensoren sondern das machst Du ja mit Deiner Logikmaschine (Blockly, JS oder NR) - da musst das halt ggf. nochmals überprüfen, ob die Signale auch das Skript triggern.
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@martink sagte in Shelly States im ioBroker Root Verzeichnis ? ?:
die Aquara Motion liefern den state sofort - aber irgendwie werden sie erst beim zweiten mal der Änderung an den Shelly Adapter zum schalten weiter gegeben...
Nun das machen ja nicht den Sensoren sondern das machst Du ja mit Deiner Logikmaschine (Blockly, JS oder NR) - da musst das halt ggf. nochmals überprüfen, ob die Signale auch das Skript triggern.
@mickym Ja, das machen Sie - aber wie gesagt, nicht immer zuverlässig beim ersten mal wenn der State der Sensoren geändert wird... komisch das ganze. Ich sehe unter den Objekten das der State zuverlässig erkannt wird, nur eben nicht gleich im Shelly adapter geschaltet wird... :-/
...konnte ich helfen ? Dann würde ich mich über ein Voting freuen ! (rechts unten)...
-
@mickym Ja, das machen Sie - aber wie gesagt, nicht immer zuverlässig beim ersten mal wenn der State der Sensoren geändert wird... komisch das ganze. Ich sehe unter den Objekten das der State zuverlässig erkannt wird, nur eben nicht gleich im Shelly adapter geschaltet wird... :-/
@martinkOk ACK Flag ist es erst mal nicht
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@martink Vielleicht kommt der Shelly Adapter nicht mit, weil Du 2 DP so schnell hintereinander schaltest. Schau mal ob das Problem nicht mehr hast, wenn Du nur 1 Shelly schaltest. Wenn das geht musst halt so 250-500 ms Verzögerung dazwischen schalten.
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@mickym puuuh, ich bin wie gesagt nicht so der Nerd... ich wüsste auch nicht genau wie ich das im Debug output darstellen kann....
- beim Objekttrigger wird ja die Änderung mit "egal" angegeben, da sollte das flag doch keine Rolle spielen oder ?
...konnte ich helfen ? Dann würde ich mich über ein Voting freuen ! (rechts unten)...
-
@martink Vielleicht kommt der Shelly Adapter nicht mit, weil Du 2 DP so schnell hintereinander schaltest. Schau mal ob das Problem nicht mehr hast, wenn Du nur 1 Shelly schaltest. Wenn das geht musst halt so 250-500 ms Verzögerung dazwischen schalten.
@mickym sagte in Shelly States im ioBroker Root Verzeichnis ? ?:
@martink Vielleicht kommt der Shelly Adapter nicht mit, weil Du 2 DP so schnell hintereinander schaltest. Schau mal ob das Problem nicht mehr hast, wenn Du nur 1 Shelly schaltest.
Ist auch bei Blocklys mit 1. Shelly das gleiche ;-)
-
@mickym puuuh, ich bin wie gesagt nicht so der Nerd... ich wüsste auch nicht genau wie ich das im Debug output darstellen kann....
- beim Objekttrigger wird ja die Änderung mit "egal" angegeben, da sollte das flag doch keine Rolle spielen oder ?
@martink sagte in Shelly States im ioBroker Root Verzeichnis ? ?:
@mickym puuuh, ich bin wie gesagt nicht so der Nerd... ich wüsste auch nicht genau wie ich das im Debug output darstellen kann....
- beim Objekttrigger wird ja die Änderung mit "egal" angegeben, da sollte das flag doch keine Rolle spielen oder ?
Jo das ist OK
-
@mickym puuuh, ich bin wie gesagt nicht so der Nerd... ich wüsste auch nicht genau wie ich das im Debug output darstellen kann....
- beim Objekttrigger wird ja die Änderung mit "egal" angegeben, da sollte das flag doch keine Rolle spielen oder ?
@martink sagte in Shelly States im ioBroker Root Verzeichnis ? ?:
@mickym puuuh, ich bin wie gesagt nicht so der Nerd... ich wüsste auch nicht genau wie ich das im Debug output darstellen kann....
- beim Objekttrigger wird ja die Änderung mit "egal" angegeben, da sollte das flag doch keine Rolle spielen oder ?
Du machst einfach in dem Trigger so einen Debug output und dann siehst Du im Log, ob das Skript sofort getriggert wurde:
im Log steht ja auch immer ein Zeitstempel und den kann man mit dem Zeitstempel der letzten Änderung im Zigbee Datenpunkt vergleichen.
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@martink sagte in Shelly States im ioBroker Root Verzeichnis ? ?:
@mickym puuuh, ich bin wie gesagt nicht so der Nerd... ich wüsste auch nicht genau wie ich das im Debug output darstellen kann....
- beim Objekttrigger wird ja die Änderung mit "egal" angegeben, da sollte das flag doch keine Rolle spielen oder ?
Du machst einfach in dem Trigger so einen Debug output und dann siehst Du im Log, ob das Skript sofort getriggert wurde:
im Log steht ja auch immer ein Zeitstempel und den kann man mit dem Zeitstempel der letzten Änderung im Zigbee Datenpunkt vergleichen.
-
@martink sagte in Shelly States im ioBroker Root Verzeichnis ? ?:
@mickym puuuh, ich bin wie gesagt nicht so der Nerd... ich wüsste auch nicht genau wie ich das im Debug output darstellen kann....
- beim Objekttrigger wird ja die Änderung mit "egal" angegeben, da sollte das flag doch keine Rolle spielen oder ?
Du machst einfach in dem Trigger so einen Debug output und dann siehst Du im Log, ob das Skript sofort getriggert wurde:
im Log steht ja auch immer ein Zeitstempel und den kann man mit dem Zeitstempel der letzten Änderung im Zigbee Datenpunkt vergleichen.
@mickym .. also ich habe das ganze mal wie folgt getestet mit der debug ausgabe :
und das Ergebnis ist wie immer verzöger:
wie kann ich die Fehlerquelle denn jetzt näher eingrenzen ?
...konnte ich helfen ? Dann würde ich mich über ein Voting freuen ! (rechts unten)...
-
@mickym .. also ich habe das ganze mal wie folgt getestet mit der debug ausgabe :
und das Ergebnis ist wie immer verzöger:
wie kann ich die Fehlerquelle denn jetzt näher eingrenzen ?
-
@mickym .. also ich habe das ganze mal wie folgt getestet mit der debug ausgabe :
und das Ergebnis ist wie immer verzöger:
wie kann ich die Fehlerquelle denn jetzt näher eingrenzen ?
@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.
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@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.
@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 :-)
...konnte ich helfen ? Dann würde ich mich über ein Voting freuen ! (rechts unten)...
-
@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.
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@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 ?
...konnte ich helfen ? Dann würde ich mich über ein Voting freuen ! (rechts unten)...
-
@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. ;)
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@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 ;-)
...konnte ich helfen ? Dann würde ich mich über ein Voting freuen ! (rechts unten)...
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 Anmelden546
Online32.9k
Benutzer83.0k
Themen1.3m
Beiträge