ich habe im gesamten Haus an Fenstern und Türen Fibaro Fensterkontakte installiert sowie in den Kellerräumen und Bädern Wassersensoren. Die Geräte sind alle Batteriebetrieben, nur die Anzeigen des Batteriestandes scheinen nicht zu stimmen. Ein Beispiel, der Sensor der Eingangstüre hatte bis Freitag ca. 50% Batterieladung, seit heute werden wieder 100% angezeigt aber der Sensor reagiert nur noch jedes 2. oder 3. mal auf das öffnen der Türe. Ich gehe also davon aus das die Batterie sogut wie leer ist.
Kann man einen Rundruf starten um die Batterieanzeigen komplett aktualisieren zu lassen? Evlt. via LUA Script? Ich habe bereits via LUA den Bateriestand abgefragt aber im Beispiel der Eingangstüre sagt auch das Script das es 100% Ladung sind.
nein sie werden weiter “normal” im System angezeigt. Das einzige das sich ändert ist das nun die Batterieanzeige wieder bei 100% ist (auch wenn ich sie via LUA auslese) und sie nur noch ab und an funzen.
wenn die Batterieladung von 50% wieder auf 100% geht, ist es fast 100% tig das die Batterie tatsächlich am Ende ist.
Rundruf starten geht nicht, da Batteriegeräte dauernd in einem “deep sleep” Stadium sind. Werte werdem dem Controller (HC2)
immer zum wakeup Intervall übermittelt. Du könntest das wakeUp Intervall verkleinern, was sich aber negativ auf die
Batterielebensdauer auswirkt.
Aber ich habe auch schon Fälle gehabt wo Batterien innerhalb von 2 Tagen ihre 80% Ladung komplett verloren haben.
Andere arbeiten noch mit 20% Wochenlang tadellos.
Eine laufende Überwachung der Batterien ist deshalb sehr wichtig. Kannst Dir ja mal das hier anschauen. Vielleicht hilft es Dir
rechtzeitig fehlerhafte Geräte zu erkennen. https://www.siio.de/board/thema/und-noch-ein-batterie-check-scipt/page/6/#post-76046
so ein ähnliches Script habe ich mir auch schon zugelegt und etwas abgeändert … allerdings liest auch das Script die falschen Daten aus … ich bekomme also eine Mail mit 100% Batterie was ja definitiv nicht stimmt ;).
Das ist wirklich n bissl blöd, was bringt mir eine Batterieanzeige bei der ich nie weiß ob sie korrekt ist. Zumal auch so der Haken “Warne mich bei niedrigem Batteriestand” nie zum Einsatz kommt, da ja die Batterie angeblich voll ist.
Das Einzige was mir jetzt noch dazu einfällt wäre, ich lege für jedes Batteridings im Z-Wave Netzwerk eine Variable im HC2 an. Hier trage ich regelmässig (jede halbe Stunde z.B.) die aktuellen Batterie-stati (statusse? ^^) ein und vergleiche vorher mit den Werten welche schon in der Variable stehen. Wenn die Batterieladung nun also, wie durch ein Wunder, auf einmal größer ist als vorher und ich weiß ich habe die Batterie nicht gewechselt hätte ich so zumindest einen Hinweis wo etwas nicht stimmen kann. Das ist halt nur viel Tipparbeit, daher wäre ich über eine andere evlt. etwas simplere Idee auch dankbar :).
Hi,
die scripte können nur das auslesen was die Geräte beim letzten wakeUp übermittelt haben. Mehr nicht. Das heißt das Deine
Variablen auch keine anderen Werte bekommen. Wenn ein wakeUp Intervall auf 84000 steht, hast Du 24 Stunden den gleichen
Wert, den Du im 1/2 Stunde Rhythmus aktualisierst. Und dann der Vergleich jede 1/2 Stunde.
Das eine Batterie von wenig Ladung nach mehr Ladung springt, ist äußerst selten und vermutlich
den heißen Tagen geschuldet die wir in den letzten Wochen hatten.
Und der Haken “Warne mich bei niedrigen Batteriestand” funktioniert sehr wohl, ist aber sehr nervig da jede 10 Min. eine Mail
losgeschickt wird. Ich kenne Installationen mit knapp 100 Batteriedevices. Da würde das total nerven.
Ob Dir der Aufwand das Wert ist, musst Du selbst entscheiden.
ich habe nun mal einen Test gemacht und alle Batterien überprüft … ich habe insgesamt 21 Batterisensoren im Netzwerk bei 7 davon war die Batterie bereits komplett entladen wurde aber noch mit 80% oder 100% angezeigt :(. Das ist natürlich besonders bei Wassersensoren besonders ärgerlich da damit der komplette Sinn verlorgen geht :(. Wir hatten vor 2 Jahren einen Wassereinbruch im Keller wärend wir geschlafen haben. Das war der Ursprüngliche Grund für uns (und für die Budgetfreigabe der Frau ;)) uns hier “abzusichern”. Wenn ich mich nun aber nichteinmal darauf verlassen kann das die Geräte überhaupt noch Saft haben bin ich schon sehr verunsichert. Zumal die Geräte ja auch nichtmal als “nicht erreichbar” angezeigt werden sondern weiter “normal” zu sehen sind.
Ich denke ich frage einmal die Hotline an, evlt. ist es ja auch eine Einstellungssache.
@Jeep: ja klar der Haken funktioniert schon aber eben nicht wenn das System denkt das die Batterie noch zu 100% geladen ist ;).
obwohl ZWave schon über 10 Jahre Entwicklung auf dem Buckel hat, gibt es immer noch Schwachstellen im Design, so auch bei den Batteriegeräten. Aber nicht immer ist Fibaro oder Sigma Designs daran Schuld. Mit den Lithium-Ionen Batterien ist es auch so eine Sache. Die arbeiten fast bis zum letzten Atemzug und geben dann sporadisch den Geist auf. Das habe ich schon oft bemerkt - heute noch 75% und morgen 0%.
Genau hier liegt das Problem. Wenn das Gerät zwischen zwei wakeUp Intervallen ausfällt, bekommt man nichts mehr mit. Wenn man großes Glück hat, geht die Batterie während des letzten wakeUp in die Knie, da je mit dem Controller kommuniziert wird und Leistung verbraten wird.
Ich bastele gerade an einem Ansatz um dem Problem Herr zu werden. Aber ich bin noch nicht zufrieden. Zum Beispiel: Eine Batterie im Tür-/Fenstersensor fällt total aus. Das device wird sich nie mehr beim Controller melden, das hast Du ja mitbekommen mit Deinen 7 komplett entladenen Geräten. Fenster und Türen werden ja naturgemäß öfter mal geöffnet und bekommen den Status “Breached”. Ich habe jetzt in meinem Script das Attribut ‘lastBreached’ mit der aktuellen Zeit verglichen. Wird ein Fenster/Türsensor längere Zeit nicht geöffnet, oder Batterie leer, kann man eventuell daran erkennen (auch in der WEBGui) dass da was nicht stimmt. Bei Wasser- oder Rauchmelder steht aber hier meistens eine ‘0’ für “Never breached”, also Differenz zur aktuellen Zeit tausende Stunden. Obwohl meine Wasser und Rauchmelder bis jetzt immer korrekt den Batteriestatus wiedergeben (die verlieren pro Monat immer ein paar Prozent).
Der Vorteil, bei Tür/Fenster Sensoren, man man müsste nicht mehr die Batterie zum messen rausnehmen, nur einmal die Tür öffnen würde reichen. Für Fernbedienungen ist dieser Ansatz nicht brauchbar, aber das bekommt man ja zeitnah mit.
Würde dann so wie screenshot aussehen.
hm verstehe … dann ist das aber wirklich ein grundlegendes Problem.
Haben denn die Sensoren überhaupt keine Möglichkeit von extern “geweckt” zu werden? Funken können sie ja also müsste es doch auch eine Möglichkeit der Abfrage geben, und sei es nur “was ist deine ID” … irgendetwas damit man eine Reaktion erwarten und somit auswerten kann?
Dein Ansatz ist interessant, ich habe mir heute etwas Ähnliches überlegt. Ich habe mir eine Variablen ‘w_sensor_da1’ sowie ‘w_sensor_da2’ angelegt und nutze die Temperatur dafür, ich gehe davon aus das die Temperatur im Kommabereich über 12 Stunden nie gleich bleiben kann. Bei der ersten Temperaturerkennung wird die 1. Variable mit den Grad befüllt und in die 2. ein Timestamp geschrieben. Wenn sich nun innerhalb von 12 Stunden keine neue Temperatur “meldet” bzw. die Grad-Werte gleich geblieben sind gibt es eine Meldung via Mail. Die dauerhafte Abfrage löse ich mittels eine Unendlichschleife in einem LUA Script in welcher ich alle 12 Stunden die Temperatur abfrage … allerdings bin ich mir hier noch nicht so sicher was das für Auswirkungen auf die Performance des HC2 hat.
Das ist aber ziemlich von hinten durch die brust ins Auge gebastelt und nicht wirklich befriedigend.
Haben denn die Sensoren überhaupt keine Möglichkeit von extern „geweckt“ zu werden?
Nein…
allerdings bin ich mir hier noch nicht so sicher was das für Auswirkungen auf die Performance des HC2 hat.
Keine messbare. Vielleicht 0,5 % Last.
Bei den Fenstersensoren scheint es am Meisten Probleme mit der Batterieübertragung zu geben. Keine Ahnung warum, ist mir aber im Dauerbetrieb auch vermehrt aufgefallen.
