Batteriezustände regelmäßig prüfen

Für welche Projekte verwendet Ihr OpenHAB? Was habt Ihr automatisiert? Stellt eure Projekte hier vor.

Moderator: seppy

Antworten
Benutzeravatar
seppy
Beiträge: 715
Registriert: 24. Sep 2015 20:25
Answers: 3
Wohnort: Bonn

Batteriezustände regelmäßig prüfen

Beitrag von 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
Homematic und HomematicIP über Raspberrymatic (RaspPi 4 4GB) mit 2x HMLAN. Steuerung und Visualisierung durch OpenHAB2 auf RaspPi in Hutschienengehäuse im Sicherungskasten. Rund 100 Aktoren/Sensoren

- Abgesichert durch APC USV
- Bewässerungssteuerung mit Hunter Magnetventilen (HM-LC-Sw4-DR)
- Beleuchtungssteuerung Innen und Aussen (HM-LC-Sw4-DR + HM-LC-SW1-FM + HMW-IO-12-SW7-DR)
- Rolladensteuerung mit Beschattungsautomatik über Temperaturdifferenzsensor (HM-LC-Bl1PBU-FM)
- Wetter und Unwetterinformationen von wunderground
- Benachrichtigung der Bewohner via Pushover
- Multimediawand und Dreambox Steuerung (HM-LC-SW1-FM)
- Heizungssteuerung mit Komfort und Energiesparfunktionen (HM-CC-RT-DN + HM-Sec-SC-2 + HMIP-eTRV-2)
- Werkstatt Kompressorsteuerung (HMW-IO-12-SW7-DR)
- Weihnachtsbeleuchtung außen
- Präsenzerkennung über Geolocation (iCloud Binding), iBeacon und WLAN (Unifi Binding)
- Philips HUE & Tasmota Devices (Tuya) Einbindung

HeHa
Beiträge: 47
Registriert: 13. Nov 2019 17:41
Answers: 1

Re: Batteriezustände regelmäßig prüfen

Beitrag von 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

Benutzeravatar
udo1toni
Beiträge: 2509
Registriert: 11. Apr 2018 18:05
Answers: 11
Wohnort: Darmstadt

Re: Batteriezustände regelmäßig prüfen

Beitrag von 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.

Benutzeravatar
Cyrelian
Beiträge: 474
Registriert: 24. Sep 2015 17:55
Answers: 2

Re: Batteriezustände regelmäßig prüfen

Beitrag von 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

Benutzeravatar
udo1toni
Beiträge: 2509
Registriert: 11. Apr 2018 18:05
Answers: 11
Wohnort: Darmstadt

Re: Batteriezustände regelmäßig prüfen

Beitrag von 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.

;)

Benutzeravatar
Cyrelian
Beiträge: 474
Registriert: 24. Sep 2015 17:55
Answers: 2

Re: Batteriezustände regelmäßig prüfen

Beitrag von Cyrelian »

Hi Udo,

ich erinnere mich, das du so sowas erwähnt hast :D . 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

Benutzeravatar
udo1toni
Beiträge: 2509
Registriert: 11. Apr 2018 18:05
Answers: 11
Wohnort: Darmstadt

Re: Batteriezustände regelmäßig prüfen

Beitrag von udo1toni »

:D

mcdandrew
Beiträge: 83
Registriert: 13. Dez 2018 17:42

Re: Batteriezustände regelmäßig prüfen

Beitrag von 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?

Antworten