Aeon Labs Z-Wave Multisensor 6 (AEOEZW100) Probleme beim Anlernen

[rudolfkoenig]

Warum?

Weil eine Nachricht per Ack zu bestaetigen Senden bedeutet, was mehr Strom benoetigt als Empfangen.
Die Frage ist, wieviel mehr, bzw. wie lange bleiben die Geraete wach. Ich gehe davon aus (Bauchgefuehl), dass eine Sekunde Ersparnis sich nicht lohnt. Offensichtlich gehen manche Geraete vorher schon schlafen, da lohnt sich WNMI sicher nicht.
Christian: gibts irgendwo eine Tabelle/Bericht/Erfahrungswert, wie lange Geraete wach bleiben?

Fuer ein Berechnen der WNMI Intervalls fuehle ich mich noch nicht sicher genug, ich wuerde bei default+Attribut bleiben, wie jetzt.

[scooty]

Hallo zusammen,

erst einmal vielen Dank für die Antworten, klaren Erläuterungen und WNMI-Diskussion, sehr aufschlussreich für mein Verständnis und soweit habe ich das hoffentlich auch kapiert. 

1.) kann ich nicht sagen, bei mir läuft das Ding momentan nur Batteriebetrieben.

Perfekt, genau das versuche ich herauszufinden. Schickt der Sensor bei Dir im Batterie-Betrieb seine Daten abhängig von den

Code Auswählen Erweitern

configGroupxInterval
configxxxReportingThreshold
Einstellungen oder nur bei einem Wakeup?

Hattest Du heute morgen ein Update gemacht?

Ja, Update hatte ich gemacht, die No_ACKs traten aber auch schon die Vortage auf.

Eine offene Frage bleibt mir noch (oder ich habe den Zusammenhang zu den bisherigen Antworten übersehen) zu den folgenden Log-Einträgen:

Code Auswählen Erweitern

2016.02.15 16:24:12.670 1: ZWave_SENSOR_MULTILEVEL_82: secDecrypt: Authentification code not verified, command 3b60ba1866 will be dropped!
2016.02.15 16:24:14.356 2: ZWDongle_ProcessSendStack: no ACK, resending message 01110013520a9880e96cd683ac155df9255207
2016.02.15 16:24:14.410 1: ZWave_SENSOR_MULTILEVEL_82: secDecrypt: Authentification code not verified, command dfec55 will be dropped!
2016.02.15 16:24:15.487 2: ZWDongle_ProcessSendStack: no ACK, resending message 01110013520a98807d69ca69a23625012552cd
2016.02.15 16:24:15.544 1: ZWave_SENSOR_MULTILEVEL_82: secDecrypt: Authentification code not verified, command 5f0cc9dd835e will be dropped!
2016.02.15 16:24:15.693 1: ZWave_SENSOR_MULTILEVEL_82: secDecrypt: Authentification code not verified, command f5c450f5fe will be dropped!
2016.02.15 16:24:15.694 1: ZWave_SENSOR_MULTILEVEL_82: first frame of message (sequence 01) for decryption not found!
2016.02.15 16:24:16.807 2: ZWDongle_ProcessSendStack: no ACK, resending message 01110013520a9880f6e6c2fc3e12567e2552e0

Vielen Dank bisher,
Andreas

[krikan]

Weil eine Nachricht per Ack zu bestaetigen Senden bedeutet, was mehr Strom benoetigt als Empfangen.

Wenn ich Paetz 2.Aufl. / http://wiki.zwaveeurope.com/index.php?title=Z-Wave_Application_Layer#Battery_operated_devices (=Paetz 1.Aufl?) vertraue, ist das bei aktuellen Chipsätzen nur minimal unterschiedlich.

Die Frage ist, wieviel mehr, bzw. wie lange bleiben die Geraete wach. Ich gehe davon aus (Bauchgefuehl), dass eine Sekunde Ersparnis sich nicht lohnt. Offensichtlich gehen manche Geraete vorher schon schlafen, da lohnt sich WNMI sicher nicht.

Also die Sekundärquellen Paetz/Z-way und Co. sprechen immer von wenigen Sekunden bis eine Minute nach WakeupNotification; jeweils geräteindividuell implementiert. Abfragemöglchkeiten sind mir noch keine begegnet. Zudem wird immer wieder darauf hingewiesen, dass nach Inklusion ein längere Wachzeit von mehreren Minuten auftitt; einzelne Geräte gehen dann auch nur nach explizitem WNMI in den Schlafzustand. Auch wird immer wieder auf die Notwendigkeit von WNMI zur Batterieschonung hingewiesen.
Auch die zwapi weisen immer wieder auf die Notwendigkeit von WNMI hin.
Alles bleibt recht oberflächlich ohne wirklich genaue Angaben der Auswirkungen; vermutlich zu sehr von Gerät und Chipsatz abhängig.

gibts irgendwo eine Tabelle/Bericht/Erfahrungswert, wie lange Geraete wach bleiben?

Mir nicht bekannt. Nur das obige.
Kann natürlich auch meine eigenen einmal testen. Aus der Erinnerung: der Philio-Mehrfachsensor ist mehrere Sekunden wach, wenn WMNI fehlt.

Fuer ein Berechnen der WNMI Intervalls fuehle ich mich noch nicht sicher genug, ich wuerde bei default+Attribut bleiben, wie jetzt.

Eigentlich halte ich das auch für unnötig.
Problemgerät ist doch definitiv nur der hier angesprochene Multisensor 6. Alle anderen scheinen mit den derzeitigen Einstellungen relativ problemlos zu funktionieren. Das Attribut WNMI_delay wurde hier im Forum laut Suchfunktion nur noch 2 Mal bei anderen Geräten vorgeschlagen. Ein Fazit gibt es dort jeweils aber nicht, so dass ich dort erst einmal von einer anderen Ursache ausgehe. Das TRANSMIT_NO_ACK bei Wakeup-Geräten häufiger auftreten als bei netzgebundenen Geräten finde ich "normal".

Eine einfache (?) Optimierung kann ich mir momentan nur hinsichtlich der angenommen Wachzeit nach der letzten Nachricht eines WakeUp-Gerätes vorstellen. Bisher geht Fhem von einer fixen Zeit aus. Hier könnte man zur Sicherheit vor dem Versand einer Nachricht nach x Zeit eine NO_OP-Nachricht verschicken und nur nach einem erfolgreichen ACK vom WakeUp-Gerät die tatsächliche Nachricht verschicken. Das NO_OP sollte die Wachzeit dann auch automatisch verlängern. Aus der Erinnerung macht ozw so etwas. Ich müsste ich mir das aber am Wochenende noch mal bei ozw und z-way-Logs genauer anschauen. Es ist schon länger her, dass ich mich damit auseinandergesetzt habe. Notwendigkeit einer solchen Codeänderung bezweifel ich erst einmal.

@Andreas (beide!): Welche Firmware-Version hat Euer Sensor. Habt ihr beide die alte Firmware? Nicht dass wir ein kaputte Firmware als Grundlage eines Umbaues nehmen. Mein Multisensor ist auf aktueller 1.06 Firmware. Müsste mir mal eine Batterie zum Testen besorgen, falls ihr alte Stände habt.

[A.Harrenberg]

Hi Andreas,

Perfekt, genau das versuche ich herauszufinden. Schickt der Sensor bei Dir im Batterie-Betrieb seine Daten abhängig von den

Code Auswählen Erweitern

configGroupxInterval
configxxxReportingThreshold
Einstellungen oder nur bei einem Wakeup?

hmm, das müsste ich mich dann mal anschauen, das Ding steht ja nur für Experimente bei mir auf dem Tisch rum. Habe noch nie so genau geschaut wann der was sendet...
Ich schau erst mal auf was der eingestellt ist und versuche dann mal nachzuvollziehen wann der sendet.

Eine offene Frage bleibt mir noch (oder ich habe den Zusammenhang zu den bisherigen Antworten übersehen) zu den folgenden Log-Einträgen:

Code Auswählen Erweitern

2016.02.15 16:24:12.670 1: ZWave_SENSOR_MULTILEVEL_82: secDecrypt: Authentification code not verified, command 3b60ba1866 will be dropped!
2016.02.15 16:24:14.356 2: ZWDongle_ProcessSendStack: no ACK, resending message 01110013520a9880e96cd683ac155df9255207
2016.02.15 16:24:14.410 1: ZWave_SENSOR_MULTILEVEL_82: secDecrypt: Authentification code not verified, command dfec55 will be dropped!
2016.02.15 16:24:15.487 2: ZWDongle_ProcessSendStack: no ACK, resending message 01110013520a98807d69ca69a23625012552cd
2016.02.15 16:24:15.544 1: ZWave_SENSOR_MULTILEVEL_82: secDecrypt: Authentification code not verified, command 5f0cc9dd835e will be dropped!
2016.02.15 16:24:15.693 1: ZWave_SENSOR_MULTILEVEL_82: secDecrypt: Authentification code not verified, command f5c450f5fe will be dropped!
2016.02.15 16:24:15.694 1: ZWave_SENSOR_MULTILEVEL_82: first frame of message (sequence 01) for decryption not found!
2016.02.15 16:24:16.807 2: ZWDongle_ProcessSendStack: no ACK, resending message 01110013520a9880f6e6c2fc3e12567e2552e0

Oh, das war mir in den Logfiles nicht aufgefallen... Da ist (mindestens) ein Paket nicht sauber empfangen worden, oder die NONCE sind durcheinander gekommen, wahrscheinlich eher letzteres. Dadurch konnte das Paket nicht als gültig erkannt werden und wurde verworfen. Anscheinend hat es sich dabei um den ersten Teil einer langen, zweigeteilten Nachricht gehandelt, worauf dann beim Eintreffen der zweiten Hälfte auch nichts mehr ging.

Das hängt wahrscheinlich alles damit zusammen das die NONCE Anfragen vom Geräte nicht beantwortet wurden. Warum das passiert kann ich momentan nicht sagen und werde da in den nächsten Tagen leider auch nicht wirklich dazu kommen.

Gruß,
Andreas.

[scooty]

Hallo Andreas,

kein Thema, alles nicht zeitkritisch.

Welche Firmware-Version hat Euer Sensor. Habt ihr beide die alte Firmware?

@Christian:
die Frage, die jetzt kommt, kannst Du Dir sicherlich vorstellen  : Wie finde ich die aktuelle Firmware raus?

Andreas

[krikan]

Hallo Andreas!

Wie finde ich die aktuelle Firmware raus?

Kannst Du mit

Code Auswählen Erweitern

get <device> version
abrufen.

Meiner hat 1.06, d.h. die letzte von AEOTEC auf der Homepage veröffentlichte:
Reading:

Code Auswählen Erweitern

version Lib 3 Prot 4.5 App 1.6 HW 100 FWCounter 0
Was als App (Application Version) ausgewiesen ist, soll in V2 der CC Version die Firmwareversion sein.

Gruß, Christian

[scooty]

Hallo Christian,

doch so einfach diesmal  .

Gerade geprüft, FW ist auf meinen Sensoren auch die 1.06.

Andreas

[krikan]

Gerade geprüft, FW ist auf meinen Sensoren auch die 1.06.

Danke. Wäre ja auch zu einfach gewesen. Aus Neugierde werde ich mir mal Batterien besorgen...

[A.Harrenberg]

Hi,

ich habe V1.6 und das Ding sendet anscheinend nur bei WakeUp.

Habe WakeUp auf 240 sek gestellt und configGroup1Interval auf 90, die Werte kommen alle 4 min...

Gruß, Andreas.

[krikan]

ich habe V1.6

Jetzt verstehe ich nichts mehr  . Hattest Du nicht eine alte Firmwareversion und wolltest das Update später machen, um den Updateprozeß nachzuvollziehen? Muss man die Firmwareversion evtl. doch anders ermitteln als mit "get <device> version"?
Gruß, Christian

[A.Harrenberg]

Hi Christian,

äh, jetzt wo Du es sagst... Ich hatte gar nicht darauf geachtet, aber dann habe ich wohl schon die neueste Version drauf und kann es gar nicht mehr laufen lassen.

Bzw. jetzt könnte ich es auch einfach ausprobieren, entweder es geht gar nicht oder es geht immer ,-)

Gruß,
Andreas.

P.S.: Die Logik mit 1.6 und 1.06 verstehe ich aber nicht so ganz...

[krikan]

P.S.: Die Logik mit 1.6 und 1.06 verstehe ich aber nicht so ganz...

Kannst Du in den Raw-Telegrammen erkennen: Raw-Wert ist 06, der (interpretationsbedürftig) als .6 ausgeben wird; Raw-Wert 60 sollte dann .60 als "eigentliche" 1.60 sein. Hoffe ist verständlich. Diese Interpretationsbedürftigkeit existiert in den kompletten version-Abfragen: Prot 4.5 musst Du in den Übersetzungstabellen als 4.05 suchen. Und ich befürchte, daran bin ich nicht ganz unschuldig...

[A.Harrenberg]

Hi,

ok, gerade zwei mal upgedatet ,-) Geht also immer wieder...

Gruß,
Andreas.

[krikan]

ok, gerade zwei mal upgedatet ,-) Geht also immer wieder...

Und warum ging das bei mir kein 2. Mal? Muss ich wohl auch noch mal probieren..

[scooty]

das Ding sendet anscheinend nur bei WakeUp.
Habe WakeUp auf 240 sek gestellt und configGroup1Interval auf 90, die Werte kommen alle 4 min...

Danke für's Ausprobieren und Bestätigen, nicht so prickelnd für meinen Einsatzzweck, aber vielleicht gibt's noch Hoffnung auf eine neue Firmware:

My last communication with Aeotec was that he'd let me know if he hears back from Engineering to see if they can 'fix' this in firmware and allow the non-motion sensors to report based on a Parameter setting even when on Battery.

Siehe hier ff. (letzte Änderung 21.01.2016).

Andreas