Batteriestatus und Speicherung des letzten Wechsel

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

Vorheriges Thema - Nächstes Thema

_fhemuser_

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.
fhem in der aktuellsten Version auf:
Raspberry 4 mit SSD | fhem2fhem | NanoCul433 Selbstbau | NanoCul868 Selbstbau | DbLog | MAX! | zigbee2MQTT | homebridge | alexa
inkl zigbee2MQTT Server, Unifi-Server

Raspberry 4 mit SD Karte | fhem2fhem | motioneye

Amenophis86

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 ;)
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Wzut

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.   
     
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

_fhemuser_

@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.
fhem in der aktuellsten Version auf:
Raspberry 4 mit SSD | fhem2fhem | NanoCul433 Selbstbau | NanoCul868 Selbstbau | DbLog | MAX! | zigbee2MQTT | homebridge | alexa
inkl zigbee2MQTT Server, Unifi-Server

Raspberry 4 mit SD Karte | fhem2fhem | motioneye

Amenophis86

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 ";
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

_fhemuser_

@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.
fhem in der aktuellsten Version auf:
Raspberry 4 mit SSD | fhem2fhem | NanoCul433 Selbstbau | NanoCul868 Selbstbau | DbLog | MAX! | zigbee2MQTT | homebridge | alexa
inkl zigbee2MQTT Server, Unifi-Server

Raspberry 4 mit SD Karte | fhem2fhem | motioneye

Wzut

@_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 :)
 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Amenophis86

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.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Amenophis86

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%.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Wzut

#54
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.

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Amenophis86

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.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

_fhemuser_

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.
fhem in der aktuellsten Version auf:
Raspberry 4 mit SSD | fhem2fhem | NanoCul433 Selbstbau | NanoCul868 Selbstbau | DbLog | MAX! | zigbee2MQTT | homebridge | alexa
inkl zigbee2MQTT Server, Unifi-Server

Raspberry 4 mit SD Karte | fhem2fhem | motioneye

Amenophis86

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.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Wzut

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)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher