Batteriestatus von unterschiedlichen Hersteller auslesen

[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.