mein (derzeit) einziges Z-Wave-gerät (Fibaro CO-Sensor) wacht nur alle paar Stunden auf und schickt nur Daten, wen n sich was verändert hat. Wenn sich nichts geändert hat, wird auch keine Variable aktualisiert.
Gerade weil das Gerät nicht aktiv ansprechbar ist, ist es schwierig zu sagen, ob es überhaupt noch online ist.
Ich würde gerne einen Timestamp mit der letzten (erfolgreichen) Kommunikation haben bzw otimalerweise den Zeitpunkt der letzten Kommunikation und den Status der Kommunikation (also ok oder fail).
Dann könnte ich prüfen, ob seit der letzten Kommunikation mehr als WakeUpInterval Sekunden verstrichen sind und weis, das hier was hängt.
Ich habe mir bereits ZW_GetInformation() abgeschaut, das liefert aber nur indirekt eine Information (Erhöhung der NodeReceivedPacktes).
Gibt es da irgend eine Möglichkeit? Und wenn nicht, ist es vorstellbar, in einer zukünftigen IPS-Version eine entsprechende Möglichkeit einzubauen?
Ich werde zu den jeweiligen Countern den Zeitstempel hinzufügen, wann zuletzt inkrementiert wurde. Damit solltest du (denke ich) genug Informationen haben.
Hi,
ich benutze ZW_RequestStatus für einige meiner Geräte. Da wird wohl ein Notification Frame angefordert und dabei werden beim nächsten Aufwachen Variablen wie z.B. Batteriestatus neu geschrieben und die Änderung des Variablendatums prüfe ich einmal am Tag und die Zeitdifferenz muss <86400 Sekunden sein sonst stimmt was nicht.
ich hatte vorhin eine solchen ZW_RequestSttatus() aufgerufen. In der Warteschlange auf der Konfigurationsseite waren 11 Einträge .
das Z-Wave-Geräte hat sich inzwischen gemeldet
a) in der Warteschlage sind nun noch 10 Einträge, also nur ein Eintrag abgearbeitet
b) es wurde bisher keine Variable aktualisiert, die nicht sowieso aktualisiert wurde, bestimmte Variablen sind immer noch auf „Nie“
ich warte mal ab, bis die Queue komplett abgearbeitet ist, aber ich befürchte, das das Verhalten von Gerät zu Gerät ziemlich unterschiedlich ist.
Ich überwache meine Rauchmelder mit der „Variablenüberwachung“ aus dem Store.
Intervall: 86400 - also 24 Stunden.
Hier verwende ich die Temperatur die der Melder liefert.
Ob der CO-Sensor auch was passendes anbietet, weiß ich nicht, wäre aber interessant, da ich mich auch für den Sensor interessiere, aber erst brauche wenn der Holzofen steht.
ja die Temperatur wurde bisher anscheinend immer geändert und ( soweit meine Beobachtung ) auch die Batterieladung. Insofern kann man das Gerät wahrscheinlich genau darüber überwachen.
Das basiert aber alles darauf, das sich Daten ändern und von daher ist es pragmatisch aber nicht systematisch. Wenn der Hintergrund ist, das nur geänderte Daten übertragen werden (was zu meiner Beobachtung passt) würde das Gerät als verdächtig eigestuft, obwohl es ordentlich kommuniziert.
Mein Hintergrund war davon unabhängig anzusetzen und zu schauen, ob das Gerät korrekt kommuniziert hat.
Was mich etwas wundert ist, das er beim Aufwachen die Warteschlange nicht komplett abarbeitet sondern immer nur einen Eintrag. Ist das bei deinen Rauchmelder auch so?
Ob alle Einträge abgearbeitet werden, kann ich so jetzt auf die schnelle nicht nachvollziehen.
Die Melder haben bei mir ein WakeUp Intervall von 10800 eingestellt.
Manche Warteschlangen sind leer, bei einem ist noch ein „Optimize“ drin und bei einem „DeleteRoute“ und „AssignRoute“.
Soweit ist bei mir die Überwachung bis jetzt zuverlässig. Ansonsten bekomme ich eine Meldung.
Die Variable CO2 Level wurde bei aktualisiert. Daher habe ich mit Hilfe einer Kerze in einem Top erhöhten CO simuliert, der Wert stieg bis auf 64 und fiel nach Belüftung wieder bis auf 33 und bleib dort stehen.
Dann habe ich den CO-Sensor ordnungsgemäß via IPS abgelernt, auf Werkseinstellungen zurück gesetzt und wieder neu angelernt.
also viel weniger Variablen und bei Datenabruf bleibt er weiterhin bei RequestStatus28 hängen.
Da ich wenig bis nix von Z-Wave verstehe frage ich mich, ob das bedeutet, das der Sensor einen Defekt hat.
Sehr irritierend ist auch, das die Batterie nach einer guten Woche an Betrieb schon auf 20% gefallen ist. Klar habe ich einiges damit romprobiert und häufiger mal ein WakeUp gemacht. Ist aber trotzdem überraschend.
Das sieht nach einem Bug vom Gerät aus. Wir fragen die 28 ab, aber er liefert trotzdem den falschen Sensorwert… Das wird also nie was. Magst du mir mal vom Laden einen Debug hier hochladen. Dann kann ich versuchen da eine Ausnahme zu bauen, sodass wir die MultiSensor Werte nicht abfragen.
Meinst du, das ist ein genereller Bug? Zuerst fragt er den SensorMultilevel01 ab (Temperatur) und hat damit kein Problem, der Wert wird auch laufend aktualisiert.
Beim 1. Anmelden hat er ja deutlich mehr Werte / Variablen erzeugt als beim 2. mal. Ich bin fast davon ausgegangen, das das Gerät selbst einen Defekt hat und würde es reklamieren.
Es gibt ja zudem auch diesen „Sensoralarm (Generell)“, der auf true steht. Hatte mal versucht Infos zu den Kanälen/Messwerten aus dem Fibaro-Forum zu bekommen, aber noch nix gekommen.
Ich vermute eher ein generelles Problem. Die Fibaro Geräte haben da gerne mal Bugs die dann nie behoben werden. Evtl. kann ein Firmware Update dort „helfen“, aber dafür benötigst du ein HC2 von denen und auch dann kann es sein, dass der Fehler weiterhin besteht. Ich kann das Gerät einfach auf die Ignore Liste für die Klasse setzen - damit würden immerhin die restlichen Klassen korrekt abgefragt werden und du hättest keine Leichen in dier Queue.
ok, dann machen wir das so.
wovon brauchst den debug? ich habe von der neuen Instand den Debug kurz nach dem anlegen (heute Vormittag). und von der alten Instanz seit vorgestern. Die beiden sind angehängt
Oder soll ich noch etwas testen?