Autor Thema: Batteriestatus und Speicherung des letzten Wechsel  (Gelesen 82194 mal)

Offline Betonklotz

  • Jr. Member
  • **
  • Beiträge: 62
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #315 am: 08 Juni 2020, 11:55:07 »
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

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 10625
  • NIVEAu ist keine Creme...
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #316 am: 08 Juni 2020, 12:06:46 »
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+ Buster: 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)
FHEM PI3 RaspiOS (Test)

Offline Betonklotz

  • Jr. Member
  • **
  • Beiträge: 62
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #317 am: 08 Juni 2020, 17:49:48 »
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

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 10625
  • NIVEAu ist keine Creme...
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #318 am: 08 Juni 2020, 17:56:10 »
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
« Letzte Änderung: 08 Juni 2020, 17:58:43 von MadMax-FHEM »
FHEM PI3B+ Buster: 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)
FHEM PI3 RaspiOS (Test)

Offline Betonklotz

  • Jr. Member
  • **
  • Beiträge: 62
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #319 am: 08 Juni 2020, 17:58:01 »
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

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 10625
  • NIVEAu ist keine Creme...
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #320 am: 08 Juni 2020, 18:06:31 »
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+ Buster: 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)
FHEM PI3 RaspiOS (Test)

Offline Betonklotz

  • Jr. Member
  • **
  • Beiträge: 62
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #321 am: 09 Juni 2020, 07:46:31 »
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

Offline TWART016

  • Hero Member
  • *****
  • Beiträge: 1142
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #322 am: 03 August 2020, 23:20:51 »
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>")} \
}\

Offline amenomade

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7449
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #323 am: 03 August 2020, 23:29:00 »
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

Offline mr.sulu

  • New Member
  • *
  • Beiträge: 6
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #324 am: 15 März 2021, 10:24:09 »
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