Batteriestatus von unterschiedlichen Hersteller auslesen

[pi-user]

Ich verwende folgender Code, um den Batteriestatus der Sensoren im Zusammenhang mit dem JeeLink Stick darzustellen.

Code Auswählen Erweitern

#Batteriestatus aller Devices im Raum Zentral anzeigen
define ZE.Batterie readingsGroup .*:[Bb]attery\
.*:[Bb]atteryLevel
attr ZE.Batterie notime 1
attr ZE.Batterie room Zentral
attr ZE.Batterie valueFormat {return "0" if( $VALUE eq "low" );; return "100" if( $VALUE eq "ok" );; return "25" if( $VALUE < 2.1 );; return "50" if( $VALUE < 2.3 );; return "75" if( $VALUE < 2.5 );; return "100"}
attr ZE.Batterie valueIcon {'battery.0' => 'measure_battery_0@red','battery.100' => 'measure_battery_100@green','Battery.0' => 'measure_battery_0@red','Battery.100' => 'measure_battery_100@green','batteryLevel.0' => 'measure_battery_0@red','batteryLevel.25' => 'measure_battery_25@red','batteryLevel.50' => 'measure_battery_50@orange','batteryLevel.75' => 'measure_battery_75@green','batteryLevel.100' => 'measure_battery_100@green'}


Das Ganze funktioniert sehr gut. Ich habe einen neuen Z-Wave Stick zugelegt. Der Batteriestatus eines Z-Wave Sensors wird aber nicht im Raum Zentral angezeigt! Ich dachte, dass der Code alle Sensoren, die eine Variable battery haben auslist!?! Brauche ich für die Z-Wave Sensoren einen neuen Code, um den Batteriestatus auszulesen?

Vielen Dank im Voraus.

[Thorsten Pferdekaemper]

Hi,
wann wird denn das DEF ausgewertet? Vielleicht bekommt die readingsGroup einfach nicht mit, dass da ein neues Device ist. Hast Du mal shutdown restart probiert?
Gruß,
   Thorsten

[pi-user]

Hä! Ich habe gerade beim Z-Wave Sensor nachgeschaut. In der Readings Tabelle existiert kein Attribut namens "battery" aber es gibt ein get battery Feld. Bitte siehe Anhang.

[pi-user]

Die anderen NICHT Z-Wave Sensoren haben in der Tabelle Readings ein Attribut namens battery. Aus diesem Grund funktioniert auch der Code.
Die Z-Wave Sensoren haben in der Tabelle Readings kein Attribut namens battery!?! Wie kann ich sonst den Batteriestatus der Z-Wave Geräte auslesen?

[Thorsten Pferdekaemper]

Hi,
laut Commandref müsste es ein Event battery:... geben. Allerdings ist mir nicht klar, ob das dann auch ein Reading wird. Hast Du zu dem Device ein FileLog und kommt da irgendwann mal ein battery-Event durch?
Wenn nicht: Was genau passiert denn, wenn Du get ... battery machst?
Gruß,
   Thorsten

[MadMax-FHEM]

Die anderen NICHT Z-Wave Sensoren haben in der Tabelle Readings ein Attribut namens battery. Aus diesem Grund funktioniert auch der Code.
Die Z-Wave Sensoren haben in der Tabelle Readings kein Attribut namens battery!?! Wie kann ich sonst den Batteriestatus der Z-Wave Geräte auslesen?

Mach mal ein get batteryState (oder wie das heißt).
Wenn es ein wakeup-Gerät ist, dann kommt der Wert beim nächsten wakeup oder du weckst manuell.

Ich habe ein notify auf wakeup und setze da dann den get batteryState ab, so bekomme (hole) ich mir bei jedem wakeup den aktuellen Batteriestatus meiner ZWave-Geräte.

Bin grad nicht zuhause, drum kann ich's nur "umschreiben"...

Gruß, Joachim

[pi-user]

Wenn ich get ausführe, dann bekommt ich eine Meldung. Die Meldung befindet sich als Bild im Anhang.

[pi-user]

Hallo Joachim,

das hört sich gut. Kannst Du mir den Codeschnipsel zuschicken, wenn Du zuhause bist? Danke.

[MadMax-FHEM]

Wenn ich get ausführe, dann bekommt ich eine Meldung. Die Meldung befindet sich als Bild im Anhang.

Also wakeup-Gerät.
Entweder manuell wecken oder halt warten bis zum nächsten Wakeup.

Dann sollte auch ein entsprechendes Reading da sein.

Gruß, Joachim

[MadMax-FHEM]

Hallo Joachim,

das hört sich gut. Kannst Du mir den Codeschnipsel zuschicken, wenn Du zuhause bist? Danke.

Jep, klar...
...kann aber spät werden, bin unterwegs...

Gruß, Joachim

[MadMax-FHEM]

Hi,

so jetzt.

Hier das notify:

Code Auswählen Erweitern

define nZWaveGetBattery notify .*.wakeup:.notification get $NAME battery

Allerdings sendet bzw. ist das Reading bei ZWave (zumindest bei meinen) dann gleich mit %.

Andere (z.B. Homematic) haben bei battery "ok" oder "low" bzw. die aktuell noch vorhandenen Batteriespannungen...

Für eine einheitliche Anzeige muss da halt u.U. noch etwas angepasst werden...

Gruß, Joachim

[KernSani]

@pi-user: Mir scheint das eine sehr ZWAVE-spezifische Diskussion zu werden, daher würde ich dich bitten, das Thema ins entsprechende Unterforum  zu verschieben (Button ganz links unten).

Danke,

Grüße,

Oli

[pi-user]

Danke Joachim. 

[pi-user]

In der Logdatei steht nun nach dem Wakeup Notify der Batteriestatus. Wie kann ich den Batteriestatus in Fhem grafisch darstellen bzw. eine Benachrichtigung rausschicken, wenn der Batteriestatus unter 20% ist? Muss ich dafür ein Skript schreiben?

Danke.

[pi-user]

Hallo Joachim,

wie kommst Du an Batteriestatus-Wert bei Deinem Code? Wie kann man den Batteriestatus in eine Variable speichern?

Danke.

[MadMax-FHEM]

Hallo Joachim,

wie kommst Du an Batteriestatus-Wert bei Deinem Code? Wie kann man den Batteriestatus in eine Variable speichern?

Danke.

Da ich wieder unterwegs bin wieder mal nur beschreibend:

ich habe ein notify auf .*battery.* in etwa so oder so ähnlich:

Code Auswählen Erweitern

define nCalculateAndStoreBatteryStates notify .*battery.* {my_CalculateAndStoreBatteryStates($NAME)}

(ich übergebe auch gleich noch irgendwie den Readingnamen [müsste aber nachschauen wie: $READING ??] und vielleicht auch den Wert)

Dann habe ich eben eine Sub in myUtils:

Code Auswählen Erweitern


my_CalculateAndStoreBatteryStates($$$) # wieviele Parameter es nun sind weiß ich grad nicht ;)
{


}


Wo ich dann abfrage, ob das Reading im Event battery oder batteryLevel (glaube ich heißt es bei Homematic), da ich Homematic Geräte habe, die sowohl battery (ok/low) als auch die aktuelle Batteriespannung melden.
Bei diesen gibt es auch ein Register wo das Batterielimit drin steht.

Dann frage ich noch den Typ ab, also ob Homematic oder ZWave und wenn Homematic, ob es vom Typ eines ist, was auch batteryLevel hat, dann nehme ich das und nicht den battery der ja auch kommt...
...bei diesen ignoriere ich dann den "battery".

Bei HM-Geräten, die nur "battery" liefern (z.B. Fensterkontank):
Bei battery = ok setze ich ein entsprechendes Reading in einem Dummy auf 100, bei low auf 0.

Bei HM-Geräten die auch den batteryLevel liefern (z.B. Wandthermostat):
Mit den batteryLevel "berechne" ich einen groben Prozentwert (voll: ca. 3.0V - 3.2V und "leer" ist dann das Limit aus dem Register) und trage den ebenfalls als Reading in den Dummy ein.

Bei ZWave nehme ich die Prozent weg und schreibe nur den Wert (ist ja bereits "Prozent") ebenfalls in den Dummy.

Den Dummy nutze ich dann zur Anzeige mit unterschiedlichen Icons und Farben (je nach "Füllstand")...

Geht sicher auch "einfacher" aber so habe ich das gelöst...

Ist aber halt sehr spezifisch für meine Gerätelandschaft...

Du müsstest halt festlegen wie du dann evtl. "Berechnungen" in der myUtils-Sub machst/machen müsstest...

EDIT: wenn ein gewisser Level unterschritten wird (bzw. von ok auf low), dann schicke ich eine Nachricht, dass es bald Zeit zum Wechseln ist.

Gruß, Joachim

[pi-user]

Hallo Joachim,

ich danke Dir für die Infos. Ich habe nun die Richtung, die ich gehen kann.

[pi-user]

Nach einem get Befehl ist auf einmal das Attribut battery in der Readings Tabelle aufgetaucht. Hä!

Ich gehe davon aus, dass der Wert von diesem Attribut (battery) sich nicht mehr ändert bis ich wieder

Code Auswählen Erweitern

get <Device> battery aufruft! Ist das korrekt?

Danke.

[Thorsten Pferdekaemper]

Nach einem get Befehl ist auf einmal das Attribut battery in der Readings Tabelle aufgetaucht. Hä!

Das war zu erwarten, wenn man mal Antwort #5 und Antwort #8 aufmerksam liest.
Gruß,
   Thorsten

[MadMax-FHEM]

Nach einem get Befehl ist auf einmal das Attribut battery in der Readings Tabelle aufgetaucht. Hä!

Ich gehe davon aus, dass der Wert von diesem Attribut (battery) sich nicht mehr ändert bis ich wieder

Code Auswählen Erweitern

get <Device> battery aufruft! Ist das korrekt?

Danke.

Korrekt.

Der Wert wird bei diesem ZWave Gerät nur geliefert, wenn gefragt wird und geantwortet auf eine Frage wird erst beim Aufwachen (daher ja auch das Popup beim Absetzen des get, dein Screenshot).

Daher ja der "Trick" auf das Aufwachen zu lauschen (notify) und dann die Frage zu stellen solange das Gerät noch wach ist

Wie häufig das Gerät aufwacht kann man sich auch holen/auslesen, wenn es noch kein Reading gibt: get Befehl absetzen und warten oder aufwecken...
...den Wert kann man auch verändern.
Aber je häufiger wach desto kürzer hält die Batterie, eh klar...

Und das Attribut battery ist ein Reading

Daher gibt es (bei Änderung) auch einen Event und daher kann dann das andere notify auf .*battery.* reagieren und tun was es tun soll...

Das war zu erwarten, wenn man mal Antwort #5 und Antwort #8 aufmerksam liest.
Gruß,
   Thorsten

Korrekt!


Gruß, Joachim

[pi-user]

Zuerst vielen Dank für die Antworten. Ich werde aber mein notify direkt an diesem Z-Wave Gerät binden. Wenn ich einfach

Code Auswählen Erweitern

define NotifyName notify .*battery.*

aufrufe, dann weiß ich doch nicht welches Gerät? Ich habe auch andere NICHT Z-Wave Sensoren, die ein battery Attribut haben.

Also, so wird es aussehen:

Code Auswählen Erweitern

define EingangstuerBatteryState notify Eingangstuer:wakeup:.notification get Eingangstuer battery {\

# Hier kann ich den neuen Wert (Batteriestatus) aus der Reading Tabelle lesen.
}

Danke.

[MadMax-FHEM]

ACHTUNG:

du musst zwei Sachen auseinander halten:

1. Notify auf wakeup. "define nZWaveGetBattery notify .*.wakeup:.notification get $NAME battery" Das sollte eigentlich nur für ZWave passen, da andere Geräte andere Events erzeugen (aber besser mal prüfen). Damit holst du dir immer den aktuellen Batteriezustand von deinen ZWave-Geräten.

2. Notify auf *.battery.* mache ich deshalb, weil ich dann in meiner Sub die battery-Werte aller Geräte bekomme und dann wie geschrieben halt je nach Gerät/Typ etc. verschiedene "Berechungen" durchführe und entsprechend die Ergebnisse dann pro Gerät genau eines in einen Dummy schreibe...

Ansonsten musst du ja/halt für jedes Gerät ein )(oder zwei) passendes Notify machen und evtl. auch eine "Funktion" wo dann entsprechend "gerechnet" wird.

Wenn dir die "%" nichts ausmachen und dich nicht stören, reicht auch das Notify zum Abrufen des Batteriewertes...
...das andere mache ich ja nur, damit alle Geräte die ich habe eine "vergleichbare Anzeige" bzgl. Batteriewert haben...

...und ich eine NAchricht schicken kann, wenn etwas unterschritten wird.

Gruß, Joachim

[Thorsten Pferdekaemper]

Hi,
könnte man das "get battery" nicht auch ganz banal mit einem "at" machen? Ich nehme mal an, dass diese Geräte alle paar Minuten aufwachen, aber so oft braucht man den Batteriezustand nicht. ...also ein "at +*01:00:00..."?
Gruß,
   Thorsten

[MadMax-FHEM]

Hi,
könnte man das "get battery" nicht auch ganz banal mit einem "at" machen? Ich nehme mal an, dass diese Geräte alle paar Minuten aufwachen, aber so oft braucht man den Batteriezustand nicht. ...also ein "at +*01:00:00..."?
Gruß,
   Thorsten

Im Prinzip schon aber zumindest bei den ZWave Geräten die ich so habe sind die wakeup-Intervalle schon eher größer:

86400 Sekunden -> 24h

21600 Sekunden -> 6h

Aber ginge auch, die Antwort kommt halt erst beim nächsten Wakeup.
Ein Auslösen reicht (zumindest soweit mir bekannt und ich probiert habe, eben noch mal) nicht...

Ich hab's für ZWave halt mal wo gelesen und es tut

Hauptsächlich habe ich Homematic...
...bei ZWave bin ich froh, wenn's läuft...

Gruß, Joachim

[Thorsten Pferdekaemper]

Im Prinzip schon aber zumindest bei den ZWave Geräten die ich so habe sind die wakeup-Intervalle schon eher größer:

Ok, ich bin da von so etwas wie den HM-Thermostaten, also wenige Minuten, ausgegangen. Bei den großen Intervallen ist natürlich ein notify besser.
Gruß,
   Thorsten

[pi-user]

Ich habe mir jetzt folgendes vorgenommen:

1. Ich werde auf wakeup:.notification reagieren. Ich gehe davon aus, dass nach dem Notification der Wert battery sofort in der Reading Tabelle aktualisiert wird! Vielleicht sollte ich ein sleep einbauen bevor ich den Wert aus der Reading Tabelle auslese!
2. Ich werden den Wert battery in der Tabelle Reading auslesen, da der battery Wert aktualisiert wurden ist. Und fertig oder?

[MadMax-FHEM]

Zu 1.: nur, wenn du dann im notify den "get Gerät battery" absetzt (wie in meinem notify von weiter vorher). Der get aktulaisiert den Wert. Sleep? Auslesen wozu? Der Wert steht doch dann im Reading battery des jeweiligen Gerätes das den notify getriggert hat und somit für den der get abgesetzt wurde.

Zu 2.: ich weiß nicht was du meinst. Warum (noch mal) auslesen? Siehe 1.

Noch mal:

wenn du nur willst, dass das Reading battery auch bei deinen ZWave Geräten kommt und aktualisiert wird (von Zeit zu Zeit), dann reicht das notify mit dem get.
Alternativ geht auch das von Thorsten vorgeschlagene at, also einfach ab und an den get battery absetzen.
Die Antwort kommt halt dann nicht sofort wenn der at den get Befehl absetzt sondern halt wenn das Gerät aufwacht.
Bei der Variante mit dem notify auf wakeup kommt die Antwort quasi sofort, da das Gerät ja (noch) wach ist...

Allerdings (zumindest) bei mir steht dann im Reading battery halt z.B. 100% also inkl. dem %-Zeichen. Und das wollte ich nicht, daher der notify auf .*battery.* wo ich dann bei ZWave eben das %-Zeichen entferne (ja geht auch anders aber nachdem ich die Funktion schon mal hatte mache ich das so). Und für meine Homematic-Geräte "berechne" ich halt Prozentangaben damit ich das für alle Geräte einheitlich habe...
Und wenn bestimmte Dinge gegeben sind schicke ich eine entsprechende Nachricht etc.

Wenn dich das %-Zeichen nicht stört und dir nur wichtig ist von allen (bzw. in dem Fall ZWave) Geräten das Reading battery zu haben, dann reicht das eine notiy auf wakeup inkl. dem get battery.

Gruß, Joachim

[MadMax-FHEM]

Wo gibst du das denn ein und wie?

Warum sleep und auslesen?

Wenn du mit dem Wert arbeiten willst, dann mach doch einfach ein notify auf den battery Event, dann ist auch sicher, dass der Wert den du willst da ist...

Du musst auch deinen notify auf wakeup anpassen, dass er auch nur bei diesem Gerät triggert.

Aktuell frägst du bei jedem Wakeup von egal welchem Gerät genau nur bei WD.Eingangstuer nach battery ohne zu wissen ob das Gerät überhaupt wach ist (weil ja vielleicht der wakup von einem ganz anderen Gerät kam).

Was gefällt dir an meinem Notify nicht?
Das frägt immer für das passende (gerade aufgewachte) Gerät nach battery...

Eventuell zuerst mal ein wenig in notify etc. einlesen!?

Gruß, Joachim

[pi-user]

>Zu 1.: nur, wenn du dann im notify den "get Gerät battery" absetzt (wie in meinem notify von weiter vorher). Der get aktulaisiert den Wert. Sleep? Auslesen wozu? Der Wert steht doch dann im Reading battery >des jeweiligen Gerätes das den notify getriggert hat und somit für den der get abgesetzt wurde.

OK. Genau das möchte ich doch tun. Also, Reading battery wird nach jedem get aktualisiert. Soweit so gut. Jetzt möchte ich den Reading battery Wert auslesen.

Es funktioniert so nicht. Ich kann die Datei fhem.cfg nicht speichern, da ich eine Fehlermeldung belommen: Unknown command }, try help.

Code Auswählen Erweitern

define EingangstuerBatteriestatus notify Eingangstuer.*:wakeup.* get WD.Eingangstuer battery {\

     $wert = ReadingsVal("WD.Eingangstuer ", "battery", "-1")
}

Sorry, aber ich stehe gerade wirklich auf dem Schlauch! Ich möchte nur den Wert mit % in $wert speichern. Mehr möchte ich nicht.

Danke.

[DeeSPe]

Anbei mal meine DEF.
Es werden Geräte mit prozentualem Batteriewert ausgewertet und Geräte mit Batteriewerten "ok/low".

Code Auswählen Erweitern

define n_battery_msg notify .*:battery:.* {\
  fhem "msg ACHTUNG!!! Die Batterie von ".AttrVal($NAME,"alias",$NAME)." geht zur Neige ($EVENT)!"\
    if (($EVTPART1 =~ /^([a-z]+)$/ && $1 !~ /ok/)\
    || ($EVTPART1 =~ /^(\d{1,3})%$/ && $1 < 50))\
}

So bekomme ich eine Nachricht wenn der Batteriewert Text und was anderes als "ok" ist, oder wenn der Batteriewert ein Prozentwert und unter 50 ist.

Besser wäre natürlich dann ein Custom Reading anzulegen welches auf "lowBat" geht. Auf dieses dann das notify zum Versenden der msg. Das hätte den Vorteil dass die Nachrichten nur 1x pro Gerät rausgehen und nicht bei jedem Batterieabfragen.

Gruß
Dan

[MadMax-FHEM]

Hi Dan,

jep aber er muss ja erst mal den aktuellen Wert battery bekommen, ist bei ZWave nicht wie bei Homematic, dass die immer automatisch kommen.

@pi-user: was meinst du immer mit speichern? Wenn der Wert beim Wakeup per get battery geholt wird, dann wird er doch direkt im Reading battery beim Gerät gespeichert. Ich weiß nicht so recht was du genau willst. Wenn das Reading dann gesetzt ist kannst du ja mit beispielsweise dem was Dan vorgeschlagen hat (oder etwas anderm oder auch gar nichts) weiter machen...

Gruß, Joachim

[Thorsten Pferdekaemper]

Es funktioniert so nicht. Ich kann die Datei fhem.cfg nicht speichern, da ich eine Fehlermeldung belommen: Unknown command }, try help.

Code Auswählen Erweitern

define EingangstuerBatteriestatus notify .*:wakeup.* get WD.Eingangstuer battery {\

     $wert = ReadingsVal("WD.Eingangstuer ", "battery", "-1")
}

Sorry, aber ich stehe gerade wirklich auf dem Schlauch! Ich möchte nur den Wert mit % in $wert speichern. Mehr möchte ich nicht.

Das, was Du da versuchst, klappt aus mehreren Gründen nicht:

• Man kann nicht so einfach einen FHEM-Befehl mit Perl-Coding mischen.
• $wert sollte auch deklariert werden, denke ich.
• Du machst mit $wert nacher nichts. Wofür also das ganze?
• Wahrscheinlich triggert das get nur den Update des battery Readings. Der Update selbst passiert dann danach.

Du solltest diese beiden Dinge als komplett unabhängig voneinander betrachten:

• Das notify für's get battery
• Das Auslesen des battery-Readings

Also Du definierst Dein notify einfach so ohne den Kram in {}:

Code Auswählen Erweitern


define EingangstuerBatteriestatus notify .*:wakeup.* get WD.Eingangstuer battery

Ansonsten tust Du einfach so, als ob das Device WD.Eingangstuer schon immer ein Reading battery gehabt hat und auch schon immer battery-Events geliefert hat. Anders gesagt: Jetzt hast Du die Voraussetzungen wie bei jedem anderen Device, das ein battery Reading hat.
Wahrscheinlich musst Du dafür sogar gar nichts machen, da Du anscheinend schon einen allgemeinen Mechanismus dafür gebaut hast.
Gruß,
   Thorsten

[DeeSPe]

Hi Dan,

jep aber er muss ja erst mal den aktuellen Wert battery bekommen, ist bei ZWave nicht wie bei Homematic, dass die immer automatisch kommen.

Klar, hattest Du ja erklärt wie das geht.
Ich mache das im Prinzip genauso:

Code Auswählen Erweitern

defmod n_Sensors_wakeup notify .*:wakeup.* {fhem "get $NAME battery" if (ReadingsAge($NAME,"battery",10)>2760)}

So werden die Batteriewerte geholt wenn das Reading älter als 46 min ist. Somit kann ich sicher sein mindestens 1x pro Stunde einen Wert zu bekommen, da mein Wake Interval auf 900 steht.

Gruß
Dan

[MadMax-FHEM]

Du solltest diese beiden Dinge als komplett unabhängig voneinander betrachten:

• Das notify für's get battery
• Das Auslesen des battery-Readings

Also Du definierst Dein notify einfach so ohne den Kram in {}:

Code Auswählen Erweitern


define EingangstuerBatteriestatus notify .*:wakeup.* get WD.Eingangstuer battery

Ansonsten tust Du einfach so, als ob das Device WD.Eingangstuer schon immer ein Reading battery gehabt hat und auch schon immer battery-Events geliefert hat. Anders gesagt: Jetzt hast Du die Voraussetzungen wie bei jedem anderen Device, das ein battery Reading hat.
Wahrscheinlich musst Du dafür sogar gar nichts machen, da Du anscheinend schon einen allgemeinen Mechanismus dafür gebaut hast.
Gruß,
   Thorsten

Jep, darauf will ich die ganze Zeit schon raus (und so mache ich es ja auch) und Dan auch (bis auf das get battery, da das ja ZWave-spezifisch ist)...

EDIT: also sogar inkl. dem get battery Ok, ich lasse die Wakeup-Intervalle wie sie sind...

Oder man muss nach dem notify mit get battery gar nichts machen weil ja dann das Reading battery da ist und auch (bei jedem Wakup, hängt halt vom Wakeup-Intervall ab) aktualisiert wird.

(Und vielleicht ja bereits andere Mechanismen da sind sie bereits was mit vorhandenen und sich aktualisierenden battery Readings machen)

Gruß, Joachim

[pi-user]

Dieser Code ist an keinem Gerät gebunden. Mit anderen Worten: Wenn ein zweites Z-Wave Gerät (z.B. Fenster Sensor) ein wakeup Notification auslöst, dann wird get WD.Eingangstuer battery ausgelöst.

Code Auswählen Erweitern

define EingangstuerBatteriestatus notify .*:wakeup.* get WD.Eingangstuer battery

Vielleicht kann man das Ganze so an einem Gerät binden, falls mein Code richtig ist:

Code Auswählen Erweitern

define EingangstuerBatteriestatus notify WD.Eingangstuer.*:wakeup.* get WD.Eingangstuer battery

>Wenn der Wert beim Wakeup per get battery geholt wird, dann wird er doch direkt im Reading battery beim Gerät gespeichert.
@Joachim: Genau das möchte ich auch tun, aber die Klammen {} sind doch notwendig! Wie kann ich sonst sofort nach dem notify .*:wakeup den Wert mit ReadingsVal abfragen. Ohne Klammen sieht so aus:

Code Auswählen Erweitern

define EingangstuerBatteriestatus notify WD.Eingangstuer.*:wakeup.* get WD.Eingangstuer battery
ReadingsVal("WD.Eingangstuer ", "battery", "-1")

So, wenn ich das Ganze ohne Klammen schreibe, dann werden diese zwei Zeilen unabhängig voneinander aufgerufen. Das Ganze ist vergleichbar mit einer if Bedingung:

Richtig:

if(blabla)
{
     funktionXYZ();
}

Falsch:
if(blabla)

funktionXYZ();

Ich möchte direkt nach dem wakeup notiy bzw. get device battery  den Reading battery Wert auslesen.

[Thorsten Pferdekaemper]

Ich möchte direkt nach dem wakeup notiy bzw. get device battery  den Reading battery Wert auslesen.

Hast Du meinen Beitrag nicht gelesen oder nicht verstanden?
Warum willst Du denn den Wert auslesen? Was machst Du dann damit?
Gruß,
    Thorsten

[pi-user]

Hallo Thorsten,

sorry, es sieht so aus, dass ich wirklich auf dem Schlauch stehe.

Ich möchte nur nach dem wakeup notify sofort den Wert von battary aus der Tabelle Reading auslesen und nicht mehr. Ich möchte aber den Wert nur dann lesen, wenn ein wakeup ausgelöt wurde. Aus diesem Grund sind die Klammen doch da.

Also so oder nicht?

Code Auswählen Erweitern

define EingangstuerBatteriestatus notify WD.Eingangstuer.*:wakeup.* get WD.Eingangstuer battery {\
   
{if (ReadingsVal("WD.Eingangstuer ", "battery", "-1")) eq "blabla")\
  {fhem ("Tue etwas")}\
}


[MadMax-FHEM]

Dann nimm doch einfach (wie schon mehrfach genannt) einen weiteren notify auf den battery Event.

Denn dann ist sicher, dass der aktualisierte Wert auch da ist ansonsten ist das ja nicht zuverlässig der Fall sondern nur (sehr) wahrscheinlich so.
Ein sleep ist ja auch nix gescheites.

Und dann wieder die Frage: WAS willst du denn dann mit dem Wert weiter tun??

Gruß, Joachim

[DeeSPe]

Hallo Thorsten,

sorry, es sieht so aus, dass ich wirklich auf dem Schlauch stehe.

Ich möchte nur nach dem wakeup notify sofort den Wert von battary aus der Tabelle Reading auslesen und nicht mehr. Ich möchte aber den Wert nur dann lesen, wenn ein wakeup ausgelöt wurde. Aus diesem Grund sind die Klammen doch da.

Also so oder nicht?

Code Auswählen Erweitern

define EingangstuerBatteriestatus notify WD.Eingangstuer.*:wakeup.* get WD.Eingangstuer battery {\
   
{if (ReadingsVal("WD.Eingangstuer ", "battery", "-1")) eq "blabla")\
  {fhem ("Tue etwas")}\
}


battery im wakeup notify zu verarbeiten ist kompletter Blödsinn.
Dort sagst Du ja nur dass Du battery haben willst, was Dir aber nicht sagt wann das Reading gesetzt wird. Das kann sofort sein, evtl. in 2-3 Sekunden, vielleicht aber auch erst beim nächsten wakeup.
Es kann nur mit 2x notify gehen. Eines für das wakeup und eines für battery.

Gruß
Dan

[Thorsten Pferdekaemper]

Also so oder nicht?

Nein, so:

Code Auswählen Erweitern


define EingangstuerBatteriestatus notify WD.Eingangstuer.*:wakeup.* get WD.Eingangstuer battery
define EingangstuerBatteriestatus notify WD.Eingangstuer.*:battery.* Tue etwas mit [WD.Eingangstuer:battery]

oder auch

Code Auswählen Erweitern


define EingangstuerBatteriestatus notify WD.Eingangstuer.*:wakeup.* get WD.Eingangstuer battery
define EingangstuerBatteriestatus notify WD.Eingangstuer:battery.blabla Tue etwas mit [WD.Eingangstuer:battery]

Gruß,
   Thorsten

[pi-user]

Hallo Joachim,

ich werde zuerst das Zeichen % entfernen und anschließend damit arbeiten. Z.B. wenn der Wert kleine 20 ist, dann sende eine Benachrichtigung und etc.

>Dann nimm doch einfach (wie schon mehrfach genannt) einen weiteren notify auf den battery Event.
Acho, also ein notify auf das Attribut battary aus der Tabelle Reading. Das heißt, wenn der Wert Reading battary durch get aktualisiert wird, wird ein weiteres on-change Event in der Tabelle Reading ausgelöst. Ist das korrekt?

[pi-user]

Ich danke Euch wirklich vielmals für die Hilfe.  Ich werde morgen das Ganze testen und Euch Bescheid sagen.

Vielen Dank.

[DeeSPe]

ich werde zuerst das Zeichen % entfernen und anschließend damit arbeiten. Z.B. wenn der Wert kleine 20 ist, dann sende eine Benachrichtigung und etc.

Schon mal meine Antwort genauer betrachtet?
Mein notify macht (auch) genau das!

Es werden Geräte mit prozentualem Batteriewert ausgewertet und Geräte mit Batteriewerten "ok/low".

Code Auswählen Erweitern

define n_battery_msg notify .*:battery:.* {\
  fhem "msg ACHTUNG!!! Die Batterie von ".AttrVal($NAME,"alias",$NAME)." geht zur Neige ($EVENT)!"\
    if (($EVTPART1 =~ /^([a-z]+)$/ && $1 !~ /ok/)\
    || ($EVTPART1 =~ /^(\d{1,3})%$/ && $1 < 50))\
}

Gruß
Dan

[MadMax-FHEM]

Hallo Joachim,

ich werde zuerst das Zeichen % entfernen und anschließend damit arbeiten. Z.B. wenn der Wert kleine 20 ist, dann sende eine Benachrichtigung und etc.

>Dann nimm doch einfach (wie schon mehrfach genannt) einen weiteren notify auf den battery Event.
Acho, also ein notify auf das Attribut battary aus der Tabelle Reading. Das heißt, wenn der Wert Reading battary durch get aktualisiert wird, wird ein weiteres on-change Event in der Tabelle Reading ausgelöst. Ist das korrekt?

Naja so ähnlich.

Aber die Attribute sind Readings und das was im System "rumgeht" sind Events.

Daher wäre es wohl sinnvoll sich mit diesen Basics auseinanderzusetzen, dann ist leichter zu verstehen wie das dann so gehen kann...
...und wovon wir sprechen.

Grob (für diesen Fall) in etwa (vereinfacht):

das Gerät wacht auf, das bekommt das ZWave-Modul mit und es wird ein Event (wakeup...) erzeugt.

Daraufhin löst das passende notify aus (das welches halt auf wakeup "hört") und setzt den get-Befehl an das Gerät ab.

Normalerweise kommt die Antwort wenn das Gerät aufwacht. Aber da es ja gerade (noch) wach ist schickt es die Antwort gleich.

Das wird dann vom ZWave Modul empfangen und das Reading battery mit dem neuen Wert aktualisiert (der neue Wert steht dann nach/bei der Antwort [wann immer die dann tatsächlich kommt] im Reading battery OHNE dass irgendwer was abfragen und speichern muss).

Es gibt dann eben ein neues Event bzgl. des neuen battery Wertes.
Daraufhin wird dann das notify bzgl. battery aktiviert (also das welches auf battery "hört") und tut was immer dort eben konfiguriert wurde.
Z.B. eben eine Sub in myUtils (woe bei mir) oder halt direkt diverse Dinge wie bei Dan...

Mit Dingen wie event-on-change-reading etc. lässt sich dann noch beeinflussen wann Events gesendet werden oder auch nicht -> ebenfalls Basics!
(Und das sind dann Attribute)

Gruß und viel Erfolg, Joachim

[pi-user]

Hallo zusammen,

es funktioniert endlich.  Ich danke Euch.

So sieht es vorerst aus:

99_myUtils.pm:

Code Auswählen Erweitern

sub batteriestatus($) {
  my ($batteryState) = @_; 
  #Hier arbeite ich mit $batteryState weiter.
}

fhem.cfg:

Code Auswählen Erweitern

define EingangstuerBatteriestatusWakeup notify WD.Eingangstuer.*:wakeup.* get WD.Eingangstuer battery;;
define EingangstuerBatteriestatus notify WD.Eingangstuer:battery.* {batteriestatus(ReadingsVal('WD.Eingangstuer','battery',''))}

Das blöde ist, dass der Sensor zu viel Saft von der Batterie abzieht! Der Sensor ist nur eine Woche alt und heute steht der Batteriestatus auf 94%. Also 6% pro Woche!?! Das ist echt übel. Das Wakeup Interval steht auf 21600 (6 Stunden). Soll ich lieber das Intervall auf 24 Stunden anpassen, damit die Batterie länger am Leben bleibt?

[Thorsten Pferdekaemper]

Hallo zusammen,Der Sensor ist nur eine Woche alt und heute steht der Batteriestatus auf 94%. Also 6% pro Woche!?! Das ist echt übel.

Bist Du Dir sicher, dass man davon ausgehen kann, dass das linear mit der Zeit geht? Ich würde nicht davon ausgehen.
Gruß,
   Thorsten

[pi-user]

Wer weiß das schon?   

[krikan]

Das blöde ist, dass der Sensor zu viel Saft von der Batterie abzieht! Der Sensor ist nur eine Woche alt und heute steht der Batteriestatus auf 94%. Also 6% pro Woche!?! Das ist echt übel. Das Wakeup Interval steht auf 21600 (6 Stunden). Soll ich lieber das Intervall auf 24 Stunden anpassen, damit die Batterie länger am Leben bleibt?

Behaupte, dass es keine gute Idee ist, ZWave Wake-Up Devices regelmäßig zu pollen und derartig niedrige Wakeup Intervalle (6 Stunden) einzustellen. Selbst 24 Stunden ist in vielen Fällen meiner Meinung nach unnötig.
Man kann (fast) immer die Geraete so konfigurieren, dass die wichtigen Daten automatisch ohne Pollen kommen und persönlich kenne ich kein wakeup-Gerät, das sich nicht automatisch bei zu Ende gehender Batterie penetrant und frühzeitig meldet...

Was ist das für ein Sensor?

Gruß, Christian

[MadMax-FHEM]

Hallo zusammen,

es funktioniert endlich.  Ich danke Euch.

So sieht es vorerst aus:

99_myUtils.pm:

Code Auswählen Erweitern

sub batteriestatus($) {
  my ($batteryState) = @_; 
  #Hier arbeite ich mit $batteryState weiter.
}

fhem.cfg:

Code Auswählen Erweitern

define EingangstuerBatteriestatusWakeup notify WD.Eingangstuer.*:wakeup.* get WD.Eingangstuer battery;;
define EingangstuerBatteriestatus notify WD.Eingangstuer:battery.* {batteriestatus(ReadingsVal('WD.Eingangstuer','battery',''))}

Das blöde ist, dass der Sensor zu viel Saft von der Batterie abzieht! Der Sensor ist nur eine Woche alt und heute steht der Batteriestatus auf 94%. Also 6% pro Woche!?! Das ist echt übel. Das Wakeup Interval steht auf 21600 (6 Stunden). Soll ich lieber das Intervall auf 24 Stunden anpassen, damit die Batterie länger am Leben bleibt?

Gratuliere!

Evtl. eigene Funktionen/Subs eindeutig kennzeichnen, also my_ davor.
Nicht dass es mal Konflikt mit "System-Funktionen" (von fhem etc.) gibt...

Und beim Battery-Notify ist es eigentlich unnötig den Wert per ReadingsVal abzufragen, ein $EVENT oder je nachdem was im Event kommt auch ein $EVTPART0, $EVTPART1, ...

Wenn du den Wert in der Funktion/Sub ohne %-Zeichen haben willst (oder generell ohne Einheit), dann geht auch ReadingsNum...

Gruß, Joachim

[MadMax-FHEM]

Behaupte, dass es keine gute Idee ist, ZWave Wake-Up Devices regelmäßig zu pollen und derartig niedrige Wakeup Intervalle (6 Stunden) einzustellen. Selbst 24 Stunden ist in vielen Fällen meiner Meinung nach unnötig.
Man kann (fast) immer die Geraete so konfigurieren, dass die wichtigen Daten automatisch ohne Pollen kommen und persönlich kenne ich kein wakeup-Gerät, das sich nicht automatisch bei zu Ende gehender Batterie penetrant und frühzeitig meldet...

Was ist das für ein Sensor?

Gruß, Christian

Hmmm, habe bei meinen (wenigen) ZWave-Geräten nie das wakeup Intervall geändert.

Manche stehen auf 24h andere auf 6h Standard...

Die Fibaro-Augen laufen seit knapp einem Jahr so und zeigen immer noch 100%

Aber gut zu wissen...

Danke, Joachim

[DeeSPe]

Hmmm, habe bei meinen (wenigen) ZWave-Geräten nie das wakeup Intervall geändert.

Manche stehen auf 24h andere auf 6h Standard...

Die Fibaro-Augen laufen seit knapp einem Jahr so und zeigen immer noch 100%

Aber gut zu wissen...

Danke, Joachim

Hast Du Plots für den Batteriestand laufen?
Wenn ja, wie machst Du es dass sie nicht abreißen bei 24/6 Intervall?

Gruß
Dan

[MadMax-FHEM]

Hast Du Plots für den Batteriestand laufen?
Wenn ja, wie machst Du es dass sie nicht abreißen bei 24/6 Intervall?

Gruß
Dan

Hi Dan,

nö.

Nur eine Readingsgroup mit Icons und Farbe entsprechend des Füllstands...

EDIT: aber mir fällt ein, dass ich meinen Wasserstandsverbrauch 1x am Tag berechne (also Stand gestern - Stand heute) ihn aber "plotten" will. Habe daher ein at welches halt ab und an (jede Stunde oder so) den Wert noch mal setzt (ohne Berechnung natürlich) und dadurch ja ein Event und einen Logeintrag erzeugt... Vielleicht nicht die beste Lösung aber tut...

Sorry, Joachim

[pi-user]

Hallo MadMax-FHEM,

danke für die Tipps.

Wie ich es vermutet habe: heute ist der Batteriestatus auf 88% ! Der Sensor ist seit 10 Tagen im Einsatz. Das ist echt blöd! Ich werde am Wochenende eine Kiste Batterien kaufen. Auf dauer wird sehr teuer.

[Thorsten Pferdekaemper]

Hi,
naja, das sollte eigentlich nicht so sein. Ich habe zwar kein ZWave, sondern Homematic, aber da halten die Batterien in der Regel 1 bis 2 Jahre und die Teile wachen alle 2 bis 3 Minuten auf und schicken Messwerte.
Vielleicht kannst Du mal genau sagen, was das für ein Sensor ist. Vielleicht hat damit jemand Erfahrungen und kann helfen.
Gruß,
   Thorsten

[pi-user]

Der Sensor ist: FIBARO Tür- und Fenstersensor - GEN5 (FIBEFGK-101-ZW5). Ich verwende dieser Sensor mit der Eingangstür.

https://www.home4u-shop.de/fibaro-door/window-sensor-tuer-und-fenstersensor-gen5-weiss

[MadMax-FHEM]

Der Sensor ist: FIBARO Tür- und Fenstersensor - GEN5 (FIBEFGK-101-ZW5). Ich verwende dieser Sensor mit der Eingangstür.

https://www.home4u-shop.de/fibaro-door/window-sensor-tuer-und-fenstersensor-gen5-weiss

Den kenne ich zwar jetzt auch nicht.

Habe wie gesagt die "Augen" von Fibaro und Rauchmelder von Fibaro.

Die Augen bestimmt schon ein (knappes) Jahr und immer noch 100%...

Hast du irgendwelche Dinge verändert?
Z.B. irgendwelche Intervalle geändert?

Bzw. schau doch mal in der Anleitung wie die Standardeinstellungen sind...

Wie oft machst du denn die Tür auf?

Wobei bei mir die "Augen" im Schrank hängen und der geht auch (sehr) oft auf, also bestimmt 5-10mal pro Tag...

Gruß, Joachim

[pi-user]

Hallo Joachim,

die Tür geht bestimmt 10 mal am Tag auf. Ich warte noch ein paar Tagen und beobachte den Batteriestatus. 

[pi-user]

Ich habe doch eine kleine Frage. Ich habe folgende Zeile, die auch funktioniert:

Code Auswählen Erweitern

define EingangstuerBatteriestatus notify WD.Eingangstuer:battery.* {my_batteriestatus(ReadingsNum('WD.Eingangstuer','battery','default'))}

Die Tabelle Readings vom Z-Wave Sensor beinhaltet bereits ein Attribut namens battary. Wie kann ich ein weiteres bzw. eigenes Attribut namens batteriestatus in die Tabelle Readings hinzufügen, das stets den aktuellen Wert vom Attribut battary beinhaltet? Z.B.: setreading WD.Eingangstuer batteriestatus  $VALUE
Ich möchte bei dem o.g. notify den Wert von battary an batteriestatus  zuweisen. Mit anderen Worten: Die Tabelle Readings soll einfach ein zusätzliches Attribut beinhalten, das den gleichen Wert hat, wie battary. Ist das möglich?

[DeeSPe]

Code Auswählen Erweitern

define EingangstuerBatteriestatus notify WD.Eingangstuer:battery.* setreading $NAME batteriestatus $EVTPART2

Gruß
Dan

P.S. Obwohl ich nicht weiß wozu ein anderes Reading mit genau dem selben Wert gut sein soll...

[MadMax-FHEM]

Mal dumm gefragt:

warum 2 verschiedene Readings im selben Gerät mit dem selben Wert?

Mit einem angepassten/umgerechneten/... Wert würde ich ja verstehen...

Gruß, Joachim

[pi-user]

Ganz einfach:

Ich verwende doch zurzeit folgender Code, um den Batteriestatus von Technoline TX 29 DTH Sensoren grafisch auf der fhem Seite darzustellen:

Code Auswählen Erweitern

define ZE.Batterie readingsGroup .*:[Bb]attery\
.*:[Bb]atteryLevel
attr ZE.Batterie notime 1
attr ZE.Batterie room Zentral
attr ZE.Batterie valueFormat {return "0" if( $VALUE eq "low" );; return "100" if( $VALUE eq "ok" );; return "25" if( $VALUE < 2.1 );; return "50" if( $VALUE < 2.3 );; return "75" if( $VALUE < 2.5 );; return "100"}
attr ZE.Batterie valueIcon {'battery.0' => 'measure_battery_0@red','battery.100' => 'measure_battery_100@green','Battery.0' => 'measure_battery_0@red','Battery.100' => 'measure_battery_100@green','batteryLevel.0' => 'measure_battery_0@red','batteryLevel.25' => 'measure_battery_25@red','batteryLevel.50' => 'measure_battery_50@orange','batteryLevel.75' => 'measure_battery_75@green','batteryLevel.100' => 'measure_battery_100@green'}

Wie ihr oben sieht, werden alle Sensoren "abgefragt", die das Attribut battery haben. Der Batteriestatus von Technoline ist entweder "low" oder "ok". Ich möchte nun ein zweites readingsGroup für meine Z-Waves Sensoren definieren, aber ich kann nicht wieder *:[Bb]attery verwenden, weil dadurch auch die Technoline Sensoren mit dem Attribut battery angesprochen werden. Aus diesem Grund benötige ich in der Tabelle Readings der Z-Wave Sensoren ein weiteres Attribut, das nicht battery heißt.

Z.B.: define ZW.Batterie readingsGroup .*:ZWBatteriestatus

[DeeSPe]

Doch das geht indem Du Devspec veränderst!

Code Auswählen Erweitern

define ZE.Batterie readingsGroup TYPE=ZWave:FILTER=modelId=blabla:[Bb]attery.*

Gruß
Dan

[pi-user]

Oh wie geil. Aber was ist mit modelId gemeint?

[MadMax-FHEM]

Warum 2 ReadingsGroups für Battery?

Ich habe eine ReadingsGroup für alle Batteriezustände aller Geräte: Homematic und ZWave.

Aktuell noch über den Umweg eines Dummy aber das wäre dann eine Anwendung für setreading und angepasster Wert.

Also beispielsweise bei allen Geräten ein zusätzliches Reading 'batterystatus' (evtl. besser einen eideutigen Namen wählen: myBatteryStatus) wo dann immer der Batteriezustand in einheitlicher Form drin steht abgewandelt bzw. "berechnet" aus dem jeweils unterschiedlichen (vom Format etc.) Reading 'battery' (es kann nat. auch ein anderer Readingname sein, dann halt einen weiteren Notify zur "Umrechnung") der unterschiedlichen Geräte.

Und dann eine Readingsgroup über 'batterystatus' (myBatteryStatus).
Da dann alle batterystatus (myBatteryStatus) ja einheitlich sind ist auch die Darstellung etc. immer einheitlich...

Da wären wir dann wieder bei dem Notify welches dann eben auf das tatsächliche "Batteriestatus-Reading" des/der Gerät(e) lauscht (notify bNotify .*battery.* {myWandlungsfunktion($NAME)}), eine Sub aufruft und entsprechend "berechnet" bzw. in eine einheitliche Form wandelt und das dann beim entsprechenden Gerät (welches das Notify ausgelöst hat Stichwort: $NAME) als neues Reading hinterlegt: setreading batterystatus GEWANDELTER-WERT...

Ich berechne halt z.B. immer einen prozentualen Wert:
- bei den Geräten die eine Spannung liefern halt anhand der Limit-Spannung und nat. maximaler Spannung (meist 3V)
- bei Geräten die ok/low liefern: ok->100 low->0
- bei ZWave muss ich "nur" das%-Zeichen entfernen

D.h. ich habe dann im Dummy (wie gesagt historisch bedingt) für jedes Gerät einen einheitlichen Wert (Zahlenwert der Prozent) stehen, somit ist eine einheitliche Darstellung über alle Geräte(typen) ganz einfach...

Wenn die Namen der Geräte etc. gut gewählt sind, dann kann man mit entsprechender Wahl der regexe bei dem/den Notify immer gleich sehr viel erschlagen.
Ich habe wie geschrieben genau ein Notify für die "Wandlung": define bBattery .*battery.* {myWandlungsfunktion($NAME)}.
Die Prüfung welches Gerät gerade gefeuert hat und was dann wie gewandelt werden muss und was dann wie wohin geschrieben werden muss mache ich dann in der Sub...

Aber ich drehe mich gerade im Kreis...
...und geb daher nun Ruhe...

Gruß, Joachim

[DeeSPe]

Oh wie geil. Aber was ist mit modelId gemeint?

Devspec ist eindeutig erklärt!

Gruß
Dan

[pi-user]

Theoretisch konnte ich den vorhandnen Code so anpassen, dass es funktioniert:

Step 1: Das Zeichen % entfernen bzw. den Wert überschreiben, aber ohne das % Zeichen

Es kann sein, dass diese Zeile nicht korrekt definiert ist!

Code Auswählen Erweitern

define EingangstuerBatteriestatus notify WD.Eingangstuer:battery.* {setreading $NAME battery ReadingsNum('WD.Eingangstuer','battery','default')}

Step 2: den Code mit dem Operator or und eq erweitern:

define ZE.Batterie readingsGroup .*:[Bb]attery\
.*:[Bb]atteryLevel
attr ZE.Batterie notime 1
attr ZE.Batterie room Zentral
attr ZE.Batterie valueFormat {return "0" if( $VALUE eq "low" or eq 0);; return "100" if( $VALUE eq "ok" or eq 100 );; return "25" if( $VALUE < 2.1 );; return "50" if( $VALUE < 2.3 );; return "75" if( $VALUE < 2.5 );; return "100"}
attr ZE.Batterie valueIcon {'battery.0' => 'measure_battery_0@red','battery.100' => 'measure_battery_100@green','Battery.0' => 'measure_battery_0@red','Battery.100' => 'measure_battery_100@green','batteryLevel.0' => 'measure_battery_0@red','batteryLevel.25' => 'measure_battery_25@red','batteryLevel.50' => 'measure_battery_50@orange','batteryLevel.75' => 'measure_battery_75@green','batteryLevel.100' => 'measure_battery_100@green'}

Was ich in diesem Code nicht verstehe ist z.B: $VALUE < 2.1 oder $VALUE < 2.3 und so weiter!?!

[Beta-User]

Was ich in diesem Code nicht verstehe ist z.B: $VALUE < 2.1 oder $VALUE < 2.3 und so weiter!?!

Nach meinem Verständnis wird so direkt in der Readingsgroup der gemeldete Volt-Wert in einen %-Wert übersetzt.

Vielleicht solltest Du mal posten, wie so ein Batterie-Event bzw./reading für die zwaves aussieht, dann kann man das vermutlich noch in die eine Readingsgroup reinbasteln.

Gruß, Beta-User

[DeeSPe]

Code Auswählen Erweitern

define EingangstuerBatteriestatus notify WD.Eingangstuer:battery.* {setreading $NAME battery ReadingsNum('WD.Eingangstuer','battery','default')}

Warum befolgst Du nicht einfach meinen Rat?
Da habe ich bereits ein fertig funktionierendes Beispiel gebracht.

Gruß
Dan

P.S. Warum wollen eigentlich so viele "Neue" ständig das Rad neu erfinden anstatt auf die "alten Hasen" zu hören?

[pi-user]

Meinst Du das?

Code Auswählen Erweitern

define ZE.Batterie readingsGroup TYPE=ZWave:FILTER=modelId=blabla:[Bb]attery.*

[DeeSPe]

Meinst Du das?

Code Auswählen Erweitern

define ZE.Batterie readingsGroup TYPE=ZWave:FILTER=modelId=blabla:[Bb]attery.*

NEIN, ich meine das was ich verlinkt habe!

Gruß
Dan

[Beta-User]

P.S. Warum wollen eigentlich so viele "Neue" ständig das Rad neu erfinden anstatt auf die "alten Hasen" zu hören?

Wenn das auf meine Anmerkung bezogen sein sollte: Du fragst selbst, was ein zweites Reading mit anderem Namen bringen soll...

Man sollte wie von Dir vorgeschlagen besser die regex entsprechend anpassen, so dass man die ursprünglich vorhandenen Readings nutzt und dann ggf. mit valueFormat umformen.

Also etwa so:

Code Auswählen Erweitern

define ZE.Batterie readingsGroup (.*:[Bb]attery.*:[Bb]atteryLevel|TYPE=ZWave:FILTER=modelId=blabla:[Bb]attery.*)
Das ist keine neue Sache, sondern nur eine Fortsetzung dessen, was schon da ist .

[MadMax-FHEM]

Nach meinem Verständnis wird so direkt in der Readingsgroup der gemeldete Volt-Wert in einen %-Wert übersetzt.

Vielleicht solltest Du mal posten, wie so ein Batterie-Event bzw./reading für die zwaves aussieht, dann kann man das vermutlich noch in die eine Readingsgroup reinbasteln.

Gruß, Beta-User

Jep sieht genau so aus.

So ähnlich mache ich das für meine Homematic-Geräte die einen aktuellen Spannungswert liefern.

Allerdings nicht "hardcoded" als bestimmten Spannungswert sondern eben abhängig vom MinBatLimit (also wie weit runter das Gerät "sagt" dass es noch funktionieren würde)...

Und nicht direkt in der ReadingsGroup (gut könnte ich mir mal überlegen) sondern eben in einem Notify auf "alle" Batterie-Readings aller meiner Geräte...
...und dann halt in einer Sub (die dann schon weiß wie der endgültige Wert den ich zur Anzeige brauche/will zu ermitteln ist je nach Gerät)...

Ups doch wieder mitgedreht...

Langsam glaube ich drehen wir uns alle

EDIT:

Code Auswählen Erweitern


2017-05-12 17:04:53 ZWave Rauchmelder_SchlaZi wakeup: notification
2017-05-12 17:04:53 ZWave Rauchmelder_SchlaZi battery: 100 %


EDIT2:

Code Auswählen Erweitern

2017-05-12 17:04:53   battery         100 %

Gruß, Joachim

[FunkOdyssey]

Anbei mal meine DEF.
Es werden Geräte mit prozentualem Batteriewert ausgewertet und Geräte mit Batteriewerten "ok/low".

Code Auswählen Erweitern

define n_battery_msg notify .*:battery:.* {\
  fhem "msg ACHTUNG!!! Die Batterie von ".AttrVal($NAME,"alias",$NAME)." geht zur Neige ($EVENT)!"\
    if (($EVTPART1 =~ /^([a-z]+)$/ && $1 !~ /ok/)\
    || ($EVTPART1 =~ /^(\d{1,3})%$/ && $1 < 50))\
}

So bekomme ich eine Nachricht wenn der Batteriewert Text und was anderes als "ok" ist, oder wenn der Batteriewert ein Prozentwert und unter 50 ist.

Ähm, mir ist die folgende Frage schon fast zu peinlich, da ich mich dadurch eindeutig als Notify-Laie und DOIF-Jünger oute. Und ich will keineswegs dadurch eine Grundsatzdiskussion auslösen. Aber dennoch verstehe ich diese Zeilen nicht

Die Anweisungen des Notifys werden doch sukzessive abgearbeitet, oder? Das würde doch immer eine Mail beim Event .*:battery:.* ausgelöst werden. Und erst danach das Event auf ungleich "ok" und <50 ausgewertet. Müsste das nicht verschachtelt werden? Oder habe ich es einfach nicht drauf was Notifys angeht.

[Beta-User]

Ist eher eine perl-Spezialität:
Es handelt sich eigentlich nur um einen Einzeiler mit einem nachgestellten if in derselben Zeile (programmiertechnisch gesehen, optisch ist es anders). Der Sendebefehl wird also tatsächlich nur ausgeführt, wenn eine der beiden Bedingungen im if eintritt.

Gruß, Beta-User

[FunkOdyssey]

Oh, ja. Danke für die Erklärung. Das ist mir sogar ein wenig bekannt. Halt nur selbst noch nie verwendet.

[FunkOdyssey]

Könnte mir jemand noch einen Tipp geben?

Ich habe Z-Wave-Geräte, in denen das battery-Reading wie folgt aussieht: "14 %"
Hier greifen die RegExp nicht, da ein Leerzeichen vor dem Prozent enthalten ist.
Nun dachte ich ganz naiv, das ich einfach nur ein Punkt ergänzen muss.

Code Auswählen Erweitern

($EVTPART1 =~ /^(\d{1,3}).%$/ && $1 < 50))

Aber das Notify wird nicht ausgeführt.

[DeeSPe]

Könnte mir jemand noch einen Tipp geben?

Ich habe Z-Wave-Geräte, in denen das battery-Reading wie folgt aussieht: "14 %"
Hier greifen die RegExp nicht, da ein Leerzeichen vor dem Prozent enthalten ist.
Nun dachte ich ganz naiv, das ich einfach nur ein Punkt ergänzen muss.

Code Auswählen Erweitern

($EVTPART1 =~ /^(\d{1,3}).%$/ && $1 < 50))

Aber das Notify wird nicht ausgeführt.

Code Auswählen Erweitern

($EVTPART1 =~ /^(\d{1,3})\s?%$/ && $1 < 50))

Gruß
Dan

[FunkOdyssey]

Danke dir für deine Hilfe.
Ich habe es zwar zuvor unter regex101.com getestet, aber hatte absolut keine Idee hat, dass ich \s? verwenden muss. Merci.

[DeeSPe]

Danke dir für deine Hilfe.
Ich habe es zwar zuvor unter regex101.com getestet, aber hatte absolut keine Idee hat, dass ich \s? verwenden muss. Merci.

Musst Du nicht!
Mit dem Punkt sollte es auch klappen.

"\s?" bedeutet ja nur dass ein optionales Leerzeichen vor dem % vorhanden sein kann.

Gruß
Dan