Hi Ändy,
Danke für den Tipp!
Ich hab bis jetzt immer den Spannungsabfall mit einer starken LED gemessen.
Ist leider nicht so aussagekräftig!
Hab gerade deinen Tipp mit dem Kurzschlussstrom getestet, der funktioniert zuverlässiger!
Meine “Neuen” haben sogar 800mA, das gilt allerdings nur für die ER14250!
Die CR123A kann man so nicht messen, oder hast du dafür auch einen Tipp
die kannst Du auch messen allerdings haben die echt einen brutalen Strom (meine sind von Varta). Das geht locker über 10A! Dachte ich traue meinen Augen nicht Die Methode ist übrigens ziemlich grob. Besser wäre schon mit einem geeigneten Widerstand usw. Also aufpassen und nur kurz messen.
Ach ja, um nochmal auf das Batteriecheckscript zurück zu kommen. Der Türsensor war bisher komplett unauffällig was Batteriestand betrifft. Der Ausfall trat natürlich genau zwischen Türe öffnen/schließen auf. Zum ersten Senden hat’s wohl noch gereicht. Das Schließen hat das HC dann nicht mehr mitbekommen und bin dann später alarmiert worden (Haus offen bei Abwesenheit). Das hat aber natürlich nichts mit dem tollen Script zu tun sondern mit der Eigenart der Batterien und dem Türsensor.
@Atari
Dass die Batterien mit 40% schon Probleme machen ist leider eine Tatsache!
Ich hatte schon manchmal Probleme mit Batterien die noch 50% Akkustand hatten.
Deshalb habe ich mein Batterieskript so eingestellt, dass es schon bei 60% Batteriestand Alarm schlägt und ich wechsel die Batterien dann auch aus bevor sie auf 50% runter sind. Damit habe ich bis jetzt keine Probleme gehabt.
Ihr erschreckt mich, so was kann leicht ins Auge gehen und das im wörtlichen Sinne. Ich würde dass so NIE tun.
Kurzschluss über Amperemeter schadet der Batterie und Euch.
Wer schon mal messen will, kann das mit einen parallel zur Batterie geschalteten Widerstand von 120 Ohm ca. 0,5 Watt.
Der Strom der dann fließt entspricht einem sendenden ZWave GEN5 Sensor und beträgt ca. 35 mA. Am besten geht das wenn man
das per Knopfdruck lösen kann, sonst ist es eine Fummelei. Fällt die Spannung gut über 0.5 Volt, macht es die Batterie
nicht mehr lange. Hängt aber alles von der Batterie selbst, Umgebungstemperatur und Aufwachinterval ab.
Für die ER 14250 habe ich mir eine Halterung aus einem defekten Tür/Fenstersensor gebastelt.
Du hast natürlich Recht. Ich würde das nicht für den Hausgebrauch empfehlen. Die Stromstärke bei der CR123A hat mich echt überrascht. Das macht mich auch nachdenklich was passiert, wenn es mal einen Defekt gibt…
Ich habe hier noch einen einfachen Batterietester der auch sehr gut funktioniert. Die Prüfung wird unter Last durchgeführt und man kann einen deutlichen Unterschied von frisch zu verbraucht feststellen (mit ER14250 überprüft).
Für Buttons, Schalter, Keyfobs ist es ja nicht so schlimm. Die kann man ja leerziehen bis sie nicht mehr gehen. Ich Fall eines Fenster/Türsensors ist es schon deutlich unangenehmer wenn diese plötzlich versagen. Ich wunder mich noch immer, dass ich im Vorfeld keinerlei Batterieabfall festgestellt hatte. Umgekehrt habe ich einen Wassermelder, bei dem man den Batteriestandrückgang seit über einem Jahr sauber mitverfolgen kann (alles Fibarogeräte mit originaler Batterie).
Hi @Ändy,
ja das stimmt schon mit den Fenster/Türsensoren. Weil ja die meistens Teil eines Alarmsystems sind, ist das um so ärgerlicher. Und
im Winter bei Kälte ist es noch schlimmer. Da habe ich schon mal Schwankungen nach unten und paar Tage später, als es wärmer wurde wieder
ein paar % nach oben gehabt.
Dieser plötzliche Energieabfall ist Lithiumbatterien nicht ungewöhnlich.
Aber ich konnte auch schon einige ER14250 bis 25% betreiben bis sie ausfielen. Eine CR123 lief noch gut bei bis 15%. Ich versuche
eher aus Umweltschutzgründen die Batterien so lange wie möglich zu nutzen.
Mit der Z-Wave 5.0 Version soll ja alles besser werden, da kann man ja Batterie Geräte über Funk aufwecken und den Batteriestatus dann
direkt auslesen. Frage mich nur wann das sein wird.
mich würden Deine Strommessungen näher interessieren. Du schreibst was von 35mA. Hast Du auch mal einen Wakeup Vorgang beobachtet? Ist die Stromaufnahme hier intensiver?
Ich hab mir auch mal meine Batteriedevices näher angeschaut und festgestellt, dass ich auch noch LED-Signale an hatte. Beim Türsensor den Wakeup und beim MS den Tamper (LEDs bei Auslösung hatte ich schon vor längerer Zeit mal ausgemacht). Hab das alles mal ausgestellt da dies vermutlich zusätzlich die Batteriespannung einbrechen läßt, wenn diese schon am leer werden ist. Hab derzeit keine Geräte lose rumliegen für Versuche.
beim WakeUp wird ja meistens was gesendet, Temperatur- Status-, Batteriewerte etc. Manchmal werden auch Konfigurationsänderungen empfangen. Die LED wird schätzungsweise zusätzliche 2-4 mA verbraten was ich für vernachlässigbar halte da ja die Zeit relativ kurz ist. Aber ein WakeUp Intervall von 1/Tag oder 20 mal am Tag, macht da viel mehr aus. Ganz klar, ist die Batterie eh am Ende zählt jedes mA um die Kommunikation aufrecht zu erhalten.
Was ich noch beobachten konnte - nach jedem Wakeup bricht die Spannung ein wenig ein, erholt sich aber bei einer noch guten Batterie innerhalb von wenigen Sekunden. Je älter die Batterie wird desto größer ist der Spannungsabfall und die Erholzeit dauert immer länger. So was trifft aber generell auf fast alle Batterien zu.
Ein reines WakeUp so wie es FLIRS Geräte machen, verbraucht beim nur Lauschen natürlich weniger, wieviel weiß ich auch nicht genau. Thermostate mit FLIRS sollen aber zumindest eine Heizperiode durchhalten.
bisher hatte ich die alter Version des Scripts im Einsatz. Diese habe ich dahingehend verändert, dass ich zusätzlich einen Sprachausgabe über einen Sonos-Lautsprecher bekommen habe. Das ist praktisch, da ich über SceneActivation die Szene mit einem Triple-Klick auf einen Schalter starten konnte und kein Endgerät dafür brauchte. Dazu hatte ich einfach bei den kritischen Devices folgenden Befehl ergänzt (node-sonos-http-api).
Leider funktioniert dies im neuen Script nicht mehr und mir erschließt sich auch nicht, wo diesmal die Raumnamen etc herkommen. Desweiteren hatte ich am Ende des Scripts noch eine Sprachausgabe gesetzt, dass alle Geräte erfolgreich überprüft wurden. Kann mir bitte jemand helfen?
@Eldar,
ich habe keine Sonos-API im Einsatz deshalb kann ich da nicht mitreden. Aber ich kann Dir sagen von wo der Raumname herkommt. Alle Daten werden jetzt in einer Tabelle eingelesen und in Zeile 153 wird bei jedem device Durchlauf der Raumname ausgelesen.
@jeep,
danke für deine Antwort. Ich müsste wissen, wie der Ausdruck im Debug zustande kommt. Beim alten Skript wurden die Räume und Devices in …room… und …name… gespeichert. Man musste dann nur bei den kritischen Devices den unten geposteten Befehl ergänzen und das Skript hat mit …room… und …name… in der Sprachausgabe (vgl. unten) bewirkt, dass automatisch der Raum und Devicename eingesetzt wurde. Das hat hervorragend funktioniert. Auch jetzt habe ich den Befehl einfach schon mal bei den critical levels hinzugefügt. Funktioniert auch. Sobald ein Device unter den festgelegten Batteriewert fällt, kommt die Sprachausgabe. Toll wäre jetzt eben nur noch, dass er mir das Device auch sagt, indem er im Sprachbefehl den Platzhalter (früher …room… und …name…) entsprechend füllt. Ich hoffe, man versteht was ich meine…
@Eldar,
Ich verstehe schon was Du meinst.
eigentlich steht Name und Raumname immer noch in ‘name’ und ‘room’. Die Debug Ausgabe ist ein wenig formatierter, aber nimmt die Werte auch aus den beiden Variablen. Vielleicht kopierst Du ein größeres Stück Code hier damit ich sehe wo Du den Befehl eingebunden hast. Du kannst aber auch selbst ein bisschen Debug code vor Deiner Sprachausgabe stellen, z.B. print(name…’ '…room) sollte zeigen ob die Variablen gefüllt sind.
Okay, ich bin einen Schritt weiter. Folgendes habe ich hinzugefügt:
elseif
tonumber(batteryLevel) < critical then
local dots = formatString(name, room)
local tablecrit = string.format("%s %s, im Raum %s hat %s %s %% %s", sname, name, room, dots, batteryLevel, sym.crit)
local statuscrit= n..') '.. tablecrit
local htmlcrit = "<pre>".. statuscrit .. "</pre>"
local http = net.HTTPClient() http:request('http://192.168.178.36:5005/Fernseher/say/Batteriestatus%20'..sname..''..room..'nur%20noch%20'..batteryLevel..'%20Prozent/de-de/30');
if debugout then Debug('red', statuscrit) end
stathtml = stathtml .. htmlcrit
if pushactiv then
sendPush(statuscrit)
end
status = status .. statuscrit ..'\n'
table.insert(tdev, tablecrit )
Interessanterweise funktionieren aber nur die Befehle room, sname und batteryLevel. Sobald ich name (den Namen des Devices) dem String hinzufüge kommt keine Ansage mehr?! Ich kann mir also aktuell “nur” ansagen lassen, dass ein beispielsweise der Batteriestatus OG Treppe nur noch 25 Prozent beträgt…
elseif
tonumber(batteryLevel) < critical then
local dname = name -- Und im http request dname anstatt name ansagen lassen
local dots = formatString(name, room)
...
Prima! Ich könnte mir folgendes vorstellen - Du hast vor kurzem ein Update des Sonos-Systems gemacht und Sonos hat was an seiner API geändert. Vermutlich ist ‘name’ jetzt ein reserviertes Wort dass man nicht benutzen darf. Das hat mich ja auf die Idee mit dem dname gebracht.
Wegen den Leerstellen, da kann weder Sonos noch ich was, aber versuch doch mal ein Bindestrich oder Punkt in device Namen. Vielleicht schluckt er das.
Auf alle Fälle werde ich ‘name’ durch ‘dname’ in meiner nächsten Version abändern. Macht jetzt meines Erachtens mehr Sinn.
Hallo @jeep,
Danke für das Update!
Habe gleich mal,die deutsche Version bei mir aktiviert und festgestellt, dass die Umlaute sowohl im Mail als auch im Debugfenster nicht richtig angezeigt werden (siehe Screenshot).
Hab ich da bei meiner HC2 was falsch eingestellt?