Batteriestatus und Speicherung des letzten Wechsel

Begonnen von Amenophis86, 12 Januar 2018, 19:23:20

Vorheriges Thema - Nächstes Thema

Betonklotz

Hallo zusammen,

was mir nun im Betrieb aufgefallen ist als jetzt das erste Ventil mit "intensivem" Monitoring bis in die Error Position gefahren wurde (wenn ich nicht im Urlaub bin, warte ich bis zum bitteren Ende = wie man sieht dauerte das ja auch zig Tage):

2020-05-16_10:59:16 EG_Bad_Heizung actuator: 0
2020-05-16_10:59:16 EG_Bad_Heizung battery: low
2020-05-16_10:59:16 EG_Bad_Heizung batteryLevel: 2.3
2020-05-16_10:59:16 EG_Bad_Heizung desired-temp: 19.0
2020-05-16_10:59:16 EG_Bad_Heizung measured-temp: 20.5
2020-05-16_10:59:16 EG_Bad_Heizung motorErr: lowBat
2020-05-16_11:01:30 EG_Bad_Heizung actuator: 0
2020-05-16_11:01:30 EG_Bad_Heizung battery: low
2020-05-16_11:01:30 EG_Bad_Heizung batteryLevel: 2.1
2020-05-16_11:01:30 EG_Bad_Heizung desired-temp: 19.0
2020-05-16_11:01:30 EG_Bad_Heizung measured-temp: 20.6
2020-05-16_11:01:30 EG_Bad_Heizung motorErr: lowBat
2020-05-16_11:04:33 EG_Bad_Heizung actuator: 0
2020-05-16_11:04:33 EG_Bad_Heizung battery: low
2020-05-16_11:04:33 EG_Bad_Heizung batteryLevel: 2.3
2020-05-16_11:04:33 EG_Bad_Heizung desired-temp: 19.0
2020-05-16_11:04:33 EG_Bad_Heizung measured-temp: 20.6
2020-05-16_11:04:33 EG_Bad_Heizung motorErr: lowBat
[...]
2020-06-06_10:59:51 EG_Bad_Heizung actuator: 0
2020-06-06_10:59:51 EG_Bad_Heizung battery: low
2020-06-06_10:59:51 EG_Bad_Heizung batteryLevel: 2.3
2020-06-06_10:59:51 EG_Bad_Heizung desired-temp: 19.0
2020-06-06_10:59:51 EG_Bad_Heizung measured-temp: 21.4
2020-06-06_10:59:51 EG_Bad_Heizung motorErr: lowBat
2020-06-06_11:02:36 EG_Bad_Heizung actuator: 15
2020-06-06_11:02:36 EG_Bad_Heizung batteryLevel: 2.3
2020-06-06_11:02:36 EG_Bad_Heizung desired-temp: 19.0
2020-06-06_11:02:36 EG_Bad_Heizung measured-temp: 21.4
2020-06-06_11:02:36 EG_Bad_Heizung motorErr: ValveErrorPosition
2020-06-06_11:05:07 EG_Bad_Heizung actuator: 15
2020-06-06_11:05:07 EG_Bad_Heizung batteryLevel: 2.3
2020-06-06_11:05:07 EG_Bad_Heizung desired-temp: 19.0
2020-06-06_11:05:07 EG_Bad_Heizung measured-temp: 21.5
2020-06-06_11:05:07 EG_Bad_Heizung motorErr: ValveErrorPosition

Die Spannung geht einmalig (2020-05-16_11:01:30 EG_Bad_Heizung batteryLevel: 2.1) runter auf das R-lowBatLimitRT. Das führt dazu, dass die "letzte kritische" Warnung gesendet wird (da elsif(($ActBatLevel - $MinBatLevel) > 0) nicht mehr zutrifft), wobwohl noch alles i.O. ist. Habe daher den Code wie folgt umgebaut

if($TYPE eq "CUL_HM" and $BatteryType[0] eq "batteryLevel")
{
# use ReadingsVal as batteryLevel is a pure value without units
$ActBatLevel = ReadingsVal($Device, "batteryLevel", "0.0");
# use ReadingsNum as R-lowBatLimitRT contains a value and unit [V]olt ==> ReadingsNum takes just the value without unit
$MinBatLevel = ReadingsNum($Device, "R-lowBatLimitRT", "0.0");
# divide the max passible voltage range in 4 equal quarters to show different colours and icons for each quarter
$RemainingVoltageQuater = ($MaxBattery - $MinBatLevel) / 4;
# set battery level to 100% and show in BatteryStatus-Device if new
if(ReadingsVal($BatteryStatus, $Device, "undef") eq "undef")
{
# set the (our internal) battery reading of the device to 100 and add it to our BatteryStatus Device
fhem("setreading $BatteryStatus $Device 100");
Log3(undef, 1, "$Device, added to $BatteryStatus");
return undef;
}
# check if the voltage level is in the range of 75...100% (= 4 of 4 quarters)
if(($ActBatLevel - $MinBatLevel) > (3 * $RemainingVoltageQuater))
{
# check if the voltage level was low before and is now full again ==> battery is (most likely) replaced
if(ReadingsVal($BatteryStatus, $Device, 100) <= 25)
{
# battery was replaced, lets calculate the lifetime of the battery since last change
my_CalculateBatteryLife($Device);
# set date/time for changed battery by setting the text ==> FHEM sets the actual time/date automatically on its own
fhem("setreading $BatteryChanged $Device $text_changed");
fhem($msg." ".$text_batchanged);
Log3(undef, 3, "Battery change detected on HM device $Device");
}
# set the internal battery value to 100%
fhem("setreading $BatteryStatus $Device 100");
return undef;
}
# check if the voltage level is in the range of 50...75% (= 3 of 4 quarters)
elsif(($ActBatLevel - $MinBatLevel) > (2 * $RemainingVoltageQuater))
{
# set the internal battery value to 75%
fhem("setreading $BatteryStatus $Device 75");
return undef;
}
# check if the voltage level is in the range of 25...50% (= 2 of 4 quarters)
elsif(($ActBatLevel - $MinBatLevel) > ($RemainingVoltageQuater))
{
# set the internal battery value to 50%
fhem("setreading $BatteryStatus $Device 50");
return undef;
}
# check if the voltage level is in the range of 0...25% (= 1 of 4 quarters)
elsif(($ActBatLevel - $MinBatLevel) > 0)
{
# check if the device wasn't already before in the state of having just 0...25% voltage level left
if(ReadingsNum($BatteryStatus, $Device, 0) != 25)
{
# check if the valve is indicationg already an motor error (= battery drained)
if (ReadingsVal($Device, "motorErr", "ok") eq "ValveErrorPosition")
{
# battery drained and valve couldn't move any longer ==> set the battery value to 0%
fhem("setreading $BatteryStatus $Device 0");
fhem($msg." ".$text_motorErrValve);
Log3(undef, 3, "Motor of $Device is in eror state, BatteryChange needed NOW");
}
# check if the valve is indicationg already an error low bat (= battery soon drained)
elsif (ReadingsVal($Device, "motorErr", "ok") eq "lowBat")
{
# check if the device had a rapid voltage drop before
if(ReadingsNum($BatteryStatus, $Device, 0) != 0)
{
my $test2 = ReadingsVal($BatteryStatus, $Device, "99");
Log3(undef, 3, "Device=$Device , BatteryStatus=$BatteryStatus , ActBatLevel=$ActBatLevel , MinBatLevel=$MinBatLevel , RemainingVoltageQuater=$RemainingVoltageQuater , readval=$test2");
# set the internal battery value to 25%
fhem("setreading $BatteryStatus $Device 25");
fhem($msg." ".$text_soon);
Log3(undef, 3, "$Device, BatteryChange needed soon");
}
}
# no error state, valve is still running normally and in 0...25% state (= 1 of 4 quarters)
else
{
# set the internal battery value to 25%
fhem("setreading $BatteryStatus $Device 25");
}
}
return undef;
}
# some unknown state or no actual state received or device has a rapid voltage drop (=> $ActBatLevel - $MinBatLevel becomes negative)
else
{
my $test = ReadingsVal($BatteryStatus, $Device, "99");
Log3(undef, 3, "Device=$Device , BatteryStatus=$BatteryStatus , ActBatLevel=$ActBatLevel , MinBatLevel=$MinBatLevel , RemainingVoltageQuater=$RemainingVoltageQuater , readval=$test");
# check if the device wasn't already before in the state of having just 0% voltage level left
if (ReadingsVal($BatteryStatus, $Device, 0) != 0)
{
# set the internal battery value to 0% (= totally empty or no state received)
fhem("setreading $BatteryStatus $Device 0");
fhem($msg." ".$text_now);
Log3(undef, 3, "$Device, BatteryChange needed NOW");
}
return undef;
}
}

Evtl. ist das ja auch etwas als Anregung für euch, bzw. ihr seht identische Probleme bei euren Ventilen.
Als weitere Verbesserung würde ich gerne die Meldungen "ausdünnen". Aktuell kommt alle 3min die Meldung wenn das Ventil hängt

# check if the voltage level is in the range of 0...25% (= 1 of 4 quarters)
elsif(($ActBatLevel - $MinBatLevel) > 0)
{
# check if the device wasn't already before in the state of having just 0...25% voltage level left
if(ReadingsNum($BatteryStatus, $Device, 0) != 25)
{
# check if the valve is indicationg already an motor error (= battery drained)
if (ReadingsVal($Device, "motorErr", "ok") eq "ValveErrorPosition")
{
# battery drained and valve couldn't move any longer ==> set the battery value to 0%
fhem("setreading $BatteryStatus $Device 0");
fhem($msg." ".$text_motorErrValve);
Log3(undef, 3, "Motor of $Device is in eror state, BatteryChange needed NOW");

Kann man das irgendwie "einfach" auf jede zehnte (also alle 30min, oder alle 1h o.ä.) ausdünnen? Würde sonst eine weitere Variable/Zähler einführen die bei jedem "MotorErr" Durchlauf um eins hochzählt und dann "MODULO 10" o.ä. für den Log nutzen, sowie den Zähler bei Batteriwechsel zurücksetzen. Oder geht das eleganter?

Gruß, Robert

MadMax-FHEM

Schön zu sehen, dass der Code (auch hier) (weiter)"lebt"...


Wenn es "nur" um die Meldung(en) bzgl. motorErr geht: event-on-change-reading (mit entspr. event-min-intervall) passend setzen...
...bzw. geht das ja generell...
Wenn kein Event kommt, dann "passiert" auch nichts... ;)

Oder wie du selbst vorgeschlagen hast: einen entspr. Zähler...
(sowas bzw. einen "Merker" habe ich generell zum "Kontrollieren" von Nachrichten)

Anmerkung: ich habe (unabhängig) von diesem "Modul" für "kritische Dinge" (wie z.B. motorErr und weitere) generell noch notify mit entsprechender Meldung etc. :)

Gruß und danke, 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)

Betonklotz

Zitat von: MadMax-FHEM am 08 Juni 2020, 12:06:46
Wenn es "nur" um die Meldung(en) bzgl. motorErr geht: event-on-change-reading (mit entspr. event-min-intervall) passend setzen...
...bzw. geht das ja generell...
Wenn kein Event kommt, dann "passiert" auch nichts... ;)
Hallo Joachim,

das könnte ich in der Tat (nur) für den motorErr nutzen und den min intervall auf 3600 (=1h) setzen.

event-on-change-reading .*
event-min-interval .*:3600

Übersehe ich da irgendetwas? Denn das wäre ja fast zu einfach... Wobei ich gerade lese: das wirkt sich (natürlich) auch auf die plots aus, da die Temp Werte, Ventilstellung usw. auch nicht mehr regelmäßig kommt. Egal, schaue ich mir mal an und ist deutlich einfacher als ein neues Reading über die Anzahl an Warnugnen einzuführen.

Gruß, Robert

MadMax-FHEM

#318
Dann mach statt .* (also "alle Readings") halt nur motorErr...

Bzw. kannst du ja für verschidene Readings verschiedene Einstellungen vornehmen...
...in den Attributen gibt man/kann man ja Listen von Readings angeben...

EDIT: mit event-on-update-reading kannst du auch einzelne Events wieder "freigeben", die von event-on-change "geblockt" wurden... Je nachdem was einfacher ist. Also kleine Blacklist ohne Whitelist oder "ausführliche" Blacklist mit ein paar Whitelist Einträgen... ;)

Ich nutze die event-on Attribute eigentlich (fast) überall.
Damit kann man etwas "Ruhe" ins System bringen und auch die Last reduzieren:

"unnötige" Events ganz weg bzw. max. bei Änderung

Events für's Plotten so, dass mir die Plots "gefallen"...

Und Events zur Steuerung so, dass die Steuerung tut wie ich will...

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)

Betonklotz

ich oute mich: bis jetzt habe ich die noch gar nicht genutzt... Muss ich mich erst einmal mit vertraut machen wie sich das in der Praxis verhält

MadMax-FHEM

Ja, da muss man ein wenig "spielen"...

Aber es hilft wirklich (viel), nicht nur hier für das "Nachrichten-Problem"... ;)

Einfach mal den Eventmonitor laufen lassen und schauen was da so alles "gefeuert" wird...

Das Meiste ist eher unnötig...
...erzeugt aber halt (trotzdem) "Last"...

Und dann eben Stück für Stück reduzieren...
...aber immer schön langsam und prüfen, ob noch alles tut...

Da ist schnell auch mal ein notwendiger Event mit "weg"...
...und wenn man zuviel geändert hat iat es schwer herauszufinden welcher Schritt nun zu viel war... ;)

Du kannst auch DOIFTools "installieren".
Das zeigt an, welches Device wieviele Events pro Zeit etc. "erzeugt"...

Dann ist es einfacher sich auf die "Event-Schleudern" zu konzentrieren...

Weil Devices die nur ab ind an mal ein paar Events generieren ist es unnötig "ausgeklügelte" event-on Einstellungen vorzunehmen...

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)

Betonklotz

Hallo Joachim,

habe mir das mal über Nacht angeschaut, würde es aber wohl auf motorErr beschränken.
FHEM läuft bei mir als VM in Proxmox auf dem Server und ist im Grunde im idle state (2 Cores und die sind bei 0,8% im Schnitt). Also Lastprobleme habe ich seit dem Umzug weg vom RPi nicht mehr ;-) Die HM Funkschnittstelle ist (trotz AES überall aktiv = quasi Verdopplung des Traffics) auch noch nie in overload gegangen, auch nicht nach Reboot o.ä. Geschichten.
Getreu dem Motto never change a running system würde ich es erst einmal so belassen, habe einfach zu viele Baustellen und weiß gar nicht wo ich anfangen soll (den Bat-Status wollte ich mir auch mal grundlegend neu entwerfen, ist aber auch nur ein Eintrag auf der To-Do Liste)...

Gruß, Robert

TWART016

Ich habe das so gelöst. Geht sicherlich schöner, sollte aber funktionieren  ;)

defmod batterie_notify notify .*:[Bb]attery:.* {\
if ($EVTPART1 =~ "0|1|2|3|4|5|6|7|8|9" and $EVTPART1 >= 0 and $EVTPART1 <= 20) {fhem("set Telegram msg Die Battery von <b>" .$NAME ."</b> liegt bei <b>" .$EVTPART1 ."</b>%")} \
elsif ($EVTPART1 =~ "a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|v|w|x|y|z" and $EVTPART1 ne "ok") {fhem("set Telegram msg Die Batterie von <b>" .$NAME ."</b> ist <b>" .$EVTPART1 ."</b>")} \
}\

amenomade

Regex:

0|1|2|3|4|5|6|7|8|9    <=>   [0-9]
a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|v|w|x|y|z   <=>   [a-z]
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

mr.sulu

Hallo zusammen,
vielen Dank erst mal für dieses super Modul!!!!
Hatte erst ein wenig Probleme, da ich sehr viele verschiedene Geräte habe und auch FHEM2FHEM nutze. LaCrosse und einige HM wurden nicht angezeigt (Version no-BatteryStatusBot-Zweig). Nach dem ich aber anstelle von $DEVICE -> $ALIAS eingefügt habe funktioniert jetzt alles  ;)
Gruß,mr.sulu

Kai-Alfonso

Moin - ich hab mal eine Frage. Ich wollte das Modul auch mal testen, aber ich bekomme nix gemeldet, wenn ich eine Batterie mal testweise rausnehme.  Wie kann ich denn das Modul mal gescheit testen?
Raspi2|nanoCul433|nanoCul868|CCU2
Energie-USBZähler|homebrew HM Devices
DBLog|DBRep|Homematic|Baumarktsteckdosen
Hue|Webcams mit DS-Station (Synology)|Bewegungsmelder|Rollladen|Schalter (IT|HM)

MadMax-FHEM

Zitat von: Kai-Alfonso am 13 August 2021, 13:31:29
Moin - ich hab mal eine Frage. Ich wollte das Modul auch mal testen, aber ich bekomme nix gemeldet, wenn ich eine Batterie mal testweise rausnehme.  Wie kann ich denn das Modul mal gescheit testen?

setreading Device battery low

Oder was halt immer das entsprechende Reading ist und der passende Testwert ;)

Oder auch mittels trigger nur das notify triggern...

Das Reading korrigiert sich ja wieder bei der nächsten Meldung vom Gerät ;)

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)

Kai-Alfonso

Zitat von: MadMax-FHEM am 13 August 2021, 15:40:39
setreading Device battery low


Lol, da hatte ich ein Brett vorm Kopf - danke fürs wegschlagen des Brettes ;-) :o :o

Ist ja logisch - wird gleich mal getestet
Raspi2|nanoCul433|nanoCul868|CCU2
Energie-USBZähler|homebrew HM Devices
DBLog|DBRep|Homematic|Baumarktsteckdosen
Hue|Webcams mit DS-Station (Synology)|Bewegungsmelder|Rollladen|Schalter (IT|HM)

Kai-Alfonso

so, die Benachrichtigungen gehen bei mir nicht.

Ich nutze dafür diesen Befehl:

my $msg = "msg \@rr_Kai title='Battery Check' ";

"msg @rr_Kai Test" schickt mir eine Push per Pushover an mein Handy, wenn ich das in Fhem teste oder in einem doif zum Beispiel
Raspi2|nanoCul433|nanoCul868|CCU2
Energie-USBZähler|homebrew HM Devices
DBLog|DBRep|Homematic|Baumarktsteckdosen
Hue|Webcams mit DS-Station (Synology)|Bewegungsmelder|Rollladen|Schalter (IT|HM)

Amenophis86

Welchen Branche nutzt du und was sagt das Log? Gibt es einen Fehler?
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...