Hallo allerseits.
Ich habe ca. 35 batteriebetriebene Sensoren/Aktoren im Einsatz.
Jetzt nach ca. 2 Jahren müssen langsam die Batterien getauscht werden. (battery low)
Ich will den Batteriewechsel in FHEM dokumentieren. Der Eintrag in comment war mir zu umständlich.
Im Augenblick tendiere ich zu folgender Lösung. --> Usage: setreading <name> <reading> <value>
-->setreading <name> Batteriewechsel 1 ( value 1 für 1. BW bis value n für ff BW)
Beispiel für HM-CC-TC: --> setreading EG_WZ Batteriewechsel 1
Ergebnis: -->Readings: Batteriewechsel 1 2014-10-27 08:05:17
Ein list .* Batteriewechsel --> spuckt
EG_WZ 2014-10-27 08:05:17 1
aus.
Vorteil, der Batteriewechsel wird in FHEM automatisch mit Datum/Zeit dokumentiert und kann jederzeit mit (list .* Batteriewechsel)
über alle Geräte abgerufen werden.
Spricht was gegen diese Vorgehensweise (fhem.save muß regelmässig gespeichert werden) oder gibt es schon
eine bessere Lösung? z.B Attribut samt Datum setzen?
Gruß Billy
Hallo,
gute Idee.
Genial wäre wenn man über ein setList das Device auswählen könnte und per set dann das reading im richtigen Device abgespeichert wird.
Inkl. Datum und Uhrzeit.
Also sowas wie ein Dummy der im setList alle batteriebetriebenen Geräte auflistet wo man dann einfach nur das jeweilige auswählen müsste.
Aber deine Idee ist auch gut - ich leg mir bisher immer einen Zettel ins Batteriefach mit dem Datum ;D
Grüße
Bei einigen Geräten müsste sich das ganz automatisch realisieren lassen: Wenn die gelieferte Spannung von 'eher leer' auf 'eher frisch' springt, dann ein Wechsel dokumentieren...
Oder (umständlicher, wenn keine Spannung geliefert wird): Wenn LOW-Warnung verschwindet dann vormerken und wenn mehrere Tage nicht wieder auftritt, den vorgemerkten Wechsel 'festschreiben'.
Auch bei anderen Geräten die mit einem set replaceBatteryForSec arbeiten (LaCrosse/Jeelink), müsste sich das automatisieren lassen.
Hallo,
gute Idee @Hexenmeister und marvin78
Bei meinen FHT müsste aber dann noch sowas wie ein watchdog dazwischen.
Die melden erstmal battery:low und gehen dann wieder auf ok.
ZitatWenn LOW-Warnung verschwindet dann vormerken und wenn mehrere Tage nicht wieder auftritt, den vorgemerkten Wechsel 'festschreiben'.
Äh ja genau - hat hexenmeister ja schon erwähnt ::)
Grüße
@ Alle
Den Antworten entnehme ich, dass es bisher noch keine entsprechende Lösung gibt und dass nichts gegen mein Vorgehen spricht.
Die Ideen zum automatischen Eintrag haben durchaus Scharm! ;)
Ich für meinen teil möchte aber dokumentieren wann ich die Batterien gewechselt habe.
Das kann im Einzelfall auch Tage nach der ersten battery low Meldung sein.
Ausserdem meldet mein Zisternensensor KFM100 kein Battery low, da nutzt mir die Automatik leider nichts.
Danke schon mal für Eure Ideen.
Ich bin überzeugt, da kommt noch mehr.
Gruß Billy
die ideen zum automatischen eintrage zielten glaube ich entweder auf den übergang von low wider nach ok d.h. es wird registriert wenn eine neue batterie drin ist oder waren mit dem replaceBatteryForSec verknüpft das manuell gesetzt wird.
noch ein ideefür alle die eine readingsGroup einsetzen um den batteriestand anzuzeigen (siehe z.b. wiki) kann man für das (rote) battery low icon ein kommando hinterlegen das das setreading mit einem klick erledigen würde.
gruss
andre
Danke Andre,
das scheint mir eine gute Kombination aus Automatik und manueller Bestätigung.
Dem werde ich mal nachgehen.
Gruß Billy
ZitatSpricht was gegen diese Vorgehensweise (fhem.save muß regelmässig gespeichert werden)
vorsicht. wenn du bei homematic zb ein clear readings machst, ist das reading weg.
Zitat von: frank am 28 Oktober 2014, 18:47:34
vorsicht. wenn du bei homematic zb ein clear readings machst, ist das reading weg.
Danke für den Hinweis.
Deshalb habe ich jetzt eine andere Möglichkeit ausprobiert über zusätzliches Attribut
"battery_change"Mit Eingabe auf Befehlszeile von { addToAttrList("battery_change") } --> in attr List aufgenommen.
Jetzt kann ich bei Batteriewechsel das Attribut setzen.
Ein --> list .* battery_change
EG_WZ 1 2014-10-27 08:05:17
KFM100 1 2014-05-07 09:44:58
sieht dann so aus.
Im Augenblick bevorzuge ich diese Lösung.
Ist m.E. einfacher und sicherer.
Gruß Billy
leider kann man das als attribut nicht mehr direkt loggen/plotten. wenn man das will müsste man beim setzen noch ein zusätzliches trigger ... einbauen.
gruß
andre