FHEM Forum

FHEM => Codeschnipsel => Thema gestartet von: Amenophis86 am 12 Januar 2018, 19:23:20

Titel: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 12 Januar 2018, 19:23:20
Der User MadMax-FHEM hat dankenswerterweise hier (https://forum.fhem.de/index.php/topic,75571.msg740976.html#msg740976) seinen Code geteilt. Dieser soll den User informieren, sobald eine Batterie leer ist, oder sich dahingehend nähert. Weiterhin soll das skript auch automatisch einen Batteriewechsel erkennen und vermerken.

Aktuell gibt es zwei Versionen der Scripte. Beide sind auf github zu finden: https://github.com/Amenophis86/Batteryfunktion

Der Master-Zweig ist aktuell am auslaufen und wird nicht weiter bearbeitet werden. Die Skripte sind aber noch vollfunktionsfähig.
Der no-BatteryStatusBot-Zweig wird aktuell weiter entwickelt. Hier der Stand für diesen:

1. [BatterieStatus] Ein Dummy, in welchem die aktuellen Prozente der Batterie festgehalten werden (dient der ReadingsGroup Ansicht)
2. [rgBatterieStatus] Eine ReadingsGroup, welche den aktuellen Status der Batterie als Icon darstellt
3. [BatterieWechsel] Ein Dummy, welcher automatisch für gewechselte Batterien ein Reading anlegt
4. Das Script verschickt eine Nachricht, sobald der Status einer Batterie 25% erreicht, oder leer meldet

Um das Script zu erhalten muss wie folgt vorgegangen werden:
1. Es kann entweder direkt die PM runtergeladen, im Order /FHEM/ eingefügt und ein reload 99_BatteryCheckUtils.pm ausgeführt werden, oder der Code kopiert und in die eigene 99_BatteryCheckUtils.pm eingefügt werden.
2. Werte entsprechend anpassen (Siehe weiter unten)
3. Einmalig die Funktion BatteryStart mittels {BatteryStart()}ausführen.


Aktuell sind folgende Änderungen direkt in der Funktion verfügbar:
BatteryStatusFunction:

###############################
# Here you can change the variables to fit your installation.
#
  my $text_now = "Die Batterien von $Device müssen JETZT gewechselt werden!"; #Text for changing battery now
  my $text_soon = "Die Batterien von $Device sollten bald gewechselt werden!"; #Text for changing battery soon
  my $text_motorErrValve = "Der Motor kann sich nicht mehr bewegen!"; #Text for motorErr ValveErrorPosition only HM
  my $text_changed = "Batterie zuletzt gewechselt: "; #Text for last change
  my $BatteryStatus = "BatterieStatus"; #Name of the Dummy for status
  my $BatteryChanged = "BatterieWechsel"; #Name of the Dummy for battery changed information
 
###############################
# Here you can change the times for the temp-at and waittime for the reduction of 5% steps

  my $FivePercent_HM = 600;
  my $TempAt_HM = 43200;
  my $FivePercent_Max = 600;
  my $TempAt_Max = 43200;
  my $FivePercent_Xiaomi = 600;
  my $TempAt_Xiaomi = 43200;
  my $FivePercent_ZWave = 600;
  my $TempAt_ZWave = 600;
  my $FivePercent_LaCrosse = 600;
  my $TempAt_LaCrosse = 43200;
  my $FivePercent_Other = 600;
  my $TempAt_Other = 43200;

Dieser Teil kann und sollte angepasst werden. Im ersten Teil könnt ihr den Text ändern, welcher auch zugeschickt wird. Weiterhin müssen die Namen der Dummies aus der Funktion BatteryStart passen.

$FivePercent_:
Manche Device haben die Angewohnheit, dass sie zwischen low und ok wechseln. Daher prüft das Skript, wann der %-Wert der Battery zuletzt verändert wurde ($FivePercent_). Erst, wenn dieser Wert überschritten wurde wird der %-Wert weiter um 5% verringert. Natürlich gilt das nur für Device, welche lediglich mit dem Reading Battery und nicht mit BatterLevel arbeiten. Die vorgegeben Werte sind noch nicht erprobt und lediglich geschätzt.

$TempAt_:
Jedesmal, wenn ein Device low meldet wird ein temporäres At gestartet. Diese wird wieder gelöscht, sollte das Gerät zwischendurch wieder ein ok melden. Passiert dies nicht wird nach der angegeben Zeit (in Sekunden) das Event "dead" generiert. Damit wird die letzte Meldung der Berechnung abgegeben und das Gerät als leer bezeichnet.

Ein Beispiel:
Unser HM Fensterkontakt hat nur das Reading Battery mit low und ok. Nun fängt die Batterie an zu schwächeln. In unregelmäßigen Abständen wird zwischen low und ok gewechselt.
$FivePercent_HM steht auf 600. Meldet das Gerät mal wieder low und die letzte Änderung des Readings Battery ist länger als 10 Minunten (600 Sekunden) wird der %-Wert für dieses Gerät um 5% verringert. Beim ersten Mal wechselt er also von 100 auf 95%. Das geht nun immer so weiter, bis der Wert 25% erreicht hat. Nun wird die Meldung im String $text_soon an den Nutzer gesendet.
Wechselt der Kontakt nicht mehr zwischen low und ok hin und her, sondern bleibt schlussendlich bei low und $TempAt_HM steht auf 43200 Sekunden (=12 Stunden) kommt nach 12 Stunden die Meldung aus dem String $text_now. Wichtig, diese Berechnung findet nur bei Geräten statt, welche NICHT das Reading BatteryLevel haben. Sobald dieses vorhanden ist, wird hieraus der Wert berechnet. Dazu kann die Variable $MaxBattery = 3.1 angepasst werden. Aktuell wird noch davon ausgegangen, dass alle Geräte mit BatterLevel mit 2xAA Batterien betrieben werden und somit der Wert bei neuen Batterien bei ca. 3.1V liegen müsste.


Nun wechselt der User die Batterie am Gerät. Dieses sendet wieder ok und das System erkennt, dass ein Batteriewechsel stattgefunden hat. Voraussetzung hierfür ist aktuell, dass der %-Wert kleiner oder gleich 25% gewesen sein muss. Sollte man Probleme haben und nicht unter diesen Wert kommen, kann man entweder das Skript entsprechend anpassen oder die attr event-on-... entsprechend ändern, dass das Reading Battery weiterhin ein Event erzeugt. Vermutlich müssen dann auch die Zeiten für $FivePercent_ angepasst werden.

Nachrichtenübermittlung:
################################
# Here you choos your message device and how to send
# comment the device you do not want to use
#
# TelegramBot
  my $msg = "set TelegramBot message \@\@User ";
#
# msg-command
# my $msg = "msg \@User title='Battery Check' ";
#
# Pushover
# my $msg = "set Pushover msg device=User title='Battery Check' ";

Es kann eingestellt werden auf welchem weg die Nachricht gesendet werden soll. Dazu muss der entsprechende Teil unkommentiert gesetzt werden. Vorbelegt ist Telegram. Hier muss lediglich das Wort "User" durch den TelegramNamen des Empfängers geändert werden.



BatteryStart:
#Define Dummys for script
my $BatteryStatus = "BatterieStatus"; #Name of the Dummy for status
my $BatteryChanged = "BatterieWechsel"; #Name of the Dummy for battery changed information
my $ReadingsGroup = "rgBatterieStatus"; #Name of the ReadingsGroup
my $Room = "Z_System->BatteryCheck"; #room for the dummys
my $Notify = "NO.BatterieNotify"; #Name of the Notify for sending battery information

Hier werden die Namen für die Dummies und die ReadingsGroupe gesetzt. Wichtig ist, dass die Namen zu den Namen in der ersten Funktion passen. Weiterhin kann man einen Raum ($Room) hinterlegen in welchem automatisch alle Device erstellt werden. Unter $Notify wird der Name für die Notify-Funktion angegeben.


Aktuell werden folgende Typen individuell unterstützt:
- Homematic
- Z-Wave
- Xiamoi
- MAX!
- LaCrosse

Alle anderen Geräte mit der Meldung ok/low oder BatteryLevel werden erkannt und unterstützt, es kann jedoch nur eine Zeit für all diese Geräte gleichzeitig gesetzt werden. Wenn bedarf für weitere Geräte besteht dies bitte mitteilen.



Wichtig
Homematic Device dürfen nicht mit HM_ benannt sein, gleiches gilt für Z-Wave: ZWave_ und MAX: MAX_ da diese sonst ignoriert werden. Die Idee ist, dass diese neu angelegt wurden und daher noch keine Batterieprüfung nötig ist. Sollte jemand seine Geräte entsprechende benannt haben, so muss dieser Teil im Code auskommentiert werden:

# ignoring Devices that were just created by autocreate
  if($DeviceNameParts[0] eq "HM" || $DeviceNameParts[0] eq "ZWave" || $DeviceNameParts[0] eq "MAX")
  {
    Log3(undef, 1, "my_StoreBatteryStatus      ignoring Device: $Device");
    return;
  }
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 12 Januar 2018, 20:05:20
schön :)
aaaber schau nochmal nach den Blumen ( ich habe sie rausgeworfen da ich keine habe )
syntax error at ./FHEM/99_myUtils.pm line 371, near "XiaomiFlowerSens Devices ############################################# elsif" syntax error at ./FHEM/99_myUtils.pm line 436, near "}" Can't use global @_ in "my" at ./FHEM/99_myUtils.pm line 443, near "= @_" Global symbol "$Value" requires explicit package name (did you forget to declare "my $Value"?) at ./FHEM/99_myUtils.pm line 444. syntax error at ./FHEM/99_myUtils.pm line 472, near "}" Can't redeclare "my" in "my" at ./FHEM/99_myUtils.pm line 481, near "" syntax error at ./FHEM/99_myUtils.pm line 515, near ") }"
da fehlt oben das # vor  XiaomiFlowerSens Devices

und bei HM muss die VCCU noch raus ... meine hat keine Batterie :)
Wenn du eh noch LaCrosse machen möchtest schaue ich mal nach einem Block für MAX!

Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 12 Januar 2018, 20:38:05
Für MAX! Geräte muss oben noch eine Zeile dazu denn sie haben kein Attribut model :
my $TYPE = InternalVal($Device, "TYPE", "undef"); # MAX!
und dann ein copy & paste  Block

  ##############################################
  # MAX! Devices
  ##############################################
  elsif(($BatteryType[0] eq "battery")  && ($TYPE eq "MAX"))
  {
    if(ReadingsVal($Device, "battery", "low") eq "ok")
    {
      # check if battery was low before -> possibly changed
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low")
      {
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $BatteryChanged $text_changed");
        # set the signal state back to none
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }

      # status is "ok" so we set to 100% (we don't know better)
      fhem("setreading $BatteryStatus $Device 100");
    }
    else
    {
      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem("set $myTelegramBot message $text_soon");
      }

      # status is NOT "ok" ("low") so we set to 0% (we don't know better)
      fhem("setreading $BatteryStatus $Device 0");
    }
  }


EDIT :
# ignoring Devices that were just created by autocreate
  if($DeviceNameParts[0] eq "HM" || $DeviceNameParts[0] eq "ZWave")  || $DeviceNameParts[0] eq "MAX")

 
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 13 Januar 2018, 00:28:45
Toll wie das weiter geht!

Vielen Dank an Amenophis86 für's "Verbreiten"!

Kleine Anmerkung:

  # actually only devices HM-TC-IT-WM-W-EU and HM-CC-RT-DN have battery level and min-level

bezieht sich halt auf meinen "Flohzirkus" ;)

Wenn es weitere Geräte von HM gibt, die ebenfalls Spannungswerte liefern, dann eben den entsprechenden Typen hier hinzufügen.
Ansonsten sollten sie aber zumindest als "normale" Batterie-Geräte mit "ok/nok/low" aufgenommen werden.

Vielleicht schaffe ich es auch die Batteriehaltbarkeit mit aufzunehmen, also eine Statistik der letzten Batteriewechsel und dann eben die Lebensdauer etc.

Oder kann da eines der bestehenden Statistik-Module verwendet werden?

Gruß und viel Spaß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 13 Januar 2018, 10:52:36
Zitat von: Wzut am 12 Januar 2018, 20:05:20
schön :)
aaaber schau nochmal nach den Blumen ( ich habe sie rausgeworfen da ich keine habe )
Danke geändert. Ich habe sie bei mir auskommentiert und beim einkommentieren wohl ein Zeichen zu viel weggenommen.

Zitat
und bei HM muss die VCCU noch raus ... meine hat keine Batterie :)
Die taucht bei mir nicht auf. Dürfte sie auch nicht, weil sie eigentlich auch kein battery/Level Reading haben dürfte. Daher frage ich mich, wieso sie bei dir erscheint?

Deinen Max Block habe ich eingefügt.

Ich habe das ganze mal auf mein github gelegt. Habe das gerade zum ersten Mal gemacht und wenig Ahnung davon, aber das könnte es einfacher machen mit den Änderungen etc. und ich habe ein kleines Projekt mit dem ich üben kann. Hier ist der Link: https://github.com/Amenophis86/Batteryfunktion
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 13 Januar 2018, 14:29:51
Zitat von: Amenophis86 am 13 Januar 2018, 10:52:36
Daher frage ich mich, wieso sie bei dir erscheint?
--- snipp ---
Deinen Max Block habe ich eingefügt.
a. das hatte ich mich auch gefragt , werde mal auf die Suche gehen, ist ja jetzt nicht so ein tragischer Fehler

b. Mit MAX! erigibt sich leider ein anderes Problem ... ich habe z.Z. zufällig ein unbenutzes Device mit alter Batterie -> Daueranzeige seit Wochen low
und eines bei dem die Batterie so langsam an ihr Lebensende kommt. Und genau hier liegt das Problem mit den MAX! Geräten das ich so auch schon im MAX! Forum beschrieben hatte. Leider wechseln die Geräte nicht irgendwann von ok auf low und bleiben dann auf low, sondern das low verschwindet nach ein paar Minuten wieder.
Am Anfag kommt die low Meldung 1 -2 am Tag , dann im Abstand von Stunden und irgendwann bleibt sie wirklich dauerhaft auf low. Das ist dann der Zeitpunkt wo ich die Batterien tausche und mir das Wechseldatum von Hand ins Comment Attibut schreibe. Ich dachte noch oh tolll das kannst du dir in Zukunft sparen, ist aber leider nicht so, denn dadurch das die Meldung sich von selbst zurücksetzt geht der Codeschnipsel von einem manuellen Batterie Tausch aus, was aber ja nicht stimmt.
Mal schauen ob mir da was sinnvolles zu einfällt, ala Logging der Zeitstempel und deren Auswertung.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: helmut am 13 Januar 2018, 16:09:44
Zitat von: Amenophis86 am 13 Januar 2018, 10:52:36
https://github.com/Amenophis86/Batteryfunktion

Ein Fluechtigkeitsfehler steht in Form einer doppelten runden schliessenden Klammer in Zeile 51.

Das Projekt interessiert mich wegen des Zusatznutzens von "BatterieWechsel" und gegebenenfalls
"Batteriehaltbarkeit". Allerdings werde ich es fuer meine Zwecke anpassen da ich mich zur Zeit
per E-Mail und Signal mittels eines Notifys fuer Batterien mit Zustand "low" benachrichtigen lasse.

Signal durch Telegram zu ersetzen waere durchaus eine Ueberlegung wert; auf die Benachrichtigung
per E-Mail will ich aber nicht verzichten.

Gruss Helmut
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 13 Januar 2018, 17:44:31
@Wuzt ich überlege auch mal
@helmut einbauen, dass man auf verschiedenen Wegen verschickt ist ja nicht so schwer. Gerade mit dem msg Befehl zB. Aber auch im Script könnte man eine Auswahl setzen.

Den Fehler schaue ich mir später an, bin die Tage unterwegs.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 14 Januar 2018, 19:56:37
@Wzut:
Zum Verständnis nochmal für mich. MAX wechselt immer wieder den Status zwischen low und ok und bleibt dann irgendwann bei low. Wie lange das dauert ist nicht klar, oder? Von der Idee her müsste man quasi eine Verzögerung für MAX einbauen, also einen Zwischenspeicher in dem der letzte Wechsel auf low steht und die Meldung, so wie ein Batterie tausch erst einstellen, wenn ein gewisser Zeitstempel überschritten wurde. Dabei sehe ich folgende Probleme:
1. Wenn jemand direkt beim ersten low die Batterie wechselt würde das Script das nicht erkenne
2. Wie lange muss man warten bis es bei low bleibt

Hast du mal mit dem Maintainer des MAX Moduls gesprochen woran es liegt, dass der Status gegen Ende immer wechselt? Sendet das Gerät immer wieder andere Signale und wieso wird es nicht direkt dort abgefangen? Habe mal in den Quellcode geschaut, aber werde nicht schlau draus. Fehlt mir wohl die Doku der MAX Signale zu.

Edit:
@Wzut: Habe gerade deinen Beitrag im alten Thema gefunden, da hast du es ja ganz gut beschrieben. Bleibt die Frage, wie wir das Problem lösen. Ich tendiere zum warten, bis die Meldung dauerhaft bleibt.

@helmut:
Fehler habe ich korriegiert, vielen Dank. Bezüglich der verschiedenen Nachrichten sehe ich wie gesagt drei Möglichkeiten:
1. Einfach den Befehle für das Senden der Nachricht vorab definieren und die verschiedenen Geräte zu unterstützten
2. Eine eigene Routine für das Senden schreiben, finde ich sehr aufwendig und unnötig
3. Den msg befehl einbauen
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: helmut am 14 Januar 2018, 20:09:23
Zitat von: Amenophis86 am 14 Januar 2018, 19:56:37
@helmut:
Fehler habe ich korriegiert, vielen Dank. Bezüglich der verschiedenen Nachrichten sehe ich wie gesagt drei Möglichkeiten:
1. Einfach den Befehle für das Senden der Nachricht vorab definieren und die verschiedenen Geräte zu unterstützten
2. Eine eigene Routine für das Senden schreiben, finde ich sehr aufwendig und unnötig
3. Den msg befehl einbauen

Nachdem ich mir den ausgesprochen maechtigen msg Befehl genauer angesehen habe halte ich
die dritte fuer die beste Loesung.

Gruss Helmut
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 15 Januar 2018, 11:26:29
@Amenophis86 , ich denke das etwas komische Verhalten der MAX! Geräte ist den e3q Entwicklern anzulasten und nicht M.Gehre als Autor der Module ( er ist hier auch nicht mehr aktiv um noch mal Rückfragen zu können)
Klar wenn der User sehr schnell auf die Batterie Warnung reagiert dann klappt das so in der jetzigen Form nicht,
allerdings Hand aufs Herz : wer springt sofort auf und wechselt ? Zumal die Meldung unmittelbar an der Warngrenze wieder relativ schnell verschwinden.

Noch eien andere Sache ist mir aufgefallen : Der Dummy BatterieWechsel sollte sich ja so nach und nach mit den Daten getauschter Batterien füllen, das tut er aber z.Z. nur bedingt ( bei MAX u.a. so nicht )
Ursache ist IMHO ein kleiner Tippfehler, du hast den Eintrag in die Readings unterschiedlich behandelt, mal mit Device Namen und mal ohne :
fhem("setreading $BatteryChanged $text_changed");
fhem("setreading $BatteryChanged $Device $text_changed");





Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 15 Januar 2018, 11:33:09
Original war es:

fhem("setreading $BatteryChanged $text_changed"); ;)

Evtl. kann man bei MAX! etwas mit ReadingsAge arbeiten, dazu müsste man wissen, wie lange es hin und her "flipt" bis es "stabil" bleibt...

Voraussetzung ist dann (aber das habe ich generell), dass für die Batteriewerte/Readings kein event-on-change-reading gesetzt ist...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 15 Januar 2018, 14:53:44
Habe mir die Doku von Max mal angesehen, da gibt es nicht viel zu Batterien. Daher legt es wohl wirklich alleine am Gerät was einfach nur low oder ok übermittelt. Denke es wird nur über ReadingsAge gehen, wie MadMax schon sagt. @wzut: kannst du grob sagen, welcher Zeitabstand zum Warten Sinn macht?

Bezüglich des Fehlers muss ich nochmal schauen, danke für den Hinweis.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 15 Januar 2018, 18:31:15
Zitat von: Wzut am 15 Januar 2018, 11:26:29
Noch eien andere Sache ist mir aufgefallen : Der Dummy BatterieWechsel sollte sich ja so nach und nach mit den Daten getauschter Batterien füllen, das tut er aber z.Z. nur bedingt ( bei MAX u.a. so nicht )
Ursache ist IMHO ein kleiner Tippfehler, du hast den Eintrag in die Readings unterschiedlich behandelt, mal mit Device Namen und mal ohne :
fhem("setreading $BatteryChanged $text_changed");
fhem("setreading $BatteryChanged $Device $text_changed");


Hattest du den Fehler im Code im 1. Post gesehen, oder auf github? Hab gerade mal auf github geschaut und finde den von dir angesprochenen Fehler nicht.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 16 Januar 2018, 07:02:29
Ja , was sage ich zum Interval .... ich versende keine Mails bei Bat low sondern lasse mir diese Art von Meldung schon seit Jahren im TV Bild unten anzeigen.
Daher weiß ich nur was so am Abend los ist und weniger am Tag/Nacht
Fensterkontakte : Hatte ich noch nie eine low Meldung, die scheinen verdamt lang zu halten.
HT & WT : Da kommt zuerst 1 - 2 am Abend die low Meldung für 10 Min - 30 Min , meist ist dann ein paar Tage Sendepause. Danach habe ich sie jeden Abend.
Wenn sie gar nicht mehr verschwindet erbarme ich mich i.d.R. sie dann zeitnah zu tauschen, d.h. ich glaube wenn die Meldung mal 24 Stunden dauerhaft da war geht sie auch nicht mehr von alleine weg. Ich lege jetzt mal ein eigenes Filelog für die Batterien an dann kann ich in ein paar Wochen/Monaten bestimmt mehr dazu sagen.
Was man allerdings sofort machen könnte ist schon beim ersten auftreten der low Meldung die Restanzeige auf nur noch 50% setzen und die "müsste bald gewechselt" Meldung absetzen.
     
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 16 Januar 2018, 10:00:54
Zitat von: Amenophis86 am 15 Januar 2018, 18:31:15
Hab gerade mal auf github geschaut und finde den von dir angesprochenen Fehler nicht.

Bitte schön , gerade eben von github geholt. Zwave & Xiaomi sind OK da $Device vorhanden,
die anderen drei sind IMHO fehlerhaft da später immer das gleiche Reading überschrieben wird ohne Devicename

  # HM Devices with battery
  fhem("setreading $BatteryChanged $text_changed");
  # HM Devices with batteryLevel
  fhem("setreading $BatteryChanged $text_changed");
  # ZWave Devices
  fhem("setreading $BatteryChanged $Device $text_changed");
  # XiaomiFlowerSens Devices
  fhem("setreading $BatteryChanged $Device $text_changed");
  # MAX! Devices
  fhem("setreading $BatteryChanged $text_changed");
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Firetic am 16 Januar 2018, 12:40:57
Ich glaube durch die "BatteryStart()" Funktion wird das notifiy falsch definiert?!

Es müsste doch {BatteryStatusFunction(\$NAME, \$EVENT)} anstatt {BatterieStatusFunction(\$NAME, \$EVENT)} heißen...


Gruß Firetic
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 16 Januar 2018, 17:34:14
Zitat von: Wzut am 16 Januar 2018, 10:00:54
Bitte schön , gerade eben von github geholt. Zwave & Xiaomi sind OK da $Device vorhanden,
die anderen drei sind IMHO fehlerhaft da später immer das gleiche Reading überschrieben wird ohne Devicename

  # HM Devices with battery
  fhem("setreading $BatteryChanged $text_changed");
  # HM Devices with batteryLevel
  fhem("setreading $BatteryChanged $text_changed");
  # ZWave Devices
  fhem("setreading $BatteryChanged $Device $text_changed");
  # XiaomiFlowerSens Devices
  fhem("setreading $BatteryChanged $Device $text_changed");
  # MAX! Devices
  fhem("setreading $BatteryChanged $text_changed");


Da hat mich meine Suche gestern doch echt überlistet. Habe es jetzt gefixt, hoffe ich habe nicht wieder eins übersehen.

Zitat von: Firetic am 16 Januar 2018, 12:40:57
Ich glaube durch die "BatteryStart()" Funktion wird das notifiy falsch definiert?!
Es müsste doch {BatteryStatusFunction(\$NAME, \$EVENT)} anstatt {BatterieStatusFunction(\$NAME, \$EVENT)} heißen...
Gruß Firetic

Oh, da war noch eine alte Version im git gepusht. Muss da echt noch mit üben, sry. Habe ich auch gefixt.


Ich hoffe, dass ich am Wochenende dazu kommen mal das temporäre einzubauen. Aktuell bin ich zeitlich ziemlich eingespannt.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 18 Januar 2018, 20:04:27
So, habe mal TelegramBot / Pushover und den msg Befehl eingebaut. Muss man halt auf seine Bedürfnisse anpassen den String.

Bezüglich Max dauert noch ein bisschen.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 20 Januar 2018, 19:01:47
Ich überlege aktuell wie man das MAX Problem lösen kann, komme aber einfach nicht weiter. Mir fehlt die Logik, wie man es prüfen kann. Entweder ist das Problem, dass es "ok" meldet, weil kein Batterie wechsel stattgefunden hat und es nur eine verfrühte Meldung war, oder es ist "ok", weil ein Batteriewechsel stattgefunden hat. Das lässt sich jedoch in keinem Fall unterscheiden. Daher sehe ich aktuell keine Möglichkeit, wie es automatisiert werden kann, dass der Batteriewechsel sicher gespeichert wird.
Auch eine verzögerte Abfrage hilft nicht viel, weil man genau den Zeitpunkt des Wechsels abpassen müsste, sonst bekommt man wieder nur ein "ok" und weiß nicht warum.

Man müsste quasi anders merken, dass die Batterie gewechselt wurde. Gibt es ein Reading bei Max was sich quasi nur ändert, wenn die Batterie gewechselt wurde. Habe gerade mal bei meinen HM-CC-RT-DN geschaut, da gibt es ein Reading powerOn, da muss ich die Tage mal testen, ob das ist wann er das letzte mal eingeschaltet wurde. Das wäre für den Batteriewechsel natürlich top. Hat MAX! das auch?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: SibbeH am 20 Januar 2018, 21:06:33
Bei mir ist es so das bei einen Batterie-wechsel das Group-ID auf 0 zurück wird gesetzt. Sollte man als Lösung für deines Problem Group-ID brachen muss es nach ein Batterie-wechsel neu eingestellt werden.

Grüss
Sibbe
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 20 Januar 2018, 21:08:53
Kannst du mir mal ein list von einem MAX Thermostat posten, dass ich das sehen kann. Danke für die Info. Dh aber auch, dass die bei 0 ist, wenn man sie nie verändert hat?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: SibbeH am 20 Januar 2018, 21:12:32
Ich habe jeder Raum ein eigenes Group-ID vergeben.
Wohnzimmer 1
Kuche 2
usw

Internals:
   DEF        HeatingThermostat 0f8955
   IODev      cm
   LASTInputDev cm
   MSGCNT     9954
   NAME       MAX_CV_Keuken
   NR         278
   RSSI       -60
   STATE      15.0 °C
   TYPE       MAX
   addr       0f8955
   backend    cm
   cm_MSGCNT  9954
   cm_TIME    2018-01-20 21:09:26
   dstsetting 1
   mode       0
   rferror    0
   type       HeatingThermostat
   READINGS:
     2018-01-20 21:09:26   RSSI            -60
     2015-11-06 21:11:18   TimeInformationHour 2
     2018-01-20 21:09:26   battery         ok
     2015-11-06 21:54:01   boostDuration   5
     2015-11-06 21:54:01   boostValveposition 80
     2015-11-06 21:54:01   decalcification Sat 12:00
     2018-01-20 21:09:26   desiredTemperature 15.0
     2017-02-17 15:13:45   firmware        1.0
     2017-02-17 15:31:59   groupid         2
     2015-11-06 22:57:47   maxValveSetting 100
     2018-01-20 21:09:26   mode            auto
     2018-01-20 15:12:13   msgcnt          124
     2016-05-20 21:21:30   onlyAutoMode    0
     2018-01-20 21:09:26   state           15.0 °C
     2018-01-20 19:00:35   temperature     19.6
     2017-02-17 15:13:45   testresult      161
     2015-11-06 21:54:01   valveOffset     0
     2018-01-20 21:09:26   valveposition   0
     2016-05-27 19:36:51   weekprofile-0-Sat-temp 15.0 °C  /  19.0 °C  /  15.0 °C  /  15.0 °C
     2016-05-27 19:36:51   weekprofile-0-Sat-time 00:00-07:30  /  07:30-22:00  /  22:00-23:55  /  23:55-00:00
     2016-05-27 19:36:51   weekprofile-1-Sun-temp 15.0 °C  /  19.0 °C  /  15.0 °C  /  15.0 °C
     2016-05-27 19:36:51   weekprofile-1-Sun-time 00:00-07:30  /  07:30-22:00  /  22:00-23:55  /  23:55-00:00
     2016-05-27 19:36:51   weekprofile-2-Mon-temp 15.0 °C  /  19.0 °C  /  17.0 °C  /  19.0 °C  /  17.0 °C  /  15.0 °C
     2016-05-27 19:36:51   weekprofile-2-Mon-time 00:00-05:15  /  05:15-07:30  /  07:30-16:00  /  16:00-19:00  /  19:00-23:55  /  23:55-00:00
     2016-05-27 19:36:51   weekprofile-3-Tue-temp 15.0 °C  /  19.0 °C  /  17.0 °C  /  19.0 °C  /  17.0 °C  /  15.0 °C
     2016-05-27 19:36:51   weekprofile-3-Tue-time 00:00-05:15  /  05:15-07:30  /  07:30-14:00  /  14:00-19:00  /  19:00-23:55  /  23:55-00:00
     2016-05-27 19:36:51   weekprofile-4-Wed-temp 15.0 °C  /  19.0 °C  /  15.0 °C  /  19.0 °C  /  17.0 °C  /  15.0 °C
     2016-05-27 19:36:51   weekprofile-4-Wed-time 00:00-05:15  /  05:15-07:30  /  07:30-14:00  /  14:00-19:00  /  19:00-23:55  /  23:55-00:00
     2016-05-27 19:36:51   weekprofile-5-Thu-temp 15.0 °C  /  19.0 °C  /  17.0 °C  /  19.0 °C  /  19.0 °C  /  15.0 °C
     2016-05-27 19:36:51   weekprofile-5-Thu-time 00:00-05:15  /  05:15-09:00  /  09:00-15:00  /  15:00-19:00  /  19:00-23:55  /  23:55-00:00
     2016-05-27 19:36:51   weekprofile-6-Fri-temp 15.0 °C  /  17.0 °C  /  19.0 °C  /  15.0 °C
     2016-05-27 19:36:51   weekprofile-6-Fri-time 00:00-07:30  /  07:30-19:00  /  19:00-23:55  /  23:55-00:00
   internals:
     interfaces thermostat;battery;temperature
Attributes:
   IODev      cm
   room       Keuken


Sibbe
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 20 Januar 2018, 21:32:40
Und man muss wirklich jedes Mal nach dem Batteriewechsel die Groupid neu vergeben? Dann könnte man darauf aufbauen. Danke für die Info und das list.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 21 Januar 2018, 08:45:13
Das mit der groupid klimgt gut. Ich muss gestehen die noch nie bei einem meiner Geräte gesetzt zu haben da ich sie nicht brauche.
Gerade mal mit meinem WT am Schreibtisch getestet : groupid auf einen Wert != 0 , Reading ändert sich. Bat raus und wieder rein, groupid == 0 :)
Also würde ich folgenden Ansatz wählen :
1. Bei einem Bat low && groupid != 0 && Level == 100 , Bat Level auf 50 runtersetzen und ggf Warn Meldung mit "müsste demnächst gewechselt werden".
2. Bat wird wieder zu ok aber groupid bleibt auf >0 , Status OK aber Level auf  50 stehen lassen als Merker "da war schon mal was"  , temporäres at löschen.
3. Bat low && groupid != 0 && Level < 100 , wieder Warn Meldung und ein temoräres at erzeugen mit einer Laufzeit von 24 Stunden.

Schritt 2 & 3 werden sich nun ein paar Mal wiederholen , irgendwann verschwindet das low aber nicht mehr , da es nun keinen Bat event mehr gibt schlägt das temoräre at zu und setzt den Level auf 0 und die Bat leer Meldung.
Auch jetzt könnte sich 2 & 3 wiederholen was aber ok wäre
4. Es kommt eine Bat OK Meldung Level < 100 aber groupid == 0 : Level zurück auf 100 und Eintrag in die Wechsel Liste.

Bei dem Spiel gehe ich davon aus das an jedem Device event-on-change-reading zumindest für battery gesetzt ist.
Man sollte sich auch mal überlegen wie es auschauen würde wenn es nicht so wäre und jeder Bat Event zum Überwachugs notify durch geht.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 21 Januar 2018, 08:58:45
So war auch meine Logik, muss nur schauen, wann ich dazu komme. Aber zumindest sind wir jetzt ein bisschen weiter :)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: SibbeH am 21 Januar 2018, 14:28:28
@ Amenophis86
Gerne gemacht

Bei mir kommt die Meldung Bat low, wenn der Entkalkungsfarhrt ausgeführt wird. Das Motorchen von das HT zieht dann so viel Strom, dass die Batteriespannung unter 2,4 V kommt. Ich habe gelesen das darum auch kein wiederaufladbare Batterien gebraucht werden können, weil sie ein Spanning von nur 1,2 V haben.
Später wird die Meldung Bat low auch dann ausgegeben, wenn das Motorchen von das HT eine "längere Fahrt" für das Heizventil machen sollte.

@Wzut
Wunsch für die Zukunft:
5. Wenn das Level wieder auf 100 zurückgesetzt wurde und die Wechselung in der Liste verarbeitet wurde, sollte Groupid wieder auf den alten Wert zurückgesetzt werden.

Grüss
Sibbe
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 21 Januar 2018, 15:06:16
Zitat von: SibbeH am 21 Januar 2018, 14:28:28
5. Wenn das Level wieder auf 100 zurückgesetzt wurde und die Wechselung in der Liste verarbeitet wurde, sollte Groupid wieder auf den alten Wert zurückgesetzt werden.
Das sollte kein großes Problem sein. Lässt sich IMHO recht elegant mit einem userattr groupid an jedem MAX Device lösen, das bleibt einmal gesetzt schön dauerhaft in der config. U.a. kann man dann auch die ganze MAX Batterie Überwachung daran festmachen, D.h. gesetzt wird das Device berücksichtigt, nicht gesetzt wird es links liegen gelassen. Mal schauen, vermutlich werde ich im Laufe der nächsten Woche etwas Zeit zum basteln haben.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 21 Januar 2018, 15:34:29
Zitat von: SibbeH am 21 Januar 2018, 14:28:28
Bei mir kommt die Meldung Bat low, wenn der Entkalkungsfarhrt ausgeführt wird. Das Motorchen von das HT zieht dann so viel Strom, dass die Batteriespannung unter 2,4 V kommt. Ich habe gelesen das darum auch kein wiederaufladbare Batterien gebraucht werden können, weil sie ein Spanning von nur 1,2 V haben.
Später wird die Meldung Bat low auch dann ausgegeben, wenn das Motorchen von das HT eine "längere Fahrt" für das Heizventil machen sollte.

Sollte ja beim verwendeten Code nicht passieren, da für die Heizköper- und Wandthermostate (ok, nur von HomeMatic) ja anhand der LowBatLimit (HT: 2,1V / WT: 2,2V) "gerechnet" wird.
Das "normale" battery Reading wird dort gar nicht ausgewertet...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: SibbeH am 21 Januar 2018, 16:34:17
Ich wollte nur angeben warum bei MAX die Meldung Bat low so often wechselt....
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 22 Januar 2018, 10:36:58
Ich bin gerade auf diesen thread gestossen und finde die Idee dahinter sehr gut, aber in den letzten Beitägen versucht ihr über die groupid einen Zwischenstatus zu speichern.
Das funktioniert nicht wenn der MAX-Cube und Fensterkontakte verwendet werden. Über die groupid werden die Fensterkontakte den passenden Heizungsreglern zugeordnet.

Readings Fensterkontakt hinzugefügt

MAXLAN_error 0
MAXLAN_errorInCommand
MAXLAN_initialized 1
MAXLAN_isAnswer 0
MAXLAN_valid 100
RSSI -75
battery ok
firmware 1.4
groupid 2
onoff 0
state closed
testresult 15
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 22 Januar 2018, 11:27:49
Wieso? Wenn eine GroupID vergeben wurde wird diese auf 0 gesetzt nach einem Tausch. Wenn keine vergeben wurde, dann muss der Nutzer nur eine fiktive einmalig vergeben um auf diese zu triggern, wenn sie wieder 0 ist. Nach dem Tausch wird dann entweder die alte wieder gesetzt, oder die fiktive.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 22 Januar 2018, 11:29:36
ist doch schön dann gibt es ein Reading groupid - genau darum geht es erst einmal.
Die Frage ist allerdings wie verhält sich da das Reading bei Batt Wechsel ?
Ich kann das leider nicht nachstellen da ich schon ewig keine Original MAX Software mehr betreibe.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 22 Januar 2018, 11:30:42
Die IDs werden im Cube passend zu den Geräten gespeichert und haben sich bei mir bisher beim Batteriwechsel in den Thermostaten nicht verändert. Bei den Fensterkontakten habe ich bislang noch keine Batterien getauscht.

Ich werde mal testweise alte Batterien in einen Fensterkontakt und in einen Thermosaten einbauen und testen.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 22 Januar 2018, 11:32:50
OK, dann fällt auch das zum Thema Bat Wechsel Erkennung raus. D.h. es bleibt dann wohl wirklich nur die Alternative des Nachschauens auf eine lang anstehende Meldung.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 22 Januar 2018, 12:37:58
Ich habe gerade mal bei einem Thermostaten eine leere und eine volle Batterie eingesetzt. Nach den Lernfahrten waren alle vorherigen Einstellungen bezüglich des Wochenprofils und der Kopplung mit dem Fensterkontakt wieder vorhanden.
Die Batterieleerwarnung wird in Kürze wohl detektiert.

Dann habe ich bei einem Fensterkontakt die Batterien entfernt und an ein regelbares Netzteil angeschlossen.
Auch hier bleibt die Zuordnung erhalten.
Bei Batteriespannungen unterhalb von 2,4 Volt wird nach längerer Zeit oder direkt beim Auslösen des Kontakts der Batterieleerstatus übermittelt. Bei Spanungen von ca 2 Volt funktioniert der Fensterkontakt garnicht mehr.
Wenn die Spannung wieder ansteigt, erlischt die Batteriewarnung. Eine zuerlässige Erkennung ob die Batterie getauscht wurde ist somit nicht möglich. Beim MAX!System werden leider keine Zwichenwerte übermittelt, aus denen man eine erneuerte Batterie ableiten könnte.
Auch die anderen Readings ändern sich nicht.

Wäre es möglich über eine Taste den Batteriewechsel manuell einzutragen?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Mitch am 22 Januar 2018, 13:01:21
Grundsätzlich sehr nett, aber ich habe noch einige Probleme damit.

1. ich habe einige Devices, die zwar ein Reading battery haben, aber nicht mit einbezogen werden sollen
2. habe ich viel zu viele Logeinträge
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 Januar 2018, 13:05:19
Zitat von: _fhemuser_ am 22 Januar 2018, 12:37:58
Wäre es möglich über eine Taste den Batteriewechsel manuell einzutragen?

Da letztendlich "nur" ein "setreading BattWechselDummy Batterie gewechselt" ausgeführt wird lässt sich das machen...

Z.B. per webCmd etc.

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 22 Januar 2018, 14:39:46
Hört sich an, als ob aus dem Codeteil eher ein Modul werden muss um allen Ansprüchen gerecht zu werden :D
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Mumpitz am 22 Januar 2018, 19:57:15
hallo zusammen

ich wollte mir soeben das Script holen und es einmalig ausführen. Nun habe ich jedoch festgestellt, dass im git ein Modul 99_batterycheck.pm vorhanden ist. Leider finde ich jedoch keine entsprechende Doku wie man das Modul definiert...

Jemand eine Idee?

gruess
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 Januar 2018, 20:17:41
Einfach nach /opt/fhem/FHEM kopieren.

Ist quasi eine weitere myUtils.pm

Kurz da nur Handy...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Mumpitz am 22 Januar 2018, 20:25:25
Zitat von: MadMax-FHEM am 22 Januar 2018, 20:17:41
Einfach nach /opt/fhem/FHEM kopieren.

Ist quasi eine weitere myUtils.pm

Kurz da nur Handy...

Gruß, Joachim

habe ich gemacht, und dann?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 Januar 2018, 20:31:54
Siehe erster Post im Thread: z.B. Notify anlegen und Sub aufrufen lassen und zunächst die Initialisierungs-Sub manuell ausführen (sofern sich nix geändert hat)...

So lang ist der Thread ja noch nicht da kann man sich schon noch "durchquälen" ;)

Achja: reload 99_batterycheck.pm oder Neustart von fhem nicht vergessen...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 22 Januar 2018, 20:40:59
Alternativ kannst du den Inhalt der Datei auch einfach in deine vorhanden 99_myUtils einfügen. Zum starten musst du nur die Funktion BatteryStart() ausführen. Das geht indem du in der Commandozeile { BatteryStart()} eingibst und Enter drückst. Vorher die entsprechenden Variablen anpassen.

Steht aber auch alles im ersten Post, außer wie man die Funktion aufruft ;)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 22 Januar 2018, 20:53:45
Wenn ich mir die Diskussion von heute ansehe, dann ist es bei MAX! wohl wirklich so, dass wir uns nur auf die Zeit einstellen müssen. Das ist ziemlich doof, gerade solange es sich um einen Code und kein Modul handelt. Mal sehen, ob ich das hinbekomme. Ist somit auch aufwendiger zu Programmieren. Versprecht euch nicht zu früh etwas, habe noch einen Test nächste Woche vor mir und bis dahin wenig Zeit zum programmieren. Mal sehen.

Zitat von: Mitch am 22 Januar 2018, 13:01:21
1. ich habe einige Devices, die zwar ein Reading battery haben, aber nicht mit einbezogen werden sollen
Aktuell werden nur HM Device, MAX! (nicht richtig), XiaomiFlower und Z-Wave unterstützt. Da es sich aktuell noch um einen Code und kein Modul handelt, wirst du die entsprechenden Device selbst "deaktvieren" müssen im Code. Nur mal Interessehalber, welche wären das und wieso?

Zitat
2. habe ich viel zu viele Logeinträge
Welche hast du denn? Aktuell kann es nur folgende geben:
# ignoring Devices that were just created by autocreate
  if($DeviceNameParts[0] eq "HM" || $DeviceNameParts[0] eq "ZWave" || $DeviceNameParts[0] eq "MAX")
  {
    Log3(undef, 1, "my_StoreBatteryStatus      ignoring Device: $Device");
    return;
  }

Und dieser kommt, wenn deine Device mit HM / ZWave / MAX heißen. Dh wenn du sie nicht umbenannt hast. Ist das der Fall?

Zitat von: _fhemuser_ am 22 Januar 2018, 12:37:58
Wäre es möglich über eine Taste den Batteriewechsel manuell einzutragen?
Ja eigentlich schon, wäre aber auch wieder ein eigener Code und spricht auch für ein Modul.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 22 Januar 2018, 21:20:54
Meine Intention zum manuellen speichern liegt darin, dass man nicht lange an einem Code rumbasteln muss und nach dem Battriewechsel ein paar Mausklicks betätigen ist nicht zuviel Arbeit.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 23 Januar 2018, 06:56:41
Zitat von: _fhemuser_ am 22 Januar 2018, 21:20:54
Meine Intention zum manuellen speichern liegt darin, dass man nicht lange an einem Code rumbasteln muss und nach dem Battriewechsel ein paar Mausklicks betätigen ist nicht zuviel Arbeit.

Richtig, ich kann auch wenn ich in einen Raum komme einfach den Lichtschalter drücken, dann muss ich keine Präsenzmelder verbauen, Kabel verlegen und entsprechend programmieren. Widerspricht halt dem Sinn eines Smarthomes ;)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 23 Januar 2018, 07:23:26
Zitat von: Amenophis86 am 22 Januar 2018, 20:53:45
Wenn ich mir die Diskussion von heute ansehe, dann ist es bei MAX! wohl wirklich so, dass wir uns nur auf die Zeit einstellen müssen. Das ist ziemlich doof, gerade solange es sich um einen Code und kein Modul handelt. Mal sehen, ob ich das hinbekomme.
Nur kein Stress :) Ich bin mit meinen Tests seit gestern Abend recht weit, bevor ich nun hier die Beta poste noch ein paar grundsätzliche Gedanken.
a. Manueller Eintrag des Wechseldatums
Sollte immer möglich sein , denn schliesslich entscheide ich ob eine neue Batterie irgendwo reingekommen ist oder nicht. Gerade gestern Abend hatte ich wieder so ein Aha Erlebniss bei einem LaCrosse Sensor. Obwohl das Bat Reading noch auf ok stand, schickte der Sensor nur noch ca alle Stunde ein Telegramm. Ein Blick in meine vorhandene Wechselliste sagte letzter Batt Tausch war am 8.10.16. Also Batterien nachgemessen, gesammt Spannung noch ca 2,5V. Batterien getauscht und er sendet wieder alle paar Minuten. Das mal so als kleine Erinnerung für den noch austehenden LaCrosse Teil. Die Batterien hebe ich noch etwas auf, fast leere kann ich im Moment gut gebrauchen. :)

b. MAX :
Ich habe einen z.Z. unbenutzen Fensterkontakt der steht nun schon seit Tagen auf dauerhaft low. Normalerweise stehen bei mir alle battery Readings auf event-on-change-reading, für die jetzige Testerei habe ich einige umgestellt auf event-on-update-reading und siehe da : FKs senden normalerweise  1 x am Tag ein Status Telegramm auch wenn sie nicht betätigt werden, aber dieser Bruder mit seinen fast leeren Batterien haut sein Bat low nun laut Log im Stundentakt raus. Funktion bei open/close ist immer noch gegeben, allerdings leuchtet die grüne LED gefühlt  nicht mehr so hell wie ich es in Erinnerung habe.
Nun zu meiner bisher Beta Version (nachdem ich das Thema groupid wieder komplett entfernt habe) :
Ich setze jetzt beim ersten Auftreten von low den Bat Status von 100 runter auf 75, danach beim jedem neuen low (wenn es in einem Mindestabstand von X Minuten kommt) ziehe ich 5 ab. Ist der Level auf 50 runter (d.h. 5 x low ) geht die soon Mail raus. Sinkt der Level auf 25 runter sende ich die now Mail und erzeuge ein Temp at mit einer Laufzeit von 12 Stunden. Dies wird bei jedem weiteren Bat OK wieder gelöscht und bei low neu angelegt. Allerdings bleibt der Level weiter auf 25. Steht nun ein low dauerhaft 12 Stunden an und das at läuft ab, ruft es BatteryStatusFunction mit dem Pseudo Event dead auf und ich setze den Level auf 0. Sollte nach Level 0 wieder irgendendwann ein Bat ok kommen gehe ich von einem Wechsel aus und trage das Datum in die Liste - fertig
Nach eine Bemerkung zur oben genannten Zeit X : Ich denke man muss hier unterscheiden/aufpassen welche Art von MAX Gerät man hat. Der beschriebene FK  sendete ja brav alle Stunde, aber mein Test Wandthermostat haut jedesmal drei Bat Low innerhalb von 3 Minuten raus. 
Die Lösung mit dem Temp at mag vllt. etwas umständlich wirken, man könnte ja einfach auch mit ReadingsAge auf den letzten Zeitstempel schauen, dann wären aber die User gekniffen die event-on-change-reading verwenden, mit dem Temp at ist man unabhänig von den User Settings.   
     
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 23 Januar 2018, 09:51:13
@Wzut
Deine Idee mit dem herunterzählen des Betteristatus gefällt mir. Dazu noch eine paar Hinweise:

Die Batteriewarnungen bei MAX sind natürlich stark von der Nutzung und dem jeweiligem Gerät abhängig.

Der Fensterkontakt braucht in der Regel kaum Strom und der Strombedarf ist fast konstant. Wenn das Fenster geöffnet ist, fließt geringfügig mehr Strom.

Beim Heizungsthermostaten ist der Strombedarf stark schwankend aufgrund des Motors. Im Ruhezustand ist er vernachlässigbar und je nach benötigter Kraft steigt er auf ca 30 mA an. Dann kann natürlich die Batteriespannung unterschritten werden. Wenn der Motor wieder steht erholt sich die Batterie und die Spannung steigt.

Der Wandthermostat sendet ohne Veränderung irgendwelcher Paramater immer im Minutentakt. Daher sind dort auch viel mehr Batteriewarnungen im Log als beim Fensterkontakt oder den Thermostaten, die seltener senden.

Ich versuche noch einen Zusammenhang zwischen leerer Batterie und Sendestärke bzw dem RSSI-Wert zu finden, dass man darüber eventuell eine Erkennung des Batteriewechsels genauer automatisieren kann.

Dann habe ich noch eine Frage zu den Messages über den TelegramBot den ich bisher noch nicht genutzt habe.
Welchen Nutzernamen mitt ich im Script bei   
Zitatmy $msg = "set TelegramBot message \@\@User ";
eintragen?
Wenn ich den Botnamen eintragen erhalte ich im Log nur:
ZitatDie Batterien von Buro sollten bald gewechselt werden! : Unknown command Die, try help.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 23 Januar 2018, 11:37:21
Du musst den Namen des Telegram empfängers eingeben. Also wenn dein Telegramdevice TelegramBot heißt und dein Account auf welchem du die Nachrichten empfängst hans dann my $msg = "set TelegramBot message \@\@hans ";
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 23 Januar 2018, 14:40:55
@Amenophis86
vielen Dank, werde ich ausprobieren.

Nach vielen Tests mit einem Fensterkontakt und einem Heizungsthermostaten bezüglich der Batteriewarnungen im MAX!System bin ich nicht viel weiter gekommen.
Es wird nur "Batterie Leer" oder "Batterie Voll" ermittelt, es gibt keinen nachweislichen Zusammenhang mit der Sendestärke (RSSI) und dem Batteriezustand. Auch andere Readings ändern sich nicht wie zB testresult.

Dh wenn automatisch ein Batteriewechsel erkannt werden soll, muss der Betteriezustand des Gerätes über eine längere Zeit, ich würde ca 7 Tage empfehlen, geprüft, protokolliert und ausgewertet werden. Eventuell kann der Zeitraum auch gerätespezifisch geändert werden. Bei Heizungsthermostaten länger und anderen Geräte auch kürzer.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 23 Januar 2018, 15:53:05
@_fhemuser_, das sehe ich genau so ! Z.Z. sind meine Zeiten allerdings noch "etwas" kürzer sonst würde ich mit dem testen erst fertig sein mit meiner ersten Rentenauszahlung :)
 
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 23 Januar 2018, 17:00:48
Zitat von: Wzut am 23 Januar 2018, 07:23:26
Gerade gestern Abend hatte ich wieder so ein Aha Erlebniss bei einem LaCrosse Sensor. Obwohl das Bat Reading noch auf ok stand, schickte der Sensor nur noch ca alle Stunde ein Telegramm. Ein Blick in meine vorhandene Wechselliste sagte letzter Batt Tausch war am 8.10.16. Also Batterien nachgemessen, gesammt Spannung noch ca 2,5V. Batterien getauscht und er sendet wieder alle paar Minuten. Das mal so als kleine Erinnerung für den noch austehenden LaCrosse Teil. Die Batterien hebe ich noch etwas auf, fast leere kann ich im Moment gut gebrauchen. :)
Danke für die Info, wenn ich mich dran setze werde ich das beobachten, habe die natürlich auch auf event-on-change stehen

Zitat
b. MAX :
Ich habe einen z.Z. unbenutzen Fensterkontakt der steht nun schon seit Tagen auf dauerhaft low. Normalerweise stehen bei mir alle battery Readings auf event-on-change-reading, für die jetzige Testerei habe ich einige umgestellt auf event-on-update-reading und siehe da : FKs senden normalerweise  1 x am Tag ein Status Telegramm auch wenn sie nicht betätigt werden, aber dieser Bruder mit seinen fast leeren Batterien haut sein Bat low nun laut Log im Stundentakt raus. Funktion bei open/close ist immer noch gegeben, allerdings leuchtet die grüne LED gefühlt  nicht mehr so hell wie ich es in Erinnerung habe.
Nun zu meiner bisher Beta Version (nachdem ich das Thema groupid wieder komplett entfernt habe) :
Ich setze jetzt beim ersten Auftreten von low den Bat Status von 100 runter auf 75, danach beim jedem neuen low (wenn es in einem Mindestabstand von X Minuten kommt) ziehe ich 5 ab. Ist der Level auf 50 runter (d.h. 5 x low ) geht die soon Mail raus. Sinkt der Level auf 25 runter sende ich die now Mail und erzeuge ein Temp at mit einer Laufzeit von 12 Stunden. Dies wird bei jedem weiteren Bat OK wieder gelöscht und bei low neu angelegt. Allerdings bleibt der Level weiter auf 25. Steht nun ein low dauerhaft 12 Stunden an und das at läuft ab, ruft es BatteryStatusFunction mit dem Pseudo Event dead auf und ich setze den Level auf 0. Sollte nach Level 0 wieder irgendendwann ein Bat ok kommen gehe ich von einem Wechsel aus und trage das Datum in die Liste - fertig
Nach eine Bemerkung zur oben genannten Zeit X : Ich denke man muss hier unterscheiden/aufpassen welche Art von MAX Gerät man hat. Der beschriebene FK  sendete ja brav alle Stunde, aber mein Test Wandthermostat haut jedesmal drei Bat Low innerhalb von 3 Minuten raus. 
Die Lösung mit dem Temp at mag vllt. etwas umständlich wirken, man könnte ja einfach auch mit ReadingsAge auf den letzten Zeitstempel schauen, dann wären aber die User gekniffen die event-on-change-reading verwenden, mit dem Temp at ist man unabhänig von den User Settings.   
Ich denke das Temp at ist die beste Lösung. Lässt du ein richtiges Device anlegen, welches man sehen kann, oder nimmst du ein quite sleep? Bei einem AT würde ich diese auch mit -temporary belegen, dass nicht jedes Mal das Fragezeichen hinter dem Save auftaucht. Doof halt nur, wenn der User in der Zeit sein FHEM neustartet.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 23 Januar 2018, 17:08:19
Die generelle Einbindung von LaCrosse wäre ja relativ einfach mittels


##############################################
  # LaCrosse Devices
  ##############################################
  elsif(($BatteryType[0] eq "battery")  && ($TYPE eq "LaCrosse"))
  {
    if(ReadingsVal($Device, "battery", "low") eq "ok")
    {
      # check if battery was low before -> possibly changed
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low")
      {
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $BatteryChanged $Device $text_changed");
        # set the signal state back to none
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }

      # status is "ok" so we set to 100% (we don't know better)
      fhem("setreading $BatteryStatus $Device 100");
    }
    else
    {
      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }

      # status is NOT "ok" ("low") so we set to 0% (we don't know better)
      fhem("setreading $BatteryStatus $Device 0");
    }
  }


Frage ist, ob man jetzt noch auf das Achten muss was du gesagt hast. So lang es sich nicht wie MAX! Verhält sendet es ja nur einmal ein low, so war es zumindest bisher bei mir. Habe auch keins, wo ich aktuell die Batterie fast leer habe. Das heißt die Überwachung, ob die Daten nicht mehr regelmäßig kommen müsste über ein Watchdog / DOIF laufen, welcher im vorliegenden Fall unser Skript mit der Info triggert, dass es weniger wird und die soon-Nachricht raus soll. Über das battery Reading kommen wir da nicht weiter. Ich würde vielleicht mittels das Watchdog auf 50% melden, wenn es nicht mehr alle Minute kommt und bei einem low auf 0%.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 23 Januar 2018, 21:06:15
Zitat von: Amenophis86 am 23 Januar 2018, 17:00:48
Ich denke das Temp at ist die beste Lösung. Lässt du ein richtiges Device anlegen, welches man sehen kann, oder nimmst du ein quite sleep? Bei einem AT würde ich diese auch mit -temporary belegen, dass nicht jedes Mal das Fragezeichen hinter dem Save auftaucht. Doof halt nur, wenn der User in der Zeit sein FHEM neustartet.
Puhh jetzt hast mich auf dem linken Fuß erwischt , ich habe noch nie ats mit -temporary angelgt da ich bis jetzt immer der Meinung war wenn die Zeit realativ und nicht wiederholend ist wird es nicht in der config gespeichert sondern in fhem.save Daher kann es auch wieder gelöscht werden ohne rotes Fragezeichen. Der dazu passende Code wird so auch in meinem SIP Modul verwendet :

anlegen :
my $time_s = strftime("\%H:\%M:\%S", gmtime(43200)); # z.Z. 12 Stunden
        my $error = CommandDefine(undef, "at_BatLow_".$Device." at +".$time_s." {BatteryStatusFunction('".$Device."','battery: dead')}");
        if (!$error) { $attr{"at_BatLow_".$Device}{room} = AttrVal($BatteryStatus,"room","Unsorted"); }
        else { Log3(undef, 3,"$Device, temp at error -> $error"); }

löschen:
delete $defs{"at_BatLow_".$Device}   if (defined($defs{"at_BatLow_".$Device}));

Du siehst ich packe das at auch in den Raum in dem sich der Rest befindet damit es in Unsorted nicht untergeht.
Bei der Gelegenheit noch ne kleine Anmerrkung, ich habe da den Pseudo Event dead eingeführt, ich wollte auch noch :changed dazunehmen für den manuellen Eintrag des Wechseldatums. Die Pseido Events haben IMHO den Vorteil das wir innerhalb der BatteryStatusFunction bleiben können pro Device ohne nochmal was extra dazubauen zu müssen.

Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 23 Januar 2018, 21:17:59
Zitat von: Amenophis86 am 23 Januar 2018, 17:08:19
Das heißt die Überwachung, ob die Daten nicht mehr regelmäßig kommen müsste über ein Watchdog / DOIF laufen, welcher im vorliegenden Fall unser Skript mit der Info triggert
LaCrosse (und andere)  überwache ich schon recht lange mit ReadingsSupervision -> https://forum.fhem.de/index.php/topic,49408.0.html
Stammt in seiner Urform von HCS (dem Autor der LaCosse Module) der wollte es aber damals nicht weiterentwickeln.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 24 Januar 2018, 07:32:12
Zitat von: Wzut am 23 Januar 2018, 21:06:15
da ich bis jetzt immer der Meinung war wenn die Zeit realativ und nicht wiederholend ist wird es nicht in der config gespeichert sondern in fhem.save

Und jetzt hast du mich auf dem kalten Fuß erwischt, dass muss ich zuhause mal testen. Ich hatte im Kopf, dass das Fragezeichen erscheint und habe deshalb teilweise lieber ein quit sleep genutzt, aber schauen wir einfach mal. Der Code selbst gefällt mir sehr gut und sollten wir auch so übernehmen. Insbesondere, da es auch direkt in den entsprechenden Raum geschoben wird. Allerdings muss ich mir das mit pseudo event nochmal ansehen. Habe ich noch nicht zu 100% verstanden :D Aber ich denke der Ansatz ist mir klar und dürfte Sinn machen.

Zitat von: Wzut am 23 Januar 2018, 21:17:59
LaCrosse (und andere)  überwache ich schon recht lange mit ReadingsSupervision -> https://forum.fhem.de/index.php/topic,49408.0.html
Stammt in seiner Urform von HCS (dem Autor der LaCosse Module) der wollte es aber damals nicht weiterentwickeln.
Schöne Sache, werde ich mir genauer anschauen. Ist quasi ein ActionDetector für nicht Homematic Device.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 24 Januar 2018, 08:47:09
Habt ihr auch an die User gedacht die den MAX!Scanner nutzen?
Damit wird alle paar Minuten über den Cube eine Statusänderung an die Thermostate gesandt und Parameter abgefragt. Die Batteriewarnungen werden dann vermehrt gemeldet.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 24 Januar 2018, 09:29:46
Zitat von: Wzut am 23 Januar 2018, 07:23:26
Die Lösung mit dem Temp at mag vllt. etwas umständlich wirken, man könnte ja einfach auch mit ReadingsAge auf den letzten Zeitstempel schauen, dann wären aber die User gekniffen die event-on-change-reading verwenden, mit dem Temp at ist man unabhänig von den User Settings.         
Denke das dürfte damit auch bedacht sein. Ansonsten muss der User sich halt überlegen, wie er event-on setzt, dass er nicht mit Nachrichte bombadiert wird.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 24 Januar 2018, 10:22:06
Zitat von: _fhemuser_ am 24 Januar 2018, 08:47:09
Die Batteriewarnungen werden dann vermehrt gemeldet.
Nicht nur die Warnungen auch die OKs schlagen dann ständig in der Funktion auf. Daher ja mein Vorschlag intern mit   ReadingsAge  zu arbeiten um alles was in nicht ins gewollte Zeitraster passt einfach zu verwerfen. Das Temp at wird nur gebraucht damit später auch ohne Event der Ablauf weiter geht (entweder weil der User on-change benutzt oder aber die Batt so platt ist das es gar keinen echten Event mehr geben kann)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 24 Januar 2018, 10:54:23
Hallo,

ich bin ja nicht sicher, ob das jetzt mit dem "temp-at" und dem "Fragezeichen" geklärt ist aber ich nutze das beispielsweise für die Waschmaschinenbenachrichtigung und die "Tür wurde geöffnet Prüfung".

D.h. ich definiere einen relativen "one shot timer":

defmod at$Devname at +00:10:00 {my_CheckSomething(\"$Devicename\")}

Somit kann ich dann in der Sub "my_CheckSomething" den at-Namen wieder "ermitteln" und weiß auch welches Gerät zu behandeln ist.

Wenn der Timer aus der "Timer-Sub" heraus wieder benutzt werden soll (also quasi sich selber wieder nach einer bestimmten Zeit aufrufen soll), dann muss der (experimentell ermittelt ;)  ) zuerst gelöscht werden und dann mit obigem defmod erneut angelegt werden.
Ansonsten, wenn er nur "außerhalb" gesetzt/defined wird ist er nach dem jeweils einen Aufruf "einfach weg"...

Fragezeichen bzgl. "save config" hatte ich noch nie...


sub my_CheckSomething($)
{
  my ($Devcename) = @_;

  fhem("delete at$Devicename"); # wenn von hier erneut aufgerufen werden soll
 
  # Perform Checks

  fhem("defmod at$Devicename at +00:15:00 {my_CheckSomething{\"$Devicename\")}"); # wenn erneut nach einiger Zeit geprüft werden soll
}


Was ich zugegebenermaßen noch nicht geprüft habe: was passiert wenn der Timer angelegt ist und das System neu gestartet wird während der Timer läuft...

EDIT: die durchzuführenden Checks sollten sich möglichst für alle Geräte (evtl. wie eh schon per "Abfrage des Typs" etc.) in einer Sub durchführen lassen, somit hätte man nur eine weitere Sub für "zyklische Tests" die jeweils pro zu prüfendes Gerät eben mit dem Gerätenamen (oder weiteren/anderen "Kennungen") per "eigenem" at aufgrufen wird...

EDIT2: toll was hier aus ein wenig Code wird!! :)   Vielen Dank!!! Und nat. viel "Spaß" weiterhin damit!

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: nils_ am 24 Januar 2018, 11:16:16
Zitat von: MadMax-FHEM am 24 Januar 2018, 10:54:23
ich bin ja nicht sicher, ob das jetzt mit dem "temp-at" und dem "Fragezeichen" geklärt ist aber ich nutze das beispielsweise für die Waschmaschinenbenachrichtigung und die "Tür wurde geöffnet Prüfung".

zur Fragezeichen-Kalte-Warme-Füße-Problematik:
https://fhem.de/commandref_DE.html#at

ZitatHinweise:
wenn kein * angegeben wird, wird der Befehl nur einmal ausgeführt und der entsprechende at Eintrag danach gelöscht. In diesem Fall wird der Befehl im Statefile gespeichert (da er nicht statisch ist) und steht nicht im Config-File (siehe auch save).

grüße
nils_
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 24 Januar 2018, 12:21:47
Wie immer ein Blick in die CommandRef hilft ;)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 24 Januar 2018, 12:34:38
Also ich meinte geklärt im Sinne: von hier unter den beteiligten Codern ;)

Mir war das mit dem Fragezeichen (also dass es nicht kommt und warum) schon klar ;)

Aber nun weiß ich auch, dass er nicht "verloren geht" bei einem Neustart...

Danke, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 24 Januar 2018, 16:32:31
Zitat von: Amenophis86 am 23 Januar 2018, 11:37:21
Du musst den Namen des Telegram empfängers eingeben. Also wenn dein Telegramdevice TelegramBot heißt und dein Account auf welchem du die Nachrichten empfängst hans dann my $msg = "set TelegramBot message \@\@hans ";
Damit funktioniert die Benachrichtigung leider auch nicht.
Meine Defininiton des TelegramBot:defmod fhembot TelegramBot
attr fhembot allowUnknownContacts 0
attr fhembot cmdKeyword FHEM
attr fhembot cmdRestrictedPeer XXXXXX    <= Peernummer anonymisiert
attr fhembot defaultPeer XXXXXXX
attr fhembot pollingTimeout 120

In der 99_myutils steht:
# TelegramBot
  my $msg = "set fhembot message \@\@xXXXXx_bot ";   <= botname anonymisiert
#
# msg-command
# my $msg = "msg \@User title='Battery Check' ";
#
# Pushover
# my $msg = "set Pushover msg device=User title='Battery Check' ";

Wenn ich in der Kommandozeile eingebe: set fhembot message \@\@xXXXXx_bot also das was im Programm steht, erhalte ich die Meldung: \@\@xXXXXx_bot

Dort sollte aber wohl der Botname nicht mit angezeigt werden. Und Nachrichten über leere Batterien erhalte ich auch nicht.
Bei set fhembot message heute ist Mittwoch, erhalte ich den Text: heute ist Mittwoch
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 24 Januar 2018, 17:06:39
Wenn du es in die Commandozeile eingibst musst du die @ nicht escapen. Dann ist die Frage, wenn du einen Standard Nutzer im fhembot hinterlegt hast, der Nachrichten erhalten soll musst du keinen mehr definieren der die Nachricht erhalten soll. Und das @@User ist NICHT der Name deines Telegrambot, sondern der Name des Geräts welches die Nachricht empfangen soll. Also der Nutzer mit dem du zB auf deinem Handy bei Telegram eingeloggt bist.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 24 Januar 2018, 17:15:33
OK, wenn der Botname nicht angegeben werden muss in meinem Fall, dann müsste die Meldung mit dem Botnamen und dem Text bitte Batterie tauschen übermittelt werden.

Aber es kommt bei Telegram nichts an und im Log steht weiterhin: Die Batterien von Buro sollten bald gewechselt werden! : Unknown command Die, try help.Das deutet darauf hin, dass "Die" kein Befehl ist.
Dann muss der Fehler an einer anderen Stelle im Code sein.
an 4 Stellen im Code steht jeweils:        #send message via TelegramBot
       fhem($msg." ".$text_soon);
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 24 Januar 2018, 17:46:29
Jain, also nochmal von vorne. Der Code my $msg = "set TelegramBot message \@\@hans "; ist der erste Teil der Nachricht. Der zweite Teil ergibt sich aus den Variablen $text_xxx. Wenn bei deinem TelegramBot ein Standarduser für Nachrichten hinterlegt ist, dann musst du nur den Teil mit \@\@User weglassen. Soll heißen in deiner Sub muss stehen: my $msg = "set TelegramBot message  ";.

Ob das klappt kannst du testen, wenn du in deiner Commandzeile folgendes eingibst:
set TelegramBot message Hallo Wenn diese Nachricht bei dir nicht ankommt, dann musst du den user noch mit angeben, wie in der Sub vordefiniert. Den richtigen Usernamen findest du im Reading "Contacts" im TelegrambotDevice. Der Name beginnt immer mit @ und muss zum senden in einer sub mit einem zweiten @ geschrieben werden, die wiederum escaped werden muss durch \. Es handelt sich somit nicht um einen Fehler im Code, sondern um einen Verständnisfehler.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 24 Januar 2018, 18:01:15
Zitat von: Amenophis86 am 24 Januar 2018, 17:46:29
Ob das klappt kannst du testen, wenn du in deiner Commandzeile folgendes eingibst:
set TelegramBot message Hallo
Das funktioniert problemlos.

Da die Benachrichtigung nur einmal versandt wird, muss ich erst wieder volle Batterien einsetzen und dann wieder leere.

Bei dem ganzen Testen mit Batterien und Netzteil scheint sich heraus zu stellen, dass einige MAX!Geräte anders reagieren. Eventuell ist das auf eine Änderung der Hardwererevision oder Firmwarerevision zurück zu führen.
Bei einem HT, ich glaube der hat die zweite Hardwarerevision, ändert sich innerhalb von bis jetzt 2 Stunden der Batteriezustand nicht auf Voll obwohl die Batterispannung 3 Volt hat. Wenn die Batterien komplett entfernt werden und die Adaptierfahrt durchgeführt wird ist die Batteriewarnung gelöscht. Bei dem HT werde ich vorerst die Batterien nicht tauschen um zu sehen, ob die Batteriewarnung sich später selbst löscht.
Den Effekt, dass die Bateriewarnung schwankt, kann ich mit dem HT und dem Netzteil nicht nachstellen.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 24 Januar 2018, 18:37:35
Zitat von: _fhemuser_ am 24 Januar 2018, 18:01:15
Das funktioniert problemlos.
Dann musst du den Code nur wie folgt anpassen:
my $msg = "set TelegramBot message  ";

Zitat
Bei einem HT, ich glaube der hat die zweite Hardwarerevision, ändert sich innerhalb von bis jetzt 2 Stunden der Batteriezustand nicht auf Voll obwohl die Batterispannung 3 Volt hat. Wenn die Batterien komplett entfernt werden und die Adaptierfahrt durchgeführt wird ist die Batteriewarnung gelöscht.
Soll heißen das Reading Battery bleibt auf low stehen, obwohl du neue volle Batterien einfügst?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Intruder1956 am 24 Januar 2018, 18:59:13
ich habe auch einen Sensor CUL_TCM Auriol der lässt sich nicht auf battery ok bewegen.
battery
low
2018-01-20 15:15:30
mode
normal
2018-01-20 15:16:03
other
10.2
2018-01-24 18:55:16
state
T: 10.2
2018-01-24 18:55:16
trend
rising
2018-01-24 11:10:31


habe mit neuen Batterien und frisch geladene Akkus probiert und zu letzt wieder neue Batterien, immer auf "low"
Ich denke da wird was im Modus nicht richtig interpretiert.

Gruß
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 24 Januar 2018, 19:21:32
Wenn du meinst, dass er nicht erfasst wird und keine Meldungen absetzt, dann ist das richtig. Aktuell werden nur die im ersten Post genannten Device unterstützt. Aber eigentlich könnte man auch einen allgemeinen Teil einsetzen, welcher nur auf low und ok hört. Setze mich da mal dran.

Edit:
Ich habe mal einen Test-Branche auf dem git erstellt. Dieser unterstützt nun LaCrosse in einem extra Block, damit wir hier noch mit ReadingsAge arbeiten können und alle anderen, welche nur low/ok senden. Habe es noch nicht testen können, aber da kann sich ja jeder dran beteiligen.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 24 Januar 2018, 20:42:47
Bei nur low und ok müssen (sollten) die HM Geräte die auch battery_level senden "ausgefiltert" werden, sonst werden die doppelt behandelt weil die zusätzlich low/ok senden...

Kurz da nur Handy...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 24 Januar 2018, 21:20:23
Hat mich jetzt gerade echt einen Moment gekostet zu verstehen wieso du das schreibst, weil ich dachte es ist ja die letzte elseif Abfrage und die müssten vorher schon abgefangen worden sein. Aber stimmt die werden nur bei der Meldung mit batteryLevel abgefangen und nicht bei battery, da sind sie vorher ins leere gelaufen. Ok dann muss ich das noch ändern, danke für den Hinweis. Schaffe ich aber heute leider nicht mehr.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 24 Januar 2018, 21:24:12
Sorry für die Kürze und auch für die zusätzliche Arbeit...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 25 Januar 2018, 06:29:02
Quatsch, lag nicht an deiner Aussage, sondern daran, dass ich nicht mehr in der Lage war schnell zu denken. Und für zusätzliche Arbeit musste dich nicht entschuldigen, sonst dürfte ich ja nicht am Code weiter basteln wollen ;)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 25 Januar 2018, 07:06:24
Zitat von: _fhemuser_ am 24 Januar 2018, 18:01:15
Da die Benachrichtigung nur einmal versandt wird, muss ich erst wieder volle Batterien einsetzen und dann wieder leere.
Wenn du so testest wird das ganze zu einer Strafarbeit für einen der Vater und Mutter erschlagen hat .....
Tipp : setze  das readings xxx_Bot im BatteryStatiusBot direkt wieder auf none :) 
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 25 Januar 2018, 11:18:44
@Amenophis86, ich hätte da noch zwei Sachen für dich :
a. du besetzt die drei Dummys zwar mit BatteryStart vor, aber bitte bedenke es können danach immer noch neue Geräte  dazukommen die dann aber nicht erfasst sind. Es wird zwar durch den folgenden Block etwas gemildert 
# if it is the first time for that device set it to none (initialize)
  if(ReadingsVal($BatteryStatusBot, $SignalDevice, "undef") eq "undef")
  {
    fhem("setreading $BatteryStatusBot $SignalDevice none");
  }

aber konsequenter wäre es auch den  $BatteryStatus mit $Device dazu zu nehmen.

b. Stichwort  fhem("setreading xyz
mache ich z.B. in einem notify auch so , aber schaut man mal hinter die FHEM Kulissen, dann sieht man das dies zuerst zu CommandSetReading führt um dann bei readingsSingeleUpdate(a,b,c,1) zu enden.
Also warum dann nicht gleich statt z.B.
fhem("setreading $BatteryStatusBot $SignalDevice none");
den Code ändern in:
readingsSingeleUpdate($defs{$BatteryStatusBot}, $SignalDevice, "none",1);
denn nun kann man sich noch überlegen wie sinnvoll es ist mit jeder Änderung des Readings auch gleich wieder einen weiteren Event zu erzeugen -> die ,1 am Ende oder ob man nicht auf diesen zusätzlichen (IMHO überflüssigen) Event auch noch verzichtet und satt der ,1 ein ,0 am Ende einsetzt. 
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 25 Januar 2018, 12:29:36
Bin noch nie tiefer als myUtils eingestiegen, habe die von dir genannten Funktionen im DeveloperBoard mal gelesen, aber nicht näher mit beschäftigt. Kann es aber gerne ändern, da ich deine Argumentation nachvollziehen kann. Schreibe es mir auf die ToDo Liste. Danke für den Hinweis.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 25 Januar 2018, 19:17:44
Zitat von: Amenophis86 am 24 Januar 2018, 18:37:35
Dann musst du den Code nur wie folgt anpassen:
my $msg = "set TelegramBot message  ";
Soll heißen das Reading Battery bleibt auf low stehen, obwohl du neue volle Batterien einfügst?
Also ich beschreibe mal wie ich vorgehe.
1. Die Geräte werden normal mit Batterien betrieben
2. ich klemme parallel zur Batterie ein (Labor-)Netzteil an mit einer Spannung von 3 Volt
3. ich nehme die Batterien heraus. Damit ensteht keine Spannungsunterbrechung
4. in unregelmäßigen Abständen verringere ich die Spannung um 0,1 Volt und betätige die Boost-Taste um Strom zu verbrauchen.
5. Das Gerät meldet eine Batteriewarnung bei zB 2,4 Volt
6. Ich setze die Batterien wieder ein und entferne das Netzteil. Damit sollte die Batteriewarnung erlöschen weil die Spannung steigt. Auch hier ist keine Spannungsunterbrechung

Diesen Test werde ich mit anderen HTs wiederholen, da ich mindestens 4 verschiedene habe. Den Basic, 2 Versionen vom HT und den HT+.

Mögliche Fehlerquellen dabei:
Da der interne Programmcode der Geräte unbekannt ist, kann es sein, dass die Batteriespannung nicht kontinuierlich geprüft wird, sondern zB nur im Abstand von 2 Stunden. In der Zeit kann ich eventuell bereits die Versorgungsspannung soweit gesenkt haben, dass ich bereits unterhalb der Warnschwelle bin.
Der getestete HT geht bei einer weiteren Senkung der Betriebsspannung sogar in Fehler 9 und bleibt dann auf einem festen Wert stehen und sendet auch nicht mehr.

Zitat von: Wzut am 25 Januar 2018, 07:06:24
Wenn du so testest wird das ganze zu einer Strafarbeit für einen der Vater und Mutter erschlagen hat .....
Tipp : setze  das readings xxx_Bot im BatteryStatiusBot direkt wieder auf none :)
OK, Danke
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 26 Januar 2018, 18:59:31
@_fhemuser_:
Und wenn du so testest, dann bleibt das Device auf low und es wird kein Batteriewechsel angezeigt, obwohl es auf ok wechseln sollte und ein Batterie Wechsel angezeigt werden sollte, verstehe ich das richtig?

Klappte denn jetzt bei dir die Meldung per Telegram?
_______________________________

Ich habe soeben den Code mal ziemlich stark verändert im test-Zweig. Ich habe die Abfrage wie folgt geändert:

- Kommt die Meldung als battery Meldung rein?
--> JA: Weiter im battery Zweig
----> Wie lautet der TYPE des Device und hat das Device kein batteryLevel Reading JA: Weiter im zuständigen TYPE Abschnitt
- Kommt die Meldung als batteryLevel Meldung rein?
--> JA: Weiter im batteryLevel Zweig
----> Wie lautet der TYPE des Device: Weiter im zuständigen TYPE Abschnitt

Jeweils am Ende werden dann alle anderen Geräte entsprechend abgearbeitet. Damit dürfte auch die doppelte Abarbeitung bei battery und batteryLevel Reading nicht mehr vorhanden sein.


Bei Xiaomi war ich mir nicht ganz sicher und habe mal auf =~ geprüft. CoolTux hat da die Tage was verändert und bin mir nicht sicher, ob alle Xiaomi Device den gleichen Typ haben und ob alle auch ein batterLevel Reading haben.


Wäre nett, wenn ihr mal über den neuen Code drüber schaut, ob ihr Fehler findet. Als nächstes würde ich dann gerne den temp-At Teil von Wzut einbauen. Muss ich mir nur nochmal näher ansehen, wo und wie genau der da rein kommt.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 26 Januar 2018, 21:51:24
Zitat von: Amenophis86 am 26 Januar 2018, 18:59:31
Als nächstes würde ich dann gerne den temp-At Teil von Wzut einbauen.
Bitteschön , hier meine Beta Version mit (noch) viel Logging :

  ##############################################
  # MAX! Devices
  ##############################################
  elsif($TYPE eq "MAX")
  {
    my $level = ReadingsNum($BatteryStatus, $Device, 0);

    if($Event eq "battery: ok")
    {
     # Log3(undef, 3,"$Device, Batt ok");
      if (defined($defs{"at_BatLow_".$Device}))
     {
     CommandDelete(undef,"at_BatLow_".$Device)  if (defined($defs{"at_BatLow_".$Device}));
      Log3(undef, 3,"$Device, lösche at_BatLow_".$Device);
     }
     return undef;
    }
     elsif ($Event eq "battery: low")
    {
     Log3(undef, 3,"$Device, Batt low");
     # nicht zu schnell in zu kurzer Zeit !
    return undef  if (ReadingsAge($BatteryStatus, $Device,0) < 600);
     Log3(undef, 3,"$Device, Batt low2");
      if($level == 100)
      {
       readingsSingleUpdate($defs{$BatteryStatus},$Device, 75,0); # 1.Stufe
       return undef;
      }
      elsif ($level > 25)
      {
        $level -=5;
        readingsSingleUpdate($defs{$BatteryStatus}, $Device, $level,0);
        Log3(undef, 3,"$Device, Batt Level $level");
        return undef;
      }
       elsif ($level == 25)
      {
        readingsSingleUpdate($defs{$BatteryStatusBot}, $SignalDevice ,"low",0);
        fhem($msg.$text_soon);

        my $time_s = strftime("\%H:\%M:\%S", gmtime(43200));  # z.Z. 12 Stunden 
        my $error = CommandDefine(undef, "at_BatLow_".$Device." at +".$time_s." {BatteryStatusFunction('".$Device."','battery: dead')}");
        if (!$error) { $attr{"at_BatLow_".$Device}{room} = AttrVal($BatteryStatus,"room","Unsorted"); }
        else { Log3(undef, 3,"$Device, temp at error -> $error"); }
        return undef;
      }
       else { Log3(undef, 3,"$Device, unknown Level $level") if ($level);}
    }
     elsif ($Event eq "battery: dead")
    {
     Log3(undef, 3,"$Device, dead Event !");
     readingsSingleUpdate($defs{$BatteryStatus},$Device,0,1); # hier mal mit zusätzlichem Event , vllt will den jemand zum Mail/SMS Versand benutzen ?
     readingsSingleUpdate($defs{$BatteryStatusBot},$SignalDevice,"dead",0);
     fhem($msg.$text_now);
     return undef;
    }
     else
    {
     Log3(undef, 3,"$Device, unknown Event $Event");
    }
}



Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 26 Januar 2018, 23:54:21
Top, schaue es mir die Tage an. Und da fällt mir ein, dass ich noch auf readingsSingeleUpdate umstellen wollte. Schaue ich mir auch noch an. Danke
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 27 Januar 2018, 10:50:58
Zitat von: Amenophis86 am 26 Januar 2018, 18:59:31
@_fhemuser_:
Und wenn du so testest, dann bleibt das Device auf low und es wird kein Batteriewechsel angezeigt, obwohl es auf ok wechseln sollte und ein Batterie Wechsel angezeigt werden sollte, verstehe ich das richtig?
Genau, ich erwartete dass nach steigen der Batteriespannung das Symbol erlischt und der Status an den Cube übermittelt wird. Da ich erst einen HT testen konnte, kann ich das noch nicht für alle MAX!Geräte bestätigen.
Zitat
Klappte denn jetzt bei dir die Meldung per Telegram?
Nein,leider immer noch nicht. Im Log steht:2018.01.27 10:32:45 3:  Die Batterien von Burofenster sollten bald gewechselt werden! : Unknown command Die, try help.
Die Definition des Telegram Bots habe ich geändert auf TelegramBotdefmod TelegramBot TelegramBot
attr TelegramBot allowUnknownContacts 0
attr TelegramBot cmdKeyword FHEM
attr TelegramBot cmdRestrictedPeer xxxxxxxxxx
attr TelegramBot defaultPeer xxxxxxxxxx
attr TelegramBot pollingTimeout 120
und in dem Code nur den Benutzernamen heraus gelöscht.################################
# Here you choos your message device and how to send
# comment the device you do not want to use
#
# TelegramBot
  my $msg = "set TelegramBot message ";
#
# msg-command
# my $msg = "msg \@User title='Battery Check' ";
#
# Pushover
# my $msg = "set Pushover msg device=User title='Battery Check' ";
Den Rest habe ich unverändert von github übernommen, Stand 26.01.17 testbranch checksum: 9af26fb
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 27 Januar 2018, 11:24:32
Um einen Fehler durch eventuelle Änderungen auszuschließen habe ich den auf github veröffebtlichten Code aus der 99_myUtils.pm gelöscht. Alle Definitionen die urprüglich angelgt wurde gelöscht und fhem neu gestartet.

dann wie in Beitrag #1Edit: Code ist nun auf github verfügbar: https://github.com/Amenophis86/Batteryfunktion
Es kann entweder direkt die PM runtergeladen, im Order /FHEM/ eingefügt und ein
Code: [Auswählen]

reload 99_Batterycheck.pm

ausgeführt werden, oder der Code kopiert und in die eigene 99_myUtils.pm eingefügt werden.

2. Werte entsprechend anpassen (Siehe weiter unten)
3. Einmalig die Funktion BatteryStart mittels
Code: [Auswählen]

{BatteryStart()}

ausführen. Sobald diese durchgelaufen ist, könnt ihr sie wieder löschen.
beschrieben den Code in die 99_myUtils.pm eingefügt, wie oben eine Zeile bei TelegramBot angepasst und fhem erneut gestartet anschließend mit {BatteryStart()} alle benötigten Definitionen erstellen lassen.

Die Batterieerkennung funktioniert aber ich erhalte keine Nachricht über TelegramBot. In der Logdatei steht wieder der og Eintrag nur mit einem neuen Zeitstempel
[edit]
Ich habe aus der Definition des TelegramBot die Einstellung für den defaultUser gelöscht und in der Kommandozeile eingegebenTelegramBot message hallound erhalte wie erwartet den Fehler018.01.27 11:28:27 3: FHEMWEB WEB CSRF error: csrf_194100744996488 ne csrf_643818872398676 for client WEB_192.168.0.17_49908 / command set TelegramBot message Hallo. For details see the csrfToken FHEMWEB attribute.Dann habe ich in der n der Kommandozeile eingegebenTelegramBot message @1234567 hallound erhalte die Nachricht. Die Übermittlung funktioniert.
Dann die Einstellung im Code geändert auf:# TelegramBot
my $msg = "set TelegramBot message \@\@1234576 ";
und erhalte den Fehler:FHEMWEB WEB CSRF error: csrf_194100744996488 ne csrf_643818872398676 for client WEB_192.168.0.17_49914 / command style edit 99_myUtils.pm . For details see the csrfToken FHEMWEB attribute.sowie erneut den Hinweis, dass Die kein Befehl ist
[/edit]
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 27 Januar 2018, 12:57:36
@Wzut:
Habe deinen Code gerade mal ein bisschen angepasst und kommentiert. Schau mal bitte drüber, ob ich es richtig verstanden habe:

   ##############################################
   # MAX! Devices with battery
   ##############################################
   elsif($TYPE eq "MAX" and ReadingsVal($Device, "batteryLevel", "undef") eq "undef")
   {
my $level = ReadingsNum($BatteryStatus, $Device, 0);

    if($Event eq "battery: ok")
{
# Log3(undef, 3,"$Device, Batt ok");
  if (defined($defs{"at_BatLow_".$Device})) # temporary at allready defined?
{
CommandDelete(undef,"at_BatLow_".$Device)  if (defined($defs{"at_BatLow_".$Device})); #if defined delete it, battery not dead yet or allready changed?
  Log3(undef, 3,"$Device, deleted at_BatLow_".$Device);
}
return undef;
}
     elsif ($Event eq "battery: low")
{
Log3(undef, 3,"$Device, Batt low");

return undef  if (ReadingsAge($BatteryStatus, $Device,0) < 600); #take some time since the last event
Log3(undef, 3,"$Device, Batt low2");
  if($level == 100)
  {
   readingsSingleUpdate($defs{$BatteryStatus},$Device, 75,0); # set battery level 75%
   return undef;
  }
  elsif ($level > 25)
  {
$level -=5;
readingsSingleUpdate($defs{$BatteryStatus}, $Device, $level,0); # reduce battery level by 5 with every event
Log3(undef, 3,"$Device, Batt Level $level");
return undef;
  }
   elsif ($level == 25)
  {
readingsSingleUpdate($defs{$BatteryStatusBot}, $SignalDevice ,"low",0);# set battery level to low and send message
fhem($msg." ".$text_soon);

my $time_s = strftime("\%H:\%M:\%S", gmtime(43200));  # 12 hours waittime for the temp at 
my $error = CommandDefine(undef, "at_BatLow_".$Device." at +".$time_s." {BatteryStatusFunction('".$Device."','battery: dead')}");
if (!$error) { $attr{"at_BatLow_".$Device}{room} = AttrVal($BatteryStatus,"room","Unsorted"); }
else { Log3(undef, 3,"$Device, temp at error -> $error"); }
return undef;
  }
   else { Log3(undef, 3,"$Device, unknown Level $level") if ($level);}
}
     elsif ($Event eq "battery: dead")
{
Log3(undef, 3,"$Device, dead Event !");
readingsSingleUpdate($defs{$BatteryStatus},$Device,0,1); # set device 0 with an event
readingsSingleUpdate($defs{$BatteryStatusBot},$SignalDevice,"dead",0); # set device dead without event
fhem($msg." ".$text_now);
return undef;
}
     else
{
Log3(undef, 3,"$Device, unknown Event $Event");
}
   }



@_fhemuser_
Wundert mich auch, dass es nicht von low auf ok wechselt.

Telegram:
lösche den defaultUser, gib den User im Skript ein und füge mal folgenden Code nach
# Pushover
# my $msg = "set Pushover msg device=User title='Battery Check' ";

ein:


Log 3, "tele: ".$msg."\nNach.: ".$text_soon;
fhem($msg." ".$text_soon);


Und führe das Skript mit {BatteryStatusFunction(1,"1:1")} in der CommandoZeile aus. Was steht im Log?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 27 Januar 2018, 15:42:06
Zitat von: Amenophis86 am 27 Januar 2018, 12:57:36
@_fhemuser_
Wundert mich auch, dass es nicht von low auf ok wechselt.

Telegram:
lösche den defaultUser, gib den User im Skript ein und füge mal folgenden Code nach
# Pushover
# my $msg = "set Pushover msg device=User title='Battery Check' ";

ein:


Log 3, "tele: ".$msg."\nNach.: ".$text_soon;
fhem($msg." ".$text_soon);


Und führe das Skript mit {BatteryStatusFunction(1,"1:1")} in der CommandoZeile aus. Was steht im Log?
Alles so eingestellt, wie du empfohlen hast und es ergibt NICHTS. Dh es ist kein Eintrag im Log. Wobei ich auch "Log 3" in  "Log3" geändert habe.
Nach den Änderungen natürlich immer "shutdown restart" durchgeführt.

Dass das System auf einem Raspberry3 unter Raspbian GNU/Linux 8 (jessie) läuft kann es nicht liegen?
Können andere Programmteile zu dem Fehler führen?
Fehlen vielleicht noch Module?

Ich habe jetzt fast alle unterschiedlichen MAX!Geräte getestet und bei allen ändert sich die Batteriewarnung ohne Batteriewechsel. Daher gehe ich davon aus, dass nur das eine Gerät sich geringfügig anders verhält.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 27 Januar 2018, 15:55:47
Zitat von: _fhemuser_ am 27 Januar 2018, 15:42:06
Wobei ich auch "Log 3" in  "Log3" geändert habe.

Und das hast du gemacht weil?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 27 Januar 2018, 15:59:37
Weil alle andern ähnlichen Einträge Log3 am Anfang hatten und es keinen Eintrag gab.

Sowohl mit Log 3, "tele: ".$msg."\nNach.: ".$text_soon;
als auch
Log3, "tele: ".$msg."\nNach.: ".$text_soon;
gibt es keine Einträge im Log.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 27 Januar 2018, 16:13:27
Ja, gibt auch einen Unterschied zwischen Log3 und Log 3, hatte bewusst Log 3 gewählt. Ein Shutdownrestart musst du nicht ausführen, wenn du es direkt im Editor von FHEM editierst und speicherst, werden sofort die Änderungen übernommen.

Es wundert mich, dass NICHTS ausgegeben wird, wenn du {BatteryStatusFunction(1,"1:1")} in die CommandZeile eingibst. Da stimmt was nicht.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 27 Januar 2018, 16:28:45
So ich bin einen kleinen Schritt weiter.

Ich habe deinen Code komplett aus der 99_myUtils.pm gelöscht und eine 99_BatterycheckUtils.pm angelegt und den Code mit den zusätzlichen Erweiterungen eingefügt und fhem restartet. Dann kommt jetzt nach Eingabe von {BatteryStatusFunction(1,"1:1")}
2018.01.27 16:20:49 3: tele: set TelegramBot message @@12345678
Nach.: Die Batterien von 1 sollten bald gewechselt werden!
2018.01.27 16:20:49 3: TelegramBot_SendIt TelegramBot: Failed with :FAILED peer not found :@12345678::
2018.01.27 16:20:49 3: TelegramBot_Callback TelegramBot: resulted in NonBlockingGet: returned FAILED peer not found :@12345678: from SendIt
2018.01.27 16:20:49 3: set TelegramBot message @@12345678   Die Batterien von 1 sollten bald gewechselt werden! : FAILED peer not found :@12345678:
also ein Problem mit dem Namen
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 27 Januar 2018, 16:30:59
Du darfst nicht die ID nehmen, sondern musst deinen Telegram Username nehmen.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 27 Januar 2018, 17:03:40
Es funktioniert endlich!

Ich habe wie am Anfang einen defaultUser im TelegramBot eingetragen und # TelegramBot
my $msg = "set TelegramBot message  ";
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 27 Januar 2018, 17:20:49
Zitat von: Amenophis86 am 27 Januar 2018, 12:57:36
Habe deinen Code gerade mal ein bisschen angepasst und kommentiert. Schau mal bitte drüber, ob ich es richtig verstanden habe:
ähh ja schaut noch fast so aus wie mein Vorschlag :) Aber doch noch ne kleine Anmerkung
elsif($TYPE eq "MAX" and ReadingsVal($Device, "batteryLevel", "undef") eq "undef")
IMHO wird bei TYPE "MAX" niemals ein Reading  batteryLevel auftauchen daher hatte ich diese simple Abfrage
Noch ein Wort zu Telegram (und seinen möglichen Brüdern) Wie du an meinem Beispiel siehts schleppe ich den Dummy BatteryStatusBot nur noch mit weil er halt schon da ist , aber wirklich gebraucht wird er meiner Meinung nach nicht , alles wichtige lässt sich direkt aus  BatteryStatus ableiten mit Sicherheit auch bei den anderen möglichen Geräten. Da ich selbst kein Telegram oder ähnliches verwende hatte ich dafür einen Dummy angelegt damit die Zeilen  fhem($msg." ".$text_soon) auch greifen. Allerdinsg mit dem einen echten Event ( ,1 bei readingsSingleUpdate) könnte man auch das ganze Thema Benachrichtigung komplett aus deiner sub entfernen
und mit einem notify/DOIF direkt auf diesen Event triggern. Das hätte halt den Vorteil das du Batterie Monitoring und Benachrichtigungsverwaltung ganz sauber trennen könntest. Sorry wenn ich gedanklich jetzt fast alles aus der Urform auf den Kopf stelle, aber die Ideen kommen halt immer so nach und nach und immer getreu dem Motto "das Bessere ist der Feind des Guten"  :) :)  :) 
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 27 Januar 2018, 18:14:19
@Wzut:
Bin für alle Vorschläge offen, daher kein Problem. Die Idee hinter BatteryStatusBot ist, dass Meldungen nicht doppelt verschickt werden. Soll heißen, wenn die Soon Meldung raus ist und nochmal ein Event erzeugt wird, welches Soon erzeugen würde, wird vorher geprüft, ob dafür schon eine Meldung raus ist. Dies wird bei dir ja auch nicht verhindert, oder? Dies könnte man machen, wenn man eine Meldung nur bei einem Event aus einer Externen Abfrage sendet. Im Code selbst wüsste ich jetzt nicht, wie es verhindert werden soll. Oder übersehe ich gerade etwas?

Ich hatte auch schon überlegt das Versenden der Meldung doch wieder raus zu nehmen und als Event drauf zu reagieren. Die Frage die sich damit eher stellt ist, wie allgemein soll der Code irgendwann werden. Eigentlich war es mal nur ein Code von MadMax-FHEM für seine Bedürfnisse. Bin mir da noch unschlüssig.

Da ich keine MAX Geräte habe, wusste ich nicht, ob es da auch welche mit batteryLevel gibt und habe somit die Prüfung als Vorsicht drinnen gelassen.

@_fhemuser_
Freut mich, dass es nun geht :)

_________________________

Habe im Testzweig gerade mal von setreading auf singleReadingUpdate umgestellt.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 27 Januar 2018, 20:09:07
Zitat von: Amenophis86 am 27 Januar 2018, 18:14:19
Dies wird bei dir ja auch nicht verhindert, oder? 
doch mit $level == 25 , denn den gibt es nur 1x , beim nächste low wäre er dann ja schon runter auf 20 :)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 27 Januar 2018, 20:32:19
Stimmt.
Nur nochmal zum Verständnis für mich. Bisher wissen wir, dass alle Geräte außer MAX mit dem reinen Reading Battery nicht zwischen low und ok wechseln. Das heißt bei diesen müssten wir direkt bei der ersten Meldung auf 0 setzen und damit die Meldung absetzen. Problem ist jetzt wieder, wenn ein Gerät doch wechselt, dann würde die Meldung ständig erscheinen. Beim Einsatz vom Dummy würde dies verhindert werden. Richtig so, oder habe ich etwas übersehen?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 28 Januar 2018, 20:09:24
ich kann dir geistig jetzt nicht ganz folgen ... klar mein Bespiel war auf MAX bezogen aber auch bei anderen Geräten lässt sich die Abstufung des Levels und die damit verbunden Aktion einsetzen. D.h. eben nicht gleich beim ersten low auf 0 runter, warum auch das Gerät macht es bestimmt noch ne Weile mit der Batterie.
Allerdings sind war da wieder beim event-on Thema, z.B. wird der LaCrosse Sensor recht flott seine lows raushauen bei on-update, hier kann dann die Verwerfung von x Minuten/Stunden hilfreich sein. Setzt der User allerdings on-change ein klappt das alles nicht da ja keine weiteren Events nach dem ersten low kommen werden.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 28 Januar 2018, 21:03:38
Das war mein Gedankengang, dass die MEISTEN User (ich auch) mit on-change arbeiten. Hätte ich dazu schreiben müssen, sorry.

Dh wenn wir so arbeiten wollen, dann müssen wir auch zumindest mit on-update und der Dauer von ReadingsAge bezogen auf die einzelnen Device. <600 wäre zB bei LaCrosse vermutlich noch zu wenig.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 06 Februar 2018, 14:54:29
@Amenophis86, FYI : https://forum.fhem.de/index.php/topic,71413.msg761857.html#msg761857
Beim selbst gebauten Fensterdrehgriff Kontakt zeigte sich auch das sonst typische MAX! Verhalten.
Unklar ist jetzt ob das bei HM normal ist oder ob das eine Eigenart von papas AskSin Lib ist.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 06 Februar 2018, 18:01:10
Gut zu wissen, wobei ich aktuell das Projekt hinten anstellen musste. Wie sieht denn ein List dieses Gerät aus soll heißen was steht im Reading TYPE und model?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 06 Februar 2018, 18:19:28
Jetzt hat es mich natürlich doch wieder gereizt über den Code zu grübeln und ich weiß wieder was meine letztes Problem war. Ich finde die Idee von dir mit dem Runterzählen gut, brauchen natürlich für die einzelnen Geräte dann Erfahrungswerte, wie lange die Batterien zB noch halten um festzusetzen was wir beim ReadingsAge einsetzen und wie lange das At laufen soll bis die Dead-Meldung kommt.

Bei der Dead-Meldung sehe ich auch noch ein Problem. Wenn der User die Batterie wechselt, bevor die Dead-Meldung durch das At getriggert wurde, dann denkt das Skript, dass keine Batterie gewechselt wurde und sagt alles wieder ok. Das heißt die Laufzeit des At darf nicht zu lange gewählt werden. Das stelle ich mir schwierig vor, weil ich kann mir vorstellen, dass es sowohl vom Gerät, als auch von der Batterie abhängt, wie lange ein Gerät noch funktioniert obwohl auf low gewechselt wurde. Ich habe zB aktuell einen HM Fensterkontakt, der meldet mir seit bestimmt 6 Wochen, dass er low ist und läuft noch ohne Probleme.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 07 Februar 2018, 07:27:22
Zitat von: Amenophis86 am 06 Februar 2018, 18:01:10
soll heißen was steht im Reading TYPE und model?
STATE      closed
   TYPE       CUL_HM
 
GK_2_Buero type:threeStateSensor -
list:peer register         :value
   0:      cyclicInfoMsg    :on
   0:      pairCentral      :0x---------
   0:      transmDevTryMax  :6
   1:      eventDlyTime     :0 s
   1:      ledOnTime        :0.5 s
   1:      msgRhsPosA       :closed
   1:      msgRhsPosB       :open
   1:      msgRhsPosC       :tilted
   1:      sign             :off
   1:      transmitTryMax   :0
 
   model      HM-SEC-RHS
subType    threeStateSensor

Wobei ich denke das ist völlig egal, sobald man papas Eigenbau FW für Geräte nutzt und bei diesen Bat definert ist werden sie sich alle gleich verhalten:
public:
  void init () {
    BaseHal::init();
    // init real time clock - 1 tick per second
    rtc.init();
    // measure battery every 1h
    battery.init(60UL*60,rtc);
    battery.low(22);
    battery.critical(19);

hier sollten wir mal abwarten was papa dazu meint , vllt ändert er ja auch noch seine lib so das ein einmal gesetztes low bis zum reset des Kontrollers erhalten bleibt.

zu dead : ich arbeite halt mit 12 Stunden , u.U. kann man die Zeit ja auch als Variable im Kopf definieren so das dies jeder nach seinem persönlichen Geschmack leicht selbst festlegen kann. 
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 07 Februar 2018, 10:36:17
Zitat von: Wzut am 07 Februar 2018, 07:27:22
STATE      closed
   TYPE       CUL_HM
   model      HM-SEC-RHS
subType    threeStateSensor

Wobei ich denke das ist völlig egal, sobald man papas Eigenbau FW für Geräte nutzt und bei diesen Bat definert ist werden sie sich alle gleich verhalten:
...
hier sollten wir mal abwarten was papa dazu meint , vllt ändert er ja auch noch seine lib so das ein einmal gesetztes low bis zum reset des Kontrollers erhalten bleibt.
Ok, habe mich mit der Lib noch gar nicht beschäftigt. Dachte nur, wir müssen dann für diese Geräte auch wieder eine Sonderlocke einführen weshalb ich wissen wollte, wie die sich melden.

Zitat
zu dead : ich arbeite halt mit 12 Stunden , u.U. kann man die Zeit ja auch als Variable im Kopf definieren so das dies jeder nach seinem persönlichen Geschmack leicht selbst festlegen kann.

Das mit der Variable im Kopf war auch meine Überlegung und sehe ich bisher als einzige Möglichkeit. Wird wenig Sinn machen da etwas vorzugeben.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: DarkT am 07 Februar 2018, 10:40:12
Gibt es eine bestimmten Grund für diesen Code im Skript?


# ignoring Devices that were just created by autocreate
  #if($DeviceNameParts[0] eq "HM" || $DeviceNameParts[0] eq "ZWave" || $DeviceNameParts[0] eq "MAX")
  #{
  #  Log3(undef, 1, "my_StoreBatteryStatus      ignoring Device: $Device");
  #  return;
  #}


Ich habe den jetzt auskommentiert, da meine Devices mit HM_ anfangen.
Diese "Sicherheitsüberprüfung" verstehe ich allerdings nicht und sie macht das Modul schwere verständlich für neue Benutzer.

lg darkT
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 07 Februar 2018, 10:49:58
Ja gibt es. Die Idee dahinter ist, dass neue Device beim ersten anlegen nicht bearbeitet werden sollen. Dazu dürfen diese natürlich nicht mit HM_ beginnen. Sollte ich als Erklärung mal im ersten Post aufnehmen.

Edit:
Habe den ersten Post entsprechend angepasst.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: DarkT am 07 Februar 2018, 11:39:07
Zitat von: Amenophis86 am 07 Februar 2018, 10:49:58
Edit:
Habe den ersten Post entsprechend angepasst.

Sehr Gut. Danke.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 07 Februar 2018, 12:52:01
@DarkT: Um mal auf deine Frage, welche per PM kam, zu antworten warum das so ist, sei folgendes erklärt. Geräte mit HM_ etc. werden nicht überwacht, weil es vermutlich bei vielen Leuten so abläuft:

- Neues Gerät gekauft und in FHEM angelegt (Beispiel HM_123456)
- Gerät wird nach erfolgreichem anlegen umbenannt in Bad.Fenster

Sollte nun beim anlegen das Geräts in FHEM das Skript direkt das Gerät HM_123456 angelegt haben, wird es für immer in den Dummys verbleiben und als ok angezeigt werden, obwohl es das ja gar nicht mehr gibt. Dazu wird das Gerät Bad.Fenster angezeigt, welches das neue Gerät ist. Aus diesem Grund werden neu angelegte Geräte ignoriert um sie erst nach dem Rename zu erfassen.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: DarkT am 07 Februar 2018, 13:01:45
Zitat von: Amenophis86 am 07 Februar 2018, 12:52:01
@DarkT: Um mal auf deine Frage, welche per PM kam, zu antworten warum das so ist, sei folgendes erklärt. Geräte mit HM_ etc. werden nicht überwacht, weil es vermutlich bei vielen Leuten so abläuft:

- Neues Gerät gekauft und in FHEM angelegt (Beispiel HM_123456)
- Gerät wird nach erfolgreichem anlegen umbenannt in Bad.Fenster

Sollte nun beim anlegen das Geräts in FHEM das Skript direkt das Gerät HM_123456 angelegt haben, wird es für immer in den Dummys verbleiben und als ok angezeigt werden, obwohl es das ja gar nicht mehr gibt. Dazu wird das Gerät Bad.Fenster angezeigt, welches das neue Gerät ist. Aus diesem Grund werden neu angelegte Geräte ignoriert um sie erst nach dem Rename zu erfassen.

Danke für die Erklärung. Den Punkt mit den Dummys hatte ich nicht gesehen. Danke dafür.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 07 Februar 2018, 13:33:13
Ich habe einen neuen Branche (no-BatteryStatusBot) angelegt zum testen. Den test-branche habe ich nochmal gelassen um ihn mit dem neuen Vergleichen zu können. Der Neue enthält folgende Änderungen:

@Wzut: Du hattest geschrieben:
Zitat von: Wzut am 27 Januar 2018, 20:09:07
doch mit $level == 25 , denn den gibt es nur 1x , beim nächste low wäre er dann ja schon runter auf 20 :)
Ich konnte aber nirgends finden, dass bei 25% nochmal um 5% reduziert wird, das habe ich jetzt eingebaut. Der Status bleibt quasi bei 5% stehen bis dead als Event kommt:

elsif ($level < 25 && $level > 10)
  {
    $level -=5;
readingsSingleUpdate($defs{$BatteryStatus}, $Device, $level,0); # reduce battery level by 5 with every event
Log3(undef, 3,"$Device, Batt Level $level");

return undef;
  }
   elsif($level == 5)
  {
    return undef;
  }


Ich habe den BatteryStatusBot bei batteryLevel jetzt damit ersetzt, dass quasi in der Funktion selbst ein event-on-change-reading eingesetzt wurde. Meldet das Gerät sich mit dem gleichen Level wie vorher, dann wird nichts gemacht. Erst, wenn ein neues Level erreicht wurde, wird einmalig geprüft, die entsprechenden Werte gesetzt und wenn nötig die Nachricht versendet.

_________________________________________
Weiterhin habe ich jetzt mal folgende neue Variablen zu Beginn definiert:
###############################
# Here you can change the times for the temp-at and waittime for the reduction of 5% steps

  my $FivePercent_HM = 600;
  my $TempAt_HM = 43200;
  my $FivePercent_Max = 600;
  my $TempAt_Max = 43200;
  my $FivePercent_Xiaomi = 600;
  my $TempAt_Xiaomi = 43200;
  my $FivePercent_LaCrosse = 600;
  my $TempAt_LaCrosse = 43200;
  my $FivePercent_Other = 600;
  my $TempAt_Other = 43200;


Die besten Zeiten müssen wir über Testen finden.

_________________________________________
Auch gibt es folgende neue Variable:
my $text_motorErrValve = "Der Motor kann sich nicht mehr bewegen!"; #Text for motorErr ValveErrorPosition only HM
Diese wird im HM Bereich mit batteryLevel genutzt. Beim ersten Durchlaufen auf 25% wird gleich noch getestet, ob der Motor bereits "ValveErrorPosition" meldet. Wenn ja, wird dies an die Nachricht angehängt und direkt auf 0% gesetzt. Ansonsten wird lediglich auf 25% gesetzt.

_________________________________________
Weiterhin habe ich noch LaCrosse zur Ignoreliste am Anfang dazu gefügt. Nach der Frage von DarkT ist mir aufgefallen, dass ich dies vergessen hatte.

Könnt ja mal über den Code schauen, ob euch noch Fehler auffallen. Ich hoffe, dass ich ihn die Tage testen kann.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: mahowi am 07 Februar 2018, 20:55:43
Ich setze den Code jetzt auch zur Batterieüberwachung ein. Nach dem Ausführen von BatteryStart werden meine Geräte auch schön aufgeführt. Da bei 2 ZWave Thermostaten die Batterien bereits auf low waren, habe ich sie eben gewechselt. Der Dummy BatterieWechsel bleibt aber leer, und der Status der Geräte in der ReadingsGroup bleibt auf low.

Hab ich irgendwas übersehen, das ich noch definieren muß?

Reading der Thermostate:
2018-02-07 16:53:59 battery 88 %
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: mahowi am 08 Februar 2018, 10:13:50
Ich habe heute mal alle Dummies, das Notify und die ReadingsGroup gelöscht. Die 99_Batterycheck.pm habe ich neu aus dem "no-BatteryStatusBot"-Branch geholt.

Nach Reload und {BatteryStart()} werden die ZWave-Geräte gar nicht mehr angezeigt.

Liegt es eventuell daran, daß für die Geräte ein "unknown Event" gemeldet wird?

2018.02.08 10:05:55.353 3: wz.ZW_HT2, unknown Event battery: 93 %
2018.02.08 10:06:07.003 3: bz.ZW_HT, unknown Event battery: 65 %
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 08 Februar 2018, 10:39:21
Bezieht sich auf den ersten Post im Master Branche:
Ich gehe davon aus, dass du die erste Version aus dem Master-Branch nutzt?

Hat das Device das Reading battery ok/low und/oder batteryLevel mit einem Wert? Wie waren die Werte vor dem Wechsel und wie nach dem Wechsel? Was stand vor, was nach dem Wechsel im BatteryStatus Dummy was im BatteryStatusBot Dummy? Hast du event-on-change / -on-update gesetzt?

Bezieht sich auf den zweiten Post im no-BatteryStatusBot-Branche:
Edit:
Ja scheinbar macht das % Zeichen hier Probleme. Glaube es wird noch auf ReadingsVal und nicht auf ReadingsNum geprüft. Habe kein Z-Wave, daher ist mir das vermutlich nicht aufgefallen. Schaue es mir mal an. Dank dir.

Edit2:
Wie ist das bei Z-Wave, haben die ein Reading Battery und ein Reading batteryLevel, oder steht das Level im Reading battery? Poste mal bitte ein list eines der Device, dass ich mir das anschauen kann. Habe wie gesagt keine Z-Wave Komponenten.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: mahowi am 08 Februar 2018, 11:31:23
Der erste Post hatte sich auf den "test"-Branch bezogen. Da es beides ZWave-Geräte waren, dürfte das Problem dasselbe wie im zweiten Post sein.

Hier mal ein list von einem Thermostat:
Internals:
   CFGFN     
   DEF        ee0b4efd 8
   IODev      ZME_UZB1
   LASTInputDev ZME_UZB1
   MSGCNT     100
   NAME       wz.ZW_HT2
   NR         242
   STATE      19.64 C
   TYPE       ZWave
   ZME_UZB1_MSGCNT 100
   ZME_UZB1_RAWMSG 00040008044608007f
   ZME_UZB1_TIME 2018-02-08 11:20:14
   ZWaveSubDevice no
   homeId     ee0b4efd
   isWakeUp   1
   lastMsgSent 1518084919.18064
   nodeIdHex  08
   useMultiCmd 1
   READINGS:
     2017-10-04 16:23:13   CMD             ZW_APPLICATION_UPDATE
     2018-02-08 09:00:15   LastSetTemperature 18.21
     2018-02-08 11:20:14   battery         93 %
     2018-02-08 11:20:14   ccsOverride     no, unused
     2018-02-08 11:20:14   setpointTemp    18.20 C heating
     2018-02-08 11:15:16   temperature     19.64 C
     2018-02-08 11:15:19   timeToAck       0.103
     2018-02-08 11:15:19   transmit        OK
     2018-02-08 11:15:16   wakeup          notification
Attributes:
   IODev      ZME_UZB1
   alias      Thermostat WZ Hof
   classes    BATTERY CLIMATE_CONTROL_SCHEDULE CLOCK MANUFACTURER_SPECIFIC MULTI_CMD PROTECTION SENSOR_MULTILEVEL THERMOSTAT_SETPOINT VERSION WAKE_UP MARK CLIMATE_CONTROL_SCHEDULE CLOCK MULTI_CMD
   genericDeviceType thermostat
   group      Heizung
   icon       max_heizungsthermostat_basic
   room       Homekit,Wohnzimmer
   stateFormat temperature
   useMultiCmd 1
   vclasses   BATTERY:1 CLIMATE_CONTROL_SCHEDULE:1 CLOCK:1 MANUFACTURER_SPECIFIC:1 MULTI_CMD:1 PROTECTION:2 SENSOR_MULTILEVEL:6 THERMOSTAT_SETPOINT:2 VERSION:1 WAKE_UP:2
   webCmd     thermostatSetpointSet
   widgetOverride thermostatSetpointSet:slider,4.0,0.5,28.0,1


Wie Du siehst, gibt es hier nur das Reading battery, aber mit Prozentangabe. batteryLevel gibt es nicht, zumindest bei keinem meiner batteriebetriebenen ZWave-Geräte.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 08 Februar 2018, 16:50:02
Bei mir ist jetzt wirklich eine Batterie leer und ich erhalte alle 3 Minuten eine Nachricht per Telegram, die Batterie in Kürze zu tauschen.
Aktiviert ist noch der Testzweig von Ende Januar.

Ich werde den letzten Codezweig nachher einbauen.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 09 Februar 2018, 07:10:31
@mahowi: Ok das war mir nicht bewusst. Wenn ich mir allerdings den Ursprungscode ansehe dann hatte MadMax-Fhem das schon entsprechende bedacht, ich nur übersehen. Werde es im no-BatteryStatusBot an passen.

Warum es allerdings beim test Zweig nicht klappt erschließt sich mir noch nicht. Da wären die Antworten auf die Frage interessant gewesen. Wichtig ist, dass vor einem Batteriewechsel bei Geräten mit einer Wertangabe der Wert unter 25 gewesen sein muss. Bei ok/low Geräten muss das nicht sein, ausnahme ist hier MAX!.


@_fehmuser_:
Warum du im Testzweig ständig die Meldung bekommst brauche ich mehr Informationen. Was für eine Device ist es, was steht im BatteryStatus und BatteryStatusBot für Werte für das Gerät?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 09 Februar 2018, 07:31:12
@mahowi: Ich habe gerade mal die "batteryLevel" prüfung im no-BatteryStatusBot Zweig eingefügt. Würdest du mir noch eine raw Defintion deines Z-Wave Device zur Verfügung stellen, dann muss ich mir keins selbst bauen und kann damit ein bisschen testen. Finde es immer besser die Werte eines richtiges Device zu haben, als mit einem dummy zu üben.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: mahowi am 09 Februar 2018, 07:54:32
Ich habe die neue Version heruntergeladen, bekomme beim reload aber Syntaxfehler:
syntax error at ./FHEM/99_Batterycheck.pm line 675, near "))
   "
syntax error at ./FHEM/99_Batterycheck.pm line 693, near ")
{"
syntax error at ./FHEM/99_Batterycheck.pm line 698, near "}"
syntax error at ./FHEM/99_Batterycheck.pm line 705, near "}"
syntax error at ./FHEM/99_Batterycheck.pm line 718, near "}"
syntax error at ./FHEM/99_Batterycheck.pm line 729, near "}"
syntax error at ./FHEM/99_Batterycheck.pm line 794, near "}"
syntax error at ./FHEM/99_Batterycheck.pm line 856, near "}"
Unmatched right curly bracket at ./FHEM/99_Batterycheck.pm line 858, at end of line
Can't use global @_ in "my" at ./FHEM/99_Batterycheck.pm line 865, near "= @_"
./FHEM/99_Batterycheck.pm has too many errors.


Da wird wohl eine Klammer falsch sitzen. Ich komme nur leider gerade nicht dazu, drüber zu gucken.

Hier mal die raw definition vom Thermostat:
defmod wz.ZW_HT2 ZWave ee0b4efd 8
attr wz.ZW_HT2 IODev ZME_UZB1
attr wz.ZW_HT2 alias Thermostat WZ Hof
attr wz.ZW_HT2 classes BATTERY CLIMATE_CONTROL_SCHEDULE CLOCK MANUFACTURER_SPECIFIC MULTI_CMD PROTECTION SENSOR_MULTILEVEL THERMOSTAT_SETPOINT VERSION WAKE_UP MARK CLIMATE_CONTROL_SCHEDULE CLOCK MULTI_CMD
attr wz.ZW_HT2 genericDeviceType thermostat
attr wz.ZW_HT2 group Heizung
attr wz.ZW_HT2 icon max_heizungsthermostat_basic
attr wz.ZW_HT2 room Homekit,Wohnzimmer
attr wz.ZW_HT2 stateFormat temperature
attr wz.ZW_HT2 useMultiCmd 1
attr wz.ZW_HT2 vclasses BATTERY:1 CLIMATE_CONTROL_SCHEDULE:1 CLOCK:1 MANUFACTURER_SPECIFIC:1 MULTI_CMD:1 PROTECTION:2 SENSOR_MULTILEVEL:6 THERMOSTAT_SETPOINT:2 VERSION:1 WAKE_UP:2
attr wz.ZW_HT2 webCmd thermostatSetpointSet
attr wz.ZW_HT2 widgetOverride thermostatSetpointSet:slider,4.0,0.5,28.0,1

setstate wz.ZW_HT2 19.50 C
setstate wz.ZW_HT2 2017-10-04 16:23:13 CMD ZW_APPLICATION_UPDATE
setstate wz.ZW_HT2 2018-02-09 07:38:28 LastSetTemperature 16.21
setstate wz.ZW_HT2 2017-05-24 07:50:26 SEND_DATA failed:00
setstate wz.ZW_HT2 2018-02-01 07:41:08 UNPARSED SENSOR_MULTILEVEL 0631010142080d
setstate wz.ZW_HT2 2018-02-09 07:49:05 battery 91 %
setstate wz.ZW_HT2 2017-12-20 02:48:40 ccs UNKNOWN 88007f
setstate wz.ZW_HT2 2018-02-09 07:49:05 ccsOverride no, unused
setstate wz.ZW_HT2 2017-04-11 09:54:41 humidity 0
setstate wz.ZW_HT2 2017-08-25 02:26:11 power 0 W
setstate wz.ZW_HT2 2018-02-09 07:49:05 setpointTemp 16.20 C heating
setstate wz.ZW_HT2 2017-12-31 19:54:06 state desired-temp 18.82 ;; get ZWave_THERMOSTAT_8 setpoint
setstate wz.ZW_HT2 2018-02-09 07:49:05 temperature 19.50 C
setstate wz.ZW_HT2 2018-02-09 07:49:07 timeToAck 0.031
setstate wz.ZW_HT2 2018-02-09 07:49:07 transmit OK
setstate wz.ZW_HT2 2018-02-09 07:49:05 wakeup notification
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 09 Februar 2018, 08:39:32
Sorry war zu früh, habe den Syntaxcheck vergessen. Jetzt müsste es passen.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: mahowi am 09 Februar 2018, 08:44:59
Läuft, aber ich bekomme für die ZWave-Geräte immer noch "unknown Event":
2018.02.09 08:43:35.380 3: wz.ZW_HT2, unknown Event battery: 91 %
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 09 Februar 2018, 10:17:51
Habe noch einen Fehler gefunden:

Mach mal aus Zeile 676:
if($TYPE eq "Z-Wave" and ReadingsVal($Device, "battery", undef) =~ "%")

if($TYPE eq "ZWave" and ReadingsVal($Device, "battery", undef) =~ "%")

Der - ist da falsch. Der TYPE wird ohne - geschrieben und schau, ob es dann funktioniert.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: mahowi am 09 Februar 2018, 12:35:05
Ich hab die Zeile geändert, leider mit dem selben Ergebnis:

2018.02.09 12:28:39.940 3: bz.ZW_HT, unknown Event battery: 69 %
2018.02.09 12:28:39.941 3: bz.ZW_WM, unknown Event battery: 100 %
2018.02.09 12:28:39.943 3: k.ZW_WM, unknown Event battery: 100 %
2018.02.09 12:28:39.947 3: wz.ZW_HT2, unknown Event battery: 91 %


Wenn ich das richtig sehe, prüfst Du ja bei battery auf "ok", "low" und "dead". Wenn keiner der 3 Werte zutrifft, kommt "unknown Event". Müsste für ZWave nicht battery wie batteryLevel behandelt werden?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 09 Februar 2018, 13:55:43
Fehler gefunden. Das unknown kam, weil es in den battery Zweig gesprungen ist, und beim elseif am Ende nicht raus genommen wurde. Habe ich behoben. Dann ist mir noch aufgefallen, dass neue Geräte nicht beim ersten Mal im BatteryStatus landen, habe ich jetzt auch eingebaut. Zumindest für Z-Wave, bei anderen muss ich noch testen. Und jetzt sollten die Werte von Z-Wave, wenn sie eine Zahl haben auch richtig verarbeitet werden. Zumindest passiert das so in meiner Testumgebung.

Edit:
Allerdings muss die ReadingsGroupe jetzt noch angepasst werden sehe ich gerade.

Edit2:
Habe die ReadingsGroup nun wie folgt angepasst und geändert:
Changed the readingsGroup:
76 - 100 = green 100% (Symbolwert)
51 - 75 = green 75% (Symbolwert)
26 - 50 = yellow 50% (Symbolwert)
11 - 25 = orange 25% (Symbolwert)
0 - 10 = red 0% (Symbolwert)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: mahowi am 09 Februar 2018, 14:54:25
Super, das war's. Jetzt werden alle Geräte angezeigt.  :)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 09 Februar 2018, 17:14:50
Top, dann ordentlich testen und bescheid sagen, wenn noch was ist. :)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Spezialtrick am 09 März 2018, 17:32:14
Hallo zusammen!

Bei mir taucht im Log leider immer wieder dieser Fehler auf:

reload: Error:Modul 99_Batterycheck deactivated:

Gibt es dafür Abhilfe?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 10 März 2018, 14:02:23
Ich gehe mal davon aus, dass du die Datei heruntergeladen hast und als eigene Datei integrieren wolltest. Es war mal als reine eigene Funktion gedacht, habe es aber jetzt mal zur eigenen PM-Datei umgebaut. Das heißt ich habe davor und danach noch einen Teil eingebaut. Nun kann die Datei aus dem no-BatteryStatusBot Zweig als eigene Datei heruntergeladen und integriert werden. Hat den Vorteile, dass es auch unter FHEM als editierbare Datei angezeigt wird.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: helmut am 11 März 2018, 20:09:17
Zitat von: Amenophis86 am 10 März 2018, 14:02:23
Nun kann die Datei aus dem no-BatteryStatusBot Zweig als eigene Datei heruntergeladen und integriert werden.

Das habe ich eben getan und bekam als Fehlermeldung:
"rp2 fhem45"> rel 99_BatteryCheckUtil
Undefined subroutine &main::BatteryCheckUtil_Initialize called at fhem.pl line 2486.


Den Dateinamen "99_BatteryCheckUtil.pm" habe ich unbesehen uebernommen. Die
Initialisierungsroutine heisst aber "BatteryCheckUtils_Initialize". Ich nehme an, auch die Datei
soll ...Utils heissen. Deswegen habe ich die bei mir so umbenannt. Wenn Du es Dir anders
herum gedacht hast, gib bitte Bescheid.

Soll das nun eigentlich ein offizielles Modul werden?

Gruss Helmut
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 12 März 2018, 06:43:31
Habe natürlich den Dateiname geändert in Util und in der Definition vergessen. Kann ich erst am Wochenende ändern. Danke für die Info.

Ein eigenes Modul wäre wesentlich komplexer, da traue ich mich a noch nicht ran und b keine Zeit für aktuell.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: helmut am 12 März 2018, 10:35:43
Zitat von: Amenophis86 am 12 März 2018, 06:43:31
Kann ich erst am Wochenende ändern.

Gar kein Problem, das eilt nun wirklich nicht.

Zitat von: Amenophis86 am 12 März 2018, 06:43:31
Ein eigenes Modul wäre wesentlich komplexer, da traue ich mich a noch nicht ran und b keine Zeit für aktuell.

Das sehe ich ein; schoen waere es trotzdem. Wenn ich bei der Doku mit Korrekturlesen behilflich sein kann ...

Gruss Helmut
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Spezialtrick am 12 März 2018, 17:08:16
Zitat von: Amenophis86 am 10 März 2018, 14:02:23
Ich gehe mal davon aus, dass du die Datei heruntergeladen hast und als eigene Datei integrieren wolltest. Es war mal als reine eigene Funktion gedacht, habe es aber jetzt mal zur eigenen PM-Datei umgebaut. Das heißt ich habe davor und danach noch einen Teil eingebaut. Nun kann die Datei aus dem no-BatteryStatusBot Zweig als eigene Datei heruntergeladen und integriert werden. Hat den Vorteile, dass es auch unter FHEM als editierbare Datei angezeigt wird.

Ich habe die Datei heruntergeladen und nach /opt/fhem/FHEM kopiert und für Pushover abgeändert. Dann Fhem neugestartet und

{BatteryStart()}

ausgeführt. Entsprechend wurde ein neuer Raum mit den vorgesehen Objekten angelegt. Leider habe ich keine Meldung für leer Batterien bekommen.

Aufgrund deiner Antwort habe ich nochmals alle gelöscht und die Datei aus dem "no-BatteryStatusBot" Zweig heruntergeladen und ebenfalls nach /opt/fhem/FHEM kopiert und auch für Pushover angepasst. Meldungen erhalte ich leider weiterhin nicht. Diese sollte aber doch erfolgen, wenn ich bei einem Sensor die Batterie entferne, oder?

Folgende Meldungen finden sich im Log:

2018.03.12 12:15:38 1: PERL WARNING: Subroutine BatteryCheckUtils_Initialize redefined at ./FHEM/99_BatteryCheckUtil.pm line 12, <$fh> line 9.
2018.03.12 12:15:38 1: PERL WARNING: Subroutine BatteryStatusFunction redefined at ./FHEM/99_BatteryCheckUtil.pm line 23, <$fh> line 9.
2018.03.12 12:15:38 1: PERL WARNING: Subroutine SetBatterieIcon redefined at ./FHEM/99_BatteryCheckUtil.pm line 888, <$fh> line 9.
2018.03.12 12:15:38 1: PERL WARNING: Subroutine BatteryStart redefined at ./FHEM/99_BatteryCheckUtil.pm line 932, <$fh> line 9.

2018.03.12 12:15:51 3: eval: my $EVTPART0='battery:';my $SELF='NO.BatterieNotify';my $TYPE='CUL_HM';my $NAME='Fl.Motion.Innen';my $EVTPART1='ok';my $EVENT='battery: ok';{BatteryStatusFunction($NAME, $EVENT)}
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 12 März 2018, 19:09:09
@helmut:
Konnte den Fehler doch schon heute korrigieren. Du hast Recht, die Datei soll natürlich 99_BatteryCheckUtils.pm heißen. So wurde es nun auch auf github geändert. Habe auch noch die ReadingsGroup Standardname von rgBatteryStatus zu rgBatterieStatus gewechselt. Alles wurde mit ie geschrieben nur hier hatte ich die Änderung vergessen.

Habe auch schon drüber nachgedacht und sollte ich mehr Zeit finden, versuche ich vielleicht auch ein Modul draus zu machen. Sollte sich jemand anderes finde, der Zeit hat und möchte bin ich natürlich auch nicht abgeneigt zu helfen wo es geht.

Die Doku muss ich die Tage mal angehen, wann was wie aktuell genau gemacht wird. Auch hier, wer möchte darf gerne unterstützten. Bin min. die nächsten 2-3 Wochen ziemlich eingeschränkt.

@Spezialtrick:
Dafür brauche ich bisschen mehr Informationen. Es scheint sich um ein CUL_HM Device zu handeln. Dies hat battery: ok gemeldet. War das Device vorher auf low und wenn ja auf wie viel Prozent in BatteryStatus Dummy bzw. rg.BatteryStatus?
Wenn du im Thread in bisschen weiter vorne schaust, dann erkennst du folgendes Problem. Viele Device wechseln oft zwischen low / ok, wenn sie kein BatteryLevel Reading haben. Um diesen "Fehler" zu beheben muss das Device für längere Zeit bzw. öfter den Status low melden. Dadurch senkt sich die % immer weiter ab. Sobald diese bei 25% angekommen ist wird die erste Meldung abgesetzt. Die letzte dann beim selbst generierten Event "dead".
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 12 März 2018, 19:45:32
Zitat von: Amenophis86 am 12 März 2018, 19:09:09
versuche ich vielleicht auch ein Modul draus zu machen.
Nix da , hier wird nichts versucht , hier wird entweder etwas gemacht oder sein gelassen ..... und das Wort "vielleicht" ist auf neudeutsch eh ein "no go" :)

Ich habe aber noch ne Info für dich zumThema low-ok-low . Die HM Selbstbau Geräte die auf papas AskSinPP Lib bassieren machen das genau so.
D.h. er schaut z.B. alle Stunde nach dem Zustand der Batterie und meldet diesen ohne den bisherigen zu speichern bzw. zu berücksichtigen.
Mein letzter Stand ist das er nochmal darüber nachdenken wollte ein einmal festgestelltes low dauehaft bis zum nächsten Reset (u.a. durch Batt Wechsel) zu halten.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 12 März 2018, 19:49:33
Zitat von: Wzut am 12 März 2018, 19:45:32
Nix da , hier wird nichts versucht , hier wird entweder etwas gemacht oder sein gelassen ..... und das Wort "vielleicht" ist auf neudeutsch eh ein "no go" :)
;)

Mir ist aufgefallen, dass meine HM Fensterkontakte auch immer mal wieder zwischen low und ok wechseln. Habe jetzt mal eingestellt, dass alle battery Readings geloggt werden um mal eine grobe Übersicht zu bekommen.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 14 März 2018, 19:23:28
Ich habe heute überraschend Zeit gehabt und daher mich nochmal mit dem Skript beschäftigt. Auch bei mir wurde ein Wechsel nicht erkannt. Daher habe ich nochmal alles geprüft und noch den ein oder anderen Fehler gefunden. Diese habe ich soeben beseitigt, getestet und scheint jetzt wieder zu funktionieren. Daher empfehle ich jedem die neuste Version aus dem no-BatteryStatusBot-Zweig zu holen bzw. zu kopieren.

Weiterhin habe ich die Doku im ersten Post mal auf den neusten Stand gebracht. Sollte jemanden etwas fehlen oder nach den Änderungen heute Fehler auffallen, mir bitte mitteilen :)

Edit:
Ich habe jetzt auch mal eine Variable Loglevel eingebaut, da ja doch einige Logmeldungen geschrieben wurde, was man eigentlich nicht brauch im normalen Betrieb. So kann ich aber regelmäßig mit den Logs testen und ihr könnt es ausstellen.
Weiterhin habe ich noch kleine Bugfixes durchgeführt. Zum Beispiel wurden nicht alle Device erkannt und beim ersten Ausführen angelegt, wie es scheint. Dies sollte nun behoben sein.

Edit2:
Puh habe noch einige Fehler gefunden. Habe auch die Struktur verändern müssen, weil zB Z-Wave Device mit batteryLevel nicht richtig erkannt wurden. Habe mit heute extra zum testen nochmal ein Device angelegt und dabei die Fehler festgestellt. Mehr schaffe ich heute aber leider nicht. Sollten euch noch weitere Fehler auffallen, bitte mitteilen.

Es empfiehlt sich die aktuelle Version aus github zu holen, wer mit dem no-BatteryStatusBot Zweig arbeitet!!
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Mave am 26 März 2018, 11:02:05
Funktioniert das Modul auch mit HMIP Komponenten?

Meine HMIP Kontakte haben ein 0.LOWBAT Reading und keine Batterielevel Readings.

Vielen Dank.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 26 März 2018, 11:09:46
Zitat von: Mave am 26 März 2018, 11:02:05
Funktioniert das Modul auch mit HMIP Komponenten?

Meine HMIP Kontakte haben ein 0.LOWBAT Reading und keine Batterielevel Readings.

Vielen Dank.

Nicht vom "Stand weg"...

Aber entweder du postest mal ein list eines der Geräte (und berichtest wie der "Verlauf" ist, also was signalisiert voll leer und gibt es "Zwischenzustände" etc.) vielleicht findet sich jemand der es erweitert...
...oder du schaust dir den Code an und erweiterst entsprechend...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 26 März 2018, 11:45:21
Wie Joachim schrieb. Ein List und eine Raw Definition des Device helfen mir um zu testen und es einzubauen.

Ansonsten Teste ich gerade mit einem Fensterkontakt von HM und einem Lacrosse Device, welche ständig low und ok senden. Wird aber noch ein wenig dauern, bis es hier einen Durchbruch gibt. Melde mich dann.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: networker am 29 März 2018, 17:55:13
Habe heute die 99_BatteryCheckUtils.pm aus dem Git installiert, angepasst und Initialisiet mit reload 99_BatteryCheckUtils.pm und {BatteryStart()}

Habe jetzt im Log für alle meine HM-CC-RT-DN folgendes gesehen:
2018.03.29 17:38:45 1 : BaZi_Heizkreis, Error! Unkown Device Type with event battery: ok

Das ist das List des Devices zum obrigen Log.:
Internals:
   CFGFN      ./FHEM/badezimmer.cfg
   DEF        26E564
   HMLAN1_MSGCNT 51
   HMLAN1_RAWMSG E26E564,0000,03D39A51,FF,FFB8,20861026E5640000000AB0E60B0040
   HMLAN1_RSSI -72
   HMLAN1_TIME 2018-03-29 17:45:57
   HMUSB1_MSGCNT 51
   HMUSB1_RAWMSG E26E564,0000,682757D6,FF,FFBC,20861026E5640000000AB0E60B0040
   HMUSB1_RSSI -68
   HMUSB1_TIME 2018-03-29 17:45:57
   HmModUartWLAN1_MSGCNT 50
   HmModUartWLAN1_RAWMSG 0500003020861026E5640000000AB0E60B0040
   HmModUartWLAN1_RSSI -48
   HmModUartWLAN1_TIME 2018-03-29 17:45:57
   IODev      HmModUartWLAN1
   LASTInputDev HMUSB1
   MSGCNT     152
   NAME       BaZi_Heizkreis
   NOTIFYDEV  global
   NR         311
   NTFY_ORDER 50-BaZi_Heizkreis
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 BaZi_Heizkreis_Weather
   channel_02 BaZi_Heizkreis_Climate
   channel_03 BaZi_Heizkreis_WindowRec
   channel_04 BaZi_Heizkreis_Clima
   channel_05 BaZi_Heizkreis_ClimaTeam
   channel_06 BaZi_Heizkreis_remote
   lastMsg    No:20 - t:10 s:26E564 d:000000 0AB0E60B0040
   protLastRcv 2018-03-29 17:45:57
   protSnd    1 last_at:2018-03-29 16:07:36
   protState  CMDs_done
   rssi_at_HMLAN1 avg:-71.6 min:-72 max:-71 lst:-72 cnt:51
   rssi_at_HMUSB1 avg:-68.07 min:-69 max:-67 lst:-68 cnt:51
   rssi_at_HmModUartWLAN1 avg:-47.62 min:-48 max:-47 lst:-48 cnt:50
   Helper:
     DBLOG:
       actuator:
         myDbLog:
           TIME       1522338357.75079
           VALUE      0
       battery:
         myDbLog:
           TIME       1522338357.75079
           VALUE      ok
       batteryLevel:
         myDbLog:
           TIME       1522338357.75079
           VALUE      2.6
       desired-temp:
         myDbLog:
           TIME       1522338357.75079
           VALUE      22.0
       measured-temp:
         myDbLog:
           TIME       1522338357.75079
           VALUE      23.0
       motorErr:
         myDbLog:
           TIME       1522338357.75079
           VALUE      ok
       state:
         myDbLog:
           TIME       1522332456.43292
           VALUE      CMDs_done
       time-request:
         myDbLog:
           TIME       1522332456.43292
           VALUE      -
   READINGS:
     2018-03-29 15:43:54   Activity        alive
     2018-03-29 05:57:35   CommandAccepted yes
     2015-10-13 23:14:14   D-firmware      1.4
     2015-10-13 23:14:14   D-serialNr      LEQ0111245
     2017-12-30 17:48:03   PairedTo        0x26EA36
     2015-10-13 23:16:12   R-backOnTime    10 s
     2015-10-14 00:19:48   R-btnLock       on
     2015-10-13 23:16:12   R-burstRx       on
     2015-10-13 23:16:12   R-cyclicInfoMsg on
     2015-10-13 23:16:12   R-cyclicInfoMsgDis 0
     2015-10-14 00:22:31   R-globalBtnLock off
     2015-10-13 23:16:12   R-localResDis   off
     2015-10-13 23:16:12   R-lowBatLimitRT 2.1 V
     2015-10-13 23:16:12   R-modusBtnLock  off
     2015-10-13 23:16:12   R-pairCentral   0x26EA36
     2017-12-30 17:48:03   RegL_00.        01:01 02:01 09:01 0A:26 0B:EA 0C:36 0E:0A 0F:01  11:00 12:15 16:00 18:00 19:00 1A:00 00:00
     2017-12-30 17:50:37   RegL_07.       
     2018-03-29 17:45:57   actuator        0
     2018-03-29 17:45:57   battery         ok
     2018-03-29 17:45:57   batteryLevel    2.6
     2018-03-29 17:45:57   desired-temp    22.0
     2018-03-29 17:45:57   measured-temp   23.0
     2018-03-29 17:45:57   motorErr        ok
     2016-07-22 07:39:17   powerOn         2016-07-22 07:39:17
     2016-07-22 07:39:17   recentStateType info
     2018-03-29 16:07:36   state           CMDs_done
     2018-03-29 16:07:36   time-request    -
   helper:
     HM_CMDNR   32
     mId        0095
     regLst     ,0
     rxType     140
     supp_Pair_Rep 0
     expert:
       def        1
       det        1
       raw        1
       tpl        0
     io:
       newChn     +26E564,00,00,00
       nextSend   1522338357.9192
       prefIO     
       rxt        2
       vccu       vccu
       p:
         26E564
         00
         00
         00
     mRssi:
       mNo        20
       io:
         HMLAN1:
           -72
           -72
         HMUSB1:
           -68
           -68
         HmModUartWLAN1:
           -40
           -40
     prt:
       bErr       0
       sProc      0
       sleeping   1
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       at_HMLAN1:
         avg        -71.6078431372549
         cnt        51
         lst        -72
         max        -71
         min        -72
       at_HMUSB1:
         avg        -68.078431372549
         cnt        51
         lst        -68
         max        -67
         min        -69
       at_HmModUartWLAN1:
         avg        -47.62
         cnt        50
         lst        -48
         max        -47
         min        -48
     shRegW:
       07         04
     shadowReg:
     tmpl:
Attributes:
   IODev      HmModUartWLAN1
   IOgrp      vccu
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     3
   firmware   1.4
   icon       hm-cc-rt-dn
   model      HM-CC-RT-DN
   room       CUL_HM
   serialNr   LEQ0111245
   subType    thermostat
   verbose    3
   webCmd     getConfig:clear msgEvents:burstXmit


und dann hab ich noch einen HM-LC-SW1-BA-PCB bei dem die Batterie auf low ist, und der fehlt komplett in der ReadingsGroup.

List von Device:
Internals:
   CFGFN      ./FHEM/Kerze.cfg
   DEF        4D4685
   HMLAN1_MSGCNT 5
   HMLAN1_RAWMSG E4D4685,0000,03BCC399,FF,FFB2,FC80024D468526EA360101C88038
   HMLAN1_RSSI -78
   HMLAN1_TIME 2018-03-29 17:21:02
   HMUSB1_MSGCNT 6
   HMUSB1_RAWMSG E4D4685,0000,6810820A,FF,FFB8,FC80024D468526EA360101C88038
   HMUSB1_RSSI -72
   HMUSB1_TIME 2018-03-29 17:21:02
   HmModUartWLAN1_MSGCNT 5
   HmModUartWLAN1_RAWMSG 04030036FC80024D468526EA360101C88038
   HmModUartWLAN1_RSSI -54
   HmModUartWLAN1_TIME 2018-03-29 17:21:01
   IODev      HmModUartWLAN1
   LASTInputDev HMUSB1
   MSGCNT     16
   NAME       Kerze
   NOTIFYDEV  global
   NR         1031
   NTFY_ORDER 50-Kerze
   STATE      on
   TYPE       CUL_HM
   lastMsg    No:FC - t:02 s:4D4685 d:26EA36 0101C88038
   peerList   FB_1_392AF8_Btn_05,
   protLastRcv 2018-03-29 17:21:02
   protSnd    6 last_at:2018-03-29 17:21:00
   protState  CMDs_done
   rssi_HMUSB1 avg:-73 min:-73 max:-73 lst:-73 cnt:1
   rssi_HmModUartWLAN1 avg:-56 min:-56 max:-56 lst:-56 cnt:4
   rssi_at_HMLAN1 avg:-78.2 min:-80 max:-77 lst:-78 cnt:5
   rssi_at_HMUSB1 avg:-72 min:-72 max:-72 lst:-72 cnt:6
   rssi_at_HmModUartWLAN1 avg:-54 min:-54 max:-54 lst:-54 cnt:5
   Helper:
     DBLOG:
       battery:
         myDbLog:
           TIME       1522336861.21706
           VALUE      low
       deviceMsg:
         myDbLog:
           TIME       1522336861.21706
           VALUE      on (to vccu)
       level:
         myDbLog:
           TIME       1522336861.21706
           VALUE      100
       pct:
         myDbLog:
           TIME       1522336861.21706
           VALUE      100
       state:
         myDbLog:
           TIME       1522336861.21706
           VALUE      on
       timedOn:
         myDbLog:
           TIME       1522336861.21706
           VALUE      off
   READINGS:
     2018-03-29 17:21:01   CommandAccepted yes
     2017-01-06 14:43:06   D-firmware      1.7
     2017-01-06 14:43:06   D-serialNr      NEQ0696523
     2017-10-04 17:39:27   PairedTo        0x26EA36
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-lgActionType jmpToTarget
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-lgCtDlyOff geLo
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-lgCtDlyOn geLo
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-lgCtOff geLo
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-lgCtOn geLo
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-lgCtValHi 100
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-lgCtValLo 50
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-lgMultiExec on
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-lgOffDly 0 s
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-lgOffTime unused
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-lgOffTimeMode absolut
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-lgOnDly 0 s
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-lgOnTime unused
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-lgOnTimeMode absolut
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-lgSwJtDlyOff off
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-lgSwJtDlyOn on
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-lgSwJtOff dlyOn
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-lgSwJtOn dlyOff
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-shActionType jmpToTarget
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-shCtDlyOff geLo
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-shCtDlyOn geLo
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-shCtOff geLo
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-shCtOn geLo
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-shCtValHi 100
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-shCtValLo 50
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-shMultiExec off
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-shOffDly 0 s
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-shOffTime unused
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-shOffTimeMode absolut
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-shOnDly 0 s
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-shOnTime unused
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-shOnTimeMode absolut
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-shSwJtDlyOff off
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-shSwJtDlyOn on
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-shSwJtOff dlyOn
     2017-01-07 12:44:58   R-FB_1_392AF8_Btn_05-shSwJtOn dlyOff
     2017-01-05 15:42:24   R-intKeyVisib   invisib
     2017-01-05 15:42:24   R-ledMode       off
     2017-01-06 14:43:41   R-lowBatLimitBA 5 V
     2017-01-05 15:42:24   R-pairCentral   0x26EA36
     2017-01-05 15:42:25   R-sign          off
     2017-10-04 17:39:27   RegL_00.        02:01 05:00 0A:26 0B:EA 0C:36 12:32  00:00
     2017-10-04 17:39:28   RegL_01.        08:00 00:00
     2017-10-04 17:39:30   RegL_03.FB_1_392AF8_Btn_05 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:63 00:00
     2018-03-29 17:21:01   battery         low
     2018-03-29 17:21:01   deviceMsg       on (to vccu)
     2018-03-29 17:21:01   level           100
     2018-03-29 17:21:01   pct             100
     2018-03-29 15:43:55   peerList        FB_1_392AF8_Btn_05,
     2017-10-04 17:39:24   powerOn         2017-10-04 17:39:24
     2018-03-29 17:21:01   recentStateType ack
     2018-03-29 17:21:01   state           on
     2018-03-29 17:21:01   timedOn         off
     2018-03-26 23:45:37   trigLast        FB_1_392AF8_Btn_05:short
     2018-03-26 23:45:37   trig_FB_1_392AF8_Btn_05 Short_38
   helper:
     HM_CMDNR   252
     cSnd       1126EA364D46850201000000,1126EA364D46850201C80000
     dlvlCmd    ++A01126EA364D46850201C80000
     mId        006C
     regLst     ,0,1,3p
     rxType     2
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        1
       raw        1
       tpl        0
     io:
       newChn     +4D4685,00,00,00
       nextSend   1522336862.49729
       prefIO     
       rxt        0
       vccu       vccu
       p:
         4D4685
         00
         00
         00
     mRssi:
       mNo        FC
       io:
         HMLAN1:
           -78
           -78
         HMUSB1:
           -72
           -72
         HmModUartWLAN1:
           -48
           -48
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rssi:
       HMUSB1:
         avg        -73
         cnt        1
         lst        -73
         max        -73
         min        -73
       HmModUartWLAN1:
         avg        -56
         cnt        4
         lst        -56
         max        -56
         min        -56
       at_HMLAN1:
         avg        -78.2
         cnt        5
         lst        -78
         max        -77
         min        -80
       at_HMUSB1:
         avg        -72
         cnt        6
         lst        -72
         max        -72
         min        -72
       at_HmModUartWLAN1:
         avg        -54
         cnt        5
         lst        -54
         max        -54
         min        -54
     shadowReg:
     tmpl:
Attributes:
   IODev      HmModUartWLAN1
   IOgrp      vccu
   autoReadReg 4_reqStatus
   expert     3_allReg+raw
   firmware   1.7
   icon       icoHEIZUNG
   model      HM-LC-SW1-BA-PCB
   msgRepeat  1
   peerIDs    00000000,392AF805,
   room       1.30_Wohnzimmer,CUL_HM
   serialNr   NEQ0696523
   subType    switch
   webCmd     statusRequest:toggle:on:off


Gruß, Michael

Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 29 März 2018, 18:42:26
Kannst du mir von den beiden Device noch eine RAW Definition posten, dass ich so nachbilden und testen kann bitte.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: networker am 29 März 2018, 20:18:13
RAW vom  HM-CC-RT-DN


defmod BaZi_Heizkreis CUL_HM 26E564
attr BaZi_Heizkreis IODev HmModUartWLAN1
attr BaZi_Heizkreis IOgrp vccu
attr BaZi_Heizkreis actCycle 000:10
attr BaZi_Heizkreis actStatus alive
attr BaZi_Heizkreis autoReadReg 4_reqStatus
attr BaZi_Heizkreis expert 3
attr BaZi_Heizkreis firmware 1.4
attr BaZi_Heizkreis icon hm-cc-rt-dn
attr BaZi_Heizkreis model HM-CC-RT-DN
attr BaZi_Heizkreis room CUL_HM
attr BaZi_Heizkreis serialNr LEQ0111245
attr BaZi_Heizkreis subType thermostat
attr BaZi_Heizkreis verbose 3
attr BaZi_Heizkreis webCmd getConfig:clear msgEvents:burstXmit

setstate BaZi_Heizkreis CMDs_done
setstate BaZi_Heizkreis 2018-03-29 20:13:05 .protLastRcv 2018-03-29 20:13:05
setstate BaZi_Heizkreis 2018-03-29 15:43:54 Activity alive
setstate BaZi_Heizkreis 2018-03-29 05:57:35 CommandAccepted yes
setstate BaZi_Heizkreis 2015-10-13 23:14:14 D-firmware 1.4
setstate BaZi_Heizkreis 2015-10-13 23:14:14 D-serialNr LEQ0111245
setstate BaZi_Heizkreis 2017-12-30 17:48:03 PairedTo 0x26EA36
setstate BaZi_Heizkreis 2015-10-13 23:16:12 R-backOnTime 10 s
setstate BaZi_Heizkreis 2015-10-14 00:19:48 R-btnLock on
setstate BaZi_Heizkreis 2015-10-13 23:16:12 R-burstRx on
setstate BaZi_Heizkreis 2015-10-13 23:16:12 R-cyclicInfoMsg on
setstate BaZi_Heizkreis 2015-10-13 23:16:12 R-cyclicInfoMsgDis 0
setstate BaZi_Heizkreis 2015-10-14 00:22:31 R-globalBtnLock off
setstate BaZi_Heizkreis 2015-10-13 23:16:12 R-localResDis off
setstate BaZi_Heizkreis 2015-10-13 23:16:12 R-lowBatLimitRT 2.1 V
setstate BaZi_Heizkreis 2015-10-13 23:16:12 R-modusBtnLock off
setstate BaZi_Heizkreis 2015-10-13 23:16:12 R-pairCentral 0x26EA36
setstate BaZi_Heizkreis 2017-12-30 17:48:03 RegL_00. 01:01 02:01 09:01 0A:26 0B:EA 0C:36 0E:0A 0F:01  11:00 12:15 16:00 18:00 19:00 1A:00 00:00
setstate BaZi_Heizkreis 2017-12-30 17:50:37 RegL_07.
setstate BaZi_Heizkreis 2018-03-29 20:13:05 actuator 0
setstate BaZi_Heizkreis 2018-03-29 20:13:05 battery ok
setstate BaZi_Heizkreis 2018-03-29 20:13:05 batteryLevel 2.6
setstate BaZi_Heizkreis 2018-03-29 20:13:05 desired-temp 22.0
setstate BaZi_Heizkreis 2018-03-29 20:13:05 measured-temp 23.0
setstate BaZi_Heizkreis 2018-03-29 20:13:05 motorErr ok
setstate BaZi_Heizkreis 2016-07-22 07:39:17 powerOn 2016-07-22 07:39:17
setstate BaZi_Heizkreis 2016-07-22 07:39:17 recentStateType info
setstate BaZi_Heizkreis 2018-03-29 16:07:36 state CMDs_done
setstate BaZi_Heizkreis 2018-03-29 16:07:36 time-request -


und vom HM-LC-SW1-BA-PCB


defmod Kerze CUL_HM 4D4685
attr Kerze IODev HmModUartWLAN1
attr Kerze IOgrp vccu
attr Kerze autoReadReg 4_reqStatus
attr Kerze expert 3_allReg+raw
attr Kerze firmware 1.7
attr Kerze icon icoHEIZUNG
attr Kerze model HM-LC-SW1-BA-PCB
attr Kerze msgRepeat 1
attr Kerze peerIDs 00000000,392AF805,
attr Kerze room 1.30_Wohnzimmer,CUL_HM
attr Kerze serialNr NEQ0696523
attr Kerze subType switch
attr Kerze webCmd statusRequest:toggle:on:off

setstate Kerze on
setstate Kerze 2017-01-06 14:43:06 .D-devInfo 410100
setstate Kerze 2017-01-06 14:43:06 .D-stc 10
setstate Kerze 2017-10-04 17:39:28 .peerListRDate 2017-10-04 17:39:28
setstate Kerze 2018-03-29 18:49:49 .protLastRcv 2018-03-29 18:49:49
setstate Kerze 2018-03-29 18:49:48 CommandAccepted yes
setstate Kerze 2017-01-06 14:43:06 D-firmware 1.7
setstate Kerze 2017-01-06 14:43:06 D-serialNr NEQ0696523
setstate Kerze 2017-10-04 17:39:27 PairedTo 0x26EA36
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-lgActionType jmpToTarget
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-lgCtDlyOff geLo
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-lgCtDlyOn geLo
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-lgCtOff geLo
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-lgCtOn geLo
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-lgCtValHi 100
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-lgCtValLo 50
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-lgMultiExec on
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-lgOffDly 0 s
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-lgOffTime unused
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-lgOffTimeMode absolut
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-lgOnDly 0 s
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-lgOnTime unused
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-lgOnTimeMode absolut
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-lgSwJtDlyOff off
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-lgSwJtDlyOn on
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-lgSwJtOff dlyOn
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-lgSwJtOn dlyOff
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-shActionType jmpToTarget
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-shCtDlyOff geLo
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-shCtDlyOn geLo
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-shCtOff geLo
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-shCtOn geLo
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-shCtValHi 100
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-shCtValLo 50
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-shMultiExec off
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-shOffDly 0 s
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-shOffTime unused
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-shOffTimeMode absolut
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-shOnDly 0 s
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-shOnTime unused
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-shOnTimeMode absolut
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-shSwJtDlyOff off
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-shSwJtDlyOn on
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-shSwJtOff dlyOn
setstate Kerze 2017-01-07 12:44:58 R-FB_1_392AF8_Btn_05-shSwJtOn dlyOff
setstate Kerze 2017-01-05 15:42:24 R-intKeyVisib invisib
setstate Kerze 2017-01-05 15:42:24 R-ledMode off
setstate Kerze 2017-01-06 14:43:41 R-lowBatLimitBA 5 V
setstate Kerze 2017-01-05 15:42:24 R-pairCentral 0x26EA36
setstate Kerze 2017-01-05 15:42:25 R-sign off
setstate Kerze 2017-10-04 17:39:27 RegL_00. 02:01 05:00 0A:26 0B:EA 0C:36 12:32  00:00
setstate Kerze 2017-10-04 17:39:28 RegL_01. 08:00 00:00
setstate Kerze 2017-10-04 17:39:30 RegL_03.FB_1_392AF8_Btn_05 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:63 00:00
setstate Kerze 2018-03-29 18:49:48 battery low
setstate Kerze 2018-03-29 18:49:48 deviceMsg on (to vccu)
setstate Kerze 2018-03-29 18:49:48 level 100
setstate Kerze 2018-03-29 18:49:48 pct 100
setstate Kerze 2018-03-29 15:43:55 peerList FB_1_392AF8_Btn_05,
setstate Kerze 2017-10-04 17:39:24 powerOn 2017-10-04 17:39:24
setstate Kerze 2018-03-29 18:49:48 recentStateType ack
setstate Kerze 2018-03-29 18:49:48 state on
setstate Kerze 2018-03-29 18:49:48 timedOn off
setstate Kerze 2018-03-26 23:45:37 trigLast FB_1_392AF8_Btn_05:short
setstate Kerze 2018-03-26 23:45:37 trig_FB_1_392AF8_Btn_05 Short_38


Gruß, Michael
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 30 März 2018, 16:57:43
Konnte die Fehler nachstellen und dürften jetzt behoben sein. Dein HM-LC-SW1-BA-PCB sollte bei seiner nächsten Meldung nach dem Update auch automatisch in Dummy für den Status sowie in der ReadingsGroup auftauchen. Sollte doch noch etwas sein bitte Bescheid geben.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: networker am 30 März 2018, 20:14:09
Bei der HM-CC-RT-DN kommt jetzt im Log (loglevel 3)

2018.03.30 19:54:42 3 : BaZi_Heizkreis, 'battery: ok' ignored, has batteryLevel reading
2018.03.30 19:54:42 3 : batteryLevel Strang


beim HM-LC-SW1-BA-PCB leider noch keine Änderung.
Im Eventmanager kommt

2018-03-30 19:57:36 CUL_HM Kerze battery: low
2018-03-30 19:57:36 CUL_HM Kerze deviceMsg: off (to vccu)
2018-03-30 19:57:36 CUL_HM Kerze level: 0
2018-03-30 19:57:36 CUL_HM Kerze pct: 0
2018-03-30 19:57:36 CUL_HM Kerze off
2018-03-30 19:57:36 CUL_HM Kerze timedOn: off


Was mir noch aufgefallen ist, das von 6 HM-TC-IT-WM-W-EU melden 2 Stück auch den _Climate Kanal mit.

RAW vom dem ohne _Climate
Internals:
   CFGFN      ./FHEM/flur.cfg
   DEF        2D3362
   HMLAN1_MSGCNT 14
   HMLAN1_RAWMSG E2D3362,0000,09790776,FF,FFA3,D884702D336200000000E636
   HMLAN1_RSSI -93
   HMLAN1_TIME 2018-03-30 20:04:30
   HMUSB1_MSGCNT 14
   HMUSB1_RAWMSG E2D3362,0000,6DCC8B2D,FF,FFA8,D884702D336200000000E636
   HMUSB1_RSSI -88
   HMUSB1_TIME 2018-03-30 20:04:30
   HmModUartWLAN1_MSGCNT 13
   HmModUartWLAN1_RAWMSG 05000026D884702D336200000000E636
   HmModUartWLAN1_RSSI -38
   HmModUartWLAN1_TIME 2018-03-30 20:04:30
   IODev      HmModUartWLAN1
   LASTInputDev HMUSB1
   MSGCNT     41
   NAME       Flur_Thermostat
   NOTIFYDEV  global
   NR         615
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 Flur_Thermostat_Weather
   channel_02 Flur_Thermostat_Climate
   channel_03 Flur_Thermostat_WindowRec
   channel_06 Flur_Thermostat_remote
   channel_07 Flur_Thermostat_SwitchTr
   lastMsg    No:D8 - t:70 s:2D3362 d:000000 00E636
   protLastRcv 2018-03-30 20:04:30
   rssi_at_HMLAN1 avg:-92.78 min:-93 max:-92 lst:-93 cnt:14
   rssi_at_HMUSB1 avg:-88.5 min:-90 max:-87 lst:-88 cnt:14
   rssi_at_HmModUartWLAN1 avg:-38 min:-38 max:-38 lst:-38 cnt:13
   READINGS:
     2018-03-30 19:51:44   Activity        alive
     2018-03-29 12:28:15   CommandAccepted yes
     2016-12-30 19:05:01   D-firmware      1.3
     2016-12-30 19:05:01   D-serialNr      LEQ0598568
     2018-02-11 11:01:55   PairedTo        0x26EA36
     2016-12-30 19:06:56   R-btnLock       on
     2016-12-30 18:25:45   R-burstRx       on
     2016-12-30 18:25:45   R-cyclicInfoMsg on
     2016-12-30 18:25:45   R-cyclicInfoMsgDis 0
     2016-12-30 18:25:45   R-globalBtnLock off
     2016-12-30 18:25:45   R-localResDis   off
     2016-12-30 18:25:45   R-lowBatLimitRT 2.2 V
     2016-12-30 18:25:45   R-modusBtnLock  off
     2016-12-30 18:25:45   R-pairCentral   0x26EA36
     2018-02-11 11:01:55   RegL_00.        01:01 02:01 09:01 0A:26 0B:EA 0C:36 0F:01 11:00  12:16 16:00 18:00 19:00 1A:00 00:00
     2018-02-11 11:19:05   RegL_07.       
     2018-03-30 18:20:36   battery         ok
     2018-03-30 18:20:36   batteryLevel    2.7
     2018-03-30 18:20:36   desired-temp    21.0
     2018-03-30 18:20:36   measured-temp   23.0
     2017-09-30 09:58:32   powerOn         2017-09-30 09:58:32
     2017-09-30 09:58:32   recentStateType info
     2018-03-29 12:28:16   state           CMDs_done
     2017-09-30 09:58:34   time-request    -
   helper:
     HM_CMDNR   216
     PONtest    1
     mId        00AD
     regLst     ,0
     rxType     6
     supp_Pair_Rep 0
     expert:
       def        1
       det        1
       raw        1
       tpl        0
     io:
       newChn     +2D3362,00,00,00
       nextSend   1522433070.404
       prefIO     
       rxt        0
       vccu       vccu
       p:
         2D3362
         00
         00
         00
     mRssi:
       mNo        D8
       io:
         HMLAN1:
           -93
           -93
         HMUSB1:
           -88
           -88
         HmModUartWLAN1:
           -30
           -30
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       at_HMLAN1:
         avg        -92.7857142857143
         cnt        14
         lst        -93
         max        -92
         min        -93
       at_HMUSB1:
         avg        -88.5
         cnt        14
         lst        -88
         max        -87
         min        -90
       at_HmModUartWLAN1:
         avg        -38
         cnt        13
         lst        -38
         max        -38
         min        -38
     shRegW:
       07         02
     shadowReg:
     tmpl:
Attributes:
   IODev      HmModUartWLAN1
   IOgrp      vccu
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   event-on-change-reading .*
   expert     3_allReg+raw
   firmware   1.3
   icon       hm-tc-it-wm-w-eu
   model      HM-TC-IT-WM-W-EU
   msgRepeat  1
   room       CUL_HM
   serialNr   LEQ0598568
   subType    thermostat
   verbose    3
   webCmd     getConfig:clear msgEvents


Internals:
   CFGFN      ./FHEM/flur.cfg
   DEF        2D336202
   NAME       Flur_Thermostat_Climate
   NOTIFYDEV  global
   NR         621
   STATE      T: 23.0 desired: 21.0
   TYPE       CUL_HM
   chanNo     02
   device     Flur_Thermostat
   Helper:
     DBLOG:
       desired-temp:
         myDbLog:
           TIME       1522433050.29181
           VALUE      21.0
       humidity:
         myDbLog:
           TIME       1522433050.29181
           VALUE      53
       measured-temp:
         myDbLog:
           TIME       1522433050.29181
           VALUE      23.0
       state:
         myDbLog:
           TIME       1522433050.29181
           VALUE      T: 23.0 desired: 21.0
   READINGS:
     2018-03-29 12:28:16   CommandAccepted yes
     2016-12-30 18:25:50   R-boostPeriod   5 min
     2016-12-30 18:25:50   R-dayTemp       21 C
     2016-12-30 18:25:50   R-daylightSaveTime on
     2016-12-30 18:25:50   R-heatCool      heating
     2016-12-30 18:25:50   R-modePrioManu  all
     2016-12-30 18:25:50   R-modePrioParty all
     2016-12-30 18:25:50   R-nightTemp     17 C
     2016-12-30 18:25:50   R-noMinMax4Manu off
     2016-12-30 18:25:50   R-sendWeatherData on
     2016-12-30 18:25:50   R-showHumidity  temp
     2016-12-30 18:25:50   R-showInfo      time
     2016-12-30 18:25:50   R-showSetTemp   actTemp
     2016-12-30 18:25:50   R-showWeekday   off
     2016-12-30 18:25:46   R-sign          off
     2016-12-30 18:25:50   R-tempMax       30.5 C
     2016-12-30 18:25:50   R-tempMin       4.5 C
     2016-12-30 18:25:50   R-tempOffset    0.0K
     2016-12-30 18:25:50   R-weekPrgSel    prog1
     2016-12-30 18:25:50   R-winOpnBoost   off
     2018-02-11 11:02:01   R_P1_0_tempListSat 06:00 17.0 22:00 21.0 24:00 17.0
     2018-02-11 11:02:01   R_P1_1_tempListSun 06:00 17.0 22:00 21.0 24:00 17.0
     2018-02-11 11:02:01   R_P1_2_tempListMon 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
     2018-02-11 11:02:01   R_P1_3_tempListTue 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
     2018-02-11 11:02:01   R_P1_4_tempListWed 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
     2018-02-11 11:02:01   R_P1_5_tempListThu 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
     2018-02-11 11:02:01   R_P1_6_tempListFri 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
     2018-02-11 11:02:01   R_P1_tempList_State verified
     2018-02-11 11:02:05   R_P2_0_tempListSat 24:00 17.0
     2018-02-11 11:02:05   R_P2_1_tempListSun 24:00 17.0
     2018-02-11 11:02:05   R_P2_2_tempListMon 24:00 17.0
     2018-02-11 11:02:05   R_P2_3_tempListTue 24:00 17.0
     2018-02-11 11:02:05   R_P2_4_tempListWed 24:00 17.0
     2018-02-11 11:02:05   R_P2_5_tempListThu 24:00 17.0
     2018-02-11 11:02:05   R_P2_6_tempListFri 24:00 17.0
     2018-02-11 11:02:05   R_P2_tempList_State verified
     2018-02-11 11:02:09   R_P3_0_tempListSat 24:00 17.0
     2018-02-11 11:02:09   R_P3_1_tempListSun 24:00 17.0
     2018-02-11 11:02:09   R_P3_2_tempListMon 24:00 17.0
     2018-02-11 11:02:09   R_P3_3_tempListTue 24:00 17.0
     2018-02-11 11:02:09   R_P3_4_tempListWed 24:00 17.0
     2018-02-11 11:02:09   R_P3_5_tempListThu 24:00 17.0
     2018-02-11 11:02:09   R_P3_6_tempListFri 24:00 17.0
     2018-02-11 11:02:09   R_P3_tempList_State verified
     2018-02-11 11:01:57   RegL_01.        08:00 00:00
     2018-02-11 11:02:01   RegL_07.        01:2A 02:22 03:09 04:3D 05:00 06:00 07:00 08:00 09:87 0A:30 0B:00 0C:00 0D:00 0E:01 0F:04 10:00 11:00 12:09 13:00 14:44 15:48 16:55 17:08 18:45 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:44 2F:48 30:55 31:08 32:45 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:44 49:48 4A:54 4B:6C 4C:44 4D:CC 4E:55 4F:08 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:44 63:48 64:54 65:6C 66:44 67:CC 68:55 69:08 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:44 7D:48 7E:54 7F:6C 80:44 81:CC 82:55 83:08 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:44 97:48 98:54 99:6C 9A:44 9B:CC 9C:55 9D:08 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:44 B1:48 B2:54 B3:6C B4:44 B5:CC B6:55 B7:08 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:00 CB:00 CC:00 CD:00 CE:00 CF:00 00:00
     2018-02-11 11:02:05   RegL_08.        01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:00 0B:00 0C:00 0D:00 0E:00 0F:00 10:00 11:00 12:00 13:00 14:45 15:20 16:45 17:20 18:45 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:45 2F:20 30:45 31:20 32:45 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:45 49:20 4A:45 4B:20 4C:45 4D:20 4E:45 4F:20 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:45 63:20 64:45 65:20 66:45 67:20 68:45 69:20 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:45 7D:20 7E:45 7F:20 80:45 81:20 82:45 83:20 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:45 97:20 98:45 99:20 9A:45 9B:20 9C:45 9D:20 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:45 B1:20 B2:45 B3:20 B4:45 B5:20 B6:45 B7:20 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:00 CB:00 CC:00 CD:00 CE:00 CF:00 00:00
     2018-02-11 11:02:09   RegL_09.        01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:00 0B:00 0C:00 0D:00 0E:00 0F:00 10:00 11:00 12:00 13:00 14:45 15:20 16:45 17:20 18:45 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:45 2F:20 30:45 31:20 32:45 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:45 49:20 4A:45 4B:20 4C:45 4D:20 4E:45 4F:20 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:45 63:20 64:45 65:20 66:45 67:20 68:45 69:20 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:45 7D:20 7E:45 7F:20 80:45 81:20 82:45 83:20 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:45 97:20 98:45 99:20 9A:45 9B:20 9C:45 9D:20 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:45 B1:20 B2:45 B3:20 B4:45 B5:20 B6:45 B7:20 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:00 CB:00 CC:00 CD:00 CE:00 CF:00 00:00
     2018-03-30 18:20:36   boostTime       -
     2018-03-30 18:20:36   commReporting   off
     2018-03-30 18:20:36   controlMode     manual
     2018-03-30 20:04:10   desired-temp    21.0
     2018-03-30 20:04:10   humidity        53
     2018-03-30 20:04:10   measured-temp   23.0
     2018-03-29 12:28:16   recentStateType ack
     2018-03-30 20:04:10   state           T: 23.0 desired: 21.0
     2018-03-30 18:20:36   winOpenReporting off
   helper:
     regLst     ,1,7,8,9
     expert:
       def        1
       det        1
       raw        1
       tpl        0
     role:
       chn        1
     shRegR:
       07         00
     shadowReg:
     tmpl:
Attributes:
   event-min-interval .*:600
   event-on-change-reading .*
   model      HM-TC-IT-WM-W-EU
   peerIDs    00000000,


RAW vom dem mit _Climate

Internals:
   CFGFN      ./FHEM/kinderzimmer.cfg
   DEF        2D4D41
   HMLAN1_MSGCNT 19
   HMLAN1_RAWMSG E2D4D41,0000,097BDD60,FF,FFA2,0280412D4D412A16DB07EA0080
   HMLAN1_RSSI -94
   HMLAN1_TIME 2018-03-30 20:07:36
   HMUSB1_MSGCNT 19
   HMUSB1_RAWMSG E2D4D41,0000,6DCF60F8,FF,FFB7,0280412D4D412A16DB07EA0080
   HMUSB1_RSSI -73
   HMUSB1_TIME 2018-03-30 20:07:36
   HmModUartWLAN1_MSGCNT 18
   HmModUartWLAN1_RAWMSG 0500003D0280412D4D412A16DB07EA0080
   HmModUartWLAN1_RSSI -61
   HmModUartWLAN1_TIME 2018-03-30 20:07:36
   IODev      HmModUartWLAN1
   LASTInputDev HMUSB1
   MSGCNT     56
   NAME       KiZi_Thermostat
   NOTIFYDEV  global
   NR         417
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 KiZi_Thermostat_Weather
   channel_02 KiZi_Thermostat_Climate
   channel_03 KiZi_Thermostat_WindowRec
   channel_06 KiZi_Thermostat_remote
   channel_07 KiZi_Thermostat_SwitchTr
   lastMsg    No:02 - t:41 s:2D4D41 d:2A16DB 07EA0080
   protLastRcv 2018-03-30 20:07:36
   rssi_at_HMLAN1 avg:-94.1 min:-95 max:-93 lst:-94 cnt:19
   rssi_at_HMUSB1 avg:-72.84 min:-73 max:-72 lst:-73 cnt:19
   rssi_at_HmModUartWLAN1 avg:-60.38 min:-61 max:-60 lst:-61 cnt:18
   Helper:
     DBLOG:
       batteryLevel:
         myDbLog:
           TIME       1522433183.75021
           VALUE      2.8
       measured-temp:
         myDbLog:
           TIME       1522433183.75021
           VALUE      22.9
   READINGS:
     2018-03-30 19:51:44   Activity        alive
     2018-03-30 10:38:19   CommandAccepted yes
     2016-12-30 21:25:45   D-firmware      1.3
     2016-12-31 14:22:53   D-serialNr      LEQ0594422
     2017-11-08 18:25:18   PairedTo        0x26EA36
     2016-12-30 21:38:39   R-btnLock       on
     2015-10-13 23:08:43   R-burstRx       on
     2015-10-13 23:08:43   R-cyclicInfoMsg on
     2015-10-13 23:08:43   R-cyclicInfoMsgDis 0
     2015-10-13 23:08:43   R-globalBtnLock off
     2015-10-13 23:08:43   R-localResDis   off
     2015-10-13 23:08:43   R-lowBatLimitRT 2.2 V
     2015-10-13 23:08:43   R-modusBtnLock  off
     2015-10-13 23:08:43   R-pairCentral   0x26EA36
     2017-11-08 18:25:18   RegL_00.        01:01 02:01 09:01 0A:26 0B:EA 0C:36 0F:01 11:00  12:16 16:00 18:00 19:00 1A:00 00:00
     2017-11-08 18:31:27   RegL_07.       
     2018-03-30 20:06:23   battery         ok
     2018-03-30 20:06:23   batteryLevel    2.8
     2018-03-30 20:06:23   desired-temp    21.0
     2016-12-30 20:53:44   fwUpdate        fail:Block5
     2018-03-30 20:06:23   measured-temp   22.9
     2017-11-08 18:25:13   powerOn         2017-11-08 18:25:13
     2017-11-08 18:25:13   recentStateType info
     2018-03-30 10:38:20   state           CMDs_done
     2017-11-08 18:25:15   time-request    -
   helper:
     HM_CMDNR   2
     PONtest    1
     mId        00AD
     regLst     ,0
     rxType     6
     supp_Pair_Rep 0
     expert:
       def        1
       det        1
       raw        1
       tpl        0
     io:
       newChn     +2D4D41,00,00,00
       nextSend   1522433256.22652
       prefIO     
       rxt        0
       vccu       vccu
       p:
         2D4D41
         00
         00
         00
     mRssi:
       mNo        02
       io:
         HMLAN1:
           -94
           -94
         HMUSB1:
           -73
           -73
         HmModUartWLAN1:
           -57
           -57
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       at_HMLAN1:
         avg        -94.1052631578947
         cnt        19
         lst        -94
         max        -93
         min        -95
       at_HMUSB1:
         avg        -72.8421052631579
         cnt        19
         lst        -73
         max        -72
         min        -73
       at_HmModUartWLAN1:
         avg        -60.3888888888889
         cnt        18
         lst        -61
         max        -60
         min        -61
     shRegW:
       07         02
     shadowReg:
     tmpl:
Attributes:
   IODev      HmModUartWLAN1
   IOgrp      vccu
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   event-on-change-reading .*
   expert     3
   firmware   1.3
   icon       hm-tc-it-wm-w-eu
   model      HM-TC-IT-WM-W-EU
   msgRepeat  1
   room       CUL_HM
   serialNr   LEQ0594422
   subType    thermostat
   verbose    3
   webCmd     getConfig:clear msgEvents

Internals:
   CFGFN      ./FHEM/kinderzimmer.cfg
   CHANGED   
   DEF        2D4D4102
   NAME       KiZi_Thermostat_Climate
   NOTIFYDEV  global
   NR         423
   STATE      T: 22.9 desired: 21.0
   TYPE       CUL_HM
   chanNo     02
   device     KiZi_Thermostat
   Helper:
     DBLOG:
       boostTime:
         myDbLog:
           TIME       1522433024.79706
           VALUE      -
       commReporting:
         myDbLog:
           TIME       1522433024.79706
           VALUE      off
       controlMode:
         myDbLog:
           TIME       1522433024.79706
           VALUE      manual
       desired-temp:
         myDbLog:
           TIME       1522433173.74382
           VALUE      21.0
       humidity:
         myDbLog:
           TIME       1522433014.73513
           VALUE      55
       measured-temp:
         myDbLog:
           TIME       1522433173.74382
           VALUE      22.9
       state:
         myDbLog:
           TIME       1522433173.74382
           VALUE      T: 22.9 desired: 21.0
       winOpenReporting:
         myDbLog:
           TIME       1522433024.79706
           VALUE      off
   READINGS:
     2018-03-30 10:38:20   CommandAccepted yes
     2015-10-13 23:08:48   R-boostPeriod   5 min
     2015-10-13 23:08:48   R-dayTemp       21 C
     2015-10-13 23:08:48   R-daylightSaveTime on
     2015-10-13 23:08:48   R-heatCool      heating
     2015-10-13 23:08:48   R-hyst2point    0.4 C
     2015-10-13 23:08:48   R-modePrioManu  all
     2015-10-13 23:08:48   R-modePrioParty all
     2015-10-13 23:08:48   R-nightTemp     17 C
     2015-10-13 23:08:48   R-noMinMax4Manu off
     2015-10-13 23:08:48   R-sendWeatherData on
     2015-10-13 23:08:48   R-showHumidity  temp
     2015-10-13 23:08:48   R-showInfo      time
     2015-10-13 23:08:48   R-showSetTemp   actTemp
     2015-10-13 23:08:48   R-showWeekday   off
     2015-10-13 23:08:44   R-sign          off
     2015-10-13 23:08:48   R-tempMax       30.5 C
     2015-10-13 23:08:48   R-tempMin       4.5 C
     2015-10-13 23:08:48   R-tempOffset    0.0K
     2015-10-13 23:08:48   R-weekPrgSel    prog1
     2015-10-13 23:08:48   R-winOpnBoost   off
     2017-11-08 18:25:23   R_P1_0_tempListSat 06:00 17.0 22:00 21.0 24:00 17.0
     2017-11-08 18:25:23   R_P1_1_tempListSun 06:00 17.0 22:00 21.0 24:00 17.0
     2017-11-08 18:25:23   R_P1_2_tempListMon 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
     2017-11-08 18:25:23   R_P1_3_tempListTue 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
     2017-11-08 18:25:23   R_P1_4_tempListWed 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
     2017-11-08 18:25:23   R_P1_5_tempListThu 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
     2017-11-08 18:25:23   R_P1_6_tempListFri 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
     2017-11-08 18:25:23   R_P1_tempList_State verified
     2017-11-08 18:25:27   R_P2_0_tempListSat 24:00 17.0
     2017-11-08 18:25:27   R_P2_1_tempListSun 24:00 17.0
     2017-11-08 18:25:27   R_P2_2_tempListMon 24:00 17.0
     2017-11-08 18:25:27   R_P2_3_tempListTue 24:00 17.0
     2017-11-08 18:25:27   R_P2_4_tempListWed 24:00 17.0
     2017-11-08 18:25:27   R_P2_5_tempListThu 24:00 17.0
     2017-11-08 18:25:27   R_P2_6_tempListFri 24:00 17.0
     2017-11-08 18:25:27   R_P2_tempList_State verified
     2017-11-08 18:25:31   R_P3_0_tempListSat 24:00 17.0
     2017-11-08 18:25:31   R_P3_1_tempListSun 24:00 17.0
     2017-11-08 18:25:31   R_P3_2_tempListMon 24:00 17.0
     2017-11-08 18:25:31   R_P3_3_tempListTue 24:00 17.0
     2017-11-08 18:25:31   R_P3_4_tempListWed 24:00 17.0
     2017-11-08 18:25:31   R_P3_5_tempListThu 24:00 17.0
     2017-11-08 18:25:31   R_P3_6_tempListFri 24:00 17.0
     2017-11-08 18:25:31   R_P3_tempList_State verified
     2017-11-08 18:25:19   RegL_01.        08:00 00:00
     2017-11-08 18:25:23   RegL_07.        01:2A 02:22 03:09 04:3D 05:00 06:00 07:00 08:00 09:87 0A:30 0B:00 0C:00 0D:00 0E:01 0F:04 10:00 11:00 12:09 13:00 14:44 15:48 16:55 17:08 18:45 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:44 2F:48 30:55 31:08 32:45 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:44 49:48 4A:54 4B:6C 4C:44 4D:CC 4E:55 4F:08 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:44 63:48 64:54 65:6C 66:44 67:CC 68:55 69:08 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:44 7D:48 7E:54 7F:6C 80:44 81:CC 82:55 83:08 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:44 97:48 98:54 99:6C 9A:44 9B:CC 9C:55 9D:08 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:44 B1:48 B2:54 B3:6C B4:44 B5:CC B6:55 B7:08 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:00 CB:00 CC:00 CD:00 CE:00 CF:00 00:00
     2017-11-08 18:25:27   RegL_08.        01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:00 0B:00 0C:00 0D:00 0E:00 0F:00 10:00 11:00 12:00 13:00 14:45 15:20 16:45 17:20 18:45 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:45 2F:20 30:45 31:20 32:45 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:45 49:20 4A:45 4B:20 4C:45 4D:20 4E:45 4F:20 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:45 63:20 64:45 65:20 66:45 67:20 68:45 69:20 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:45 7D:20 7E:45 7F:20 80:45 81:20 82:45 83:20 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:45 97:20 98:45 99:20 9A:45 9B:20 9C:45 9D:20 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:45 B1:20 B2:45 B3:20 B4:45 B5:20 B6:45 B7:20 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:00 CB:00 CC:00 CD:00 CE:00 CF:00 00:00
     2017-11-08 18:25:31   RegL_09.        01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:00 0B:00 0C:00 0D:00 0E:00 0F:00 10:00 11:00 12:00 13:00 14:45 15:20 16:45 17:20 18:45 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:45 2F:20 30:45 31:20 32:45 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:45 49:20 4A:45 4B:20 4C:45 4D:20 4E:45 4F:20 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:45 63:20 64:45 65:20 66:45 67:20 68:45 69:20 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:45 7D:20 7E:45 7F:20 80:45 81:20 82:45 83:20 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:45 97:20 98:45 99:20 9A:45 9B:20 9C:45 9D:20 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:45 B1:20 B2:45 B3:20 B4:45 B5:20 B6:45 B7:20 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:00 CB:00 CC:00 CD:00 CE:00 CF:00 00:00
     2015-11-04 19:15:06   battery         ok
     2018-03-30 20:06:23   boostTime       -
     2018-03-30 20:06:23   commReporting   off
     2018-03-30 20:06:23   controlMode     manual
     2018-03-30 20:08:38   desired-temp    21.0
     2018-03-30 20:08:38   humidity        55
     2018-03-30 20:08:38   measured-temp   22.9
     2018-03-30 10:38:20   recentStateType ack
     2018-03-30 20:08:38   state           T: 22.9 desired: 21.0
     2018-03-30 20:06:23   winOpenReporting off
   helper:
     regLst     ,1,7,8,9
     expert:
       def        1
       det        1
       raw        1
       tpl        0
     role:
       chn        1
     shRegR:
       07         00
     shadowReg:
     tmpl:
Attributes:
   event-min-interval .*:600
   event-on-change-reading .*
   model      HM-TC-IT-WM-W-EU
   peerIDs    00000000,
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 31 März 2018, 08:39:40
Bezüglich der Channel mit dem battery Readings ist die Frage wie aktuell dein FHEM bzw. CUL_HM ist? Früher war das so, dass das Reading auch in den Channels stand, wurde aber schon lange geändert. Daher schau mal auf den Timestamp das battery Reading im Channel, wie alt der ist.

BaZi_Heizkreis, 'battery: ok' ignored, has batteryLevel reading
Das ist bei Log3 normal so und wurde neu eingebaut. Würde, wenn dann alles klappt, auf Log2 wechseln.

batteryLevel Strang
Habe ich eine Logausgabe vom testen vergessen zu deaktivieren. Lösch mal in Zeile 211 folgendes:
Log 3, "batteryLevel Strang";
Dann ist das auch weg.


Zitatbeim HM-LC-SW1-BA-PCB leider noch keine Änderung.
Fehler gefunden. Bisher bin ich davon ausgegangen, dass man damit anfängt, das alle Device mit battery ok starten und nicht auch mit battery low beim ersten Anlegen. Jetzt dürfte er aber beim neuen Event angelegt werden. Neue Version gerade eingespielt.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: networker am 31 März 2018, 11:17:38
Bin gerade am Testen und hab gesehen, du hast noch deinen Telegram-User drinnen.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 31 März 2018, 11:26:35
Danke, gerade geändert.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: networker am 31 März 2018, 11:34:02
Funktioniert PERFEKT!

Das mit den alten Readings war ein guter Tipp, die waren aus 2015.
Einfach im -Climate Kanal ein "clear readings" und anschließend ein "get config" behebt das.

Frohe Ostern.
Gruß Michael
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 31 März 2018, 11:42:43
Top, freut mich. Dann mal bitte testen, ob es bei dir soweit läuft. Wie gesagt die Zeiten für die 5% sind noch nicht perfekt und teste ich immer noch. Ansonsten ist mir aufgefallen, dass es manchmal dazu kommt, dass ein Batteriewechsel erkannt wird, obwohl keiner stattgefunden hat. Sollte das bei noch jemanden sein bitte mal mit schauen, ob ihr den Grund seht.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 02 April 2018, 11:25:38
@Amenophis86:

ich bin immer noch begeistert, was du daraus gemacht hast!

Da mal wieder der eine oder andere Batteriewechsel ansteht habe ich mich endlich aufgerafft und eine Erweiterung geschrieben:

Berechnung der Wochen seit dem letzten Wechsel ;)

Ich hoffe du nimmst mir nich übel, dass ich immer noch meinen eigenen Code verwende ;)

Daher liefere ich den "Patch" in "gewohnter Weise" ;)
Meine "Konstanten" für die Namen der Dummies musst du halt leider anpassen...
...sollte aber an den gewählten Namen gut zu erkennen sein...

Mit folgender Sub berechne ich die Wochen seit dem letzten Wechsel:


#########################################################################
# Helper for readingsGroup BatteryStatus:
# reads the last battery change from dummy and
# calculates the battery life time since last change and
# stores it as reading in corresponding dummy device
sub my_CalculateBatteryLife($)
{
  my ($Device)  = @_;
  my $ActualLifeTimes = ReadingsVal($myDummyBatteryLifeTimes, $Device, "");
  my $LastChange = ReadingsAge($myDummyLastBatteryChange, $Device, 0);
  my $WeeksSinceLastChange = $LastChange % 604800;
  $WeeksSinceLastChange = ($LastChange - $WeeksSinceLastChange) / 604800;
 
  if($WeeksSinceLastChange > 0)
  {
    # appending actual calculated life time to last life times of device in dummy
    $ActualLifeTimes .= " $WeeksSinceLastChange";
    fhem("setreading $myDummyBatteryLifeTimes $Device $ActualLifeTimes");
  }
 
  Log3(undef, 3, "my_CalculateBatteryLife     Device: $Device    LastChange: $LastChange     WeeksSinceLastChange: $WeeksSinceLastChange");
}


Der Aufruf dieser Sub muss VOR dem Eintragen in den "Wechsel-Dummy" erfolgen, also bevor das Reading "Last Change" im Dummy aktualisiert wird (dieser Eintrag dient als Basis für die Berechnung und muss daher nat. der letzte Wechseleintrag sein).


Dann habe ich noch einen Dummy, in dem ich pro Device (ähnlich wie Batteriewechsel) die Wochen seit dem letzten Wechsel speichere.
Da mir nichts besseres eingefallen ist, immer einfach durch Leerzeichen getrennt hintereinander, also die jeweiligen Haltbarkeitswochen pro Device:


Internals:
   CFGFN     
   NAME       dmBatteryLifeTimes
   NR         113933
   STATE      ???
   TYPE       dummy
   READINGS:
     2018-04-02 10:47:12   Wandthermostat_WoZi 50 50
Attributes:


Hier im Beispiel hat also die Batterie für der Wandthermostat im Wohnzimmer 2x 50 Wochen gehalten.
(Funktion wurde 2x aufgerufen zum Test ;)  )


Und eine ReadingsGroup wegen der Übersicht:


Internals:
   CFGFN     
   DEF        <Gerät>,<>,<Haltbarkeit> NAME=dmBatteryLifeTimes:.*
   NAME       rgBatteryLifeTimes
   NR         114074
   NTFY_ORDER 50-rgBatteryLifeTimes
   STATE      Initialized
   TYPE       readingsGroup
   mayBeVisible 1
   CONTENT:
     dmBatteryLifeTimes 1
   CONTENT2:
   DEVICES:
     ARRAY(0x3a462e0)
     ARRAY(0x5d4bbb8)
   fhem:
     lastDefChange 16
     last_update 1522661070.87141
   helper:
     DEF       
     mapping    $READING
     positions:
       dmBatteryLifeTimes.Wandthermostat_WoZi 2:1
     values:
       formated:
         undef
         ARRAY(0x3a3a9a8)
       orig:
         undef
         ARRAY(0x54dafd0)
       prefixsuffix:
         undef
         ARRAY(0x3acfd38)
Attributes:
   alias      Batteriehaltbarkeiten
   mapping    $READING
   nolinks    1
   notime     1
   room       Overview,Overview Battery
   sortby     10


Vielleicht ja interessant...

Ich geh dann mal Batterien wechseln und teste ob das auch so klappt ;)

EDIT: klappt wohl soweit. Allerdings was mir noch nicht gefällt ist, dass (natürlich) für Geräte wo noch nie die Batterie gewechselt wurde (und somit nicht im Batteriewechsel-Dummy stehen) eine '0' beim ersten Batteriewechsel in die Haltbarkeit eingetragen wird... Habe es mal damit "abgefangen", dass nur Werte größer '0' eingetragen werden...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 03 April 2018, 15:36:30
Werde es mir die Tage mal ansehen. Vielen Dank :)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: fini am 29 April 2018, 00:52:43
moin,

habe das modul installiert.

leider wird bei mir gar nichts angezeigt.
habe z.b. mehre LaCrosse mit battery ok und homematic mit BATTERY_STATE 2.7

wenn ich im NO.BatterieNotify bei DEF
.*:*.BATTERY_STATE|battery|batteryLevel
eintrage, dann bekomme ich auch den zustand der batterien

was habe ich falsch gemacht.
im anhang wie es aussieht nach der installation.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 29 April 2018, 07:37:16
Hallo fini,

1. Es ist "noch" kein Modul, sondern nur verschieden Codeteile
2. Welche hast Version du genommen hast, also welchen Zweig vom Github?
3. Hast du die Start Funktion ausgeführt?  (Gehe ich jetzt mal von aus, weil die Dummys vorhanden sind)
4. Steht etwas im Log?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: fini am 29 April 2018, 08:41:35
Zitat von: Amenophis86 am 29 April 2018, 07:37:16
Hallo fini,

1. Es ist "noch" kein Modul, sondern nur verschieden Codeteile
2. Welche hast Version du genommen hast, also welchen Zweig vom Github?
3. Hast du die Start Funktion ausgeführt?  (Gehe ich jetzt mal von aus, weil die Dummys vorhanden sind)
4. Steht etwas im Log?

zu 2., ich habe https://github.com/Amenophis86/Batteryfunktion genommen
zu 3. ja
zu 4. nein

jetzt wird was angezeigt.
zu 2. hatte master, wusste nicht das man noch auswälen kann da  :o
jetz habe ich no-BatteryStatusBot
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: fini am 29 April 2018, 09:10:28
was noch nicht bei mir angezeigt wird ist
hue bewegungsmelder -> battery 100
und
homematic -> 4.BATTERY_STATE 2.7

und dummys haben alle fragezeichen
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 29 April 2018, 09:56:37
Die ??? bei den Dummys ist normal und bleibt so.

Mit Hue habe ich noch nicht gearbeitet. Da bitte ein List und eine RAW Defintion hier in Codetags posten. Muss ich mir ansehen. Gleiches für das Homematic Gerät, welches nicht funktioniert.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: fini am 29 April 2018, 10:13:30
Zitat von: Amenophis86 am 29 April 2018, 09:56:37
Die ??? bei den Dummys ist normal und bleibt so.

Mit Hue habe ich noch nicht gearbeitet. Da bitte ein List und eine RAW Defintion hier in Codetags posten. Muss ich mir ansehen. Gleiches für das Homematic Gerät, welches nicht funktioniert.

hue bewegungsmelder

Internals:
   DEF        sensor 8  IODev=hueBridge1
   ID         S8
   INTERVAL   
   IODev      hueBridge1
   NAME       hue_bewegungsmelder1
   NR         65
   STATE      Initialized
   TYPE       HUEDevice
   lastupdated 2018-04-29 09:41:40
   manufacturername Philips
   modelid    SML001
   name       K�che Sensor
   on         1
   reachable  1
   sensitivity 1
   swversion  6.1.0.18912
   type       ZLLPresence
   uniqueid   00:17:88:01:02:01:9b:a8-02-0406
   READINGS:
     2018-04-29 09:41:40   battery         100
     2018-04-29 09:41:40   reachable       1
     2018-04-29 09:41:40   state           nomotion
   helper:
     devtype    S
     update_timeout 1
     setList:
Attributes:
   IODev      hueBridge1
   room       HUEDevice



defmod hue_bewegungsmelder1 HUEDevice sensor 8  IODev=hueBridge1
attr hue_bewegungsmelder1 IODev hueBridge1
attr hue_bewegungsmelder1 room HUEDevice

setstate hue_bewegungsmelder1 2018-04-29 09:41:40 .lastupdated 2018-04-29 09:41:40
setstate hue_bewegungsmelder1 2018-04-29 09:41:40 battery 100
setstate hue_bewegungsmelder1 2018-04-29 09:41:40 reachable 1
setstate hue_bewegungsmelder1 2018-04-29 09:41:40 state nomotion


homematic termostat

Internals:
   DEF        NEQ0416601
   IODev      d_ccu
   NAME       k_Thermostat
   NR         33
   STATE      20.0
   TYPE       HMCCUDEV
   ccuaddr    NEQ0416601
   ccudevstate active
   ccuif      BidCos-RF
   ccuname    Heizung Kueche
   ccutype    HM-CC-RT-DN
   channels   7
   firmware   1.4
   statevals  devstate
   READINGS:
     2018-04-29 10:07:39   4.ACTUAL_TEMPERATURE 20.5
     2018-04-29 10:07:39   4.BATTERY_STATE 2.7
     2018-04-29 10:07:39   4.CONTROL_MODE  AUTO
     2018-04-29 10:07:39   4.PARTY_TEMPERATURE 5.0
     2018-04-29 10:07:39   4.SET_TEMPERATURE 20.0
     2018-04-29 10:07:39   4.VALVE_STATE   23
     2018-04-29 10:07:39   control         20.0
     2018-04-29 10:07:39   hmstate         20.0
     2018-04-29 10:07:39   state           20.0
   hmccu:
     dp:
       0.AES_KEY:
         OVAL       0
         VAL        0
       0.CONFIG_PENDING:
         OVAL       false
         VAL        false
       0.DEVICE_IN_BOOTLOADER:
         OVAL       false
         VAL        false
       0.INHIBIT:
         OVAL       false
         VAL        false
       0.LOWBAT:
         OVAL       false
         VAL        false
       0.RSSI_DEVICE:
         OVAL       1
         VAL        1
       0.RSSI_PEER:
         OVAL       211
         VAL        211
       0.STICKY_UNREACH:
         OVAL       false
         VAL        false
       0.UNREACH:
         OVAL       false
         VAL        false
       0.UPDATE_PENDING:
         OVAL       false
         VAL        false
       4.ACTUAL_TEMPERATURE:
         OSVAL      20.6
         OVAL       20.600000
         SVAL       20.5
         VAL        20.500000
       4.BATTERY_STATE:
         OSVAL      2.7
         OVAL       2.700000
         SVAL       2.7
         VAL        2.700000
       4.BOOST_STATE:
         OVAL       0
         VAL        0
       4.CONTROL_MODE:
         OSVAL      AUTO
         OVAL       0
         SVAL       AUTO
         VAL        0
       4.FAULT_REPORTING:
         OVAL       0
         VAL        0
       4.PARTY_START_DAY:
         OVAL       1
         VAL        1
       4.PARTY_START_MONTH:
         OVAL       1
         VAL        1
       4.PARTY_START_TIME:
         OVAL       0
         VAL        0
       4.PARTY_START_YEAR:
         OVAL       0
         VAL        0
       4.PARTY_STOP_DAY:
         OVAL       1
         VAL        1
       4.PARTY_STOP_MONTH:
         OVAL       1
         VAL        1
       4.PARTY_STOP_TIME:
         OVAL       0
         VAL        0
       4.PARTY_STOP_YEAR:
         OVAL       0
         VAL        0
       4.PARTY_TEMPERATURE:
         OSVAL      5.0
         OVAL       5.000000
         SVAL       5.0
         VAL        5.000000
       4.SET_TEMPERATURE:
         OSVAL      20.0
         OVAL       20.000000
         SVAL       20.0
         VAL        20.000000
       4.VALVE_STATE:
         OSVAL      23
         OVAL       23
         SVAL       23
         VAL        23
Attributes:
   IODev      d_ccu
   ccureadingfilter (TEMPERATURE|VALVE_STATE|CONTROL|BATTERY_STATE)
   cmdIcon    Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
   controldatapoint 4.SET_TEMPERATURE
   eventMap   /datapoint 4.MANU_MODE 20.0:Manu/datapoint 4.AUTO_MODE 1:Auto/datapoint 4.BOOST_MODE 1:Boost/datapoint 4.MANU_MODE 4.5:off/datapoint 4.MANU_MODE 30.5:on/
   hmstatevals FAULT_REPORTING!1:valve_tight,2:range_too_large,3:range_too_small,4:communication_error,5:other_error,6:battery_low,7:valve_error_pos
   room       Homematic
   statedatapoint 4.SET_TEMPERATURE
   stripnumber 1
   substexcl  control
   substitute CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;SET_TEMPERATURE!#0-4.5:off,#30.5-40:on;FAULT_REPORTING!0:no,1:valve_tight,2:range_too_large,3:range_too_small,4:communication_error,5:other_error,6:battery_low,7:valve:error_pos
   verbose    1
   webCmd     control:Auto:Manu:Boost:on:off
   widgetOverride control:slider,4.5,0.5,30.5,1


defmod k_Thermostat HMCCUDEV NEQ0416601
attr k_Thermostat IODev d_ccu
attr k_Thermostat ccureadingfilter (TEMPERATURE|VALVE_STATE|CONTROL|BATTERY_STATE)
attr k_Thermostat cmdIcon Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
attr k_Thermostat controldatapoint 4.SET_TEMPERATURE
attr k_Thermostat eventMap /datapoint 4.MANU_MODE 20.0:Manu/datapoint 4.AUTO_MODE 1:Auto/datapoint 4.BOOST_MODE 1:Boost/datapoint 4.MANU_MODE 4.5:off/datapoint 4.MANU_MODE 30.5:on/
attr k_Thermostat hmstatevals FAULT_REPORTING!1:valve_tight,2:range_too_large,3:range_too_small,4:communication_error,5:other_error,6:battery_low,7:valve_error_pos
attr k_Thermostat room Homematic
attr k_Thermostat statedatapoint 4.SET_TEMPERATURE
attr k_Thermostat stripnumber 1
attr k_Thermostat substexcl control
attr k_Thermostat substitute CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;;SET_TEMPERATURE!#0-4.5:off,#30.5-40:on;;FAULT_REPORTING!0:no,1:valve_tight,2:range_too_large,3:range_too_small,4:communication_error,5:other_error,6:battery_low,7:valve:error_pos
attr k_Thermostat verbose 1
attr k_Thermostat webCmd control:Auto:Manu:Boost:on:off
attr k_Thermostat widgetOverride control:slider,4.5,0.5,30.5,1

setstate k_Thermostat 20.0
setstate k_Thermostat 2018-04-29 10:10:40 4.ACTUAL_TEMPERATURE 20.5
setstate k_Thermostat 2018-04-29 10:10:40 4.BATTERY_STATE 2.7
setstate k_Thermostat 2018-04-29 10:10:40 4.CONTROL_MODE AUTO
setstate k_Thermostat 2018-04-29 10:10:40 4.PARTY_TEMPERATURE 5.0
setstate k_Thermostat 2018-04-29 10:10:40 4.SET_TEMPERATURE 20.0
setstate k_Thermostat 2018-04-29 10:10:40 4.VALVE_STATE 23
setstate k_Thermostat 2018-04-29 10:10:40 control 20.0
setstate k_Thermostat 2018-04-29 10:10:40 hmstate 20.0
setstate k_Thermostat 2018-04-29 10:10:40 state 20.0
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 29 April 2018, 11:50:10
Ok, Hue dürfte nicht so schwer sein das einzubauen, wird aber dauern. Plane aktuell das ganze in ein Modul zu gießen. Jedoch habe ich a sehr wenig Zeit und b muss ich mich viel einlesen. Daher wird das vermutlich erst kommen, wenn das Modul fertig ist.

Was mich wundert ist das Homematic Thermostat. Ist das ein normale HM-CC-RT-DN?? Das Reading sieht ganz anders aus als sonst. Weiterhin die Frage mit der 4 im Reading, ist das immer so? 4.BATTERY_STATE 2.7??
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: fini am 29 April 2018, 12:51:51
Zitat von: Amenophis86 am 29 April 2018, 11:50:10
Was mich wundert ist das Homematic Thermostat. Ist das ein normale HM-CC-RT-DN?? Das Reading sieht ganz anders aus als sonst. Weiterhin die Frage mit der 4 im Reading, ist das immer so? 4.BATTERY_STATE 2.7??

ist ein normaler HM-CC-RT-DN
beim wandthermostat HM-TC-IT-WM-W-EU ist es auch so.

Internals:
   DEF        MEQ1842790
   IODev      d_ccu
   NAME       w_Wandthermostat
   NR         32
   STATE      20.0
   TYPE       HMCCUDEV
   ccuaddr    MEQ1842790
   ccudevstate active
   ccuif      BidCos-RF
   ccuname    Wandthermostat
   ccutype    HM-TC-IT-WM-W-EU
   channels   6
   firmware   1.3
   statevals  devstate
   READINGS:
     2018-04-29 12:41:11   1.HUMIDITY      52
     2018-04-29 12:41:11   1.TEMPERATURE   20.0
     2018-04-29 12:14:20   2.BATTERY_STATE 2.7
     2018-04-29 12:43:41   2.SET_TEMPERATURE 20.0
     2018-04-29 12:14:20   2.WINDOW_OPEN_REPORTING closed
     2018-04-29 12:43:41   control         20.0
     2018-04-29 12:43:41   hmstate         20.0
     2018-04-29 12:43:41   state           20.0
   hmccu:
     dp:
       0.AES_KEY:
         OVAL       0
         VAL        0
       0.CONFIG_PENDING:
         OVAL       false
         VAL        false
       0.DEVICE_IN_BOOTLOADER:
         OVAL       false
         VAL        false
       0.INHIBIT:
         OVAL       false
         VAL        false
       0.LOWBAT:
         OVAL       false
         VAL        false
       0.RSSI_DEVICE:
         OVAL       1
         VAL        1
       0.RSSI_PEER:
         OVAL       202
         VAL        202
       0.STICKY_UNREACH:
         OVAL       false
         VAL        false
       0.UNREACH:
         OVAL       false
         VAL        false
       0.UPDATE_PENDING:
         OVAL       false
         VAL        false
       1.HUMIDITY:
         OSVAL      52
         OVAL       52
         SVAL       52
         VAL        52
       1.TEMPERATURE:
         OSVAL      20.0
         OVAL       20.000000
         SVAL       20.0
         VAL        20.000000
       2.ACTUAL_HUMIDITY:
         OVAL       52.000000
         VAL        51.000000
       2.ACTUAL_TEMPERATURE:
         OVAL       20.000000
         VAL        20.000000
       2.BATTERY_STATE:
         OSVAL      2.7
         OVAL       2.700000
         SVAL       2.7
         VAL        2.700000
       2.BOOST_STATE:
         OVAL       0
         VAL        0
       2.COMMUNICATION_REPORTING:
         OVAL       0
         VAL        0
       2.CONTROL_MODE:
         OVAL       0
         VAL        0
       2.LOWBAT_REPORTING:
         OVAL       0
         VAL        0
       2.PARTY_START_DAY:
         OVAL       1
         VAL        1
       2.PARTY_START_MONTH:
         OVAL       1
         VAL        1
       2.PARTY_START_TIME:
         OVAL       0
         VAL        0
       2.PARTY_START_YEAR:
         OVAL       0
         VAL        0
       2.PARTY_STOP_DAY:
         OVAL       1
         VAL        1
       2.PARTY_STOP_MONTH:
         OVAL       1
         VAL        1
       2.PARTY_STOP_TIME:
         OVAL       0
         VAL        0
       2.PARTY_STOP_YEAR:
         OVAL       0
         VAL        0
       2.PARTY_TEMPERATURE:
         OVAL       5.000000
         VAL        5.000000
       2.SET_TEMPERATURE:
         OSVAL      20.0
         OVAL       20.000000
         SVAL       20.0
         VAL        20.000000
       2.WINDOW_OPEN_REPORTING:
         OSVAL      closed
         OVAL       0
         SVAL       closed
         VAL        0
       7.DECISION_VALUE:
         OVAL       0
         VAL        0
Attributes:
   IODev      d_ccu
   ccureadingfilter (^HUMIDITY|^TEMPERATURE|^SET_TEMPERATURE|^WINDOW_OPEN|BATTERY_STATE)
   cmdIcon    Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
   controldatapoint 2.SET_TEMPERATURE
   eventMap   /datapoint 2.MANU_MODE 20.0:Manu/datapoint 2.AUTO_MODE 1:Auto/datapoint 2.BOOST_MODE 1:Boost/datapoint 2.MANU_MODE 4.5:off/datapoint 2.MANU_MODE 30.5:on/
   room       Homematic
   statedatapoint 2.SET_TEMPERATURE
   stripnumber 1
   substexcl  control
   substitute CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;WINDOW_OPEN_REPORTING!(true|1):open,(false|0):closed;SET_TEMPERATURE!#0-3.5:off,#30.5-40:on
   verbose    1
   webCmd     control:Auto:Manu:Boost:on:off
   widgetOverride control:slider,4.5,0.5,30.5,1
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 29 April 2018, 13:17:44
Da steht aber jetzt zum Beispiel eine 2 im Reading vorne an. Vielleicht weiß jemand anders warum die Readings so anders aussehen, als sonst?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: fini am 29 April 2018, 15:17:17
Zitat von: Amenophis86 am 29 April 2018, 13:17:44
Da steht aber jetzt zum Beispiel eine 2 im Reading vorne an. Vielleicht weiß jemand anders warum die Readings so anders aussehen, als sonst?

hab mal in der ccu nachgeschaut, die zahl ist der kanal

bei HM-CC-RT-DN kanal 4
Heizungsthermostat Empfänger

bei HM-TC-IT-WM-W-EU kanal 2
Heizungsthermostat

vielleicht kannstdu dich mit zap von HMCCU auseinandersetzen bei fragen.
der sollte sich ja sehr gut auskennen denke ich.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 29 April 2018, 16:27:55
Ah ich sehe es du hast ein anderes IO-Device und scheinbar werden dann die Kanäle anders ausgelesen. Da verstehe ich jetzt nicht, wieso man die Readings nicht gleich benannt hat, aber ok. Müssen arbeiten mit dem was wir haben. Dann werde ich wohl noch diese Sonderlocken einbauen. Wird aber wie gesagt dauern, sry.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: thunder1902 am 30 April 2018, 13:40:06
Hallo!

Colles Modul! :-)

Was muss man am Code ändern, damit man nicht den Gerätenamen, sondern den Alias-Namen angezeigt bekommt? :-)

Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 30 April 2018, 18:12:15
Zitat von: thunder1902 am 30 April 2018, 13:40:06
Was muss man am Code ändern, damit man nicht den Gerätenamen, sondern den Alias-Namen angezeigt bekommt? :-)

Füge in Zeile 34 folgendes ein:
my $Alias = AttrVal($Device, "alias", "Kein Alias");

Ersetze jetzt in den Variablen $text_... $Device mit $Alias

So bekommst du wenigstens als Nachricht den Alias. Damit es in den Dummys auch steht ist es umfangreicher. Da musst du vermutlich immer, wenn du die Funktion readingsSingleUpdate irgendwo siehst $Device mit $Alias tauschen.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 04 Mai 2018, 22:14:50
Hat jemand Xiaomi Geräte mit battery oder batterLevel Readings und kann mal eine Raw Definition davon posten zum Testen? Danke.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 04 Mai 2018, 23:41:37
Zitat von: Amenophis86 am 04 Mai 2018, 22:14:50
Hat jemand Xiaomi Geräte mit battery oder batterLevel Readings und kann mal eine Raw Definition davon posten zum Testen? Danke.

Jep ;)
Und jep ;)


defmod XiaomiHumTemp_Buero XiaomiSmartHome_Device 158d0001c2c887 sensor_ht XiaomiGateway
attr XiaomiHumTemp_Buero IODev XiaomiGateway
attr XiaomiHumTemp_Buero room MiSmartHome
attr XiaomiHumTemp_Buero stateFormat temperature °C, humidity %

setstate XiaomiHumTemp_Buero 23.3 °C, 51.87 %
setstate XiaomiHumTemp_Buero 2018-05-04 23:12:37 battery ok
setstate XiaomiHumTemp_Buero 2018-05-04 23:12:37 battery_level 3
setstate XiaomiHumTemp_Buero 2018-05-04 23:12:37 dewpoint 12.8
setstate XiaomiHumTemp_Buero 2018-05-04 23:12:37 heartbeat 158d0001c2c887
setstate XiaomiHumTemp_Buero 2018-05-04 23:12:37 humidity 51.87
setstate XiaomiHumTemp_Buero 2018-05-04 23:12:37 temperature 23.3


Das sind die "kleinen" runden Humidity/Temp-Sensoren: https://de.gearbest.com/living-appliances/pp_344665.html

Mache allerdings (noch) nicht wirklich viel/was damit, sind aktuell noch im Testsystem "verbaut"...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 05 Mai 2018, 09:23:23
Dank dir schon mal. Zwei Sachen dazu, ist dir bekannt, wie die Dinger ihr battery_level Reading ändern. Also was für Schritte es da gibt?

Und dann bitte mal prüfen, ob noch jemand welche hat, wo das battery_level Reading wiederum anders ist. Also zB mit % drin oder in Schritten von 1-100. Danke
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 05 Mai 2018, 10:40:11
Bitte gerne!
Zu Veränderungen/Schritten kann ich (noch) nichts sagen: gab noch keine...

Ich behalte es im Auge und geb Bescheid...
...evtl. lege ich bei Gelegenheit auch mal ne "abgenutzte" Batterie ein...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wolle02 am 13 Mai 2018, 08:54:54
Hallo zusammen,

ich finde diese Batterieüberwachung sehr spannend und würde das bei mir auch gerne einbauen. Ein paar Posts weiter vorne habe ich gelesen, dass es sich um "noch" kein Modul handelt. Das ist soweit klar. Habt ihr einen Fahrplan bis wann ihr daraus ein Modul entwickeln wollt?
Bitte nicht misverstehen: Ich möchte nicht drängeln oder so was, sondern nur für mich herausfinden, ob ich den "Codeschnipsel" einbauen soll oder lieber noch etwas warte, weil ihr sowieso kurz vor einer Modulerstellung steht.

Gruß
Wolle
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 13 Mai 2018, 10:31:18
Kein Problem. Aktuell ist die Modulentwicklung gestoppt. Ich habe festgestellt, das es unglaublich viele Sonderlocken gibt und eine Diskussion im Entwicklerbereich angestoßen: https://forum.fhem.de/index.php/topic,87575.0.html Solange hier keine Einigung entsteht entwickle ich vorerst nicht weiter bzw. warte erst Mal was raus kommt.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Peter aus Calw am 26 Juni 2018, 23:52:29
Hallo  Amenophis86,
habe nun komplett die ganzen Seiten gelesen und auch mal installiert, es werden auch alle meine HM-Geräte angezeigt, was ich nicht gefunden habe, wie sendet man mit dem Modul eine Email mit:

{ DebianMail('xx.yyy@t-online.de', 'Batteriewarnung', $NAME.': '.$EVENT)}

Wo kann ich das eintragen ?
Bin schon etwas älter und würde mich über Hilfe freuen.
LG Peter
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 27 Juni 2018, 18:32:37
Schwierig, aktuell wird das senden aus dem Teil Zeile 62 - 73 und dem Text zusammengesetzt. Da müsstest du ansetzen. Bin aktuell im Urlaub und generell dabei alles umzubauen. Die Entscheidung für gleiche Readings wurde ja getroffen. Dauert aber noch.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Peter aus Calw am 27 Juni 2018, 20:06:33
Ok, dann gedulde ich mich bis zu einer Lösung und wünsche einen schönen und erholsamen Urlaub.
LG Peter
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: my-engel am 27 Juli 2018, 18:22:32
Hallo,
tolle Sache und bis jetzt funktioniert alles soweit.
Du hast geschrieben:

BaZi_Heizkreis, 'battery: ok' ignored, has batteryLevel reading
Das ist bei Log3 normal so und wurde neu eingebaut. Würde, wenn dann alles klappt, auf Log2 wechseln.

Jetzt die Blöde Frage von mir, wo genau stelle ich das ein? (Zeilennummer)
Kann das jetzt irgendwie nicht finden

MfG
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 28 Juli 2018, 11:31:36
Welchen Zweig hast du genommen?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: my-engel am 28 Juli 2018, 11:35:44
Hallo,

wie im ersten Post empfohlen den letzten no-BatteryStatusBot-Zweig

LG
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 28 Juli 2018, 11:38:03
Dann müsstest du in Zeile 33 das Loglevel ändern können.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: my-engel am 28 Juli 2018, 11:51:41
Hallo Amenophis86,

Danke dir, jetzt sehe ich es auch und es funktioniert...
Könntest Du kurz auflisten was die einzelnen LogLevel so tun?
Ich hoffe es ist jetzt nicht zuviel verlangt...

LG
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 28 Juli 2018, 11:58:21
Da musste um Code schauen. Einfach nach Log3 suchen und dann schauen, welches Level eingestellt ist.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: tomspatz am 23 August 2018, 17:02:54
coole Sache ich bin hier auch dabei.
Habe NUR Z-Wave devices hier, wenn etwas gebraucht wird bitte melden.

Frage gleich zu der Benachrichtigung:
Ich nutze den Systemweiten msg dieser greift ja sofort den User. Wäre das dann so OK??

################################
# Here you choos your message device and how to send
# comment the device you do not want to use
#
# TelegramBot
# my $msg = "set TelegramBot message \@\@User ";
#
# msg-command
# my $msg = "msg \@User title='Battery Check' ";
#
# Pushover
my $msg = "msg device=\@rr_Tom title='Battery Check' ";


LG

Tom
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 24 August 2018, 08:18:50
Bei msg musst du das Device doch eigentlich nicht angeben, oder? Du hast den Teil von Pushover genommen. Schau mal darüber wäre der msg Teil:
# msg-command
# my $msg = "msg \@User title='Battery Check' ";

Das brauchst du und musst du anpassen.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: tomspatz am 26 August 2018, 15:56:30
SORRY  :-[

voll die Tomaten auf den Augen, dabei versuche ich mich wirklich in den Code reinzudenken.

LG
Tom
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Benny33 am 21 Oktober 2018, 08:05:44
Moin zusammen,

jetzt habe ich den Batteriestatus auch mal installiert.
Im Logfile taucht aber zu oft der Batteriestatus auf.
Habe schon versucht mit verbose 2 dies zu minimieren.
Wie kann ich das minimieren?

2018.10.21 07:59:21 3: HKT_Buegelzimmer, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 07:59:49 3: HKT_WC, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 07:59:53 3: HKT_Schlafzimmer, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 07:59:57 3: HKT_Pia, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:00:01 3: HKT_am_Ofen, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:00:10 3: HKT_Tuer, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:00:27 3: HKT_Bad, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:01:25 3: HKT_am_Computer, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:01:40 3: HKT_Buegelzimmer, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:02:03 3: HKT_Schlafzimmer, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:02:04 3: HKT_WC, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:02:18 3: HKT_am_Ofen, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:02:18 3: HKT_Tuer, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:02:35 3: FK_Terassentuer, Batt ok
2018.10.21 08:02:50 3: HKT_Bad, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:02:58 3: HKT_Pia, 'battery: ok' ignored, has batteryLevel reading
2018.10.21 08:03:28 3: Rauchm_Flur, Batt ok
2018.10.21 08:03:45 3: HKT_Buegelzimmer, 'battery: ok' ignored, has batteryLevel reading


Danke benny
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 21 Oktober 2018, 09:24:29
Wo genau hast du es auf lvl 2 gesetzt bzw welche Version nutzt du?
Hoffe, dass ich jetzt im Winter wieder etwas dazu komme.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Benny33 am 21 Oktober 2018, 19:57:51
Da nichts funktionierte habe ich es mittlerweile in Batteriestatusbot, Batteriewechsel NO.BatterieNotify rgBatteriestatus.
Die Version ist vom 31.03.18.

Benny
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 22 Oktober 2018, 13:10:22
Das heißt du setzt es per Attr? Das ist falsch, du musst es im Script setzen. Ein paar Beiträge vorher hatten wir das schon. Mal.

Weiterhin war die Frage der Version nicht von wann sie ist, sondern welche. Es gibt aktuell zwei verschiedene Zweige der Entwicklung :)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Benny33 am 22 Oktober 2018, 15:05:26
Ja hatte ich über attr gemacht.
Jetzt habe ich es gerade im script von my $Loglevel = 4 nach my $Loglevel = 2 geändert, mal sehen was passiert.
Die Version ist nicht die Master sondern no-BatterieStatusBot. bzw. 99_BatteryCheckUtils.pm

Benny
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 22 Oktober 2018, 19:17:32
Dann müsste es jetzt klappen, wenn nicht melden :)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Migul47 am 25 Oktober 2018, 14:43:31
Hallo,

klappt super. Hat jemand schon die Readings von Netatmo eingebaut?

Danke
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 29 Oktober 2018, 22:05:06
Bisher noch nicht.

Ich habe mich heute auch mal wieder mit dem Modul beschäftigt. Das Hauptproblem ist das erkennen, wie lange/oft ein low gesendet wird, bis der kritische Status erreicht wurde. Das habe ich nun mehrfach getestet. Leider ist das Ergebnis nicht gut. Soll heißen es kommt einfach zu sehr auf die Batterien und das Gerät an. Bei manchen Batterietypen dauert es so lange, dann ist es von Gerät zu Gerät wieder verschieden. Selbst bei HM Geräten ist es teilweise nicht gleich...
Daher werde ich das Modul leider nochmal über den Haufen werfen und von vorne beginnen mit einer neuen Idee, wie es arbeiten sollte. Da bin ich gerade in der Überlegung und melde mich wieder, wenn es etwas Neues gibt. Das kann jedoch dauern, da ich immer nur selten und kurz dran arbeiten kann. Bis dahin werde ich auch keine Änderungen mehr vornehmen an den aktuellen Versionen.


Meine aktuelle Idee sieht wie folgt aus. Keine Probleme machen Geräte, welche einen genauen Wert übertragen. Allerdings macht alles mit reinem ok/low Probleme. Für diese Geräte werde ich vielleicht eine Art ActionDector einbauen, der nach dem ersten Mal low startet. Der soll regelmäßig prüfen, ob sich ein bestimmtes Reading geändert hat. Sollte das nach einer gewissen Zeit nicht mehr der Fall sein, dann meldet das Modul kritisch. Vielleicht klappt das ja besser.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 29 Oktober 2018, 22:23:23
Ich bin bei den optischen Fenstersensoren drüber gestolpert und hatte eingebaut auf "dead" zu warten/kucken...
...hat sich aber bei der Zeitumstellung als "doof" erwiesen...
Weil da irgendwie der ActionDetector ein wenig naja ;)

Neueste Idee: ReadingsAge von powerOn < 2 Tage (oder auch noch neuer).

D.h. wenn von low - nach ok habe ich aktuell eingebaut ReadingsAge abzufragen...
Sollte ja immer noch das alte powerOn sein, außer es wurde tatsächlich gewechselt...
Weil gerade die optischen HM Sensoren öfter mal zwischen low - ok - low - ok usw. wechseln...
Mal sehen wie sich das tut...

Dumm, dass das halt nur bei Geräten mit diesem powerOn Reading tut.

Aber für die (zumindest bei mir) problematischen optischen HM-Sensoren sollte das helfen.

Bei den magnetischen hatte ich noch keine Probleme.
Da kommt low bleibt (zumindest bei mir bislang) low (zugegebenermassen ziemlich lange ;)  ) und dann dead...

Bei denen wo ich die Prozente berechne klappt alles und auch bei ZWave etc. die schon gleich Prozent melden...

Für Geräte ohne das powerOn hab ich auch noch keine rechte Lösung...

EDIT: ups noch mal gelesen. Ganz andere Baustelle/Problem das du beschreibst ;)  Ich mache es bei mir aktuell so, dass ich bei low eine Nachricht schicke "demnächst Batterien wechseln" (schon mal nach Batterien schauen/besorgen) und dann bei HM auf "dead" warte. Bei ZWave prüfe ich einmal am Tag ob das wakeup gekommen ist, das Intervall kann man abfragen (zumindest bei denen die ich habe) und dann einen ähnlichen Mechanismus wie ActionDetector habe... Wobei eigentlich bei allen Geräten die Prozente anzeigen keine großen Probleme da sind (bei mir), einzig die jeweilige Schwelle, also wann "bald wechseln" und "jetzt isses aber soweit weil tot" ist halt etwas "Einstellungssache"... Hmmm, das passt wohl besser hierher ;)

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: gloob am 12 November 2018, 11:35:04
Hallo,

Ich habe meine Xiaomi Sensoren über eine Hue Bridge eingebunden:

defmod XiaomiSensor2_1 HUEDevice sensor 5  IODev=deCONZ
attr XiaomiSensor2_1 IODev deCONZ
attr XiaomiSensor2_1 room Zigbee
attr XiaomiSensor2_1 stateFormat {sprintf("Temperatur: %.1f Grad / Feuchte: %.1f Prozent / Luftdruck: %.1f hPa / Batterie: %d %%",ReadingsVal($name,"temperature",0),ReadingsVal($name,"humidity",0),ReadingsVal($name,"pressure",0),ReadingsVal($name,"battery",0))}
attr XiaomiSensor2_1 userReadings humidity {ReadingsVal("XiaomiSensor2_2","humidity","");;},\
pressure {ReadingsVal("XiaomiSensor2_3","pressure","");;}

setstate XiaomiSensor2_1 2018-11-12 10:53:41 .lastupdated 2018-11-12 10:53:41
setstate XiaomiSensor2_1 2018-11-12 10:53:41 battery 95
setstate XiaomiSensor2_1 2018-11-12 10:53:41 humidity 53.24
setstate XiaomiSensor2_1 2018-11-12 10:53:41 pressure 1002
setstate XiaomiSensor2_1 2018-11-12 10:53:41 reachable 1
setstate XiaomiSensor2_1 2018-11-12 10:53:41 temperature 22.75


Gibt es eine Möglichkeit die Senoren auch mit in die Batterieüberwachung aufzunehmen? Leider gibt es ein battery reading welches direkt als Prozent Werte gesetzt wird.

Man läuft somit immer in den Zweig:


##############################################
# All other Devices with batteryLevel
##############################################
.
.
.
if($Loglevel >=1) {Log3(undef, 1,"$Device, unknown Event $Event");}
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 12 November 2018, 19:25:08
Ja, die Möglichkeit gibt es. Aktuell komme ich aber aus Zeitmangel nicht dazu es einzubauen. Das heißt entweder forken oder mir einen Patch erstellen. Sorry
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Green Hornet am 19 Februar 2019, 22:15:51
Zitat von: gloob am 12 November 2018, 11:35:04
Hallo,

Ich habe meine Xiaomi Sensoren über eine Hue Bridge eingebunden:

defmod XiaomiSensor2_1 HUEDevice sensor 5  IODev=deCONZ
attr XiaomiSensor2_1 IODev deCONZ
attr XiaomiSensor2_1 room Zigbee
attr XiaomiSensor2_1 stateFormat {sprintf("Temperatur: %.1f Grad / Feuchte: %.1f Prozent / Luftdruck: %.1f hPa / Batterie: %d %%",ReadingsVal($name,"temperature",0),ReadingsVal($name,"humidity",0),ReadingsVal($name,"pressure",0),ReadingsVal($name,"battery",0))}
attr XiaomiSensor2_1 userReadings humidity {ReadingsVal("XiaomiSensor2_2","humidity","");;},\
pressure {ReadingsVal("XiaomiSensor2_3","pressure","");;}

setstate XiaomiSensor2_1 2018-11-12 10:53:41 .lastupdated 2018-11-12 10:53:41
setstate XiaomiSensor2_1 2018-11-12 10:53:41 battery 95
setstate XiaomiSensor2_1 2018-11-12 10:53:41 humidity 53.24
setstate XiaomiSensor2_1 2018-11-12 10:53:41 pressure 1002
setstate XiaomiSensor2_1 2018-11-12 10:53:41 reachable 1
setstate XiaomiSensor2_1 2018-11-12 10:53:41 temperature 22.75


Gibt es eine Möglichkeit die Senoren auch mit in die Batterieüberwachung aufzunehmen? Leider gibt es ein battery reading welches direkt als Prozent Werte gesetzt wird.

Man läuft somit immer in den Zweig:


##############################################
# All other Devices with batteryLevel
##############################################
.
.
.
if($Loglevel >=1) {Log3(undef, 1,"$Device, unknown Event $Event");}


Hallo,

gibt es bezüglich Batterieüberwachung der Xiaomi Devices über HUE Bridge schon etwas neues?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 20 Februar 2019, 20:01:49
Sry, von meiner Seite liegt das Projekt aktuell auf Eis. Hat verschiedene Gründe. Manche Module haben noch nicht auf die neuen Readings umgestellt und ich wollte nicht für jede Sonderlocke etwas programmieren und dazu bin ich beruflich aktuell ziemlich eingespannt. Muss mal sehen wann ich das Projekt weiter voran treibe. Du kannst aber mal ein List deines Device hier posten vielleicht kann ich dir sagen was du am Code ändern musst, dass es geht.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Green Hornet am 20 Februar 2019, 20:39:04
Trotzdem Danke das du es dir evtl. mal anschaust.  :)
Batterie Reading wird in Prozent angegeben.

Internals:
   CFGFN     
   DEF        sensor 9  IODev=Raspbee_1
   FUUID      5c6800b9-f33f-9f3a-e63d-b58a53a621998bcf
   ID         S9
   INTERVAL   
   IODev      Raspbee_1
   NAME       GA.Bm_Motion
   NR         735
   STATE      nomotion
   TYPE       HUEDevice
   lastupdated 2019-02-20 18:56:44
   lastupdated_local 2019-02-20 19:56:44
   manufacturername LUMI
   modelid    lumi.sensor_motion.aq2
   name       Bewegungsmelder Garage
   on         1
   reachable  1
   swversion  20170627
   type       ZHAPresence
   uniqueid   00:15:8d:00:02:cb:47:43-01-0406
   Helper:
     DBLOG:
       state:
         DBLogging:
           TIME       1550689004.86648
           VALUE      nomotion
   READINGS:
     2019-02-20 19:56:44   battery         95
     2019-02-20 19:56:44   reachable       true
     2019-02-20 19:56:44   state           nomotion
   helper:
     devtype    S
     reachable  0
     update_timeout 1
     setList:
Attributes:
   IODev      Raspbee_1
   alias      Bewegungsmelder Garage
   group      Bewegungsmelder
   icon       motion_detector@blue
   room       Garage
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Papaloewe am 20 Februar 2019, 21:38:26
Ich glaube für den
TYPE       HUEDevice
gibt es noch keine Subroutine, richtig?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Papaloewe am 20 Februar 2019, 21:57:36
Mit ein bischen Copy & Paste habe ich diese Subroutine einfach mal reinkopiert:
  ##############################################
   # HUEDevice Devices with batteryLevel
   ##############################################
   elsif($TYPE =~ "HUEDevice" and $BatteryType[0] eq "battery")
   {
    $ActBatLevel = ReadingsNum($Device, "battery", "0");

if(ReadingsNum($BatteryStatus, $Device, undef) eq "undef") # set battery level 100% and show in BatteryStatus-Device if new
{
  readingsSingleUpdate($defs{$BatteryStatus},$Device, 100,0);
  if($Loglevel >=1) {Log3(undef, 1, "$Device, added to $BatteryStatus");}
  return;
}

if($ActBatLevel > 75)
   {
# set date/time for changed battery if it was low before (so probably a change happended)
if(ReadingsNum($BatteryStatus, $Device, 100) <= 25)
  {
readingsSingleUpdate($defs{$BatteryChanged}, $Device, $text_changed, 0);
  }

  # set the battery value to 75% - 100%
  readingsSingleUpdate($defs{$BatteryStatus}, $Device, 100, 0);
 
  return undef;
}
elsif($ActBatLevel > 50)
{
  # between 50% and 75%
  readingsSingleUpdate($defs{$BatteryStatus}, $Device, 75, 0);
 
  return undef;
}
elsif($ActBatLevel > 25)
{
  # between 25% and 50%
  readingsSingleUpdate($defs{$BatteryStatus}, $Device, 50, 0);
 
  return undef;
}
elsif($ActBatLevel > 5)
{
  if(ReadingsNum($BatteryStatus, $Device, 0) != 25) # check befor action if already has the status
    {
  # between 5% and 25%
  readingsSingleUpdate($defs{$BatteryStatus}, $Device, 25, 0);
 
  fhem($msg." ".$text_soon);
  return undef;
}
 
  return undef;
}
else
{
  if(ReadingsNum($BatteryStatus, $Device, 0) != 0) # check befor action if already has the status
    {
  # totally empty (below 5%)
  readingsSingleUpdate($defs{$BatteryStatus}, $Device, 0, 0);
   
  fhem($msg." ".$text_now);
  return undef;
}
 
  return undef;
}
   }
   


Scheint z funktionieren. Sorry ich habe keine Ahnung vom Programmieren, oder wie ich jetzt ein Diff davon erstelle.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Green Hornet am 21 Februar 2019, 19:43:12
@Papaloewe, Danke für deinen Denkanstoß. Hab deinen Code in der ersten Zeile noch etwas angepasst und es wird mir im Batteriestatus jetzt schon mal angezeigt, ob die Leermeldung funktioniert kann ich noch nicht sagen. Kann man das irgendwie testen???

   ##############################################
   # HUEDevice Devices with batteryLevel
   ##############################################
   elsif($BatteryType[0] eq "battery"  && InternalVal($Device, "TYPE", "undef") eq "HUEDevice")
   {
    $ActBatLevel = ReadingsNum($Device, "battery", "0");

if(ReadingsNum($BatteryStatus, $Device, undef) eq "undef") # set battery level 100% and show in BatteryStatus-Device if new
{
  readingsSingleUpdate($defs{$BatteryStatus},$Device, 100,0);
  if($Loglevel >=1) {Log3(undef, 1, "$Device, added to $BatteryStatus");}
  return;
}

if($ActBatLevel > 75)
   {
# set date/time for changed battery if it was low before (so probably a change happended)
if(ReadingsNum($BatteryStatus, $Device, 100) <= 25)
  {
readingsSingleUpdate($defs{$BatteryChanged}, $Device, $text_changed, 0);
  }

  # set the battery value to 75% - 100%
  readingsSingleUpdate($defs{$BatteryStatus}, $Device, 100, 0);
 
  return undef;
}
elsif($ActBatLevel > 50)
{
  # between 50% and 75%
  readingsSingleUpdate($defs{$BatteryStatus}, $Device, 75, 0);
 
  return undef;
}
elsif($ActBatLevel > 25)
{
  # between 25% and 50%
  readingsSingleUpdate($defs{$BatteryStatus}, $Device, 50, 0);
 
  return undef;
}
elsif($ActBatLevel > 5)
{
  if(ReadingsNum($BatteryStatus, $Device, 0) != 25) # check befor action if already has the status
    {
  # between 5% and 25%
  readingsSingleUpdate($defs{$BatteryStatus}, $Device, 25, 0);
 
  fhem($msg." ".$text_soon);
  return undef;
}
 
  return undef;
}
else
{
  if(ReadingsNum($BatteryStatus, $Device, 0) != 0) # check befor action if already has the status
    {
  # totally empty (below 5%)
  readingsSingleUpdate($defs{$BatteryStatus}, $Device, 0, 0);
   
  fhem($msg." ".$text_now);
  return undef;
}
 
  return undef;
}
   }
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 21 Februar 2019, 20:22:34
Einfach mal per
setreading GA.Bm_Motion battery 4

Oder welcher Wert auch immer zu einer Meldung führen soll...

Bei der nächsten "echten" Meldung des battery Wertes vom Gerät wird dann wieder richtig gesetzt und dann verm. ein Batteriewechsel "gemeldet"... ;)

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Green Hornet am 21 Februar 2019, 20:33:47
Sehr cool, funktioniert Danke  ;D
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 23 Februar 2019, 09:07:25
Geht doch, freut mich, wenn andere mit machen :)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Peter aus Calw am 14 April 2019, 19:27:37
Hallo zusammen,
hier wurde mal das Reading vom HM-CC-RT-DN "powerOn" angesprochen. Bei mir habe ich 6 von den Geräten mit den SW-Versionen 1.1 und 1.4 eingesetzt und dabei festgestellt, daß 2 RT - einer mit 1.1 und einer mit 1.4 kein "powerOn" senden. Alle anderen Parameter sind identisch, gibt es dafür einen Tipp ?
Mit meinen restlichen Geräten (4 Fenstersenoren, Aussentemp-Sensor, 2 Wandthermostaten)
ermittle ich durch :

{((ReadingsAge("FS_Gwc","powerOn",1))- (TimeNow(),13,5))/24/3600}

die Anzahl der Tage seit dem Batteriewechsel und habe so auch einen recht guten Überblick.
Hoffe auf einen guten Rat.
LG Peter


Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: SimonHipp am 23 April 2019, 22:23:58
Kann es sein das aktuell der "no-BatteryStatusBot-Zweig" nicht verfügbar ist, wollte mit soeben den Code laden und einbauen.
Leider erscheint immer 404 als Fehler.

Grüße
Simon
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 24 April 2019, 11:05:52
Gerade nochmal geschaut, bei mir ist alles online und der Link aus dem 1.Post geht.

Aber nochmal zur Info, ich arbeite aktuell nicht weiter an dem Projekt.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Benny33 am 09 Mai 2019, 08:14:22
Hi zusammen,

könnte man in dem Code einstellen, dass bei den CUL_HM die Meldung "Die Batterien von $Device müssen JETZT gewechselt werden!" schon ab 2,4V kommt?
Demzufolge auch vorher schon "Die Batterien von $Device sollten bald gewechselt werden!"?
Ausserdem finde ich bei keinen meiner 8 Heizkörperthermostaten das reading R-lowBatLimitRT.

Internals:
   DEF        4CF1A0
   FUUID      5c481a9e-f33f-ad31-dc48-2c9bc357e407f7e1
   HMLAN1_MSGCNT 546
   HMLAN1_RAWMSG E4CF1A0,0000,130CD2F1,FF,FFC0,8A86104CF1A00000000AA0D60B1D00
   HMLAN1_RSSI -64
   HMLAN1_TIME 2019-05-09 08:09:47
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     546
   NAME       HKT_WC
   NOTIFYDEV  global
   NR         424
   NTFY_ORDER 50-HKT_WC
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HKT_WC_Weather
   channel_02 HKT_WC_Climate
   channel_03 HKT_WC_WindowRec
   channel_04 HKT_WC_Clima
   channel_05 HKT_WC_ClimaTeam
   channel_06 HKT_WC_remote
   lastMsg    No:8A - t:10 s:4CF1A0 d:000000 0AA0D60B1D00
   protLastRcv 2019-05-09 08:09:47
   protRcv    545 last_at:2019-05-09 08:09:47
   protSnd    1 last_at:2019-05-08 12:24:27
   protState  CMDs_done
   rssi_at_HMLAN1 cnt:546 min:-71 max:-63 avg:-65.84 lst:-64
   READINGS:
     2019-05-08 08:09:48   Activity        alive
     2019-05-07 10:55:44   CommandAccepted yes
     2018-08-01 06:45:46   D-firmware      1.4
     2018-08-01 06:45:46   D-serialNr      NEQ0876150
     2018-12-30 12:39:47   PairedTo        0x1E4ED6
     2018-08-01 08:13:25   R-backOnTime    10 s
     2018-08-01 08:13:25   R-burstRx       on
     2018-08-01 08:13:25   R-cyclicInfoMsg on
     2018-08-01 08:13:25   R-cyclicInfoMsgDis 0
     2018-08-01 08:13:25   R-pairCentral   0x1E4ED6
     2018-12-30 12:39:47   RegL_00.        00:00 01:01 02:01 09:01 0A:1E 0B:4E 0C:D6 0E:0A 0F:00 11:00 12:15 16:01 18:00 19:00 1A:00
     2018-12-30 23:59:55   RegL_07.       
     2019-05-09 08:09:47   actuator        29
     2019-05-09 08:09:47   battery         ok
     2019-05-09 08:09:47   batteryLevel    2.6
     2019-05-09 08:09:47   desired-temp    20.0
     2019-05-09 08:09:47   measured-temp   21.4
     2019-05-09 08:09:47   motorErr        ok
     2018-12-30 12:37:17   powerOn         2018-12-30 12:37:17
     2018-12-30 12:37:17   recentStateType info
     2019-05-08 12:24:27   state           CMDs_done
     2019-05-08 12:24:27   time-request    -
   helper:
     HM_CMDNR   138
     mId        0095
     peerFriend
     peerOpt    -:thermostat
     regLst     0
     rxType     140
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +4CF1A0,00,01,00
       nextSend   1557382187.86575
       prefIO     
       rxt        2
       vccu       vccu
       p:
         4CF1A0
         00
         01
         00
     mRssi:
       mNo        8A
       io:
         HMLAN1:
           -60
           -60
         nanoCUL868:
     prt:
       bErr       0
       sProc      0
       sleeping   1
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       at_HMLAN1:
         avg        -65.8461538461539
         cnt        546
         lst        -64
         max        -63
         min        -71
     shRegW:
       07         04
     tmpl:
Attributes:
   DbLogExclude .*
   IODev      HMLAN1
   IOgrp      vccu
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.4
   model      HM-CC-RT-DN
   room       WC,Hardware
   serialNr   NEQ0876150
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit


Könnte mir da mal bitte einer auf die Sprünge helfen.

Besten Dank
Benny
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 09 Mai 2019, 09:17:16
Also der Code holt sich den Wert aus dem Reading R-lowBatLimitRT, welches ich bei dir auch nicht sehe. Verändere mal das Attr Expert um zu schaue, ob es dann erscheint.

Wenn du den Wert selbst setzen willst, dann musst folgende Zeile ändern:

Zeile 218 von
$MinBatLevel = ReadingsNum($Device, "R-lowBatLimitRT", "0.0"); 
In
$MinBatLevel = 2.4

Habe es nicht getestet und eben nur schnell auf dem Handy getippt, müsste aber gehen.

Wieso willst du die Meldung schon so früh haben? "Jetzt" kommt doch erst vorm Tod und der ist bei der 2.1 Meldung bei mir erst nach mehreren Tagen. Somit genug Zeit eigentlich.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Benny33 am 09 Mai 2019, 12:29:57
Jau das war es habe jetzt expert auf 1_allReg gestellt, nun habe ich auch R-lowBatLimitRT.
Ich habe die Anzeige immer bekommen wenn das HKT nicht mehr funktionierte und das war zu spät.
Aber da auch das R-lowBatLimitRT nun habe werde ich den Code so nehmen wie Du ihn zur Verfügung gestellt hast ohne irgendeine Veränderung bis auf telegrambot.
Werde ich ja dann sehen ob es nun klappt.
Kann ich expert jetzt so stehen lassen? Denke schon.

Vielen Dank für die Info.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 09 Mai 2019, 13:04:22
Zitat von: Benny33 am 09 Mai 2019, 12:29:57
Kann ich expert jetzt so stehen lassen? Denke schon.

Ja.
Ist nur eine Einstellung wieviele/welche "Registerwerte" (als R-Readings) zu sehen sind.

Man muss ja nicht immer alle sehen...
...allerdings sehe ich gerne immer alles ;)

Meine erste "Tätigkeit" bei neuen HM-Geräten ist daher die Umstellung auf 1_allReg... ;)

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: kennymc.c am 01 Juni 2019, 17:51:54
Das Skript soll ja auch mit Xiaomi Geräten funktionieren, allerdings werden bei mir nur meine HomeMatic Geräte angezeigt. Die Xiaomis haben alle ein battery, battery_level und voltage Reading. Sie laufen über zigbee2mqtt und dem XiaomiMQTTDevice Modul Damit sollten sie doch eigentlich automatisch auftauchen oder?
Außerdem sind bei zwei meiner HM Devices Ausrufungszeichen in der Readingsgroup, obwohl im Batteriestatus Dummydevice die Werte aller Devices auf 100 stehen.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 02 Juni 2019, 09:30:33
Ein List der Geräte posten, welche nicht gehen oder Fehlerhaft sind. Sonst kann man nicht helfen :)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: kennymc.c am 02 Juni 2019, 14:11:23
Xiaomi Sensor

Internals:
   DEF        WSDCGQ01LM 0x00158d000215933c BK_Sensor
   FRIENDLYNAME BK_Sensor
   FUUID      5c5de5e9-f33f-ed56-1602-add78fd2ca5d81e4
   IODev      mqtt
   MODEL      WSDCGQ01LM
   NAME       BK_Sensor
   NOTIFYDEV  WSDCGQ01LM 0x00158d000215933c BK_Sensor
   NR         140
   SID        0x00158d000215933c
   STATE      Temperatur: 30.5 °C | Luftfeuchtigkeit: 38 %
   TYPE       XiaomiMQTTDevice
   Helper:
     DBLOG:
       humidity:
         DBLogging:
           TIME       1559476864.28189
           VALUE      38
       last_seen:
         DBLogging:
           TIME       1559476864.28189
           VALUE      1559476864181
       linkquality:
         DBLogging:
           TIME       1559476864.28189
           VALUE      81
       temperature:
         DBLogging:
           TIME       1559476864.21724
           VALUE      30.5
   READINGS:
     2019-06-02 14:01:04   battery         ok
     2019-06-02 14:01:04   battery_level   100
     2019-06-02 14:01:04   humidity        38
     2019-06-02 14:01:04   last_seen       1559476864181
     2019-06-02 14:01:04   linkquality     81
     2019-06-02 14:01:04   temperature     30.5
     2019-06-02 14:01:04   transmission-state incoming publish received
     2019-06-02 14:01:04   voltage         3025
   message_ids:
   subscribe:
     zigbee2mqtt/BK_Sensor
     xiaomi/0x00158d000215933c/#
   subscribeExpr:
     ^zigbee2mqtt\/BK_Sensor$
     ^xiaomi\/0x00158d000215933c.*$
   subscribeQos:
     xiaomi/0x00158d000215933c/# 0
     zigbee2mqtt/BK_Sensor 0
Attributes:
   DbLogExclude .*
   DbLogInclude humidity,temperature,linkquality,battery_level,last_seen
   IODev      mqtt
   alias      Klima Balkon
   event-on-change-reading humidity,temperature:0.2,linkquality,battery_level,last_seen
   group      KlimaXiaomi
   homebridgeMapping history:size=1024 StatusLowBattery=BK_Sensor:battery,values=ok:BATTERY_LEVEL_NORMAL;/^.*/:BATTERY_LEVEL_LOW batteryVoltage=BK_Sensor:voltage,factor=1000,name=Voltage,format=FLOAT history:size=1024
   mqttPublish temperature:topic={"EPSD/Temp/BK"} humidity:topic={"EPSD/Hum/BK"} temperature:retain=1 humidity:retain=1
   room       Balkon,Favoriten,Homebridge,ZigBee
   stateFormat Temperatur: temperature °C | Luftfeuchtigkeit: humidity %
   userattr   EPSDAlias:textField-long EPSDDefaults:textField-long EPSDDisable:both,incoming,outgoing EPSDPublish:textField-long EPSDSubscribe:textField-long mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttPublish:textField-long mqttSubscribe:textField-long


Einer der 2 HM Fenstersensor mit Ausrufungszeichen scheint jetzt den korrekten Batteriestatus zu zeigen. Bei einem anderen ist das Symbol aber noch vorhanden

Internals:
   DEF        2BD7F1
   FUUID      5c5de5ee-f33f-ed56-b73c-91731d343b5b22a6
   IODev      hmusb
   NAME       SZ_Fenster
   NOTIFYDEV  global
   NR         574
   NTFY_ORDER 50-SZ_Fenster
   STATE      closed
   TYPE       CUL_HM
   chanNo     01
   peerList   SZ_Thermostat_WindowRec,
   READINGS:
     2019-06-02 05:09:10   Activity        unknown
     2018-09-02 15:42:41   D-firmware      2.4
     2018-09-02 15:42:41   D-serialNr      LEQ0566785
     2019-05-30 12:55:37   battery         ok
     2019-05-30 12:55:37   contact         closed (to vccu)
     2019-06-02 05:09:12   peerList        SZ_Thermostat_WindowRec,
     2019-05-30 12:55:37   state           closed
     2019-05-30 12:55:37   trigger_cnt     24
   helper:
     HM_CMDNR   35
     mId        0030
     peerFriend peerAct,peerVirt
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     20
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +2BD7F1,00,00,00
       rxt        2
       vccu       vccu
       p:
         2BD7F1
         00
         00
         00
       prefIO:
         hmusb
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   00
       qReqStat   
     role:
       chn        1
       dev        1
     tmpl:
Attributes:
   DbLogExclude .*
   DbLogInclude state,battery,trigger_cnt
   IODev      hmusb
   IOgrp      vccu:hmusb
   actCycle   028:00
   actStatus  unknown
   alias      Fenster Schlafzimmer
   autoReadReg 5_readMissing
   devStateIcon closed:fts_window_1w@green open:fts_window_1w_open@red tilted:fts_window_1w_tilt@yellow
   expert     2_full
   firmware   2.4
   genericDeviceType ContactSensor
   group      HomematicFenstersensor
   homebridgeMapping StatusLowBattery=battery,values=ok:BATTERY_LEVEL_NORMAL;/^.*/:BATTERY_LEVEL_LOW history:size=1024 ContactSensorState=state,values=closed:CONTACT_DETECTED;open:CONTACT_NOT_DETECTED
   model      HM-SEC-RHS
   mqttPublish state:topic={"EPSD/Con/SZ"} state:retain=1
   peerIDs    00000000,2D30D803,
   room       Favoriten,HomeMatic,Homebridge,Schlafzimmer
   serialNr   LEQ0566785
   subType    threeStateSensor


Ich vermute, das battery Reading muss sich nach dem Start des Bots einmal aktualisieren, damit es richtig erkannt wird? Das würde erklären, warum über Nacht eins der Devices jetzt keinen Fehler mehr zeigt.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 02 Juni 2019, 14:37:54
Der Typ XiaomiMQTTDevice wird noch nicht unterstützt. Du müsstest dir einen Block mit batteryLevel suchen, kopieren und anpassen.

Zu HomeMatic, normal wird zu Beginn einmal alles abgefragt. Ein ! Kann es geben, wenn der ActionDetector das Gerät zB als tot meldet. Schwer zu sagen warum es bei dir so war.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: kennymc.c am 03 Juni 2019, 18:07:35
Ich hab das Skript entsprechend angepasst aber nach einem reload und einem erneutem {BatteryStart()} tauchen die Devices immer noch nicht auf. Ich hab auch schon versucht alle angelegten dummys und notifys zu löschen.


   ##############################################
  # XiaomiMQTT Devices
  #############################################
elsif($BatteryType[0] eq "battery_level"  && InternalVal($Device, "TYPE", "undef") eq "XiaomiMQTTDevice")
{
   $ActBatLevel = ReadingsNum($Device, "battery_level", "0");

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        fhem("setreading $BatteryChanged $Device $text_changed");
      }

      # set the battery value to 75% - 100%
      fhem("setreading $BatteryStatus $Device 100");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 50)
    {
      # between 50% and 75%
      fhem("setreading $BatteryStatus $Device 75");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 25)
    {
      # between 25% and 50%
      fhem("setreading $BatteryStatus $Device 50");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 5)
    {
      # between 5% and 25%
      fhem("setreading $BatteryStatus $Device 25");

      # maybe already send a message! Easy possible with new signal states
    }
    else
    {
      # totally empty (below 5%)
      fhem("setreading $BatteryStatus $Device 0");

      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }
    }
  }


Die HM Devices werden jetzt alle korrekt angezeigt. Vermutlich liegt es am ActionDetector, der bei mir irgendwie seltsame Werte anzeigt hat.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 03 Juni 2019, 18:25:36
Füge doch am Anfang mal eine Logausgabe ein, um zu sehen, ob der Zweig überhaupt "getroffen" wird:


   ##############################################
  # XiaomiMQTT Devices
  #############################################
elsif($BatteryType[0] eq "battery_level"  && InternalVal($Device, "TYPE", "undef") eq "XiaomiMQTTDevice")
{

  Log3(undef, 3, "Battery for XiaomiMQTTDevice");

   $ActBatLevel = ReadingsNum($Device, "battery_level", "0");

   if($ActBatLevel > 75)


Wenn die Ausgabe nicht kommt, ist was an dieser "Abfrage" schief oder eine zuvor macht etwas "kaputt"...

Wie sieht das split bzgl. BatteryType aus!?

EDIT: hab grad geschaut, das sollte passen...


Und evtl. mal (glaube aber nicht, dass es was macht) bei der ReadingsNum-Abfrage eine 0 statt einer "0", weil ReadingsNum immer eine Zahl liefert...
...aber ich denke Perl wandelt das eh passend um ;)

EDIT: bzw. mal ganz an den Anfang eine Logausgabe: Log3(undef, 3, "Battery-Function Device: $Device     Event: $Event");

Edit2: und es kommen nat. nur Werte bzw. werden "berechnet" und in den Dummy geschrieben, wenn auch Events mit battery_level kommen! Wie oft wird denn aktualisiert!? Wenn nicht, dann einfach mal zu Test: setreading BK_Sensor battery_level 99

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: kennymc.c am 03 Juni 2019, 21:12:59
Zitat von: MadMax-FHEM am 03 Juni 2019, 18:25:36Edit2: und es kommen nat. nur Werte bzw. werden "berechnet" und in den Dummy geschrieben, wenn auch Events mit battery_level kommen! Wie oft wird denn aktualisiert!? Wenn nicht, dann einfach mal zu Test: setreading BK_Sensor battery_level 99

Gruß, Joachim

Daran lag es wohl. Da die HM Devices ja direkt nach dem Einrichten ohne Event auftauchen, dachte ich, dass das bei den Xiaomi genauso ist. Da die Sensoren aber nur sehr selten ihren Status updaten, waren sie wohl nicht direkt mit in der ReadingsGroup. Ein manuelles ändern des Reading hat aber geholfen.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 03 Juni 2019, 21:32:32
Na dann... :)

Kann der Code ja übernommen werden ;)

Gruß und viel Spaß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 04 Juni 2019, 09:06:04
freut mich, dass es geht. Allerdings eine Frage dazu, welchen Branche hast du genutzt? no-BatteryStatusBot oder Master? Es sieht mir sehr nach Master aus, da die Variable BatteryStatusBot in deinem Code vorkommt. Ich würde dir empfehlen eher no-BatteryStatusBot zu nehmen. In diesem Fall hätten deine Geräte Xiaomi Geräte eigentlich auch erkannt werden müssen auf Grund des Zweiges für alle nicht direkt definierten Geräte, fällt mir aber eben erst ein. Weiterhin ist der Zweig auch wesentlich weiter entwickelt, als der Master Zweig.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: kennymc.c am 04 Juni 2019, 18:55:30
Ich hab den master Branch genutzt. Mit dem no-BatteryStatusBot geht es auch direkt ohne Bearbeitung des Skripts. Um die Prozentanzeige bei den Xiaomis direkt zu nutzen müsste ich es aber nochmal anpassen, oder?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 04 Juni 2019, 20:11:39
Normal müsstest du bei diesem nichts mehr machen oder wird etwas fehlerhaft angezeigt? Werde aus deinem Post nicht ganz schlau.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: kennymc.c am 04 Juni 2019, 21:20:27
Ich hab es so verstanden, dass wenn es kein Reading mit BatterLevel gibt (bei den Xiaomis heißt es ja battery_level) hängt der Batteriestatus nur vom ok / low Wert aus dem battery Reading ab und ist dadurch ungenauer.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 05 Juni 2019, 10:36:31
Ah das ist korrekt. Ich hatte nicht gesehen, dass das Reading battery_level heißt. Da könntest du den Modulauthoren auch mal anschreiben und darauf hinweisen, dass man sich auf einen Standard geeinigt hat. Mehr dazu findet man hier: Topic (https://forum.fhem.de/index.php/topic,87575.0.html) und Wiki (https://wiki.fhem.de/wiki/DevelopmentGuidelines#Standardisierung_der_Readings).

Also ja, dann müsstest du im anderen Zweig auch wieder Anpassungen vornehmen. Wenn es bei dir jedoch jetzt läuft ist die Frage, ob du die Arbeit auf dich nehmen willst.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: kennymc.c am 05 Juni 2019, 19:44:14
Ich hab im Github Repository des Moduls mal ein entsprechendes Issue erstellt. Allerdings übernimmt das Modul im Prinzip nur die Namen aus der ZigBee2MQTT Bridge, die mit Fhem aber nichts zu tun hat und auch unabhängig davon läuft.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 05 Juni 2019, 20:13:32
Dann wirste schwierigkeiten bekommen, dass die das anpassen. Alternativ kannst du dir ein UserReading anlegen, welches den Wert von battery_level übernimmt und batterLevel heißt :)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: kennymc.c am 06 Juni 2019, 15:39:48
Das Modul selbst gibt es ja nur für Fhem also könnte das schon etwas bringen. Ein UserReading wäre zwar eine Lösung, eventuell wäre es für die Zukunft aber besser, wenn man die zu erkennenden Readings für den Status oder Prozentangabe für alle Devices einfach selber z.B. über ein Attribut in einem Dummy festlegen könnte.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Madstar2409 am 21 August 2019, 11:22:26
Hallo,

ich bin relativ frisch mit FHEM unterwegs. Ich bin vor einiger Zeit auf das Modul gestoßen und konnte es auch gut nutzen bis heute. Ich habe nämlich meine Fensterkontakte von MAX auf XIAOMI gewechselt und diese per MQTT2_DEVICE eingebunden. Habe auch den Batteriebot neu gestartet aber er erkennt leider die Battery Readings nicht.

Hier mal die Readings einer der Fensterkontakte:

Readings      
associatedWith   MQTT2_MQTT2Broker   19.08.2019 09:45
battery                   86                                   21.08.2019 11:07
contact                   true                                   21.08.2019 11:07
linkquality           99                                   21.08.2019 11:07
voltage                   2975                           21.08.2019 11:07


Ich habe das Modul auch schon mit den folgenden erweitert:

##############################################
  # MQTT2_DEVICE Devices
  ##############################################
elsif($BatteryType[0] eq "battery"  && InternalVal($Device, "TYPE", "undef") eq "MQTT2_DEVICE")
{
   if(ReadingsVal($Device, "battery", "na") eq "low")
   {
     $ActBatLevel = 0;
   }
   else
   {
    $ActBatLevel = ReadingsNum($Device, "battery", "0");
   }

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
     {
       fhem("setreading $BatteryChanged $Device $text_changed");
     }

     # set the battery value to 75% - 100%
     fhem("setreading $BatteryStatus $Device 100");

     # set the signal state back to none
     fhem("setreading $BatteryStatusBot $SignalDevice none");
   }
   elsif($ActBatLevel > 50)
   {
    # between 50% and 75%
     fhem("setreading $BatteryStatus $Device 75");

     # set the signal state back to none
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
     {
       fhem("setreading $BatteryStatusBot $SignalDevice none");
     }
   }
   elsif($ActBatLevel > 25)
   {
     # between 25% and 50%
     fhem("setreading $BatteryStatus $Device 50");

     # set the signal state back to none
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
     {
       fhem("setreading $BatteryStatusBot $SignalDevice none");
     }
   }
   elsif($ActBatLevel > 5)
   {
     # between 5% and 25%
     fhem("setreading $BatteryStatus $Device 25");

     # maybe already send a message! Easy possible with new signal states
   }
   else
   {
     # TODO: test for 0 and then send "change NOW"!
     # TODO: test for 0 and then send "change NOW"!
     # TODO: test for 0 and then send "change NOW"!
     # TODO: test for 0 and then send "change NOW"!
     # TODO: test for 0 and then send "change NOW"!
     # totally empty (below 5%)
     fhem("setreading $BatteryStatus $Device 0");

     # check if message was already sent
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
     {
       # set signal state to low
       fhem("setreading $BatteryStatusBot $SignalDevice low");
       #send message via TelegramBot
       fhem($msg." ".$text_soon);
     }
   }
}


Leider ohne Erfolg. Hat jemand eine Idee?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Christoph Morrison am 21 August 2019, 13:39:20
Zitat von: Madstar2409 am 21 August 2019, 11:22:26
Leider ohne Erfolg. Hat jemand eine Idee?

Bitte lies unbedingt die Tipps für Forums-Neulinge (https://forum.fhem.de/index.php/topic,71806.0.html).
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Madstar2409 am 21 August 2019, 15:09:11
Danke für den Hinweis aber um ehrlich zu sein hilft mir das bei meinen Problem nicht weiter. Ich habe aber immerhin meinen Post formatieren können  ;).
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 21 August 2019, 15:51:39
Zitat von: Madstar2409 am 21 August 2019, 15:09:11
Danke für den Hinweis aber um ehrlich zu sein hilft mir das bei meinen Problem nicht weiter. Ich habe aber immerhin meinen Post formatieren können  ;).

Dann nicht aufmerksam genug gelesen ;)

Poste doch mal ein list eines dieser neuen MQTT-Dinger ;)

Steht in den INTERNALS tatsächlich unter TYPE MQTT2_DEVICE?

Ansonsten kannst du z.B. mal ein paar Logausgaben einbauen, damit man sieht was wie wo:

Ganz am Anfang, damit man sieht was überhaupt rein kommt.
Da du den Anfang weggelassen hast (also dort wo man die übergebenen Parameter sieht) habe ich mal "nur" $DEVICE loggen lassen...
...wenn mehr Parameter kommen, vielleicht auch die mal loggen lassen...

Log3(undef,3,"BatteryFunction    Device: $Device       BatteryType: $BatteryType[0]");


Und dann mal sehen, ob du generell "rein läufst" und was denn der Batteriewert so "spricht"...


elsif($BatteryType[0] eq "battery"  && InternalVal($Device, "TYPE", "undef") eq "MQTT2_DEVICE")
{
   if(ReadingsVal($Device, "battery", "na") eq "low")
   {
     $ActBatLevel = 0;
   }
   else
   {
    $ActBatLevel = ReadingsNum($Device, "battery", "0");
   }

Log3(undef,3,"BatteryFunction    ActBatLevel: $ActBatLevel");

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
     {
       fhem("setreading $BatteryChanged $Device $text_changed");
     }


Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Madstar2409 am 22 August 2019, 09:28:24
Hallo MadMax,

Hier mal ein Auszug von einem Gerät mit Internals und Readings.

Internals
CID zigbee_0x00158d000xxxxxx
DEF zigbee_0x00158d000xxxxxx

DEVICETOPIC eg_hwr_tuer
FUUID 5d5a5811-f33f-60b1-9d1d-0bb590bxxxxxxx
IODev MQTT2_Broker

LASTInputDev MQTT2_Broker

MQTT2_Broker_MSGCNT 70
MQTT2_Broker_TIME 2019-08-22 08:01:43
MSGCNT 70
NAME eg_hwr_tuer
NR 616
STATE close
TYPE MQTT2_DEVICE



Readings
associatedWith MQTT2_MQTT2Broker 2019-08-19 10:04:33
battery 100 2019-08-22 08:01:43
contact true 2019-08-22 08:01:43
linkquality 102 2019-08-22 08:01:43
voltage 3035 2019-08-22 08:01:43


Der TYPE ist MQTT2_DEVICE.

Ich habe nun den Part der Funktion abgeändert der für meine Geräte greifen sollte aber kein Erfolg.
Hier mal die gesamte Funktion.

#########################################################################
# Helper for readingsGroup BatteryStatus:
# reads the battery states of devices and
# calculates the battery state in percent (depending on device type) and
# stores it as reading in corresponding dummy device
sub BatteryStatusFunction($$)
{
  my ($Device, $Event)  = @_;
  my @BatteryType = split(/:/,$Event); # to distinguish between "battery" and "batteryLevel" devices
  my $Model = AttrVal($Device, "model", "undef"); # get the corresponding model type
  my $TYPE = InternalVal($Device, "TYPE", "undef"); # MAX!
  my $ActBatLevel = 0.0;
  my $MinBatLevel = 0.0;
  my $RemainingVoltageQuater = 0.0; # for "calculating" the colors
  my $MaxBattery = 3.1; # two 1.5V batteries have a measured voltage of 3.1V or even 3.2V
  my @DeviceNameParts = split(/_/,$Device); # to filter out HM_ Devices from neighbor or test system or newly included ones
  my $SignalDevice = $Device . "_BatState";

###############################
# Here you can change the variables to fit your installation.
#
  my $text_now = "Die Batterien von $Device müssen JETZT gewechselt werden!"; #Text for changing battery now
  my $text_soon = "Die Batterien von $Device sollten bald gewechselt werden!"; #Text for changing battery soon
  my $text_changed = "Batterie zuletzt gewechselt: "; #Text for last change
  my $BatteryStatus = "BatterieStatus"; #Name of the Dummy for status
  my $BatteryStatusBot = "BatterieStatusBot"; #Name of the Dummy for status of send messages
  my $BatteryChanged = "BatterieWechsel"; #Name of the Dummy for battery changed information

################################
# Here you choos your message device and how to send
# comment the device you do not want to use
#
# TelegramBot
  my $msg = "set MessageBOT message ";
#
# msg-command
# my $msg = "msg \@User title='Battery Check' ";
#
# Pushover
# my $msg = "set Pushover msg device=User title='Battery Check' ";


 
  Log3(undef, 1, "my_StoreBatteryStatus      Device: $Device       Event: $Event      Model: $Model");
 
  # ignoring Devices that were just created by autocreate
  if($DeviceNameParts[0] eq "HM" || $DeviceNameParts[0] eq "ZWave" || $DeviceNameParts[0] eq "MAX")
  {
    Log3(undef, 1, "my_StoreBatteryStatus      ignoring Device: $Device");
    return;
  }

  # if it is the first time for that device set it to none (initialize)
  if(ReadingsVal($BatteryStatusBot, $SignalDevice, "undef") eq "undef")
  {
    fhem("setreading $BatteryStatusBot $SignalDevice none");
  }
   
  # actually only devices HM-TC-IT-WM-W-EU and HM-CC-RT-DN have battery level and min-level
  # so calculating the percentage of actual level depending on min-level
  # all others just have battery ok or nok
  # IMPORTANT: first filter those which only send "battery" in EVENT
  #            then calculate for those which send "batteryLevel"!
  #            New devices: ZWave. They deliver battery already in percentage.
  #            New devices: XiaomiFlowerSens. They also deliver batteryLevel but already in percentage.

  ##############################################
  # HM Devices with battery
  ##############################################
  if($BatteryType[0] eq "battery"  && $Model ne "HM-TC-IT-WM-W-EU" && $Model ne "HM-CC-RT-DN" && $Model ne "undef")
  {
    if(ReadingsVal($Device, "battery", "low") eq "ok")
    {
      # check if battery was low before -> possibly changed
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $BatteryChanged $Device $text_changed");
        # set the signal state back to none
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }

      # status is "ok" so we set to 100% (we don't know better)
      fhem("setreading $BatteryStatus $Device 100");
    }
    else
    {
      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }

      # status is NOT "ok" ("low") so we set to 0% (we don't know better)
      fhem("setreading $BatteryStatus $Device 0");
    }
  }
  ##############################################
  # ZWave Devices
  ##############################################
elsif($BatteryType[0] eq "battery"  && InternalVal($Device, "TYPE", "undef") eq "ZWave")
{
   if(ReadingsVal($Device, "battery", "na") eq "low")
{
     $ActBatLevel = 0;
}
else
{
    $ActBatLevel = ReadingsNum($Device, "battery", "0");
}

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
     {
       fhem("setreading $BatteryChanged $Device $text_changed");
     }

     # set the battery value to 75% - 100%
     fhem("setreading $BatteryStatus $Device 100");

     # set the signal state back to none
     fhem("setreading $BatteryStatusBot $SignalDevice none");
   }
   elsif($ActBatLevel > 50)
   {
    # between 50% and 75%
     fhem("setreading $BatteryStatus $Device 75");

     # set the signal state back to none
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
     {
       fhem("setreading $BatteryStatusBot $SignalDevice none");
     }
   }
   elsif($ActBatLevel > 25)
   {
     # between 25% and 50%
     fhem("setreading $BatteryStatus $Device 50");

     # set the signal state back to none
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
     {
       fhem("setreading $BatteryStatusBot $SignalDevice none");
     }
   }
   elsif($ActBatLevel > 5)
   {
     # between 5% and 25%
     fhem("setreading $BatteryStatus $Device 25");

     # maybe already send a message! Easy possible with new signal states
   }
   else
   {
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
     # totally empty (below 5%)
     fhem("setreading $BatteryStatus $Device 0");

     # check if message was already sent
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
     {
       # set signal state to low
       fhem("setreading $BatteryStatusBot $SignalDevice low");
       #send message via TelegramBot
       fhem($msg." ".$text_soon);
     }
   }
}

  ##############################################
  # HUE Devices
  ##############################################

elsif($BatteryType[0] eq "battery"  && InternalVal($Device, "TYPE", "undef") eq "HUEDevice")
{
   if(ReadingsVal($Device, "battery", "na") eq "low")
{
     $ActBatLevel = 0;
}
else
{
    $ActBatLevel = ReadingsNum($Device, "battery", "0");
}

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
     {
       fhem("setreading $BatteryChanged $Device $text_changed");
     }

     # set the battery value to 75% - 100%
     fhem("setreading $BatteryStatus $Device 100");

     # set the signal state back to none
     fhem("setreading $BatteryStatusBot $SignalDevice none");
   }
   elsif($ActBatLevel > 50)
   {
    # between 50% and 75%
     fhem("setreading $BatteryStatus $Device 75");

     # set the signal state back to none
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
     {
       fhem("setreading $BatteryStatusBot $SignalDevice none");
     }
   }
   elsif($ActBatLevel > 25)
   {
     # between 25% and 50%
     fhem("setreading $BatteryStatus $Device 50");

     # set the signal state back to none
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
     {
       fhem("setreading $BatteryStatusBot $SignalDevice none");
     }
   }
   elsif($ActBatLevel > 5)
   {
     # between 5% and 25%
     fhem("setreading $BatteryStatus $Device 25");

     # maybe already send a message! Easy possible with new signal states
   }
   else
   {
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
     # totally empty (below 5%)
     fhem("setreading $BatteryStatus $Device 0");

     # check if message was already sent
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
     {
       # set signal state to low
       fhem("setreading $BatteryStatusBot $SignalDevice low");
       #send message via TelegramBot
       fhem($msg." ".$text_soon);
     }
   }
}

  #############################################
  # XiaomiFlowerSens Devices
  #############################################
elsif($BatteryType[0] eq "batteryLevel"  && InternalVal($Device, "TYPE", "undef") eq "XiaomiFlowerSens")
{
   $ActBatLevel = ReadingsNum($Device, "batteryLevel", "0");

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        fhem("setreading $BatteryChanged $Device $text_changed");
      }

      # set the battery value to 75% - 100%
      fhem("setreading $BatteryStatus $Device 100");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 50)
    {
      # between 50% and 75%
      fhem("setreading $BatteryStatus $Device 75");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 25)
    {
      # between 25% and 50%
      fhem("setreading $BatteryStatus $Device 50");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 5)
    {
      # between 5% and 25%
      fhem("setreading $BatteryStatus $Device 25");

      # maybe already send a message! Easy possible with new signal states
    }
    else
    {
      # totally empty (below 5%)
      fhem("setreading $BatteryStatus $Device 0");

      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }
    }
  }
 
  ##############################################
  # XiaomiMQTTDevice Devices
  ##############################################
 
 
   elsif($BatteryType[0] eq "battery"  && InternalVal($Device, "TYPE", "undef") eq "XiaomiMQTTDevice")
{
   $ActBatLevel = ReadingsNum($Device, "battery", "0");

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        fhem("setreading $BatteryChanged $Device $text_changed");
      }

      # set the battery value to 75% - 100%
      fhem("setreading $BatteryStatus $Device 100");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 50)
    {
      # between 50% and 75%
      fhem("setreading $BatteryStatus $Device 75");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 25)
    {
      # between 25% and 50%
      fhem("setreading $BatteryStatus $Device 50");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 5)
    {
      # between 5% and 25%
      fhem("setreading $BatteryStatus $Device 25");

      # maybe already send a message! Easy possible with new signal states
    }
    else
    {
      # totally empty (below 5%)
      fhem("setreading $BatteryStatus $Device 0");

      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }
    }
  }

##############################################
  # MQTT2_DEVICE Devices
  ##############################################
elsif($BatteryType[0] eq "battery"  && InternalVal($Device, "TYPE", "undef") eq "MQTT2_DEVICE")
{
   $ActBatLevel = ReadingsNum($Device, "battery", "0");


   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        fhem("setreading $BatteryChanged $Device $text_changed");
      }

      # set the battery value to 75% - 100%
      fhem("setreading $BatteryStatus $Device 100");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 50)
    {
      # between 50% and 75%
      fhem("setreading $BatteryStatus $Device 75");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 25)
    {
      # between 25% and 50%
      fhem("setreading $BatteryStatus $Device 50");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 5)
    {
      # between 5% and 25%
      fhem("setreading $BatteryStatus $Device 25");

      # maybe already send a message! Easy possible with new signal states
    }
    else
    {
      # totally empty (below 5%)
      fhem("setreading $BatteryStatus $Device 0");

      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }
    }
  }
  ##############################################
  # MAX! Devices
  ##############################################
  elsif(($BatteryType[0] eq "battery")  && ($TYPE eq "MAX"))
  {
    if(ReadingsVal($Device, "battery", "low") eq "ok")
    {
      # check if battery was low before -> possibly changed
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low")
      {
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $BatteryChanged $Device $text_changed");
        # set the signal state back to none
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }

      # status is "ok" so we set to 100% (we don't know better)
      fhem("setreading $BatteryStatus $Device 100");
    }
    else
    {
      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }

      # status is NOT "ok" ("low") so we set to 0% (we don't know better)
      fhem("setreading $BatteryStatus $Device 0");
    }
  }
}

##################################################
# Helper for readingsGroup BatteryStatus:
# sets the icon and icon color depending on "calculated" percentage value
sub SetBatterieIcon($$)
{
  my ($Device, $Value)  = @_;
  my $Icon = "measure_battery_" . "$Value"; # here the matching icon is "set"
  my $ActionDetectorDevice = "status_" . $Device;
  my $Name = ""; # name for signal state
  my $State = ReadingsVal("ActionDetector", $ActionDetectorDevice, "alive");

#  Log3(undef, 1, "my_SetBatteryIcon      Device: $Device       Value: $Value");

  if($State ne "alive")
  {
    $Icon = "message_attention\@red";
  }
  else
  {
    if($Value > 75)
    {
      $Icon = $Icon . "\@green"; # between 75% and 100%
    }
    elsif($Value > 25)
    {
      $Icon = $Icon . "\@orange"; # between 25% and 75%
    }
    else
    {
      $Icon = $Icon . "\@red"; # below 25%
    }
  }

  return $Icon;
}

#####################################################
# Start script once and delet after

sub BatteryStart()
{
#Define Dummys for script
my $BatteryStatus = "BatterieStatus"; #Name of the Dummy for status
my $BatteryStatusBot = "BatterieStatusBot"; #Name of the Dummy for status of send messages
my $BatteryChanged = "BatterieWechsel"; #Name of the Dummy for battery changed information
my $ReadingsGroup = "rgBatteryStatus"; #Name of the ReadingsGroup
my $Room = "Batterystatus"; #room for the dummys
my $Notify = "NO.BatterieNotify"; #Name of the Notify for sending battery information

fhem("setdefaultattr room $Room; define $BatteryStatus dummy; define $BatteryStatusBot dummy; define $BatteryChanged dummy;
      define $ReadingsGroup readingsGroup NAME=BatterieStatus:.*; attr $ReadingsGroup valueIcon {SetBatterieIcon(\$READING, \$VALUE)};
      attr $ReadingsGroup mapping \$READING; setdefaultattr;");


#Set Readings for device with reading battery
my @bat_b = devspec2array("battery=.*");
for(my $x=0;$x<@bat_b;$x++)
{
my $stat_b = ReadingsVal($bat_b[$x],"battery","undef");
if($stat_b ne "undef")
{
BatteryStatusFunction($bat_b[$x],"battery: $stat_b");
}
}

#Set Readings for device with reading batteryLevel
my @bat_l = devspec2array("batteryLevel=.*");
for(my $x=0;$x<@bat_l;$x++)
{
my $stat_l = ReadingsVal($bat_l[$x],"batteryLevel","undef");
if($stat_l ne "undef")
{
BatteryStatusFunction($bat_l[$x],"batteryLevel: $stat_l");
}
}

fhem("define $Notify notify .*:battery.* {BatteryStatusFunction(\$NAME, \$EVENT)}; attr $Notify room $Room;")
}





Log im Anhang. Also die Werte werden gelesen aber nicht richtig dargestellt. Liegt es evtl. an den Wert für Model. Der ist bei den Geräten wo es funktioniert undef und bei den MQTT Geräten irgendwas mit zigbee...?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 August 2019, 10:29:51
Warum hast du die Logausgaben nicht eingebaut?
EDIT: oder ist die weiter unten erwähnte von dir? Was steht denn dann dazu im Log? Ah, ok, Log als Bild. Hmmm, besser als "code" posten!

So kann man nur (was du ja schon getan hast) theoretisch checken, dass der Teil eigentlich gehen sollte/könnte/müsste...
...aber ohne weitere Infos WEISS man es halt nicht (warum nicht)...

D.h. es läuft für andere Geräte von dir!?

Wie geschrieben ich würde mal alles ausgeben lassen was "rein" kommt bzw. zu Beginn "erzuegt" wird...
...bin ja nicht mal sicher welche Version des Codes du nutzt (gibt da wohl mehrere!?).

Bzw. ein Log-Eintrag müsste doch kommen:


# my $msg = "set Pushover msg device=User title='Battery Check' ";



  Log3(undef, 1, "my_StoreBatteryStatus      Device: $Device       Event: $Event      Model: $Model");

  # ignoring Devices that were just created by autocreate


Was steht denn dazu im Log?
Also bzgl. Device, Event und Model?

EDIT: ok, als Bild...

Evtl. (wie geschrieben) mal erweitern um weitere Werte, wie z.B. Type etc.
EDIT: das wäre interessant. Model wird (soweit ich's im Kopf hab/überflogen hab) nur für HomeMatic verwendet...

Ich bin da ja (eigentlich) schon lang raus, hatte nur mal meinen Ursprungscode gepostet ;)

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Madstar2409 am 22 August 2019, 11:35:49
Ok ich bin nun sicher das es an Model liegt.  Ich habe von einem MQTT2_DEVICE Gerät das Attribut Model gelöscht und siehe das Gerät wird erkannt bzw. die richtigen Werte. Siehe folgende Logs und Screenshot.


2019.08.22 11:18:17 3: my_StoreBatteryStatus      Device: Temp_Sensor_Kueche       Event: battery: 91      Model: L_07_TempHumHpa_TempSensor      Type: MQTT2_DEVICE
2019.08.22 11:18:17 3: my_StoreBatteryStatus      Device: Temp_Sensor_SZ       Event: battery: 86      Model: L_07_TempHumHpa_TempSensor      Type: MQTT2_DEVICE
2019.08.22 11:18:18 3: my_StoreBatteryStatus      Device: eg_flur_haustuer       Event: battery: 100      Model: L_06_zigbee2mqtt_ContactSensor      Type: MQTT2_DEVICE
2019.08.22 11:18:18 3: my_StoreBatteryStatus      Device: eg_hwr_fenster       Event: battery: 100      Model: L_06_zigbee2mqtt_ContactSensor      Type: MQTT2_DEVICE
2019.08.22 11:18:18 3: my_StoreBatteryStatus      Device: eg_hwr_tuer       Event: battery: 100      Model: L_06_zigbee2mqtt_ContactSensor      Type: MQTT2_DEVICE
2019.08.22 11:18:18 3: my_StoreBatteryStatus      Device: eg_kueche_fenster       Event: battery: 86      Model: L_06_zigbee2mqtt_ContactSensor      Type: MQTT2_DEVICE
2019.08.22 11:18:18 3: my_StoreBatteryStatus      Device: eg_wz_doppelfenst_li       Event: battery: 100      Model: undef      Type: MQTT2_DEVICE
2019.08.22 11:18:18 3: my_StoreBatteryStatus      Device: eg_wz_doppelfenst_re       Event: battery: 100      Model: L_06_zigbee2mqtt_ContactSensor      Type: MQTT2_DEVICE
2019.08.22 11:18:18 3: my_StoreBatteryStatus      Device: eg_wz_einzelfenster       Event: battery: 100      Model: L_06_zigbee2mqtt_ContactSensor      Type: MQTT2_DEVICE
2019.08.22 11:18:18 3: my_StoreBatteryStatus      Device: eg_wz_terrasse_li       Event: battery: 100      Model: L_06_zigbee2mqtt_ContactSensor      Type: MQTT2_DEVICE
2019.08.22 11:18:18 3: my_StoreBatteryStatus      Device: og.dachboden.lucke       Event: battery: ok      Model: undef      Type: MAX
2019.08.22 11:18:18 3: my_StoreBatteryStatus      Device: Pflanzensensor1       Event: batteryLevel: 95      Model: undef      Type: XiaomiFlowerSens
2019.08.22 11:18:18 3: my_StoreBatteryStatus      Device: Pflanzensensor2       Event: batteryLevel: 100      Model: undef      Type: XiaomiFlowerSens


2019.08.22 11:18:18 3: my_StoreBatteryStatus      Device: eg_wz_doppelfenst_li       Event: battery: 100      Model: undef      Type: MQTT2_DEVICE

Nun ist die Frage wie bekomme ich das im Modul Code korrigiert.  ???

Hier nochmal der Code des Batterie Moduls.

#########################################################################
# Helper for readingsGroup BatteryStatus:
# reads the battery states of devices and
# calculates the battery state in percent (depending on device type) and
# stores it as reading in corresponding dummy device
sub BatteryStatusFunction($$)
{
  my ($Device, $Event)  = @_;
  my @BatteryType = split(/:/,$Event); # to distinguish between "battery" and "batteryLevel" devices
  my $Model = AttrVal($Device, "model", "undef"); # get the corresponding model type
  my $TYPE = InternalVal($Device, "TYPE", "undef"); # MAX!
  my $ActBatLevel = 0.0;
  my $MinBatLevel = 0.0;
  my $RemainingVoltageQuater = 0.0; # for "calculating" the colors
  my $MaxBattery = 3.1; # two 1.5V batteries have a measured voltage of 3.1V or even 3.2V
  my @DeviceNameParts = split(/_/,$Device); # to filter out HM_ Devices from neighbor or test system or newly included ones
  my $SignalDevice = $Device . "_BatState";

###############################
# Here you can change the variables to fit your installation.
#
  my $text_now = "Die Batterien von $Device müssen JETZT gewechselt werden!"; #Text for changing battery now
  my $text_soon = "Die Batterien von $Device sollten bald gewechselt werden!"; #Text for changing battery soon
  my $text_changed = "Batterie zuletzt gewechselt: "; #Text for last change
  my $BatteryStatus = "BatterieStatus"; #Name of the Dummy for status
  my $BatteryStatusBot = "BatterieStatusBot"; #Name of the Dummy for status of send messages
  my $BatteryChanged = "BatterieWechsel"; #Name of the Dummy for battery changed information

################################
# Here you choos your message device and how to send
# comment the device you do not want to use
#
# TelegramBot
  my $msg = "set MessageBOT message ";
#
# msg-command
# my $msg = "msg \@User title='Battery Check' ";
#
# Pushover
# my $msg = "set Pushover msg device=User title='Battery Check' ";


  #Log3(undef,3,"my_StoreBatteryStatus    Device: $Device       BatteryType: $BatteryType[0]");
  Log3(undef, 3, "my_StoreBatteryStatus      Device: $Device       Event: $Event      Model: $Model      Type: $TYPE");
 
  # ignoring Devices that were just created by autocreate
  if($DeviceNameParts[0] eq "HM" || $DeviceNameParts[0] eq "ZWave" || $DeviceNameParts[0] eq "MAX")
  {
    Log3(undef, 1, "my_StoreBatteryStatus      ignoring Device: $Device");
    return;
  }

  # if it is the first time for that device set it to none (initialize)
  if(ReadingsVal($BatteryStatusBot, $SignalDevice, "undef") eq "undef")
  {
    fhem("setreading $BatteryStatusBot $SignalDevice none");
  }
   
  # actually only devices HM-TC-IT-WM-W-EU and HM-CC-RT-DN have battery level and min-level
  # so calculating the percentage of actual level depending on min-level
  # all others just have battery ok or nok
  # IMPORTANT: first filter those which only send "battery" in EVENT
  #            then calculate for those which send "batteryLevel"!
  #            New devices: ZWave. They deliver battery already in percentage.
  #            New devices: XiaomiFlowerSens. They also deliver batteryLevel but already in percentage.

  ##############################################
  # HM Devices with battery
  ##############################################
  if($BatteryType[0] eq "battery"  && $Model ne "HM-TC-IT-WM-W-EU" && $Model ne "HM-CC-RT-DN" && $Model ne "undef")
  {
    if(ReadingsVal($Device, "battery", "low") eq "ok")
    {
      # check if battery was low before -> possibly changed
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $BatteryChanged $Device $text_changed");
        # set the signal state back to none
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }

      # status is "ok" so we set to 100% (we don't know better)
      fhem("setreading $BatteryStatus $Device 100");
    }
    else
    {
      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }

      # status is NOT "ok" ("low") so we set to 0% (we don't know better)
      fhem("setreading $BatteryStatus $Device 0");
    }
  }
  ##############################################
  # ZWave Devices
  ##############################################
elsif($BatteryType[0] eq "battery"  && InternalVal($Device, "TYPE", "undef") eq "ZWave")
{
   if(ReadingsVal($Device, "battery", "na") eq "low")
{
     $ActBatLevel = 0;
}
else
{
    $ActBatLevel = ReadingsNum($Device, "battery", "0");
}

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
     {
       fhem("setreading $BatteryChanged $Device $text_changed");
     }

     # set the battery value to 75% - 100%
     fhem("setreading $BatteryStatus $Device 100");

     # set the signal state back to none
     fhem("setreading $BatteryStatusBot $SignalDevice none");
   }
   elsif($ActBatLevel > 50)
   {
    # between 50% and 75%
     fhem("setreading $BatteryStatus $Device 75");

     # set the signal state back to none
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
     {
       fhem("setreading $BatteryStatusBot $SignalDevice none");
     }
   }
   elsif($ActBatLevel > 25)
   {
     # between 25% and 50%
     fhem("setreading $BatteryStatus $Device 50");

     # set the signal state back to none
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
     {
       fhem("setreading $BatteryStatusBot $SignalDevice none");
     }
   }
   elsif($ActBatLevel > 5)
   {
     # between 5% and 25%
     fhem("setreading $BatteryStatus $Device 25");

     # maybe already send a message! Easy possible with new signal states
   }
   else
   {
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
     # totally empty (below 5%)
     fhem("setreading $BatteryStatus $Device 0");

     # check if message was already sent
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
     {
       # set signal state to low
       fhem("setreading $BatteryStatusBot $SignalDevice low");
       #send message via TelegramBot
       fhem($msg." ".$text_soon);
     }
   }
}

  ##############################################
  # HUE Devices
  ##############################################

elsif($BatteryType[0] eq "battery"  && InternalVal($Device, "TYPE", "undef") eq "HUEDevice")
{
   if(ReadingsVal($Device, "battery", "na") eq "low")
{
     $ActBatLevel = 0;
}
else
{
    $ActBatLevel = ReadingsNum($Device, "battery", "0");
}

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
     {
       fhem("setreading $BatteryChanged $Device $text_changed");
     }

     # set the battery value to 75% - 100%
     fhem("setreading $BatteryStatus $Device 100");

     # set the signal state back to none
     fhem("setreading $BatteryStatusBot $SignalDevice none");
   }
   elsif($ActBatLevel > 50)
   {
    # between 50% and 75%
     fhem("setreading $BatteryStatus $Device 75");

     # set the signal state back to none
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
     {
       fhem("setreading $BatteryStatusBot $SignalDevice none");
     }
   }
   elsif($ActBatLevel > 25)
   {
     # between 25% and 50%
     fhem("setreading $BatteryStatus $Device 50");

     # set the signal state back to none
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
     {
       fhem("setreading $BatteryStatusBot $SignalDevice none");
     }
   }
   elsif($ActBatLevel > 5)
   {
     # between 5% and 25%
     fhem("setreading $BatteryStatus $Device 25");

     # maybe already send a message! Easy possible with new signal states
   }
   else
   {
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
     # totally empty (below 5%)
     fhem("setreading $BatteryStatus $Device 0");

     # check if message was already sent
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
     {
       # set signal state to low
       fhem("setreading $BatteryStatusBot $SignalDevice low");
       #send message via TelegramBot
       fhem($msg." ".$text_soon);
     }
   }
}

  #############################################
  # XiaomiFlowerSens Devices
  #############################################
elsif($BatteryType[0] eq "batteryLevel"  && InternalVal($Device, "TYPE", "undef") eq "XiaomiFlowerSens")
{
   $ActBatLevel = ReadingsNum($Device, "batteryLevel", "0");

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        fhem("setreading $BatteryChanged $Device $text_changed");
      }

      # set the battery value to 75% - 100%
      fhem("setreading $BatteryStatus $Device 100");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 50)
    {
      # between 50% and 75%
      fhem("setreading $BatteryStatus $Device 75");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 25)
    {
      # between 25% and 50%
      fhem("setreading $BatteryStatus $Device 50");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 5)
    {
      # between 5% and 25%
      fhem("setreading $BatteryStatus $Device 25");

      # maybe already send a message! Easy possible with new signal states
    }
    else
    {
      # totally empty (below 5%)
      fhem("setreading $BatteryStatus $Device 0");

      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }
    }
  }
 
  ##############################################
  # XiaomiMQTTDevice Devices
  ##############################################
 
 
   elsif($BatteryType[0] eq "battery"  && InternalVal($Device, "TYPE", "undef") eq "XiaomiMQTTDevice")
{
   $ActBatLevel = ReadingsNum($Device, "battery", "0");

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        fhem("setreading $BatteryChanged $Device $text_changed");
      }

      # set the battery value to 75% - 100%
      fhem("setreading $BatteryStatus $Device 100");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 50)
    {
      # between 50% and 75%
      fhem("setreading $BatteryStatus $Device 75");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 25)
    {
      # between 25% and 50%
      fhem("setreading $BatteryStatus $Device 50");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 5)
    {
      # between 5% and 25%
      fhem("setreading $BatteryStatus $Device 25");

      # maybe already send a message! Easy possible with new signal states
    }
    else
    {
      # totally empty (below 5%)
      fhem("setreading $BatteryStatus $Device 0");

      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }
    }
  }

##############################################
  # MQTT2_DEVICE Devices
  ##############################################
elsif($BatteryType[0] eq "battery"  && InternalVal($Device, "TYPE", "undef") eq "MQTT2_DEVICE")
{
   $ActBatLevel = ReadingsNum($Device, "battery", "0");


   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        fhem("setreading $BatteryChanged $Device $text_changed");
      }

      # set the battery value to 75% - 100%
      fhem("setreading $BatteryStatus $Device 100");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 50)
    {
      # between 50% and 75%
      fhem("setreading $BatteryStatus $Device 75");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 25)
    {
      # between 25% and 50%
      fhem("setreading $BatteryStatus $Device 50");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 5)
    {
      # between 5% and 25%
      fhem("setreading $BatteryStatus $Device 25");

      # maybe already send a message! Easy possible with new signal states
    }
    else
    {
      # totally empty (below 5%)
      fhem("setreading $BatteryStatus $Device 0");

      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }
    }
  }
  ##############################################
  # MAX! Devices
  ##############################################
  elsif(($BatteryType[0] eq "battery")  && ($TYPE eq "MAX"))
  {
    if(ReadingsVal($Device, "battery", "low") eq "ok")
    {
      # check if battery was low before -> possibly changed
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low")
      {
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $BatteryChanged $Device $text_changed");
        # set the signal state back to none
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }

      # status is "ok" so we set to 100% (we don't know better)
      fhem("setreading $BatteryStatus $Device 100");
    }
    else
    {
      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }

      # status is NOT "ok" ("low") so we set to 0% (we don't know better)
      fhem("setreading $BatteryStatus $Device 0");
    }
  }
}

##################################################
# Helper for readingsGroup BatteryStatus:
# sets the icon and icon color depending on "calculated" percentage value
sub SetBatterieIcon($$)
{
  my ($Device, $Value)  = @_;
  my $Icon = "measure_battery_" . "$Value"; # here the matching icon is "set"
  my $ActionDetectorDevice = "status_" . $Device;
  my $Name = ""; # name for signal state
  my $State = ReadingsVal("ActionDetector", $ActionDetectorDevice, "alive");

#  Log3(undef, 1, "my_SetBatteryIcon      Device: $Device       Value: $Value");

  if($State ne "alive")
  {
    $Icon = "message_attention\@red";
  }
  else
  {
    if($Value > 75)
    {
      $Icon = $Icon . "\@green"; # between 75% and 100%
    }
    elsif($Value > 25)
    {
      $Icon = $Icon . "\@orange"; # between 25% and 75%
    }
    else
    {
      $Icon = $Icon . "\@red"; # below 25%
    }
  }

  return $Icon;
}

#####################################################
# Start script once and delet after

sub BatteryStart()
{
#Define Dummys for script
my $BatteryStatus = "BatterieStatus"; #Name of the Dummy for status
my $BatteryStatusBot = "BatterieStatusBot"; #Name of the Dummy for status of send messages
my $BatteryChanged = "BatterieWechsel"; #Name of the Dummy for battery changed information
my $ReadingsGroup = "rgBatteryStatus"; #Name of the ReadingsGroup
my $Room = "Batterystatus"; #room for the dummys
my $Notify = "NO.BatterieNotify"; #Name of the Notify for sending battery information

fhem("setdefaultattr room $Room; define $BatteryStatus dummy; define $BatteryStatusBot dummy; define $BatteryChanged dummy;
      define $ReadingsGroup readingsGroup NAME=BatterieStatus:.*; attr $ReadingsGroup valueIcon {SetBatterieIcon(\$READING, \$VALUE)};
      attr $ReadingsGroup mapping \$READING; setdefaultattr;");


#Set Readings for device with reading battery
my @bat_b = devspec2array("battery=.*");
for(my $x=0;$x<@bat_b;$x++)
{
my $stat_b = ReadingsVal($bat_b[$x],"battery","undef");
if($stat_b ne "undef")
{
BatteryStatusFunction($bat_b[$x],"battery: $stat_b");
}
}

#Set Readings for device with reading batteryLevel
my @bat_l = devspec2array("batteryLevel=.*");
for(my $x=0;$x<@bat_l;$x++)
{
my $stat_l = ReadingsVal($bat_l[$x],"batteryLevel","undef");
if($stat_l ne "undef")
{
BatteryStatusFunction($bat_l[$x],"batteryLevel: $stat_l");
}
}

fhem("define $Notify notify .*:battery.* {BatteryStatusFunction(\$NAME, \$EVENT)}; attr $Notify room $Room;")
}
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 22 August 2019, 13:00:35
IMHO sollte man hier nachbessern :
if($BatteryType[0] eq "battery"  && $Model ne "HM-TC-IT-WM-W-EU" && $Model ne "HM-CC-RT-DN" && $Model ne "undef")
weil sonst die Dinger unter die HM Decke rutschen :)
D.h. wenn es HM sein soll warum dann nicht gleich auf TYPE CUL_HM prüfen ?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 August 2019, 13:37:23
Das dachte ich auch...
...weil Model ja sonst nirgends groß "vorkommt"...
...drum ja mal loggen lassen was rein kommt bzw. gleich zuu Beginn "definiert/erkannt" wird...

Damit lässt sich dann besser feststellen "wo es dann im Code lang geht" ;)

EDIT: diese Zeile ist (zugegebenermassen) auch sehr "speziell" ;) Die habe ich halt damals (bei mir) eingebaut, um die etwas "schlaueren" HM-Devices (die Spannungen liefern) auch zu bekommen. Sauberer wäre nat. ein genereller "Umbau" der Readings auf "Standard". Es gab/gibt ja eine Diskussion diesbezüglich... Oder halt das mal "echt gerade rücken" (wüsste nur nicht wie und da es für mich passt/gepasst hat ;)  ).

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Madstar2409 am 22 August 2019, 13:47:30
Ok, ich habe den Part für die HM Devices nun entfernt(da ich sie nicht brauche) und es werden nun die Batteriestatus readings initial auf 100 (grün) gesetzt. Leider werden die Readings nicht aktualisiert mit den realen Geräte Readings wenn EVENTS zu den Geräten rein kommen. Ich suche noch warum sie nicht aktualisiert werden.
EDIT: Sorry hatte die Logik im Code falsch interpretiert. Es sollte alles funktionieren. Vielen Dank für eure Hilfe.  :) :) :) :)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 August 2019, 14:01:04
Kommen Events?

EventMonitor und schauen...

Was zeigt dir, dass nicht aktualisiert wird, obwohl Events kommen?

Irgendwo event-on-change gesetzt?

Wie sieht das Notify aus, welches ja die Werte "berechnet"?
Triggert es (bei den Events)?

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Madstar2409 am 22 August 2019, 14:04:04
Hi MadMax,

habe meinen vorherigen parallel gerade editiert. Es ist alles ok. Ich hatte die Logik im Modul erst falsch gedeutet. Habe dann ein manuelles setreading gemacht und es funktioniert wie es soll ;-).

VG
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 August 2019, 16:23:53
Kein Ding!

Wenn es geht is gut! :)

Viel Spaß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: FunkOdyssey am 31 Oktober 2019, 09:29:12
Ich nutze neuerdings diese Lösung hier und auch den Zweig 'no-BatteryStatusBot'.
Bei meinen Z-Wave-Geräten erhalte ich die Benachrichtungen doppelt und weiß nicht wieso.

Als Event habe ich Folgendes:

2019-10-31_06:52:12 zw_pir battery: 20 %
2019-10-31_06:52:12 zw_pir batteryPercent: 20


Im FHEM-Log das hier:

2019.10.31 06:52:12.065 1:  PERL WARNING: Use of uninitialized value $v in substitution (s///) at fhem.pl line 1131.
2019.10.31 06:52:12.065 3:  eval: my $EVTPART1='20';my $NAME='zw_pir';my $EVENT='battery: 20 %';my $TYPE='ZWave';my $SELF='NO.BatterieNotify';my $EVTPART0='battery:';my $EVTPART2='%';{BatteryStatusFunction($NAME, $EVENT)}
2019.10.31 06:52:12.065 1:  PERL WARNING: Use of uninitialized value $v in concatenation (.) or string at fhem.pl line 1132.
2019.10.31 06:52:12.065 3:  eval: my $EVTPART1='20';my $NAME='zw_pir';my $EVENT='battery: 20 %';my $TYPE='ZWave';my $SELF='NO.BatterieNotify';my $EVTPART0='battery:';my $EVTPART2='%';{BatteryStatusFunction($NAME, $EVENT)}


Das Gerät hat diese Readings:

     2019-10-31 06:52:12   battery         20 %
     2019-10-31 06:52:12   batteryPercent  20
     2019-10-31 06:52:12   batteryState    ok



Hat jemand eine Idee woran der Doppelversand liegt?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: DeeSPe am 31 Oktober 2019, 10:18:05
Zitat von: FunkOdyssey am 31 Oktober 2019, 09:29:12
Hat jemand eine Idee woran der Doppelversand liegt?

Ja, es liegt daran dass das notify auf battery, batteryLevel und batteryPercent reagiert.
Ändere doch einfach den Trigger des notify:
define NO.BatterieNotify notify .*:(battery|batteryLevel)\s.* {BatteryStatusFunction($NAME, $EVENT)}

Gruß
Dan
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: FunkOdyssey am 31 Oktober 2019, 10:32:55
Danke für den Tipp.
Ich habe mich rückwärts durch den Code gearbeitet und bin auch gerade an dieser Stelle stehengeblieben. Ich hätte vielleicht dem Event folgen sollen. :-)
Aber auf deine Schreibvariante wäre ich nicht gekommen. Das \s hätte ich vergessen. Danke. Ich probiere es aus.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: gehrt am 22 November 2019, 22:32:05
Hallo!

Ich habe mir von Github das Script runtergeladen und in FHEM integriert. Ich habe LaCrosse und Homematic-Thermostate. Die Homematic-Sachen werden schön angezeigt, aber von den LaCrosse nichts. Im Skript steht auch nichts von LaCrosse und hier im Thread finde ich keinen Hinweis, dass LaCrosse nicht mehr drin ist.
Auch irritiert mich GitHub, wo steht, dass das der letzte Commit von 18.01.18 schon 2 Jahre her sein soll.

Wie ist der Stand um dieses Projekt? Lebt das hier noch, oder nicht mehr? Was ist mit LaCrosse?

Grüße
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 November 2019, 22:39:23
Poste ein list von einem deiner LaCrosse-Dinger...
...und vielleicht lässt sich das integrieren... :)

Ansonsten auch gerne selber machen:

einfach einen möglichst passenden Zweig suchen, kopieren/einfügen und anpassen ;)

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 23 November 2019, 20:35:54
Die Frage ist, welchen Zweig du genommen hast und wie die Batterie Readings der Geräte heißen. Daher list Posten und Zweig benennen.

Und nein, effektiv richtig weiter bearbeitet wird das "Modul" aktuell nicht.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Aladin222 am 13 Dezember 2019, 11:08:19
hi @all,

hab das mal ausprobiert .... verstehe aber wohl noch nicht ganz die volle Funktion :-(

Es wurden  rgBatterieStatus angelegt :

BadTaster 2019-12-10 03:49:26
Bad_UG   2019-12-10 03:49:26

alle mit voller Batterie ....also soweit alles gut :-)

die Dummies BatterieStatus & BatterieWechsel zeigen nur ???  ....ist das normal ?
Wie kann ich eine leere Batterie simulieren, um zu schauen das die Benachrichtigung funktioniert ?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 13 Dezember 2019, 11:23:35
Zitat von: Aladin222 am 13 Dezember 2019, 11:08:19
hi @all,

hab das mal ausprobiert .... verstehe aber wohl noch nicht ganz die volle Funktion :-(

Es wurden  rgBatterieStatus angelegt :

BadTaster 2019-12-10 03:49:26
Bad_UG   2019-12-10 03:49:26

alle mit voller Batterie ....also soweit alles gut :-)

die Dummies BatterieStatus & BatterieWechsel zeigen nur ???  ....ist das normal ?
Wie kann ich eine leere Batterie simulieren, um zu schauen das die Benachrichtigung funktioniert ?

Hmmm ob die "drei Fragezeichen" normal sind: keine Ahung.
Meist zeigt das, dass noch nichts (kein Status) gesetzt wurde...


Simulieren: einfach mittels setreading Device battery Low (oder welches Reading und welcher Wert halt für das jeweilige Gerät zutrifft)

Bei der nächsten Meldung vom Gerät wird das ja wieder "zurückkorrigiert" ;)

Kommen denn von deinen Geräten zyklische Batterie-Meldungen?

Denn solange keine Batterie-Events kommen, passiert nat. (für dieses Gerät) nix...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: sepultura30 am 12 Januar 2020, 01:13:25
Hallo,

im Modul ist ein Fehler drinnen für HM-Devices, Zeile 210 muss das so heisen:

$MinBatLevel = ReadingsNum($Device, ".R-lowBatLimitRT", "0.0"); der Punkt fehlt. So funktioniert die Berechnung nicht mit .R-lowBatLimitRT

Grüße Sandro
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 12 Januar 2020, 10:08:04
Zitat von: sepultura30 am 12 Januar 2020, 01:13:25
Hallo,

im Modul ist ein Fehler drinnen für HM-Devices, Zeile 210 muss das so heisen:

$MinBatLevel = ReadingsNum($Device, ".R-lowBatLimitRT", "0.0"); der Punkt fehlt. So funktioniert die Berechnung nicht mit .R-lowBatLimitRT

Grüße Sandro

Funktioniert bei mir problemlos...
Poste doch mal ein list von deinem Homematic wo es nicht geht/ging...

EDIT: eher würde ich die Anführungszeichen um den "Ersatzwerr" enrfernen, also 0.0 statt "0.0" (schlägt aber ja nur zu, falls es das Reading nicht gibt)

EDIT: was liefert denn {ReadingsNum("DeviceName","R-lowBatLimitRT",0.0)} in FhemWeb. DeviceName halt mit einem passenden Namen ersetzen... Eben bei mir getestet: funktioniert und liefert 2.2 zurück...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: sepultura30 am 12 Januar 2020, 11:35:14
Hallo,

bei allen Geräten mit BatteryLevel ->HM-CC-RT-DN weil da das Reading so aussieht ->.R-lowBatLimitRT 2.4 V 2020-01-10 22:42:46
seit dem ich den Code geändert habe funktioniert es.


Grüße

Sandro
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 12 Januar 2020, 11:56:57
Dann ist eher die Frage: warum das (nur) bei dir so ist!?

Bei mir steht da nichts mit Punkt...

Also schon seit ich die Geräte mittels CUL_HM angelegt habe (ca. 5 Jahre) ist das bei mir OHNE Punkt...

Entweder kam das mit einem der letzten (kleiner 3 Wochen, weil da bei mir in etwa das letzte Update war) Updates, dann ist es die Frage: warum!? Also Absicht (warum?!) oder Fehler...
Und wenn das nicht: was ist (nur) bei dir anders...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: my-engel am 12 Januar 2020, 12:01:51
Hallo,

ich habe das Problem, dass in der Tabelle des "rgBatterieStatus" einzelne HM-CC-RT-DN nicht das aktuelle Datum haben,
obwohl das Datum im Reading des Device selbst aktuell ist.
Nach setzen des Punkt laut "sepultura30" und "reload 99_BatteryCheckUtils.pm"
ist die Tabelle des "rgBatterieStatus" wieder i.O.

MfG Uwe

Edit:  das Reading selbst ist bei mir auch ohne Punkt!
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 12 Januar 2020, 12:08:50
Hmmm, kann ich nicht nachvollziehen...

Habt ihr kürzlich (also unter 3 Wochen) ein fhem Update gemacht?

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: my-engel am 12 Januar 2020, 12:18:06
Hallo,

ja, Update mache ich regelmaßig aller Woche und die HM-CC-RT-DN sind schon ca. 2 Jahre in Betrieb.
Habe da noch Telegram mit aktiviert um mir die Batteriestände übermitteln zun lassen.
Dies funktionierte auch bis jetzt regelmäßig.
(habe gerade welche mit niedrigem Batteriestand aber noch nicht gewechselt, somit kommt immer mal ne Meldung)
Bei mir ist dass nur die Tabelle des "rgBatterieStatus",
die Readings selbst stehen alle ohne Punkt drinn.
mal sehen ob nach dem Ändern Telegramm noch funktioniert...
Am Update liegt es glaube ich nicht, da dies schon länger so ist.
Hatte mich bis jetzt noch nicht gestört...

Gruß Uwe
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 12 Januar 2020, 12:33:16
Trotzdem noch mal die Bitte:

was liefert denn


{ReadingsNum("DeviceName","R-lowBatLimitRT",0.0)}


Devicename nat. mit einem gültigen Namen ersetzen ;)
Und eingegeben im "FhemWeb-cmd" Fenster...

Bzw. was liefert dann im Vergleich:


{ReadingsNum("DeviceName",".R-lowBatLimitRT",0.0)}


Eventuell steht bei euch VOR dem Readingnamen ein "Leerzeichen" (das man nicht gleich sieht!?), denn das würde dann passen...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: my-engel am 12 Januar 2020, 12:57:45
Ich noch mal,

ich habe den Punkt in der 99_BatteryCheckUtils.pm wieder entfernt weil Telegram nicht mehr funktionierte.
Logisch weil:
{ReadingsNum("Arbeitszimmer.DG.Fenster",".R-lowBatLimitRT",0.0)}
0

liefert und:
{ReadingsNum("Arbeitszimmer.DG.Fenster","R-lowBatLimitRT",0.0)}
2.1

vielleicht war ich etwas voreilig in meiner Aussage aber
ohne Punkt aktualisiert es nicht alle HM-CC-RT-DN in der "rgBatterieStatus",
habe jetzt wie von dir empfohlen  0.0 statt "0.0" eingetragen und jetzt funktioniert mit
setreading Arbeitszimmer.DG.Fenster batteryLevel 2.0
Telegram und auch die Aktualisierung in der "rgBatterieStatus"
mal sehen wie sich das bei den Anderen verhält wenn es ein paar Tage so läuft...

Danke Uwe
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 12 Januar 2020, 13:05:34
Hast du (kürzlich) ein event-on-change-reading gesetzt!?

EDIT2: drum sind gelieferte list von Geräten immer hilfreich(er als einfach zu schreiben: jaja passt schon weil mit etc. ;)  ).

Weil, wenn nat. keine battery-Events kommen, dann gibt es in der readingsGroup auch keine Aktualisierung... ;)

Hat aber dann mit der Berechnung nichts zu tun...

EDIT: wenn die ReadingsVal-Abfrage MIT Punkt 0 liefert, dann wird der "Ersatzwert" (0.0) genommen, weil nat. das Reading nicht gefunden/ausgelesen werden kann. Wenn OHNE Punkt der richtige Wert kommt, dann ist OHNE Punkt alle mal besser... ;)

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: my-engel am 12 Januar 2020, 13:15:02
ZitatHast du (kürzlich) ein event-on-change-reading gesetzt!?

Ja, aber in einem ganz anderem Gerät was nichts mit Batterie und HM-CC-RT-DN zu tun hat...
in den Devices HM-CC-RT-DN steht niergendwo event-on-change-reading

Internals:
   DEF        356A8F
   FUUID      5c43081c-f33f-0edb-ea17-f26635cec50d8b40
   FVERSION   10_CUL_HM.pm:0.206330/2019-12-01
   HMUARTLGW_MSGCNT 626
   HMUARTLGW_RAWMSG 0500004E918610356A8F0000000A8CB7C70000
   HMUARTLGW_RSSI -78
   HMUARTLGW_TIME 2020-01-12 13:11:45
   IODev      MapleCUN_2.1
   LASTInputDev HMUARTLGW
   MSGCNT     1867
   MapleCUN_1.1_MSGCNT 606
   MapleCUN_1.1_RAWMSG A0F918610356A8F0000000A8CB7C70000::-95.5:MapleCUN_1.1
   MapleCUN_1.1_RSSI -95.5
   MapleCUN_1.1_TIME 2020-01-12 13:11:45
   MapleCUN_2.1_MSGCNT 635
   MapleCUN_2.1_RAWMSG A0F918610356A8F0000000A8CB7C70000::-59.5:MapleCUN_2.1
   MapleCUN_2.1_RSSI -59.5
   MapleCUN_2.1_TIME 2020-01-12 13:11:45
   NAME       Wohnzimmer.OG.FensterRechts
   NOTIFYDEV  global
   NR         57
   NTFY_ORDER 50-Wohnzimmer.OG.FensterRechts
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 Wohnzimmer.OG.FensterRechts_Weather
   channel_02 Wohnzimmer.OG.FensterRechts_Climate
   channel_03 Wohnzimmer.OG.FensterRechts_WindowRec
   channel_04 Wohnzimmer.OG.FensterRechts_Clima
   channel_05 Wohnzimmer.OG.FensterRechts_ClimaTeam
   channel_06 Wohnzimmer.OG.FensterRechts_remote
   lastMsg    No:91 - t:10 s:356A8F d:000000 0A8CB7C70000
   protLastRcv 2020-01-12 13:11:45
   protRcv    635 last_at:2020-01-12 13:11:45
   protRcvB   4 last_at:2020-01-12 09:02:44
   protSnd    3 last_at:2020-01-12 01:30:25
   protState  CMDs_done
   rssi_MapleCUN_2.1 cnt:1 min:-51 max:-51 avg:-51 lst:-51
   rssi_at_HMUARTLGW cnt:626 min:-85 max:-74 avg:-76.84 lst:-78
   rssi_at_MapleCUN_1.1 cnt:606 min:-100.5 max:-82 avg:-91.41 lst:-95.5
   rssi_at_MapleCUN_2.1 cnt:635 min:-69.5 max:-58.5 avg:-60.5 lst:-59.5
   READINGS:
     2020-01-11 11:04:10   Activity        alive
     2020-01-11 22:06:48   CommandAccepted yes
     2018-08-10 17:10:01   D-firmware      1.4
     2018-08-10 17:10:01   D-serialNr      LTK0135431
     2018-08-10 21:50:32   PairedTo        0x123456
     2018-08-10 21:50:32   R-backOnTime    10 s
     2018-08-10 21:50:32   R-btnLock       off
     2018-08-10 21:50:32   R-burstRx       on
     2018-08-10 21:50:32   R-cyclicInfoMsg on
     2018-08-10 21:50:32   R-cyclicInfoMsgDis 0
     2018-08-10 21:50:32   R-globalBtnLock off
     2018-08-10 21:50:32   R-localResDis   off
     2018-08-10 21:50:32   R-lowBatLimitRT 2.1 V
     2018-08-10 21:50:32   R-modusBtnLock  off
     2018-08-10 21:50:32   R-pairCentral   0x123456
     2020-01-12 13:11:45   actuator        0
     2020-01-12 13:11:45   battery         low
     2020-01-12 13:11:45   batteryLevel    2.2
     2020-01-12 09:02:44   controlMode     auto
     2020-01-12 13:11:45   desired-temp    17.5
     2020-01-12 13:11:45   measured-temp   18.3
     2020-01-12 13:11:45   motorErr        lowBat
     2018-08-10 21:25:15   sabotageAttack_ErrIoAttack cnt 2
     2020-01-12 01:30:25   state           CMDs_done
     2020-01-12 01:30:25   time-request    -
   helper:
     HM_CMDNR   145
     cSnd       ,11123456356A8F8004
     mId        0095
     peerFriend
     peerOpt    -:thermostat
     regLst     0
     rxType     140
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     io:
       newChn     +356A8F,00,00,00
       nextSend   1578831105.98144
       prefIO     
       rxt        2
       vccu       virtualCCU
       p:
         356A8F
         00
         00
         00
     mRssi:
       mNo        91
       io:
         HMUARTLGW:
           -78
           -78
         MapleCUL_1.1:
         MapleCUN_1.1:
           -95.5
           -95.5
         MapleCUN_2.1:
           -53.5
           -53.5
         MapleCUN_3.1:
     prt:
       bErr       0
       sProc      0
       sleeping   1
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       MapleCUN_2.1:
         avg        -51
         cnt        1
         lst        -51
         max        -51
         min        -51
       at_HMUARTLGW:
         avg        -76.8498402555909
         cnt        626
         lst        -78
         max        -74
         min        -85
       at_MapleCUN_1.1:
         avg        -91.4183168316832
         cnt        606
         lst        -95.5
         max        -82
         min        -100.5
       at_MapleCUN_2.1:
         avg        -60.5031496062992
         cnt        635
         lst        -59.5
         max        -58.5
         min        -69.5
     shRegW:
       07         04
     tmpl:
Attributes:
   IODev      MapleCUN_2.1
   IOgrp      virtualCCU
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     1_allReg
   firmware   1.4
   icon       sani_heating
   model      HM-CC-RT-DN
   room       Obergeschoss->Wohnzimmer
   serialNr   LTK0135431
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit


Gruß Uwe
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 12 Januar 2020, 13:20:44
Hi Uwe,

hmm, eigenartig...
...weil ja die Readings erst aktualisiert wurden...

Gut, ich benutze (immer noch) "meinen" Ursprungscode...
Aber der ist im Kern gleich...

Und tut nach wie vor...
(habe erst heute eine Telegram-Nachricht bzgl. Batteriewechsel bekommen, gut es war kein Heizkörpertermostat sondern ein Homematic Wandthermostat aber die sind ja bzgl. "battery" gkeich)

Anmerkung: zukünftig lists besser in "code-Tags", das '#' im "Menü"... ;)

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: my-engel am 12 Januar 2020, 14:47:26
Hallo Joachim,

habe wieder gleichen Stand wie vorher, auch 0.0 statt "0.0" bringt nichts.
Bin nun wieder auf Ursprungscode.
Es verhält sich so als ob irgendwo event-on-change-reading gesetzt wäre.
Ich finde nur keine Attribute. Um beim Bsp.-Device zu bleiben:
setreading Wohnzimmer.OG.FensterRechts batteryLevel 2.0
Telegram und "rgBatterieStatus" funktionieren,
dann warten bis automatisch das Device seine Readings bekommt und auch dann funktioniert "rgBatterieStatus".
Alle weiteren Readings werden im Device also im Wohnzimmer.OG.FensterRechts - HM-CC-RT-DN aktualisiert
aber nicht in die readingGroup "rgBatterieStatus" übertragen...
hast Du hier noch eine Idee?

MfG Uwe
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 12 Januar 2020, 14:58:23
Das mit "0.0" und 0.0 ist "egal", Perl ist da (leider ;)  ) ziemlich tolerant...
Es wäre nur "korrekter" weil es ja um numerische Werte statt um Zeichenketten geht ;)

Hmm, einzig was ich so mitbekommen habe ist, dass irgendwann mal bei ReadingsGroup "etwas" bzgl. Events etc. umgebaut wurde aber mittlerweile wieder laufen soll(te)...

Und wie geschrieben: bei mir kein Problem.

Du kannst ja mal den Eventmonitor öffnen und einen Filter setzen und sehen, ob entsprechende Events bzgl. battery kommen...

Wenn die kommen, dann höchstens das Notify was ja die Berechnungsroutine anwirft prüfen, ob das triggert...

EDIT: wobei wenn das mittels setzen durch setreading tut... Dann sollte das ja gehen...

Wenn die Events nicht kommen, dann eben prüfen warum nicht.
Sehe aber aktuell nichts...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: sepultura30 am 12 Januar 2020, 22:05:43
Zitat von: MadMax-FHEM am 12 Januar 2020, 12:08:50
Hmmm, kann ich nicht nachvollziehen...

Habt ihr kürzlich (also unter 3 Wochen) ein fhem Update gemacht?

Gruß, Joachim

Hallo Joachim,

ich mache täglich Updates und hier mal das Readings wie es bei mir ist.


setstate Thermostat_Ess CMDs_done
setstate Thermostat_Ess 2019-01-20 21:40:35 .D-devInfo 00FFFF
setstate Thermostat_Ess 2019-01-20 21:40:35 .D-stc 59
setstate Thermostat_Ess 2017-11-22 17:35:35 .R-btnLock off
setstate Thermostat_Ess 2017-11-22 17:35:35 .R-globalBtnLock off
setstate Thermostat_Ess 2017-11-22 17:35:35 .R-localResDis off
setstate Thermostat_Ess 2020-01-10 22:40:10 .R-lowBatLimitRT 2.4 V
setstate Thermostat_Ess 2017-11-22 17:35:35 .R-modusBtnLock off
setstate Thermostat_Ess 2020-01-12 22:04:35 .protLastRcv 2020-01-12 22:04:35
setstate Thermostat_Ess 2020-01-12 11:20:44 Activity alive
setstate Thermostat_Ess 2020-01-10 22:40:08 CommandAccepted yes
setstate Thermostat_Ess 2019-01-20 21:40:35 D-firmware 1.4
setstate Thermostat_Ess 2019-01-20 21:40:35 D-serialNr OEQ0855361
setstate Thermostat_Ess 2020-01-10 22:40:10 PairedTo 0x945612
setstate Thermostat_Ess 2017-11-22 17:35:35 R-backOnTime 10 s
setstate Thermostat_Ess 2017-11-22 17:35:35 R-burstRx on
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 12 Januar 2020, 22:32:39
Würdest du bitte (wie geschrieben) ein list posten!?

So sehe ich zwar, dass die Readings (bei dir) so heißen aber so kann man keine Idee entwickeln: warum

Weil ich auch nichts gelesen hätte, dass da etwas geändert wurde...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: FunkOdyssey am 13 Januar 2020, 00:00:20
Zitat von: DeeSPe am 31 Oktober 2019, 10:18:05
Ja, es liegt daran dass das notify auf battery, batteryLevel und batteryPercent reagiert.
Ändere doch einfach den Trigger des notify:
define NO.BatterieNotify notify .*:(battery|batteryLevel)\s.* {BatteryStatusFunction($NAME, $EVENT)}

Gruß
Dan

Oh Mist. Ich merke jetzt gerade erst, dass der gesamte Notify mit dieser Änderung seit Monaten nicht mehr funktioniert. Ich habe anstatt \s.* auch ein einfaches $ ausprobiert. Alles ohne Erfolg.

Hast du noch einen Tipp? Danke.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 13 Januar 2020, 00:17:39
Also ich habe ein Notify auf "nur" battery.*

Weil doch meist also zumindest bei mir die Geräte:

battery
batteryPercent
batteryValue
...

haben.
Und (zumindest bei mir) auch immer zusammen kommen, slso sollte ein Device mehrere "Batterie-Readings" haben (eigentl. haben bei mir alle Devices mind. 2 davon)...

Zu viel auslösen/berechnen schränke ich dann bei den Devices mittels event-on-change-reading so ein, dass aber immer noch aktuelle Werte in der ReadingsGroup angezeigt werden...

Mehr Tipp fällt mir nicht ein...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: sepultura30 am 13 Januar 2020, 12:21:26
Zitat von: MadMax-FHEM am 12 Januar 2020, 22:32:39
Würdest du bitte (wie geschrieben) ein list posten!?

So sehe ich zwar, dass die Readings (bei dir) so heißen aber so kann man keine Idee entwickeln: warum

Weil ich auch nichts gelesen hätte, dass da etwas geändert wurde...

Gruß, Joachim

Hallo Joachim,

wie gewünscht das list vom Device :)


Internals:
   DEF        5B0461
   FUUID      5c44ee7a-f33f-784a-1fe6-292cd529b2de6cb8
   IODev      myHmUART
   LASTInputDev myHMLANGW
   MSGCNT     51
   NAME       WandThermWohn
   NOTIFYDEV  global
   NR         122
   NTFY_ORDER 50-WandThermWohn
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 WandThermWohn_Weather
   channel_02 WandThermWohn_Climate
   channel_03 WandThermWohn_WindowRec
   channel_06 WandThermWohn_remote
   channel_07 WandThermWohn_SwitchTr
   lastMsg    No:06 - t:70 s:5B0461 d:000000 00DC23
   myHMLANGW_MSGCNT 17
   myHMLANGW_RAWMSG 050000300684705B046100000000DC23
   myHMLANGW_RSSI -48
   myHMLANGW_TIME 2020-01-13 12:18:57
   myHmUART_MSGCNT 17
   myHmUART_RAWMSG 050000320684705B046100000000DC23
   myHmUART_RSSI -50
   myHmUART_TIME 2020-01-13 12:18:57
   myRemoteHmUART_MSGCNT 17
   myRemoteHmUART_RAWMSG 0500003C0684705B046100000000DC23
   myRemoteHmUART_RSSI -60
   myRemoteHmUART_TIME 2020-01-13 12:18:57
   protLastRcv 2020-01-13 12:18:57
   protRcv    17 last_at:2020-01-13 12:18:57
   rssi_at_myHMLANGW cnt:17 min:-49 max:-47 avg:-48.05 lst:-48
   rssi_at_myHmUART cnt:17 min:-50 max:-48 avg:-49.47 lst:-50
   rssi_at_myRemoteHmUART cnt:17 min:-62 max:-60 avg:-61.05 lst:-60
   .attraggr:
   .attrminint:
     state:900
   Helper:
     DBLOG:
       desired-temp:
         myDbLog:
           TIME       1578914036.72651
           VALUE      22.0
       measured-temp:
         myDbLog:
           TIME       1578914036.72651
           VALUE      22.0
   READINGS:
     2020-01-11 02:39:04   .R-btnLock      off
     2020-01-11 02:39:04   .R-globalBtnLock off
     2020-01-11 02:39:04   .R-localResDis  off
     2020-01-12 01:31:15   .R-lowBatLimitRT 2.4 V
     2020-01-11 02:39:04   .R-modusBtnLock off
     2020-01-13 12:18:57   .protLastRcv    2020-01-13 12:18:57
     2020-01-13 12:00:52   Activity        alive
     2020-01-13 10:00:03   CommandAccepted yes
     2020-01-11 02:38:07   D-firmware      1.3
     2020-01-11 02:38:07   D-serialNr      OEQ0760983
     2020-01-13 01:14:29   LastLowBattMailSent 1
     2020-01-13 01:19:24   PairedTo        0x945612
     2020-01-11 02:39:04   R-burstRx       on
     2020-01-11 02:39:04   R-cyclicInfoMsg on
     2020-01-11 02:39:04   R-cyclicInfoMsgDis 0
     2020-01-11 02:39:04   R-pairCentral   0x945612
     2020-01-13 01:19:24   RegL_00.        00:00 01:01 02:01 09:01 0A:94 0B:56 0C:12 0F:00 11:00 12:18 16:00 18:00 19:00 1A:00
     2020-01-13 12:00:38   RegL_07.       
     2020-01-13 12:13:56   battery         ok
     2020-01-13 12:13:56   batteryLevel    3.2
     2020-01-13 12:13:56   desired-temp    22.0
     2020-01-13 12:13:56   measured-temp   22.0
     2020-01-13 01:19:18   powerOn         2020-01-13 01:19:18
     2020-01-13 01:19:18   recentStateType info
     2020-01-13 10:00:04   state           CMDs_done
     2020-01-13 01:19:20   time-request    -
   helper:
     HM_CMDNR   6
     PONtest    1
     mId        00AD
     peerFriend
     peerOpt    -:thermostat
     regLst     0
     rxType     6
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +5B0461,00,01,00
       nextSend   1578914338.03532
       prefIO     
       rxt        0
       vccu       VCCU
       p:
         5B0461
         00
         01
         00
     mRssi:
       mNo        06
       io:
         myHMLANGW:
           -48
           -48
         myHmUART:
           -44
           -44
         myRemoteHmUART:
           -60
           -60
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       at_myHMLANGW:
         avg        -48.0588235294118
         cnt        17
         lst        -48
         max        -47
         min        -49
       at_myHmUART:
         avg        -49.4705882352941
         cnt        17
         lst        -50
         max        -48
         min        -50
       at_myRemoteHmUART:
         avg        -61.0588235294118
         cnt        17
         lst        -60
         max        -60
         min        -62
     shRegW:
       07         02
     tmpl:
Attributes:
   .mId       00AD
   IODev      myHmUART
   IOgrp      VCCU
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   event-min-interval state:900
   expert     2_raw
   firmware   1.3
   icon       hm-tc-it-wm-w-eu
   model      HM-TC-IT-WM-W-EU
   msgRepeat  1
   room       Esszimmer,Heizung,Wohnzimmer
   serialNr   OEQ0760983
   subType    thermostat
   webCmd     getConfig:clear msgEvents
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 13 Januar 2020, 13:11:48
Also zunächst mal: danke! ;)

Dann: komisch ist, dass einige "Register-Readings" (gekennzeichnet durch R-...) OHNE Punkt und andere wiederum MIT Punkt da sind.

Normal war (ist denke ich immer noch): OHNE Punkt!

Daher mal ergründen (neuer Thread in Homematic) WARUM das bei dir so ist...
(evtl. mache ich mal ein Update und schaue, ob das bei mir dann auch so kommt / denke aber, dass man davon schon mehr gelesen hätte, wenn?)


Und dann werde ich selbst aus der Beschreibung bzgl. event-min-interval nicht so ganz schlau...
Nutze nur event-on-change-reading...

Aber könnte es sein, dass event-min-interval NUR auf state OHNE event-on-change-reading etc. dazu führt, dass eben nur noch Events für state kommen!?
https://wiki.fhem.de/wiki/Event-min-interval

Schon mal den Eventmonitor geöffnet!?

Oder ging es bei dir "nur" um die Berechnung? ;)
(Bei so viel "Durcheinander" kann man schon mal was aus dem Auge verlieren ;)  )

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 13 Januar 2020, 15:44:36
Zitat von: MadMax-FHEM am 13 Januar 2020, 13:11:48
Dann: komisch ist, dass einige "Register-Readings" (gekennzeichnet durch R-...) OHNE Punkt und andere wiederum MIT Punkt da sind.
Nix komisch, war bei mir schon immer so :)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 13 Januar 2020, 16:00:07
Zitat von: Wzut am 13 Januar 2020, 15:44:36
Nix komisch, war bei mir schon immer so :)

Und was heißt immer!?
Ab wann/wie lange schon immer? ;)

EDIT: auch "gemischt" oder alle mit/ohne Punkt!?

Also bei mir (und wohl den Meisten, zumindest die lists die ich gesehen habe ;) ) noch nie so...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Wzut am 13 Januar 2020, 16:25:23
puhh , ja wann habe ich mir den HM-CC-RT-DN gekauft ... ??? die ältesten Readings sind vom August 2018, könnte hinkommen.

Punkt gewinnt mit 6:5 :)
2018-08-07 07:47:23   .R-btnLock      off
2018-08-07 07:47:23   .R-globalBtnLock off
2018-08-07 07:47:23   .R-localResDis  off
2018-08-07 07:47:23   .R-lowBatLimitRT 2 V
2018-08-07 07:47:23   .R-modusBtnLock off
2020-01-13 16:17:48   .protLastRcv    2020-01-13 16:17:48

2018-08-07 07:47:23   R-backOnTime    10 s
2018-08-07 07:47:23   R-burstRx       on
2018-08-07 07:47:23   R-cyclicInfoMsg on
2018-08-07 07:47:23   R-cyclicInfoMsgDis 0
2018-08-07 07:47:23   R-pairCentral   0x230960
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 13 Januar 2020, 17:00:42
Danke!

Hmmm...

Ich denke ich werde mal im Homematic Forum die Frage stellen ;)

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: FunkOdyssey am 13 Januar 2020, 17:24:43
Zitat von: MadMax-FHEM am 13 Januar 2020, 00:17:39
Also ich habe ein Notify auf "nur" battery.*

Weil doch meist also zumindest bei mir die Geräte:

battery
batteryPercent
batteryValue
...

haben.
Und (zumindest bei mir) auch immer zusammen kommen, slso sollte ein Device mehrere "Batterie-Readings" haben (eigentl. haben bei mir alle Devices mind. 2 davon)...

Zu viel auslösen/berechnen schränke ich dann bei den Devices mittels event-on-change-reading so ein, dass aber immer noch aktuelle Werte in der ReadingsGroup angezeigt werden...

Mehr Tipp fällt mir nicht ein...

Gruß, Joachim

Ich versuche nun folgende Schreibweise (Doppelpunkt ergänzt) und warte auf das Event.
.*:(battery|batteryLevel):\s.* {BatteryStatusFunction($NAME, $EVENT)}
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: sepultura30 am 13 Januar 2020, 22:20:56
Zitat von: MadMax-FHEM am 13 Januar 2020, 13:11:48
Also zunächst mal: danke! ;)

Dann: komisch ist, dass einige "Register-Readings" (gekennzeichnet durch R-...) OHNE Punkt und andere wiederum MIT Punkt da sind.

Normal war (ist denke ich immer noch): OHNE Punkt!

Daher mal ergründen (neuer Thread in Homematic) WARUM das bei dir so ist...
(evtl. mache ich mal ein Update und schaue, ob das bei mir dann auch so kommt / denke aber, dass man davon schon mehr gelesen hätte, wenn?)


Und dann werde ich selbst aus der Beschreibung bzgl. event-min-interval nicht so ganz schlau...
Nutze nur event-on-change-reading...

Aber könnte es sein, dass event-min-interval NUR auf state OHNE event-on-change-reading etc. dazu führt, dass eben nur noch Events für state kommen!?
https://wiki.fhem.de/wiki/Event-min-interval

Schon mal den Eventmonitor geöffnet!?

Oder ging es bei dir "nur" um die Berechnung? ;)
(Bei so viel "Durcheinander" kann man schon mal was aus dem Auge verlieren ;)  )

Gruß, Joachim

Hallo Joachim,

mir gings nur um die Berechnung, mehr nicht und ich habe dein Script noch erweitert, so das man nur einmal am Tag eine Nachricht per TelegramBot bekommt.

Grüße

Sandro
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 18 Januar 2020, 11:37:51
Da ich leider nicht im Kopf habe welches Gerät nun welche Batterie (und wieviele davon) braucht habe ich meinen Code und meine Batterie-Geräte etwas erweitert...

Und weil das was ich nutze ja hier mal Basis war dachte ich vielleicht auch hierfür interessant ;)

Also ich habe jedem meiner Batterie-Geräte mittels userattr ein Attribut my_batteryType verpasst und dann eben das Attribut my_batteryType mit dem Batterie-Typ und Anzahl gesetzt.

Beispiel:

Zitat von: list
Internals:
   DEF        697334
   FUUID      5c573a6f-f33f-753d-961e-90a6d3d04ef7910a
   IODev      hmusb
   NAME       Briefkasten
   NOTIFYDEV  global
   NR         522
   NTFY_ORDER 50-Briefkasten
   STATE      open
   TYPE       CUL_HM
   chanNo     01
   READINGS:
     2020-01-05 21:17:54   Activity        dead
     2019-01-18 16:14:19   CommandAccepted yes
     2019-01-18 17:03:36   D-firmware      1.0
     2019-01-18 17:03:36   D-serialNr      PEQ0580746
     2019-01-18 16:14:20   PairedTo        0xAFFE11
     2019-01-18 16:13:40   R-cyclicInfoMsg on
     2019-01-18 16:13:40   R-eventDlyTime  0 s
     2019-01-18 16:13:40   R-msgScPosA     open
     2019-01-18 16:13:40   R-msgScPosB     closed
     2019-01-18 16:13:40   R-pairCentral   0xAFFE11
     2019-01-18 16:13:40   R-sabotageMsg   on
     2019-01-18 16:14:20   R-sign          off
     2019-01-18 16:13:40   R-transmDevTryMax 6
     2019-01-18 16:13:40   R-transmitTryMax 6
     2019-01-18 16:14:19   aesCommToDev    ok
     2019-01-18 16:14:19   aesKeyNbr       00
     2019-01-18 17:23:10   alive           yes
     2019-01-18 17:23:10   battery         ok
     2019-01-18 17:23:10   contact         open (to vccu)
     2019-01-18 17:23:10   recentStateType info
     2019-01-18 17:23:10   sabotageError   on
     2019-01-18 17:23:10   state           open
     2019-01-18 17:23:07   trigger_cnt     242
   helper:
     HM_CMDNR   179
     mId        00C7
     peerFriend peerAct,peerVirt
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     28
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     io:
       newChn     +697334,00,00,00
       rxt        2
       vccu       vccu
       p:
         697334
         00
         00
         00
       prefIO:
         hmusb
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     tmpl:
Attributes:
   IODev      hmusb
   IOgrp      vccu:hmusb
   actCycle   002:50
   actStatus  dead
   autoReadReg 4_reqStatus
   expert     1_allReg
   firmware   1.0
   icon       message_mail
   model      HM-SEC-SCO
   my_batteryType 1xAAA
   peerIDs    00000000,
   serialNr   PEQ0580746
   subType    threeStateSensor
   userattr   my_batteryType

Aber VORSICHT beim Anwenden von userattr!
Gerade, wenn man das für mehrere Geräte/Devices in fhem per devSpec setzt!
(also z.B. attr battery=..* userattr my_batteryType / d.h. das userattr für alle Devices setzen, die "irgendwas mit battery haben")
Ich mache das immer nur bei den Geräten wo ich das brauche und ich nenne "meine" Attribute auch immer my_Irgendwas...

Es ist "umständlicher" aber damit nehme ich so wenig Einfluss wie möglich.

Einfachere Alternative: userattr unter global erweitern. Dann gibt es das Attribut halt für alle Geräte... ;)


So nun wozu das:

Ich habe dann eben zusätzlich die Abfrage des Batterie-Typs eingebaut (dort wo eben berechnet wird, wie der Zustand ist und gegebenenfalls eine Nachricht verschickt wird):


$BatteryType = AttrVal($Device, "my_batteryType", "unknown");


und beim senden gebe ich dann eben neben dem Device-Namen ($Device) auch noch den notwendigen Batterie-Typ inkl. Anzahl mit (also das was halt im Attribut my_batteryType steht)...

Noch ungetestet (nächster Wechsel steht aber demnächst an, dann werde ich ja sehen), sollte aber funktionieren... ;)

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: kotaro am 25 Februar 2020, 15:29:41
Hallo,

leier bin ich erst jetzt auf dieses tolle Projekt gestoßen.
Dazu wollte ich mal fragen, ob ihr Homematic und Homematic IP-Gerät über HMCCU integriert habt?

habe mal durchgesehen, und die typischen Readings sind:

 
   
   
   
   
   
HMIPHomematic
HKT0.OPERATING_VOLTAGE
0.LOW_BAT
4.BATTERY_STATE
0.LOWBAT
WT0.OPERATING_VOLTAGE
0.LOW_BAT
2.BATTERY_STATE
0.LOWBAT
Tür/Fenster0.OPERATING_VOLTAGE
0.LOW_BAT
0.LOWBAT
Wassersensor0.LOWBAT


und folgende Internals:
HMIP
ccuif: HmIP-RF
HM:
ccuif: BidCos-RF

Also bei HMIP mit OPERATING_VOLTAGE ist wie der Name schon sagt, die akutelle Spannung gelistet, bei LOW_BAT gibt es ein true oder false...
bei Homematic mit BATTERY_STATE das gleiche --> Spannung, LOWBAT der Wert, ob true oder false

Vielleicht wisst ihr mehr?? in der Github-Datei von 2018 finde ich diese nicht hinterlegt.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 25 Februar 2020, 15:54:57
Zitat von: kotaro am 25 Februar 2020, 15:29:41
Vielleicht wisst ihr mehr?? in der Github-Datei von 2018 finde ich diese nicht hinterlegt.

Dann wird das wohl noch nicht drin sein...

Aber du kannst "einfach" einen bestehenden Homematic-Teil (kopieren und einfügen und dann) abändern, also die Geräte die nur low/ok liefern bzw. die bei denen Spannungswerte kommen.

Ist ja für beide bei Homematic was vorhanden.

Ansonsten mal besser 2 lists, eines von einem mit "nur" low/ok und einem mit Spannungsanzeige...
...dazu nat. wichtig wieviel Spannung "voll" ist (verm. auch 3,0V bzw. 3,2V) und wo steht wann das Gerät "aus geht"...

Bei den bestehenden Homematic ist es wie folgt:

2x1,5V Batterie macht 3,0V (oder 3,2V weil es ist schon mal "mehr drin")
und im Register-Reading "R-lowBatLimitRT" steht wann "Ende ist", da müsstest du halt sehen wo man das bei "deinen" Geräten sehen kann...

Wenn du (erfolgreich) geändert hast, dann "zurück-teilen" :)

Mit den gelieferten lists kann es Amenophis86 versuchen einzupflegen...

Mittlerweile habe ich einige Änderungen bzgl. den Homematic-Fenstersensoren optisch vorgenommen, da diese sehr lange dazu neigen zwischen low und ok zu springen...
...muss ich auch mal posten, vielleicht kann es ja verwendet werden.

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Aladin222 am 08 März 2020, 11:23:22
Hallo @all,

endlich Wochenende und ich kann mal schauen und testen :-)
Leider bekomme ich die Benachrichtigung bei leeren Batterien nicht gebacken ....

list BatterieStatus

Internals:
   CFGFN     
   FUUID      5e64c2d8-f33f-9117-d425-0cc980ad08f16507
   NAME       BatterieStatus
   NR         2432
   STATE      ???
   TYPE       dummy
   READINGS:
     2020-03-08 11:03:04   BadTaster       100
     2020-03-08 11:03:04   Bad_UG          100
     2020-03-08 11:03:04   EZ_Taster       100
     2020-03-08 11:03:04   FensterKontaktBadOG 100
     2020-03-08 11:03:04   FensterKontaktBadUG 100
     2020-03-08 11:03:04   FensterKontaktEsszimmer 100
     2020-03-08 11:03:04   FensterKontaktGaeste 100
     2020-03-08 11:03:04   FensterKontaktKuecheL 100
     2020-03-08 11:03:04   FensterKontaktKuecheR 100
     2020-03-08 11:03:04   FensterKontaktSchlafz1 100
     2020-03-08 11:03:04   FensterKontaktSchlafz2 100
     2020-03-08 11:03:04   FensterKontaktTGriff 100
     2020-03-08 11:03:04   FensterKontaktTerrasse 100
     2020-03-08 11:03:04   FensterKontaktTimo 100
     2020-03-08 11:03:04   FensterKontaktWz 100
     2020-03-08 11:03:04   GaesteZimmer    100
     2020-03-08 11:03:04   HeizungBadOG    100
     2020-03-08 11:03:04   HeizungBadUG    100
     2020-03-08 11:03:04   HeizungSZ       100
     2020-03-08 11:03:04   HeizungWzL      100
     2020-03-08 11:03:04   HeizungWzR      30
     2020-03-08 11:03:04   Kueche          100
     2020-03-08 11:03:04   NUKIDevice355445389 100
     2020-03-08 11:03:04   SchlafZimmer    100
     2020-03-08 11:03:04   Schuppen        100
     2020-03-08 11:03:04   SturzTemp       100
     2020-03-08 11:03:04   Sturz_Taster    100
     2020-03-08 11:03:04   TerrasseTemp    100
     2020-03-08 11:03:04   Timo            100
     2020-03-08 11:03:04   WasserMelder    100
     2020-03-08 11:03:04   WohnZimmer      100
     2020-03-08 11:03:04   WzWandthermostat 100
Attributes:
   DbLogExclude .*
   room       Z_System->BatteryCheck


Somit sollte sich doch HeizungWzR melden ,oder ? Dazu stellt sich mir echt die Frage das der STATE "3 Fragezeichen" hat ...

list BatterieWechsel

Internals:
   CFGFN     
   FUUID      5e64c2d8-f33f-9117-a952-1c4923ac9edc06cc
   NAME       BatterieWechsel
   NR         2433
   STATE      ???
   TYPE       dummy
Attributes:
   DbLogExclude .*
   room       Z_System->BatteryCheck

Ist für mich ok , da er noch keinen Batteriewechsel mitbekommen hat ...

in 99_BatterieCheckUtils

################################
# Here you choos your message device and how to send
# comment the device you do not want to use
#
# TelegramBot
# my $msg = "set WEB_TelegramBot message \@\@User ";
#
# msg-command
# my $msg = "msg \@User title='Battery Check' ";
#
# Pushover
  my $msg = "set WEB_Pushover msg device= Aladin212Iphone title='Battery Check' ";




list WEB_Pushover


Internals:
   APP_TOKEN  ajhgjhghghgjhkj5kud
   CFGFN      /opt/fhem/FHEM/02_Messager.cfg
   DEF        agajhjhjgjhjhhkjktL1toHM
   FUUID      5cc3eb02-f33f-9117-0015-b7b9261af6482a0c
   FVERSION   70_Pushover.pm:v2.2.0-s20897/2020-01-06
   NAME       WEB_Pushover
   NR         452
   STATE      connected
   TYPE       Pushover
   USER_KEY   urMbkhkjsdhkjsddsgoHM
   VALIDATION_TIMER 1583684445.80531
   READINGS:
     2020-03-08 08:58:40   apiLimit        7500
     2020-03-08 08:58:40   apiRemaining    7494
     2020-03-08 08:58:40   apiReset        1585717200
     2020-03-08 11:20:45   available       1
     2019-06-03 07:32:03   devices         Aladin212iPad,Aladin212Iphone,ipad_pro,TimoIphone
     2019-04-27 07:39:20   group           0
     2020-03-08 08:58:40   lastAction      -
     2020-03-08 08:58:40   lastDevice      Aladin212iPad,Aladin212Iphone,ipad_pro,TimoIphone
     2020-03-08 08:58:40   lastMessage     Morgen wird  Abfuhrtermin Biotonne (BRAUN) abgeholt
     2020-03-08 08:58:40   lastRequest     fd57d46e-622b-4a31-9b86-8a31d4079775
     2020-03-08 11:20:45   lastResult      ok
     2020-03-08 08:58:40   lastTitle       Müll
     2020-03-08 11:20:45   state           connected
     2019-04-27 07:39:20   tokenState      valid
     2019-04-27 07:39:20   userState       valid
Attributes:
   DbLogExclude .*
   alias      Pushover
   icon       pushover



Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 08 März 2020, 12:08:50
So wie ich das lese erst ab/unter 25%:

Zitat von: Erläuterung erster Post
4. Das Script verschickt eine Nachricht, sobald der Status einer Batterie 25% erreicht, oder leer meldet

Du hast aber ja 30% ;)

Ein Device hat solange die drei Fragezeichen, solange noch kein set Device irgendwas erfolgt ist...
...wird evtl. hier auch nie passieren (nutze nicht genau diese "Implementierung" sondern immer noch "meine eigene" [die mal Basis war] / daher: bzgl. "gehen die 3 Fragezeichen weg" nur Vermutung hier ;) )

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Aladin222 am 08 März 2020, 14:03:25
Hi  MadMax ,

Danke für deine Rückmeldung ... ja das List ist neu ...hatte nochmal neu eingebunden !
Der Batteriestand ist 0 ...
Dauert ja ein wenig bis er auf 25% fällt ... komisch ist nur , es funktioniert nun !
Nachdem der Batteriestand weiter fiel ,kam nun auch die Push ... also war es gut alles nochmal neu zu definieren :-)

Danke !
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Betonklotz am 27 März 2020, 09:37:47
Hallo,

habe das Modul im Grunde sauber installiert (kleine Anmerkung für Seite 1: evtl. noch ein prüfen der Rechte ergänzen, das hatte ich in der Eile vergessen...), bekomme aber im Log immer alle paar Sekunden Meldungen in der Art

EG_Schlafzimmer_Heizung_HM2E7xxx, 'battery: ok' ignored, has batteryLevel reading
EG_BadRobert_Heizung_HM535xxx, 'battery: ok' ignored, has batteryLevel reading
EG_Wohnzimmer_Heizung_HM535xxx, 'battery: ok' ignored, has batteryLevel reading

Was habe ich falsch gemacht, bzw. wie kann ich es unterdrücken? Was braucht ihr ggf. zur Eingrenzung des Fehlers? Und finde ich (z.B. in einer readingsgroup) das Datum wann die Batterien zuletzt gewechselt wurden (=müsste bei mir ja das aktuelle Datum oder ??? sein)?

Gruß, Robert
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: FunkOdyssey am 27 März 2020, 10:00:16
Das ist doch okay.
Kannst du nicht das Loglevel ändern? Ganz oben im Quellcode.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 27 März 2020, 10:02:54
Zitat von: Betonklotz am 27 März 2020, 09:37:47
Hallo,

habe das Modul im Grunde sauber installiert (kleine Anmerkung für Seite 1: evtl. noch ein prüfen der Rechte ergänzen, das hatte ich in der Eile vergessen...), bekomme aber im Log immer alle paar Sekunden Meldungen in der Art

EG_Schlafzimmer_Heizung_HM2E7xxx, 'battery: ok' ignored, has batteryLevel reading
EG_BadRobert_Heizung_HM535xxx, 'battery: ok' ignored, has batteryLevel reading
EG_Wohnzimmer_Heizung_HM535xxx, 'battery: ok' ignored, has batteryLevel reading

Was habe ich falsch gemacht, bzw. wie kann ich es unterdrücken? Was braucht ihr ggf. zur Eingrenzung des Fehlers? Und finde ich (z.B. in einer readingsgroup) das Datum wann die Batterien zuletzt gewechselt wurden (=müsste bei mir ja das aktuelle Datum oder ??? sein)?

Gruß, Robert

Für ersteres "Problem" kenne ich den aktuellen Code zu wenig...


Den Tausch siehst du (zumindest ist das bei meiner "Basis-SW" so) erst NACH einem Wechsel.
Also: Batterie war mal "low" etc. und ist dann wieder "ok" etc.

Was helfen könnte (sollte) bei einem Gerät welches "nur" battery ok/low hat ein:

setreading Gerätename battery low

dann sollte die Nachricht kommen...
...und beim nächsten Update vom Gerät (das muss halt zyklisch senden) wird ja dann wieder "ok" gesetzt (weil die Batterie ja tatsächlich ok ist ;)  )...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Betonklotz am 27 März 2020, 11:02:03
Hallo,

@FunkOdyssey: grrrr, sehe ich erst jetzt. Frage mich warum das nicht im Block "bitte ändern/prüfen" mit drin ist. Aber im Grunde werden nur Logs 1 & 3 genutzt, d.h. wichtige Sachen wie "Batterie" ist leer steht dann nicht mehr im Log.
@Joachim: danke dir.

@all: muss mir den Quellcode aber eh mal ansehen, das Script triggert zusätzlich auch auf meine USV.

USV, unknown Event battery.runtime: 3418

==> werde das Script mal als Vorlage am Wochenende nutzen und mir darauf basierend was basteln.

Danke und Gruß,

Robert
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: jeti am 27 März 2020, 11:25:08
Hallo zusammen,
ich habe das script gefunden, klasse Arbeit!
Natürlich habe ich es gleich eingesetzt. Soweit sieht es auch gut aus. Meine Z-Wave Thermostate werden korrekt erkannt und das Batterie Level dementsprechend ermittelt.
Nun zu meinem Problem:
meine Zigbee (über MQTT) also vom TYPE MQTT2_DEVICE haben jeweils das reading "battery" und werde auch erkannt, nur wird der battery Wert (0-100) nicht korrekt ermittelt und bei allen "0" angezeigt.
Eigentlich sollte das doch out of the box funktionieren?
Anbei eines meiner MQTT2_DEVICES.

Wo kann hier der Fehler liegen?

Danke und Gruß
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: FunkOdyssey am 27 März 2020, 11:32:49
Ich habe in letzter Zeit viele kleine Änderungen im Code vorgenommen.
Im Code wird viel das batteryLevel abgefragt. Und gelegentlich nur das battery-Reading mit den Strings ok, low, etc.

Viele meiner Geräte wie bspw. ZWave und Zigbee nutzen neuerdings das Reading batteryPercent.
Homematic wird wohl weiterhin eine Sonderlösung bleiben. Und LaCrosse und MAX! haben auch kein batteryPercent-Reading.

Theoretisch könnte man den Code weiter generalisieren und die Unterscheidungen nach Gerätetyp entfernen, wenn das Reading batteryPercent existiert.
Wenn sich das in FHEM nun durchsetzt, so dürfte die Batterieüberwachung irgendwann viel einfacher werden.
Ich bin aber froh, dass es diesen Code gibt.

Soll das hier https://github.com/Amenophis86/Batteryfunktion/tree/no-BatteryStatusBot eigentlich noch weiterentwickelt werden?
Im Thread sehe ich viele neue Beispiele, die noch nicht implementiert wurden.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: jeti am 27 März 2020, 12:18:28
Ich finde das Script sehr wertig und eine Weiterentwicklung würde mich sehr freuen :)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 27 März 2020, 13:31:03
Zitat von: FunkOdyssey am 27 März 2020, 11:32:49
Ich habe in letzter Zeit viele kleine Änderungen im Code vorgenommen.
Im Code wird viel das batteryLevel abgefragt. Und gelegentlich nur das battery-Reading mit den Strings ok, low, etc.

Viele meiner Geräte wie bspw. ZWave und Zigbee nutzen neuerdings das Reading batteryPercent.
Homematic wird wohl weiterhin eine Sonderlösung bleiben. Und LaCrosse und MAX! haben auch kein batteryPercent-Reading.

Theoretisch könnte man den Code weiter generalisieren und die Unterscheidungen nach Gerätetyp entfernen, wenn das Reading batteryPercent existiert.
Wenn sich das in FHEM nun durchsetzt, so dürfte die Batterieüberwachung irgendwann viel einfacher werden.

Es gibt/gab ja auch mal Versuche das zu vereinheitlichen: https://forum.fhem.de/index.php/topic,87575.msg800017.html#msg800017

Ich glaube auch, dass es ins "Best Practice" für Modulentwickler eingeflossen ist...
...und einige auch schon umgestellt haben...
...andere wiederum nicht...
...und leider halten sich manche neue Module auch nicht dran (ist ja kein Zwang)...



Zitat von: FunkOdyssey am 27 März 2020, 11:32:49
Ich bin aber froh, dass es diesen Code gibt.

Soll das hier https://github.com/Amenophis86/Batteryfunktion/tree/no-BatteryStatusBot eigentlich noch weiterentwickelt werden?
Im Thread sehe ich viele neue Beispiele, die noch nicht implementiert wurden.

Ja vielen Dank noch mal an Amenophis86 den Code übernommen und so weit gebracht zu haben!!

Leider weiß ich bzgl. aktuellem Stand nichts...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: FunkOdyssey am 27 März 2020, 13:33:01
Wie wäre es denn, wenn wir den Code unter https://github.com/fhem zentralisieren und alle daran mitarbeiten?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 27 März 2020, 13:34:33
Tja warten wir doch mal auf Rückmeldung von Amenophis86...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: frank_41 am 27 März 2020, 14:15:26
Hallo Leute,
ich bin auf dieses Modul gestossen und finde es schon gut.
Da sollen ja auch Xiaomi Devices integriert sein ?
Leider findet es meine Xiaomi Pflanzen Sensoren nicht.
Wie könnte ich die intergrieren :


Internals:
   BTMAC      C4:7C:8D:65:CA:23
   DEF        C4:7C:8D:65:CA:23
   FUUID      5c8af284-f33f-37cc-67c6-c28bda7eefdfbaa5
   FVERSION   74_XiaomiBTLESens.pm:v2.8.2-s20924/2020-01-10
   INTERVAL   590
   NAME       Sansevieria
   NOTIFYDEV  global,Sansevieria
   NR         432
   NTFY_ORDER 50-Sansevieria
   STATE      active
   TYPE       XiaomiBTLESens
   VERSION    v2.8.2
   loglevel   2
   Helper:
     DBLOG:
       batteryPercent:
         myDbLog:
           TIME       1585256457.10973
           VALUE      99
       batteryState:
         myDbLog:
           TIME       1585256457.10973
           VALUE      ok
       fertility:
         myDbLog:
           TIME       1585313958.51414
           VALUE      1327
       firmware:
         myDbLog:
           TIME       1585256457.10973
           VALUE      3.2.1
       lastGattError:
         myDbLog:
           TIME       1585262443.99034
           VALUE      Function not implemented (38)
       lux:
         myDbLog:
           TIME       1585313958.51414
           VALUE      436
       moisture:
         myDbLog:
           TIME       1585313958.51414
           VALUE      66
       state:
         myDbLog:
           TIME       1585313958.51414
           VALUE      active
       temperature:
         myDbLog:
           TIME       1585313958.51414
           VALUE      18.5
   READINGS:
     2020-03-26 22:00:57   batteryPercent  99
     2020-03-26 22:00:57   batteryState    ok
     2020-03-27 13:59:18   fertility       1327
     2020-03-26 22:00:57   firmware        3.2.1
     2020-03-26 23:40:43   lastGattError   Function not implemented (38)
     2020-03-27 13:59:18   lux             436
     2020-03-27 13:59:18   moisture        66
     2020-03-27 13:59:18   state           active
     2020-03-27 13:59:18   temperature     18.5
   helper:
     CallBattery 0
     CallSensDataCounter 0
     updateTimeCallBattery 1585256457.09493
     updateTimestampCallBattery 2020-03-26 22:00:57
Attributes:
   battery_change 2020-02-06
   blockingCallLoglevel 2
   devStateIcon {my $w=int(ReadingsVal("$name","moisture",0));if($w < 10){'.*:sani_irrigation@red'}else{'.*:sani_irrigation@green'}}
   interval   590
   model      flowerSens
   room       FlowerSens,plants
   verbose    1
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 27 März 2020, 14:40:06
Hmmm, sollte eigentlich drin sein!?

Ich habe es wie folgt bei mir eingebunden:


  ##############################################
  # XiaomiFlowerSens Devices
  ##############################################
# new fhem Module -> new Type
  elsif($Type eq "XiaomiBTLESens")
  {
# Changed from batteryLevel to batteryPercentage 
#    $ActBatLevel = ReadingsNum($Device, "batteryLevel", "0");
    $ActBatLevel = ReadingsNum($Device, "batteryPercent", "0");

    if($ActBatLevel > 75)
    {
      # set date/time for changed battery if it was low before (so probably a change happended)
      # not necessary to have "special treatment" here because they normally just don't stopp they go down by percentage...
      if(ReadingsVal($myDummySignalMessageStatesFhemBot, $SignalDevice, "none") eq "low" || ReadingsVal($myDummyBatteryStates, $Device, 100) < 50)
      {
        # calculate lifetime since last change
        my_CalculateBatteryLife($Device);
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $myDummyLastBatteryChange $Device Battery changed:");
        # set the signal state back to none
        fhem("setreading $myDummySignalMessageStatesFhemBot $SignalDevice none");
      }

      # set the battery value to 75% - 100%
      fhem("setreading $myDummyBatteryStates $Device 100");
    }
    elsif($ActBatLevel > 50)
    {
      # between 50% and 75%
      fhem("setreading $myDummyBatteryStates $Device 75");

      # set the signal state (back) to none
      if(ReadingsVal($myDummySignalMessageStatesFhemBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $myDummySignalMessageStatesFhemBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 25)
    {
      # between 25% and 50%
      fhem("setreading $myDummyBatteryStates $Device 50");

      # set the signal state (back) to none
      if(ReadingsVal($myDummySignalMessageStatesFhemBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $myDummySignalMessageStatesFhemBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 5)
    {
      # between 5% and 25%
      fhem("setreading $myDummyBatteryStates $Device 25");

      # maybe already send a message! Easy possible with new signal states
    }
    else
    {
      # totally empty (below 5%)
      fhem("setreading $myDummyBatteryStates $Device 0");

      # check if message was already sent
      if(ReadingsVal($myDummySignalMessageStatesFhemBot, $SignalDevice, "low") ne "low")
      {
        # set signal state to low
        fhem("setreading $myDummySignalMessageStatesFhemBot $SignalDevice low");
        #send message via TelegramBot
        fhem("set $myTelegramBot message Change battery $BatteryType for device $Device soon!");
      }
    }
  }



ABER ACHTUNG!! Der Code-Schnipsel ist aus MEINEM ursprünglichen Code!!! Muss für hier sicher angepasst werden!!

EDIT:
Ich habe beispielsweise ja das Senden per Telegram direkt im Code...
...ebenso das Merken, ob/wann bereits gesendet wurde (myDummySignalMessageStatesFhemBot )...

Auch habe ich eine Routine die "berechnet" wann zuletzt gewechselt wurde, also die "Laufzeit" der Batterie protokolliert.
So sehe ich wie lange die Batterien so bei den diversen Geräten (in der Regel) halten/gehalten haben (my_CalculateBatteryLife)...

Und ich habe ja die Erweiterung um ein userattr wo der jeweilige Batterie-Typ drin steht, der geht bei der Wechselmeldung (bzw. Wechsel-Bald-Meldung) mit raus, dann weiß ich gleich welche Batterie ich besser kaufe oder schon zuhause habe(n sollte)... ;)  ($BatteryType)



Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: frank_41 am 27 März 2020, 17:43:47
Danke für die Antwort.
Ich hatte BatteryCheckUtils.pm eingebunden und da erscheinen sie nicht.
Nun habe ich Batterycheck.pm eingebunden und da sehe ich was unter BatterieStatusBot
aber nichts bei rgBatteryStatus ??
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: FunkOdyssey am 27 März 2020, 18:19:24
Hast du das Notify auch so passend, dass batteryPercent matcht?
Ich habe in meinem Code auch eine Schleife für das neue Reading ergänzt.
Suche mal nach:
#Set Readings for device with reading batteryLevel

Keine Ahnung, ob das wichtig war.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 29 März 2020, 16:05:30
Hallo an alle,

Fangen wir vorne an. Ich bin dafür, dass der Code freigegeben wird und alle daran arbeiten können. Ich hatte ihn damals ja auch nur angepasst. Leider war ich erst beruflich sehr eingespannt, dass ich kaum Zeit hatte. Nun haben wir ein Haus gekauft, welches wir Kernsanieren, KNX selbst einbauen, viel planen und wegen Corona Handwerker absagen und Kinder betreut werden müssen :D Somit noch weniger Zeit als vorher.

Lange Rede kurzer Sinn. Sagt mir was ich machen muss, dass alle daran arbeiten können. Das Modul ist generell super und daher sollte es weiter entwickelt werden. Ich alleine werde es nicht leisten können.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: frank_41 am 30 März 2020, 10:05:48
Hallo Allerseits,
ja fände es auch gut, wenn das Projekt weiter gehen würde.
Leider habe ich zu wenig Ahnung von Perl, dass ich da groß helfen könnte.
Aber die Xiaomi Flower Dinger sehe ich nun.
Gruß
Frank
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: FunkOdyssey am 30 März 2020, 15:11:00
Ich habe mich mal umgehört. Mir wurde gesagt, dass unser Projekt auf GitHub eher für Module genutzt werden soll.
Also brauchen wir doch wieder jemanden, der seinen GitHub-Namen zur Verfügung stellt.
Oder wir bleiben bei Amenophis86-Repository und reichen Pull Requests ein.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 30 März 2020, 17:48:43
Gerne darf auch jemand ein Fork machen und sein Github zur Verfügung stellen. Kann aktuell nicht sagen, wie oft ich dazu komme den Request zu prüfen und oder zu übernehmen. Sorry
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: aruttkamp am 30 März 2020, 22:07:53
ZitatGerne darf auch jemand ein Fork machen und sein Github zur Verfügung stellen.
Ich habe mir erlaubt einen Fork anzulegen.
Ihr findet diesen hier https://github.com/aruttkamp/Batteryfunktion (https://github.com/aruttkamp/Batteryfunktion)
Alles weitere später ;-)

Andreas
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: FunkOdyssey am 06 April 2020, 21:22:38
Ich habe wirklich keine Ahnung von Perl, aber ich habe irgendwie ein Brett vor dem Kopf.

Wieso ist diese elsif gültig, bei einem $event="battery" und $TYPE="HUEDevice"?

elsif ((ReadingsVal($Device, "batteryLevel", "undef") eq "undef" || ReadingsVal($Device, "batteryPercent", "undef") eq "undef") and ($TYPE ne "ZWave" || $TYPE ne "HUEDevice"))

Kann mir jemand helfen?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 06 April 2020, 21:31:38
Mal angenommen es gibt keine Readings:

batteryLevel -> undef -> true
oder
batteryPercent -> undef -> true

also sobald $Device EINES dieser Readings NICHT hat ist der erste Teil -> true

Ob das so ist: das weißt nur du...

Wenn $TYPE NICHT ZWave (sondern HUEDevice) ist (oder andersrum), dann ist auch der zweite Teil -> true
(und es ist ja entweder NUR eins davon oder sogar weder noch -> true)

Ergo ist dann auch "true and true" -> true ;)

EDIT: ich würde auch eher ReadingsNum denn ReadingsVal nehmen... (hat aber hiermit nix zu tun ;)  )

Gruß, Joachim

P.S.: hat aber mit $event nix zu tun, maximal mit dem $Device daraus...
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: FunkOdyssey am 06 April 2020, 21:35:32
Er soll in die Weiterverarbeitung nur dann gehen, wenn es
- kein Reading batteryLevel
- kein Reading batteryPercent
- kein Device ZWave
- kein Device HUEDevice
ist.

Ich dachte erst, dass ich im zweiten Teil einen Gedankenfehler habe und habe es auch so getestet:
($TYPE ne "ZWave" and $TYPE ne "HUEDevice")

Hat auch nicht funktioniert.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 06 April 2020, 21:42:14
Wenn du willst, dass KEIN Reading batteryPercent UND KEIN Reading batteryLevel beim $Device da ist, dann musst du das auch so schreiben ;)

Also

elsif ((ReadingsVal($Device, "batteryLevel", "undef") eq "undef" && ReadingsVal($Device, "batteryPercent", "undef") eq "undef")

und der zweite Teil, also NUR $TYPE=HUEDevice, dann:

$TYPE eq "HUEDevice"

und wenn du auch (warum auch immer) irgendwas mit nicht-ZWave haben willst, dann:

$TYPE eq "HUEDevice" && $TYPE ne "ZWave"


Zusammen dann in etwa so:

elsif ((ReadingsVal($Device, "batteryLevel", "undef") eq "undef" && ReadingsVal($Device, "batteryPercent", "undef") eq "undef") && $TYPE eq "HUEDevice")

bzw.:

elsif ((ReadingsVal($Device, "batteryLevel", "undef") eq "undef" && ReadingsVal($Device, "batteryPercent", "undef") eq "undef") && ($TYPE eq "HUEDevice"  && $TYPE ne "ZWave"))

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: FunkOdyssey am 07 April 2020, 12:34:34
Ich danke dir. Ich habe leider sowieso festgestellt, dass ich meine gesamte Logik überarbeiten muss.
Aber du hast mir schon sehr geholfen.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 07 April 2020, 13:27:15
Zitat von: FunkOdyssey am 07 April 2020, 12:34:34
Ich danke dir. Ich habe leider sowieso festgestellt, dass ich meine gesamte Logik überarbeiten muss.
Aber du hast mir schon sehr geholfen.

Ich dachte mir schon, dass das etwas ;)

Aber jeder wie er es haben will...

Gerne, viel Spaß noch, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Betonklotz am 15 April 2020, 07:28:47
Hallo Joachim,

magst du deine my_CalculateBatteryLife($Device) Funktion posten? Baue mir gerade auch etwas (wobei das super simpel ist, da nur HM Geräte mit Angabe der Batterie Spannung), scheitere aber an der Laufzeitberechnung. Dachte ich lese einfach den letzten Wechsel aus (wird ja gespeichert) und subtrahiere das aktuelel Datum. Aber irgendwie stehe ich da mit Perl auf Kriesgsfuss... Ein kleiner Tipp reicht mir sonst auch schon.

Gruß, Robert

Zitat von: MadMax-FHEM am 27 März 2020, 14:40:06
Auch habe ich eine Routine die "berechnet" wann zuletzt gewechselt wurde, also die "Laufzeit" der Batterie protokolliert.
So sehe ich wie lange die Batterien so bei den diversen Geräten (in der Regel) halten/gehalten haben (my_CalculateBatteryLife)...
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 15 April 2020, 10:02:04
Hi Robert,

klar! :)


sub my_CalculateBatteryLife($)
{
  my ($Device)  = @_;
  my $ActualLifeTimes = ReadingsVal($myDummyBatteryLifeTimes, $Device, "");
  my $LastChange = ReadingsAge($myDummyLastBatteryChange, $Device, 0);
  my $WeeksSinceLastChange = $LastChange % 604800;
  $WeeksSinceLastChange = ($LastChange - $WeeksSinceLastChange) / 604800;
 
  if($WeeksSinceLastChange > 0)
  {
    # appending actual calculated life time to last life times of device in dummy
    $ActualLifeTimes .= " $WeeksSinceLastChange";
    fhem("setreading $myDummyBatteryLifeTimes $Device $ActualLifeTimes");
  }
 
  Log3(undef, 3, "my_CalculateBatteryLife     Device: $Device    LastChange: $LastChange     WeeksSinceLastChange: $WeeksSinceLastChange");
}



  my $ActualLifeTimes = ReadingsVal($myDummyBatteryLifeTimes, $Device, "");


hier wäre wohl ReadingsNum "korrekter"...
...wie auch an anderen Stellen wie ich grad sehe ;)


Ich rufe die Sub jeweils auf, bevor ich die Readings bzgl. "Batterie ist wieder ok" setze (dann ist ja der Zeitstempel des letzten Wechsels noch im Zeitstempel des Readings im Dummy für Wechsel des jeweiligen Devices hinterlegt (-> ReadingsAge)...


      # we are "in the loop" of "ok" (again)
      # check if battery is actually low -> possibly changed
      if((ReadingsVal($myDummySignalMessageStatesFhemBot, $SignalDevice, "none") eq "low" || ReadingsVal($myDummyBatteryStates, $Device, 100) < 50) && ReadingsAge($Device, "powerOn", 0) < 2 * $my_DayInSeconds)
      {
        # calculate lifetime since last change
        my_CalculateBatteryLife($Device);
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $myDummyLastBatteryChange $Device Battery changed:");
        # set the signal state (back) to none
        fhem("setreading $myDummySignalMessageStatesFhemBot $SignalDevice none");
      }


Ich speichere die "Haltbarkeit" dann im Dummy $myDummyBatteryLifeTimes (ich habe zu Beginn dafür "globale" Variablen, dann kann ich die Namen einfach ändern, falls ich das will/"muss" / du kannst nat. auch einfach direkt den Namen des Dummy angeben, dan halt vorher anlegen! ;)  )...

Bei mir heißt er: dmBatteryLifeTimes

Hier ein list:


Internals:
   FUUID      5c573a6a-f33f-753d-ac1f-3012ffe7f5aff1ee
   NAME       dmBatteryLifeTimes
   NR         202
   STATE      ???
   TYPE       dummy
   READINGS:
     2019-12-27 06:57:16   Heizkoerperthermostat_SchlaZi 153
     2019-08-29 22:32:20   Heizkoerperthermostat_WoZi 145
     2020-02-18 22:28:09   Wandthermostat_Bad 65 66
     2019-10-15 18:42:48   Wandthermostat_Buero 63
     2019-10-12 09:37:24   Wandthermostat_EssZi 59 67
     2019-02-23 10:05:11   Wandthermostat_Kueche 54 46
     2019-11-12 00:03:48   Wandthermostat_SchlaZi 66 67
     2019-09-09 10:41:39   Wandthermostat_WC 64 64
     2019-09-19 17:10:57   Wandthermostat_WoZi 61 65
Attributes:


Man sieht hier ("Space separiert" / ich lese ja die letzte Laufzeit aus und füge die neu berechntete mit "Space" hinzu: $ActualLifeTimes .= " $WeeksSinceLastChange"; / bislang funktioniert das) die "Laufzeiten" in Wochen (wenn ich mich nicht "verrechnet" hab)...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Betonklotz am 15 April 2020, 13:55:02
Hallo Joachim,

danke dir.

Habe bei mir nun ein

#####################################################
# calculate the lifetime of the batteries in weeks and stores it in dummy
sub my_CalculateBatteryLife($)
{
my ($Device)  = @_;
my $myDummyBatteryLifeTimes = "BatterieLebensdauer";
my $BatteryChanged = "LetzterBatterieWechsel";
my $ActualLifeTimes = ReadingsVal($myDummyBatteryLifeTimes, $Device, "");
my $LastChange = ReadingsAge($BatteryChanged, $Device, 0);
my $WeeksSinceLastChange = $LastChange % 604800;
$WeeksSinceLastChange = ($LastChange - $WeeksSinceLastChange) / 604800;
my $Loglevel = 3;

if($WeeksSinceLastChange > 0)
{
# appending actual calculated life time to last life times of device in dummy
$ActualLifeTimes .= " $WeeksSinceLastChange";
readingsSingleUpdate($defs{$myDummyBatteryLifeTimes}, $Device, $ActualLifeTimes, 0);
}
if($Loglevel >=3) {Log3(undef, 3, "my_CalculateBatteryLife     Device: $Device    LastChange: $LastChange     WeeksSinceLastChange: $WeeksSinceLastChange");}
}

drin, also quasi eine 1:1 Übernahme deines Codes. Aber werde das sehr wahrscheinlich noch mal aufblähen/umbauen, das gefällt mir noch nicht...
- letzte Batteriewechsel jeweils mit Datum speichern (ja, man könnte aktuell vom letzten bekannten Wechsel immer zurückrechnen)
- Vorhersage wann die Batterien fällig werden (==> muss ich einen 10er Pack bestellen weil weitere Geräte anstehen, oder reichen zwei aus)
- jeweils den Typ/Marke/MHD/Bezugsquelle mit abspeichern

Gruß, Robert
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 15 April 2020, 14:51:28
Zitat von: Betonklotz am 15 April 2020, 13:55:02
Hallo Joachim,

danke dir.

Gerne!
Und klar: pass an/bau um ;)

Zitat von: Betonklotz am 15 April 2020, 13:55:02
- letzte Batteriewechsel jeweils mit Datum speichern (ja, man könnte aktuell vom letzten bekannten Wechsel immer zurückrechnen)
- Vorhersage wann die Batterien fällig werden (==> muss ich einen 10er Pack bestellen weil weitere Geräte anstehen, oder reichen zwei aus)
- jeweils den Typ/Marke/MHD/Bezugsquelle mit abspeichern

Gut "Vorhersage" könnte man machen: at was täglich (oder wöchentlich) prüft, wie lange die Batterie letztes Mal gehalten hat und dann frühzeitig "warnt"...
...setzt aber voraus, dass das schon eine Weile läuft/gelaufen ist.

Wie du siehst halten die Batterien der Heizkörperthermostate so knapp 3 Jahre, Wandthermostate knapp 1,5 Jahre und bei meinem Außenthermometer habe ich seit 4 Jahren noch nicht gewechselt ;)

Allerdings ist es meist so, dass die Leer-Meldung kommt und das Gerät meist noch so 1-2 Wochen (manchmal sogar noch über einen Monat) "rennt"...

EDIT: drum hab ich auch die Prüfung auf powerUp (bei Homematic) eingebaut, weil gerade die Fenstersensoren (v.a. die "optischen") echt lange zwischen "low" und "ok" wechseln...

Gewechselt wird bei mir dann bei "dead" ;)

Bzgl. "merken" welcher Typ hab ich schon was erweitert:
https://forum.fhem.de/index.php/topic,82637.msg1014387.html#msg1014387

Weil ich kann mir das auch nie merken... ;)

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Betonklotz am 15 April 2020, 20:18:34
Hallo Joachim,

so kompliziert würde ich es gar nicht machen...
Laufzeit des letzten Satz Batterien + aktuelles Dateum des Wechsels = Prognose bis wann es hält. Als Text ist das völlig i.O. Wenn sich dann ein Gerät meldet, dann schaue ich in den "Raum" "Batterie" und sehe dort was ansteht. Denn die Erfahrung "Batterien halte noch ewig" mache ich auch gerade ;-)
Deshalb: die Batterien halten bis Motor Err ansteht, dafür gibt es ja extra das Register Error Position ;-) Vorher gibt es nur leichte (Kauf-)Hinweise, wenn der Motor steht dann ein bitte austauschen. Wobei 3 Jahre schaffe ich wohl nicht, bei mir verrecken so langsam die ersten Heizkörperthermostate (mit den "mitgekauften" Batterien).

Gruß, Robert
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 15 April 2020, 20:22:40
Ich hab fast nur Bausätze, da sind keine Batterien dabei...
...daher habe ich (fast) nirgends Originalbatterien...

Viel Spaß beim Umsetzen!

Kannst ja hier vorstellen...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Betonklotz am 17 April 2020, 07:57:28
Hallo Joachim,

wird noch etwas länger dauern.
Hadere noch ob ich alles als userattr dem Device zuordne (schließlich sind die Batterien, Wechselzeiten usw. Device spezifisch), oder es wie jetzt weiterhin über dummys mache. Muss mich mal belesen was besser ist, bzw. wie es für mich am einfachsten geht.

Grüße, Robert
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Betonklotz am 17 Mai 2020, 09:19:57
Hallo Joachim,

irgendwie stehe ich noch auf Kriegsfuss mit den Batterien...
Nachdem nun der erste Wechsel anstand, hagelte es Fehlermeldungen im Log und auch das reading "BatterieWechsel" hat nicht das aktuelle Datum drin :-(

2020.05.16 12:19:17 3: Motor of EG_ArbeitRobert_Heizung_Durchgang is in eror state, BatteryChange needed NOW
2020.05.16 12:22:42 3: CUL_HM set EG_ArbeitRobert_Heizung_Durchgang getConfig
2020.05.16 12:22:42 3: my_CalculateBatteryLife     Device: EG_ArbeitRobert_Heizung_Durchgang    LastChange: 0     WeeksSinceLastChange: 0
2020.05.16 12:22:42 1: ERROR: empty name in readingsBeginUpdate
2020.05.16 12:22:42 1: stacktrace:
2020.05.16 12:22:42 1:     main::readingsBeginUpdate           called by fhem.pl (4939)
2020.05.16 12:22:42 1:     main::readingsSingleUpdate          called by ./FHEM/99_BatteryCheckUtils.pm (215)
2020.05.16 12:22:42 1:     main::BatteryStatusFunction         called by (eval 524316) (1)
2020.05.16 12:22:42 1:     (eval)                              called by fhem.pl (1146)
2020.05.16 12:22:42 1:     main::AnalyzePerlCommand            called by fhem.pl (1171)
2020.05.16 12:22:42 1:     main::AnalyzeCommand                called by fhem.pl (1100)
2020.05.16 12:22:42 1:     main::AnalyzeCommandChain           called by ./FHEM/91_notify.pm (121)
2020.05.16 12:22:42 1:     main::notify_Exec                   called by fhem.pl (3775)
2020.05.16 12:22:42 1:     main::CallFn                        called by fhem.pl (3695)
2020.05.16 12:22:42 1:     main::DoTrigger                     called by fhem.pl (4062)
2020.05.16 12:22:42 1:     main::Dispatch                      called by ./FHEM/00_HMUARTLGW.pm (1463)
2020.05.16 12:22:42 1:     main::HMUARTLGW_Parse               called by ./FHEM/00_HMUARTLGW.pm (1566)
2020.05.16 12:22:42 1:     main::HMUARTLGW_Read                called by fhem.pl (3775)
2020.05.16 12:22:42 1:     main::CallFn                        called by fhem.pl (757)
2020.05.16 12:22:42 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at fhem.pl line 4794.
2020.05.16 12:22:42 3: eval: my $TYPE='CUL_HM';my $EVTPART0='batteryLevel:';my $NAME='EG_ArbeitRobert_Heizung_Durchgang';my $EVTPART1='3';my $SELF='NO.BatterieNotify';my $EVENT='batteryLevel: 3';{BatteryStatusFunction($NAME, $EVENT)}
2020.05.16 12:22:42 1: readingsUpdate(,EG_ArbeitRobert_Heizung_Durchgang,Batterie zuletzt gewechselt am/um: ) missed to call readingsBeginUpdate first.
2020.05.16 12:22:42 1: stacktrace:
2020.05.16 12:22:42 1:     main::readingsBulkUpdate            called by fhem.pl (4940)
2020.05.16 12:22:42 1:     main::readingsSingleUpdate          called by ./FHEM/99_BatteryCheckUtils.pm (215)
2020.05.16 12:22:42 1:     main::BatteryStatusFunction         called by (eval 524316) (1)
2020.05.16 12:22:42 1:     (eval)                              called by fhem.pl (1146)
2020.05.16 12:22:42 1:     main::AnalyzePerlCommand            called by fhem.pl (1171)
2020.05.16 12:22:42 1:     main::AnalyzeCommand                called by fhem.pl (1100)
2020.05.16 12:22:42 1:     main::AnalyzeCommandChain           called by ./FHEM/91_notify.pm (121)
2020.05.16 12:22:42 1:     main::notify_Exec                   called by fhem.pl (3775)
2020.05.16 12:22:42 1:     main::CallFn                        called by fhem.pl (3695)
2020.05.16 12:22:42 1:     main::DoTrigger                     called by fhem.pl (4062)
2020.05.16 12:22:42 1:     main::Dispatch                      called by ./FHEM/00_HMUARTLGW.pm (1463)
2020.05.16 12:22:42 1:     main::HMUARTLGW_Parse               called by ./FHEM/00_HMUARTLGW.pm (1566)
2020.05.16 12:22:42 1:     main::HMUARTLGW_Read                called by fhem.pl (3775)
2020.05.16 12:22:42 1:     main::CallFn                        called by fhem.pl (757)
2020.05.16 12:22:42 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4547.
2020.05.16 12:22:42 3: eval: my $TYPE='CUL_HM';my $EVTPART0='batteryLevel:';my $NAME='EG_ArbeitRobert_Heizung_Durchgang';my $EVTPART1='3';my $SELF='NO.BatterieNotify';my $EVENT='batteryLevel: 3';{BatteryStatusFunction($NAME, $EVENT)}
2020.05.16 12:22:42 3: Battery change detected on HM device EG_ArbeitRobert_Heizung_Durchgang

Was soll mir diese Fehlermeldung sagen? ein

readingsBeginUpdate

habe ich bei mir nicht, bzw. finde ich nicht. Die Zeile 215 ist das zweite readingsSingleUpdate in dem Ausschnitt (poste sonst auch die ganze Datei wenn es das einfache rmacht)

##############################################
# HM Devices with batteryLevel
##############################################
elsif($TYPE eq "CUL_HM" and $BatteryType[0] eq "batteryLevel")
{
$ActBatLevel = ReadingsVal($Device, "batteryLevel", "0.0");
$MinBatLevel = ReadingsNum($Device, "R-lowBatLimitRT", "0.0");
$RemainingVoltageQuater = ($MaxBattery - $MinBatLevel) / 4; # to get 4 quaters for different colours and icons
if(ReadingsVal($BatteryStatus, $Device, "undef") eq "undef") # set battery level 100% and show in BatteryStatus-Device if new
{
readingsSingleUpdate($defs{$BatteryStatus},$Device, 100,0);
if($Loglevel >=1) {Log3(undef, 1, "$Device, added to $BatteryStatus");}
return undef;
}
if(($ActBatLevel - $MinBatLevel) > (3 * $RemainingVoltageQuater))
{
# check if battery was low before -> possibly changed
if(ReadingsNum($BatteryStatus, $Device, 100) <= 25)
{
# calculate lifetime since last change
my_CalculateBatteryLife($Device);
# set date/time for changed battery if it was low before (so probably a change happended)
readingsSingleUpdate($defs{$BatteryChanged}, $Device, $text_changed, 0);
if($Loglevel >=3) {Log3(undef, 3, "Battery change detected on HM device $Device");}
}

bin wieder mal ratlos...

Gruß, Robert
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 17 Mai 2020, 09:49:16
Da der Code den du verwendest nicht von mir ist: keine Ahnung.

Woher hast du den Code!?

Wie ganz zu Beginn des Threads zu lesen: die Basis war mal von mir kopiert...
...hat aber wenn ich mir deinen Codeschnipsel so ansehe nichts mehr/nicht mehr viel mit dem Ursprungs-Code zu tun...

Ich verwende in "meinem Original-Code" kein readingsSingleUpdate sondern mache alles mittels setreading...

Interessant wäre zu posten was in der Funktion my_CalculateBatteryLife (da scheint doch der Fehler herzukommen!?) drin steht...

Zitat
2020.05.16 12:22:42 3: my_CalculateBatteryLife     Device: EG_ArbeitRobert_Heizung_Durchgang    LastChange: 0     WeeksSinceLastChange: 0
2020.05.16 12:22:42 1: ERROR: empty name in readingsBeginUpdate

Auch sieht das hier komisch aus:


if(ReadingsNum($BatteryStatus, $Device, 100) <= 25)


Weil ReadingsNum so geht: ReadingsNum("DeviceName","ReadingName",Ersatzwert), daher würde ich (wenn die Namen "vernünftig" gewählt sind das eher so erwarten ReadingsNum($Device,$BatteryStatus,100)  )...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Betonklotz am 17 Mai 2020, 10:19:04
Hallo Joachim,

der Code ist der ursprüngliche, angereichert mit Infos von dir. Anbei die my_CalculateBatteryLife (c&p von dir aus https://forum.fhem.de/index.php/topic,82637.msg1042493/topicseen.html#msg1042493), aber wahrscheinlich bin ich schon zu blöd für c&p...

#####################################################
# calculate the lifetime of the batteries in weeks
# and stores/appends the value to dummy
sub my_CalculateBatteryLife($)
{
my ($Device)  = @_;
my $myDummyBatteryLifeTimes = "BatterieLebensdauer";
my $BatteryChanged = "LetzterBatterieWechsel";
my $ActualLifeTimes = ReadingsVal($myDummyBatteryLifeTimes, $Device, "");
my $LastChange = ReadingsAge($BatteryChanged, $Device, 0);
my $WeeksSinceLastChange = $LastChange % 604800;
$WeeksSinceLastChange = ($LastChange - $WeeksSinceLastChange) / 604800;
my $Loglevel = 3;

if($WeeksSinceLastChange > 0)
{
# appending actual calculated life time to last life times of device in dummy
$ActualLifeTimes .= " $WeeksSinceLastChange";
readingsSingleUpdate($defs{$myDummyBatteryLifeTimes}, $Device, $ActualLifeTimes, 0);
}
if($Loglevel >=3) {Log3(undef, 3, "my_CalculateBatteryLife     Device: $Device    LastChange: $LastChange     WeeksSinceLastChange: $WeeksSinceLastChange");}
}


Und die komische codestelle stammt ebenfalls aus dem Original
https://github.com/Amenophis86/Batteryfunktion/blob/no-BatteryStatusBot/99_BatteryCheckUtils.pm
An so wichtige Dinge die ich kaum verstehe gehe ich nicht dran...
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 17 Mai 2020, 12:07:57
Also ich hab mal geschaut und laut "Doku" ist ReadingsSingleUpdate so:


readingsSingleUpdate($hash,$reading,$value,$dotrigger);


Und damit für mich ebenso "komisch" (falsch!?) wie das zuvor erwähnte ReadingsVal...

Aber da nicht mein Code...
...kann ich dazu wenig sagen, leider.

Da wird wohl Amenophis86 was sagen müssen...

Sorry, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Betonklotz am 18 Mai 2020, 11:24:54
Hallo Joachim,

trotzdem danke.
Batteriüberwachung ist nach wie vor auf der to-do Liste, aber derzeit komme ich zu nix (außer aufzuschrecken wenn Fehler im Log auftauchen...)

Gruß, Robert
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 19 Mai 2020, 09:35:08
Lastchange Weeks etc ist nicht von mir. Frage mich wo der Code her kommt. Ich empfehle alles löschen und den Code aus github komplett neu kopieren.

Zusammen kopierte Dinge aus verschiedenen Dingen sind halt teilweise schwer kompatibel. Wie ich sehe hast du zwei Versionen zusammen kopiert, oder?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Betonklotz 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
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM 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
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Betonklotz am 08 Juni 2020, 17:49:48
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
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM 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
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Betonklotz 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
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM 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
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Betonklotz 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
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: TWART016 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>")} \
}\
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: amenomade 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]
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: mr.sulu 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
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag 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?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 13 August 2021, 15:40:39
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
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Kai-Alfonso am 13 August 2021, 15:58:08
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
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Kai-Alfonso am 13 August 2021, 16:19:23
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
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 13 August 2021, 20:00:05
Welchen Branche nutzt du und was sagt das Log? Gibt es einen Fehler?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: gent am 25 August 2021, 18:41:38
Ich habe mal eine wahrscheinlich dumme Frage:

Muss ich in den Devices, bei denen ich den Batteriestand überwachen will das attribut "event-on-change-reading" passend setzen?

Liebe Grüße vom Gent
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 25 August 2021, 18:45:43
Zitat von: gent am 25 August 2021, 18:41:38
Ich habe mal eine wahrscheinlich dumme Frage:

Muss ich in den Devices, bei denen ich den Batteriestand überwachen will das attribut "event-on-change-reading" passend setzen?

Liebe Grüße vom Gent

Naja: wenn z.B. nie ein battery-etc-Event kommt, dann kommt auch nie ein Eintrag bzw. halt nur geänderte Einträge.

Wo es eh nur ok/low gibt ist es wohl egal, also bzw. event-on-change... sollte zumindest diese beiden Events "ermöglichen"...
...bei Geräten/Devices die Zwischenwerte liefern sollten die halt kommen (können)...

Also es ist wie bei allen Events... ;)

EDIT: für die "Erstellung" einer "Erstansicht" sollten zumindest alle Devices mal ein Event "lostreten" ;)

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: gent am 25 August 2021, 19:48:04
Hallo Joachim,

also wenn ich im Event-Monitor für das Device z.B. so etwas sehe


2021-08-25 19:46:30 CUL_HM LA2.Heizung battery: ok
2021-08-25 19:46:30 CUL_HM LA2.Heizung batteryLevel: 2.7


Dann ist hier ein Event ausgelöst worden und ich brauche kein weiteres Attribut zu setzen. Sehe ich das richtig?
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 25 August 2021, 19:55:49
Zitat von: gent am 25 August 2021, 19:48:04
Hallo Joachim,

also wenn ich im Event-Monitor für das Device z.B. so etwas sehe


2021-08-25 19:46:30 CUL_HM LA2.Heizung battery: ok
2021-08-25 19:46:30 CUL_HM LA2.Heizung batteryLevel: 2.7


Dann ist hier ein Event ausgelöst worden und ich brauche kein weiteres Attribut zu setzen. Sehe ich das richtig?

Zumindest wird so immer aktualisiert.
Je nachdem wie oft das kommt (und wie oft du eine Aktualisierung wirklich brauchst) kannst du nat. event-on-change-... setzen.

Wenn dir z.B. EINE Nachricht bei LEER reicht und du auch sonst nicht auf battery-Events reagierst, dann kannst du mit event-on-change genau das erreichen.
Wenn dich wiederholte Benachrichtigungen stören, dann kannst du entweder event-on-change setzen oder eben bei der Benachrichtigung dafür sorgen, dass diese nur 1x kommt.
(wobei das nicht ganz stimmt, weil manche Geräte kurz vor leer u.U. noch [ein paar] mal hin und her wanken ;)  )

Andersrum: wenn du mehrfach auf eine leere Batterie hingewiesen werden willst, dann einfach event-on-change (für battery) weglassen (vorausgesetzt das Device/Gerät schickt weiterhin battery-Meldungen) oder eben in der Benachrichtigung bzw. dort wo diese erzeugt wird entsprechend für Wiederholungen sorgen...

Noch mal: es gibt keine Regel für event-on-change weil es eben davon abhängt, wie oft die Events kommen (zu oft unbenötigt -> einschränken u.U. sinnvoll) wenn sie eh nicht oft kommen (wie man dann eben will) und wenn man auch noch anderweitig drauf reagieren will, z.B. regelmäßig irgendwelche Automatismen oder auch "nur" prüfen "lebt das Ding noch", dann ist event-on-change eher/oft kontraproduktiv...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: DonJuan am 02 Dezember 2021, 23:37:40
Moin,

ich stehe da irgendwie auf dem Schlauch. Habe mir den Code vom Git kopiert und in mein FHEM eingebunden. Mit {BatteryStart()} wurde auch alles mögliche Angelegt. Aber es gibt keinen Inhalt im "rgBatteryStatus". Im "BatterieStatusBot" stehen zwar alle Devices drin, aber mit "none". Wenn ich den Code richtig verstehe, soll das beim ersten mal auch so sein. Nun ist aber eine Batterie leer und es passiert nichts.

Ich weiss, dass ich das Script schon mal benutzt hatte. Da wurde ich nur nicht gewarnt und der Wechseltag wurde nicht dokumentiert.

Ich finde leider den Fehler nicht. Evtl liegt es daran, dass meine Homematic-IP-Geräte alle "HmIP_...." heissen.

Kennt jemand das Problem?

Gruss Dennis
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 03 Dezember 2021, 07:42:45
Poste doch mal ein list von einem deiner Devices und vom notify bzgl. Batterie.

Sind es HM-IP Geräte?
Klingt danach...

Sind die im Code der Sub überhaupt schon drin?
Gut, sieht man (evtl.) wenn man ein list hat/hätte...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: DonJuan am 03 Dezember 2021, 10:13:25
Moin Moin,

ja, es sind alles HM-IP-Geräte (und ein paar LaCrosse).
Ob die im Code mit drin sind, weiss ich nicht. Ich habe das einfach alles so übernommen. Auch, weil ich nicht wusste, wo ich was anpassen sollte.

Hier die List vom Device.

Internals:
   DEF        000A1A49A0C978
   FUUID      5e061613-f33f-42e4-0365-fa764823c7157fd1
   IODev      d_ccu
   NAME       HmIP_HZ_Buero
   NR         22
   STATE      20
   TYPE       HMCCUDEV
   ccuaddr    000A1A49A0C978
   ccudevstate active
   ccuif      HmIP-RF
   ccuname    HmIP-HZ-Buero
   ccurolectrl HEATING_CLIMATECONTROL_TRANSCEIVER
   ccurolestate HEATING_CLIMATECONTROL_TRANSCEIVER
   ccusubtype TRV
   ccutype    HmIP-eTRV-2
   firmware   2.2.8
   readonly   no
   sender     HmIP_FT_Buero
   READINGS:
     2021-12-03 09:36:28   1.ACTUAL_TEMPERATURE 21.3
     2021-12-03 09:36:28   1.ACTUAL_TEMPERATURE_STATUS NORMAL
     2021-12-03 09:36:28   1.BOOST_MODE    false
     2021-12-03 09:36:28   1.SET_POINT_MODE auto
     2021-12-03 09:36:28   1.SET_POINT_TEMPERATURE 20
     2021-12-03 09:36:28   1.WINDOW_STATE  closed
     2021-12-01 23:46:23   IODev           d_ccu
     2021-12-03 09:36:28   activity        alive
     2021-12-03 09:36:28   battery         ok
     2021-12-03 09:36:28   control         20
     2021-12-03 09:36:28   desired-temp    20
     2021-12-03 09:36:28   devstate        ok
     2021-12-03 09:36:28   hmstate         20
     2021-12-03 09:36:28   measured-temp   21.3
     2021-12-03 09:36:28   rssidevice      -72
     2021-12-03 09:36:28   rssipeer        186
     2021-12-03 09:36:28   state           20
     2021-12-03 09:36:28   valve_position  2
     2021-12-03 09:36:28   valve_position_STATUS NORMAL
   hmccu:
     channels   8
     detect     1
     devspec    000A1A49A0C978
     forcedev   0
     nodefaults 1
     role       0:MAINTENANCE,1:HEATING_CLIMATECONTROL_TRANSCEIVER,2:HEATING_CLIMATECONTROL_RECEIVER,3:HEATING_CLIMATECONTROL_CL_RECEIVER,4:HEATING_SHUTTER_CONTACT_RECEIVER,5:HEATING_ROOM_TH_TRANSCEIVER,6:HEATING_ROOM_TH_RECEIVER,7:HEATING_KEY_RECEIVER
     semDefaults 0
     cmdlist:
       get       
       set        boost:noArg desired-temp on:noArg auto:noArg off:noArg manu:noArg holiday:noArg toggle:noArg
     control:
       chn        1
       dpt        SET_POINT_TEMPERATURE
     dp:
       0.CONFIG_PENDING:
         VALUES:
           NVAL       0
           ONVAL      0
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
       0.DUTY_CYCLE:
         VALUES:
           NVAL       0
           ONVAL      0
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
       0.INSTALL_TEST:
         VALUES:
           NVAL       true
           ONVAL      true
           OSVAL      true
           OVAL       true
           SVAL       true
           VAL        true
       0.LOW_BAT:
         VALUES:
           NVAL       0
           ONVAL      0
           OSVAL      ok
           OVAL       0
           SVAL       ok
           VAL        0
       0.OPERATING_VOLTAGE:
         VALUES:
           NVAL       2.4
           ONVAL      2.4
           OSVAL      2.4
           OVAL       2.4
           SVAL       2.4
           VAL        2.4
       0.OPERATING_VOLTAGE_STATUS:
         VALUES:
           NVAL       0
           ONVAL      0
           OSVAL      NORMAL
           OVAL       0
           SVAL       NORMAL
           VAL        0
       0.RSSI_DEVICE:
         VALUES:
           NVAL       -72
           ONVAL      -72
           OSVAL      -72
           OVAL       -72
           SVAL       -72
           VAL        -72
       0.RSSI_PEER:
         VALUES:
           NVAL       186
           ONVAL      186
           OSVAL      186
           OVAL       186
           SVAL       186
           VAL        186
       0.UNREACH:
         VALUES:
           NVAL       0
           ONVAL      0
           OSVAL      alive
           OVAL       0
           SVAL       alive
           VAL        0
       0.UPDATE_PENDING:
         VALUES:
           NVAL       false
           ONVAL      false
           OSVAL      false
           OVAL       false
           SVAL       false
           VAL        false
       1.ACTIVE_PROFILE:
         VALUES:
           NVAL       1
           ONVAL      1
           OSVAL      1
           OVAL       1
           SVAL       1
           VAL        1
       1.ACTUAL_TEMPERATURE:
         VALUES:
           NVAL       21.3
           ONVAL      21.3
           OSVAL      21.3
           OVAL       21.3
           SVAL       21.3
           VAL        21.3
       1.ACTUAL_TEMPERATURE_STATUS:
         VALUES:
           NVAL       0
           ONVAL      0
           OSVAL      NORMAL
           OVAL       0
           SVAL       NORMAL
           VAL        0
       1.BOOST_MODE:
         VALUES:
           NVAL       0
           ONVAL      0
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
       1.BOOST_TIME:
         VALUES:
           NVAL       0
           ONVAL      0
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
       1.FROST_PROTECTION:
         VALUES:
           NVAL       0
           ONVAL      0
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
       1.LEVEL:
         VALUES:
           NVAL       2
           ONVAL      1
           OSVAL      1
           OVAL       0.01
           SVAL       2
           VAL        0.02
       1.LEVEL_STATUS:
         VALUES:
           NVAL       0
           ONVAL      0
           OSVAL      NORMAL
           OVAL       0
           SVAL       NORMAL
           VAL        0
       1.PARTY_MODE:
         VALUES:
           NVAL       0
           ONVAL      0
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
       1.PARTY_SET_POINT_TEMPERATURE:
         VALUES:
           NVAL       0
           ONVAL      0
           OSVAL      0
           OVAL       0.000000
           SVAL       0
           VAL        0.000000
       1.PARTY_TIME_END:
         VALUES:
           NVAL       
           ONVAL     
           OSVAL     
           OVAL       
           SVAL       
           VAL       
       1.PARTY_TIME_START:
         VALUES:
           NVAL       
           ONVAL     
           OSVAL     
           OVAL       
           SVAL       
           VAL       
       1.QUICK_VETO_TIME:
         VALUES:
           NVAL       0
           ONVAL      0
           OSVAL      0
           OVAL       0
           SVAL       0
           VAL        0
       1.SET_POINT_MODE:
         VALUES:
           NVAL       0
           ONVAL      0
           OSVAL      auto
           OVAL       0
           SVAL       auto
           VAL        0
       1.SET_POINT_TEMPERATURE:
         VALUES:
           NVAL       20
           ONVAL      20
           OSVAL      20
           OVAL       20.0
           SVAL       20
           VAL        20.0
       1.SWITCH_POINT_OCCURED:
         VALUES:
           NVAL       0
           ONVAL      0
           OSVAL      false
           OVAL       0
           SVAL       false
           VAL        0
       1.VALVE_ADAPTION:
         VALUES:
           NVAL       false
           ONVAL      false
           OSVAL      false
           OVAL       false
           SVAL       false
           VAL        false
       1.VALVE_STATE:
         VALUES:
           NVAL       4
           ONVAL      4
           OSVAL      ADAPTION_DONE
           OVAL       4
           SVAL       ADAPTION_DONE
           VAL        4
       1.WINDOW_STATE:
         VALUES:
           NVAL       0
           ONVAL      0
           OSVAL      closed
           OVAL       0
           SVAL       closed
           VAL        0
     roleCmds:
       get:
       set:
         auto:
           channel    1
           role       HEATING_CLIMATECONTROL_TRANSCEIVER
           subcount   1
           syntax     V:CONTROL_MODE:0
           usage      auto
           subcmd:
             000:
               args       0
               dpt        CONTROL_MODE
               fnc       
               max        3
               min        0
               parname    CONTROL_MODE
               partype    3
               ps         VALUES
               scn        000
               unit       
         boost:
           channel    1
           role       HEATING_CLIMATECONTROL_TRANSCEIVER
           subcount   1
           syntax     V:BOOST_MODE:1
           usage      boost
           subcmd:
             000:
               args       1
               dpt        BOOST_MODE
               fnc       
               max        1
               min        0
               parname    BOOST_MODE
               partype    3
               ps         VALUES
               scn        000
               unit       
         desired-temp:
           channel    1
           role       HEATING_CLIMATECONTROL_TRANSCEIVER
           subcount   1
           syntax     V:SET_POINT_TEMPERATURE:?temperature
           usage      desired-temp temperature
           subcmd:
             000:
               args       
               dpt        SET_POINT_TEMPERATURE
               fnc       
               max        30.5
               min        4.5
               parname    temperature
               partype    2
               ps         VALUES
               scn        000
               unit       �C
         holiday:
           channel    1
           role       HEATING_CLIMATECONTROL_TRANSCEIVER
           subcount   1
           syntax     V:CONTROL_MODE:2
           usage      holiday
           subcmd:
             000:
               args       2
               dpt        CONTROL_MODE
               fnc       
               max        3
               min        0
               parname    CONTROL_MODE
               partype    3
               ps         VALUES
               scn        000
               unit       
         manu:
           channel    1
           role       HEATING_CLIMATECONTROL_TRANSCEIVER
           subcount   1
           syntax     V:CONTROL_MODE:1
           usage      manu
           subcmd:
             000:
               args       1
               dpt        CONTROL_MODE
               fnc       
               max        3
               min        0
               parname    CONTROL_MODE
               partype    3
               ps         VALUES
               scn        000
               unit       
         off:
           channel    1
           role       HEATING_CLIMATECONTROL_TRANSCEIVER
           subcount   2
           syntax     V:CONTROL_MODE:1 V:SET_POINT_TEMPERATURE:4.5
           usage      off
           subcmd:
             000:
               args       1
               dpt        CONTROL_MODE
               fnc       
               max        3
               min        0
               parname    CONTROL_MODE
               partype    3
               ps         VALUES
               scn        000
               unit       
             001:
               args       4.5
               dpt        SET_POINT_TEMPERATURE
               fnc       
               max        30.5
               min        4.5
               parname    SET_POINT_TEMPERATURE
               partype    3
               ps         VALUES
               scn        001
               unit       �C
         on:
           channel    1
           role       HEATING_CLIMATECONTROL_TRANSCEIVER
           subcount   2
           syntax     V:CONTROL_MODE:1 V:SET_POINT_TEMPERATURE:30.5
           usage      on
           subcmd:
             000:
               args       1
               dpt        CONTROL_MODE
               fnc       
               max        3
               min        0
               parname    CONTROL_MODE
               partype    3
               ps         VALUES
               scn        000
               unit       
             001:
               args       30.5
               dpt        SET_POINT_TEMPERATURE
               fnc       
               max        30.5
               min        4.5
               parname    SET_POINT_TEMPERATURE
               partype    3
               ps         VALUES
               scn        001
               unit       �C
     state:
       chn        1
       dpt        SET_POINT_TEMPERATURE
Attributes:
   IODev      d_ccu
   ccureadingfilter ^ACTUAL_TEMPERATURE|^BOOST_MODE|^SET_POINT_MODE|^SET_POINT_TEMPERATURE|^LEVEL|^WINDOW_STATE
   ccureadingname 1.LEVEL:valve_position
   ccuscaleval LEVEL:0:1:0:100
   cmdIcon    auto:sani_heating_automatic manu:sani_heating_manual boost:sani_heating_boost on:general_an off:general_aus
   controldatapoint 1.SET_POINT_TEMPERATURE
   event-on-change-reading .*
   eventMap   /datapoint 1.BOOST_MODE true:Boost/datapoint 1.CONTROL_MODE 0:Auto/datapoint 1.CONTROL_MODE 1:Manual/datapoint 1.CONTROL_MODE 2:Holiday/datapoint 1.CONTROL_MODE 1 1.SET_POINT_TEMPERATURE 4.5:off/datapoint 1.CONTROL_MODE 0 1.SET_POINT_TEMPERATURE 30.5:on/
   group      Buero
   room       Homematic,Wohnung
   statedatapoint 1.SET_POINT_TEMPERATURE
   stripnumber 1
   substexcl  desired-temp
   substitute SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open
   verbose    5
   webCmd     desired-temp:auto:manu:boost:on:off
   widgetOverride desired-temp:slider,4.5,0.5,30.5,1


Und hier vom Notify

Internals:
   CFGFN     
   DEF        .*:battery.* {BatteryStatusFunction($NAME, $EVENT)}
   FUUID      61a94728-f33f-42e4-fed5-f0af2a86869cfa9b
   NAME       NO.BatterieNotify
   NR         558
   NTFY_ORDER 50-NO.BatterieNotify
   REGEXP     .*:battery.*
   STATE      2021-12-03 10:12:16
   TRIGGERTIME 1638522736.84415
   TYPE       notify
   READINGS:
     2021-12-02 23:22:32   state           active
Attributes:
   room       BatteryCheck


Bin mal gespannt, was ich falsch gemacht habe.

Gruss Dennis
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 03 Dezember 2021, 11:15:14
Also wie ich dachte: (noch) nicht drin :-\
(zumindest der Typ von dem das list ist: mal von einem der anderen Devices [LaCrosse] auch ein list aber ich vermute auch da: [noch] nicht drin)

Du kannst mal folgendes machen:

Zitat von: BatteryStatusFunction
################################
# Here you choos your message device and how to send
# comment the device you do not want to use
#
# TelegramBot
  my $msg = "set TelegramBot message \@\@User ";
#
# msg-command
# my $msg = "msg \@User title='Battery Check' ";
#
# Pushover
# my $msg = "set Pushover msg device=User title='Battery Check' ";


 
#  Log3(undef, 1, "my_StoreBatteryStatus      Device: $Device       Event: $Event      Model: $Model");
 
  # ignoring Devices that were just created by autocreate
  if($DeviceNameParts[0] eq "HM" || $DeviceNameParts[0] eq "ZWave" || $DeviceNameParts[0] eq "MAX")
  {
    Log3(undef, 1, "my_StoreBatteryStatus      ignoring Device: $Device");
    return;
  }

mal das was rot ist wegmachen, also nur das '#' also sodass die Logausgabe wieder erfolgt ;)

Dann mal eine zeitlang laufen lassen, es sollten halt von ein paar der Devices auch Batterie-Events kommen...

Und dann mal DIESE Logeinträge posten (wobei in Model verm. "undef" stehen wird)...

Ich kann (dann) versuchen mal die HMCCU-Devices auch "reinzubasteln"...
...und falls ein list von einem LaCrosse kommt die auch...
...in der Hoffnung, dass ich den Code (noch) verstehe ;)

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 03 Dezember 2021, 11:22:30
So ich hab mal was "gebastelt":


  ##############################################
  # HMCCU Devices
  ##############################################
elsif($BatteryType[0] eq "battery"  && (InternalVal($Device, "TYPE", "undef") eq "HMCCUDEV" || InternalVal($Device, "TYPE", "undef") eq "LaCrosse"))
  {
    if(ReadingsVal($Device, "battery", "low") eq "ok")
    {
      # check if battery was low before -> possibly changed
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $BatteryChanged $Device $text_changed");
        # set the signal state back to none
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }

      # status is "ok" so we set to 100% (we don't know better)
      fhem("setreading $BatteryStatus $Device 100");
    }
    else
    {
      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }

      # status is NOT "ok" ("low") so we set to 0% (we don't know better)
      fhem("setreading $BatteryStatus $Device 0");
    }
  }


das einfach mal ans Ende, also nach dem MAX!-Eintrag "dranbasteln" und dann mal sehen...

EDIT: sollte jetzt auch mit LaCrosse funktionieren... Also sofern das mit HMCCU geht/ging ;)

Eventuell (Code ist halt [auch bei mir] schwer "gewachsen") sollte/könnte man auch die eigentlich gar nicht unterschiedlichen Devices (also Reading battery und da dann ok/nok) mal zusammenfassen...
...und nur gegenüber Devices unterscheiden, die zwar battery im Reading haben aber da eben z.B. "Prozentwerte" etc. stehen haben...

Unsicher (da ich keine habe und auch HMCCU wenig kenne) bin ich halt bzgl. der "Sonderlocke" HMCCUDEV, also ob das dann tatsächlich "allgemein" für HMCCU Devices gilt oder ob es da weitere/andere "Spezialitäten" gibt...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: DonJuan am 03 Dezember 2021, 15:40:53
Ich danke euch.

Ich werde mir eure Beiträge heute Abend nochmal in Ruhe angucken.

Hier aber noch das Listing von einem LaCrosse-Geräte

Internals:
   DEF        05
   FUUID      6182a1ac-f33f-42e4-0408-8526c2d1ecb7c920
   IODev      myJeeLink
   LASTInputDev myJeeLink
   LaCrosse_lastRcv 2021-12-03 15:39:16
   MSGCNT     8377
   NAME       T.Buero
   NR         123
   STATE      T: 19.5 H: 45
   TYPE       LaCrosse
   addr       05
   battery_new 0
   bufferedH 
   bufferedT 
   corr1      0
   corr2      0
   myJeeLink_MSGCNT 8377
   myJeeLink_RAWMSG OK 9 5 1 4 171 45
   myJeeLink_TIME 2021-12-03 15:39:16
   previousH  45
   previousT  19.5
   sensorType 0=T(H)
   READINGS:
     2021-12-01 23:46:24   IODev           myJeeLink
     2021-12-03 15:39:16   battery         ok
     2021-12-03 15:39:16   humidity        45
     2021-12-03 15:32:01   state           T: 19.5 H: 45
     2021-12-03 15:39:16   temperature     19.5
Attributes:
   IODev      myJeeLink
   group      Buero
   room       LaCrosse,Wohnung


Nachtrag: Hier der LogfileAuszug

021.12.03 16:11:43 1: my_StoreBatteryStatus      Device: T.Wohn       Event: battery: ok      Model: undef
2021.12.03 16:11:47 1: my_StoreBatteryStatus      Device: T.Gast       Event: battery: ok      Model: undef
2021.12.03 16:11:48 1: my_StoreBatteryStatus      Device: T.Wohn       Event: battery: ok      Model: undef
2021.12.03 16:11:50 1: my_StoreBatteryStatus      Device: T.Bad       Event: battery: ok      Model: undef
2021.12.03 16:11:51 1: my_StoreBatteryStatus      Device: T.Buero       Event: battery: ok      Model: undef
2021.12.03 16:11:53 1: my_StoreBatteryStatus      Device: T.Schlaf       Event: battery: ok      Model: undef
2021.12.03 16:12:01 1: my_StoreBatteryStatus      Device: T.Buero       Event: battery: ok      Model: undef
2021.12.03 16:12:03 1: my_StoreBatteryStatus      Device: T.Schlaf       Event: battery: ok      Model: undef
2021.12.03 16:12:11 1: my_StoreBatteryStatus      Device: T.Buero       Event: battery: ok      Model: undef
2021.12.03 16:12:13 1: my_StoreBatteryStatus      Device: T.Schlaf       Event: battery: ok      Model: undef
2021.12.03 16:12:23 1: my_StoreBatteryStatus      Device: T.Wohn       Event: battery: ok      Model: undef
2021.12.03 16:12:27 1: my_StoreBatteryStatus      Device: T.Gast       Event: battery: ok      Model: undef
2021.12.03 16:12:28 1: my_StoreBatteryStatus      Device: T.Wohn       Event: battery: ok      Model: undef
2021.12.03 16:12:30 1: my_StoreBatteryStatus      Device: T.Bad       Event: battery: ok      Model: undef
2021.12.03 16:12:33 1: my_StoreBatteryStatus      Device: T.Wohn       Event: battery: ok      Model: undef
2021.12.03 16:12:34 1: my_StoreBatteryStatus      Device: HmIP_HZ_Wohnzimmer       Event: battery: low      Model: undef
2021.12.03 16:12:35 1: my_StoreBatteryStatus      Device: T.Bad       Event: battery: ok      Model: undef
2021.12.03 16:12:36 1: my_StoreBatteryStatus      Device: HmIP_FT_Gaestezimmer       Event: battery: ok      Model: undef
2021.12.03 16:12:36 1: my_StoreBatteryStatus      Device: HmIP_FT_Gaestezimmer       Event: battery: ok      Model: undef
2021.12.03 16:12:37 1: my_StoreBatteryStatus      Device: T.Gast       Event: battery: ok      Model: undef
2021.12.03 16:12:38 1: my_StoreBatteryStatus      Device: T.Wohn       Event: battery: ok      Model: undef
2021.12.03 16:12:40 1: my_StoreBatteryStatus      Device: T.Bad       Event: battery: ok      Model: undef
2021.12.03 16:12:43 1: my_StoreBatteryStatus      Device: T.Wohn       Event: battery: ok      Model: undef
2021.12.03 16:12:45 1: my_StoreBatteryStatus      Device: T.Bad       Event: battery: ok      Model: undef
2021.12.03 16:12:47 1: my_StoreBatteryStatus      Device: T.Gast       Event: battery: ok      Model: undef
2021.12.03 16:12:48 1: my_StoreBatteryStatus      Device: T.Wohn       Event: battery: ok      Model: undef
2021.12.03 16:12:51 1: my_StoreBatteryStatus      Device: T.Buero       Event: battery: ok      Model: undef
2021.12.03 16:12:53 1: my_StoreBatteryStatus      Device: T.Schlaf       Event: battery: ok      Model: undef
2021.12.03 16:13:01 1: my_StoreBatteryStatus      Device: T.Buero       Event: battery: ok      Model: undef
2021.12.03 16:13:03 1: my_StoreBatteryStatus      Device: T.Schlaf       Event: battery: ok      Model: undef
2021.12.03 16:13:11 1: my_StoreBatteryStatus      Device: T.Buero       Event: battery: ok      Model: undef
2021.12.03 16:13:13 1: my_StoreBatteryStatus      Device: T.Schlaf       Event: battery: ok      Model: undef
2021.12.03 16:13:21 1: my_StoreBatteryStatus      Device: HmIP_STHD_Wohnzimmer       Event: battery: ok      Model: undef
2021.12.03 16:13:22 1: my_StoreBatteryStatus      Device: HmIP_STHD_Schlafzimmer       Event: battery: ok      Model: undef
2021.12.03 16:13:23 1: my_StoreBatteryStatus      Device: T.Wohn       Event: battery: ok      Model: undef
2021.12.03 16:13:25 1: my_StoreBatteryStatus      Device: T.Bad       Event: battery: ok      Model: undef
2021.12.03 16:13:27 1: my_StoreBatteryStatus      Device: T.Gast       Event: battery: ok      Model: undef
2021.12.03 16:13:30 1: my_StoreBatteryStatus      Device: T.Bad       Event: battery: ok      Model: undef
2021.12.03 16:13:33 1: my_StoreBatteryStatus      Device: T.Wohn       Event: battery: ok      Model: undef
2021.12.03 16:13:35 1: my_StoreBatteryStatus      Device: T.Bad       Event: battery: ok      Model: undef
2021.12.03 16:13:37 1: my_StoreBatteryStatus      Device: T.Gast       Event: battery: ok      Model: undef
2021.12.03 16:13:40 1: my_StoreBatteryStatus      Device: T.Bad       Event: battery: ok      Model: undef
2021.12.03 16:13:43 1: my_StoreBatteryStatus      Device: T.Wohn       Event: battery: ok      Model: undef
2021.12.03 16:13:47 1: my_StoreBatteryStatus      Device: T.Gast       Event: battery: ok      Model: undef
2021.12.03 16:13:50 1: my_StoreBatteryStatus      Device: T.Bad       Event: battery: ok      Model: undef
2021.12.03 16:13:51 1: my_StoreBatteryStatus      Device: T.Buero       Event: battery: ok      Model: undef
2021.12.03 16:13:53 1: my_StoreBatteryStatus      Device: T.Schlaf       Event: battery: ok      Model: undef
2021.12.03 16:14:01 1: my_StoreBatteryStatus      Device: T.Buero       Event: battery: ok      Model: undef
2021.12.03 16:14:03 1: my_StoreBatteryStatus      Device: T.Schlaf       Event: battery: ok      Model: undef
2021.12.03 16:14:11 1: my_StoreBatteryStatus      Device: T.Buero       Event: battery: ok      Model: undef
2021.12.03 16:14:13 1: my_StoreBatteryStatus      Device: T.Schlaf       Event: battery: ok      Model: undef
2021.12.03 16:14:14 1: my_StoreBatteryStatus      Device: HmIP_AT_Balkon       Event: battery: ok      Model: undef
2021.12.03 16:14:14 1: my_StoreBatteryStatus      Device: HmIP_AT_Balkon       Event: battery: ok      Model: undef
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 03 Dezember 2021, 16:30:53
Ok, habe LaCrosse auch mal integriert (so ich denek)...
...also obigen Code angepasst/erweitert.

Bin gespannt, ob es tut...

Logausgaben wie erwartet... 8)

EDIT: du kannst nun das '#' wieder vor die Logzeile machen ;)

EDIT: ich weiß nicht, ob Amenophis86 das hier noch pflegt. Evtl. schaue ich mal noch mal drüber (da kann man bestimmt einiges vereinfachen/zusammenfassen) und melde das auf GIT irgendwie...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: DonJuan am 03 Dezember 2021, 20:44:57
Vielen Dank, Joachim. Eingespielt und schon tauchten die Geräte auf.

Jetzt muss ich mal abwarten und gucken, wann die "schwache" Batterie angezeigt wird. Im Moment behauptet das System noch, dass die Batterien i. O. sind.

Gruss Dennis
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 03 Dezember 2021, 21:19:39
Zitat von: DonJuan am 03 Dezember 2021, 20:44:57
Vielen Dank, Joachim. Eingespielt und schon tauchten die Geräte auf.

Jetzt muss ich mal abwarten und gucken, wann die "schwache" Batterie angezeigt wird. Im Moment behauptet das System noch, dass die Batterien i. O. sind.

Gruss Dennis

Schön, freut mich! :)

Du kannst die Nachricht ja simulieren:


setreading Devicename battery low


also z.B.:

setreading T.Buero battery low

Wird ja mit dem nächsten Update wieder "korrigiert"...

WOBEI: ich bin halt mal von "ok" und "low" ausgegangen... Wenn die Geräte andere "Werte" liefern, dann muss ich "nachbessern" und du mir nat. mitteilen was bei "leerer Batterie" im reading steht...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 03 Dezember 2021, 23:24:58
Danke Joachim fürs übernehmen. Da ich bei mir mit dem neuen Haus auf KNX umgestellt habe, habe ich hier sehr wenig gemacht und aktuell andere Prios. Sollte sich jemand anbieten können wir den Thread gerne schließen und auf eine neue Version verweisen, die weiter gepflegt wird.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: DonJuan am 04 Dezember 2021, 00:24:08
So, ein "kleiner" Fehler war noch drin. Jedenfalls hatte ich eine "}" zuviel. Daher funktionierte die Benachrichtigung per Telegram nicht. Ansonsten funktioniert es nun.

Ich kopiere hier mal den ganzen Code rein. So für den Fall der Fälle.
Danke nochmal.

#########################################################################
# Helper for readingsGroup BatteryStatus:
# reads the battery states of devices and
# calculates the battery state in percent (depending on device type) and
# stores it as reading in corresponding dummy device
sub BatteryStatusFunction($$)
{
  my ($Device, $Event)  = @_;
  my @BatteryType = split(/:/,$Event); # to distinguish between "battery" and "batteryLevel" devices
  my $Model = AttrVal($Device, "model", "undef"); # get the corresponding model type
  my $TYPE = InternalVal($Device, "TYPE", "undef"); # MAX!
  my $ActBatLevel = 0.0;
  my $MinBatLevel = 0.0;
  my $RemainingVoltageQuater = 0.0; # for "calculating" the colors
  my $MaxBattery = 3.1; # two 1.5V batteries have a measured voltage of 3.1V or even 3.2V
  my @DeviceNameParts = split(/_/,$Device); # to filter out HM_ Devices from neighbor or test system or newly included ones
  my $SignalDevice = $Device . "_BatState";

###############################
# Here you can change the variables to fit your installation.
#
  my $text_now = "Die Batterien von $Device müssen JETZT gewechselt werden!"; #Text for changing battery now
  my $text_soon = "Die Batterien von $Device sollten bald gewechselt werden!"; #Text for changing battery soon
  my $text_changed = "Batterie zuletzt gewechselt: "; #Text for last change
  my $BatteryStatus = "BatterieStatus"; #Name of the Dummy for status
  my $BatteryStatusBot = "BatterieStatusBot"; #Name of the Dummy for status of send messages
  my $BatteryChanged = "BatterieWechsel"; #Name of the Dummy for battery changed information

################################
# Here you choos your message device and how to send
# comment the device you do not want to use
#
# TelegramBot
  my $msg = "set TelegramBot message \@\@User ";
#
# msg-command
# my $msg = "msg \@User title='Battery Check' ";
#
# Pushover
# my $msg = "set Pushover msg device=User title='Battery Check' ";


 
# Log3(undef, 1, "my_StoreBatteryStatus      Device: $Device       Event: $Event      Model: $Model");
 
  # ignoring Devices that were just created by autocreate
  #if($DeviceNameParts[0] eq "HM" || $DeviceNameParts[0] eq "ZWave" || $DeviceNameParts[0] eq "MAX")
  #{
  #  Log3(undef, 1, "my_StoreBatteryStatus      ignoring Device: $Device");
  #  return;
  #}

  # if it is the first time for that device set it to none (initialize)
  if(ReadingsVal($BatteryStatusBot, $SignalDevice, "undef") eq "undef")
  {
    fhem("setreading $BatteryStatusBot $SignalDevice none");
  }
   
  # actually only devices HM-TC-IT-WM-W-EU and HM-CC-RT-DN have battery level and min-level
  # so calculating the percentage of actual level depending on min-level
  # all others just have battery ok or nok
  # IMPORTANT: first filter those which only send "battery" in EVENT
  #            then calculate for those which send "batteryLevel"!
  #            New devices: ZWave. They deliver battery already in percentage.
  #            New devices: XiaomiFlowerSens. They also deliver batteryLevel but already in percentage.

  ##############################################
  # HM Devices with battery
  ##############################################
  if($BatteryType[0] eq "battery"  && $Model ne "HM-TC-IT-WM-W-EU" && $Model ne "HM-CC-RT-DN" && $Model ne "undef")
  {
    if(ReadingsVal($Device, "battery", "low") eq "ok")
    {
      # check if battery was low before -> possibly changed
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $BatteryChanged $Device $text_changed");
        # set the signal state back to none
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }

      # status is "ok" so we set to 100% (we don't know better)
      fhem("setreading $BatteryStatus $Device 100");
    }
    else
    {
      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }

      # status is NOT "ok" ("low") so we set to 0% (we don't know better)
      fhem("setreading $BatteryStatus $Device 0");
    }
  }
  ##############################################
  # HM Devices with batteryLevel
  ##############################################
  elsif($BatteryType[0] eq "batteryLevel"  && $Model ne "undef")
  {
    $ActBatLevel = ReadingsVal($Device, "batteryLevel", "0.0");
    $MinBatLevel = ReadingsNum($Device, "R-lowBatLimitRT", "0.0");
    $RemainingVoltageQuater = ($MaxBattery - $MinBatLevel) / 4; # to get 4 quaters for different colours and icons

    if(($ActBatLevel - $MinBatLevel) > (3 * $RemainingVoltageQuater))
    {
      # check if battery was low before -> possibly changed
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $BatteryChanged $Device $text_changed");
        # set the signal state back to none
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }

      # set battery value to 100%
      fhem("setreading $BatteryStatus $Device 100");
    }
    elsif(($ActBatLevel - $MinBatLevel) > (2 * $RemainingVoltageQuater))
    {
      # between 50% and 75%
      fhem("setreading $BatteryStatus $Device 75");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif(($ActBatLevel - $MinBatLevel) > (1 * $RemainingVoltageQuater))
    {
      # between 25% and 50%
      fhem("setreading $BatteryStatus $Device 50");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif(($ActBatLevel - $MinBatLevel) > (0 * $RemainingVoltageQuater))
    {
      # check for critical stuff
      if(ReadingsVal($Device, "motorErr", "ok") eq "lowBat" || ReadingsVal($Device, "motorErr", "ok") eq "ValveErrorPosition")
      {
        # empty!
        fhem("setreading $BatteryStatus $Device 0");
        # check if message was already sent
        if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
        {
          # set signal state to low
          fhem("setreading $BatteryStatusBot $SignalDevice low");
          #send message via TelegramBot
          if(ReadingsVal($Device, "motorErr", "ok") eq "ValveErrorPosition")
          {
            fhem($msg." ".$text_now);
          }
          else
          {
            fhem($msg." ".$text_soon);
          }
        }
      }
      else
      {
        # between 0% and 25%
        fhem("setreading $BatteryStatus $Device 25");
      }
    }
    else
    {
      # totally empty
      fhem("setreading $BatteryStatus $Device 0");

      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }
    }
  }
  ##############################################
  # ZWave Devices
  ##############################################
elsif($BatteryType[0] eq "battery"  && InternalVal($Device, "TYPE", "undef") eq "ZWave")
{
   if(ReadingsVal($Device, "battery", "na") eq "low")
{
     $ActBatLevel = 0;
}
else
{
    $ActBatLevel = ReadingsNum($Device, "battery", "0");
}

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
     {
       fhem("setreading $BatteryChanged $Device $text_changed");
     }

     # set the battery value to 75% - 100%
     fhem("setreading $BatteryStatus $Device 100");

     # set the signal state back to none
     fhem("setreading $BatteryStatusBot $SignalDevice none");
   }
   elsif($ActBatLevel > 50)
   {
    # between 50% and 75%
     fhem("setreading $BatteryStatus $Device 75");

     # set the signal state back to none
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
     {
       fhem("setreading $BatteryStatusBot $SignalDevice none");
     }
   }
   elsif($ActBatLevel > 25)
   {
     # between 25% and 50%
     fhem("setreading $BatteryStatus $Device 50");

     # set the signal state back to none
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
     {
       fhem("setreading $BatteryStatusBot $SignalDevice none");
     }
   }
   elsif($ActBatLevel > 5)
   {
     # between 5% and 25%
     fhem("setreading $BatteryStatus $Device 25");

     # maybe already send a message! Easy possible with new signal states
   }
   else
   {
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
     # totally empty (below 5%)
     fhem("setreading $BatteryStatus $Device 0");

     # check if message was already sent
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
     {
       # set signal state to low
       fhem("setreading $BatteryStatusBot $SignalDevice low");
       #send message via TelegramBot
       fhem($msg." ".$text_soon);
     }
   }
}
  #############################################
  # XiaomiFlowerSens Devices
  #############################################
elsif($BatteryType[0] eq "batteryLevel"  && InternalVal($Device, "TYPE", "undef") eq "XiaomiFlowerSens")
{
   $ActBatLevel = ReadingsNum($Device, "batteryLevel", "0");

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        fhem("setreading $BatteryChanged $Device $text_changed");
      }

      # set the battery value to 75% - 100%
      fhem("setreading $BatteryStatus $Device 100");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 50)
    {
      # between 50% and 75%
      fhem("setreading $BatteryStatus $Device 75");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 25)
    {
      # between 25% and 50%
      fhem("setreading $BatteryStatus $Device 50");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 5)
    {
      # between 5% and 25%
      fhem("setreading $BatteryStatus $Device 25");

      # maybe already send a message! Easy possible with new signal states
    }
    else
    {
      # totally empty (below 5%)
      fhem("setreading $BatteryStatus $Device 0");

      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }
    }
  }
 
  ##############################################
  # MAX! Devices
  ##############################################
  elsif(($BatteryType[0] eq "battery")  && ($TYPE eq "MAX"))
  {
    if(ReadingsVal($Device, "battery", "low") eq "ok")
    {
      # check if battery was low before -> possibly changed
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low")
      {
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $BatteryChanged $Device $text_changed");
        # set the signal state back to none
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }

      # status is "ok" so we set to 100% (we don't know better)
      fhem("setreading $BatteryStatus $Device 100");
    }
    else
    {
      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }

      # status is NOT "ok" ("low") so we set to 0% (we don't know better)
      fhem("setreading $BatteryStatus $Device 0");
    }
  }
   ##############################################
  # HMCCU Devices
  ##############################################
elsif($BatteryType[0] eq "battery"  && (InternalVal($Device, "TYPE", "undef") eq "HMCCUDEV" || InternalVal($Device, "TYPE", "undef") eq "LaCrosse"))
  {
    if(ReadingsVal($Device, "battery", "low") eq "ok")
    {
      # check if battery was low before -> possibly changed
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $BatteryChanged $Device $text_changed");
        # set the signal state back to none
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }

      # status is "ok" so we set to 100% (we don't know better)
      fhem("setreading $BatteryStatus $Device 100");
    }
    else
    {
      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }

      # status is NOT "ok" ("low") so we set to 0% (we don't know better)
      fhem("setreading $BatteryStatus $Device 0");
    }
  }


##################################################
# Helper for readingsGroup BatteryStatus:
# sets the icon and icon color depending on "calculated" percentage value
sub SetBatterieIcon($$)
{
  my ($Device, $Value)  = @_;
  my $Icon = "measure_battery_" . "$Value"; # here the matching icon is "set"
  my $ActionDetectorDevice = "status_" . $Device;
  my $Name = ""; # name for signal state
  my $State = ReadingsVal("ActionDetector", $ActionDetectorDevice, "alive");

#  Log3(undef, 1, "my_SetBatteryIcon      Device: $Device       Value: $Value");

  if($State ne "alive")
  {
    $Icon = "message_attention\@red";
  }
  else
  {
    if($Value > 75)
    {
      $Icon = $Icon . "\@green"; # between 75% and 100%
    }
    elsif($Value > 25)
    {
      $Icon = $Icon . "\@orange"; # between 25% and 75%
    }
    else
    {
      $Icon = $Icon . "\@red"; # below 25%
    }
  }

  return $Icon;
}
}


Eine letzte Frage: Zum Senden mit Telegram steht in dem Code "\@\@User". Aber wenn ich da "\@\@<msgChat>" eintrage, dann bekomme ich im Log einen Fehler. Schreibe ich aber "\@<msgChatID>" dann funktioniert es. Ist das so richtig? Oder was versteht ihr unter
ZitatHier muss lediglich das Wort "User" durch den TelegramNamen des Empfängers geändert werden.
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 04 Dezember 2021, 09:25:35
Zitat von: DonJuan am 04 Dezember 2021, 00:24:08
So, ein "kleiner" Fehler war noch drin. Jedenfalls hatte ich eine "}" zuviel. Daher funktionierte die Benachrichtigung per Telegram nicht. Ansonsten funktioniert es nun.

Ich kopiere hier mal den ganzen Code rein. So für den Fall der Fälle.
Danke nochmal.


Ich hab meinen Code noch mal kontrolliert: der stimmt!! Vermutlich hast du falsch ANgefügt! Weil ich hatte ja geschrieben: einfach einen weiteren Block AN das letzte MAX! dran.
Also NACH dem MAX! Block aber VOR die letzte schließende Klammer der Sub (so war MEINE Idee).
Ich bin fast sicher, dass dein komplett geposteter Code einen Fehler hat?
(ich werde dann in Ruhe die Klammern noch mal checken aber auf den ersten schnellen Blick meldet mein Editor einen "Klammer-Mismatch")

EDIT: in deinem Gesamt-Post ist definitiv ein Fehler drin!! Bei dir ist die Readingsgroup-Sub IN der Batterie-Sub "mit drin"! Das muss eigentlich einen Fehler geben?

EDIT: in dem was im ersten Post verlinkt ist nach git (und da habe ich meine Erweiterungsgrundlage her) sind ZWEI subs drin! Korrigiere: DREI subs. D.h. der Block von mir muss einfach ans Ende der ersten Sub, bevor diese die schließende Klammer hat...


Zitat von: DonJuan am 04 Dezember 2021, 00:24:08
Eine letzte Frage: Zum Senden mit Telegram steht in dem Code "\@\@User". Aber wenn ich da "\@\@<msgChat>" eintrage, dann bekomme ich im Log einen Fehler. Schreibe ich aber "\@<msgChatID>" dann funktioniert es. Ist das so richtig? Oder was versteht ihr unter

Hmm, wie gesagt der Code ist nicht ganz von mir aber ich würde denken, dass dort die PEER-ID oder der PEER-User-Name hin muss...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 04 Dezember 2021, 09:43:30
Zitat von: Amenophis86 am 03 Dezember 2021, 23:24:58
Danke Joachim fürs übernehmen.

Gerne :)

Zitat von: Amenophis86 am 03 Dezember 2021, 23:24:58
Da ich bei mir mit dem neuen Haus auf KNX umgestellt habe, habe ich hier sehr wenig gemacht und aktuell andere Prios. Sollte sich jemand anbieten können wir den Thread gerne schließen und auf eine neue Version verweisen, die weiter gepflegt wird.

Hmmm, pflegen, neuer Thread.
Da müsste man wohl erst mal zusammensammeln was bislang alles erweitert wurde.
Hab den Thread ja nur so nebenbei verfolgt...

Ich würde das hier einfach mal weiterlaufen lassen...

Klappt doch ganz gut?

Weil in ein Modul gießen wird wohl (von deiner Seite) nicht mehr passieren...
...und ich habe ehrlich gesagt auch nicht die Zeit für ein Modul und auch nicht wirklich die Fähigkeit für ein gutes Modul.

Wenn ich mir das doch überlegen sollte, dann kann man immer noch neu machen...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Amenophis86 am 04 Dezember 2021, 10:15:33
Können wir auch so machen. Ich schaue hier ja auch regelmäßig rein und versuche zu helfen. Vielleicht findet sich ja irgendwann jemand, der es angehen möchte :)
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: DonJuan am 04 Dezember 2021, 17:26:45
Zitat von: MadMax-FHEM am 04 Dezember 2021, 09:25:35
Ich hab meinen Code noch mal kontrolliert: der stimmt!! Vermutlich hast du falsch ANgefügt! Weil ich hatte ja geschrieben: einfach einen weiteren Block AN das letzte MAX! dran.
Also NACH dem MAX! Block aber VOR die letzte schließende Klammer der Sub (so war MEINE Idee).
Ich bin fast sicher, dass dein komplett geposteter Code einen Fehler hat?
(ich werde dann in Ruhe die Klammern noch mal checken aber auf den ersten schnellen Blick meldet mein Editor einen "Klammer-Mismatch")

EDIT: in deinem Gesamt-Post ist definitiv ein Fehler drin!! Bei dir ist die Readingsgroup-Sub IN der Batterie-Sub "mit drin"! Das muss eigentlich einen Fehler geben?

EDIT: in dem was im ersten Post verlinkt ist nach git (und da habe ich meine Erweiterungsgrundlage her) sind ZWEI subs drin! Korrigiere: DREI subs. D.h. der Block von mir muss einfach ans Ende der ersten Sub, bevor diese die schließende Klammer hat...


Hmm, wie gesagt der Code ist nicht ganz von mir aber ich würde denken, dass dort die PEER-ID oder der PEER-User-Name hin muss...

Gruß, Joachim

Na guck mal einer an. Grade nochmal in den Editor geguckt und tatsächlich eine Klammer zu wenig. Selbige wurde mir gestern als zuviel angezeigt. Ok. Nun sollten wir es haben.

Gruss Dennis
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Fredi69 am 24 Januar 2022, 12:32:14
Zitat von: MadMax-FHEM am 03 Dezember 2021, 16:30:53
Ok, habe LaCrosse auch mal integriert (so ich denek)...
...also obigen Code angepasst/erweitert.

Bin gespannt, ob es tut...
Wo kann ich den aktuellen Code inkl. LaCrosse finden?

Vielen Dank
Fredi
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 24 Januar 2022, 13:04:22
Zitat von: Fredi69 am 24 Januar 2022, 12:32:14
Wo kann ich den aktuellen Code inkl. LaCrosse finden?

Vielen Dank
Fredi

Also entweder aus git die aktuelle laden (da ist aber verm. LaCrosse noch nicht drin?) und dann das hier ergänzen: https://forum.fhem.de/index.php/topic,82637.msg1190831.html#msg1190831
(also einen weiteren Block ähnlich der anderen Device-Typen "an-/einfügen")

Oder den Code von hier nehmen: https://forum.fhem.de/index.php/topic,82637.msg1191026.html#msg1191026

Habe aber nicht mehr drüber geschaut, ob da der Klammerfehler noch drin oder schon raus ist...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Fredi69 am 24 Januar 2022, 16:10:24
Vielen Dank für die, wie so oft, schnelle Unterstützung.

Folgende Fragen habe ich noch.
1. Die Hue Devices werden aktuell noch nicht unterstützt, oder?
Hier ein List:
Internals:
   DEF        sensor 12  IODev=HUEBridge01
   FUUID      61edfd0e-f33f-0af0-cfb6-305e5233c5215efe
   FVERSION   31_HUEDevice.pm:0.255380/2022-01-21
   ID         S12
   INTERVAL   
   IODev      HUEBridge01
   NAME       HUESensor12
   NR         625
   STATE      4002
   TYPE       HUEDevice
   has_v2_api 1
   inputs     4
   manufacturername Signify Netherlands B.V.
   modelid    RWL021
   name       Hue dimmer switch Terrasse
   on         1
   productname Hue dimmer switch
   reachable  1
   swversion  6.1.1.28573
   type       ZLLSwitch
   uniqueid   00:17:88:01:08:05:c8:89-02-fc00
   v2_id      33f017a9-6a7a-4e90-8c9e-1c4afc05337b
   Helper:
     DBLOG:
       battery:
         MyDBlog:
           TIME       1643035325.80401
           VALUE      95
       batteryPercent:
         MyDBlog:
           TIME       1643035325.80401
           VALUE      95
       batteryState:
         MyDBlog:
           TIME       1643035325.80401
           VALUE      normal
   READINGS:
     2022-01-24 13:46:46   IODev           HUEBridge01
     2022-01-24 15:42:05   battery         95
     2022-01-24 15:42:05   batteryPercent  95
     2022-01-24 15:42:05   batteryState    normal
     2022-01-18 21:46:22   reachable       1
     2022-01-18 21:46:22   state           4002
   helper:
     devtype    S
     update_timeout 1
     capabilities:
       inputs:
         HASH(0x69bb938)
         HASH(0x69bbb60)
         HASH(0x69bbd88)
         HASH(0x69bbfb0)
     configList:
     events:
       HASH(0x6a0b1e0)
       HASH(0x6a0b2a0)
       HASH(0x6a0b3d8)
       HASH(0x6a0b468)
     json:
       diversityid 73bbabea-3420-499a-9856-46bf437e119b
       manufacturername Signify Netherlands B.V.
       modelid    RWL021
       name       Hue dimmer switch Terrasse
       productname Hue dimmer switch
       swversion  6.1.1.28573
       type       ZLLSwitch
       uniqueid   00:17:88:01:08:05:c8:89-02-fc00
       capabilities:
         inputs:
           HASH(0x6d62310)
           HASH(0x6f78558)
           HASH(0x6ee6070)
           HASH(0x6eda898)
       config:
         battery    95
         pending:
       state:
         buttonevent 4002
         lastupdated 2022-01-18T20:46:22
       swupdate:
         lastinstall 2020-05-26T22:16:53
         state      noupdates
     setList:
Attributes:
   IODev      HUEBridge01
   alias      Hue dimmer switch Terrasse
   group      HUESensor
   icon       hue_filled_hds
   model      RWL021
   room       HUEDevice


2. Wie kann man bei der Pushmsg und der ReadingsGroup den Alias anstatt den Namen ausgeben?

3. Bei zwei Homematic Geräten (HM-SEN-MDIR-SM) habe ich ein rotes Ausrufezeichen in der Readingsgroup, obwohl battery ok ist.

Vielen Dank
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 24 Januar 2022, 16:48:10
HUEDevice ist wohl noch nicht drin...
...also in dem was auf GitHub liegt.

Ob es irgendwo im Thread-Verlauf schon (mal) ergänzt wurde: keine Ahnung :-\

Du könntest folgendes versuchen:


  ##############################################
  # ZWave Devices
  ##############################################
elsif($BatteryType[0] eq "battery"  && InternalVal($Device, "TYPE", "undef") eq "ZWave")
{
   if(ReadingsVal($Device, "battery", "na") eq "low")
{
     $ActBatLevel = 0;
}
else
{
    $ActBatLevel = ReadingsNum($Device, "battery", "0");
}


durch das hier zu ersetzen/ergänzen:


  ##############################################
  # ZWave Devices
  ##############################################
elsif($BatteryType[0] eq "battery"  && (InternalVal($Device, "TYPE", "undef") eq "ZWave" || InternalVal($Device, "TYPE", "undef") eq "HUEDevice"))


Der Rest sollte ja ähnlich der ZWave sein, so ich das dem list richtig entnommen habe.

Es kann halt höchstens sein, dass die für ZWave angenommenen "Low-Level" (und damit Nachrichtenversand) halt nicht für die ZigBee Geräte passen.
Dann müsste man den ganzen Zweig kopieren und eben als neuen Typ anfügen...

Aber das mit dem Level bei Geräten, die Prozent o.ä. melden (und kein low etc.) ist eh schwierig festzulegen.

Für ZWave habe ich das nur "empirisch" mit meinen Rauchmeldern/"Augen" ermittelt...

Poste doch mal ein list der Homematic-Devices.

EDIT: bzgl. Alias statt Name. Evtl. hier

###############################
# Here you can change the variables to fit your installation.
#
  my $text_now = "Die Batterien von $Device müssen JETZT gewechselt werden!"; #Text for changing battery now
  my $text_soon = "Die Batterien von $Device sollten bald gewechselt werden!"; #Text for changing battery soon


mal das einbauen:


###############################
# Here you can change the variables to fit your installation.
#
my $SendName = $Device;
if(AttrVal($Device, "alias", "n.a.") ne "n.a.")
{
  $SendName  = AttrVal($Device, "alias", "n.a.");
}

  my $text_now = "Die Batterien von $SendName müssen JETZT gewechselt werden!"; #Text for changing battery now
  my $text_soon = "Die Batterien von $SendName sollten bald gewechselt werden!"; #Text for changing battery soon


Bei ReadingsGroup gibt es das Mapping-Attribut, vielleicht hilft das. Evtl. brauchst du aber da auch eine Sub, die eben schaut, ob es einen alias gibt und dann den "setzt" und ansonsten Name (oder was eben aktuell in der RG steht) zurück gibt...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Fredi69 am 24 Januar 2022, 19:31:02
Erstmal herzlichen Dank, ich muss mich mal damit auseinandersetzten und melde mich wieder.
Zitat von: MadMax-FHEM am 24 Januar 2022, 16:48:10...
Poste doch mal ein list der Homematic-Devices.
...


Internals:
   CUL_0_MSGCNT 11
   CUL_0_RAWMSG A0DD2A6416AABA42CD994019A0060::-66:CUL_0
   CUL_0_RSSI -66
   CUL_0_TIME 2022-01-24 19:20:19
   DEF        6AABA4
   FUUID      5e70d1ab-f33f-0af0-8758-af129eb92a7578b2
   HMLAN1_MSGCNT 11
   HMLAN1_RAWMSG E6AABA4,0000,00B24B5F,FF,FFB9,D2A6416AABA42CD994019A0060
   HMLAN1_RSSI -71
   HMLAN1_TIME 2022-01-24 19:20:19
   HMLAN2_MSGCNT 11
   HMLAN2_RAWMSG E6AABA4,0000,4DA922E9,FF,FFC2,D2A6416AABA42CD994019A0060
   HMLAN2_RSSI -62
   HMLAN2_TIME 2022-01-24 19:20:19
   HMLAN3_MSGCNT 10
   HMLAN3_RAWMSG E6AABA4,0000,75A77186,FF,FFBB,D2A6416AABA42CD994019A0060
   HMLAN3_RSSI -69
   HMLAN3_TIME 2022-01-24 19:20:19
   IODev      CUL_0
   LASTInputDev HMLAN2
   MSGCNT     43
   NAME       Aussen_Garten_Bewegungmelder_Haustuer
   NR         553
   NTFY_ORDER 48-Aussen_Garten_Bewegungmelder_Haustuer
   STATE      noMotion
   TYPE       CUL_HM
   chanNo     01
   disableNotifyFn 1
   lastMsg    No:D2 - t:41 s:6AABA4 d:2CD994 019A0060
   protLastRcv 2022-01-24 19:20:19
   protRcv    9 last_at:2022-01-24 19:20:19
   protSnd    9 last_at:2022-01-24 19:20:19
   protState  CMDs_done
   rssi_at_CUL_0 cnt:11 min:-66 max:-59.5 avg:-61.68 lst:-66
   rssi_at_HMLAN1 cnt:11 min:-71 max:-66 avg:-68.18 lst:-71
   rssi_at_HMLAN2 cnt:11 min:-79 max:-58 avg:-70.81 lst:-62
   rssi_at_HMLAN3 cnt:10 min:-76 max:-69 avg:-73.2 lst:-69
   Helper:
     DBLOG:
       battery:
         MyDBlog:
           TIME       1643048419.46738
           VALUE      ok
       brightness:
         MyDBlog:
           TIME       1643048419.46738
           VALUE      0
       motion:
         MyDBlog:
           TIME       1643048481.28878
           VALUE      off
       motionCount:
         MyDBlog:
           TIME       1643048419.46738
           VALUE      154_next:60s
       motionDuration:
         MyDBlog:
           TIME       1643048481.28878
           VALUE      62
   READINGS:
     2022-01-24 19:23:03   Activity        alive
     2020-03-18 12:33:32   CommandAccepted yes
     2020-03-17 14:36:01   D-firmware      1.6
     2020-03-17 14:36:01   D-serialNr      PEQ0659029
     2022-01-24 19:20:19   IODev           CUL_0
     2020-03-18 12:43:35   PairedTo        0x2CD994
     2020-03-18 12:33:29   R-brightFilter  7
     2020-03-18 12:33:29   R-captInInterval off
     2020-03-18 12:33:29   R-evtFltrNum    1
     2020-03-18 12:33:29   R-evtFltrPeriod 1 s
     2020-03-18 12:43:36   R-minInterval   60
     2020-03-17 14:36:02   R-pairCentral   0x2CD994
     2020-03-18 12:33:29   R-sign          off
     2020-03-18 12:43:35   RegL_00.        00:00 02:01 0A:2C 0B:D9 0C:94
     2020-03-18 12:43:36   RegL_01.        00:00 01:12 02:72 08:00 22:00
     2022-01-24 19:20:19   battery         ok
     2022-01-24 19:20:19   brightness      0
     2021-08-09 22:51:26   cfgState        ok
     2022-01-24 19:20:19   commState       CMDs_done
     2022-01-24 19:21:21   motion          off
     2022-01-24 19:20:19   motionCount     154_next:60s
     2022-01-24 19:21:21   motionDuration  62
     2022-01-24 19:21:21   state           noMotion
     2022-01-24 19:20:19   trigger_cnt     154
   helper:
     HM_CMDNR   210
     lastMsgTm  1643048419.27872
     mId        005D
     peerFriend peerAct,peerVirt
     peerIDsState complete
     peerOpt    4:motionDetector
     regLst     0,1,4p
     rxType     28
     supp_Pair_Rep 0
     ack:
     cmds:
       TmplKey    :no:1643037182.58033
       TmplTs     1643037182.58033
       cmdKey     1:1:0::Aussen_Garten_Bewegungmelder_Haustuer:005D:01:
       cmdLst:
         assignHmKey noArg
         clear      [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         peerChan   -btnNumber- -actChn- [({single})] [({set}|unset)] [actor|remote|both]
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         sign       [(on|{off})]
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         trgEventL  -peer- -condition-
         trgEventS  -peer- -condition-
         trgPressL  [(-peer-|{all})]
         trgPressS  [(-peer-|{all})]
         unpair     noArg
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       flgs       0
       newChn     +6AABA4,00,00,00
       nextSend   1643048419.43768
       rxt        2
       vccu       VCCU
       p:
         6AABA4
         00
         00
         00
       prefIO:
         CUL_0
     mRssi:
       mNo        D2
       io:
         CUL_0:
           -62
           -62
         HMLAN1:
           -71
           -71
         HMLAN2:
           -62
           -62
         HMLAN3:
           -69
           -69
     peerIDsH:
       00000000   broadcast
     prt:
       bErr       0
       sProc      0
       sleeping   1
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rpt:
       IO         CUL_0
       flg        A
       ts         1643048419.27872
       ack:
         HASH(0x6223cb8)
         D280022CD9946AABA401010000
     rssi:
       at_CUL_0:
         avg        -61.6818181818182
         cnt        11
         lst        -66
         max        -59.5
         min        -66
       at_HMLAN1:
         avg        -68.1818181818182
         cnt        11
         lst        -71
         max        -66
         min        -71
       at_HMLAN2:
         avg        -70.8181818181818
         cnt        11
         lst        -62
         max        -58
         min        -79
       at_HMLAN3:
         avg        -73.2
         cnt        10
         lst        -69
         max        -69
         min        -76
     tmpl:
Attributes:
   DbLogInclude brightness
   IOgrp      VCCU:CUL_0
   actCycle   000:10
   actStatus  alive
   alias      Bewegungsmelder Haustür
   autoReadReg 4_reqStatus
   comment    Inbetriebnahme: 17.03.2020
   expert     defReg,rawReg
   firmware   1.6
   group      Bewegungsmelder
   icon       people_sensor
   model      HM-SEN-MDIR-SM
   peerIDs    00000000
   room       Aussen,Übersicht
   serialNr   PEQ0659029
   showtime   1
   subType    motionDetector
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 24 Januar 2022, 21:30:53
Hm das mit den Homematic kann eigentlich nur durch den ActionDetector kommen...

Es steht zwar im list "alive" aber evtl. ist irgendwas "falsch" beim ActionDetector...

Eine andere Erklärung habe ich aktuell nicht.

Wie zu Beginn des Posts geschrieben steht stammt der Code von mir und ist halt an manchen Stellen (sehr) speziell an meine "Umgebung"...

Du kannst auch den ActionDetector-Teil rauslassen, also:


##################################################
# Helper for readingsGroup BatteryStatus:
# sets the icon and icon color depending on "calculated" percentage value
sub SetBatterieIcon($$)
{
  my ($Device, $Value)  = @_;
  my $Icon = "measure_battery_" . "$Value"; # here the matching icon is "set"
  my $ActionDetectorDevice = "status_" . $Device;
  my $Name = ""; # name for signal state
  my $State = ReadingsVal("ActionDetector", $ActionDetectorDevice, "alive");

#  Log3(undef, 1, "my_SetBatteryIcon      Device: $Device       Value: $Value");

  if($State ne "alive")
  {
    $Icon = "message_attention\@red";
  }
  else
  {
    if($Value > 75)
    {
      $Icon = $Icon . "\@green"; # between 75% and 100%
    }
    elsif($Value > 25)
    {
      $Icon = $Icon . "\@orange"; # between 25% and 75%
    }
    else
    {
      $Icon = $Icon . "\@red"; # below 25%
    }
  }

  return $Icon;
}


dann einfach so:


##################################################
# Helper for readingsGroup BatteryStatus:
# sets the icon and icon color depending on "calculated" percentage value
sub SetBatterieIcon($$)
{
  my ($Device, $Value)  = @_;
  my $Icon = "measure_battery_" . "$Value"; # here the matching icon is "set"

#  Log3(undef, 1, "my_SetBatteryIcon      Device: $Device       Value: $Value");

    if($Value > 75)
    {
      $Icon = $Icon . "\@green"; # between 75% and 100%
    }
    elsif($Value > 25)
    {
      $Icon = $Icon . "\@orange"; # between 25% and 75%
    }
    else
    {
      $Icon = $Icon . "\@red"; # below 25%
    }

  return $Icon;
}


Wenn ich mich nicht "vertippt" hab...

Das mit dem ActionDetector hilft halt, falls ein Device/Gerät es nicht mehr geschafft hat eine leere Batterie zu melden, dann merkt das ja irgendwann der ActionDetector und dann ist da eben das Ausrufezeichen :)

Stammt noch vom Beginn, also ich (fast) nur Homematic hatte...
...mittlerweile habe ich das stellenweise anders/zusätzliche Dinge.
Evtl. müsste man das (wie den gesamten Code) mal "verbessern"...

Aber dafür fehlt dann doch leider die Zeit.
Mal sehen...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Kohle77 am 19 Oktober 2022, 12:02:00
Hallo,
aus https://forum.fhem.de/index.php/topic,129736.msg1240072.html#msg1240072 (https://forum.fhem.de/index.php/topic,129736.msg1240072.html#msg1240072) kam die Idee das ich ein List meiner devices hier poste damit diese vielleicht integriert werden.
Für den Shelly Fensterkontakt:
Internals:
   CFGFN      /opt/fhem/FHEM/CFG/13_mqtt.cfg
   FUUID      617a2729-f33f-d2f4-5e7e-67421914707b79af
   IODev      Mosquitto
   NAME       BueroChris
   NR         288
   STATE      close
   TYPE       MQTT_DEVICE
   eventCount 2
   READINGS:
     2022-10-19 08:18:46   IODev           Mosquitto
     2022-10-19 05:47:23   announce        {"id":"mibueoben","model":"SHDW-2","mac":"E8DB84D3BA82","ip":"192.168.178.32","new_fw":false,"fw_ver":"xxxxxxxx-yyyyyyy/va.bb.c-eeeeee12"}
     2022-10-19 05:47:23   batteryPercent  97
     2022-10-19 08:18:50   batteryState    ok
     2022-10-19 05:47:23   error           0
     2022-10-19 05:47:23   fw_ver          xxxxxxxx-yyyyyyy/va.bb.c-eeeeee12
     2022-10-19 05:47:23   id              mibueoben
     2022-10-19 05:47:23   ip              190.132.150.32
     2022-10-19 05:47:23   mac             E7DA84B3BC92
     2022-10-19 05:47:23   model           SHDW-2
     2022-10-19 05:47:23   new_fw          0
     2022-10-19 05:48:54   online          false
     2022-10-17 10:01:35   state           close
     2022-10-19 08:18:50   transmission-state subscription acknowledged
   message_ids:
   sets:
   subscribe:
     shellies/mibueoben/announce
     shellies/mibueoben/sensor/battery
     shellies/mibueoben/sensor/error
     shellies/mibueoben/online
     shellies/mibueoben/sensor/state
   subscribeExpr:
     ^shellies\/mibueoben\/announce$
     ^shellies\/mibueoben\/sensor\/battery$
     ^shellies\/mibueoben\/sensor\/error$
     ^shellies\/mibueoben\/online$
     ^shellies\/mibueoben\/sensor\/state$
   subscribeQos:
     shellies/mibueoben/announce 0
     shellies/mibueoben/online 0
     shellies/mibueoben/sensor/battery 0
     shellies/mibueoben/sensor/error 0
     shellies/mibueoben/sensor/state 0
   subscribeReadings:
     shellies/mibueoben/announce:
       cmd       
       name       announce
     shellies/mibueoben/online:
       cmd       
       name       online
     shellies/mibueoben/sensor/battery:
       cmd       
       name       batteryPercent
     shellies/mibueoben/sensor/error:
       cmd       
       name       error
     shellies/mibueoben/sensor/state:
       cmd       
       name       state
Attributes:
   DbLogExclude .*
   alias      Fenster Büro Chris
   comment    IP: 190.132.150.32
   devStateIcon open:fts_window_1wbb_open@red close:fts_window_1w@black
   group      Chris Buero
   room       Buero Chris
   subscribeReading_announce shellies/mibueoben/announce
   subscribeReading_batteryPercent shellies/mibueoben/sensor/battery
   subscribeReading_error shellies/mibueoben/sensor/error
   subscribeReading_online shellies/mibueoben/online
   subscribeReading_state shellies/mibueoben/sensor/state
   userReadings batteryState { return "ok" if(ReadingsVal("BueroChris","batteryPercent","0"))>"25"; return "low"}
   userattr   subscribeReading_state subscribeReading_batteryPercent subscribeReading_error subscribeReading_announce subscribeReading_online


und für das Fritz!DECT 301 Heizkörperthermostat:
Internals:
   CFGFN      /opt/fhem/FHEM/CFG/21_heizung.cfg
   DEF        FritzSmart:09995_0702078 actuator,tempSensor
   FUUID      6006cddc-f33f-d2f4-8485-208a926f2f4ce162
   FritzSmart_MSGCNT 37
   FritzSmart_TIME 2022-10-19 11:18:49
   IODev      FritzSmart
   LASTInputDev FritzSmart
   MSGCNT     37
   NAME       HzMiChBu
   NR         400
   STATE      desired-temp: 14.0 C
   TYPE       FBDECT
   eventCount 37
   id         09995_0702078
   props      actuator,tempSensor
   webCmd     desired-temp
   READINGS:
     2022-10-19 11:18:49   AIN             09995 0702128
     2022-10-19 11:18:49   FBNAME          Büro Chris
     2022-10-19 11:18:49   FBPROP          actuator,tempSensor
     2022-10-19 11:18:49   FBTYPE          FRITZ!DECT 301
     2022-10-19 11:18:49   ID              20
     2022-10-19 08:18:46   IODev           FritzSmart
     2022-10-19 11:18:49   battery         80 %
     2022-10-19 11:18:49   batteryPercent  80
     2022-10-19 11:18:49   batteryState    ok
     2022-10-19 11:18:49   batterylow      0
     2022-10-19 11:18:49   boostactive     no
     2022-10-19 11:18:49   boostactiveendtime N/A
     2022-10-19 11:18:49   day-temp        21.0 C
     2022-10-19 11:18:49   desired-temp    14.0 C
     2022-10-19 11:18:49   devicelock      no
     2022-10-19 11:18:49   errorcode       noError (0)
     2022-10-19 11:18:49   fwversion       05.02
     2022-10-19 11:18:49   holidayactive   no
     2022-10-19 11:18:49   locked          no
     2022-10-19 11:18:49   nextPeriodStart 1970-01-01 01:00:00
     2022-10-19 11:18:49   nextPeriodTemp  21.0 C
     2022-10-19 11:18:49   night-temp      16.0 C
     2022-10-19 11:18:49   present         yes
     2022-10-19 11:18:49   state           desired-temp: 14.0 C
     2022-10-19 11:18:49   summeractive    no
     2022-10-19 11:18:49   tempadjust      0.0 C
     2022-10-19 11:18:49   temperature     22.5 C (measured)
     2022-10-19 11:18:49   windowopenactiv no
     2022-10-19 11:18:49   windowopenactiveendtime N/A
Attributes:
   DbLogExclude .*
   IODev      FritzSmart
   alias      Heizköper Büro
   event-min-interval power:120
   room       DG_MI->Buero Chris
   verbose    0


Danke
Christian
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 19 Oktober 2022, 13:02:19
Hallo Christian,

ich schaue mir das mal an.

Muss nur sehen, wie ich das "übergebe".
Mit git habe ich noch nicht viel gearbeitet, werde es also wohl (wieder) hier posten?

Mal sehen.
Wird aber etwas dauern...
(außer es findet sich jemand anders :)  ;)  )

Der "Mechanismus" hier ist aber (ganz klar) anders!
Das Device meldet (per Telegram ob per Signal: keine Ahnung, wenn dann müsste das evtl. eingebaut werden), wenn die Batterie leer ist (oder eine Schwelle unterschritten ist)...
...es ist nicht so, dass das zu einer bestimmten Zeit erfolgt.

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 14 November 2022, 13:48:55
So, ich habe mal versucht ausgehend von der github-Version: https://github.com/Amenophis86/Batteryfunktion/blob/master/99_Batterycheck.pm
einige Dinge einzuarbeiten, eine Version hängt an.

Folgendes habe ich mal eingebaut (Historie meiner Änderungen in diesem Thread).

Eingearbeitete Änderungen:

(HMCCUDEV und) LaCrosse
https://forum.fhem.de/index.php/topic,82637.msg1190831.html#msg1190831
(wobei LaCrosse schon mal potentiell hätte integriert werden können: https://forum.fhem.de/index.php/topic,82637.msg754406.html#msg754406 / weicht aber von meiner Integration nicht ab?)
(Und ich bzgl. HMCCUDEV gar nicht sicher bin, ob das funktioniert? Denke eher nicht, wenn ich mir das hier anschaue: https://forum.fhem.de/index.php/topic,82637.msg798155.html#msg798155)


HUEDevice:
https://forum.fhem.de/index.php/topic,82637.msg1203153.html#msg1203153
(wurde aber auch schon mal vorgeschlagen: https://forum.fhem.de/index.php/topic,82637.msg909188.html#msg909188 nicht geprüft inwieweit "ich" da "abweiche")

FBDECT:
https://forum.fhem.de/index.php/topic,82637.msg1240399.html#msg1240399

Ich übernehme keine Gewähr, da ich (immer noch) "meinen Code" laufen habe... ;) :-\


EDIT: Fehler korrigiert (so hoffe ich ;)  ), siehe https://forum.fhem.de/index.php/topic,82637.msg1249538.html#msg1249538


Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: kallidalli am 05 Dezember 2022, 15:35:58
Erst einmal auch von mir vielen Dank an alle die bereits an dem Thema arbeiten / gearbeitet haben.
Ich teste gerade die neueste Version von dir (Joachim).
Dabei ist mir aufgefallen das in Zeile 272 sich noch ein Fehler eingeschlichen hat.
Habe die Zeile mal korrigiert, da war eine Klammer zu viel am Ende.

elsif($BatteryType[0] eq "batteryLevel" && InternalVal($Device, "TYPE", "undef") eq "XiaomiFlowerSens" || InternalVal($Device, "TYPE", "undef") eq "FBDECT")

Aktuell habe ich nur HM Geräte im Einsatz mit battery & batteryLevel... falls ich noch andere Sachen heraus finde werde ich mich wieder melden  :)

Viele Grüße
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 05 Dezember 2022, 15:59:16
@kallidalli: danke!

Allerdings muss das so:


elsif($BatteryType[0] eq "batteryLevel" && (InternalVal($Device, "TYPE", "undef") eq "XiaomiFlowerSens" || InternalVal($Device, "TYPE", "undef") eq "FBDECT"))


Hab's ausgebessert...

Gruß, Joachim
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: gent am 14 Februar 2023, 20:42:16
Die Dummies, ReadingsGroup und Notify werden ja im Raum Z-System->BatteryCheck angelegt. Das steht ja in der Zeile

my $Room = "Z_System->BatteryCheck"; #room for the dummys


Wenn ich das jetzt nachträglich ändern will, was muss ich dann tun? Reload des Moduls und dann nochmal die BatteryStart ausführen?

LG Holger
Titel: Antw:Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 14 Februar 2023, 21:03:45
Ich denke du kannst einfach bei dummy, readingsGroup etc. das room Attribut ändern.

Wichtig sind/ist nur der Name der/des dummy, da bei dem/denen ja Readings in der Sub (die per "Battery-notify" aufgerufen wird) gesetzt werden...

Die Sub zum Anlegen ist ja "nur" damit man das nicht selbst/manuell alles anlegen muss und die Namen etc. "zusammenspielen"...

EDIT: und es ist kein Modul, sondern ein paar Subs (zum Anlegen) und per notify aufgerufen zum "Berechnen" und "Setzen" von Readings und senden von Nachrichten etc. ;)

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: gent am 12 Juli 2023, 00:28:51
Hi,

habe gerade entdeckt, dass der Batteriestatus meiner Fenstersensoren HM-SEC-SCO nicht upgedatet werden. Direkt in den Devices wird der Battery-Status von vor wenigen Minuten angezeigt. Im der Readings Group rgBatteryStatus sehe ich den Status vom 2023-05-06 11:00:30

Ist klar, was ich meine?

Viele Grüße
Holger
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 12 Juli 2023, 07:59:13
Wie wäre es mit einem list des HM-SEC-SCO?

event-on- Attribute gesetzt?

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: gent am 04 August 2023, 21:01:05
defmod BD.Fenster CUL_HM 697742
attr BD.Fenster .mId 00C7
attr BD.Fenster DbLogExclude .*
attr BD.Fenster IOgrp VCCU:CUL_1
attr BD.Fenster actCycle 002:50
attr BD.Fenster actStatus alive
attr BD.Fenster alias Badezimmerfenster
attr BD.Fenster autoReadReg 4_reqStatus
attr BD.Fenster devStateIcon devStateIcon closed:fts_door open:fts_door_open
attr BD.Fenster event-on-change-reading .*
attr BD.Fenster expert defReg,rawReg
attr BD.Fenster firmware 1.0
attr BD.Fenster model HM-SEC-SCO
attr BD.Fenster peerIDs 00000000,6951BB03
attr BD.Fenster room 02_Mitte->Bad,CUL_HM
attr BD.Fenster serialNr PEQ0579708
attr BD.Fenster subType threeStateSensor

setstate BD.Fenster open
setstate BD.Fenster 2020-12-22 19:47:15 .D-devInfo 810101
setstate BD.Fenster 2020-12-22 19:47:15 .D-stc 80
setstate BD.Fenster 2019-01-10 19:22:08 .R-msgScPosA open
setstate BD.Fenster 2019-01-10 19:22:08 .R-msgScPosB closed
setstate BD.Fenster 2019-01-10 19:22:08 .R-transmDevTryMax 6
setstate BD.Fenster 2019-01-10 19:22:08 .R-transmitTryMax 6
setstate BD.Fenster 2023-08-02 22:12:18 .associatedWith BD.Fenster,BD.Fenster,BD.Thermostat_WindowRec
setstate BD.Fenster 2023-05-10 19:20:25 .peerListRDate 2023-05-10 19:20:25
setstate BD.Fenster 2023-08-04 20:15:21 .protLastRcv 20230804201521
setstate BD.Fenster 2023-08-02 22:21:33 Activity alive
setstate BD.Fenster 2021-10-09 17:50:01 CommandAccepted no
setstate BD.Fenster 2020-12-22 19:47:15 D-firmware 1.0
setstate BD.Fenster 2020-12-22 19:47:15 D-serialNr PEQ0579708
setstate BD.Fenster 2023-08-04 20:15:21 IODev CUL_1
setstate BD.Fenster 2023-05-10 19:20:24 PairedTo 0x753347
setstate BD.Fenster 2019-08-19 20:24:22 R-BD.Thermostat_WindowRec-expectAES off
setstate BD.Fenster 2019-08-19 20:24:22 R-BD.Thermostat_WindowRec-peerNeedsBurst on
setstate BD.Fenster 2019-01-10 19:22:08 R-cyclicInfoMsg on
setstate BD.Fenster 2019-01-10 19:22:08 R-eventDlyTime 0 s
setstate BD.Fenster 2019-01-10 19:22:08 R-pairCentral 0x753347
setstate BD.Fenster 2019-01-10 19:22:08 R-sabotageMsg on
setstate BD.Fenster 2019-01-10 19:22:08 R-sign on
setstate BD.Fenster 2023-05-10 19:20:23 RegL_00. 00:00 02:01 09:01 0A:75 0B:33 0C:47 10:01 14:06
setstate BD.Fenster 2023-05-10 19:20:25 RegL_01. 00:00 08:01 20:9C 21:00 30:06
setstate BD.Fenster 2023-05-10 19:20:26 RegL_04.BD.Thermostat_WindowRec 00:00 01:01
setstate BD.Fenster 2019-08-19 20:24:21 aesCommToDev ok
setstate BD.Fenster 2019-08-19 20:24:20 aesKeyNbr 00
setstate BD.Fenster 2023-08-04 20:15:21 alive yes
setstate BD.Fenster 2023-08-04 20:15:21 battery ok
setstate BD.Fenster 2023-05-31 18:57:29 cfgState ok
setstate BD.Fenster 2023-08-04 20:15:21 commState CMDs_done
setstate BD.Fenster 2023-08-04 20:15:21 contact open (to VCCU)
setstate BD.Fenster 2023-08-02 22:12:18 peerList BD.Thermostat_WindowRec
setstate BD.Fenster 2023-05-10 18:22:01 powerOn 2023-05-10 18:22:01
setstate BD.Fenster 2023-08-04 20:15:21 recentStateType info
setstate BD.Fenster 2023-08-04 20:15:21 sabotageError off
setstate BD.Fenster 2023-08-04 20:15:21 state open
setstate BD.Fenster 2020-12-22 19:12:22 trigDst_BD.Thermostat noConfig
setstate BD.Fenster 2023-08-04 11:25:22 trigger_cnt 180


LG
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 04 August 2023, 21:19:34
Zitatattr BD.Fenster event-on-change-reading .*

Und wo/wie soll dann ein regelmäßiges Update erfolgen?

Wenn du aktuelle Batteriewerte willst bzw. regelm. Updatrs, musst du mind. dafür event-on-update-reading setzen...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: gent am 10 August 2023, 21:41:02
Das habe ich aber bei den HM Thermostaten (HM-TC-IT-WM-W-EU) und den Reglern (HM-CC-RT-DN) auch nicht gesetzt und die melden ganz regelmäßig den aktuellen Batteriezustand. Irgendwas muss da bei den Fensterkontakten anders laufen, aber was?

Edit:
Ich sehe gerade, dass ich bei den Thermostaten und den Reglern überhaupt kein event-on... definiert habe.

Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: minierm am 13 August 2023, 18:55:15
Ich habe die Benachrichtigung in eine Funktion ausgelagert, damit man leichter Anpassungen der Benachrichtigung vornehmen kann.

sub Battery_Send_Alarm {
    my ($Text) = @_;
    #send message via TelegramBot
    fhem("set TelegramBot message \@\@User $Text");
    # use your own function
    #SendAlarm($Text);
}
Und überall
fhem($msg." ".mit
Battery_Send_Alarm(ersetzt.
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: LutzG am 22 November 2023, 21:58:12
Hallo @All,

laut: https://wiki.fhem.de/wiki/DevelopmentGuidelines#BatteryReadings
sollen doch diese Readings "Standard" werden:

Aber in den Scripten habe ich nicht gefunden, dass diese Readings ausgewertet werden:

@Amenophis86 du hattest doch schon Mal versucht die Readings zu "vereinheitlichen":
https://forum.fhem.de/index.php?topic=87575.0
Ich verstehe nicht, warum sind die "Standard" - Readings nicht in das Skript gelangt?  ???

Hintergrund:
Ich habe einige Zigbee-Teile von Lidl / Sonnoff / TRADFRI (Ikea) über Zigbee2MQTT eingebunden, die bringen zum Beispiel (nur) "battery / "batterymV" oder andere nicht "standardkonforme" Readings, denen ich (mit Hilfe des Forums) den "Standard" eingehaucht habe (userReading):  8)
batteryVoltage:batterymV.* {ReadingsNum($name,'batterymV',0)/1000}, batteryPercent:battery.* {ReadingsNum($name,'battery',0)}, batteryState {if (ReadingsNum($name, "battery", 0) > 25) {return "ok"} else {return "low"}}

Leider übersteigt es meine Fähigkeiten, dem Skript den "Standard" zu verpassen. Ich würde es sehr gern nutzen, da ich die Art der Auswertung echt Spitze finde.

Vielleicht ein Beispiel-Device welches Probleme macht:

define MQTT2_zigbee_Lidl_Kontakt_1 MQTT2_DEVICE zigbee_Lidl_Kontakt_1
attr MQTT2_zigbee_Lidl_Kontakt_1 userattr myBattWechsel my_batteryType
attr MQTT2_zigbee_Lidl_Kontakt_1 DbLogExclude .*
attr MQTT2_zigbee_Lidl_Kontakt_1 alias zigbee_Kontakt_Wohnungstuer
attr MQTT2_zigbee_Lidl_Kontakt_1 devStateIcon open:fts_window_1w_open@red closed:fts_window_1w@green  Secure..true:secur_open@red Secure..false:secur_locked@gree online:10px-kreis-gruen offline:10px-kreis-rot
attr MQTT2_zigbee_Lidl_Kontakt_1 devicetopic zigbee2mqtt/Lidl_Kontakt_1
attr MQTT2_zigbee_Lidl_Kontakt_1 event-on-change-reading .*
attr MQTT2_zigbee_Lidl_Kontakt_1 genericDeviceType ContactSensor
attr MQTT2_zigbee_Lidl_Kontakt_1 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED
attr MQTT2_zigbee_Lidl_Kontakt_1 icon fts_window_1w
attr MQTT2_zigbee_Lidl_Kontakt_1 jsonMap contact:state
attr MQTT2_zigbee_Lidl_Kontakt_1 model zigbee2mqtt_ContactSensor
attr MQTT2_zigbee_Lidl_Kontakt_1 myBattWechsel 0
attr MQTT2_zigbee_Lidl_Kontakt_1 my_batteryType 2xAAA
attr MQTT2_zigbee_Lidl_Kontakt_1 readingList $DEVICETOPIC:.* { my $ret=json2nameValue($EVENT,'',$JSONMAP);; $ret->{state}=$ret->{state} eq 'true' ? 'closed' : 'open';; return $ret }\
zigbee2mqtt/Lidl_Kontakt_1/availability:.* availability
attr MQTT2_zigbee_Lidl_Kontakt_1 room Zimmer->Flur,Geräte->Zigbee
attr MQTT2_zigbee_Lidl_Kontakt_1 stateFormat availability\
state\
 Battery: battery%\
Secure: tamper
attr MQTT2_zigbee_Lidl_Kontakt_1 userReadings batteryPercent {ReadingsNum($name,'battery','0')}, batteryState {if (ReadingsNum($name, "battery", 0) > 25) {return "ok"} else {return "low"}}
#   CID        zigbee_Lidl_Kontakt_1
#   DEF        zigbee_Lidl_Kontakt_1
#   FUUID      637bcf1a-f33f-be0c-9804-9ecba85255e59624
#   FVERSION   10_MQTT2_DEVICE.pm:0.279350/2023-09-05
#   IODev      mqtt2server
#   LASTInputDev mqtt2server
#   MSGCNT     74
#   NAME       MQTT2_zigbee_Lidl_Kontakt_1
#   NR         237
#   STATE      online
#closed
# Battery: 41.5%
#Secure: false
#   TYPE       MQTT2_DEVICE
#   eventCount 73
#   mqtt2server_CONN mqtt2server_172.18.0.4_52536
#   mqtt2server_MSGCNT 74
#   mqtt2server_TIME 2023-11-22 21:04:02
#   JSONMAP:
#     contact    state
#   READINGS:
#     2023-11-21 02:10:42   IODev           mqtt2server
#     2022-11-22 00:25:02   associatedWith  MQTT2_zigbee_bridge
#     2022-11-21 20:19:24   attrTemplateVersion 20220622
#     2023-11-21 02:11:01   availability    online
#     2023-11-22 21:04:02   battery         41.5
#     2023-11-22 21:04:02   batteryPercent  41.5
#     2023-11-22 21:04:02   batteryState    ok
#     2023-11-22 21:04:02   battery_low     false
#     2023-11-22 21:04:02   last_seen       2023-11-22T20:04:02.803Z
#     2023-11-22 21:04:02   linkquality     255
#     2023-11-22 21:04:02   state           closed
#     2023-11-22 21:04:02   tamper          false
#
setstate MQTT2_zigbee_Lidl_Kontakt_1 online\
closed\
 Battery: 41.5%\
Secure: false
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-21 02:10:42 IODev mqtt2server
setstate MQTT2_zigbee_Lidl_Kontakt_1 2022-11-22 00:25:02 associatedWith MQTT2_zigbee_bridge
setstate MQTT2_zigbee_Lidl_Kontakt_1 2022-11-21 20:19:24 attrTemplateVersion 20220622
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-21 02:11:01 availability online
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-22 21:04:02 battery 41.5
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-22 21:04:02 batteryPercent 41.5
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-22 21:04:02 batteryState ok
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-22 21:04:02 battery_low false
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-22 21:04:02 last_seen 2023-11-22T20:04:02.803Z
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-22 21:04:02 linkquality 255
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-22 21:04:02 state closed
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-22 21:04:02 tamper false

Wäre toll, wenn auch der "Standard" im Skript ausgewertet wird!  8)

Viele Grüße, Lutz
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 November 2023, 22:15:16
Einheitlich ist (leider) noch nichts...

Ich schaue mir das morgen mal an...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 23 November 2023, 00:06:03
Hmm, also evtl. ginge das hier:

EDIT: nein geht (nat.) nicht ;) siehe nächste Posts :-\

Bei
Zitat#############################################
  # XiaomiFlowerSens Devices
  #############################################

Das hier:
elsif($BatteryType[0] eq "batteryLevel"  && InternalVal($Device, "TYPE", "undef") eq "XiaomiFlowerSens")
gegen das hier tauschen:
elsif($BatteryType[0] eq "batteryLevel"  && (InternalVal($Device, "TYPE", "undef") eq "XiaomiFlowerSens" || InternalVal($Device, "TYPE", "undef") eq "MQTT2_DEVICE"))
bzw. damit nicht (plötzlich) alle MQTT2_DEVICE Devices "geprüft" werden (wobei auch entsprechend an dem battery-notify eingeschränkt werden kann bzw. eh nur Devices mit irgendwas Battery hier aufgerufen werden sollten?)
elsif($BatteryType[0] eq "batteryLevel"  && (InternalVal($Device, "TYPE", "undef") eq "XiaomiFlowerSens" || (InternalVal($Device, "TYPE", "undef") eq "MQTT2_DEVICE" && AttrVal($Device, "my_batteryType", "n.a.") ne "n.a.")))
EDIT: Klammerfehler korrigiert 8so hoffe/denke ich)

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: LutzG am 23 November 2023, 17:14:02
Hallo Joachim, @All,

ich glaube nicht, dass das funktioniert, "batteryLevel" haben die Device nicht, das ist ja das, was ich meine. Wenn ich richtig gelesen habe, werden (nur):
ausgewertet, die Standards: "batteryPercent, batteryState, batteryVoltage" nicht.

Vielleicht verstehe ich auch was völlig falsch, zum Beispiel ist mir schleierhaft, wie das für FBDECT funktioniere soll:
elsif($BatteryType[0] eq "batteryLevel"  && (InternalVal($Device, "TYPE", "undef") eq "XiaomiFlowerSens" || InternalVal($Device, "TYPE", "undef") eq "FBDECT"))Es wird doch bei dem Device das Reading "batteryLevel" gelesen, oder? Dass hab ich bei "FRITZ!DECT 440" und FRITZ!DECT 301 aber nicht. ???

Ich schicke Mal ein Screenshot, Bat01.jpg ist das Ergebniss von dem Script, Bat02.jpg sind das Ergebniss von:
defmod rg_BatterieLevel readingsGroup .*:[Bb]atteryPercent
attr rg_BatterieLevel DbLogExclude .*
attr rg_BatterieLevel comment als doif: https://forum.fhem.de/index.php/topic,131349.msg1255415.html#msg1255415
attr rg_BatterieLevel notime 1
attr rg_BatterieLevel room System->BatteryCheck
attr rg_BatterieLevel valueFormat {my $value = ($VALUE =~ m/(\d+)/)?$1:$VALUE;;;; return "0" if( $value < 20 );;;; return "25" if( $value < 40 );;;; return "50" if( $value < 60 );;;; return "75" if( $value < 80 );;;; return "100";;;;}
attr rg_BatterieLevel valueIcon {'batteryPercent.0' => 'measure_battery_0@red','batteryPercent.25' => 'measure_battery_25@red','batteryPercent.50' => 'measure_battery_50@orange','batteryPercent.75' => 'measure_battery_75@green','batteryPercent.100' => 'measure_battery_100@green'}

Bat02.jpg Bat01.jpg

Viele Grüße, Lutz
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 23 November 2023, 17:40:45
Ja, sorry, mein Fehler.
Ich hab mich in deinem List/RawDef wohl verkuckt 8)

Ich schaue gleich noch mal...

Bzgl. deiner DECT bzw. alle Devices die bei dir (noch) nicht gehen wäre eine RawDef/copyForForum hilfreich.
Die Batteriewerte (in den dummy) kommen aber erst, wenn sich beim Batterie-Reading auch was ändert/tut (event-on-change-... Drum hab ich bei mir event-on-update für Batterie-Readings drin)

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 23 November 2023, 17:53:18
Dann werfe ich hier mal etwas bzgl. BatteryPercent ins Rennen :)
(hast du die Beiträge hier [von mir] mal durch, ob nicht schon mal was gepostet wurde bzgl. batteryPercent oder weitere Abfragen? Leider landet das nicht in git)

Also "einfach" einen weiteren Code-Block anfügen.

  #############################################
  # MQTT2_DEVICE Devices that have my_batteryType attribute!
  #############################################
 elsif(InternalVal($Device, "TYPE", "undef") eq "MQTT2_DEVICE" && AttrVal($Device, "my_batteryType", "n.a.") ne "n.a.")
 {
   $ActBatLevel = ReadingsNum($Device, "batteryPercent", "0");

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        fhem("setreading $BatteryChanged $Device $text_changed");
      }

      # set the battery value to 75% - 100%
      fhem("setreading $BatteryStatus $Device 100");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
  }
EDIT: Klammer korrigiert...

EDIT: Evtl. ist auch das hier ok:
  #############################################
  # MQTT2_DEVICE Devices that have batteryPercent Reading
  #############################################
 elsif($BatteryType[0] eq "batteryPercent" && InternalVal($Device, "TYPE", "undef") eq "MQTT2_DEVICE")
 {
   $ActBatLevel = ReadingsNum($Device, "batteryPercent", "0");

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        fhem("setreading $BatteryChanged $Device $text_changed");
      }

      # set the battery value to 75% - 100%
      fhem("setreading $BatteryStatus $Device 100");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
  }
EDIT: Klammer korrigiert...

Die Abfrage bzgl. Device-Type o.ä. Abfragen sind drin, da manche Devices zwar batteryPercent (in diesem Beispiel oder auch batteryLevel o.ä.) haben aber mit unterschiedlichen Formatierungen bzw. mit/ohne Einheiten oder %-Zeichen o.ä.
Wobei das mit ReadingsNum ja "ausgebügelt" werden müsste...

Ich habe dazu jetzt einen Block aus dem git-Code genommen und auf batteryPercent angepasst.
Wenn du einen anderen Code als Grundlage hast, dann poste das doch mal...

Meinen Code kann ich nicht direkt posten, da ich (inzwischen) einfach zu viele andere Dinge eingebaut habe, die nur bei mir funktionieren (dürften)...

EDIT: das notify muss u.U. auch erweitert werden? damit eben auch bei batteryPercent ein Aufruf erfolgt... (stecke jetzt nicht mehr so tief drin in dem code hier...)
EDIT: hab grad geschaut, müsste noch passen...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 23 November 2023, 19:37:26
Jetzt hab ich deinen letzten Post noch mal gelesen...

Geht es dir um FBDECT oder (wie ich dachte/denke) MQTT2_DEVICE?

Aber das Prinzip ist immer gleich:

erst mal prüfen um welches Reading und Device Typ es sich handelt.
Device Typ weil manche Typen trotz gleicher Readings/Readingnamen andere Werte etc. liefern.

Aber evtl. könnte/sollte man das mal (wieder) vereinheitlichen, also den Code hier...

Die Schwrllen, also wann bei einem Gerät die Batteriewarnung kommen sollte könnte man pro Device per Attribut angeben, wenn es fehlt, dann halt irgendwann unter 25% oder so...

Alles Ideen aber zu wenig Zeit :-\

Ich habe ja den Batterie-Typ schon beim Device verattributet und auch eine Funktion die prüft (anhand meines "Batterielagers") , ob ich noch habe oder kaufen sollte...

Und auch wie lange (in Wochen) die Batterien so pro Gerät halten...

Mal sehen...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: LutzG am 23 November 2023, 21:51:16
Hallo Joachim, @All,

@Joachim, so schnell wie du bin ich leider nicht :-[ und ich glaube, bei deinen Vorschlägen fehlt am Ende eine Klammer.  ???
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
  }   # <---

Zitat von: MadMax-FHEM am 23 November 2023, 19:37:26Geht es dir um FBDECT oder (wie ich dachte/denke) MQTT2_DEVICE?
Um alle, zum Beispiel habe ich bei keinen meiner Device ein Reading: "batteryLevel". Verwenden tue ich mehrere Device von: Lidl / Sonnoff / TRADFRI (Ikea) - über Zigbee2MQTT angebunden und FBDECT Device: "FRITZ!DECT 440", "FRITZ!DECT 301".

Zitat von: MadMax-FHEM am 23 November 2023, 17:40:45Drum hab ich bei mir event-on-update für Batterie-Readings drin
Habe ich jetzt (hoffe alle) eingetragen:
attr <Device> event-on-update-reading batteryPercent
Zitat von: MadMax-FHEM am 23 November 2023, 17:53:18(hast du die Beiträge hier [von mir] mal durch, ob nicht schon mal was gepostet wurde bzgl. batteryPercent oder weitere Abfragen? Leider landet das nicht in git)
"batteryPercent" habe ich dem Thread keine Lösung gefunden. Der Code ist von dir:
Zitat von: MadMax-FHEM am 14 November 2022, 13:48:55eine Version hängt an

Von deinen neuen Vorschlägen habe ich: "# MQTT2_DEVICE Devices that have batteryPercent Reading" eingebaut, weil "my_batteryType" ist ein "alternatives" Attribut - kein "Standard" (noch nicht  ;) die Idee ist auch echt  8) )

(geändert habe ich: my $Room = "System->BatteryCheck";)
#############################################
# https://forum.fhem.de/index.php?msg=1245462
# 99_Batterycheck.pm - vom: 05 Dezember 2022, 16:00:50 von MadMax-FHEM
#

package main;

use strict;
use warnings;
use POSIX;

sub BatteryCheckUtils_Initialize($$)
{
  my ($hash) = @_;
}

# Enter you functions below _this_ line.

#########################################################################
# Helper for readingsGroup BatteryStatus:
# reads the battery states of devices and
# calculates the battery state in percent (depending on device type) and
# stores it as reading in corresponding dummy device
sub BatteryStatusFunction($$)
{
  my ($Device, $Event)  = @_;
  my @BatteryType = split(/:/,$Event); # to distinguish between "battery" and "batteryLevel" devices
  my $Model = AttrVal($Device, "model", "undef"); # get the corresponding model type
  my $TYPE = InternalVal($Device, "TYPE", "undef"); # MAX!
  my $ActBatLevel = 0.0;
  my $MinBatLevel = 0.0;
  my $RemainingVoltageQuater = 0.0; # for "calculating" the colors
  my $MaxBattery = 3.1; # two 1.5V batteries have a measured voltage of 3.1V or even 3.2V
  my @DeviceNameParts = split(/_/,$Device); # to filter out HM_ Devices from neighbor or test system or newly included ones
  my $SignalDevice = $Device . "_BatState";

###############################
# Here you can change the variables to fit your installation.
#
  my $text_now = "Die Batterien von $Device müssen JETZT gewechselt werden!"; #Text for changing battery now
  my $text_soon = "Die Batterien von $Device sollten bald gewechselt werden!"; #Text for changing battery soon
  my $text_changed = "Batterie zuletzt gewechselt: "; #Text for last change
  my $BatteryStatus = "BatterieStatus"; #Name of the Dummy for status
  my $BatteryStatusBot = "BatterieStatusBot"; #Name of the Dummy for status of send messages
  my $BatteryChanged = "BatterieWechsel"; #Name of the Dummy for battery changed information

################################
# Here you choos your message device and how to send
# comment the device you do not want to use
#
# TelegramBot
  my $msg = "set WEB_TelegramBot message \@\@User ";
#
# msg-command
# my $msg = "msg \@User title='Battery Check' ";
#
# Pushover
# my $msg = "set Pushover msg device=User title='Battery Check' ";


# nächste Zeile war #
  Log3(undef, 1, "my_StoreBatteryStatus      Device: $Device       Event: $Event      Model: $Model");
 
  # ignoring Devices that were just created by autocreate
  if($DeviceNameParts[0] eq "HM" || $DeviceNameParts[0] eq "ZWave" || $DeviceNameParts[0] eq "MAX")
  {
    Log3(undef, 1, "my_StoreBatteryStatus      ignoring Device: $Device");
    return;
  }

  # if it is the first time for that device set it to none (initialize)
  if(ReadingsVal($BatteryStatusBot, $SignalDevice, "undef") eq "undef")
  {
    fhem("setreading $BatteryStatusBot $SignalDevice none");
  }
   
  # actually only devices HM-TC-IT-WM-W-EU and HM-CC-RT-DN have battery level and min-level
  # so calculating the percentage of actual level depending on min-level
  # all others just have battery ok or nok
  # IMPORTANT: first filter those which only send "battery" in EVENT
  #            then calculate for those which send "batteryLevel"!
  #            New devices: ZWave. They deliver battery already in percentage.
  #            New devices: XiaomiFlowerSens. They also deliver batteryLevel but already in percentage.

  ##############################################
  # HM Devices with battery
  ##############################################
  if($BatteryType[0] eq "battery"  && $Model ne "HM-TC-IT-WM-W-EU" && $Model ne "HM-CC-RT-DN" && $Model ne "undef")
  {
    if(ReadingsVal($Device, "battery", "low") eq "ok")
    {
      # check if battery was low before -> possibly changed
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $BatteryChanged $Device $text_changed");
        # set the signal state back to none
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }

      # status is "ok" so we set to 100% (we don't know better)
      fhem("setreading $BatteryStatus $Device 100");
    }
    else
    {
      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }

      # status is NOT "ok" ("low") so we set to 0% (we don't know better)
      fhem("setreading $BatteryStatus $Device 0");
    }
  }
  ##############################################
  # HM Devices with batteryLevel
  ##############################################
  elsif($BatteryType[0] eq "batteryLevel"  && $Model ne "undef")
  {
    $ActBatLevel = ReadingsVal($Device, "batteryLevel", "0.0");
    $MinBatLevel = ReadingsNum($Device, "R-lowBatLimitRT", "0.0");
    $RemainingVoltageQuater = ($MaxBattery - $MinBatLevel) / 4; # to get 4 quaters for different colours and icons

    if(($ActBatLevel - $MinBatLevel) > (3 * $RemainingVoltageQuater))
    {
      # check if battery was low before -> possibly changed
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $BatteryChanged $Device $text_changed");
        # set the signal state back to none
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }

      # set battery value to 100%
      fhem("setreading $BatteryStatus $Device 100");
    }
    elsif(($ActBatLevel - $MinBatLevel) > (2 * $RemainingVoltageQuater))
    {
      # between 50% and 75%
      fhem("setreading $BatteryStatus $Device 75");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif(($ActBatLevel - $MinBatLevel) > (1 * $RemainingVoltageQuater))
    {
      # between 25% and 50%
      fhem("setreading $BatteryStatus $Device 50");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif(($ActBatLevel - $MinBatLevel) > (0 * $RemainingVoltageQuater))
    {
      # check for critical stuff
      if(ReadingsVal($Device, "motorErr", "ok") eq "lowBat" || ReadingsVal($Device, "motorErr", "ok") eq "ValveErrorPosition")
      {
        # empty!
        fhem("setreading $BatteryStatus $Device 0");
        # check if message was already sent
        if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
        {
          # set signal state to low
          fhem("setreading $BatteryStatusBot $SignalDevice low");
          #send message via TelegramBot
          if(ReadingsVal($Device, "motorErr", "ok") eq "ValveErrorPosition")
          {
            fhem($msg." ".$text_now);
          }
          else
          {
            fhem($msg." ".$text_soon);
          }
        }
      }
      else
      {
        # between 0% and 25%
        fhem("setreading $BatteryStatus $Device 25");
      }
    }
    else
    {
      # totally empty
      fhem("setreading $BatteryStatus $Device 0");

      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }
    }
  }
  ##############################################
  # ZWave and HUEDevice Devices
  ##############################################
#elsif($BatteryType[0] eq "battery"  && InternalVal($Device, "TYPE", "undef") eq "ZWave")
elsif($BatteryType[0] eq "battery"  && (InternalVal($Device, "TYPE", "undef") eq "ZWave" || InternalVal($Device, "TYPE", "undef") eq "HUEDevice"))
 {
   if(ReadingsVal($Device, "battery", "na") eq "low")
{
     $ActBatLevel = 0;
}
else
{
    $ActBatLevel = ReadingsNum($Device, "battery", "0");
}

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
     {
       fhem("setreading $BatteryChanged $Device $text_changed");
     }

     # set the battery value to 75% - 100%
     fhem("setreading $BatteryStatus $Device 100");

     # set the signal state back to none
     fhem("setreading $BatteryStatusBot $SignalDevice none");
   }
   elsif($ActBatLevel > 50)
   {
    # between 50% and 75%
     fhem("setreading $BatteryStatus $Device 75");

     # set the signal state back to none
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
     {
       fhem("setreading $BatteryStatusBot $SignalDevice none");
     }
   }
   elsif($ActBatLevel > 25)
   {
     # between 25% and 50%
     fhem("setreading $BatteryStatus $Device 50");

     # set the signal state back to none
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
     {
       fhem("setreading $BatteryStatusBot $SignalDevice none");
     }
   }
   elsif($ActBatLevel > 5)
   {
     # between 5% and 25%
     fhem("setreading $BatteryStatus $Device 25");

     # maybe already send a message! Easy possible with new signal states
   }
   else
   {
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
  # TODO: test for 0 and then send "change NOW"!
     # totally empty (below 5%)
     fhem("setreading $BatteryStatus $Device 0");

     # check if message was already sent
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
     {
       # set signal state to low
       fhem("setreading $BatteryStatusBot $SignalDevice low");
       #send message via TelegramBot
       fhem($msg." ".$text_soon);
     }
   }
 }
  #############################################
  # XiaomiFlowerSens and FBDECT Devices
  #############################################
# elsif($BatteryType[0] eq "batteryLevel"  && InternalVal($Device, "TYPE", "undef") eq "XiaomiFlowerSens")
 elsif($BatteryType[0] eq "batteryLevel"  && (InternalVal($Device, "TYPE", "undef") eq "XiaomiFlowerSens" || InternalVal($Device, "TYPE", "undef") eq "FBDECT"))
 {
   $ActBatLevel = ReadingsNum($Device, "batteryLevel", "0");

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        fhem("setreading $BatteryChanged $Device $text_changed");
      }

      # set the battery value to 75% - 100%
      fhem("setreading $BatteryStatus $Device 100");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 50)
    {
      # between 50% and 75%
      fhem("setreading $BatteryStatus $Device 75");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 25)
    {
      # between 25% and 50%
      fhem("setreading $BatteryStatus $Device 50");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 5)
    {
      # between 5% and 25%
      fhem("setreading $BatteryStatus $Device 25");

      # maybe already send a message! Easy possible with new signal states
    }
    else
    {
      # totally empty (below 5%)
      fhem("setreading $BatteryStatus $Device 0");

      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }
    }
  }
 
  ##############################################
  # MAX! Devices
  ##############################################
  elsif(($BatteryType[0] eq "battery")  && ($TYPE eq "MAX"))
  {
    if(ReadingsVal($Device, "battery", "low") eq "ok")
    {
      # check if battery was low before -> possibly changed
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low")
      {
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $BatteryChanged $Device $text_changed");
        # set the signal state back to none
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }

      # status is "ok" so we set to 100% (we don't know better)
      fhem("setreading $BatteryStatus $Device 100");
    }
    else
    {
      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }

      # status is NOT "ok" ("low") so we set to 0% (we don't know better)
      fhem("setreading $BatteryStatus $Device 0");
    }
  }
  ##############################################
  # HMCCU and LaCrosse Devices
  ##############################################
 elsif($BatteryType[0] eq "battery"  && (InternalVal($Device, "TYPE", "undef") eq "HMCCUDEV" || InternalVal($Device, "TYPE", "undef") eq "LaCrosse"))
  {
    if(ReadingsVal($Device, "battery", "low") eq "ok")
    {
      # check if battery was low before -> possibly changed
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $BatteryChanged $Device $text_changed");
        # set the signal state back to none
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }

      # status is "ok" so we set to 100% (we don't know better)
      fhem("setreading $BatteryStatus $Device 100");
    }
    else
    {
      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }

      # status is NOT "ok" ("low") so we set to 0% (we don't know better)
      fhem("setreading $BatteryStatus $Device 0");
    }
  }
  #############################################
  # MQTT2_DEVICE Devices that have batteryPercent Reading
  #############################################
 elsif($BatteryType[0] eq "batteryPercent" && InternalVal($Device, "TYPE", "undef") eq "MQTT2_DEVICE")
 {
   $ActBatLevel = ReadingsNum($Device, "batteryPercent", "0");

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        fhem("setreading $BatteryChanged $Device $text_changed");
      }

      # set the battery value to 75% - 100%
      fhem("setreading $BatteryStatus $Device 100");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
  }
}

##################################################
# Helper for readingsGroup BatteryStatus:
# sets the icon and icon color depending on "calculated" percentage value
sub SetBatterieIcon($$)
{
  my ($Device, $Value)  = @_;
  my $Icon = "measure_battery_" . "$Value"; # here the matching icon is "set"
  my $ActionDetectorDevice = "status_" . $Device;
  my $Name = ""; # name for signal state
  my $State = ReadingsVal("ActionDetector", $ActionDetectorDevice, "alive");

#  Log3(undef, 1, "my_SetBatteryIcon      Device: $Device       Value: $Value");

  if($State ne "alive")
  {
    $Icon = "message_attention\@red";
  }
  else
  {
    if($Value > 75)
    {
      $Icon = $Icon . "\@green"; # between 75% and 100%
    }
    elsif($Value > 25)
    {
      $Icon = $Icon . "\@orange"; # between 25% and 75%
    }
    else
    {
      $Icon = $Icon . "\@red"; # below 25%
    }
  }

  return $Icon;
}

#####################################################
# Start script once and delet after

sub BatteryStart()
{
 #Define Dummys for script
 my $BatteryStatus = "BatterieStatus"; #Name of the Dummy for status
 my $BatteryStatusBot = "BatterieStatusBot"; #Name of the Dummy for status of send messages
 my $BatteryChanged = "BatterieWechsel"; #Name of the Dummy for battery changed information
 my $ReadingsGroup = "rgBatteryStatus"; #Name of the ReadingsGroup
 my $Room = "System->BatteryCheck"; #room for the dummys
 my $Notify = "NO.BatterieNotify"; #Name of the Notify for sending battery information
 
 fhem("setdefaultattr room $Room; define $BatteryStatus dummy; define $BatteryStatusBot dummy; define $BatteryChanged dummy;
      define $ReadingsGroup readingsGroup NAME=BatterieStatus:.*; attr $ReadingsGroup valueIcon {SetBatterieIcon(\$READING, \$VALUE)};
      attr $ReadingsGroup mapping \$READING; setdefaultattr;");
 
 
 #Set Readings for device with reading battery
 my @bat_b = devspec2array("battery=.*");
 for(my $x=0;$x<@bat_b;$x++)
 {
  my $stat_b = ReadingsVal($bat_b[$x],"battery","undef");
  if($stat_b ne "undef")
{
BatteryStatusFunction($bat_b[$x],"battery: $stat_b");
}
 }
 
 #Set Readings for device with reading batteryLevel
 my @bat_l = devspec2array("batteryLevel=.*");
 for(my $x=0;$x<@bat_l;$x++)
 {
my $stat_l = ReadingsVal($bat_l[$x],"batteryLevel","undef");
if($stat_l ne "undef")
{
BatteryStatusFunction($bat_l[$x],"batteryLevel: $stat_l");
}
 }
 
 fhem("define $Notify notify .*:battery.* {BatteryStatusFunction(\$NAME, \$EVENT)}; attr $Notify room $Room;")
}

1;

im nächsten Post weiter - zu viele Zeichen?
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: LutzG am 23 November 2023, 21:53:45
Meine Device:
- FRITZ!DECT 301:
define FBDECT_HKV_301_WZ FBDECT FritzBoxHttp:09995_0507067 actuator,tempSensor
attr FBDECT_HKV_301_WZ userattr myBattWechsel my_batteryType
attr FBDECT_HKV_301_WZ DbLogExclude .*
attr FBDECT_HKV_301_WZ DbLogInclude temperature,batteryPercent,desired-temp
attr FBDECT_HKV_301_WZ alexaName Heizung Wohnzimmer
attr FBDECT_HKV_301_WZ alexaRoom Wohnzimmer
attr FBDECT_HKV_301_WZ alias AVM: Heizkörperregler FRITZ!DECT 301 WZ
attr FBDECT_HKV_301_WZ event-on-change-reading .*
attr FBDECT_HKV_301_WZ event-on-update-reading batteryPercent
attr FBDECT_HKV_301_WZ icon temp_control
attr FBDECT_HKV_301_WZ myBattWechsel 2023-09-25
attr FBDECT_HKV_301_WZ my_batteryType 2xAA
attr FBDECT_HKV_301_WZ readingsWatcher 3600,,battery,temperature
attr FBDECT_HKV_301_WZ room Zimmer->Wohnzimmer,Geräte->AVM
#   DEF        FritzBoxHttp:09995_0507067 actuator,tempSensor
#   FUUID      60edd963-f33f-be0c-daed-7f5cc6fa51715a4f
#   FVERSION   10_FBDECT.pm:0.250690/2021-10-13
#   FritzBoxHttp_MSGCNT 20
#   FritzBoxHttp_TIME 2023-11-23 20:52:53
#   IODev      FritzBoxHttp
#   LASTInputDev FritzBoxHttp
#   MSGCNT     20
#   NAME       FBDECT_HKV_301_WZ
#   NR         134
#   STATE      desired-temp: 15.0 C
#   TYPE       FBDECT
#   eventCount 22
#   id         09995_0507067
#   props      actuator,tempSensor
#   webCmd     desired-temp
#   Helper:
#     DBLOG:
#       batteryPercent:
#         LOG_Db:
#           TIME       1700769173.79331
#           VALUE      90
#   READINGS:
#     2023-11-23 20:52:53   AIN             09995 0507067
#     2023-11-23 20:52:53   FBNAME          FRITZ!DECT 301 WZ
#     2023-11-23 20:52:53   FBPROP          actuator,tempSensor
#     2023-11-23 20:52:53   FBTYPE          FRITZ!DECT 301
#     2023-11-23 20:52:53   ID              17
#     2023-11-23 19:17:36   IODev           FritzBoxHttp
#     2023-11-23 20:55:53   actifity        alive
#     2023-11-23 20:52:53   battery         90 %
#     2023-11-23 20:52:53   batteryPercent  90
#     2023-11-23 20:52:53   batteryState    ok
#     2023-11-23 20:52:53   batterylow      0
#     2023-11-23 20:52:53   boostactive     no
#     2023-11-23 20:52:53   boostactiveendtime N/A
#     2023-11-23 20:52:53   day-temp        15.0 C
#     2023-11-23 20:52:53   desired-temp    15.0 C
#     2023-11-23 20:52:53   devicelock      no
#     2023-11-23 20:52:53   errorcode       noError (0)
#     2023-11-23 20:52:53   fwversion       05.08
#     2023-11-23 20:52:53   holidayactive   no
#     2023-11-23 20:52:53   locked          no
#     2023-11-23 20:52:53   nextPeriodStart 2023-11-23 22:00:00
#     2023-11-23 20:52:53   nextPeriodTemp  8.0 C
#     2023-11-23 20:52:53   night-temp      8.0 C
#     2023-11-23 20:52:53   present         yes
#     2023-11-23 20:52:53   state           desired-temp: 15.0 C
#     2023-11-23 20:52:53   summeractive    no
#     2023-11-23 20:52:53   tempadjust      0.0 C
#     2023-11-23 20:52:53   temperature     20.0 C (measured)
#     2023-11-23 20:52:53   windowopenactiv no
#     2023-11-23 20:52:53   windowopenactiveendtime N/A
#
setstate FBDECT_HKV_301_WZ desired-temp: 15.0 C
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 AIN 09995 0507067
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 FBNAME FRITZ!DECT 301 WZ
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 FBPROP actuator,tempSensor
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 FBTYPE FRITZ!DECT 301
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 ID 17
setstate FBDECT_HKV_301_WZ 2023-11-23 19:17:36 IODev FritzBoxHttp
setstate FBDECT_HKV_301_WZ 2023-11-23 20:55:53 actifity alive
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 battery 90 %
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 batteryPercent 90
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 batteryState ok
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 batterylow 0
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 boostactive no
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 boostactiveendtime N/A
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 day-temp 15.0 C
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 desired-temp 15.0 C
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 devicelock no
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 errorcode noError (0)
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 fwversion 05.08
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 holidayactive no
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 locked no
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 nextPeriodStart 2023-11-23 22:00:00
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 nextPeriodTemp 8.0 C
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 night-temp 8.0 C
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 present yes
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 state desired-temp: 15.0 C
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 summeractive no
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 tempadjust 0.0 C
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 temperature 20.0 C (measured)
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 windowopenactiv no
setstate FBDECT_HKV_301_WZ 2023-11-23 20:52:53 windowopenactiveendtime N/A

- FRITZ!DECT 440:
define FBDECT_Taster_440 FBDECT FritzBoxHttp:13979_0436912 avmButton,tempSensor
attr FBDECT_Taster_440 userattr myBattWechsel my_batteryType
attr FBDECT_Taster_440 DbLogExclude .*
attr FBDECT_Taster_440 DbLogInclude rel_humidity,temperature
attr FBDECT_Taster_440 alias AVM: Taster FRITZ!DECT 440
attr FBDECT_Taster_440 devStateIcon yes:10px-kreis-gruen no:10px-kreis-rot
attr FBDECT_Taster_440 event-on-change-reading .*
attr FBDECT_Taster_440 event-on-update-reading batteryPercent
attr FBDECT_Taster_440 icon taster_ch
attr FBDECT_Taster_440 myBattWechsel 2023-08-01
attr FBDECT_Taster_440 my_batteryType 2xAAA
attr FBDECT_Taster_440 room Geräte->AVM
attr FBDECT_Taster_440 stateFormat present\
state_info
attr FBDECT_Taster_440 userReadings state_info {sprintf ("Temp: %.1f°C, Hum: %.1f%%, Dew: %.1f°C, Bat: %.0f%%", ReadingsNum($name,"temperature",0), ReadingsNum($name,"rel_humidity",0), ReadingsNum($name,"dewpoint",0), ReadingsNum($name,"batteryPercent",0))},\
schimmelt {sprintf ("%.1f°C",schimmelfreiMinTemp(ReadingsNum("$name","temperature",20),ReadingsNum("$name","rel_humidity",100),70))}
#   DEF        FritzBoxHttp:13979_0436912 avmButton,tempSensor
#   FUUID      64d40558-f33f-be0c-8393-e96996b281816048
#   FVERSION   10_FBDECT.pm:0.250690/2021-10-13
#   FritzBoxHttp_MSGCNT 21
#   FritzBoxHttp_TIME 2023-11-23 20:57:53
#   IODev      FritzBoxHttp
#   LASTInputDev FritzBoxHttp
#   MSGCNT     21
#   NAME       FBDECT_Taster_440
#   NR         289
#   STATE      yes
#Temp: 20.0°C, Hum: 62.0%, Dew: 12.5°C, Bat: 100%
#   TYPE       FBDECT
#   eventCount 23
#   id         13979_0436912
#   props      avmButton,tempSensor
#   Helper:
#     DBLOG:
#       rel_humidity:
#         LOG_Db:
#           TIME       1700764373.77117
#           VALUE      62
#   READINGS:
#     2023-11-23 20:57:53   AIN             13979 0436912
#     2023-11-23 20:57:53   FBNAME          FRITZ!DECT 440
#     2023-11-23 20:57:53   FBPROP          avmButton,tempSensor
#     2023-11-23 20:57:53   FBTYPE          FRITZ!DECT 440
#     2023-11-23 20:57:53   ID              18
#     2023-11-23 19:17:36   IODev           FritzBoxHttp
#     2023-11-23 19:32:53   absoluteHumidity 10.7
#     2023-11-23 20:57:53   battery         100 %
#     2023-11-23 20:57:53   batteryPercent  100
#     2023-11-23 20:57:53   batteryState    ok
#     2023-11-23 20:57:53   batterylow      0
#     2023-11-23 19:32:53   dewpoint        12.5
#     2023-11-23 20:57:53   fwversion       05.32
#     2023-09-06 00:46:31   lastpressedtimestamp 2023-08-12 01:11:34
#     2023-09-06 00:46:31   lastpressedtimestamp_oben_links 2023-08-12 01:17:43
#     2023-09-06 00:46:31   lastpressedtimestamp_oben_rechts 2023-08-12 01:11:34
#     2023-09-06 00:46:31   lastpressedtimestamp_unten_links 2023-08-12 01:11:39
#     2023-09-06 00:46:31   lastpressedtimestamp_unten_rechts 2023-08-12 01:17:08
#     2023-11-23 20:57:53   present         yes
#     2023-11-23 20:57:53   rel_humidity    62 %
#     2023-11-23 20:57:53   schimmelt       17.8°C
#     2023-11-23 20:57:53   state_info      Temp: 20.0°C, Hum: 62.0%, Dew: 12.5°C, Bat: 100%
#     2023-11-23 20:57:53   tempadjust      0.0 C
#     2023-11-23 20:57:53   temperature     20.0 C (measured)
#     2023-11-23 19:32:53   vapourPressure  14.5
#
setstate FBDECT_Taster_440 yes\
Temp: 20.0°C, Hum: 62.0%, Dew: 12.5°C, Bat: 100%
setstate FBDECT_Taster_440 2023-11-23 20:57:53 AIN 13979 0436912
setstate FBDECT_Taster_440 2023-11-23 20:57:53 FBNAME FRITZ!DECT 440
setstate FBDECT_Taster_440 2023-11-23 20:57:53 FBPROP avmButton,tempSensor
setstate FBDECT_Taster_440 2023-11-23 20:57:53 FBTYPE FRITZ!DECT 440
setstate FBDECT_Taster_440 2023-11-23 20:57:53 ID 18
setstate FBDECT_Taster_440 2023-11-23 19:17:36 IODev FritzBoxHttp
setstate FBDECT_Taster_440 2023-11-23 19:32:53 absoluteHumidity 10.7
setstate FBDECT_Taster_440 2023-11-23 20:57:53 battery 100 %
setstate FBDECT_Taster_440 2023-11-23 20:57:53 batteryPercent 100
setstate FBDECT_Taster_440 2023-11-23 20:57:53 batteryState ok
setstate FBDECT_Taster_440 2023-11-23 20:57:53 batterylow 0
setstate FBDECT_Taster_440 2023-11-23 19:32:53 dewpoint 12.5
setstate FBDECT_Taster_440 2023-11-23 20:57:53 fwversion 05.32
setstate FBDECT_Taster_440 2023-09-06 00:46:31 lastpressedtimestamp 2023-08-12 01:11:34
setstate FBDECT_Taster_440 2023-09-06 00:46:31 lastpressedtimestamp_oben_links 2023-08-12 01:17:43
setstate FBDECT_Taster_440 2023-09-06 00:46:31 lastpressedtimestamp_oben_rechts 2023-08-12 01:11:34
setstate FBDECT_Taster_440 2023-09-06 00:46:31 lastpressedtimestamp_unten_links 2023-08-12 01:11:39
setstate FBDECT_Taster_440 2023-09-06 00:46:31 lastpressedtimestamp_unten_rechts 2023-08-12 01:17:08
setstate FBDECT_Taster_440 2023-11-23 20:57:53 present yes
setstate FBDECT_Taster_440 2023-11-23 20:57:53 rel_humidity 62 %
setstate FBDECT_Taster_440 2023-11-23 20:57:53 schimmelt 17.8°C
setstate FBDECT_Taster_440 2023-11-23 20:57:53 state_info Temp: 20.0°C, Hum: 62.0%, Dew: 12.5°C, Bat: 100%
setstate FBDECT_Taster_440 2023-11-23 20:57:53 tempadjust 0.0 C
setstate FBDECT_Taster_440 2023-11-23 20:57:53 temperature 20.0 C (measured)
setstate FBDECT_Taster_440 2023-11-23 19:32:53 vapourPressure 14.5

Lidl Bewegungsmelder »SMSZ 1 B2«
https://www.zigbee2mqtt.io/devices/HG06335_HG07310.html#lidl-hg06335%252Fhg07310
define MQTT2_zigbee_Lidl_BWM_1 MQTT2_DEVICE zigbee_Lidl_BWM_1
attr MQTT2_zigbee_Lidl_BWM_1 userattr HomeModeAlarmActive HomeReadings HomeValues HomeSensorLocation:inside,outside myBattWechsel my_batteryType
attr MQTT2_zigbee_Lidl_BWM_1 DbLogExclude .*
attr MQTT2_zigbee_Lidl_BWM_1 DbLogInclude occupancy
attr MQTT2_zigbee_Lidl_BWM_1 HomeModeAlarmActive armaway
attr MQTT2_zigbee_Lidl_BWM_1 HomeSensorLocation inside
attr MQTT2_zigbee_Lidl_BWM_1 alias zigbee_BWM_Kueche_1
attr MQTT2_zigbee_Lidl_BWM_1 comment jsonMap war: battery:batteryPercent voltage:batterymV\
geändert in:\
jsonMap: voltage:batterymV \
userReadings: batteryPercent:battery.* {ReadingsNum($name,'battery',0)}\
---\
devStateIcon:\
Motion..true:people_sensor Motion..false:motion_detector\
Motion..true:people_sensor Motion..false:motion_detector Secure..true:secur_open@red Secure..false:secur_locked@green'\

attr MQTT2_zigbee_Lidl_BWM_1 devStateIcon Motion..true:people_sensor Motion..false:motion_detector Secure..true:secur_open@red Secure..false:secur_locked@green online:10px-kreis-gruen offline:10px-kreis-rot
attr MQTT2_zigbee_Lidl_BWM_1 devicetopic zigbee2mqtt/Lidl_BWM_1
attr MQTT2_zigbee_Lidl_BWM_1 event-on-change-reading .*
attr MQTT2_zigbee_Lidl_BWM_1 event-on-update-reading batteryPercent
attr MQTT2_zigbee_Lidl_BWM_1 icon people_sensor
attr MQTT2_zigbee_Lidl_BWM_1 jsonMap voltage:batterymV
attr MQTT2_zigbee_Lidl_BWM_1 model zigbee2mqtt_human_body_movement
attr MQTT2_zigbee_Lidl_BWM_1 myBattWechsel 0
attr MQTT2_zigbee_Lidl_BWM_1 my_batteryType 2xAAA
attr MQTT2_zigbee_Lidl_BWM_1 readingList $DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }\
zigbee2mqtt/Lidl_BWM_1/availability:.* availability
attr MQTT2_zigbee_Lidl_BWM_1 room Geräte->Zigbee,Zimmer->Küche
attr MQTT2_zigbee_Lidl_BWM_1 stateFormat availability\
Motion: occupancy\
 Battery: batteryPercent%\
Secure: tamper
attr MQTT2_zigbee_Lidl_BWM_1 userReadings batteryVoltage:batterymV.* {ReadingsNum($name,'batterymV',0)/1000}, batteryPercent:battery.* {ReadingsNum($name,'battery',0)}, batteryState {if (ReadingsNum($name, "battery", 0) > 25) {return "ok"} else {return "low"}}
#   CID        zigbee_Lidl_BWM_1
#   DEF        zigbee_Lidl_BWM_1
#   FUUID      63964301-f33f-be0c-dfa0-b165737aed677f5a
#   FVERSION   10_MQTT2_DEVICE.pm:0.279350/2023-09-05
#   IODev      mqtt2server
#   LASTInputDev mqtt2server
#   MSGCNT     11
#   NAME       MQTT2_zigbee_Lidl_BWM_1
#   NR         243
#   STATE      online
#Motion: false
# Battery: 92%
#Secure: false
#   TYPE       MQTT2_DEVICE
#   eventCount 12
#   mqtt2server_CONN mqtt2server_172.18.0.4_43194
#   mqtt2server_MSGCNT 11
#   mqtt2server_TIME 2023-11-23 21:03:40
#   Helper:
#     DBLOG:
#       occupancy:
#         LOG_Db:
#           TIME       1700767612.1643
#           VALUE      false
#   JSONMAP:
#     voltage    batterymV
#   READINGS:
#     2023-11-23 19:17:36   IODev           mqtt2server
#     2022-12-16 03:13:05   associatedWith  MQTT2_zigbee_bridge
#     2022-12-11 22:03:25   attrTemplateVersion 20201208
#     2023-11-23 19:17:55   availability    online
#     2023-11-23 21:03:40   battery         92
#     2023-11-23 18:01:55   batteryPercent  92
#     2023-11-23 21:03:40   batteryState    ok
#     2023-11-23 18:01:55   batteryVoltage  2.9
#     2023-11-23 21:03:40   battery_low     false
#     2023-11-23 21:03:40   batterymV       2900
#     2023-11-23 21:03:40   last_seen       2023-11-23T20:03:40.853Z
#     2023-11-23 21:03:40   linkquality     255
#     2023-11-23 21:03:40   occupancy       false
#     2023-11-23 21:03:40   tamper          false
#
setstate MQTT2_zigbee_Lidl_BWM_1 online\
Motion: false\
 Battery: 92%\
Secure: false
setstate MQTT2_zigbee_Lidl_BWM_1 2023-11-23 19:17:36 IODev mqtt2server
setstate MQTT2_zigbee_Lidl_BWM_1 2022-12-16 03:13:05 associatedWith MQTT2_zigbee_bridge
setstate MQTT2_zigbee_Lidl_BWM_1 2022-12-11 22:03:25 attrTemplateVersion 20201208
setstate MQTT2_zigbee_Lidl_BWM_1 2023-11-23 19:17:55 availability online
setstate MQTT2_zigbee_Lidl_BWM_1 2023-11-23 21:03:40 battery 92
setstate MQTT2_zigbee_Lidl_BWM_1 2023-11-23 18:01:55 batteryPercent 92
setstate MQTT2_zigbee_Lidl_BWM_1 2023-11-23 21:03:40 batteryState ok
setstate MQTT2_zigbee_Lidl_BWM_1 2023-11-23 18:01:55 batteryVoltage 2.9
setstate MQTT2_zigbee_Lidl_BWM_1 2023-11-23 21:03:40 battery_low false
setstate MQTT2_zigbee_Lidl_BWM_1 2023-11-23 21:03:40 batterymV 2900
setstate MQTT2_zigbee_Lidl_BWM_1 2023-11-23 21:03:40 last_seen 2023-11-23T20:03:40.853Z
setstate MQTT2_zigbee_Lidl_BWM_1 2023-11-23 21:03:40 linkquality 255
setstate MQTT2_zigbee_Lidl_BWM_1 2023-11-23 21:03:40 occupancy false
setstate MQTT2_zigbee_Lidl_BWM_1 2023-11-23 21:03:40 tamper false

Lidl Tür Fensterkontakt
https://www.zigbee2mqtt.io/devices/HG06336.html#lidl-hg06336
define MQTT2_zigbee_Lidl_Kontakt_1 MQTT2_DEVICE zigbee_Lidl_Kontakt_1
attr MQTT2_zigbee_Lidl_Kontakt_1 userattr myBattWechsel my_batteryType
attr MQTT2_zigbee_Lidl_Kontakt_1 DbLogExclude .*
attr MQTT2_zigbee_Lidl_Kontakt_1 alias zigbee_Kontakt_Wohnungstuer
attr MQTT2_zigbee_Lidl_Kontakt_1 devStateIcon open:fts_window_1w_open@red closed:fts_window_1w@green  Secure..true:secur_open@red Secure..false:secur_locked@gree online:10px-kreis-gruen offline:10px-kreis-rot
attr MQTT2_zigbee_Lidl_Kontakt_1 devicetopic zigbee2mqtt/Lidl_Kontakt_1
attr MQTT2_zigbee_Lidl_Kontakt_1 event-on-change-reading .*
attr MQTT2_zigbee_Lidl_Kontakt_1 event-on-update-reading batteryPercent
attr MQTT2_zigbee_Lidl_Kontakt_1 genericDeviceType ContactSensor
attr MQTT2_zigbee_Lidl_Kontakt_1 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED
attr MQTT2_zigbee_Lidl_Kontakt_1 icon fts_window_1w
attr MQTT2_zigbee_Lidl_Kontakt_1 jsonMap contact:state
attr MQTT2_zigbee_Lidl_Kontakt_1 model zigbee2mqtt_ContactSensor
attr MQTT2_zigbee_Lidl_Kontakt_1 myBattWechsel 0
attr MQTT2_zigbee_Lidl_Kontakt_1 my_batteryType 2xAAA
attr MQTT2_zigbee_Lidl_Kontakt_1 readingList $DEVICETOPIC:.* { my $ret=json2nameValue($EVENT,'',$JSONMAP);; $ret->{state}=$ret->{state} eq 'true' ? 'closed' : 'open';; return $ret }\
zigbee2mqtt/Lidl_Kontakt_1/availability:.* availability
attr MQTT2_zigbee_Lidl_Kontakt_1 room Zimmer->Flur,Geräte->Zigbee
attr MQTT2_zigbee_Lidl_Kontakt_1 stateFormat availability\
state\
 Battery: battery%\
Secure: tamper
attr MQTT2_zigbee_Lidl_Kontakt_1 userReadings batteryPercent {ReadingsNum($name,'battery','0')}, batteryState {if (ReadingsNum($name, "battery", 0) > 25) {return "ok"} else {return "low"}}
#   CID        zigbee_Lidl_Kontakt_1
#   DEF        zigbee_Lidl_Kontakt_1
#   FUUID      637bcf1a-f33f-be0c-9804-9ecba85255e59624
#   FVERSION   10_MQTT2_DEVICE.pm:0.279350/2023-09-05
#   IODev      mqtt2server
#   LASTInputDev mqtt2server
#   MSGCNT     2
#   NAME       MQTT2_zigbee_Lidl_Kontakt_1
#   NR         237
#   STATE      online
#closed
# Battery: 42.5%
#Secure: false
#   TYPE       MQTT2_DEVICE
#   eventCount 2
#   mqtt2server_CONN mqtt2server_172.18.0.4_43194
#   mqtt2server_MSGCNT 2
#   mqtt2server_TIME 2023-11-23 20:14:55
#   JSONMAP:
#     contact    state
#   READINGS:
#     2023-11-23 19:17:36   IODev           mqtt2server
#     2022-11-22 00:25:02   associatedWith  MQTT2_zigbee_bridge
#     2022-11-21 20:19:24   attrTemplateVersion 20220622
#     2023-11-23 19:17:55   availability    online
#     2023-11-23 20:14:55   battery         42.5
#     2023-11-23 20:14:55   batteryPercent  42.5
#     2023-11-23 20:14:55   batteryState    ok
#     2023-11-23 20:14:55   battery_low     false
#     2023-11-23 20:14:55   last_seen       2023-11-23T19:14:55.395Z
#     2023-11-23 20:14:55   linkquality     255
#     2023-11-23 20:14:55   state           closed
#     2023-11-23 20:14:55   tamper          false
#
setstate MQTT2_zigbee_Lidl_Kontakt_1 online\
closed\
 Battery: 42.5%\
Secure: false
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-23 19:17:36 IODev mqtt2server
setstate MQTT2_zigbee_Lidl_Kontakt_1 2022-11-22 00:25:02 associatedWith MQTT2_zigbee_bridge
setstate MQTT2_zigbee_Lidl_Kontakt_1 2022-11-21 20:19:24 attrTemplateVersion 20220622
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-23 19:17:55 availability online
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-23 20:14:55 battery 42.5
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-23 20:14:55 batteryPercent 42.5
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-23 20:14:55 batteryState ok
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-23 20:14:55 battery_low false
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-23 20:14:55 last_seen 2023-11-23T19:14:55.395Z
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-23 20:14:55 linkquality 255
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-23 20:14:55 state closed
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-23 20:14:55 tamper false

SONOFF SNZB-02 ZigBee Mini Innentemperatur Luftfeuchtigkeitssensor
https://www.zigbee2mqtt.io/devices/SNZB-02.html#sonoff-snzb-02
define MQTT2_zigbee_SONOFF_TH01_Medikamente MQTT2_DEVICE zigbee_SONOFF_TH01_Medikamente
attr MQTT2_zigbee_SONOFF_TH01_Medikamente userattr myBattWechsel my_batteryType
attr MQTT2_zigbee_SONOFF_TH01_Medikamente DbLogExclude .*
attr MQTT2_zigbee_SONOFF_TH01_Medikamente DbLogInclude humidity,temperature
attr MQTT2_zigbee_SONOFF_TH01_Medikamente devStateIcon online:10px-kreis-gruen offline.*:10px-kreis-rot
attr MQTT2_zigbee_SONOFF_TH01_Medikamente devicetopic zigbee2mqtt/SONOFF_TH01_Medikamente
attr MQTT2_zigbee_SONOFF_TH01_Medikamente event-on-change-reading .*
attr MQTT2_zigbee_SONOFF_TH01_Medikamente event-on-update-reading batteryPercent
attr MQTT2_zigbee_SONOFF_TH01_Medikamente icon temperature_humidity
attr MQTT2_zigbee_SONOFF_TH01_Medikamente model zigbee2mqtt_TempHumSensor
attr MQTT2_zigbee_SONOFF_TH01_Medikamente myBattWechsel 0
attr MQTT2_zigbee_SONOFF_TH01_Medikamente my_batteryType 1xCR2450
attr MQTT2_zigbee_SONOFF_TH01_Medikamente readingList $DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }\
zigbee2mqtt/SONOFF_TH01_Medikamente/availability:.* availability
attr MQTT2_zigbee_SONOFF_TH01_Medikamente room Geräte->Zigbee
attr MQTT2_zigbee_SONOFF_TH01_Medikamente stateFormat availability\
formatedState
attr MQTT2_zigbee_SONOFF_TH01_Medikamente userReadings batteryPercent {ReadingsNum($name,'battery','0')}, batteryState {if (ReadingsNum($name, "battery", 0) > 25) {return "ok"} else {return "low"}}, formatedState {sprintf ("Temperature: %.1f°C Humidity: %.1f%%", ReadingsVal($name,"temperature",0), ReadingsVal($name,"humidity",0)) }
#   CID        zigbee_SONOFF_TH01_Medikamente
#   DEF        zigbee_SONOFF_TH01_Medikamente
#   FUUID      637b8492-f33f-be0c-64d7-b9c221f5e385832f
#   FVERSION   10_MQTT2_DEVICE.pm:0.279350/2023-09-05
#   IODev      mqtt2server
#   LASTInputDev mqtt2server
#   MSGCNT     181
#   NAME       MQTT2_zigbee_SONOFF_TH01_Medikamente
#   NR         233
#   STATE      online
#Temperature: 18.6°C Humidity: 65.7%
#   TYPE       MQTT2_DEVICE
#   eventCount 181
#   mqtt2server_CONN mqtt2server_172.18.0.4_43194
#   mqtt2server_MSGCNT 181
#   mqtt2server_TIME 2023-11-23 21:09:34
#   Helper:
#     DBLOG:
#       humidity:
#         LOG_Db:
#           TIME       1700770174.71745
#           VALUE      65.7
#       temperature:
#         LOG_Db:
#           TIME       1700769712.88877
#           VALUE      18.6
#   READINGS:
#     2023-11-23 19:17:36   IODev           mqtt2server
#     2022-11-21 20:08:49   associatedWith  MQTT2_zigbee_bridge
#     2022-11-21 15:06:05   attrTemplateVersion 20200904
#     2023-11-23 19:17:55   availability    online
#     2023-11-23 21:09:34   battery         79
#     2023-11-23 21:09:34   batteryPercent  79
#     2023-11-23 21:09:34   batteryState    ok
#     2023-11-23 21:09:34   formatedState   Temperature: 18.6°C Humidity: 65.7%
#     2023-11-23 21:09:34   humidity        65.7
#     2023-11-23 21:09:34   last_seen       2023-11-23T20:09:34.701Z
#     2023-11-23 21:09:34   linkquality     255
#     2023-11-23 21:09:34   temperature     18.6
#     2023-11-23 21:09:34   voltage         2900
#
setstate MQTT2_zigbee_SONOFF_TH01_Medikamente online\
Temperature: 18.6°C Humidity: 65.7%
setstate MQTT2_zigbee_SONOFF_TH01_Medikamente 2023-11-23 19:17:36 IODev mqtt2server
setstate MQTT2_zigbee_SONOFF_TH01_Medikamente 2022-11-21 20:08:49 associatedWith MQTT2_zigbee_bridge
setstate MQTT2_zigbee_SONOFF_TH01_Medikamente 2022-11-21 15:06:05 attrTemplateVersion 20200904
setstate MQTT2_zigbee_SONOFF_TH01_Medikamente 2023-11-23 19:17:55 availability online
setstate MQTT2_zigbee_SONOFF_TH01_Medikamente 2023-11-23 21:09:34 battery 79
setstate MQTT2_zigbee_SONOFF_TH01_Medikamente 2023-11-23 21:09:34 batteryPercent 79
setstate MQTT2_zigbee_SONOFF_TH01_Medikamente 2023-11-23 21:09:34 batteryState ok
setstate MQTT2_zigbee_SONOFF_TH01_Medikamente 2023-11-23 21:09:34 formatedState Temperature: 18.6°C Humidity: 65.7%
setstate MQTT2_zigbee_SONOFF_TH01_Medikamente 2023-11-23 21:09:34 humidity 65.7
setstate MQTT2_zigbee_SONOFF_TH01_Medikamente 2023-11-23 21:09:34 last_seen 2023-11-23T20:09:34.701Z
setstate MQTT2_zigbee_SONOFF_TH01_Medikamente 2023-11-23 21:09:34 linkquality 255
setstate MQTT2_zigbee_SONOFF_TH01_Medikamente 2023-11-23 21:09:34 temperature 18.6
setstate MQTT2_zigbee_SONOFF_TH01_Medikamente 2023-11-23 21:09:34 voltage 2900

Ikea Bewegungsmelder (TRADFRI) - im Moment nicht in Betrieb
https://www.zigbee2mqtt.io/devices/E1525_E1745.html#ikea-e1525%252Fe1745
define MQTT2_zigbee_TRADFRI_MotionSensor1 MQTT2_DEVICE zigbee_TRADFRI_MotionSensor1
attr MQTT2_zigbee_TRADFRI_MotionSensor1 userattr HomeModeAlarmActive HomeReadings HomeValues HomeSensorLocation:inside,outside myBattWechsel my_batteryType
attr MQTT2_zigbee_TRADFRI_MotionSensor1 DbLogExclude .*
attr MQTT2_zigbee_TRADFRI_MotionSensor1 HomeModeAlarmActive armaway
attr MQTT2_zigbee_TRADFRI_MotionSensor1 HomeSensorLocation inside
attr MQTT2_zigbee_TRADFRI_MotionSensor1 devStateIcon Motion..true:people_sensor Motion..false:motion_detector online:10px-kreis-gruen offline:10px-kreis-rot
attr MQTT2_zigbee_TRADFRI_MotionSensor1 devicetopic zigbee2mqtt/TRADFRI_MotionSensor1
attr MQTT2_zigbee_TRADFRI_MotionSensor1 event-on-change-reading .*
attr MQTT2_zigbee_TRADFRI_MotionSensor1 event-on-update-reading batteryPercent
attr MQTT2_zigbee_TRADFRI_MotionSensor1 icon people_sensor
attr MQTT2_zigbee_TRADFRI_MotionSensor1 jsonMap battery:batteryPercent voltage:batterymV illuminance_lux:0
attr MQTT2_zigbee_TRADFRI_MotionSensor1 model zigbee2mqtt_human_body_movement_illuminance
attr MQTT2_zigbee_TRADFRI_MotionSensor1 myBattWechsel 0
attr MQTT2_zigbee_TRADFRI_MotionSensor1 my_batteryType 2xCR2032
attr MQTT2_zigbee_TRADFRI_MotionSensor1 readingList $DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }\
zigbee2mqtt/TRADFRI_MotionSensor1/availability:.* availability
attr MQTT2_zigbee_TRADFRI_MotionSensor1 room Geräte->Zigbee
attr MQTT2_zigbee_TRADFRI_MotionSensor1 stateFormat availability\
Motion: occupancy\
 Luminance: requested_brightness_level Battery: batteryPercent%
attr MQTT2_zigbee_TRADFRI_MotionSensor1 userReadings batteryVoltage:batterymV.* {ReadingsNum($name,'batterymV',0)/1000}
#   CID        zigbee_TRADFRI_MotionSensor1
#   DEF        zigbee_TRADFRI_MotionSensor1
#   FUUID      637bcfe4-f33f-be0c-aa27-04a558d5f2da221b
#   FVERSION   10_MQTT2_DEVICE.pm:0.279350/2023-09-05
#   IODev      mqtt2server
#   LASTInputDev mqtt2server
#   MSGCNT     1
#   NAME       MQTT2_zigbee_TRADFRI_MotionSensor1
#   NR         239
#   STATE      offline
#Motion: false
# Luminance: 76 Battery: 60%
#   TYPE       MQTT2_DEVICE
#   eventCount 2
#   mqtt2server_CONN mqtt2server_172.18.0.4_43194
#   mqtt2server_MSGCNT 1
#   mqtt2server_TIME 2023-11-23 19:17:55
#   JSONMAP:
#     battery    batteryPercent
#     illuminance_lux 0
#     voltage    batterymV
#   READINGS:
#     2023-11-23 19:17:36   IODev           mqtt2server
#     2022-12-16 03:13:05   associatedWith  MQTT2_zigbee_bridge
#     2022-12-11 22:19:42   attrTemplateVersion 20201208
#     2023-11-23 19:17:55   availability    offline
#     2023-11-20 14:45:47   batteryPercent  60
#     2023-11-20 14:45:47   illuminance_above_threshold false
#     2023-11-20 14:45:47   last_seen       2023-03-21T13:23:29.386Z
#     2023-11-20 14:45:47   linkquality     255
#     2023-11-20 14:45:47   occupancy       false
#     2023-11-20 14:45:47   requested_brightness_level 76
#     2023-11-20 14:45:47   requested_brightness_percent 30
#     2023-11-20 14:45:47   update_available false
#     2023-11-20 14:45:47   update_state    idle
#
setstate MQTT2_zigbee_TRADFRI_MotionSensor1 offline\
Motion: false\
 Luminance: 76 Battery: 60%
setstate MQTT2_zigbee_TRADFRI_MotionSensor1 2023-11-23 19:17:36 IODev mqtt2server
setstate MQTT2_zigbee_TRADFRI_MotionSensor1 2022-12-16 03:13:05 associatedWith MQTT2_zigbee_bridge
setstate MQTT2_zigbee_TRADFRI_MotionSensor1 2022-12-11 22:19:42 attrTemplateVersion 20201208
setstate MQTT2_zigbee_TRADFRI_MotionSensor1 2023-11-23 19:17:55 availability offline
setstate MQTT2_zigbee_TRADFRI_MotionSensor1 2023-11-20 14:45:47 batteryPercent 60
setstate MQTT2_zigbee_TRADFRI_MotionSensor1 2023-11-20 14:45:47 illuminance_above_threshold false
setstate MQTT2_zigbee_TRADFRI_MotionSensor1 2023-11-20 14:45:47 last_seen 2023-03-21T13:23:29.386Z
setstate MQTT2_zigbee_TRADFRI_MotionSensor1 2023-11-20 14:45:47 linkquality 255
setstate MQTT2_zigbee_TRADFRI_MotionSensor1 2023-11-20 14:45:47 occupancy false
setstate MQTT2_zigbee_TRADFRI_MotionSensor1 2023-11-20 14:45:47 requested_brightness_level 76
setstate MQTT2_zigbee_TRADFRI_MotionSensor1 2023-11-20 14:45:47 requested_brightness_percent 30
setstate MQTT2_zigbee_TRADFRI_MotionSensor1 2023-11-20 14:45:47 update_available false
setstate MQTT2_zigbee_TRADFRI_MotionSensor1 2023-11-20 14:45:47 update_state idle

Ikea ON/OFF switch (TRADFRI)
https://www.zigbee2mqtt.io/devices/E1743.html#ikea-e1743
define MQTT2_zigbee_TRADFRI_OnOffSwitch3 MQTT2_DEVICE zigbee_TRADFRI_OnOffSwitch3
attr MQTT2_zigbee_TRADFRI_OnOffSwitch3 userattr myBattWechsel my_batteryType
attr MQTT2_zigbee_TRADFRI_OnOffSwitch3 DbLogExclude .*
attr MQTT2_zigbee_TRADFRI_OnOffSwitch3 devStateIcon online:10px-kreis-gruen offline:10px-kreis-rot
attr MQTT2_zigbee_TRADFRI_OnOffSwitch3 devicetopic zigbee2mqtt/TRADFRI_OnOffSwitch3
attr MQTT2_zigbee_TRADFRI_OnOffSwitch3 event-on-change-reading .*
attr MQTT2_zigbee_TRADFRI_OnOffSwitch3 event-on-update-reading batteryPercent
attr MQTT2_zigbee_TRADFRI_OnOffSwitch3 icon tradfri_dimmerswitch
attr MQTT2_zigbee_TRADFRI_OnOffSwitch3 jsonMap battery:batteryPercent voltage:batterymV
attr MQTT2_zigbee_TRADFRI_OnOffSwitch3 model zigbee2mqtt_Wireless_Button
attr MQTT2_zigbee_TRADFRI_OnOffSwitch3 myBattWechsel 0
attr MQTT2_zigbee_TRADFRI_OnOffSwitch3 my_batteryType 1xCR2032
attr MQTT2_zigbee_TRADFRI_OnOffSwitch3 readingList $DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }\
zigbee2mqtt/TRADFRI_OnOffSwitch3/availability:.* availability
attr MQTT2_zigbee_TRADFRI_OnOffSwitch3 room Geräte->Zigbee
attr MQTT2_zigbee_TRADFRI_OnOffSwitch3 stateFormat availability\
Batterie: batteryPercent%, Action: action
attr MQTT2_zigbee_TRADFRI_OnOffSwitch3 userReadings battery:batteryPercent.* {ReadingsNum($name,'batteryPercent',0)}, batteryState {if (ReadingsNum($name, "battery", 0) > 25) {return "ok"} else {return "low"}}
#   CID        zigbee_TRADFRI_OnOffSwitch3
#   DEF        zigbee_TRADFRI_OnOffSwitch3
#   FUUID      64302a05-f33f-be0c-d574-721a1e0314d3c815
#   FVERSION   10_MQTT2_DEVICE.pm:0.279350/2023-09-05
#   IODev      mqtt2server
#   LASTInputDev mqtt2server
#   MSGCNT     2
#   NAME       MQTT2_zigbee_TRADFRI_OnOffSwitch3
#   NR         267
#   STATE      online
#Batterie: 75%, Action: on
#   TYPE       MQTT2_DEVICE
#   eventCount 3
#   mqtt2server_CONN mqtt2server_172.18.0.4_43194
#   mqtt2server_MSGCNT 2
#   mqtt2server_TIME 2023-11-23 21:09:34
#   JSONMAP:
#     battery    batteryPercent
#     voltage    batterymV
#   READINGS:
#     2023-11-23 19:17:36   IODev           mqtt2server
#     2023-10-12 01:03:34   action          on
#     2023-10-12 01:03:30   action_brightness_delta 5
#     2023-10-12 01:03:30   action_rate     83
#     2023-04-07 16:34:45   associatedWith  MQTT2_zigbee_bridge
#     2023-04-07 16:39:21   attrTemplateVersion 20201208
#     2023-11-23 19:17:55   availability    online
#     2023-11-23 21:09:34   battery         75
#     2023-11-23 21:09:34   batteryPercent  75
#     2023-11-23 21:09:34   batteryState    ok
#     2023-11-23 21:09:34   brightness      225
#     2023-11-23 21:09:34   last_seen       2023-11-23T20:09:34.668Z
#     2023-11-23 21:09:34   linkquality     255
#     2023-11-23 21:09:34   update_available false
#     2023-11-23 21:09:34   update_installed_version 604241926
#     2023-11-23 21:09:34   update_latest_version 604241926
#     2023-06-15 02:54:26   update_progress 100
#     2023-06-15 02:54:26   update_remaining 6
#     2023-11-23 21:09:34   update_state    idle
#
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 online\
Batterie: 75%, Action: on
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-11-23 19:17:36 IODev mqtt2server
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-10-12 01:03:34 action on
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-10-12 01:03:30 action_brightness_delta 5
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-10-12 01:03:30 action_rate 83
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-04-07 16:34:45 associatedWith MQTT2_zigbee_bridge
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-04-07 16:39:21 attrTemplateVersion 20201208
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-11-23 19:17:55 availability online
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-11-23 21:09:34 battery 75
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-11-23 21:09:34 batteryPercent 75
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-11-23 21:09:34 batteryState ok
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-11-23 21:09:34 brightness 225
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-11-23 21:09:34 last_seen 2023-11-23T20:09:34.668Z
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-11-23 21:09:34 linkquality 255
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-11-23 21:09:34 update_available false
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-11-23 21:09:34 update_installed_version 604241926
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-11-23 21:09:34 update_latest_version 604241926
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-06-15 02:54:26 update_progress 100
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-06-15 02:54:26 update_remaining 6
setstate MQTT2_zigbee_TRADFRI_OnOffSwitch3 2023-11-23 21:09:34 update_state idle

Xiaomi Mi Temperatur und Luftfeuchtigkeit Monitor
LYWSD03MMC mit alternativer Firmware (über Bluetooth - ESP32->OpenMQTTGateway / tasmota32-bluetooth.bin)
define OMG_A4C1381A61FB MQTT2_DEVICE A4C1381A61FB
attr OMG_A4C1381A61FB userattr myBattWechsel my_batteryType
attr OMG_A4C1381A61FB DbLogExclude .*
attr OMG_A4C1381A61FB DbLogInclude humidity,temperature
attr OMG_A4C1381A61FB IODev mqtt2server
attr OMG_A4C1381A61FB alias OMG 1FB WZ
attr OMG_A4C1381A61FB autocreate 0
attr OMG_A4C1381A61FB devStateIcon alive:10px-kreis-gruen dead:10px-kreis-rot
attr OMG_A4C1381A61FB event-on-change-reading batteryPercent,temperature:0.2,humidity:0.5,distance:5
attr OMG_A4C1381A61FB event-on-update-reading batteryPercent
attr OMG_A4C1381A61FB icon temperature_humidity
attr OMG_A4C1381A61FB jsonMap batt:batteryPercent tempc:temperature tem:0 tempf:0 hum:humidity servicedatauuid:0 servicedata:0
attr OMG_A4C1381A61FB model OpenMQTTGateway_BT_temp_hum_sensor
attr OMG_A4C1381A61FB myBattWechsel 0
attr OMG_A4C1381A61FB my_batteryType 1xCR2032
attr OMG_A4C1381A61FB readingList home/O[^/]*M[^/]*G[^/]*/BTtoMQTT/A4C1381A61FB:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr OMG_A4C1381A61FB readingsWatcher 3600,,humidity,temperature,rssi
attr OMG_A4C1381A61FB room Geräte->ESP32
attr OMG_A4C1381A61FB stateFormat actifity\
state_info
attr OMG_A4C1381A61FB userReadings state_info {sprintf ("Temp: %.1f°C, Hum: %.1f%%, Dew: %.1f°C, Bat: %.0f%%", ReadingsNum($name,"temperature",0), ReadingsNum($name,"humidity",0), ReadingsNum($name,"dewpoint",0), ReadingsNum($name,"batteryPercent",0))},\
schimmelt {schimmelfreiMinTemp(ReadingsNum("$name","temperature",20),ReadingsNum("$name","humidity",100),70)}
#   CID        A4C1381A61FB
#   DEF        A4C1381A61FB
#   FUUID      649b5190-f33f-be0c-bf9c-4c884b3cad37f2b4
#   FVERSION   10_MQTT2_DEVICE.pm:0.279350/2023-09-05
#   IODev      mqtt2server
#   LASTInputDev mqtt2server
#   MSGCNT     175
#   NAME       OMG_A4C1381A61FB
#   NR         281
#   STATE      alive
#Temp: 20.3°C, Hum: 61.0%, Dew: 12.5°C, Bat: 59%
#   TYPE       MQTT2_DEVICE
#   eventCount 177
#   mqtt2server_CONN mqtt2server_192.168.178.230_64178
#   mqtt2server_MSGCNT 175
#   mqtt2server_TIME 2023-11-23 21:22:52
#   Helper:
#     DBLOG:
#       temperature:
#         LOG_Db:
#           TIME       1700763476.73095
#           VALUE      20.3
#   JSONMAP:
#     batt       batteryPercent
#     hum        humidity
#     servicedata 0
#     servicedatauuid 0
#     tem        0
#     tempc      temperature
#     tempf      0
#   READINGS:
#     2023-11-23 19:17:36   IODev           mqtt2server
#     2023-11-23 19:17:56   absoluteHumidity 10.7
#     2023-11-23 21:23:53   actifity        alive
#     2023-06-27 23:16:00   attrTemplateVersion 20220220
#     2023-11-23 21:22:52   batteryPercent  59
#     2023-11-23 19:17:56   dewpoint        12.5
#     2023-11-23 21:22:52   humidity        61
#     2023-11-23 21:22:52   id              A4:C1:38:1A:61:FB
#     2023-11-23 21:22:52   model           LYWSD03MMC_ATC
#     2023-11-23 21:22:52   name            ATC_1A61FB
#     2023-11-23 21:22:52   rssi            -93
#     2023-11-23 21:23:53   schimmelt       17.8
#     2023-11-23 21:23:53   state_info      Temp: 20.3°C, Hum: 61.0%, Dew: 12.5°C, Bat: 59%
#     2023-11-23 21:22:52   temperature     20.3
#     2023-11-23 19:17:56   vapourPressure  14.5
#     2023-11-23 21:22:52   volt            2.752
#
setstate OMG_A4C1381A61FB alive\
Temp: 20.3°C, Hum: 61.0%, Dew: 12.5°C, Bat: 59%
setstate OMG_A4C1381A61FB 2023-11-23 19:17:36 IODev mqtt2server
setstate OMG_A4C1381A61FB 2023-11-23 19:17:56 absoluteHumidity 10.7
setstate OMG_A4C1381A61FB 2023-11-23 21:23:53 actifity alive
setstate OMG_A4C1381A61FB 2023-06-27 23:16:00 attrTemplateVersion 20220220
setstate OMG_A4C1381A61FB 2023-11-23 21:22:52 batteryPercent 59
setstate OMG_A4C1381A61FB 2023-11-23 19:17:56 dewpoint 12.5
setstate OMG_A4C1381A61FB 2023-11-23 21:22:52 humidity 61
setstate OMG_A4C1381A61FB 2023-11-23 21:22:52 id A4:C1:38:1A:61:FB
setstate OMG_A4C1381A61FB 2023-11-23 21:22:52 model LYWSD03MMC_ATC
setstate OMG_A4C1381A61FB 2023-11-23 21:22:52 name ATC_1A61FB
setstate OMG_A4C1381A61FB 2023-11-23 21:22:52 rssi -93
setstate OMG_A4C1381A61FB 2023-11-23 21:23:53 schimmelt 17.8
setstate OMG_A4C1381A61FB 2023-11-23 21:23:53 state_info Temp: 20.3°C, Hum: 61.0%, Dew: 12.5°C, Bat: 59%
setstate OMG_A4C1381A61FB 2023-11-23 21:22:52 temperature 20.3
setstate OMG_A4C1381A61FB 2023-11-23 19:17:56 vapourPressure 14.5
setstate OMG_A4C1381A61FB 2023-11-23 21:22:52 volt 2.752
im nächsten Post weiter - zu viele Zeichen?
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: LutzG am 23 November 2023, 21:55:11
Vielleicht noch Ereignisse vom Event-Monitor mit .*battery.* gefiltert:
2023-11-23 20:46:49.252 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:46:49.265 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":67.3,"last_seen":"2023-11-23T19:46:49.222Z","linkquality":255,"temperature":18.7,"voltage":2900}'
2023-11-23 20:46:49.282 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:46:59.270 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.3,"last_seen":"2023-11-23T19:46:59.247Z","linkquality":255,"temperature":18.7,"voltage":2900}'
2023-11-23 20:46:59.293 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:47:09.318 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.3,"last_seen":"2023-11-23T19:47:09.290Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 20:47:09.344 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:47:29.394 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.5,"last_seen":"2023-11-23T19:47:29.370Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 20:47:29.419 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:47:29.898 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:47:37.421 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 20:47:44.574 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:47:53.864 FBDECT FBDECT_HKV_301_WZ batteryPercent: 90
2023-11-23 20:47:53.881 FBDECT FBDECT_HKV_301_SZ batteryPercent: 90
2023-11-23 20:47:53.903 FBDECT FBDECT_Taster_440 batteryPercent: 100
2023-11-23 20:47:54.729 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 20:47:58.248 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 20:48:00.882 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 20:48:37.779 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:48:49.461 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 20:48:50.217 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 20:48:50.261 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 20:48:56.594 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:48:56.787 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 20:49:06.499 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 20:49:06.525 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 20:49:29.928 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.5,"last_seen":"2023-11-23T19:49:29.878Z","linkquality":255,"temperature":18.7,"voltage":2900}'
2023-11-23 20:49:29.952 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:49:39.948 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.5,"last_seen":"2023-11-23T19:49:39.921Z","linkquality":255,"temperature":18.5,"voltage":2900}'
2023-11-23 20:49:39.966 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:49:41.879 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:49:45.725 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 20:49:48.835 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 20:49:51.552 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 20:49:55.042 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:49:55.846 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 20:49:56.613 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.5,"last_seen":"2023-11-23T19:49:56.590Z","linkquality":255,"temperature":18.5,"voltage":2900}'
2023-11-23 20:49:56.634 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:49:56.650 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.5,"last_seen":"2023-11-23T19:49:56.603Z","linkquality":255,"temperature":18.5,"voltage":2900}'
2023-11-23 20:49:56.668 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:50:02.913 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 20:50:30.142 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.5,"last_seen":"2023-11-23T19:50:30.118Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 20:50:30.166 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:50:41.868 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/Lidl_Kontakt_3', payload '{"battery":100,"battery_low":false,"contact":true,"last_seen":"2023-11-23T19:50:41.846Z","linkquality":255,"tamper":false}'
2023-11-23 20:50:41.893 MQTT2_DEVICE MQTT2_zigbee_Lidl_Kontakt_3 batteryPercent: 100
2023-11-23 20:50:46.102 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:50:55.654 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 20:50:57.821 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 20:50:58.749 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 20:51:13.832 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 20:51:17.739 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 20:51:48.338 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:51:58.337 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 20:51:59.317 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 20:52:03.445 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:52:16.096 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 20:52:18.703 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 20:52:20.558 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 20:52:53.811 FBDECT FBDECT_HKV_301_WZ batteryPercent: 90
2023-11-23 20:52:53.831 FBDECT FBDECT_HKV_301_SZ batteryPercent: 90
2023-11-23 20:52:53.853 FBDECT FBDECT_Taster_440 batteryPercent: 100
2023-11-23 20:52:56.331 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:53:00.737 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":67.5,"last_seen":"2023-11-23T19:53:00.728Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 20:53:00.748 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:53:03.978 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 20:53:10.790 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.4,"last_seen":"2023-11-23T19:53:10.769Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 20:53:10.818 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:53:11.871 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 20:53:28.870 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 20:53:28.900 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 20:53:50.971 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.4,"last_seen":"2023-11-23T19:53:50.939Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 20:53:51.001 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:54:08.037 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:54:13.730 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:54:25.477 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 20:54:30.766 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 20:54:34.505 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:55:14.117 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:55:23.910 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 20:55:36.851 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 20:56:12.553 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:56:29.485 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 20:56:29.531 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:56:29.561 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 20:56:29.593 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 20:56:45.692 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 20:56:51.701 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.4,"last_seen":"2023-11-23T19:56:51.677Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 20:56:51.726 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:57:18.595 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:57:24.843 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 20:57:26.771 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 20:57:28.059 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:57:31.854 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.4,"last_seen":"2023-11-23T19:57:31.833Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 20:57:31.876 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:57:43.223 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 20:57:43.749 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 20:57:51.225 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 20:57:53.827 FBDECT FBDECT_HKV_301_WZ batteryPercent: 90
2023-11-23 20:57:53.852 FBDECT FBDECT_HKV_301_SZ batteryPercent: 90
2023-11-23 20:57:53.868 FBDECT FBDECT_Taster_440 batteryPercent: 100
2023-11-23 20:58:01.975 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.4,"last_seen":"2023-11-23T19:58:01.950Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 20:58:02.001 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:58:12.026 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.8,"last_seen":"2023-11-23T19:58:11.994Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 20:58:12.054 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:58:22.717 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:58:28.966 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 20:58:40.796 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 20:58:42.146 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.5,"last_seen":"2023-11-23T19:58:42.122Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 20:58:42.170 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:58:47.315 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 20:58:56.850 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 20:59:12.270 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.7,"last_seen":"2023-11-23T19:59:12.242Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 20:59:12.297 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:59:22.300 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.3,"last_seen":"2023-11-23T19:59:22.275Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 20:59:22.313 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 20:59:34.472 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:59:43.874 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 20:59:45.722 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 20:59:46.419 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 20:59:55.821 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:00:02.440 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":67,"last_seen":"2023-11-23T20:00:02.428Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:00:02.455 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:00:22.551 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.6,"last_seen":"2023-11-23T20:00:22.503Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:00:22.571 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:00:34.872 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:00:46.211 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:00:52.634 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.7,"last_seen":"2023-11-23T20:00:52.617Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:00:52.659 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:00:59.254 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:01:00.047 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:01:06.709 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:01:12.728 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.4,"last_seen":"2023-11-23T20:01:12.700Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:01:12.754 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:01:32.802 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.4,"last_seen":"2023-11-23T20:01:32.777Z","linkquality":255,"temperature":18.5,"voltage":2900}'
2023-11-23 21:01:32.827 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:01:39.113 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:01:47.189 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:01:50.474 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/Lidl_BWM_1', payload '{"battery":92,"battery_low":false,"last_seen":"2023-11-23T20:01:50.454Z","linkquality":255,"occupancy":false,"tamper":false,"voltage":2900}'
2023-11-23 21:01:52.880 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.4,"last_seen":"2023-11-23T20:01:52.857Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:01:52.905 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:01:52.918 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.8,"last_seen":"2023-11-23T20:01:52.870Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:01:52.935 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:01:54.830 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:01:56.088 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:01:57.661 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:02:02.929 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.6,"last_seen":"2023-11-23T20:02:02.904Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:02:02.956 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:02:11.824 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:02:12.746 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:02:43.097 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.7,"last_seen":"2023-11-23T20:02:43.069Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:02:43.123 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:02:52.747 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:02:53.766 FBDECT FBDECT_HKV_301_WZ batteryPercent: 90
2023-11-23 21:02:53.780 FBDECT FBDECT_HKV_301_SZ batteryPercent: 90
2023-11-23 21:02:53.792 FBDECT FBDECT_Taster_440 batteryPercent: 100
2023-11-23 21:02:58.131 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:03:00.901 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:03:13.206 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.4,"last_seen":"2023-11-23T20:03:13.181Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:03:13.235 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:03:18.781 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:03:19.248 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:03:19.265 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:03:23.239 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.9,"last_seen":"2023-11-23T20:03:23.214Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:03:23.263 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:03:40.872 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/Lidl_BWM_1', payload '{"battery":92,"battery_low":false,"last_seen":"2023-11-23T20:03:40.853Z","linkquality":255,"occupancy":false,"tamper":false,"voltage":2900}'
2023-11-23 21:03:43.321 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.6,"last_seen":"2023-11-23T20:03:43.301Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:03:43.346 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:03:48.158 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:03:59.460 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:04:08.071 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:04:17.453 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:04:24.848 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:04:26.565 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/Lidl_Kontakt_2', payload '{"battery":78,"battery_low":false,"contact":true,"last_seen":"2023-11-23T20:04:26.542Z","linkquality":208,"tamper":false}'
2023-11-23 21:04:26.591 MQTT2_DEVICE MQTT2_zigbee_Lidl_Kontakt_2 batteryPercent: 78
2023-11-23 21:04:49.661 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:05:14.183 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:05:14.429 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:05:14.509 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:05:21.452 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:05:30.424 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:05:59.324 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:06:18.308 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:06:20.079 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:06:20.127 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:06:29.348 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:06:30.385 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:06:54.107 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.7,"last_seen":"2023-11-23T20:06:54.074Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:06:54.129 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:07:04.896 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:07:17.472 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:07:22.189 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:07:24.207 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.7,"last_seen":"2023-11-23T20:07:24.181Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:07:24.235 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:07:25.696 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:07:25.755 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:07:31.636 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:07:41.660 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:07:41.678 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:07:53.797 FBDECT FBDECT_HKV_301_WZ batteryPercent: 90
2023-11-23 21:07:53.816 FBDECT FBDECT_HKV_301_SZ batteryPercent: 90
2023-11-23 21:07:53.832 FBDECT FBDECT_Taster_440 batteryPercent: 100
2023-11-23 21:08:05.980 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:08:29.266 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:08:31.344 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:08:37.689 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:08:47.256 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:09:10.090 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:09:16.140 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:09:24.660 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.9,"last_seen":"2023-11-23T20:09:24.651Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:09:24.672 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:09:30.434 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:09:34.200 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:09:34.683 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/TRADFRI_OnOffSwitch3', payload '{"battery":75,"brightness":225,"last_seen":"2023-11-23T20:09:34.668Z","linkquality":255,"update":{"installed_version":604241926,"latest_version":604241926,"state":"idle"},"update_available":false}'
2023-11-23 21:09:34.698 MQTT2_DEVICE MQTT2_zigbee_TRADFRI_OnOffSwitch3 batteryPercent: 75
2023-11-23 21:09:34.712 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.7,"last_seen":"2023-11-23T20:09:34.701Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:09:34.726 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:09:35.333 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:09:45.456 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:10:21.710 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:10:35.747 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:10:40.255 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:10:48.972 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:10:51.516 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:11:27.305 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:11:39.881 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:11:40.567 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:11:59.381 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:12:04.004 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:12:26.511 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:12:28.941 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:12:32.877 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:12:44.039 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:12:53.781 FBDECT FBDECT_HKV_301_WZ batteryPercent: 90
2023-11-23 21:12:53.794 FBDECT FBDECT_HKV_301_SZ batteryPercent: 90
2023-11-23 21:12:53.807 FBDECT FBDECT_Taster_440 batteryPercent: 100
2023-11-23 21:13:01.640 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:13:02.929 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:13:09.651 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:13:09.675 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:13:25.641 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.7,"last_seen":"2023-11-23T20:13:25.626Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:13:25.666 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:13:34.514 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:13:45.734 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.6,"last_seen":"2023-11-23T20:13:45.710Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:13:45.760 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:13:56.340 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:13:59.285 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:14:07.699 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:14:15.210 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:14:15.243 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:14:36.739 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:14:55.621 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:14:58.589 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:15:14.070 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:15:15.543 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:15:16.100 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.6,"last_seen":"2023-11-23T20:15:16.076Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:15:16.125 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:15:23.951 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/Lidl_Kontakt_1', payload '{"battery":42.5,"battery_low":false,"contact":true,"last_seen":"2023-11-23T20:15:23.926Z","linkquality":255,"tamper":false}'
2023-11-23 21:15:23.977 MQTT2_DEVICE MQTT2_zigbee_Lidl_Kontakt_1 batteryPercent: 42.5
2023-11-23 21:15:40.949 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:15:56.246 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.6,"last_seen":"2023-11-23T20:15:56.238Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:15:56.258 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:16:05.894 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:16:10.608 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:16:21.036 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:16:46.453 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.6,"last_seen":"2023-11-23T20:16:46.427Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:16:46.478 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:16:49.344 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:16:54.596 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:17:06.536 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.6,"last_seen":"2023-11-23T20:17:06.511Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:17:06.561 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:17:11.959 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:17:16.146 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:17:16.214 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:17:16.234 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:17:26.604 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.6,"last_seen":"2023-11-23T20:17:26.594Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:17:26.618 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:17:27.079 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:17:31.314 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:17:54.251 FBDECT FBDECT_HKV_301_WZ batteryPercent: 90
2023-11-23 21:17:54.269 FBDECT FBDECT_HKV_301_SZ batteryPercent: 90
2023-11-23 21:17:54.286 FBDECT FBDECT_Taster_440 batteryPercent: 100
2023-11-23 21:17:55.002 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:18:00.821 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:18:14.224 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:18:16.840 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.5,"last_seen":"2023-11-23T20:18:16.816Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:18:16.867 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:18:20.431 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:18:35.479 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:18:35.778 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:18:46.950 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.8,"last_seen":"2023-11-23T20:18:46.922Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:18:46.975 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:18:56.559 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:18:56.989 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.6,"last_seen":"2023-11-23T20:18:56.963Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:18:57.021 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:18:57.253 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:19:02.279 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:19:02.879 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:19:35.891 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:19:43.209 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:19:47.191 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.7,"last_seen":"2023-11-23T20:19:47.163Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:19:47.209 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:20:02.696 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:20:10.885 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:20:17.301 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.5,"last_seen":"2023-11-23T20:20:17.287Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:20:17.321 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:20:32.976 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:20:48.742 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:20:48.760 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:21:07.512 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.7,"last_seen":"2023-11-23T20:21:07.491Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:21:07.533 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:21:09.758 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:21:11.180 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:21:14.360 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:21:27.599 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.5,"last_seen":"2023-11-23T20:21:27.583Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:21:27.622 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:21:30.075 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:21:35.132 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:21:38.624 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:22:07.772 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.7,"last_seen":"2023-11-23T20:22:07.749Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:22:07.800 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:22:13.442 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:22:17.680 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:22:23.295 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:22:35.503 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:22:36.554 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:22:44.205 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:22:44.256 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:22:47.965 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.6,"last_seen":"2023-11-23T20:22:47.908Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:22:47.984 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:22:52.497 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:22:53.840 FBDECT FBDECT_HKV_301_WZ batteryPercent: 90
2023-11-23 21:22:53.857 FBDECT FBDECT_HKV_301_SZ batteryPercent: 90
2023-11-23 21:22:53.873 FBDECT FBDECT_Taster_440 batteryPercent: 100
2023-11-23 21:22:55.980 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:22:57.978 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.6,"last_seen":"2023-11-23T20:22:57.960Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:22:58.003 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:23:08.025 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.4,"last_seen":"2023-11-23T20:23:08.000Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:23:08.051 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:23:25.785 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:23:28.842 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:23:42.203 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:23:42.774 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:23:48.720 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:23:58.145 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:23:58.215 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.6,"last_seen":"2023-11-23T20:23:58.201Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:23:58.236 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:23:59.733 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:24:28.341 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.6,"last_seen":"2023-11-23T20:24:28.318Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:24:28.366 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:24:48.776 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:24:52.826 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:24:55.170 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:25:05.715 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:25:06.013 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:25:08.506 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.7,"last_seen":"2023-11-23T20:25:08.480Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:25:08.528 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:25:11.195 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:25:28.583 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.6,"last_seen":"2023-11-23T20:25:28.566Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:25:28.605 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:25:40.025 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:25:52.858 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:25:54.396 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:26:12.077 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:26:18.779 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.6,"last_seen":"2023-11-23T20:26:18.754Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:26:18.807 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:26:36.034 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:26:38.851 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.5,"last_seen":"2023-11-23T20:26:38.829Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:26:38.868 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:26:58.932 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:27:06.563 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:27:19.040 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.6,"last_seen":"2023-11-23T20:27:19.010Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:27:19.067 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:27:19.971 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:27:29.069 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.6,"last_seen":"2023-11-23T20:27:29.045Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:27:29.094 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:27:39.124 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.7,"last_seen":"2023-11-23T20:27:39.091Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:27:39.151 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:27:41.950 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:27:49.146 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.6,"last_seen":"2023-11-23T20:27:49.125Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:27:49.169 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:27:49.848 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:27:53.810 FBDECT FBDECT_HKV_301_WZ batteryPercent: 90
2023-11-23 21:27:53.830 FBDECT FBDECT_HKV_301_SZ batteryPercent: 90
2023-11-23 21:27:53.849 FBDECT FBDECT_Taster_440 batteryPercent: 100
2023-11-23 21:28:10.255 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:28:10.675 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:28:12.222 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:28:24.088 MQTT2_DEVICE OMG_A4C138201D33 batteryPercent: 50
2023-11-23 21:28:25.711 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59
2023-11-23 21:28:27.963 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:28:29.307 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.7,"last_seen":"2023-11-23T20:28:29.283Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:28:29.334 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:28:49.374 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":65.6,"last_seen":"2023-11-23T20:28:49.358Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:28:49.390 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:28:51.793 MQTT2_DEVICE OMG_A4C138239A92 batteryPercent: 58
2023-11-23 21:28:59.404 MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/SONOFF_TH01_Medikamente', payload '{"battery":79,"humidity":66.6,"last_seen":"2023-11-23T20:28:59.393Z","linkquality":255,"temperature":18.6,"voltage":2900}'
2023-11-23 21:28:59.417 MQTT2_DEVICE MQTT2_zigbee_SONOFF_TH01_Medikamente batteryPercent: 79
2023-11-23 21:29:09.949 MQTT2_DEVICE OMG_A4C1381A61FB batteryPercent: 59
2023-11-23 21:29:10.975 MQTT2_DEVICE OMG_A4C1388CA934 batteryPercent: 59

Die Screenshots sind immer noch aktuell, Mal sehen, ob sich bis morgen was ändert.

Viele Grüße, Lutz
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 23 November 2023, 22:17:39
Hi Lutz,

ganz schön viele Infos :)
Muss ich mal in Ruhe durchgehen...

Bzgl. Klammer hast du (nat.) Recht, ist korrigiert.

Zitat von: LutzG am 23 November 2023, 21:55:11Die Screenshots sind immer noch aktuell, Mal sehen, ob sich bis morgen was ändert.
Evtl. noch welche von den geposteten Code-Varianten (also meinen elsif) du aktuell verwendest.

Mit "Risiko" kann man auch nur abfragen:

elsif($BatteryType[0] eq "batteryPercent")

Also ohne zusätzliche "Typprüfung".
Weil mit der "Typprüfung" auf MQTT2_DEVICE nat. die FBDECT usw. "rausfallen"...

Mit obigen elsif dürfte nun alles kommen, was batteryPercent hat.
Wichtig (darum auch "Typprüfung"), dass Devices nicht doppelt ausgewertet werden.
(wobei: wenn schon mal wo ein elsif getroffen hat, dann ist ja "fertig" denke ich. Kann dann aber sein, dass z.B. ein Device das battery [ok/nok] und batteryPercet hat dann [auch] nur bei battery mit groben Werten [voll/leer] auftaucht aber nicht mehr mit der tatsächlichen Prozenzahl, obwohl es auch batteryPercent hat)

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 23 November 2023, 22:24:07
Zitat von: LutzG am 23 November 2023, 21:51:16"batteryPercent" habe ich dem Thread keine Lösung gefunden. Der Code ist von dir:
Zitateine Version hängt an
https://forum.fhem.de/index.php?topic=82637.msg1245462#msg1245462
Ich habe nachgesehen, der Einbau der FBDECT in dem verlinkten Beitrag ist fehlerhaft, eieiei...
Aber es hat sich seither niemand "beschwert" ;)

Vielleicht finde ich (über Weihnachten) Zeit das (und andere Sachen)  mal glatt zu ziehen...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: LutzG am 23 November 2023, 22:54:19
Hallo Joachim,

Zitat von: MadMax-FHEM am 23 November 2023, 22:17:39Wichtig (darum auch "Typprüfung"), dass Devices nicht doppelt ausgewertet werden.
die meisten Device haben jetzt: "battery" und "batteryPercent", weswegen ich angefangen habe überall "batteryPercent" (eindeutig) einzubauen, wo nicht vorhanden. Mit "battery" habe ich immer doppelte Einträge gehabt.

Zitat von: MadMax-FHEM am 23 November 2023, 22:17:39(wobei: wenn schon mal wo ein elsif getroffen hat, dann ist ja "fertig" denke ich.
Da verstehe ich leider den Code nicht. Ich habe nicht gefunden, dass die doppelten Readings / Device gefiltert werden. Ich glaube, wenn von einem Device "battery" und "batteryPercent" gefeuert wird, werden beide Readings ausgewertet (doppelt für ein Device)?

Ich glaube, es müsste erst der Standard behandelt werden und dann die "Spezial-Fälle":
Wenn Standard -> Device erledigt -> sonst gucken, nächstes Device. Aber wie ich es verstanden geht es nach Reading nicht nach Device!? Da verstehe ich den Code zu wenig.  :(

Auch habe ich nicht ganz verstanden, das @Amenophis86 den "Standard" nicht einbaut, da er Mal einen Thread angeschubst hatte, wegen "Standard"-Readings. https://forum.fhem.de/index.php?topic=87575.0

Viele Grüße, Lutz
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 23 November 2023, 23:23:32
Ja battery und batteryPercent (wenn beides vorhanden), dann kommt es doppelt.

Mein Denkfehler: sind ja 2 Events ;)

Drum muss entweder bei battery oder batteryPercent eine Typabfrage (oder bei beiden).

Warum nicht eingebaut, hmmm...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: LutzG am 24 November 2023, 01:21:20
Mein jetziger Stand:
  #############################################
  # MQTT2_DEVICE Devices that have batteryPercent Reading
  #############################################
 elsif($BatteryType[0] eq "batteryPercent")
# elsif($BatteryType[0] eq "batteryPercent" && InternalVal($Device, "TYPE", "undef") eq "MQTT2_DEVICE")
 {
   $ActBatLevel = ReadingsNum($Device, "batteryPercent", "0");

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        fhem("setreading $BatteryChanged $Device $text_changed");
      }

      # set the battery value to 75% - 100%
      fhem("setreading $BatteryStatus $Device 100");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 50)
    {
      # between 50% and 75%
      fhem("setreading $BatteryStatus $Device 75");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 25)
    {
      # between 25% and 50%
      fhem("setreading $BatteryStatus $Device 50");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
    elsif($ActBatLevel > 5)
    {
      # between 5% and 25%
      fhem("setreading $BatteryStatus $Device 25");

      # maybe already send a message! Easy possible with new signal states
    }
    else
    {
      # totally empty (below 5%)
      fhem("setreading $BatteryStatus $Device 5");  # <-- bei ...$Device 0" keine Funktion?

      # check if message was already sent
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "low") ne "low")
      {
        # set signal state to low
        fhem("setreading $BatteryStatusBot $SignalDevice low");
        #send message via TelegramBot
        fhem($msg." ".$text_soon);
      }
    }
  }

Ich verstehe noch nicht den Sinn, warum die Werte nur 0, 25, 50, oder 100 sein dürfen. In der "sub SetBatterieIcon($$)" wird doch noch Mal verglichen, da könnten doch die wahren Werte in "BatterieStatus" geschrieben werden? Mit:
fhem("setreading $BatteryStatus $Device $ActBatLevel");funktioniert es, aber ich bekomme lauter Meldungen.  ???
2023.11.24 00:51:48.229 1: my_StoreBatteryStatus      Device: MQTT2_zigbee_SONOFF_TH01_Medikamente       Event: batteryPercent: 79.5      Model: zigbee2mqtt_TempHumSensor
2023.11.24 00:51:48.537 1: my_StoreBatteryStatus      Device: OMG_A4C1381A61FB       Event: batteryPercent: 59      Model: OpenMQTTGateway_BT_temp_hum_sensor
2023.11.24 00:51:48.637 1: my_StoreBatteryStatus      Device: OMG_A4C1388CA934       Event: batteryPercent: 59      Model: OpenMQTTGateway_BT_temp_hum_sensor
2023.11.24 00:51:58.252 1: my_StoreBatteryStatus      Device: MQTT2_zigbee_SONOFF_TH01_Medikamente       Event: batteryPercent: 79.5      Model: zigbee2mqtt_TempHumSensor
2023.11.24 00:52:08.286 1: my_StoreBatteryStatus      Device: MQTT2_zigbee_SONOFF_TH01_Medikamente       Event: batteryPercent: 79.5      Model: zigbee2mqtt_TempHumSensor
2023.11.24 00:52:28.366 1: my_StoreBatteryStatus      Device: MQTT2_zigbee_SONOFF_TH01_Medikamente       Event: batteryPercent: 79.5      Model: zigbee2mqtt_TempHumSensor
2023.11.24 00:52:39.899 1: my_StoreBatteryStatus      Device: OMG_A4C138201D33       Event: batteryPercent: 50      Model: OpenMQTTGateway_BT_temp_hum_sensor
2023.11.24 00:52:40.550 1: my_StoreBatteryStatus      Device: OMG_A4C1388CA934       Event: batteryPercent: 58      Model: OpenMQTTGateway_BT_temp_hum_sensor

Viele Grüße, Lutz
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 24 November 2023, 08:48:43
Hi Lutz,

prinzipiell spricht nichts dagegen auch die tatsächlichen Werte in den dummy zu schreiben, weil, da hast du recht, es wird in der RG beim setzen des Icons "geprüft".

Macht aber optisch keinen Unterschied ;)
Und: der Code ist schwer "gewachsen"... 8)

Die Meldungen: da muss (nur bei dir?) ein Aufruf einer Log-Funktion drin sein. Sieht man in deinem "Schnipsel" nicht. Wenn du die gesamte Funktion postest, kann ich dir bestimmt sagen, wie das wegzukriegen ist :)

Falls nun zu viele Devices erfasst werden (oder welche doppelt) und du nur MQTT2_DEVICE und FBDECT Devices zusätzlich willst, kannst du auch das probieren:

elsif($BatteryType[0] eq "batteryPercent" && (InternalVal($Device, "TYPE", "undef") eq "MQTT2_DEVICE" || InternalVal($Device, "TYPE", "undef") eq "FBDECT"))

Das war bei der Erweiterung bzgl. FBDECT falsch, da die ja kein batteryLevel haben ich aber (dummerweise/warum auch immer) dort die FBDECT Devices mit eingefügt hatte...

Wie gesagt, wenn (Weihnachten) mal Zeit ist, vielleicht schaffe ich eine "saubere" (und evtl. auch einfachere) Variante...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 24 November 2023, 10:37:20
Zitat von: LutzG am 24 November 2023, 01:21:20funktioniert es, aber ich bekomme lauter Meldungen. 
Du hast
1. (verm.) den Log-Aufruf gleich zu beginn wieder "einkommentiert"
2. durch das event-on-update-reading battery... kommen jetzt eben vermehrt Events mit Batterie (mache ich so, muss aber nicht / weiß nicht mehr genau warum ich das so habe aber verm. läuft oder lief eine [andere] Automatisierung damit und brauchte die Events?)

Um die Meldung ganz wegzukriegen (war/ist nur zu "Debugzwecken"), musst du nur die Logausgabe (wie in meinem geposteten Beispiel und auch dem git-Code) wieder auskommentieren ;)

Weil ansonsten habe ich mal geschaut ist nur eine Logausgabe aktiv und zwar, wenn ein Device "ignoriert" wird. Bei mir (und auch hier?) sind das v.a. Homematic CUL_HM Devices. Das habe ich (für mich ;) ) eingebaut, damit ich beim Anlegen von neuen Homematic Devices keine "Leichen" im dummy (und damit in der RG) habe...
Wie (mehrfach) geschrieben: schwer gewachsen das ganze (auch bei mir) mit vielen (unnötigen?) "Schnörkeln"...
(aber darum ja: Code-Schnipsel und kein Modul 8)  )

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: LutzG am 27 November 2023, 02:52:42
Hallo Joachim, @All,

heut Mal munter genug zum spielen.  ;D

Zitat von: LutzG am 24 November 2023, 01:21:20Mein jetziger Stand:
... funktioniert nicht korrekt, obwohl ich keine Batterie gewechselt habe, hatte ich im Dummy: Batteriewechsel 4 Einträge. Ich logge jetzt Mal ein paar Tage batteryPercent.

Zitat von: MadMax-FHEM am 24 November 2023, 08:48:43tatsächlichen Werte in den dummy zu schreiben [...]
Macht aber optisch keinen Unterschied ;)
Und: der Code ist schwer "gewachsen"... 8)
Das "schwere Wachstum" habe ich gelesen (mangels Hardware aber nicht nachvollziene können). Optisch macht das keinen Unterschied? ??? Ich habe alle (korrekten) Werte "gesammelt"! 8) Ich träume ja immer noch von einem Device, wo alle Batterie-Infos zusammen sind (%, ob bald ausfällt, gewechselt, Zustand melden, ...). Nebenbei, mit:
fhem("setreading $BatteryStatus $Device $ActBatLevel");funktioniert es doch nicht so richtig. Im Dummy: BatterieStatus werden zwar die Zahlen-Werte eingetragen, in der ReadingsDroup: rgBatteryStatus werden aber statt Icons Text angezeigt. ???

Zitat von: MadMax-FHEM am 24 November 2023, 10:37:20Du hast
1. (verm.) den Log-Aufruf gleich zu beginn wieder "einkommentiert"
Deine Glaskugel ist top!  :o  Wieder auskommentiert und die Meldungen sind weg.  ::)

Zitat von: MadMax-FHEM am 24 November 2023, 08:48:43Falls nun zu viele Devices erfasst werden [...] kannst du auch das probieren:
Ich habe das Notify geändert (nur Device mit "batteryPercent" will ich auswerten - damit eindeutig):
defmod NO.BatterieNotify notify .*:batteryPercent.* {BatteryStatusFunction($NAME, $EVENT)}
Zitat von: MadMax-FHEM am 24 November 2023, 08:48:43wenn (Weihnachten) mal Zeit ist, vielleicht schaffe ich eine "saubere" (und evtl. auch einfachere) Variante...
Weihnachten? Ich finde, da ist deine Familie wichtiger! Nicht deine Zeit wegen mir versauen! Seit 2021 hätte ich gern so eine Anzeige, da kommt es auf ein paar Monate nicht an! :)

Viele Grüße, Lutz
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 06 Januar 2024, 14:50:08
Hallihallo ;)

Hatte dann doch noch etwas Zeit nicht nur zu überlegen wie und so, sondern auch noch was zu tun :)

Ausgehend von dieser (meiner letzten?!) Version: https://forum.fhem.de/index.php?topic=82637.msg1245462#msg1245462

Habe ich mal versucht die weiteren Dinge im Threadverlauf einzubauen...
...jetzt aktuelle Version (meiner angepassten Variante!) hängt hier an.

Eingebaut:

FBDECT <- korrigiert. Hat kein batteryLevel, sondern "nur" batteryPercent (warum das so lange keiner gemerkt hat ;)  ).
list hier: https://forum.fhem.de/index.php/topic,82637.msg1240399.html#msg1240399
und hier: https://forum.fhem.de/index.php?topic=82637.375
zeigen das ja (hatte ich mich wohl "damals" verkuckt 8) )


Ebenso das Senden "vereinfacht", siehe: https://forum.fhem.de/index.php?topic=82637.msg1284063#msg1284063
Dank an minierm!



Dann habe ich mir erlaubt das hier "schärfer" zu fassen (hoffentlich passt das ;) ).
Da immer mehr Typen dazukommen, wird so verhindert, dass Devices "reinfallen", die ein Attribut model haben und batteryLevel aber GANZ ANDERS behandelt werden müssen.

Die Anfangs-Idee (weil ich das so habe ;)  ) war eben bei den CUL_HM Homematic Devices die "dummen" mit nur "ok/low" und die mit Spannungswerten (aber zusätzlich "ok/low") zu "trennen"...
#  elsif($BatteryType
  elsif($BatteryType

Wenn es stört, einfach die obere Zeile ein- und die untere dafür auskommentieren...


Ich habe das hier und folgende noch mal angeschaut: https://forum.fhem.de/index.php?topic=82637.msg1294235#msg1294235
batteryVoltage:batterymV.* {ReadingsNum($name,'batterymV',0)/1000}, batteryPercent:battery.* {ReadingsNum($name,'battery',0)}, batteryState {if (ReadingsNum($name, "battery", 0) > 25) {return "ok"} else {return "low"}}

Ich habe es mal eingebaut, dass es auch ohne das userReadings gehen müsste:

##############################################
# MQTT2_DEVICE that have battery Reading showing percentage!
##############################################


Dann habe ich mir die letzten Posts von LutzG (https://forum.fhem.de/index.php?action=profile;u=49095) noch mal durchgelesen und mit meinem bei mir laufenden Code verglichen und auch Devices die ich habe...
Daher habe ich nun ZWave und HUEDevices "umgebaut" -> battery auf batteryPercent (haben beides).
Da habe ich dann auch die FBDECT mitaufgenommen (siehe Eintrag weiter oben).


Damit sollte das hier passen?
https://forum.fhem.de/index.php?topic=82637.msg1294235#msg1294235



Es wird nun auf folgende Readings geprüft:
battery -> ok/low für CUL_HM (außer HM-TC-IT-WM-W-EU und HM-CC-RT-DN), MAX!, HMCCU und LaCrosse
batteryLevel -> voltage für HM-TC-IT-WM-W-EU und HM-CC-RT-DN (CUL_HM)
batteryPercent -> percentage für ZWave, HUEDevice, FBDECT und MQTT2_DEVICE <- das darf aber dann KEIN Reading battery haben! (sonst taucht es doppelt auf)
battery -> percentage für MQTT2_DEVICE ("früher" auch ZWave und HUEDevice) <- das darf aber dann KEIN Reading batteryPercent haben! (sonst taucht es doppelt auf)
batteryLevel -> percentage für XiaomiFlowerSens


Damit sollten nun die TRADFRI (batteryPercent und MQTT2_DEVICE) ebenfalls tun (ohne userreadings).
U.U. kann man da auch weiter unterscheiden, muss ich mir mal anschauen...
...aber erst mal abwarten, ob das nicht schon so läuft 8)

Beim Erstellen der Tabelle (gut hatte ich schon vorher bermutet ;)  ) ist mir aufgefallen, dass man da noch einiges zusammenfassen kann/könnte...
...mal sehen.


Ich habe bei einigen Devices mit Prozentangebe eingebaut, dass bei unter 25% eine "soon-Message" verschickt wird und bei unter 5% eine "now-Message"...
...wenn das stört, baue ich es wieder um. 8)


Wenn es nicht (mehr) tut, dann melden und ich schaue was ich tun kann...

Ich habe auch mal einen "Version-Header" eingebaut, damit zumindest ich etwas Überblick behalte ;)
#########################################################################
# Version/History
# actual version: 20240106_01
#########################################################################


-----------------------------------------------------------------------------------------------------
@LutzG:
-----------------------------------------------------------------------------------------------------

Zitat von: LutzG am 27 November 2023, 02:52:42funktioniert es doch nicht so richtig. Im Dummy: BatterieStatus werden zwar die Zahlen-Werte eingetragen, in der ReadingsDroup: rgBatteryStatus werden aber statt Icons Text angezeigt.
Nutzt du bei der readingsGroup auch die Sub "my_SetBatteryIcon" zum Setzen der Icons? ;)
Wohl nicht ;)
Zitatattr rg_BatterieLevel valueIcon {'batteryPercent.0' => 'measure_battery_0@red','batteryPercent.25' => 'measure_battery_25@red','batteryPercent.50' => 'measure_battery_50@orange','batteryPercent.75' => 'measure_battery_75@green','batteryPercent.100' => 'measure_battery_100@green'}

So in der Art attr readingsGroupName valueIcon {my_SetBatteryIcon($READING, $VALUE)}

-----------------------------------------------------------------------------------------------------

Dann ist mir aufgefallen, dass du bei einigen geposteten userReadigs KEINEN Trigger angegeben hast, evtl. noch mal anschauen und einen vergeben ;)

-----------------------------------------------------------------------------------------------------
End @LutzG
-----------------------------------------------------------------------------------------------------


Ich hoffe, ich habe durch den größeren Umbau nichts durcheinander gebracht!
Evtl. kann es sein, dass ein restart von fhem notwendig ist, statt "nur" reload -> Änderung des Sendens...

Ich hatte auch überlegt evtl. die Grenzwerte nicht wie jetzt fix für alle Devices (zumindest Device-Typen) zu haben, sondern z.B. als Attribut bei den Devices selbst.
Evtl. sogar mit verschiedenen "Warn-Leveln" -> msg.soon / msg.now


Aber da ich (immer noch) eine ganz andere (halt sehr für mich persönlich angepasste) Version verwende und ich nicht weiß wie das Interesse "hier" ist, scheue ich den Aufwand :-\
Auch, weil ich eben wenig wirklich testen kann, weil dazu, dass ich eine ganz eigene Version nutze habe ich ja auch nicht alle Geräte (logisch ;)  )...



Neue bzw. korrigierte Version hier: https://forum.fhem.de/index.php?topic=82637.msg1303697#msg1303697



Gruß, Joachim

Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Funsailor am 15 Februar 2024, 17:38:33
Hi,
ich habe das Modul vom 20240106_01 heruntergeladen und wie auf Seite 1 beschrieben initialisiert.
An den Werten habe ich nichts geändert, lediglich den TelegrammBot habe ich angepasst.

Wenn ich nun mit Batteriewechsel mit meinem HM-TC-IT-WM-W-EU (OG_BueroThermostat) Batterieausfall simuliere, bekomme ich im rgBatteryStatus die Änderungen angezeigt.
Allerdings ist die Message leer... steht nix im Text aus der Übergabe drin.

Im Logfile steht:

Zitatset MyFhemTelegram message @@Michael  : TelegramBot_Set: Command message, no msg content specified

Ich habe mir mal den Text in der Routine "sub Battery_Send_Alarm($$$)" augeben lassen, da steht nix drin
  { Log 1, "Version 1" }
  { Log 1, $Text }
  { Log 1, "Version 2" }
  { Log 1, $SignalDevice }

bringt folgende Ausgabe im Log

2024.02.15 17:25:34.949 1: Version 1
2024.02.15 17:25:34.950 1:
2024.02.15 17:25:34.950 1: Version 2
2024.02.15 17:25:34.950 1: OG_BueroThermostat_BatState

Eigentlich sollte da doch text_now bzw. text_soon stehen, oder ?


Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 15 Februar 2024, 17:46:22
Wie hast du den Telegram Bot angepasst?
Kannst du deine Anpassung posten?

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Funsailor am 15 Februar 2024, 17:49:56
Hi Joachim,
das geht ja schnell:

So:

Zitatmy $msg = "set MyFhemTelegram message \@\@Michael ";

Und mit der Eingabe in der Commandozeile :
 
Zitatset MyFhemTelegram message @Michael TEST 

empfange ich die Nachricht "TEST" !
LG
Michael
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 15 Februar 2024, 19:49:54
Ich hab was gefunden, mal sehen 8)

Und weil ich dabei war auch gleich noch was gefunden (fand ich schon gleich komisch aber hatte ich ja nur übernommen [ohne Test :-\ ]):
    my $msg = "set TelegramBot message \@\@User ";
muss eigentlich nur 1x escaped werden, zumindest hat es so bei einem Schnelltest geklappt:
    my $msg = "set TelegramBot message \@User ";

Neue Version als Anhang...
Neue und nochmals korrigierte Version (20240215_02) angehangen, siehe Folgeantworten...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Funsailor am 15 Februar 2024, 22:14:10
Hallo Joachim,
danke für die schnelle Hilfe, aber im Eifer des Gefechtes hast du die "Text_soon" Meldungen vergessen.
Nachdem ich dort die zweiten escape Zeichen entfernt habe bekome ich die Meldung

ZitatDie Batterien von OG_BueroThermostat sollten bald gewechselt werden!

Aufs Handy!!  :D
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 15 Februar 2024, 22:22:28
Ja, da hast du natürlich Recht!

Hab's geändert und oben neu angehangen...

Danke, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Funsailor am 15 Februar 2024, 22:53:24
Hi Joachim,
der Batteriewechsel wurde leider nicht festgehalten.
Ich habe die Batterien entfernt und den Level gesetzt
setreading OG_BueroThermostat batteryLevel 1.3
In der Anzeige rgBatteryStatus warein leeres rotes Kästchen zu sehen...
Nachdem ich neue Batterien eingelegt habe, wird das voll Symbol angezeigt, der Batteriewechsel wird aber nicht festgehalten.....
Irgendwo habe ich dazu mal etwas gelsen, finde es aber nicht mehr.
Hast du einen Tipp?
Danke
Michael


Upps,
hatte bei den vorherigen Wechsel "angeknabberte" Batterien verwendet, die haben nur 2,6V gebracht und da wurde der Batteriewchsel scheinbar nicht erkannt...
Mit richtig vollen Batterien hat es funktioniert!
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 16 Februar 2024, 08:01:22
Ja, die Batteriewechselerkennung funktioniert nur von leer (1x) nok oder unter 25% (glaube ich) auf voll...

Ansonsten wäre es ja kein Wechsel wg. leerer Batterien... ;)

Meine Freundin tendiert auch dazu zu wechseln, wenn auch nur Rot angezeigt wird, das ist oft auch zu früh für die Erkennung...

Bei Prozentangaben bzw. Spannungswerten könnte man einbauen, dass man sich den alten Wert merkt und wenn es dann deutlich mehr ist, auch von einem Wechsel ausgeht...

Bei nok/ok bleibt nichts anderes...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Funsailor am 18 Februar 2024, 22:43:49
Hallo Joachim,
ich denke so wie es reagiert ist es OK.... Das ist bei mir beim Testen aufgetreten, normalerweise werden "volle" Batterien eingesetzt 😉
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: weini am 19 März 2024, 19:34:51
Hallo zusammen!

Ich habe BatteryCheckUtils jetzt seit ein paar Wochen im Einsatz und muss sagen, dass sie echt Vorteile ggü. meiner alten DOIF Logik hat.
Was ich aber vermisse, ist eine "Grace Period", wenn der Status auf "low" geht. Ich nutze Außentemperaturfühler von Pearl (NC-7159), dich ich als CUL_TCM97001 mit model=NC_WS in FHEM einbinde.
Im Perl-Code have ich Zeile 295 so angepasst
  elsif(($BatteryType[0] eq "battery")  && ($TYPE eq "MAX" || $TYPE eq "CUL_TCM97001")),
dass neben den Max Devices auch diese Temperaturfühler verarbeitet werden.

Nun senden die aber die ersten Battery=low Warnungen schon, wenn die Batterie noch recht gut ist. Der Status springt nach ein paar Sekunden oder Minuten wieder auf "ok" zurück. Trotzdem löst natürlich die Alarmierung aus. In meiner alten DOIF Lösung hatte ich mir da mit einem simplen "wait" geholfen, so dass der Alarm erst ausgelöst wurde, wenn der Status für mindestens 5 Minuten auf "low" geblieben ist.

Wäre es möglich, etwas vergleichares in BatteryCheckUtils zu integrieren?
Alternativ würde ich ggf. den Status mit einem DOIF & wait selbst für die Alarmierung überwachen. Gehe ich damit besser auf das "BatterieStatus" oder auf das "BatterieStatusBot" Device los?

VG,
weini
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 20 März 2024, 07:55:04
Zitat von: weini am 19 März 2024, 19:34:51Ich nutze Außentemperaturfühler von Pearl (NC-7159), dich ich als CUL_TCM97001 mit model=NC_WS in FHEM einbinde.
Im Perl-Code have ich Zeile 295 so angepasst
Code Auswählen Erweitern
  elsif(($BatteryType[0] eq "battery")  && ($TYPE eq "MAX" || $TYPE eq "CUL_TCM97001")),
dass neben den Max Devices auch diese Temperaturfühler verarbeitet werden.
Danke, nehme ich bei Gelegenheit mit auf...

Zitat von: weini am 19 März 2024, 19:34:51Nun senden die aber die ersten Battery=low Warnungen schon, wenn die Batterie noch recht gut ist. Der Status springt nach ein paar Sekunden oder Minuten wieder auf "ok" zurück. Trotzdem löst natürlich die Alarmierung aus. In meiner alten DOIF Lösung hatte ich mir da mit einem simplen "wait" geholfen, so dass der Alarm erst ausgelöst wurde, wenn der Status für mindestens 5 Minuten auf "low" geblieben ist.

Wäre es möglich, etwas vergleichares in BatteryCheckUtils zu integrieren?
Muss ich mir ansehen.


Zitat von: weini am 19 März 2024, 19:34:51Alternativ würde ich ggf. den Status mit einem DOIF & wait selbst für die Alarmierung überwachen. Gehe ich damit besser auf das "BatterieStatus" oder auf das "BatterieStatusBot" Device los?
Wenn dann verm. BatterieStatus, dort stehen ja die aktuellen Batteriestände der "gematchten" Devices "in Kopie" drin.

In BatterieStatusBot wird sich ja bereits gemerkt, ob es eine Nachricht gab...

Soweit ich das jetzt auswendig im Kopf habe...


Frage: lieber schon mal eine Nachricht beim ersten "low" und dann keine erneute Nachricht (für eine bestimmte Zeit) oder erst eine Nachricht, wenn eine bestimmte Zeit "stabil" low war/ist?

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: weini am 20 März 2024, 16:22:23
Zitat von: MadMax-FHEM am 20 März 2024, 07:55:04Frage: lieber schon mal eine Nachricht beim ersten "low" und dann keine erneute Nachricht (für eine bestimmte Zeit) oder erst eine Nachricht, wenn eine bestimmte Zeit "stabil" low war/ist?
Aus meiner Sicht klar die zweite Variante. Der Außenfühler geht z. B. auch gerne mal kältebedingt auf "low", läuft dann aber noch Monate lang.
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 20 März 2024, 16:46:10
Zitat von: weini am 20 März 2024, 16:22:23Aus meiner Sicht klar die zweite Variante. Der Außenfühler geht z. B. auch gerne mal kältebedingt auf "low", läuft dann aber noch Monate lang.
Ja, dachte ich mir ;)

Ich schau mal...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Prof. Dr. Peter Henning am 20 März 2024, 16:49:48
Könnt Ihr bitte mal schreiben, wo der genannte Code auf diesen X Seiten steckt? Oder das mal zusammengefasst hier posten?

LG

pah
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: TomLee am 20 März 2024, 17:31:28
Hallo,

les nur mit einem halb geschlossenen Auge mit, nur acht Beiträge vorher steht schon der Hinweis das die letzte Änderung oben_angehangen_wurde, oben ist dann auch gleich 2 Beiträge davor.

Thomas
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 20 März 2024, 17:36:13
Zitat von: Prof. Dr. Peter Henning am 20 März 2024, 16:49:48Könnt Ihr bitte mal schreiben, wo der genannte Code auf diesen X Seiten steckt? Oder das mal zusammengefasst hier posten?

LG

pah

Problem: ich habe mal irgendwo meinen Code gepostet oder erläutert wie ich das mache...

Wurde vom TE übernommen und liegt unverändert (soweit ich das gesehen habe) auf git...

Allerdings kamen dann Erweiterungen und Anpassungen (auch von mir) und damit ist es schwer (für mich) im ersten Post zu editieren usw.

Was also am besten tun?

EDIT: werde zunächst mal die Erweiterung des neuen Typs einpflegen und evtl. auch bzgl. den "Wackelsensoren" schauen und dann hier (ganz unten) posten...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 20 März 2024, 21:40:07
So, ich hab hier mal eine neue Version angehangen mit dem neuen Geräte-Typ und der grace period...

Oben in der Datei kann (wie die anderen Einstellungen auch) die grace period angegeben werden:

  my $GracePeriod = 0; # seconds that a low status has to be notified until it is taken granted

Ablauf:

1. mal überhaupt -> status wird gemerkt

danach:

bei ok -> passiert nichts (außer dass ok gemerkt wird)

bei low -> low wird gemerkt bzw. geprüft, ob bereits GracePeriod abgelaufen


Wichtig: es müssen immer wieder ok/low Events kommen sonst kommt die Meldung nie (klar ;) ), wenn GracePeriod > 0. D.h. mit event-on-change-reading aufpassen...

Die Batterieanzeige low und Nachricht kommen frühestens beim nächsten "low Event" der NACH GracePeriod Sekunden kommt. Also nicht genau nach GracePeriod Sekunden.
Ich hoffe es funktioniert und ist ok so...

Ist/bleibt GracePeriod auf 0, so sollte das Verhalten wie vorher sein...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: weini am 20 März 2024, 22:07:28
Wow, das war schnell!
Ich teste und gebe Feedback.

VG,
weini
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 21 März 2024, 09:17:05
Hallo,

gibt es jetzt zwei verschiedene Module für die Batterieprüfung?

Im ersten Posting ist 99_BatteryCheckUtils.pm und 2 Posts oberhalb 99_Battercheck.pm.

Eingerichtet werden beide gleich wie im ersten Post beschrieben oder gibt es Unterschiede?

Kann man noch zusätzlich den BatterieTyp mit übermitteln?

Ich habe bei allen Geräten eine Userattr BatteryTyp angelgt in dem der Batterietyp zB 2 x AA eingefügt ist.


Gruß
_fhemuser_
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Prof. Dr. Peter Henning am 21 März 2024, 09:45:52
Ich denke, eine Klarstellung ist nötig.

99_BatteryCheck.pm ist kein FHEM-Modul, sondern eine sehr nützliche Sammlung von Hilfsfunktionen, die verschiedene FHEM-Devices miteinander verknüpfen**.

Der Dateiname beginnt mit 99, das bedeutet, dass diese Sammlung beim Start von FHEM automatisch mit eingelesen wird.

Diese Hilfsfunktionen kann man auch in anderem Kontext verwenden, beispielsweise überwache ich meinen Batteriezoo seit etlichen Jahren mit readingsGroup (so, wie das hier auch gedacht ist) und monitoring (das sind beides FHEM-Module).

LG

pah


**:Das ist, die Nebenbemerkung sei mir nach zwei Büchern über das Thema erlaubt, der eigentliche Vorteil von FHEM gegenüber vielen anderen Systemen, die modernere Programmiersprachen verwenden.
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 21 März 2024, 10:05:24
Zitat von: _fhemuser_ am 21 März 2024, 09:17:05Hallo,

gibt es jetzt zwei verschiedene Module für die Batterieprüfung?

Im ersten Posting ist 99_BatteryCheckUtils.pm und 2 Posts oberhalb 99_Battercheck.pm.

Eingerichtet werden beide gleich wie im ersten Post beschrieben oder gibt es Unterschiede?

Kann man noch zusätzlich den BatterieTyp mit übermitteln?

Ich habe bei allen Geräten eine Userattr BatteryTyp angelgt in dem der Batterietyp zB 2 x AA eingefügt ist.


Gruß
_fhemuser_

Wie pah ausgeführt hat: wir befinden uns in Code-Schnipsel ;)

Da ich hier nur versuche "Fehler" zu beheben bzw. neue Device-Typen versuche einzupflegen und auch andere Erweiterungswünsche versuche einzubauen...
...habe ich halt einzwas aus git genommen und mich daran weiterversucht ;)  8)

Ob es Unterschiede gibt und wenn welche: keine Ahnung, müsste man den TE fragen...

Ja, ich habe bei mir auch so ein Attribut für den Batterie-Typ :)
Ist aber alles sehr speziell und ich mache darüber auch eine autom. "Entnahme" aus meinem Batterie-Vorrat aber dabei muss eben alles zusammenpassen...

Ich kann das mit der Übermittlung mal versuchen einzubauen.
Wenn es kein userattr beim Device gibt, dann wird (wie jetzt auch) nix übermittelt, steht was drin, nehme ich genau den "Text" der da drin steht und packe ihn mit in die Nachricht, sollte machbar sein...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 21 März 2024, 12:11:06
Entschulldigung, dass ich die Bezeichung für Codeschnipsel, Hilfsfunktionen und Module nicht korrekt dargestellt habe.

Ich habe die Hilfsfunktionen 99_BatteryCheckUtils.pm mal entfernt sowie alle dadurch angelegten Dummys und das Notify.

Dann die 99_Batterycheck.pm kopiert, 1-2 Änderungen am TelegramBot durchgeführt, damit es zu meinem System passt. Die 99_Batterycheck.pm geladen und mit {BatteryStart()} die Dummys und Notify neu angelegt.

Soweit passt alles. Alle Batterien sind voll und es gab noch keine Meldungen.

In jedem batteriebetriebenen Gerät steht unter UserReadings ', BatteryTyp {"CR2032"}', sowie evtl andere Berechnungen. zB erzeuge ich zusätzlich ein BatteryPer das die Prozentzahl enthält abhängig vom Gerätetyp. Mir gefiel das Durcheinander nicht, dass teilweise Prozente, teilweise OK, teilweise Spannungen, voll oder OK angezeigt werden. Dadurch konnte ich mit ReadingGroups und DOIF eine einfache Übersicht und Alarmierung erhalten.

Gruß
_fhemuser_
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 21 März 2024, 13:20:05
Zitat von: _fhemuser_ am 21 März 2024, 12:11:06In jedem batteriebetriebenen Gerät steht unter UserReadings ', BatteryTyp {"CR2032"}', sowie evtl andere Berechnungen. zB erzeuge ich zusätzlich ein BatteryPer das die Prozentzahl enthält abhängig vom Gerätetyp. Mir gefiel das Durcheinander nicht, dass teilweise Prozente, teilweise OK, teilweise Spannungen, voll oder OK angezeigt werden. Dadurch konnte ich mit ReadingGroups und DOIF eine einfache Übersicht und Alarmierung erhalten.

In dem angelegten dummy stehen dann auch pro Device die Prozente :)
(zumindest so der Plan ;)  )
Allerdings bei low/ok Devices halt nur 0%/100% 8)

Daraus "bedient" sich dann die readingsGroup...


userReadings BatteryTyp ODER userattr BatteryTyp?

Ich habe dafür (weil es ja eine Konfiguration ist, die man 1x pro Device macht) ein userattr, Beispiel:

Devicename userattr my_batteryType
Devicename my_batteryType 2xAA

Das mit userattr würde ich evtl. ins Modul einbauen.
Das userattr muss dann entweder global oder pro Device wo es gebraucht wird ergänzt werden (selbst!) und den Wert nat. auch selbst füllen...

Das dann in den Meldungstext einbauen kann ich ja dann machen: wenn es das Attribut gibt (Name wird zu Beginn der Datei festgelegt, wie andere Dinge auch), dann wird der Inhalt dazugebastelt, wenn nicht, dann nicht ;)

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 21 März 2024, 13:44:53
Zitat von: MadMax-FHEM am 21 März 2024, 13:20:05
Zitat von: _fhemuser_ am 21 März 2024, 12:11:06In jedem batteriebetriebenen Gerät steht unter UserReadings ', BatteryTyp {"CR2032"}', sowie evtl andere Berechnungen. zB erzeuge ich zusätzlich ein BatteryPer das die Prozentzahl enthält abhängig vom Gerätetyp. Mir gefiel das Durcheinander nicht, dass teilweise Prozente, teilweise OK, teilweise Spannungen, voll oder OK angezeigt werden. Dadurch konnte ich mit ReadingGroups und DOIF eine einfache Übersicht und Alarmierung erhalten.

In dem angelegten dummy stehen dann auch pro Device die Prozente :)
(zumindest so der Plan ;)  )
Allerdings bei low/ok Devices halt nur 0%/100% 8)
Ähnlich habe ich das mit den userReadings bei den MAX Thermostaten gelöst:
batteryPer {if
(ReadingsVal($NAME,"batteryState","") eq "ok") {return 100} elsif
(ReadingsVal($NAME,"batteryState","") eq "low") {return 1} else
{return -1}}, BatteryTyp {"2 x AA"}

Daraus "bedient" sich dann die readingsGroup...

ZitatuserReadings BatteryTyp ODER userattr BatteryTyp?

Ich habe dafür (weil es ja eine Konfiguration ist, die man 1x pro Device macht) ein userattr, Beispiel:

Devicename userattr my_batteryType
Devicename my_batteryType 2xAA

Mir ist bislang der Unterschied zwischen userReadings und userattr gar nicht aufgefallen :(

ZitatDas mit userattr würde ich evtl. ins Modul einbauen.
Das userattr muss dann entweder global oder pro Device wo es gebraucht wird ergänzt werden (selbst!) und den Wert nat. auch selbst füllen...

Das dann in den Meldungstext einbauen kann ich ja dann machen: wenn es das Attribut gibt (Name wird zu Beginn der Datei festgelegt, wie andere Dinge auch), dann wird der Inhalt dazugebastelt, wenn nicht, dann nicht ;)

Gruß, Joachim

Ich kann natürlich von userReadings auf userattr umstellen. Das würde wahrscheinlcih FHEM auch beschleunigen da weniger gerechnet und geändert wird.

Vielen Dank für die Hilfen.

Gruß
_fhemuser_
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 21 März 2024, 14:48:00
Readings (auch userReadings-Readings) sind (wie du ja selbst angemerkt hast ;)  ) dynamische Werte...

Attribute (auch userattr-Attribute) sind eher statische Werte oder auch "Konfiguration" von Devices (so sehe ich das)...

Bei der Änderung von Attributen landen diese bei save in der cfg

Readings bei safe(statefile) im state-File

ZitatBatteryTyp {"2 x AA"}
Naja: es wird bei JEDEM Event des Devices getriggert (kein Trigger angegeben) und setzt jedesmal das Reading auf einen gleichbleibende Zeichenkette ;)
Ist verm. nicht der Performance-Killer aber notwendig auch nicht 8)

Bei Gelegenheit baue ich das mit dem Attribut und Batterie-Typ mal ein...
EDIT: muss ja keiner nutzen ;)

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: enno am 21 März 2024, 14:58:29
Moin Joachim,

ZitatBei Gelegenheit baue ich das mit dem Attribut und Batterie-Typ mal ein...
EDIT: muss ja keiner nutzen ;)

Finde ich eine gute Idee, ich habe diese Informationen zur Zeit noch in den Readings, aber in userattr-Attribute ist ja schnell geändert.

Gruss
  Enno
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 21 März 2024, 15:12:34
Ich habe alle Einträge unter userReadings geändert, die Readings gelöscht und als userattr angelegt  :)

Dabei ist mir aufgefallen, dass etliche Geräte noch fehlen. Sie werden wahrscheinlich erfasst, sobald Daten gesendet werden.

Einige Geräte sind "doppelt" vorhanden. ZB die HUE Bewegungssensoren werden als 3 Geräte eingerichtet um die Helligkeit, Bewegung und Temperatur zu übertragen. Wie kann man solche Einträge verhindern?

Dann habe ich noch einige Funkschalter die nur selten benutzt werden und bei denen die Batterie entfernt ist. Wie können diese ausgeschlossen werden? Eine Blacklst oder Whitelist gibt es ja bei den Dummy und Notify nicht.

Gruß
_fhemuser_
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 21 März 2024, 15:24:19
Zitat von: _fhemuser_ am 21 März 2024, 15:12:34Einige Geräte sind "doppelt" vorhanden. ZB die HUE Bewegungssensoren werden als 3 Geräte eingerichtet um die Helligkeit, Bewegung und Temperatur zu übertragen. Wie kann man solche Einträge verhindern?

Dann habe ich noch einige Funkschalter die nur selten benutzt werden und bei denen die Batterie entfernt ist. Wie können diese ausgeschlossen werden? Eine Blacklst oder Whitelist gibt es ja bei den Dummy und Notify nicht.


Naja um möglichst andere Anwender nicht zu "stören" (also Verhalten möglichst lassen wie es ist für alle aktuellen Nutzer), wäre mein Vorschlag ebenfalls ein weiteres userattr zu spendieren?
Sowas wie: doNotAccount (oder so) / wobei: Namen kann jeder selber wählen und dann entsprechend oben in die Datei eintragen

Wenn das Attribut existiert bzw. besser wenn es gesetzt ist: 1 dann wird das Device nicht beachtet...

Eine Whitelist/Blacklist ginge auch: oben in der Datei ein Array mit den Devicenamen (die beachtet werden sollen: whitelist / oder eben nicht beachtet werden sollen: blacklist)

Was wäre besser?
EDIT: Attribut ist einfacher 8)

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 21 März 2024, 15:41:19
Zitat von: MadMax-FHEM am 21 März 2024, 15:24:19Naja um möglichst andere Anwender nicht zu "stören" (also Verhalten möglichst lassen wie es ist für alle aktuellen Nutzer), wäre mein Vorschlag ebenfalls ein weiteres userattr zu spendieren?
Sowas wie: doNotAccount (oder so) / wobei: Namen kann jeder selber wählen und dann entsprechend oben in die Datei eintragen

Wenn das Attribut existiert bzw. besser wenn es gesetzt ist: 1 dann wird das Device nicht beachtet...

Eine Whitelist/Blacklist ginge auch: oben in der Datei ein Array mit den Devicenamen (die beachtet werden sollen: whitelist / oder eben nicht beachtet werden sollen: blacklist)

Was wäre besser?

Gruß, Joachim

Ich finde eine Lösung ohne an der 99_Batterycheck.pm Änderungen im Betrieb duchzuführen besser. Wenn es ein Dateiupdate gibt, müssten alle manuellen Änderungen wieder durchgeführt werden. Dabei fällt bestimmt einiges heraus.

Also eine automatische Erkennung wie es das Notify macht wäre optimal. Dh ich favorisiere die Lösung mit den userattr. Da das Attribut neu gesetzt werden muss, kann man den Namen nehmen den du in die Datei schreibst.

Ich durchblicke die ganze Funktion im Hintergrund noch nicht. Es scheint dass über das Notify, das auf .*:battery.* horcht, die Routine(sub) {BatteryStatusFunction($NAME, $EVENT)} aufgerufen wird. Diese befindet sich in der 99_Batterycheck.pm.
Die Rückgabewerte werden in den Dummys abgelegt und falls erforderlich auch über Telegram eine Nachricht versendet.

[edit]
Kann vielleicht in FHEM eine Konfiguration hinterlegt werden bei denen Änderunge zb für die gracetime eingetragen werden. Damit müsste die Datei bei einem Update nicht geändert werden.
[/edit]

Gruß
_fhemuser_
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 21 März 2024, 15:53:12
Zitat von: _fhemuser_ am 21 März 2024, 15:41:19Kann vielleicht in FHEM eine Konfiguration hinterlegt werden bei denen Änderunge zb für die gracetime eingetragen werden. Damit müsste die Datei bei einem Update nicht geändert werden.

Naja, man könnte einen "Config-dummy" anlegen und dort alle Angaben hinterlegen...

Jetzt schaue ich erst mal bzgl. der beiden Attribute: batteryType und doNotAccount 8)

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: TK67 am 21 März 2024, 16:44:04
Hallo,
habe da noch eine Ergänzung für die sub BatteryStart()
Dient zur Vorbelegung von Geräten mit "batteryPercent" beim ersten Start.
Habe den Block nach dem Block #Set Readings for device with reading batteryLevel eingefügt:

#Set Readings for device with reading batteryPercent
 my @bat_p = devspec2array("batteryPercent=.*");
 for(my $x=0;$x<@bat_p;$x++)
 {
my $stat_p = ReadingsVal($bat_p[$x],"batteryPercent","undef");
if($stat_p ne "undef")
{
BatteryStatusFunction($bat_p[$x],"batteryPercent: $stat_p");
}
 }
 

Gruß TK67
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 21 März 2024, 17:54:32
Zitat von: TK67 am 21 März 2024, 16:44:04Hallo,
habe da noch eine Ergänzung für die sub BatteryStart()
Dient zur Vorbelegung von Geräten mit "batteryPercent" beim ersten Start.
Habe den Block nach dem Block #Set Readings for device with reading batteryLevel eingefügt:

#Set Readings for device with reading batteryPercent
 my @bat_p = devspec2array("batteryPercent=.*");
 for(my $x=0;$x<@bat_p;$x++)
 {
my $stat_p = ReadingsVal($bat_p[$x],"batteryPercent","undef");
if($stat_p ne "undef")
{
BatteryStatusFunction($bat_p[$x],"batteryPercent: $stat_p");
}
 }
 

Gruß TK67

Hab ich eingebaut 8)

Ebenso die beiden userattr :)

Folgendes muss bei jedem Device (wo benötigt/gewünscht) getan werden (oder 1x in global erweitert werden):

attr Device userattr batteryType doNotAccount
Beide userattr oder nur eins davon...

Danach können die Attribute dann beim Device gesetzt werden, z.B.:
attr Device doNotAccount 1
attr Device batteryType 2xAA

Die Namen der Attribute können geändert werden, dazu dann entsprechend in der Datei oben anpassen.
Bei doNotAccount ist egal was gesetzt wird, sobald es "da" ist, wird das Device "ignoriert" (oder sollte ich 1 und 0 nehmen?)

Wird das Attribut batteryType gesetzt, wird was immer dort drin steht zusätzlich ausgegeben...

Beispiel:
ZitatDie Batterien vom Typ 2xAA von Device sollten bald gewechselt werden!

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: TK67 am 21 März 2024, 18:58:42
Danke Joachim, das ging ja richtig fix  :)

Habe noch ein paar kleine Ergänzungen:
Meine Hue Bewegungsmelder und der Hue Dimmschalter haben jeweils battery und batteryPercent als Readings, dies führte teilweise zu unplausiblen Zuständen.
Habe deshalb die Zeile im Block HM Devices with battery
if($BatteryType[0] eq "battery"  && $Model ne "HM-TC-IT-WM-W-EU" && $Model ne "HM-CC-RT-DN" && $Model ne "undef")ergänzt
if($BatteryType[0] eq "battery"  && $Model ne "HM-TC-IT-WM-W-EU" && $Model ne "HM-CC-RT-DN" && $Model ne "undef" && $TYPE ne "HUEDevice")

Damit auch meine Withings Geräte eingebunden werden im Block ZWave and HUEDevice Devices and FBDECT ergänzt:
elsif($BatteryType[0] eq "batteryPercent"  && ($TYPE eq "ZWave" || $TYPE eq "HUEDevice" || $TYPE eq "FBDECT" || $TYPE eq "MQTT2_DEVICE"))
mit
elsif($BatteryType[0] eq "batteryPercent"  && ($TYPE eq "ZWave" || $TYPE eq "HUEDevice" || $TYPE eq "FBDECT" || $TYPE eq "MQTT2_DEVICE" || $TYPE eq "withings"))

Wäre nett wenn du das auch noch anhängen kannst.


Gruß TK67
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Prof. Dr. Peter Henning am 22 März 2024, 04:26:30
Es ist in jedem Fall für die innere Logik von FHEM besser, mit userattr als mit userReadings zu arbeiten - der Typ einer Batterie ist eben kein Messwert des Gerätes.

Zweitens  ein Tipp: Gerade Wandthermostate sitzen oft entweder neben oder in einer 230V-Wandanschlussdose. Die kann man problemlos mit einem 3,3 V-Einbaunetzteil versorgen. Daraus folgt schon mal, dass das gesamte System nicht viel Sinn macht ohne ein Attribut zum ignorieren.

Drittens sollte man die Terminologie im Auge behalten. Ein Attributname "doNotAccount" ist so generisch, dass er sich auf jede Art der Liste beziehen könnte, das sollte man auf jeden Fall vermeiden. Auch beim Sortieren in längeren Attributlisten wäre es besser, wenn man das Attribut "batteryChk" oder so ähnlich nennt. Das mache ich bei mir seit Jahren so, hat sich gut bewährt. Außerdem kann man den Attributwert auch etwas aufpolstern. Beispiel: Der Attributwert kann aus einer "|"-getrennten Liste bestehen, sagen wir

<readingname>|<readingtype>

battery|simple       kann beispielsweise bedeuten, dass das Reading für den Batteriezustand "battery" heißt und nur "ok" oder "low" sein kann.

batteryLevel|ignore  kann beispielsweise bedeuten, dass das Reading den "batteryLevel" heißt, aber bei der Prüfung ignoriert wird.

Entsprechend kann man das auch mit dem Batterietyp machen, z.B. als

<batteryType>|<batteryChange>

Geräte, bei denen das Datum des letzten Wechsels nicht bekannt ist, haben dann eben nur Attributwerte wie z.B. "2AA". Und selbstverständlich könnte man auch erreichen, dass bei einem Wechsel des Messwertes von "low" auf "ok" das Datum automatisch an diesen Attributwert angehängt wird.

Viertens, auch das zur Terminologie: Ein Readingsname "batteryPercent" ist semantisch unsinnig, weil er die Einheit (eben dimensionslose Prozent) in den Namen mit aufnimmt. Das ist ungefähr so doof, als ob man den Messwert der Netzspannung als "Netzvolt" bezeichnet. Wenn man das schon selbst auswählt, sollte man das korrekter benennen, z.B. batteryLevel. Es ist schon ärgerlich genug, dass in vielen FHEM-Devices wie Dimmern und Rollladenaktoren einfach "pct" als Reading auftaucht, das ist aber immerhin weitgehend einheitlich geregelt.

LG

pah

Und noch eine Bitte an alle Neulinge: Nicht immer den bequemen "Zitieren"-Button verwenden. Das müllt den gesamten Thread zu. Der Button "Antworten" ist OBEN.
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 März 2024, 07:49:41
Zitat von: TK67 am 21 März 2024, 18:58:42Wäre nett wenn du das auch noch anhängen kannst.
Ich habe hier kein "Monopol" auf den Code ;)

Es darf jeder gerne mitarbeiten :)

Ist ja Code-Schnipsel und kein Modul mit Maintainer...

Aber falls du nicht willst (warum auch immer), kann ich die überschaubaren Änderungen auch einbauen... 8)

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: weini am 22 März 2024, 07:53:27
Die Grace Period scheint gut zu funktionieren. Ich hatte die Situation jetzt wieder und die Alarmierung wurde wie gewünscht unterdrückt.
Nochmals vielen Dank!
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Prof. Dr. Peter Henning am 22 März 2024, 08:09:38
Zitatelsif($BatteryType[0] eq "batteryPercent"  && ($TYPE eq "ZWave" || $TYPE eq "HUEDevice" || $TYPE eq "FBDECT" || $TYPE eq "MQTT2_DEVICE" || $TYPE eq "withings"))
Sorry wenn ich das so deutlich sage: Aber das ist primitiver Spaghetti-Code, den nach kurzer Zeit niemand mehr warten kann. Außerdem führt er zu vielen unnötigen Tests.

Stattdessen sollte es einen zentralen Hash geben, in dem die Gegebenheiten für bestimmte TYPEs abgelegt sind, und natürlich Ausnahmen für konkrete Modelle.

LG

pah
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 März 2024, 08:17:47
Zitat von: Prof. Dr. Peter Henning am 22 März 2024, 04:26:30Es ist in jedem Fall für die innere Logik von FHEM besser, mit userattr als mit userReadings zu arbeiten - der Typ einer Batterie ist eben kein Messwert des Gerätes.
Ja, sehe ich auch so.
Drum ja auch Attribut :)

Zitat von: Prof. Dr. Peter Henning am 22 März 2024, 04:26:30Zweitens  ein Tipp: Gerade Wandthermostate sitzen oft entweder neben oder in einer 230V-Wandanschlussdose. Die kann man problemlos mit einem 3,3 V-Einbaunetzteil versorgen. Daraus folgt schon mal, dass das gesamte System nicht viel Sinn macht ohne ein Attribut zum ignorieren.
Ja und andere Geräte/Gründe...

Zitat von: Prof. Dr. Peter Henning am 22 März 2024, 04:26:30Drittens sollte man die Terminologie im Auge behalten. Ein Attributname "doNotAccount" ist so generisch, dass er sich auf jede Art der Liste beziehen könnte, das sollte man auf jeden Fall vermeiden. Auch beim Sortieren in längeren Attributlisten wäre es besser, wenn man das Attribut "batteryChk" oder so ähnlich nennt. Das mache ich bei mir seit Jahren so, hat sich gut bewährt. Außerdem kann man den Attributwert auch etwas aufpolstern. Beispiel: Der Attributwert kann aus einer "|"-getrennten Liste bestehen, sagen wir

<readingname>|<readingtype>

battery|simple      kann beispielsweise bedeuten, dass das Reading für den Batteriezustand "battery" heißt und nur "ok" oder "low" sein kann.

batteryLevel|ignore  kann beispielsweise bedeuten, dass das Reading den "batteryLevel" heißt, aber bei der Prüfung ignoriert wird.

Entsprechend kann man das auch mit dem Batterietyp machen, z.B. als

<batteryType>|<batteryChange>

Geräte, bei denen das Datum des letzten Wechsels nicht bekannt ist, haben dann eben nur Attributwerte wie z.B. "2AA". Und selbstverständlich könnte man auch erreichen, dass bei einem Wechsel des Messwertes von "low" auf "ok" das Datum automatisch an diesen Attributwert angehängt wird.

Den Namen des Attributes kann man ja zu Beginn der Datei selbst festlegen...

Mag sein, dass der von mir gewählte nicht "gut" war aber ich hatte grad keine andere Idee 8)

Ja, klar kann man in einem Attribut auch Listen hinterlegen (gibt ja viele Beispiele: setList, webCmd usw. mit Komma getrennt, mit Leerzeichen getrennt usw.) und auch viel mehr in nur 1 Attribut packen (mache ich für mich an manchen Stellen auch so).

Allerdings würde ich hier den Wechsel auch eher in ein Reading packen denn ein Attribut.
Ist aber Geschmackssache...

Aber: es ist ein Code-Schnipsel (gut inzwischen ein etwas größerer und wachsender ;)  )...

Und auch hier: gerne anpacken ;)


Zitat von: Prof. Dr. Peter Henning am 22 März 2024, 04:26:30Viertens, auch das zur Terminologie: Ein Readingsname "batteryPercent" ist semantisch unsinnig, weil er die Einheit (eben dimensionslose Prozent) in den Namen mit aufnimmt. Das ist ungefähr so doof, als ob man den Messwert der Netzspannung als "Netzvolt" bezeichnet. Wenn man das schon selbst auswählt, sollte man das korrekter benennen, z.B. batteryLevel. Es ist schon ärgerlich genug, dass in vielen FHEM-Devices wie Dimmern und Rollladenaktoren einfach "pct" als Reading auftaucht, das ist aber immerhin weitgehend einheitlich geregelt.
An den Reading-Namen (bzgl. Battrie-Stand) den die Devices (vom jedeiligen Modul) bekommen (haben) kann ich nix ändern.

Wenn die schon gut und v.a. einheitlich wären, dann bräuchte es diesen Code-Schnipsel nicht 8)

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 März 2024, 08:19:04
Zitat von: Prof. Dr. Peter Henning am 22 März 2024, 08:09:38Sorry wenn ich das so deutlich sage: Aber das ist primitiver Spaghetti-Code, den nach kurzer Zeit niemand mehr warten kann. Außerdem führt er zu vielen unnötigen Tests.

Stattdessen sollte es einen zentralen Hash geben, in dem die Gegebenheiten für bestimmte TYPEs abgelegt sind, und natürlich Ausnahmen für konkrete Modelle.
Kein Monopol auf Code und Code-Schnipsel ;)

EDIT: und ja, habe auch gemerkt, dass man einiges vereinfachen und zusammenfassen kann aber ich habe dafür keine Zeit (und da ich eh bei mir anderen Code nutze auch keine rechte Lust) und testen ist ohne den Zoo zu haben nicht möglich und dann bei komplett umgebauten Code zu supporten kann ich auch nicht leisten, drum isses wie's ist ;)

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 März 2024, 08:46:05
Zitat von: _fhemuser_ am 21 März 2024, 15:41:19Kann vielleicht in FHEM eine Konfiguration hinterlegt werden bei denen Änderunge zb für die gracetime eingetragen werden. Damit müsste die Datei bei einem Update nicht geändert werden.

Zitat von: weini am 22 März 2024, 07:53:27Die Grace Period scheint gut zu funktionieren. Ich hatte die Situation jetzt wieder und die Alarmierung wurde wie gewünscht unterdrückt.
Nochmals vielen Dank!

Schön, dass es geklappt hat! :)

Ja, hatte auch überlegt das per Attribut zu lösen (ja dann evtl. wirklich ein Attribut mit einer Liste von Einstellungen), also auch gracePeriod pro Device.
Ist das Attribut bzw. der Eintrag vorhanden, dann wird NUR FÜR DIESES Device genau die ANGEGEBENE gracePeriod genommen.
Dann müsste der Anwender halt pro Device Attribute setzen.
Bislang hat der Code-Schnipsel ja "einfach so" funktioniert 8)

EDIT: ja damit würde auch der unten genannte Fall wegfallen. Also ähnlich dem ActionDetector bei Homematic. Betrachtet werden nur (Homematic / CUL_HM) Devices, die das entsprechende Attribut haben...

Und halt: Zeit das zu machen... :-\

Zitat von: TK67 am 21 März 2024, 18:58:42Meine Hue Bewegungsmelder und der Hue Dimmschalter haben jeweils battery und batteryPercent als Readings, dies führte teilweise zu unplausiblen Zuständen.

Ja ;)
Steht hier (denke ich):

https://forum.fhem.de/index.php?topic=82637.msg1299124#msg1299124

Zitat von: MadMax-FHEM am 06 Januar 2024, 14:50:08Es wird nun auf folgende Readings geprüft:
battery -> ok/low für CUL_HM (außer HM-TC-IT-WM-W-EU und HM-CC-RT-DN), MAX!, HMCCU und LaCrosse
batteryLevel -> voltage für HM-TC-IT-WM-W-EU und HM-CC-RT-DN (CUL_HM)
batteryPercent -> percentage für ZWave, HUEDevice, FBDECT und MQTT2_DEVICE <- das darf aber dann KEIN Reading battery haben! (sonst taucht es doppelt auf)
battery -> percentage für MQTT2_DEVICE ("früher" auch ZWave und HUEDevice) <- das darf aber dann KEIN Reading batteryPercent haben! (sonst taucht es doppelt auf)
batteryLevel -> percentage für XiaomiFlowerSens

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 22 März 2024, 08:47:32
Vielen Dank für die schnelle Umsetzung mit den Attributen,

Bei mir fehlen noch ganz viele Sensoren und Geräte in der Readingsgroup und bei einigen steht nur 0.

Alle fehlerhaften und fehlenden sind Zigbee Geräte die über zigbee2mqtt Daten übertragen.

In den Devicereadings ist battery mit 100 (%) enthalten und bei einigen battery_low false (low).

Dieser Sensor wird mit 0 in der Readingsgroup angezeigt:define Fenster_Ess MQTT2_DEVICE zigbee_Sensor_Fenster_Licht
attr Fenster_Ess BatteryTyp CR2032
attr Fenster_Ess DbLogExclude .*
attr Fenster_Ess DbLogInclude tamper.*|state.*|battery.*
attr Fenster_Ess devStateIcon open:fts_window_1w_open@red closed:fts_window_1w@green\
.*false:rc_BLANK \
.*true:message_service@red\
Batt.*100:measure_battery_100@green \
Batt.*9[0-9].*:measure_battery_100@green \
Batt.*8[0-9].*:measure_battery_75@green \
Batt.*7[0-9].*:measure_battery_75@green \
Batt.*6[0-9].*:measure_battery_50@green \
Batt.*5[0-9].*:measure_battery_50@green \
Batt.*4[0-9].*:measure_battery_50@green \
Batt.*3[0-9].*:measure_battery_25@orange \
Batt.*2[0-9].*:measure_battery_25@orange \
Batt.*1[0-9].*:measure_battery_25@red \
Batt.*[0][0-9].*:measure_battery_0@red
attr Fenster_Ess devicetopic zigbee2mqtt/Sensor_Fenster_Licht
attr Fenster_Ess fp_Grundriss 206,847,1,Fenster_Ess
attr Fenster_Ess genericDeviceType ContactSensor
attr Fenster_Ess group Door-Window
attr Fenster_Ess homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED
attr Fenster_Ess icon tuer_fenster_kontakt
attr Fenster_Ess jsonMap contact:state
attr Fenster_Ess model zigbee2mqtt_ContactSensor
attr Fenster_Ess readingList $DEVICETOPIC:.* { my $ret=json2nameValue($EVENT,'',$JSONMAP);; $ret->{state}=$ret->{state} eq 'true' ? 'closed' : 'open';; return $ret }
attr Fenster_Ess room Heizkoerper->-Heizkoerper,MQTT2_DEVICE,Zigbee
attr Fenster_Ess stateFormat state\
Batt: battery\
Hell: illuminance
attr Fenster_Ess userReadings batteryPer {ReadingsVal($NAME,'battery',0) }
#   CID        zigbee_Sensor_Fenster_Licht
#   DEF        zigbee_Sensor_Fenster_Licht
#   FUUID      6593dfde-f33f-d33d-4e3d-3167c848f406e555
#   IODev      MQTT2_FHEM_Server
#   LASTInputDev MQTT2_FHEM_Server
#   MQTT2_FHEM_Server_CONN MQTT2_FHEM_Server_192.168.0.103_53406
#   MQTT2_FHEM_Server_MSGCNT 48
#   MQTT2_FHEM_Server_TIME 2024-03-22 08:04:43
#   MSGCNT     48
#   NAME       Fenster_Ess
#   NR         858
#   STATE      closed
#Batt: 100
#Hell: 447
#   TYPE       MQTT2_DEVICE
#   eventCount 54
#   Helper:
#     DBLOG:
#       battery:
#         logdb:
#           TIME       1711091083.43459
#           VALUE      100
#       batteryPer:
#         logdb:
#           TIME       1711091083.43459
#           VALUE      100
#       state:
#         logdb:
#           TIME       1711091083.43459
#           VALUE      closed
#   JSONMAP:
#     contact    state
#   OLDREADINGS:
#   READINGS:
#     2024-03-21 09:24:16   IODev           MQTT2_FHEM_Server
#     2024-03-22 08:04:43   battery         100
#     2024-03-22 08:04:43   batteryPer      100
#     2024-03-22 08:04:43   device_applicationVersion 131
#     2024-03-22 08:04:43   device_friendlyName Sensor_Fenster_Licht
#     2024-03-22 08:04:43   device_hardwareVersion 1
#     2024-03-22 08:04:43   device_ieeeAddr 0xa4c138b67155d016
#     2024-03-22 08:04:43   device_manufacturerID 4098
#     2024-03-22 08:04:43   device_manufacturerName _TZE200_pay2byax
#     2024-03-22 08:04:43   device_model    ZG-102ZL
#     2024-03-22 08:04:43   device_networkAddress 63979
#     2024-03-22 08:04:43   device_powerSource Battery
#     2024-03-22 08:04:43   device_softwareBuildID 0122052017
#     2024-03-22 08:04:43   device_stackVersion 2
#     2024-03-22 08:04:43   device_type     EndDevice
#     2024-03-22 08:04:43   device_zclVersion 3
#     2024-03-22 08:04:43   illuminance     447
#     2024-03-22 08:04:43   illuminance_interval 60
#     2024-03-22 08:04:43   last_seen       2024-03-22T08:04:43+01:00
#     2024-03-22 08:04:43   linkquality     255
#     2024-03-22 08:04:43   state           closed
#     2024-01-04 07:17:08   tamper          false
#
setstate Fenster_Ess closed\
Batt: 100\
Hell: 447
setstate Fenster_Ess 2024-03-21 09:24:16 IODev MQTT2_FHEM_Server
setstate Fenster_Ess 2024-03-22 08:04:43 battery 100
setstate Fenster_Ess 2024-03-22 08:04:43 batteryPer 100
setstate Fenster_Ess 2024-03-22 08:04:43 device_applicationVersion 131
setstate Fenster_Ess 2024-03-22 08:04:43 device_friendlyName Sensor_Fenster_Licht
setstate Fenster_Ess 2024-03-22 08:04:43 device_hardwareVersion 1
setstate Fenster_Ess 2024-03-22 08:04:43 device_ieeeAddr 0xa4c138b67155d016
setstate Fenster_Ess 2024-03-22 08:04:43 device_manufacturerID 4098
setstate Fenster_Ess 2024-03-22 08:04:43 device_manufacturerName _TZE200_pay2byax
setstate Fenster_Ess 2024-03-22 08:04:43 device_model ZG-102ZL
setstate Fenster_Ess 2024-03-22 08:04:43 device_networkAddress 63979
setstate Fenster_Ess 2024-03-22 08:04:43 device_powerSource Battery
setstate Fenster_Ess 2024-03-22 08:04:43 device_softwareBuildID 0122052017
setstate Fenster_Ess 2024-03-22 08:04:43 device_stackVersion 2
setstate Fenster_Ess 2024-03-22 08:04:43 device_type EndDevice
setstate Fenster_Ess 2024-03-22 08:04:43 device_zclVersion 3
setstate Fenster_Ess 2024-03-22 08:04:43 illuminance 447
setstate Fenster_Ess 2024-03-22 08:04:43 illuminance_interval 60
setstate Fenster_Ess 2024-03-22 08:04:43 last_seen 2024-03-22T08:04:43+01:00
setstate Fenster_Ess 2024-03-22 08:04:43 linkquality 255
setstate Fenster_Ess 2024-03-22 08:04:43 state closed
setstate Fenster_Ess 2024-01-04 07:17:08 tamper false
Dieser Thermostat gar nicht.define MQTT2_zigbee_Heiz_Ess MQTT2_DEVICE zigbee_Heiz_Ess
attr MQTT2_zigbee_Heiz_Ess userattr AlleHeizungen AlleHeizungen_map MQTTHeizungen MQTTHeizungen_map structexclude weekprofile
attr MQTT2_zigbee_Heiz_Ess BatteryTyp 2 x AA
attr MQTT2_zigbee_Heiz_Ess DbLogInclude desired-temp temperature mode\
desiredTemperature
attr MQTT2_zigbee_Heiz_Ess alias Ess
attr MQTT2_zigbee_Heiz_Ess devStateIcon .*UNLOCK:secur_open@green:btnLock+LOCK\
.*LOCK:secur_locked@yellow:btnLock+UNLOCK \
\
.*Battery.*ok:measure_battery_100@green \
\
Frost.*ON:frost@lime:frost_protection+OFF\
Frost.*OFF:frost@grey:frost_protection+ON\
\
Fenster.*OFF:fts_window_1w@green:open_window+ON\
Fenster.*ON:fts_window_1w_open@red:open_window+OFF\
\
.*Aus.*ON:sani_heating@red:heating_stop+OFF # Thermostat abgeschaltet im Sommer  Strom sparen\
.*Aus.*OFF:sani_heating@green:heating_stop+ON+preset+auto # Thermostat abgeschaltet im Sommer  Strom sparen\
\
.*auto:sani_heating_automatic@lightgray:preset+manual \
.*manual:sani_heating_manual@black:preset+auto\
\
BT.*[0-9][0-9][1-9]*:sani_heating_boost@red\
BT.*[1-9]:sani_heating_boost@orange\
BT.*0:sani_heating_boost@grey:boost_time+300\
\
.*temporary:sani_heating_timer@red\
.*holiday:sani_heating_calendar@blue:preset+auto
attr MQTT2_zigbee_Heiz_Ess devicetopic zigbee2mqtt/Heiz_Ess
attr MQTT2_zigbee_Heiz_Ess fp_Grundriss 333,1074,1,MQTT2_zigbee_Heiz_Ess,
attr MQTT2_zigbee_Heiz_Ess genericDeviceType thermostat
attr MQTT2_zigbee_Heiz_Ess icon temp_control
attr MQTT2_zigbee_Heiz_Ess jsonMap current_heating_setpoint:desiredTemperature local_temperature:temperature Battery:batteryPercent system_mode:mode battery:batteryPercent voltage:batterymV btnLock:child_lock
attr MQTT2_zigbee_Heiz_Ess model zigbee2mqtt_thermostat_with_weekrofile
attr MQTT2_zigbee_Heiz_Ess readingList $DEVICETOPIC:.* { my %h;; my $temp = $EVENT;; $temp =~ s/,?("(holidays|workdays)":.([^]]+))./$h{$2}=$3/ge;; $EVENT =~ s/,?("(holidays|workdays)":.([^]]+)).//g;; my $h2 = json2nameValue($EVENT,'',$JSONMAP);; %h = (%h,%$h2);; \%h }
attr MQTT2_zigbee_Heiz_Ess room Heizkoerper->-Heizkoerper,Heizkoerper->Ess,MQTT2_DEVICE
attr MQTT2_zigbee_Heiz_Ess setList desiredTemperature:slider,5.0,0.5,22.0,1 $DEVICETOPIC/set {"current_heating_setpoint": $EVTPART1 }\
btnLock:LOCK,UNLOCK $DEVICETOPIC/set {"child_lock": "$EVTPART1"}\
preset:auto,manual,holiday $DEVICETOPIC/set {"preset": "$EVTPART1"}\
mode:heat,auto,off $DEVICETOPIC/set {"system_mode": "$EVTPART1"}\
holidays $DEVICETOPIC/set/schedule { "holidays":[$EVTPART1] }\
open_window:OFF,ON $DEVICETOPIC/set {"open_window": "$EVTPART1"}\
workdays $DEVICETOPIC/set/schedule { "workdays":[$EVTPART1] }\
week:5+2,6+1,7 $DEVICETOPIC/set $EVTPART1\
weekprofile { FHEM::attrT_z2m_thermostat_Utils::z2t_send_weekprofile($NAME, $EVTPART1, $EVTPART2) }\
x_send_set_payload:textField { my $payload = $EVENT;;$payload =~ s/$EVTPART0 //;; qq($DEVICETOPIC/set $payload)}\
boost_time:select,20,60,120,180,240,300,450 $DEVICETOPIC/set {"boost_timeset_countdown": $EVTPART1}\
comfort_temperature:slider,5.0,0.5,30.0,1 $DEVICETOPIC/set {"comfort_temperature": $EVTPART1}\
frost_protection:OFF,ON $DEVICETOPIC/set {"frost_protection": "$EVTPART1"}\
heating_stop:OFF,ON $DEVICETOPIC/set {"heating_stop": "$EVTPART1"}\
holiday_temperature:slider,8.0,0.5,18.0,1 $DEVICETOPIC/set {"holiday_temperature": $EVTPART1 }\
open_window_temperature:slider,6.0,0.5,15.0,1 $DEVICETOPIC/set {"open_window_temperature": $EVTPART1 }\
local_temperature_calibration:slider,-5.0,0.1,5.0,1 $DEVICETOPIC/set {"local_temperature_calibration": $EVTPART1 }
attr MQTT2_zigbee_Heiz_Ess stateFormat Modus: preset\
Kinder: child_lock\
Frost: frost_protection\
Aus: heating_stop\
BT:boost_timeset_countdown\
<br>\
Fenster: open_window\
Battery: batteryState\
<br>\
Temp: temperature°C, \
Wunsch: desiredTemperature °C\
Dev: diffe °C
attr MQTT2_zigbee_Heiz_Ess userReadings batteryState:battery_low.* {ReadingsVal($name,'battery_low','false') eq 'false'?'ok':'low'}, \
batteryVoltage:batterymV.* {ReadingsNum($name,'batterymV',0)/1000}, \
diffe {sprintf("%.1f", ReadingsVal($name, "temperature", 0) - ReadingsVal($name, "desiredTemperature", 0))},\
batteryPer {if\
(ReadingsVal($NAME,"batteryState","") eq "ok") {return 100} elsif\
(ReadingsVal($NAME,"batteryState","") eq "low") {return 1} else \
{return -1}}
attr MQTT2_zigbee_Heiz_Ess webCmd temperature:desiredTemperature
attr MQTT2_zigbee_Heiz_Ess widgetOverride temperature:slider,5,0.1,25,1 desiredTemperature:select,6.0,8.0,10.0,13.0,14.0,16.0,17.5,19.0,20.0,21.5,30.0
#   CID        zigbee_Heiz_Ess
#   DEF        zigbee_Heiz_Ess
#   FUUID      653d1be3-f33f-d33d-abf5-9957dfd784cccbc3
#   IODev      MQTT2_FHEM_Server
#   LASTInputDev MQTT2_FHEM_Server
#   MQTT2_FHEM_Server_CONN MQTT2_FHEM_Server_192.168.0.103_53406
#   MQTT2_FHEM_Server_MSGCNT 335
#   MQTT2_FHEM_Server_TIME 2024-03-22 08:27:08
#   MSGCNT     335
#   NAME       MQTT2_zigbee_Heiz_Ess
#   NR         844
#   STATE      Modus: auto
#Kinder: UNLOCK
#Frost: OFF
#Aus: OFF
#BT:0
#<br>
#Fenster: OFF
#Battery: ok
#<br>
#Temp: 20.3°C,
#Wunsch: 20 °C
#Dev: 0.3 °C
#   TYPE       MQTT2_DEVICE
#   eventCount 395
#   Helper:
#     DBLOG:
#       BatteryTyp:
#         logdb:
#           TIME       1711025830.11604
#           VALUE      2 x AA
#       batteryPer:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      100
#       batteryState:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      ok
#       battery_low:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      false
#       boost_timeset_countdown:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      0
#       child_lock:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      UNLOCK
#       comfort_temperature:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      20
#       desiredTemperature:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      20
#       device_applicationVersion:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      69
#       device_dateCode:
#         logdb:
#           TIME       1711092428.41369
#           VALUE     
#       device_friendlyName:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      Heiz_Ess
#       device_hardwareVersion:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      1
#       device_ieeeAddr:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      0x0c4314fffe6a36b5
#       device_manufacturerID:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      4098
#       device_manufacturerName:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      _TZE200_mudxchsu
#       device_model:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      TV02-Zigbee
#       device_networkAddress:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      30240
#       device_powerSource:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      Battery
#       device_stackVersion:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      0
#       device_type:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      EndDevice
#       device_zclVersion:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      3
#       diffe:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      0.3
#       eco_temperature:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      16
#       error_status:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      0
#       frost_protection:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      OFF
#       heating_stop:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      OFF
#       holiday_start_stop:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      2024/05/01 02:00 _ESC_ 2024/10/15 01:00
#       holiday_temperature:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      13
#       last_seen:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      2024-03-22T08:27:08+01:00
#       linkquality:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      255
#       local_temperature_calibration:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      -1
#       mode:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      heat
#       online:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      ON
#       open_window:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      OFF
#       open_window_temperature:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      8
#       preset:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      auto
#       schedule_friday:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
#       schedule_monday:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
#       schedule_saturday:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
#       schedule_schedule:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
#       schedule_sunday:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
#       schedule_thursday:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
#       schedule_tuesday:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
#       schedule_wednesday:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
#       schedule_week_day:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      monday
#       state:
#         logdb:
#           TIME       1711091083.29753
#           VALUE      open_window
#       temperature:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      20.3
#       update_available:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      false
#       update_installed_version:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      69
#       update_latest_version:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      69
#       update_state:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      idle
#       working_day:
#         logdb:
#           TIME       1711092428.41369
#           VALUE      mon_sun
#   JSONMAP:
#     Battery    batteryPercent
#     battery    batteryPercent
#     btnLock    child_lock
#     current_heating_setpoint desiredTemperature
#     local_temperature temperature
#     system_mode mode
#     voltage    batterymV
#   OLDREADINGS:
#   READINGS:
#     2024-03-21 09:24:17   IODev           MQTT2_FHEM_Server
#     2024-03-22 08:27:08   batteryPer      100
#     2024-03-22 08:27:08   batteryState    ok
#     2024-03-22 08:27:08   battery_low     false
#     2024-03-22 08:27:08   boost_timeset_countdown 0
#     2024-03-22 08:27:08   child_lock      UNLOCK
#     2024-03-22 08:27:08   comfort_temperature 20
#     2024-03-22 08:27:08   desiredTemperature 20
#     2024-03-22 08:27:08   device_applicationVersion 69
#     2024-03-22 08:27:08   device_dateCode
#     2024-03-22 08:27:08   device_friendlyName Heiz_Ess
#     2024-03-22 08:27:08   device_hardwareVersion 1
#     2024-03-22 08:27:08   device_ieeeAddr 0x0c4314fffe6a36b5
#     2024-03-22 08:27:08   device_manufacturerID 4098
#     2024-03-22 08:27:08   device_manufacturerName _TZE200_mudxchsu
#     2024-03-22 08:27:08   device_model    TV02-Zigbee
#     2024-03-22 08:27:08   device_networkAddress 30240
#     2024-03-22 08:27:08   device_powerSource Battery
#     2024-03-22 08:27:08   device_stackVersion 0
#     2024-03-22 08:27:08   device_type     EndDevice
#     2024-03-22 08:27:08   device_zclVersion 3
#     2024-03-22 08:27:08   diffe           0.3
#     2024-03-22 08:27:08   eco_temperature 16
#     2024-03-22 08:27:08   error_status    0
#     2024-03-22 08:27:08   frost_protection OFF
#     2024-03-22 08:27:08   heating_stop    OFF
#     2024-03-22 08:27:08   holiday_start_stop 2024/05/01 02:00 | 2024/10/15 01:00
#     2024-03-22 08:27:08   holiday_temperature 13
#     2024-03-22 08:27:08   last_seen       2024-03-22T08:27:08+01:00
#     2024-03-22 08:27:08   linkquality     255
#     2024-03-22 08:27:08   local_temperature_calibration -1
#     2024-03-22 08:27:08   mode            heat
#     2024-03-22 08:27:08   online          ON
#     2024-03-22 08:27:08   open_window     OFF
#     2024-03-22 08:27:08   open_window_temperature 8
#     2024-03-22 08:27:08   preset          auto
#     2024-03-22 08:27:08   schedule_friday 00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
#     2024-03-22 08:27:08   schedule_monday 00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
#     2024-03-22 08:27:08   schedule_saturday 00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
#     2024-03-22 08:27:08   schedule_schedule 00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
#     2024-03-22 08:27:08   schedule_sunday 00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
#     2024-03-22 08:27:08   schedule_thursday 00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
#     2024-03-22 08:27:08   schedule_tuesday 00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
#     2024-03-22 08:27:08   schedule_wednesday 00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
#     2024-03-22 08:27:08   schedule_week_day monday
#     2024-03-22 08:04:43   state           open_window
#     2024-03-22 08:27:08   temperature     20.3
#     2024-03-22 08:27:08   update_available false
#     2024-03-22 08:27:08   update_installed_version 69
#     2024-03-22 08:27:08   update_latest_version 69
#     2024-03-22 08:27:08   update_state    idle
#     2024-03-22 08:27:08   working_day     mon_sun
#
setstate MQTT2_zigbee_Heiz_Ess Modus: auto\
Kinder: UNLOCK\
Frost: OFF\
Aus: OFF\
BT:0\
<br>\
Fenster: OFF\
Battery: ok\
<br>\
Temp: 20.3°C, \
Wunsch: 20 °C\
Dev: 0.3 °C
setstate MQTT2_zigbee_Heiz_Ess 2024-03-21 09:24:17 IODev MQTT2_FHEM_Server
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 batteryPer 100
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 batteryState ok
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 battery_low false
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 boost_timeset_countdown 0
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 child_lock UNLOCK
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 comfort_temperature 20
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 desiredTemperature 20
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 device_applicationVersion 69
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 device_dateCode
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 device_friendlyName Heiz_Ess
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 device_hardwareVersion 1
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 device_ieeeAddr 0x0c4314fffe6a36b5
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 device_manufacturerID 4098
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 device_manufacturerName _TZE200_mudxchsu
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 device_model TV02-Zigbee
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 device_networkAddress 30240
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 device_powerSource Battery
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 device_stackVersion 0
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 device_type EndDevice
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 device_zclVersion 3
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 diffe 0.3
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 eco_temperature 16
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 error_status 0
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 frost_protection OFF
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 heating_stop OFF
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 holiday_start_stop 2024/05/01 02:00 | 2024/10/15 01:00
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 holiday_temperature 13
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 last_seen 2024-03-22T08:27:08+01:00
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 linkquality 255
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 local_temperature_calibration -1
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 mode heat
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 online ON
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 open_window OFF
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 open_window_temperature 8
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 preset auto
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 schedule_friday 00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 schedule_monday 00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 schedule_saturday 00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 schedule_schedule 00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 schedule_sunday 00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 schedule_thursday 00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 schedule_tuesday 00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 schedule_wednesday 00:10/16 07:00/16 10:00/20 11:00/20 20:00/20 24:00/16
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 schedule_week_day monday
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:04:43 state open_window
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 temperature 20.3
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 update_available false
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 update_installed_version 69
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 update_latest_version 69
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 update_state idle
setstate MQTT2_zigbee_Heiz_Ess 2024-03-22 08:27:08 working_day mon_sun

Gruß
_fhemuser_
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 März 2024, 08:57:42
Ja, inzwischen bzw. auch schon vorher dachte ich mir: mal aufnehmen was da ist und neu machen. Evtl. als Modul (ähnlich ActionDetector) aber da steht halt folgendes entgegen:

Zitat von: MadMax-FHEM am 22 März 2024, 08:19:04EDIT: und ja, habe auch gemerkt, dass man einiges vereinfachen und zusammenfassen kann aber ich habe dafür keine Zeit (und da ich eh bei mir anderen Code nutze auch keine rechte Lust) und testen ist ohne den Zoo zu haben nicht möglich und dann bei komplett umgebauten Code zu supporten kann ich auch nicht leisten, drum isses wie's ist ;)

Zitat von: MadMax-FHEM am 22 März 2024, 08:46:05Und halt: Zeit das zu machen... :-\

Weil mal ein wenig an dem Code-Schnipsel "basteln" ist das eine aber ein Modul (erstellen: eieiei) maintainen ist dann doch was anderes...

Hier (noch mal) Hut ab vor allen, die das machen!!

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 22 März 2024, 10:00:58
Dann gebe ich auch mal etwas zurück.

Erweiterung für MQTT Geräte die das Attribut battery_low haben
##############################################
# MQTT2_DEVICE that have battery Reading showing battery_low
##############################################
  elsif($BatteryType[0] eq "battery_low"  && $TYPE eq "MQTT2_DEVICE")
  {
    my $GraceStatus = checkGracePeriod($Device, $BatteryStatusBot, ReadingsVal($Device, "battery", "low"), $GracePeriod);

    if(ReadingsVal($Device, "battery_low", "false") eq "false")
    {
      # check if battery was low before -> possibly changed
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low")
      {
        # set date/time for changed battery if it was low before (so probably a change happended)
        fhem("setreading $BatteryChanged $Device $text_changed");
        # set the signal state back to none
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }

      # status is "ok" so we set to 100% (we don't know better)
      fhem("setreading $BatteryStatus $Device 100");
    }
    else
    {
      if($GraceStatus eq "true")
      {
        # send message
        Battery_Send_Alarm($BatteryStatusBot, $SignalDevice, $text_soon);

        # status is NOT "ok" ("low") so we set to 0% (we don't know better)
        fhem("setreading $BatteryStatus $Device 0");
      }
    }
  }
Ist quasi der Teil aus MAX! mit der passenden Bedingung.
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Prof. Dr. Peter Henning am 22 März 2024, 10:02:27
@MadMax-FHEM: Erst einmal großes Lob, dass Du Dir das überhaupt an die Backe gebunden hast. Das ist nämlich wirklich ein wilder Zoo, der sich kaum in einer einzelnen Codebasis verwalten lässt. Und wenn man glaubt, fertig zu sein, kommt noch User DAU123 und schreibt, dass leider sein Device Garglschnax aus dem Baumarkt in Hintertupfingen immer noch nicht korrekt angezeigt wird.

Andererseits zeigt gerade dieser Traffic, dass dafür ein großer Bedarf besteht. Also hier der konkrete Vorschlag:

Statt des gigantischen if - elsif - Konstruktes kürzt Du Deinen Code auf ein Minimum. Die einzelnen elsif-Zweige werden in separate Unterprogramme ausgelagert. Beispielsweise gibt es ein sub "batteryCheckZWaveType", das als Argument den Devicenamen bekommt. Und entweder die globalen Parameter $BatteryStatus etc. kennt, oder auf diese zugreifen kann.

In dem eigentlichen Code gibt es dann einen Hash, der unter anderem enthält

( "ZWave" => "ZWaveType",
  "HUEDevice" => "ZWaveType" ...)

Die BatteryStatusFunction schaut dann in diesem Hash nach, welche Funktion für ein Device des gegenwärtigen TYPE aufgerufen werden muss - eben z.B. dieselbe, wie bei ZWave.

Diese einzelnen Funktionen kann man (weil jetzt sehr viel kompakter) problemlos auf je einer Wiki-Seite beschreiben. Und wer möchte, kann sich diese eben in seiner eigenen 99_BatteryUtils.pm (oder was auch immer...) zusammenkopieren. Oder dazu eine eigene Funktion schreiben.

LG

pah

Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 22 März 2024, 10:25:04
Hier fehlten die Leerzeichen zwischen Batterien und $BatteryTypeText ca Zeile 42:
  my $text_now = "Die Batterien $BatteryTypeText von $Device müssen JETZT gewechselt werden!"; #Text for changing battery now
  my $text_soon = "Die Batterien $BatteryTypeText von $Device sollten bald gewechselt werden!"; #Text for changing battery soon

Könnte man auch den Aliasnamen statt des Devicenamens nehmen?

Gruß
_fhemuser_
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 März 2024, 11:32:48
Zitat von: _fhemuser_ am 22 März 2024, 10:25:04Hier fehlten die Leerzeichen zwischen Batterien und $BatteryTypeText ca Zeile 42:
-> NEIN!

Weil sonst OHNE das Attribut 2 Leerzeichen da sind ;)
Mit dem Attribut passt es (sollte)...

Zumindest bei meinen Tests... 8)

Zitat von: _fhemuser_ am 22 März 2024, 10:25:04Könnte man auch den Aliasnamen statt des Devicenamens nehmen?
Klar, es ist SW und da geht (fast) alles ;)

Mal sehen...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 März 2024, 11:40:11
Zitat von: Prof. Dr. Peter Henning am 22 März 2024, 10:02:27@MadMax-FHEM: Erst einmal großes Lob, dass Du Dir das überhaupt an die Backe gebunden hast. Das ist nämlich wirklich ein wilder Zoo, der sich kaum in einer einzelnen Codebasis verwalten lässt. Und wenn man glaubt, fertig zu sein, kommt noch User DAU123 und schreibt, dass leider sein Device Garglschnax aus dem Baumarkt in Hintertupfingen immer noch nicht korrekt angezeigt wird.
Danke!
Gerne!

Nur wer mitmacht und so :)


Zitat von: Prof. Dr. Peter Henning am 22 März 2024, 10:02:27Andererseits zeigt gerade dieser Traffic, dass dafür ein großer Bedarf besteht.
Ja, der ist aber Wellenweise, weil es war ganz zu Beginn etwas los (da war der TE ja noch dabei/dran)...
...dann passierte lange nichts.

Dann kamen ein paar Ergänzungswünsche aber auch "überschaubar"...

So viel Interesse und Traffic gab es (gefühlt) noch nie (auf jeden Fall schon lange nicht mehr)... ;)


Zitat von: Prof. Dr. Peter Henning am 22 März 2024, 10:02:27Also hier der konkrete Vorschlag:

Statt des gigantischen if - elsif - Konstruktes kürzt Du Deinen Code auf ein Minimum. Die einzelnen elsif-Zweige werden in separate Unterprogramme ausgelagert. Beispielsweise gibt es ein sub "batteryCheckZWaveType", das als Argument den Devicenamen bekommt. Und entweder die globalen Parameter $BatteryStatus etc. kennt, oder auf diese zugreifen kann.

In dem eigentlichen Code gibt es dann einen Hash, der unter anderem enthält

( "ZWave" => "ZWaveType",
  "HUEDevice" => "ZWaveType" ...)

Die BatteryStatusFunction schaut dann in diesem Hash nach, welche Funktion für ein Device des gegenwärtigen TYPE aufgerufen werden muss - eben z.B. dieselbe, wie bei ZWave.

Ja so oder so ähnlich hatte ich überlegt.
Hash, hmmm, mal sehen...

Aber das wird sicher dauern, wenn ich das überhaupt "raffe" und schaffe...


Zitat von: Prof. Dr. Peter Henning am 22 März 2024, 10:02:27Diese einzelnen Funktionen kann man (weil jetzt sehr viel kompakter) problemlos auf je einer Wiki-Seite beschreiben. Und wer möchte, kann sich diese eben in seiner eigenen 99_BatteryUtils.pm (oder was auch immer...) zusammenkopieren. Oder dazu eine eigene Funktion schreiben.

Ja, auch das müsste dann jemand machen (wollen)... ;)

Es kommt ja Ostern, ich denk mal drüber nach, vielleicht schaffe ich was vernünftiges zu bauen...
...aber grad weil Zeit ist könnte ich auch andere Projekte endlich mal umsetzen/angehen...
(noch dazu, wo ich selbst ganz anderen Code verwende, der aber ähnlich gewachsen ist ;-) :-\  )

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 März 2024, 11:46:21
Zitat von: _fhemuser_ am 22 März 2024, 10:00:58Dann gebe ich auch mal etwas zurück.

Erweiterung für MQTT Geräte die das Attribut battery_low haben

Hier wird aber ein Reading abgefragt ;)
Zitat von: _fhemuser_ am 22 März 2024, 10:00:58if(ReadingsVal($Device, "battery_low", "false") eq "false")

Wo kommt/käme das her? ;)

Ich muss mal sehen, vielleicht fällt mir was brauchbares ein.
Bzw. würde ich es ja gerne so machen, dass es für Anwender ohne Lust und Ahnung weiterhin einfach geht bzw. bestehende Anwender nix (groß) merken...
...andererseits wäre ein Attribut das angibt, dass der Code das Device beachten soll (und u.U. auch wie: welcher Readingname, GraceTime, Batterietyp, ...) sicher hilfreich, um Devices mit mehreren Batterie-Readings auseinaderhalten zu können...
Aber wenn ein Anwender dann das Attribut nicht (entsprechend) gesetzt hat, würde ja gar nix (mehr) klappen...

Nicht so einfach...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 22 März 2024, 11:52:58
Ich bin kein Programmierer und habe mir das selber beigebracht.

Der Codeschnipsel funktioniert bei mir. :)

Und mit dem Alias habe ich auch etwas gebastelt.

my $Alias = AttrVal($Device, "alias", "undef"); # get the corresponding alias name

my $text_now = "Die Batterien $BatteryTypeText von $Alias müssen JETZT gewechselt werden!"; #Text for changing battery now
my $text_soon = "Die Batterien $BatteryTypeText von $Alias sollten bald gewechselt werden!"; #Text for changing battery soon
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 März 2024, 12:03:35
Zitat von: _fhemuser_ am 22 März 2024, 08:47:32Dieser Sensor wird mit 0 in der Readingsgroup angezeigt:
Hmm, eigenartig.
Du meinst schon die readingsGroup des "Sammel-Dummy"?

Zitatmy $BatteryStatus = "BatterieStatus"; #Name of the Dummy for status

Welcher Wert steht denn dort für das Device drin?

Weil das hier:
Zitat von: _fhemuser_ am 22 März 2024, 08:47:32setstate Fenster_Ess 2024-03-22 08:04:43 battery 100

Müsste ja hier
Zitat##############################################
# MQTT2_DEVICE that have battery Reading showing percentage!
##############################################

wegen

Zitat
Zitat von: _fhemuser_ am 22 März 2024, 08:47:32#  TYPE      MQTT2_DEVICE

ausgewertet werden und dann entsprechend (weil > 75) auf 100 stehen...



Zitat von: _fhemuser_ am 22 März 2024, 08:47:32Dieser Thermostat gar nicht.
Wohin gegen hier ist klar: weder ein Attribut model/type o.ä. oder ein vergleichbares Internal...
Damit rauscht dieses Device durch alle if/elsif durch :-\

Ja würde mit dem Attribut, das anzeigt, dass es beachtet werden soll, klappen...

Mal sehen...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 März 2024, 12:09:01
Zitat von: _fhemuser_ am 22 März 2024, 11:52:58Ich bin kein Programmierer und habe mir das selber beigebracht.

Der Codeschnipsel funktioniert bei mir. :)

Und mit dem Alias habe ich auch etwas gebastelt.

my $Alias = AttrVal($Device, "alias", "undef"); # get the corresponding alias name

my $text_now = "Die Batterien $BatteryTypeText von $Alias müssen JETZT gewechselt werden!"; #Text for changing battery now
my $text_soon = "Die Batterien $BatteryTypeText von $Alias sollten bald gewechselt werden!"; #Text for changing battery soon

Ich auch nicht wirklich ;)

Ja so geht natürlich und auch der andere Schnipsel mag bei dir gehen...
...die "Kunst" ist allerdings, dass es eben bei allen anderen (weiterhin) funktioniert (wie gehabt)...

Drum ist das hier u.a. ja auch so gewachsen...

Weil: wenn es keinen alias gibt, dann steht bei Verwendung deines Codes nix drin 8)

Den alias baue ich noch ein, sodass er auch geht bzw. halt den Devicenamen anzeigt, wenn kein alias gesetzt ist...

Dann mache ich aber erst mal Pause :)

Die anderen Dinge schaue ich mir mal an, bin aber nicht sicher, ob das ohne weiteres für alle anderen (weiterhin) geht...

Ich tendiere ja eher zu Attribut, welches anzeigt, dass das Device beachtet werden soll und wenn wie...
...mal sehen.

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 März 2024, 12:14:34
Zitat von: MadMax-FHEM am 22 März 2024, 12:09:01Den alias baue ich noch ein, sodass er auch geht bzw. halt den Devicenamen anzeigt, wenn kein alias gesetzt ist...

Hängt an UNGETESTET...

EDIT: also nur im Mitteilungstext steht dann der alias. In der readingsGroup bzw. dem "Sammel-dummy" steht weiterhin (vorerst) der Devicename drin...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 22 März 2024, 12:20:58
Wird dabei nicht der Wert auf "n.a." geprüft und nicht auf "nichtvorhanden" oder "ohneInhalt"?
 :-\

Und es würden alle Geräte neu angelegt?
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 März 2024, 12:27:22
Zitat von: _fhemuser_ am 22 März 2024, 12:20:58Wird dabei nicht der Wert auf "n.a." geprüft und nicht auf "nichtvorhanden" oder "ohneInhalt"?
Ja ;)

Aber: wenn nicht vorhanden, dann Ersatzwert und der ist "n.a."

Wenn also nicht der Ersatzwert geliefert wird, dann ist der alias gesetzt und wird genommen...
...ansonsten bleibt es bei $Device.

Ja, verm. geht auch undef oder so?
Aber so weiß ich was passiert und dass es klappt, solange niemand sein Device per alias "n.a." nennt 8)


Zitat von: _fhemuser_ am 22 März 2024, 12:20:58Und es würden alle Geräte neu angelegt?
Verstehe ich nicht?

Aktuell wird ja weiterhin mit $Device gearbeitet, d.h. es hat sich NIRGENDS was geändert, nur im Message-Text.
Dort wird eben (so der Plan) der alias genommen, wenn gesetzt und wenn nicht (wie bisher) $Device (-> Devicename)...

EDIT: einen "generellen" Umbau von Devicename auf alias habe ich ja eben (noch) nicht vorgenommen...

Aber wie geschrieben: ungetestet...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 März 2024, 14:06:54
https://forum.fhem.de/index.php?topic=82637.msg1308082#msg1308082

Habe ich auch eingebaut...

Das hier https://forum.fhem.de/index.php?topic=82637.msg1308155#msg1308155

Habe ich übernommen...

Aber auch hier: NICHT GETESTET!!

Vielen Dank, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: TK67 am 22 März 2024, 16:16:55
Zitat von: MadMax-FHEM am 22 März 2024, 07:49:41
Zitat von: TK67 am 21 März 2024, 18:58:42Wäre nett wenn du das auch noch anhängen kannst.
Ich habe hier kein "Monopol" auf den Code ;)

Es darf jeder gerne mitarbeiten :)

Ist ja Code-Schnipsel und kein Modul mit Maintainer...

Aber falls du nicht willst (warum auch immer), kann ich die überschaubaren Änderungen auch einbauen... 8)

Gruß, Joachim


Hallo Joachim,
da die letzten Änderungen von dir gemacht wurden, dachte ich es macht Sinn es an dich weiter zu leiten.
Damit man einen einigermaßen gleichen Stand hat und nicht zig verschiedene Versionen.

Habe in deiner veröffentlichten Version eine Erweiterung mit CalculateBatteryLife laufen, die ich mir aus dem Topic 303 / 304 zusammen gebaut habe.
Entspricht somit auch nicht deiner Version und würde wahrscheinlich wieder zur Verwirrung führen, wenn ich die auch noch poste.

Wie gesagt es war jetzt keine Bequemlichkeit das nicht selber zu posten.
Grace Period und die letzten Erweiterungen mit skipped Device und Nachricht mit Batterietyp funktionieren bestens  :)


Gruß TK67
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 22 März 2024, 16:49:19
Zitat von: TK67 am 22 März 2024, 16:16:55Hallo Joachim,
da die letzten Änderungen von dir gemacht wurden, dachte ich es macht Sinn es an dich weiter zu leiten.
Damit man einen einigermaßen gleichen Stand hat und nicht zig verschiedene Versionen.

Zitat von: TK67 am 22 März 2024, 16:16:55Wie gesagt es war jetzt keine Bequemlichkeit das nicht selber zu posten.

;)

Alles gut!
Solche Änderungen einpflegen ist ja kein Ding und ja ein Durcheinander hätte schon passieren können, da aktuell wieder einiges los ist hier...
...und ich aktuell zwischendrin immer mal kurz Zeit hatte das zu machen, ist es so durchaus "besser" gewesen 8)

Zitat von: TK67 am 22 März 2024, 16:16:55Grace Period und die letzten Erweiterungen mit skipped Device und Nachricht mit Batterietyp funktionieren bestens  :)
Dann is ja gut. Danke :)

Zitat von: TK67 am 22 März 2024, 16:16:55Habe in deiner veröffentlichten Version eine Erweiterung mit CalculateBatteryLife laufen, die ich mir aus dem Topic 303 / 304 zusammen gebaut habe.
Entspricht somit auch nicht deiner Version und würde wahrscheinlich wieder zur Verwirrung führen, wenn ich die auch noch poste.

Weicht die (stark) von meiner geposteten Version ab?
https://forum.fhem.de/index.php?topic=82637.msg1042493#msg1042493

Naja, das kann man schon auch noch einbauen.
In der Startroutine dann noch einen dummy dafür (jaja: Schimpf und Schande ;)  ) und in der Sub dann prüfen, ob dummy da -> eintragen ansonsten eben lassen oder so...

Ich könnte auch noch eine BatteriesInStock beisteuern ;)

Ich habe einen dummy (jaja ;)  ), wo ich die Batterien, die ich aktuell zuhause habe eingepflegt habe und auch wenn ich welche kaufe oder anderweitig verwende aktualisiere.
Dann eben das Attribut BatteryType und mir darin eine "Strategie" überlegt, wie ich von dort zusammen mit meinem "InStock-dummy" dann rauskriege, ob ich noch genug Batterien habe.
Wenn nicht, bekomme ich auch eine Nachricht, dass ich nicht nur bald wechseln sollte, sondern auch Batterien kaufen sollte...

Der BatteriesInStock-Bestand wird nat. auch autom. aktualisiert, wenn ich die Batterien getauscht habe :)

Aber das würde verm. hier (aktuell) wirklich zu weit führen...
...wobei: wir sind ja in Code-Schnipsel ;)

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Prof. Dr. Peter Henning am 22 März 2024, 16:59:03
@TK67: Sorry, aber so läuft das bei FHEM nicht. Joachim ist hier nicht der Maintainer eines offiziell mit FHEM verteilten Moduls, man kann ihm also bitte nicht von außen die Verantwortung für die Pflege und Verteilung dieser Batteriesachen aufbürden. Das genau ist der Unterschied zwischen den "Codeschnipseln" in diesem Bereich des Forums, und den offiziell gewarteten Modulen.

Also bitte: Code genießen und mitwirken - aber nicht "ich leite das mal an Dich weiter, damit es eine Version gibt".

LG

pah
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: TK67 am 22 März 2024, 18:02:52
Zitat von: Prof. Dr. Peter Henning am 22 März 2024, 16:59:03@TK67: Sorry, aber so läuft das bei FHEM nicht. Joachim ist hier nicht der Maintainer eines offiziell mit FHEM verteilten Moduls, man kann ihm also bitte nicht von außen die Verantwortung für die Pflege und Verteilung dieser Batteriesachen aufbürden. Das genau ist der Unterschied zwischen den "Codeschnipseln" in diesem Bereich des Forums, und den offiziell gewarteten Modulen.

Also bitte: Code genießen und mitwirken - aber nicht "ich leite das mal an Dich weiter, damit es eine Version gibt".

LG

pah

@pah
Sorry aber irgendwie hast du mich da wohl missverstanden, es geht hier nicht darum zu delegieren, sondern ich habe Joachim lediglich freundlich darum gebeten, da er momentan sehr aktiv am Thema ist, meine von mir gefundenen Änderungen mit einzubinden.

Nichts anderes und nicht mehr, ich habe aktiv mitgewirkt und meine Lösungen gepostet.

Es ging mir darum das man nachher nicht auf über 30 Seiten irgendwelche Schnipsel zusammen suchen muss, damit man einen einheitliche Version hat.
Im übrigen bin ich dankbar dafür das sich Joachim die Mühe macht, diesen zusammen getragenen Code weiter zu entwickeln.

Gruß TK67 

Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Prof. Dr. Peter Henning am 22 März 2024, 19:17:20
Nö, da war nichts zum "missverstehen".

Und bitte nicht jedesmal den "Zitieren"- Button-benutzen, das ist einfach nur nervig und müllt das Forum zu. Der Button "Antworten" ist oben.

pah
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 23 März 2024, 11:24:39
@pah

wie könnte man denn die Änderungen, die mehrere Personen durchführen am Code, vernünftig aktualisieren und dass jeder den gleichen Versionsstand hat ohne dass jeder seine Änderung als Anhang beifügt und jeder diese Version wieder nutzt um seine Änderung einzupflegen.?

Mir würde dazu git einfallen. Aber auch da sollte einer über den Code sehen bevor die Änderungen zusammen geführt werden.

Aber selbt in Programmierteams arbeiten nicht mehrere Personen im gleichen Bereich an dem Code, was hier aber durchaus passiert.

Daher finde ich die Vorgehensweise, dass man einen bittet die Änderungen zusammen zu fassen und diese "komplette" Version dann anfügt, im Hobbybereich, und um den geht es hier, vertretbar.

Gruß
_fhemuser_
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Prof. Dr. Peter Henning am 23 März 2024, 18:26:30
Ich kann gar nicht so oft "Nein" schreiben, wie ich möchte ...
ZitatMir würde dazu git einfallen.
Wir pflegen denjenigen Code, der gepflegt wird, im zentralen SVN (nicht in git, das hat historische Gründe). Und wir warten ihn sehr intensiv.
ZitatAber auch da sollte einer über den Code sehen bevor die Änderungen zusammen geführt werden.
Das ist absoluter Unsinn. Das zentrale Programm fhem.pl wird von Rudi König gepflegt, wichtige Design-Entscheidungen von ihm und einer kleinen Gruppe getroffen. Aber für die allermeisten Module ist nur der jeweilige Maintainer zuständig. Und wenn sie nicht funktionieren, werden sie eben nicht verwendet.
ZitatAber selbt in Programmierteams arbeiten nicht mehrere Personen im gleichen Bereich an dem Code, was hier aber durchaus passiert.
Das ist doppelt unkorrekt. Selbstverständlich arbeiten in professionellen Teams durchaus verschiedene Entwickler an demselben Code. Hier in FHEM ist das wegen der verteilten Verantwortlichkeiten allerdings nicht die Regel.
ZitatDaher finde ich die Vorgehensweise, dass man einen bittet die Änderungen zusammen zu fassen und diese "komplette" Version dann anfügt, im Hobbybereich, und um den geht es hier, vertretbar.
Nein, ganz sicher nicht. Dieser Teil des Forums heißt "Codeschnipsel" und befasst sich nicht mit gewartetem Code. Sondern hier kann jeder etwas Kleineres einstellen, das anderen vielleicht nutzt. Und daraus ergibt sich keinerlei Vepflichtung, die sollte sich auch niemand aufbürden lassen.

Für größere Codebeispiele gibt es das Wiki. Und man kann solche längeren Beispiele durchaus über Updates verteilen, dafür gibt es den contrib-Ordner - aber auch dort gibt es keinerlei Wartung.

Nur in den Hauptverzeichnissen gibt es gewarteten Code. Und das soll auch so bleiben.

Mein Tipp: Sich einfach mal mit den Verzeichnisstrukturen befassen und einen Blick in die Datei MAINTAINER.txt werfen.

pah
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: LutzG am 24 März 2024, 02:56:50
Hallo Herr Prof. Dr. Peter Henning
Zitat von: Prof. Dr. Peter Henning am 23 März 2024, 18:26:30Ich kann gar nicht so oft "Nein" schreiben, wie ich möchte ...
[...] Das ist absoluter Unsinn.
[...] Das ist doppelt unkorrekt. Selbstverständlich arbeiten in professionellen Teams
[...] Nein, ganz sicher nicht.
[...] Mein Tipp: Sich einfach mal mit den Verzeichnisstrukturen befassen und einen Blick in die Datei MAINTAINER.txt werfen.
mich macht ihre Antwort echt sauer! Ich kann keine Silbe finden, die irgend etwas mit dem Thema: "Batteriestatus und Speicherung des letzten Wechsel" zu tun hat! Wenn ich mich wie @Joachim mit dem Codeschnipsel befassen könnte / hätte, hätte ich spätestens jetzt keinen Bock mehr darauf! (Was ich hoffe, nicht passiert.)

Mit freundlichen Grüßen,

Lutz
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Prof. Dr. Peter Henning am 24 März 2024, 03:26:38
Herzlich Willkommen !

Und auch hier gilt der Tipp: Einfach mal in die Datei MAINTAINER.txt schauen, dort kann man sehr gut sehen, welcher Code gewartet und weiter entwickelt wird.

pah
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 24 März 2024, 09:48:20
[OT]
@pah

Egal ob git, svn oder irgendeine andere Lösung zur Bearbeitung des Codes genutzt wird, es setzt voraus, dass es eine Benutzerverwaltung gibt die auch gepflegt werden muss. Das ist für diesen Teil nicht zu bewerkstelligen.

Zitat von: Prof. Dr. Peter Henning am 23 März 2024, 18:26:30
ZitatAber auch da sollte einer über den Code sehen bevor die Änderungen zusammen geführt werden.
Das ist absoluter Unsinn. Das zentrale Programm fhem.pl (https://fhem.pl/) wird von Rudi König gepflegt, wichtige Design-Entscheidungen von ihm und einer kleinen Gruppe getroffen. Aber für die allermeisten Module ist nur der jeweilige Maintainer zuständig. Und wenn sie nicht funktionieren, werden sie eben nicht verwendet.
Bei den Modulen ist der Maintainer derjenige der den Code überprüft vor der Veröffentlchung. Also sieht einer über den geänderten Code. Ich sprach nicht davon, dass der ganze Code immer komplett geprüft werden muss.

Zitat von: Prof. Dr. Peter Henning am 23 März 2024, 18:26:30
ZitatAber selbt in Programmierteams arbeiten nicht mehrere Personen im gleichen Bereich an dem Code, was hier aber durchaus passiert.
Das ist doppelt unkorrekt. Selbstverständlich arbeiten in professionellen Teams durchaus verschiedene Entwickler an demselben Code. Hier in FHEM ist das wegen der verteilten Verantwortlichkeiten allerdings nicht die Regel.
Ja die Entwickler arbeiten am selben Code, aber nicht in der gleichen Struktur, im gleichen Absatz, im selben Block, an einer sub, oder wie man das auch immer nennen möchte. Hier auf FHEM bezogen am selben Modul.
So nach dem Motto: Viele Köche verderben den Brei.

[So genug OT]



Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: Prof. Dr. Peter Henning am 24 März 2024, 10:41:36
ZitatBenutzerverwaltung gibt die auch gepflegt werden muss
Die gibt es auch für den gewarteten Code.

ZitatBei den Modulen ist der Maintainer derjenige der den Code überprüft vor der Veröffentlchung. Also sieht einer über den geänderten Code.
Ich schreib es ja ungern: Das ist immer noch falsch. Denn nur der Maintainer ändert den Code und checkt ihn ein. Gerne natürlich nach Vorschlägen anderer Nutzer - aber in der Regel nach sorgfältigen Tests, die nicht aus "drüber sehen" bestehen.

Zitatnicht in der gleichen Struktur,.... Hier auf FHEM bezogen am selben Modul.
Aber doch.

Abgesehen davon, dass dies nicht OT ist, sondern man offensichtlich überzogene Anforderungen in diesem Bereich des Forums korrigieren muss, steht es jedem frei, sich nicht mehr dazu zu äußern.

pah
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 25 März 2024, 17:49:20
So, es gibt ne neue Version ;)

Ich habe ein paar Dinge (ja, erst mal sehr wenige/Kleinigstkeiten ;) :-\ ) glatt gezogen (und hoffentlich nichts "kaputt gezogen" 8) ) aber v.a. die Berechnung der Batterielebensdauer eingebaut, siehe: https://forum.fhem.de/index.php?topic=82637.msg1308213#msg1308213 und https://forum.fhem.de/index.php?topic=82637.msg1042493#msg1042493

Damit steht im dummy "BatterieLebensdauer" die Lebensdauer der Batterie in Wochen. Somit hat man einen Überblick (evtl. "ausgelagert" in eine readingsGroup) wie lange die Batterien pro Device denn so halten/gehalten haben. Hilft evtl. auch bei einer Abschätzung, wann es denn wieder so weit sein könnte und ob evtl. die einen Batterie-Typen besser sind als die anderen oder ob beim Device in der Zeit mehr oder weniger "los war" o.ä.

Wer es nutzen möchte muss zusätzlich zum Einspielen der neuen Version entweder die Start-Routine noch mal anwerfen oder den dummy "BatterieLebensdauer" von Hand anlegen...

@TK67: es ist eine Mischung aus allem geworden ;)

Rudimentär getestet...

Bzgl. generellem Umbau überlege ich noch...
Zeit würde es werden...

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 26 März 2024, 10:01:07
Hier noch eine kleine Erweiterung damit im Status des BatterieStatus dummy auch die Geräteanzahl angezeigt wird und nicht die ???

attr BatterieStatus stateFormat anzahl
attr BatterieStatus userReadings anzahl {my $anz = grep( m/ */, ( keys %{$hash->{READINGS}} ));; return $anz - 1;;},
Kleiner Nachteil. In der Readingsgroup wird anzahl mit aufgeführt und versucht mit einem Batterieicon darzustellen.

Gruß
_fhemuser_
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 26 März 2024, 10:05:00
:)

EDIT: musste erst ganz kurz überlegen, was der "smiley" am Ende bedeuten soll... Klar: 3 Fragezeichen... ;)

Wobei ich ja für die Anzeige readingsGroup nutze...

Die dummy sind bei mir nur "Hilfskonstrukte" ;)

Danke, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: TK67 am 27 März 2024, 01:57:13
Zitat von: MadMax-FHEM am 25 März 2024, 17:49:20@TK67: es ist eine Mischung aus allem geworden ;)

Thx Joachim,
ist eine sehr gute Mischung geworden, läuft alles bestens.  :)   


Gruß TK67
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 27 März 2024, 13:25:24
Wie ich unter https://forum.fhem.de/index.php?msg=1308144 geschrieben hatte, wurden einige Sensoren mit 0% eingetragen aber keine Alarme versandt.

Nach langer Suche fand ich heraus, dass die MQTT Devices mit % Werten in battery eine falschen Weg einschlagen.

unter https://forum.fhem.de/index.php?msg=1308082 wurde bereits ungefähr in Zeile 100 der Eintrag erweitert.
Zitatif($BatteryType[0] eq "battery"  && $Model ne "HM-TC-IT-WM-W-EU" && $Model ne "HM-CC-RT-DN" && $Model ne "undef" && $TYPE ne "HUEDevice")


der muss um MQTT_Device erweitert werden.
Zitatif($BatteryType[0] eq "battery"  && $Model ne "HM-TC-IT-WM-W-EU" && $Model ne "HM-CC-RT-DN" && $Model ne "undef" && $TYPE ne "HUEDevice" && $TYPE ne "MQTT2_DEVICE")
für MQTT Device mit battery % gibt es einen eigenen Abschnitt ab Zeile 425

[edit]
Und bei Zeile 430 muss HUEDevice hinzu gefügt werden
Zitat##############################################
# MQTT2_DEVICE that have battery Reading showing percentage!
##############################################
  elsif($BatteryType[0] eq "battery"  && ($TYPE eq "MQTT2_DEVICE" || $TYPE eq "HUEDevice"))
[/edit]

Gruß
_fhemuser_

Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 27 März 2024, 13:41:21
Zitat von: _fhemuser_ am 27 März 2024, 13:25:24der muss um MQTT_Device erweitert werden.
Hab's eingebaut, Version hängt an.

Allerdings wie ihr merkt wird es (langsam) "unübersichtlich" und bei dem ein oder anderen gibt es dann Devices, die "sowohl als auch" haben und dann tauchen diese u.U. doppelt auf o.ä. (gibt es ja bereits, siehe: https://forum.fhem.de/index.php?topic=82637.msg1308143#msg1308143).

Aber ein Komplettumbau ist nicht ganz so schnell umgesetzt... :-\

Gruß, Joachim
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: _fhemuser_ am 27 März 2024, 15:12:55
@Joachim,

Vielleicht wäre ein etwas anderer Ansatz für die Filterung und die anschließende Auswertung und Anzeige interessant.

Ich hatte ja schon bei allen Geräten ein userReading angelegt in dem aus den vohandenen battery, battery_low, usw immer ein Prozentwert erstellt wird. Damit hat man eine identische Variable bei allen Geräten die immer die gleiche Wertigkeit hat.

Dann habe ich aus der Datei 99_Batterycheck.pm ab Zeile 70 bei denen die if Zweige starten, alles gelöscht und nur einen Zweig eingerichtet.

Damit wird die ganze Datei deutlich übersichtlicher.

Daraus folgt, dass in den if elseif Zweigen nur eine Zeile steht in der die Werte angeglichen werden und anschließend der Ausführungsteil abgearbeitet wird, und der Ausführungsteil nicht mehrfach vorhanden sein muss.

Im Anhang mal meine Version ohne if elseif Bedingungen.

Gruß
_fhemuser_
Titel: Aw: Batteriestatus und Speicherung des letzten Wechsel
Beitrag von: MadMax-FHEM am 27 März 2024, 15:40:12
Ja, userReadings ist auch eine Möglichkeit...
Neben der mit Attribut.

Weil, ein Attribut wird es eh geben: BatteryTyp ;)
Und evtl. weitere "Einstellungen"...

Gruß, Joachim