AeoTech MultiSensor6 - state: TRANSMIT_NO_ACK

[vga]

...das Problem habe ich in einem anderen Thread schon aufgegriffen, doch um es übersichtlicher zu machen, gliedere ich das Problem in diesen extra Thread aus.

Hier eine kurze Zusammenfassung:

Folgendes enthält "List AeoTechMS" (ist ein AeoTech MultiSensor6):

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        d344759d 25
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     399
   NAME       AeoTechMS
   NR         1425
   STATE      TRANSMIT_NO_ACK
   TYPE       ZWave
   ZWAVE1_MSGCNT 399
   ZWAVE1_RAWMSG 000400190a7105000000ff07000000
   ZWAVE1_TIME 2016-02-27 14:37:14
   homeId     d344759d
   isWakeUp   1
   lastMsgSent 1456578276.72652
   nodeIdHex  19
   Readings:
     2016-02-26 22:22:03   CMD             ZW_APPLICATION_UPDATE
     2016-02-27 14:37:14   alarm           HomeSecurity: Previous Events cleared, arg 0000
     2016-02-27 14:37:14   basicSet        00
     2016-02-27 14:04:36   battery         100 %
     2016-02-26 22:20:35   configBatteryReportingThreshold 10
     2016-02-26 22:20:35   configCommandOptions BasicSetDefault
     2016-02-26 22:20:35   configEnableDisableLockConfiguration Disable
     2016-02-26 22:20:35   configEnableMotionSensor EnabledLevel5MaximumSensitivity
     2016-02-26 22:20:35   configGroup1Interval 3600
     2016-02-26 22:20:35   configGroup1Reports 241
     2016-02-26 22:20:35   configGroup2Interval 3600
     2016-02-26 22:20:36   configGroup2Reports 0
     2016-02-26 22:20:38   configGroup3Interval 3600
     2016-02-26 22:20:38   configGroup3Reports 0
     2016-02-26 22:20:38   configHumidityCalibration 0
     2016-02-26 22:20:41   configHumidityReportingThreshold 10
     2016-02-26 22:20:42   configTemperatureCalibration 0
     2016-02-26 22:20:44   configTemperatureReportingThreshold 20
     2016-02-26 22:20:46   configUVReportingThreshold 2
     2016-02-26 22:20:48   configWakeUp10MinutesOnPowerOn No
     2016-02-26 22:19:03   config_9        256
     2016-02-27 14:04:35   humidity        33 %
     2016-02-27 14:04:36   luminance       69 Lux
     2016-02-26 22:20:34   model           Aeotec MultiSensor 6
     2016-02-26 22:20:34   modelConfig     aeotec/multisensor6.xml
     2016-02-26 22:20:34   modelId         0086-0002-0064
     2016-02-27 14:04:43   state           TRANSMIT_NO_ACK
     2016-02-27 14:04:34   temperature     19.7 C
     2016-02-27 14:04:43   transmit        NO_ACK
     2016-02-27 14:04:36   ultraviolet     0 UV
     2016-02-27 14:04:36   wakeup          notification
Attributes:
   IODev      ZWAVE1
   WNMI_delay 0.3
   classes    ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL ALARM WAKE_UP BATTERY SENSOR_BINARY SENSOR_MULTILEVEL CONFIGURATION FIRMWARE_UPDATE_MD MARK DEVICE_RESET_LOCALLY

Der passende Logfile Auszug um de Zeitpunkt des transmit NO_ACK mit verbose 5:

Code Auswählen Erweitern

2016.02.27 14:04:37 5: ZWDongle_Write 0013190284082519 (d344759d)
2016.02.27 14:04:37 5: SW: 010900131902840825194e
2016.02.27 14:04:37 5: ACK received, WaitForAck=>2 for 010900131902840825194e
2016.02.27 14:04:37 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.02.27 14:04:37 5: SW: 06
2016.02.27 14:04:37 5: ZWAVE1 dispatch 011301
2016.02.27 14:04:39 4: no response from device, removing 010900131902840825194e from dongle sendstack
2016.02.27 14:04:43 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00131901
2016.02.27 14:04:43 5: SW: 06
2016.02.27 14:04:43 5: ZWAVE1 dispatch 00131901
2016.02.27 14:04:43 4: ZWAVE1 CMD:ZW_SEND_DATA ID:01 ARG:
2016.02.27 14:04:43 2: ZWAVE1 transmit NO_ACK for 19
2016.02.27 14:09:30 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004001b033003ff
2016.02.27 14:09:30 5: SW: 06
2016.02.27 14:09:30 5: ZWAVE1 dispatch 0004001b033003ff
2016.02.27 14:09:30 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:1b ARG:033003ff

Im alten Thread gab krikan einen tollen Hinweis:

Der hat laut Forum ein Problem mit zu schnellem Einschlafen. Als Lösungsmöglichkeit wurde speziell das Attribut WNMI_delay eingeführt. Das solltest Du mal im passenden Thread suchen.

Daraufhin habe ich den WNMI_delay auf 0.3 (auch 0.2 getestet) geschraubt. (wie man im AeoTechMS List sehen kann)

Leider hat sich aber nichts am Zustand geändert und ich bin weiterhin ratlos. 

[A.Harrenberg]

Hi,

auch hier noch mal der Hinweis das diese Meldung "harmlos" ist. Das Gerät schläft ein bevor die Nachricht verschickt um das Gerät schlafen zu schicken.

Ich werde mal schauen ob man für diesen speziellen Fall die "Fehlermeldung" unterdrücken kann. Das hat keinerlei Auswirkungen auf die Funktion. In der Nachricht die verschickt werden soll ist ein "8408" drin, das sagt "geh schlafen". Das Gerät ist aber bereits eingeschlafen und antwortet darauf nicht (mehr).

Solange das nur beim verschicken dieser Nachricht auftaucht kannst Du das getrost ignorieren.

Gruß,
Andreas.

[rudolfkoenig]

Andreas/Christian: Wie waers mit einem Attribut "noWNMI"?

[vga]

Danke nochmal für dein Hinweis.
Dann werde ich das nun einfach damit abhaken. 
Ist ja auch gut wenn dieser NO_ACK Status wahrheitsgetreu wiedergegeben wird!
(Wenn sich der Status programmtechnisch nur auf diesen Fall eingrenzen lässt, vielleicht einfach noch den Hinweis: "already_in_SleepMode")

Dachte der Grund könnte vielleicht noch etwas anderes sein, aber dann würde die Logfile sicher noch etwas anderes hergeben nehme ich an.
Vielen Dank!

[A.Harrenberg]

Hi Rudi,

ach Du willst gleich einen Schritt weitergehen und die Nachricht gar nicht mehr verschicken? Nach welcher Zeit soll denn dann der WU-Stack aktiviert werden?

Bin da noch unentschlossen. Ich fände es "gefühlt" schöner wenn die WNMI noch versand werden würde, kann dafür aber keine technische Begründung liefern, da mMn keine existiert...

Ich muss mir das bei meinem Sensor aber noch mal genauer anschauen, mir ist nämlich gerade eingefallen das wir ja auch auf das APPLICATION_UPDATE reagieren als wäre es eine WUN. Vielleicht mag der Sensor nicht, bzw. mag dann nicht schlafen geschickt werden wenn er offiziell gar nicht aufgewacht ist...

Gruß,
Andreas.

[A.Harrenberg]

Hi,

Dachte der Grund könnte vielleicht noch etwas anderes sein, aber dann würde die Logfile sicher noch etwas anderes hergeben nehme ich an.

dazu müsstest Du Dein Logfile mal durchforsten und schauen ob bei den NO_ACK die letzte Nachricht immer diese 028408 ab der Position 7 enthält. Falls da auch andere Nachrichten dabei sind DANN ist es ein Problem...

Code Auswählen Erweitern


ZWDongle_Write 0013190284082519 (d344759d)


Gruß,
Andreas.

[krikan]

Andreas/Christian: Wie waers mit einem Attribut "noWNMI"?

Als schnelle Lösung wäre das vermutlich eine einfache Variante. Wirklich überzeugt bin ich davon nicht, da wir dann schon die 2. Spezialität neben WNMI_delay aufgrund eines einzelnen Sensor haben. Eine Alternative habe ich aber auch derzeit nicht parat.