Batteriestatus von unterschiedlichen Hersteller auslesen

Begonnen von pi-user, 08 Mai 2017, 11:45:57

Vorheriges Thema - Nächstes Thema

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Thorsten Pferdekaemper

Zitat von: pi-user am 09 Mai 2017, 20:23:31
Es funktioniert so nicht. Ich kann die Datei fhem.cfg nicht speichern, da ich eine Fehlermeldung belommen: Unknown command }, try help.

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 {}:

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

FUIP

DeeSPe

Zitat von: MadMax-FHEM am 09 Mai 2017, 20:32:58
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:
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
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

MadMax-FHEM

Zitat von: Thorsten Pferdekaemper am 09 Mai 2017, 20:35:43
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 {}:

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

pi-user

#34
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.

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

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

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:

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

Zitat von: pi-user am 09 Mai 2017, 20:56:08
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
FUIP

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?
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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

DeeSPe

Zitat von: pi-user am 09 Mai 2017, 21:11:44
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?
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
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

Thorsten Pferdekaemper

Zitat von: pi-user am 09 Mai 2017, 21:11:44
Also so oder nicht?
Nein, so:

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

oder auch

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
FUIP

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

Zitat von: pi-user am 09 Mai 2017, 21:24:49
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!

Zitat von: DeeSPe am 09 Mai 2017, 20:23:55
Es werden Geräte mit prozentualem Batteriewert ausgewertet und Geräte mit Batteriewerten "ok/low".

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
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

MadMax-FHEM

Zitat von: pi-user am 09 Mai 2017, 21:24:49
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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

pi-user

Hallo zusammen,

es funktioniert endlich.  :) Ich danke Euch.

So sieht es vorerst aus:

99_myUtils.pm:

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


fhem.cfg:

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?