openhabforum.de

Moin,

Zur Präsenzerkennung nutze ich Bluetooth BLE.
OpenHAB mäßig funktioniert seit Monaten alles bestens: u.a. komme ich nach Hause, BLE am Schlüsselbund wird erkannt, OH3 legt ein Switch um -> Musik (Google Assistant) schaltet ein...

In letzter Zeit ist es passiert das, obwohl der Schlüsselbund und ich zuhause sind, die Musik sich "Grundlos" eingeschaltet hat. Ich nehme an das der ESP32, der das Signal scannt, zwischendurch neu bootet. Der ESP32 fährt hoch, erkennt den G-Tag am Schlüsselbund "changed to ON" und OH3 schaltet die Musik ein.

Gibt es eine Möglichkeit das die Rule zusätzlich prüft, wie lange der BLE Switch schon online ist bzw. wie lange er vor der ON-Schaltung auf OFF geschaltet war?
Meine Idee dabei: schaltet der BLE Switch auf ON prüft die Rule, ob er vorher z.B. mindestens 30 min OFF war und schaltet die Musik ein. Hat der ESP32 neu gebootet war er ja nicht mindestens 30 min auf OFF und die Musik bleibt aus...

Der Übersichtlichkeit halber vereinfache ich die Rule hier mal:
sie schaut ob der BLE Switch auf ON wechselt, ob es nachmittags ist (Switch der per "Time cron" geschaltet wird) und ob ich das erste mal am Tag nach Hause komme (Counter der bei jedem ON einmal hochzählt).

Oder gibt es ne schlauere Lösung für mein Problem?
Danke und schönen Sonntagabend noch...

Was läuft auf dem ESP32 für eine Firmware? Ich nutze z.B. auf vielen Geräten Tasmota, das stellt über ein Status Topic auch die Information bereit, wann das letzte Mal gebootet wurde.
Ansonsten könntest Du KuecheGenericMQTT_KuecheBLEgruen auch persistieren (everyChange, nicht mapDB) und dann in der Rule: An Rande: Wozu diese überbordenden Itemnamen?

Moin Udo,

Es hat etwas gedauert mit mir...

udo1toni hat geschrieben: ↑3. Jul 2022 20:23 Was läuft auf dem ESP32 für eine Firmware?

Ich weiß gar nicht wie man die nennt. Ein Sketch, mit der Arduino IDE erstellt, kompiliert und hochgeladen... Arduino Firmware für ESP32?

Ansonsten könntest Du KuecheGenericMQTT_KuecheBLEgruen auch persistieren (everyChange, nicht mapDB)

Das habe ich, in \persistence\influxdb.persist so eingetragen:

und dann in der Rule:

Code: Alles auswählen

if(KuecheGenericMQTT_KuecheBLEgruen.historicState(now.minusSeconds(30)).state != ON)
    // Schalten und Walten...

Habe ich eingefügt, alles ohne Fehlermeldungen!
Und bewirkt? Das der Status des Items sich die letzten 30 sec nicht anders als ON war?
Und diese "30 sec" kommen aus der influxDB?

An Rande: Wozu diese überbordenden Itemnamen?

Du findest einen 32 Zeichen langen Namen für ein Item überbordend? Ach komm!
Nee, in meiner OH2 Installation war ich ziemlich luschig was die Item Namen angeht und habe manchmal selbst nicht mehr durchgesehen. In OH3 wollte ich es besser machen, mit System und so. Merkte dann aber selbst schon das ich ganz leicht übers Ziel hinausgeschossen bin... Allerdings die Namen die gesetzt sind, stehen erst einmal.

Also, wir gehen ja davon aus, dass die Rule getriggert hat, weil KuecheGenericMQTT_KuecheBLEgruen seinen Status auf ON gewechselt hat.
Die Codezeile prüft nun einfach, ob das Item vor 30 Sekunden ebenfalls nicht ON war.
Man könnte den Test noch etwas ausweiten und prüfen, ob das Item vor dem Changed Ereignis (was ja quasi gerade eben erst aufgetreten ist) in einem Zeitraum x seinen Zustand geändert hat, das ginge mit .changedBetween(timestamp1,timestamp2), wobei man dann also z.B. now.minusSeconds(1),now,minusMinutes(10) angeben würde, um zu prüfen, ob im Zeitraum vor einer Sekunde bis vor 10 Minuten ein Changed Ereignis aufgetreten ist. Man kann lediglich nicht mit changedSince arbeiten, denn das ist per Definition immer true, schließlich hat das die Rule erst gestartet.

Gerade fällt mir ein, dass die influxDB eventuell nicht die default Persistence ist. die ganzen persistence Methoden verwenden immer die Default persistence, es sei denn, man gibt die Persistence explizit an, also so: Diese Zeile nimmt ohne wenn und aber influxdb, selbst, wenn das Item gar nicht in influxdb gespeichert wird.

Itemnamen: Es gibt natürlich keine Vorschriften für Itemnamen (außer, dass sie nur Buchstaben des englischen Alphabets, den Unterstrich und die arabischen Ziffern enthalten dürfen und das erste Zeichen zwingend ein Buchstabe sein muss), aber Items sind komplett Hardware unabhängig. Es ist also suboptimal, im Itemanmen einen Bezug zum verwendeten Binding herzustellen, wenn dies nicht zwingend ist. Was interessiert es Dich, ob BLE über MQTT angebunden ist? Das macht nur den Itemnamen länger, ohne dass Du irgendeinen Vorteil daraus hättest. Schlimmer noch, das Wort Kueche kommt zweimal im Itemnamen vor, das ist unnötige Redundanz. KuecheBLEgruen würde vollkommen ausreichen ohne dass dabei irgendwas verloren geht. Den Bezug zu mqtt bekommst Du dennoch, wenn Du Dir das ITem in der Konfiguration ansiehst, denn dort kannst Du ja den Link sehen. Im täglichen Umgang mit dem Item (z.B. beim Erstellen einr Regel) ist das aber nur unnötiger Ballast.

Solche Namenskonventionsfallen habe ich auch schon hinter mir...

udo1toni hat geschrieben: ↑5. Jul 2022 20:36 [...]
prüft nun einfach, ob das Item vor 30 Sekunden ebenfalls nicht ON war.

Moin,

Ich bin die Sache jetzt mal angegangen: unter /settings/services/org.openhab.persistence ist InfluxDB als Persistence Service angehakt und somit wohl mein default Persistence Service.

mein Ziel:
-gruen ist aus
-G-Tag loggt sich ein und schaltet gruen ON
-gruen prüft seinen Status bis zu 10 sec in der Vergangenheit
-war er OFF -> schaltet die Lampe ON
-war er ON -> Abbruch, Lampe bleibt aus


Die Rule ist von allem Schnickschnack befreit, einfach nur:
schaltet mein Item mit dem prägnanten Namen ON wird der Status geprüft, dann, je nachdem, Lampe ein oder aus...
Ich bin begeistert, funktioniert genau wie ich es wollte! War ne Super Idee von Dir und, um das mal explizit zu sagen, die Kompetenz und Hilfsbereitschaft hier im Forum, von Dir... ist mindestens genauso Super!

Solche Namenskonventionsfallen habe ich auch schon hinter mir...

Ich versuche das in Zukunft besser zu machen!

Danke, schönen Samstagabend...