letzte Kommunikation eines Z-Wave-Gerätes

Hallo,

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?

Gruß
demel

Ich werde zu den jeweiligen Countern den Zeitstempel hinzufügen, wann zuletzt inkrementiert wurde. Damit solltest du (denke ich) genug Informationen haben.

paresy

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.

Ralf

prima

demel

Hallo

probier ich mal aus, aber ich hatte das Gefühl, das er auch dann nur eingeschränkt Variablen schickt.
in spätestens 6 Stunden weis ich mehr …

demel

Hallo,

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.

Gruß
demel

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.

Grüße
Stefan

Hallo,

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?

demel

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.

Hier mein Meldeskript:

$status = getvalueboolean(IPS_GetVariableIDByName('STATE',IPS_GetParent($_IPS['SELF'])));
$name = IPS_GetName(IPS_GetParent($_IPS['VARIABLE']));
$config = json_decode(IPS_GetConfiguration(IPS_GetParent($_IPS['SELF'])),TRUE);

if($config['Active'] == TRUE){
    if ($status == false){
	PushNotification(52516, 'Info', $name.' OK', '', 0);
    }
    else{
	PushNotification(52516, 'Fehler', $name.' Fehler', '', 0);
    }
}

Ist aber für Variablenüberwachung(Group) mit Links unterhalb der Variablenüberwachung.

Grüße
Stefan

Hallo,

die Abfragen nach Werte bleiben immer wieder hängen bei der Abfrage von RequestStatus28

17.02.2020 11:29:28 | HEX | WakeUp |
17.02.2020 11:29:28 | TXT | (S) ZWaveSensorMultilevel::RequestStatus01 | 1<EOT><SOH><NUL>
17.02.2020 11:29:28 | HEX | (S) ZWaveSensorMultilevel::RequestStatus01 | 31040100
17.02.2020 11:29:29 | TXT | ® Class (31): SENSOR_MULTILEVEL | <ENQ><SOH>"<NUL><F9>
17.02.2020 11:29:29 | HEX | ® Class (31): SENSOR_MULTILEVEL | 05012200F9
17.02.2020 11:29:29 | TXT | (S) ZWaveSensorMultilevel::RequestStatus28 | 1<EOT>(<NUL>
17.02.2020 11:29:29 | HEX | (S) ZWaveSensorMultilevel::RequestStatus28 | 31042800
17.02.2020 11:29:29 | TXT | ® Class (31): SENSOR_MULTILEVEL | <ENQ><SOH>"<NUL><F9>
17.02.2020 11:29:29 | HEX | ® Class (31): SENSOR_MULTILEVEL | 05012200F9
17.02.2020 11:29:30 | TXT | (S) ZWaveSensorMultilevel::RequestStatus28 | Retry #1 | 1<EOT>(<NUL>
17.02.2020 11:29:30 | HEX | (S) ZWaveSensorMultilevel::RequestStatus28 | Retry #1 | 31042800
17.02.2020 11:29:30 | TXT | ® Class (31): SENSOR_MULTILEVEL | <ENQ><SOH>"<NUL><F9>
17.02.2020 11:29:30 | HEX | ® Class (31): SENSOR_MULTILEVEL | 05012200F9
17.02.2020 11:29:32 | TXT | (S) ZWaveSensorMultilevel::RequestStatus28 | Retry #2 | 1<EOT>(<NUL>
17.02.2020 11:29:32 | HEX | (S) ZWaveSensorMultilevel::RequestStatus28 | Retry #2 | 31042800
17.02.2020 11:29:32 | TXT | ® Class (31): SENSOR_MULTILEVEL | <ENQ><SOH>"<NUL><F9>
17.02.2020 11:29:32 | HEX | ® Class (31): SENSOR_MULTILEVEL | 05012200F9
17.02.2020 11:29:33 | TXT | (S) ZWaveSensorMultilevel::RequestStatus28 | Retry #3 | 1<EOT>(<NUL>
17.02.2020 11:29:33 | HEX | (S) ZWaveSensorMultilevel::RequestStatus28 | Retry #3 | 31042800
17.02.2020 11:29:33 | TXT | ® Class (31): SENSOR_MULTILEVEL | <ENQ><SOH>"<NUL><F9>
17.02.2020 11:29:33 | HEX | ® Class (31): SENSOR_MULTILEVEL | 05012200F9
17.02.2020 11:29:34 | TXT | (S) WakeUpComplete | <84><BS>
17.02.2020 11:29:34 | HEX | (S) WakeUpComplete | 8408
17.02.2020 11:31:30 | TXT | ® Class (31): SENSOR_MULTILEVEL | <ENQ><SOH>"<SOH><EOT>
17.02.2020 11:31:30 | HEX | ® Class (31): SENSOR_MULTILEVEL | 0501220104
17.02.2020 11:34:36 | TXT | ® Class (84): WAKE_UP | <BEL>
17.02.2020 11:34:36 | HEX | ® Class (84): WAKE_UP | 07
17.02.2020 11:34:36 | TXT | WakeUp |

Ist das „normal“? Das Verhalten ist reproduzierbar.

Ich habe den Sensor vor einigen Tagen angelernt und habe nach einigem hin- und her folgende Variable

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.

Das Ergebnis ist wie folgt

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.

demel

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.

paresy

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.

gruß
demel

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.

paresy

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?

demel

fib-co-alt.txt (23.7 KB)

fib-co-neu.txt (32.1 KB)

Vom Drücken auf „Laden“ benötige ich einen. Eigentlich nur den Teil, wo doe ProductID ect übermittelt wird.

paresy

alles klar,

ich habe sowohl „Laden“ einmal durchgeführt als auch „Aktualisieren“ (2. Debugfile).

Nach dem RequestInfo hat er übrigens dann alle Variablen angelegt. Wahrscheinlich hatte ich bei der Ersteinrichtung unter anderem Laden ausgelöst :confused:

danke
demel

fib-co_RequestStatus.txt (3.84 KB)

fib-co_RequestInfo.txt (23.3 KB)

Ist hinzugefügt für die 28. Ein anderes Gerät aus der selben Produktreihe habe ich schon als Ausnahme drin :wink:

paresy

Super!

ist das dann in der nächsten 5.4 drin oder geht das mit Z-Wave einen anderen Weg?

demel

Ja, der Fix kommt erst zur 5.4 mit. Ggf. kommt dies dann noch zur 5.3 später.

paresy