Batteriezustände regelmäßig prüfen

[scotty]

@peter-pan

Eine Frage habe ich aber dann doch noch. Kann die Regel vorher irgendwie getestet werden oder muss ich warten, bis ein niedriger Batteriestand erreicht ist?

[PeterA]

Klar geht das.
Entweder Du erstellst ein ungebundenes test Item. Auch als Switch und auch in der entsprechenden Gruppe. Und das fügst Du irgendwo in Deiner Sitemap ein.
Oder Du manipulierst über die RestApi eines der entsprechenden Items.

[peter-pan]

...genau, so wie Peter es beschrieben hat. Oder du setzt einen deiner Batterie-Switches mal auf "OFF", wenn du ihn in der Sitemap definiert hast. Bei Homematic-Items bekommst du eine Fehlermeldung, dass es sich um ein "Nur-Read-Item" handelt und musst es dann wieder auf "ON" setzen. Oder bei einem "AVM-Switch" geht der Switch wieder von allein auf "ON".

Ich habe in der Sitemap einfach das Gruppen-Item definiert.

gbatt.jpg

Ach ja, eine Transformations-Datei hab ich auch noch:

Code: Alles auswählen

ON=Au, au, au
OFF=Alles paletti
-=undefiniert(-)

[scotty]

Danke an euch Beide!

[Tomzk]

Danke für die Antwort, Tom. Die Voraussetzungen wären bei mir erfüllt. Mit dem Telegram Binding habe ich allerdings noch nicht gearbeitet. Wo erfolgt denn die Ausgabe der Message, auf dem Display des Tablets? Hast du vielleicht noch etwas mehr Info?

Schönen Gruß

Ich habe bis jetzt für Mitteilungen nur Telegram genutzt, da ich die Steuerung von Openhab sowieso nur über das Handy mache und in der Regle immer dabei habe.
Aber die Variante der Pushmitteilungen klingt auch interessant. Muss ich mich dazu mal schlau machen und vergleichen was mir besser gefällt. Danke für den Tipp @Udo

Wenn Telegram ein Weg für dich wäre, schau einfach mal in die Binding Dokumentation, finde ist sehr gut beschrieben dort:
https://www.openhab.org/addons/bindings/telegram/
Bei weitern Unklarheiten kann ich dir aber gerne weiterhelfen.

Gruß
Tom

[udo1toni]

Das reicht mir aber völlig. Vielen Dank für den Beitrag.

@udo1toni

Dein Tipp ist so geheim, den kannte sogar ich. Aber mal ehrlich, wie viel gibt er denn einem Anfänger wie mir zum Thema "Push Notification"? Ich halte dich für einen wirklich großen Experten, aber manchmal wirken die Antworten echt demotivierend.

Vielleicht hätte ich das dazu schreiben sollen... Meine Aussage ob der Doku bezog sich hier ausdrücklich auf das Telegram Binding, welches wirklich extrem gut dokumentiert ist.


Gesendet von iPad mit Tapatalk

[zinnik]

Ich hänge mich bei dem Thema ran...

Ich habe einige Xiaomi Temperatur- und Kontaktsensoren im Einsatz.
Diese melden u.a. auch ihren Batteriestatus in Prozent.

Problem allerdings, dass die von Heute auf morgen die Werte nicht mehr melden. Bspw. wird mir in der Sitemap 86% angezeigt (vermutlich der letzte Wert) und dann ist der Sensor tot.
Direkt anfragen kann ich die Sensoren nicht und somit auch nicht in diese Richtung prüfen.
Ich bin mir nicht sicher, aber ich glaube die Sensoren melden nur bei Statusänderungen an Openhab.

Wie könnte ich nun also zyklisch prüfen ob die Sensoren erreichbar sind?

Gibt es denn hierzu auch eine Lösung für Telegram oder Pushover?

[udo1toni]

Die einfachste Variante wäre ein Expiration Timer. Ob das praktikabel ist, kommt dann vor allem auf die Anzahl zu überwachender Sensoren an. Du musst von allen zu überwachenden Sensoren ein verlinktes Item in eine Gruppe packen. Zusätzlich brauchst Du ein Item pro Sensor. Die Namen der Items sollten sich aus den gruppierten Items ableiten lassen. Dann reicht eine Rule für alle Sensoren, in der Form:

Code: Alles auswählen

rule "Sensor Heartbeat"
when
    Member of gHeartbeatIn received update
then
    val strName = trigeringItem.name.split("_").get(1) //gegeben, dass im Itemnamen der Sensorname an zweiter Stelle zwischen Untersrichen steht
    gHeartbeatOut.members.filter[i|i.name.contains(strName)].head.postUpdate(ON)
end

Diese Minirule setzt also jedes Mal, wenn der Sensor einen Wert liefert das passende Item auf ON. Die Itemnamen können lose miteinander verbunden sein, wichtig ist nur, dass es für jedes überwachte Item auch ein Alarmitem gibt.
Der Trick: Dieses Item ist mit einem Expiration Timer versehen. Der Expiration Timer kann pro Item individuell eingestellt werden, man kann also dieselbe Rule für Sensoren verwenden, die einmal in der Minute Daten liefern und andere Sensoren, die nur einmal pro Stunde Daten liefern. Die Expiration wird großzügig etwas länger als die längste zu erwartetende Sendepause gesetzt und endet mit einem postUpdate(OFF) (das wird nur ausgelöst, wenn für Zeit x kein Update rein kam)

Eine zweite Rule übernimmt dann die Alarmierung, in welcher Form auch immer:

Code: Alles auswählen

rule "Alarm Heartbeat"
when
    Member of gHeartbeatOut changed from ON to OFF
then
    logWarn("heartbeat","Sensor {} hat sich schon lange nicht mehr gemeldet!",triggeringItem.label)
end

Im Label des Alarmitems steht dann der passende Sensorname drin

Eine andere Option: Man kann über das Link Profile ein DateTime Item an beliebige Channel verlinken und dort "Zeitstempel bei Aktualisierung" auswählen. Fortan wird in dem DateTime Item also immer der Zeitpunkt der letzten Aktualisierung gespeichert.

Leider ist die Auswertung von DateTime Status nicht sehr komfortabel, und schlimmer, es geschieht nicht automatisch. Man braucht dann also eine Rule, welche zyklisch alle DateTime Items prüft und gegebenenfalls Alarm schlägt. Dafür hat man aber den Zeitstempel der Aktualisierung.

Eventuell könnte man auch beide Verfahren miteinander kombinieren und sich so das ganze Rumgerechne mit Datum und Zeit ersparen...

[zinnik]

Problem bei den Xiaomi Temp Sensoren ist das die Manchmal wirklich nur Daten senden wenn sich auch die Temperatur ändert. Das bedeutet es kann auch mal 2 Tage dauern bis die was senden.

Es gibt aber auch ein Channel mit einem Switch Item jedoch liefert der "Null"

Screenshot (285).png