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

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 1938
  • Anti-Statement befreite Zone ;)
Batteriestatus und Speicherung des letzten Wechsel
« am: 12 Januar 2018, 19:23:20 »
Der User MadMax-FHEM hat dankenswerterweise hier seinen Code geteilt, welcher folgende Funktionen inne hat:

1. Es gibt einen Dummy, in welchem der aktuelle Status sämtlicher Batteriegeräte festgehalten wird.
2. Es gibt einen Dummy, in welchem die aktuellen Prozente der Batterie festgehalten werden (dient der ReadingsGroup Ansicht)
3. Es gibt eine ReadingsGroup, welche den aktuellen Status der Batterie als Icon darstellt
4. Es gibt einen Dummy, welcher automatisch ein Reading anlegt für gewechselte Batterien
5. Das Scipt eine Nachricht verschickt, sobald der Status einer Batterie auf low wechselt, oder leer meldet


Um das Script zu erhalten muss wie folgt vorgegangen werden:
1. In der 99_myUtils.pm (oder wie auch immer eure PM für eigene Funktionen heißt) folgenden Code schreiben und speichern:

Edit: Code ist nun auf github verfügbar: https://github.com/Amenophis86/Batteryfunktion

2. Werte entsprechend anpassen (Siehe weiter unten)
3. Einmalig die Funktion BatteryStart ausführen. Sobald diese durchgelaufen ist, könnt ihr sie wieder löschen.




Aktuell sind folgende Änderungen direkt in der Funktion verfügbar:
BatteryStatusFunction:
  • Art der Nachrichten Sendung
  • Text für Nachrichten selbst wählen
  • Name der entsprechenden Dummys
  • Text für das Reading wann zuletzt die Batterie gewechselt wurde

BatteryStart:
  • Name der entsprechenden Dummys
  • Name der ReadingsGroup
  • Raum für alle Geräte
  • Name des Notify



Aktuell werden folgende Typen unterstützt:
- Homematic
- Z-Wave
- Xiamoi
- MAX! (Noch Probleme durch den ständigen Wechsel mit ok / low Meldungen)


Geplant:
- Da ich noch LaCrosse Sensoren habe, werde ich diese noch einbauen, sobald ich Zeit dafür finde.
- Weiterhin ist geplant das MAX! Problem in den Griff zu bekommen.

« Letzte Änderung: 18 Januar 2018, 20:06:23 von Amenophis86 »
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1717
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #1 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!

« Letzte Änderung: 12 Januar 2018, 20:12:23 von Wzut »
Maintainer der Module: MPD, EDIPLUG, UbiquitiMP, UbiquitiOut, SIP

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1717
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #2 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")
 
« Letzte Änderung: 12 Januar 2018, 20:49:05 von Wzut »
Maintainer der Module: MPD, EDIPLUG, UbiquitiMP, UbiquitiOut, SIP

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 3103
  • NIVEAu ist keine Creme...
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #3 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
FHEM 5.8 Pi 3: HM-CFG-USB, 40x HM, ZWave-USB, 5x ZWave, EnOcean-PI, 3x EnOcean, DashButtons, CO2, ESP-Multisensor, FireTV, NanoLeaf
FHEM 5.8 PI 2: HM-CFG-USB, 23x HM, ZWave-USB, 3x ZWave, EnOcean-PI, 3x EnOcean, CO2, KODI, ha-bridge
FHEM 5.8 PI 3 (Test): HM-MOD-PCB, Alexa (alexa-fhem), Google Home

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 1938
  • Anti-Statement befreite Zone ;)
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #4 am: 13 Januar 2018, 10:52:36 »
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
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1717
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #5 am: 13 Januar 2018, 14:29:51 »
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.
Maintainer der Module: MPD, EDIPLUG, UbiquitiMP, UbiquitiOut, SIP

Offline helmut

  • Jr. Member
  • **
  • Beiträge: 74
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #6 am: 13 Januar 2018, 16:09:44 »
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
Intelligenz ist die Fähigkeit, Arbeit zu vermeiden, aber dafür zu sorgen, daß die Arbeit gemacht wird.
(Linus Torvalds)

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 1938
  • Anti-Statement befreite Zone ;)
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #7 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.
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 1938
  • Anti-Statement befreite Zone ;)
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #8 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
« Letzte Änderung: 14 Januar 2018, 20:02:31 von Amenophis86 »
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline helmut

  • Jr. Member
  • **
  • Beiträge: 74
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #9 am: 14 Januar 2018, 20:09:23 »
@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
Intelligenz ist die Fähigkeit, Arbeit zu vermeiden, aber dafür zu sorgen, daß die Arbeit gemacht wird.
(Linus Torvalds)

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1717
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #10 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");


 

Maintainer der Module: MPD, EDIPLUG, UbiquitiMP, UbiquitiOut, SIP

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 3103
  • NIVEAu ist keine Creme...
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #11 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
FHEM 5.8 Pi 3: HM-CFG-USB, 40x HM, ZWave-USB, 5x ZWave, EnOcean-PI, 3x EnOcean, DashButtons, CO2, ESP-Multisensor, FireTV, NanoLeaf
FHEM 5.8 PI 2: HM-CFG-USB, 23x HM, ZWave-USB, 3x ZWave, EnOcean-PI, 3x EnOcean, CO2, KODI, ha-bridge
FHEM 5.8 PI 3 (Test): HM-MOD-PCB, Alexa (alexa-fhem), Google Home

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 1938
  • Anti-Statement befreite Zone ;)
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #12 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.
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 1938
  • Anti-Statement befreite Zone ;)
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #13 am: 15 Januar 2018, 18:31:15 »
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.
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1717
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #14 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.
     
« Letzte Änderung: 16 Januar 2018, 10:02:23 von Wzut »
Maintainer der Module: MPD, EDIPLUG, UbiquitiMP, UbiquitiOut, SIP

 

decade-submarginal