Neues YouTube-Video: Visualisierung im Devices-Adapter

[JoergH]

@martink sagte in Shelly States im ioBroker Root Verzeichnis ? ?:

Hallo Kollegen, kann mir einer erklären - ob es so korrekt ist - das diese Shelly States im Root Verzeichnis vom ioBroker auftauchen

Nein, das ist nicht normal. So sollte es in etwa aussehen

[MartinK.]

@mickym Kannst du mir noch kurz erklären wie ich wieder auf die Admin 4 Oberfläche komme ?

[mickym]

@martink sagte in Shelly States im ioBroker Root Verzeichnis ? ?:

@mickym Kannst du mir noch kurz erklären wie ich wieder auf die Admin 4 Oberfläche komme ?

Unter Instanzen bei Admin Adapter auf Schraubenschlüssel:

Unten beschrieben: Instanz des Admin Adapter aufmachen und dann Haken wie unten im Screenshot setzen. Admin startet neu - dann Browser refresh.

Um die root Elemente zu sehen - auch Expertenmodus einschalten und ganz nach unten scrollen:

Und wenn das dann geht - dann kannst Du nur eine DICKE Beschwerde zu dem Admin5 Adapter auf GitHub schicken. Die Liste der beschränkten Möglichkeiten in dieser Version ist inzwischen so lang - dass man den Admin4 als Referenz wohl immer aktiv lassen muss. Bislang kann ich außer bunteren Icons - in Summe nur zusätzliche Hindernisse mit diesem Release entdecken. Ich verstehe es immer noch nicht - aber egal.

[MartinK.]

@mickym Vielen Dank! Ich konnte die Objekte in der alten Admin Ansicht löschen .... und komischerweise waren meine max. Datensätze in der neuen Ansicht auf 200 heruntergesetzt ! und in der alten sind sie jetzt wieder auf 300! Wenn jetzt meine Zigbee Aktoren wieder zuverlässig funzen - dann fresse ich 'nen Besen ;-)

[mickym]

@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.

[MartinK.]

@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

[mickym]

@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.

[MartinK.]

@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... :-/

[MartinK.]

eigentlich alles ok... Blocklys liefen immer sehr zuverlässig

[mickym]

@martinkOk ACK Flag ist es erst mal nicht

[mickym]

@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.

[MartinK.]

@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.]

@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]

@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]

@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.]

@mickym alles klar! Vielen Dank. Ich werde es mal testen. :-)

[MartinK.]

@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.]

@martink nach der 3. Bewegungserkennung geht der Befehl erst zum Shelly Adapter.... :-/ ! .... und beim nächsten Versuch klappt alles auf anhieb... Ich verstehe es nicht mehr ;-)

[mickym]

@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.

[MartinK.]

@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 :-)