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

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2070
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #15 am: 16 Januar 2018, 10:00:54 »
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");
Maintainer der Module: MPD, UbiquitiMP, UbiquitiOut, SIP

Offline Firetic

  • Jr. Member
  • **
  • Beiträge: 85
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #16 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

Online Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2507
  • Anti-Statement befreite Zone ;)
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #17 am: 16 Januar 2018, 17:34:14 »
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.

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.
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Online Amenophis86

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

Online Amenophis86

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

Offline SibbeH

  • New Member
  • *
  • Beiträge: 36
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #20 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
« Letzte Änderung: 20 Januar 2018, 21:08:22 von SibbeH »
Raspberry Pi, CULV3, MAX Thermostat, MAX Wandthermostat, FS20AS1-2, FS20UE1-2, FS20PIRA, FS20DT, FS20UWS, UtilsMaxProf, UWZ

Online Amenophis86

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

Offline SibbeH

  • New Member
  • *
  • Beiträge: 36
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #22 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
Raspberry Pi, CULV3, MAX Thermostat, MAX Wandthermostat, FS20AS1-2, FS20UE1-2, FS20PIRA, FS20DT, FS20UWS, UtilsMaxProf, UWZ

Online Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2507
  • Anti-Statement befreite Zone ;)
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #23 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.
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: 2070
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #24 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.
Maintainer der Module: MPD, UbiquitiMP, UbiquitiOut, SIP

Online Amenophis86

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

Offline SibbeH

  • New Member
  • *
  • Beiträge: 36
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #26 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
Raspberry Pi, CULV3, MAX Thermostat, MAX Wandthermostat, FS20AS1-2, FS20UE1-2, FS20PIRA, FS20DT, FS20UWS, UtilsMaxProf, UWZ

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2070
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #27 am: 21 Januar 2018, 15:06:16 »
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.
Maintainer der Module: MPD, UbiquitiMP, UbiquitiOut, SIP

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 4405
  • NIVEAu ist keine Creme...
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #28 am: 21 Januar 2018, 15:34:29 »
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
FHEM 5.8 PI3: HM-CFG-USB, 40x HM, ZWave-USB, 6x ZWave, EnOcean-PI, 3x EnOcean, DashButtons, CO2, ESP-Multisensor, FireTV, NanoLeaf, ...
FHEM 5.8 PI2: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, KODI, ha-bridge, ...
FHEM 5.8 PI3 (Test): HM-MOD-PCB, Alexa (alexa-fhem), Google Home

Offline SibbeH

  • New Member
  • *
  • Beiträge: 36
Antw:Batteriestatus und Speicherung des letzten Wechsel
« Antwort #29 am: 21 Januar 2018, 16:34:17 »
Ich wollte nur angeben warum bei MAX die Meldung Bat low so often wechselt....
Raspberry Pi, CULV3, MAX Thermostat, MAX Wandthermostat, FS20AS1-2, FS20UE1-2, FS20PIRA, FS20DT, FS20UWS, UtilsMaxProf, UWZ

 

decade-submarginal