Batteriezustände regelmäßig prüfen

[seppy]

Hallo Zusammen,
da viele der Sensoren batteriebetrieben sind, ist es wichtig leere Batterien rechtzeitig zu tauschen. Ich habe das für mich mit einer globalen Batteriegruppe gelöst, die regelmäßig geprüft wird:

Code: Alles auswählen

// Alle Batteriezustände
Group gSysBatteryState
	"Gruppe aller Batteriezustände"
	(gSystem)

In dieser Gruppe sind alle Schalter für den Batteriezustand (LOWBAT) MItglied. Hier ein Beispiel:

Code: Alles auswählen

Switch InnenEGWohnzimmerHKTLinksBattery
	"Batterie Status [MAP(battery.map):%s]"
	(gInnenEGWohnzimmerHKTLinks,gSysBatteryState)
	{channel="homematic:HM-CC-RT-DN:6d2469a0:XXX:0#LOWBAT"}

Über eine Regel prüfe ich einmal am Tag alle Mitglieder der Gruppe und lasse mir eine Pushovernachricht schicken, wenn eine Batterie gewechselt werden muss:

Code: Alles auswählen

var String msg = null

/**
 * Batterieüberwachung, wenn Status nicht ok, dann Info
 */
rule "Cron_BatteryCheck"
when
	Time cron  "0 0 8 1/1 * ? *"
then
	logInfo("HomeBox.SystemRules:Cron_BatteryCheck", "Starte Batterie Check")
	gSysBatteryState?.members.forEach[t | 
		if (t.state == ON){
			if (msg === null){
				msg = transform("MAP","devices.map",t.name)  + "\n"
			} else {
				msg = msg + transform("MAP","devices.map",t.name) + "\n"	
			}
		}
		logInfo("HomeBox.SystemRules:Cron_BatteryCheck", t.name + " " + t.state)
	]
	if (msg !== null){
		pushover("Batteriewarnung für die Devices:\n" + msg,1)
		msg = null
	}
end

Grüße,
Seppy

[HeHa]

Hallo Seppy,

genau sowas würde ich auch gerne realisieren da wie du selber festgestellt hast ne Menge Batterien verbaut wurden. Zwar sollen die über ein Jahr halten aber da besteht die Gefahr des Ausfalls und des Vergessens.

Erste Frage:

Kann man die Switch Iteams in mehreren Gruppen Zuordnen ? derzeit sind sie bereits einer Gruppe zugeordnet:

Code: Alles auswählen

// Xiaomi Mi Temperature & Humidity Sensor Jan

Group gXI_MI_TE_HU_Kind_Jan
  "Temperature & Humidity Sensor Jan"
  <temperature>
  (F2_Jan)

Number:Temperature      HT_Temperature_Jan    <temperature>  (gXI_MI_TE_HU_Kind_Jan)     { channel="mihome:sensor_ht:158d0003ce77f8:temperature" }
Number:Dimensionless    HT_Humidity_Jan       <humidity>     (gXI_MI_TE_HU_Kind_Jan)     { channel="mihome:sensor_ht:158d0003ce77f8:humidity" }
Number                  HT_Battery_Jan        <battery>      (gXI_MI_TE_HU_Kind_Jan)     { channel="mihome:sensor_ht:158d0003ce77f8:batteryLevel" }
Switch                  HT_BatteryLow_Jan     <energy>       (gXI_MI_TE_HU_Kind_Jan)     { channel="mihome:sensor_ht:158d0003ce77f8:lowBattery" }

Also das Item was uns interssiert ist ja folgendes:

Code: Alles auswählen

Switch                  HT_BatteryLow_Jan     <energy>       (gXI_MI_TE_HU_Kind_Jan)     { channel="mihome:sensor_ht:158d0003ce77f8:lowBattery" }

kann man das mit einem zusätzlicher Gruppe versehen ? So in etwa:

Code: Alles auswählen

Switch                  HT_BatteryLow_Jan     <energy>       (gXI_MI_TE_HU_Kind_Jan, gBatteryStatus)     { channel="mihome:sensor_ht:158d0003ce77f8:lowBattery" }

Zweite Frage:

Dann hast du zwei MAP Dateien. Die erste im Iteam selber -> Battery.map und die zweite in der Regel -> devices.map. wie sehen die aus?

Gruß Henning

[udo1toni]

Kleiner Verbesserungsvorschlag:

Code: Alles auswählen

//    var String msg = "" // siehe Text

/**
 * Batterieüberwachung, wenn Status nicht ok, dann Info
 */
rule "Cron_BatteryCheck"
when
    Time cron  "0 0 8 * * ?"
then
    logInfo("HomeBox.SystemRules:Cron_BatteryCheck", "Starte Batterie Check")
    // msg = "" // siehe Text
    var String msg = "" // siehe Text
    gSysBatteryState?.members.forEach[t | 
        if (t.state == ON){
            msg = msg + transform("MAP","devices.map",t.name) + "\n"
        }
        logInfo("HomeBox.SystemRules:Cron_BatteryCheck", t.name + " " + t.state)
    ]
    if (msg != "")
        pushover("Batteriewarnung für die Devices:\n" + msg,1)
end

Der Time Cron Trigger ist unnötig kompliziert, das Jahr ist optional, statt 1/1 im Tagfeld kann man auch einfach einen * schreiben.

Die Prüfung auf null bringt gegen über der Prüfung auf "" keine Vorteile, hier ist sie sogar hinderlich. In diesem Fall ist es also besser, den String einfach als leeren String zu definieren. Die Variable wird nur während der Laufzeit der Rule benötigt, es sollte also möglich sein, sie in der Rule zu definieren.
Falls das nicht funktioniert, wäre die bessere Variante, die Variable zwar extern zu definieren, aber zu Beginn der Rule auf "" zu setzen, die Zeilen sind auskommentiert an passender Stelle drin. Einfach überall, wo Siehe Text als Kommentar steht, die Kommentierung umkehren, dann ist die Variable global.

[Cyrelian]

Hi,

kleine Ergänzung von mir, da ich auch Komponenten habe, die keinen Channel "battery_low" Switch haben, sondern "nur" Volt als Number liefern.

Code: Alles auswählen

//-------------  Batterie Check --------------------

rule "Wartung: Batterien"
when
   	Time cron "10 45 9,17 * * ?" or
	Item Wartungs_Trigger received update ON
then
    if (log) logInfo(filename, "Wartung - Batterien läuft...")
    gSysBattery.members.forEach [battery | {
            //if (log) logInfo(filename, "Wartung - Batterie " + battery.label + " Type(" + battery.type + "): " + battery.state)
            if (battery.type == "Number") {
		        if (battery.state <= 2.6) {
                   	if (log) logWarn(filename, "Wartung - Batterie schwach: " + battery.label)
			if (message) sendPushoverMessage(pushoverBuilder(battery.label + " schwach (" + battery.state + "V)"))
                }
            }
            else if (battery.type == "Switch") {
                if (battery.state == ON) {
                    if (log) logWarn(filename, "Wartung - Batterie schwach: " + battery.label)
		    if (message) sendPushoverMessage(pushoverBuilder(battery.label + " schwach"))
                }
            }
        }
    ]
end  

CYA
Cyrelian

[udo1toni]

Ich kann's ja nicht lassen...

Das Konstrukt

Code: Alles auswählen

if(log) logInfo(filename, ...)

ist gegen das System programmiert.

log4j2 ist ein mächtiger Logger, unter anderem bietet er die Option, beliebig viele Logger anzulegen, in allen Einzelheiten zu konfigurieren und zur Laufzeit zu steuern, was geloggt wird.

Die Zeile

Code: Alles auswählen

logInfo("batteries", "Wartung - Batterien läuft...")

zum Beispiel führt nur dann zu einer Logzeile, wenn der Logger org.openhab.model.script.batteries auf DEBUG oder INFO gesetzt ist, nicht aber, wenn er auf WARN, ERROR oder OFF steht. Entsprechendes gilt sinngemäß für logDebug(), logWarn() und logError(), es geht also nicht um die Farbgebung in frontail, sondern um eine feingranulare Steuerung, welche Meldungen ausgegeben werden.

Wenn man möchte, kann man sogar dafür sorgen, dass die Logzeilen (und nur die des batteries Loggers!) in einer anderen *.log Datei landen. Die Umschaltung des Log Levels erfolgt im laufenden Betrieb über die Karaf Konsole und ist sofort wirksam, man muss dazu keine Rules bearbeiten oder gar ein Item dafür definieren, nur um es über openHAB zu steuern.
Falls man den Log Level partout über ein Item steuern möchte, wird es etwas komplizierter, aber man kann die Karaf Konsole durchaus remote scripten

Zusammengefasst: Pro Rule (oder pro Rulethematik, also z.B. alle Rules, die den Batteriestatus betreffen) einen einfachen Loggernamen definieren, nicht pro *.rules Datei. Die Logger erben hierarchisch den gesetzen LEVEL, default ist der Log Level INFO gesetzt. Steuerung, was geloggt wird über die Karaf Konsole gesteuert - jederzeit, zur Laufzeit, über einen Neustart hinaus. Meldungen aufgrund ihres Charakters den verschiedenen Levels zuordnen, nicht für die Farbgebung.

[Cyrelian]

Hi Udo,

ich erinnere mich, das du so sowas erwähnt hast . Du hast natürlich vollkommen recht. Ich war bisher nur zu faul das zu ändern, aber ich werde das in Kürze mal angehen und in allen Rules anpassen bzw. ändern.
Angefangen hatte ich da vor geraumer Zeit schon mal mit....

Code: Alles auswählen

# ----------------------MyLogger----------------------

# Sonos Logger (Rules)
log4j2.logger.Sonos_Rules.name = org.eclipse.smarthome.model.script.Sonos
log4j2.logger.Sonos_Rules.level = INFO
log4j2.logger.Sonos_Rules.additivity = false
log4j2.logger.Sonos_Rules.appenderRefs = Sonos
log4j2.logger.Sonos_Rules.appenderRef.Sonos.ref = SONOS

# Sonos Logger (Binding)
log4j2.logger.Sonos_Binding.name = org.eclipse.smarthome.binding.sonos
log4j2.logger.Sonos_Binding.level = INFO
log4j2.logger.Sonos_Binding.additivity = false
log4j2.logger.Sonos_Binding.appenderRefs = Sonos
log4j2.logger.Sonos_Binding.appenderRef.Sonos.ref = SONOS

# Sonos File appender - Sonos.log
log4j2.appender.Sonos.name = SONOS
log4j2.appender.Sonos.type = RollingRandomAccessFile
log4j2.appender.Sonos.fileName = ${openhab.logdir}/sonos.log
log4j2.appender.Sonos.filePattern = ${openhab.logdir}/sonos.log.%i
log4j2.appender.Sonos.immediateFlush = true
log4j2.appender.Sonos.append = true
log4j2.appender.Sonos.layout.type = PatternLayout
log4j2.appender.Sonos.layout.pattern = %d{dd-MMM-yyyy HH:mm:ss.SSS} [%-5.5p] [%-50.50c] - %m%n
log4j2.appender.Sonos.policies.type = Policies
log4j2.appender.Sonos.policies.size.type = SizeBasedTriggeringPolicy
log4j2.appender.Sonos.policies.size.size = 10MB
log4j2.appender.Sonos.strategy.type = DefaultRolloverStrategy
log4j2.appender.Sonos.strategy.max = 10

# Astro Logger (Rules)
log4j2.logger.Astro_Rules.name = org.eclipse.smarthome.model.script.Astro
log4j2.logger.Astro_Rules.level = INFO
log4j2.logger.Astro_Rules.additivity = false
log4j2.logger.Astro_Rules.appenderRefs = ASTRO
log4j2.logger.Astro_Rules.appenderRef.Astro.ref = ASTRO

# Astro Logger (Binding)
log4j2.logger.Astro_Binding.name = org.openhab.binding.astro
log4j2.logger.Astro_Binding.level = INFO
log4j2.logger.Astro_Binding.additivity = false
log4j2.logger.Astro_Binding.appenderRefs = ASTRO
log4j2.logger.Astro_Binding.appenderRef.Astro.ref = ASTRO

# Astro File Appender - Astro.log
log4j2.appender.Astro.name = ASTRO
log4j2.appender.Astro.type = RollingRandomAccessFile
log4j2.appender.Astro.fileName = ${openhab.logdir}/astro.log
log4j2.appender.Astro.filePattern = ${openhab.logdir}/astro.log.%i
log4j2.appender.Astro.immediateFlush = true
log4j2.appender.Astro.append = true
log4j2.appender.Astro.layout.type = PatternLayout
log4j2.appender.Astro.layout.pattern = %d{yyyy-MM-dd HH:mm:ss.SSS} [%-5.5p] [%-36.36c] - %m%n
log4j2.appender.Astro.policies.type = Policies
log4j2.appender.Astro.policies.size.type = SizeBasedTriggeringPolicy
log4j2.appender.Astro.policies.size.size = 10MB
log4j2.appender.Astro.strategy.type = DefaultRolloverStrategy
log4j2.appender.Astro.strategy.max = 10

THX
Cyrelian

[udo1toni]

[mcdandrew]

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?

[nilsacht]

Hallo zusammen,

erst mal habe ich genau sowas gesucht. Dadurch kann ich nun endlich meine HUE Dimmer überprüfen.

Aber ich habe eine Verständnisfrage und muss daher dieses doch schon recht alte Thema noch einmal aufmachen:
Es wird eine Transformation MAP genutzt (devices.map). Muss diese von mir angelegt werden? Und wenn ja, was muss dort rein?


Vielen Dank
Nils

[udo1toni]

Ist ja schon ein Weilchen her... die devices.map musst Du im Verzeichnis ./transform/ mit exakt diesem Namen selbst erstellen. Sie enthält Wertepaare, mit einem Gleichheitszeichen getrennt. Dabei entspricht der jeweils linke Wert dem Itemnamen und der jeweils rechte Wert dem Text, der ausgegeben werden soll. Also z.B.:

Code: Alles auswählen

Item01=Tischleuchte Wohnzimmer
Item02=Esszimmer Deckenlicht

Im Meldetext will man ja nicht die Itembezeichnungen stehen haben, sondern Klartext Bezeichnungen, darum kümmert sich bei dieser Variante die MAP Transformation.