...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):
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_LOCALLYDer passende Logfile Auszug um de Zeitpunkt des transmit NO_ACK mit verbose 5:
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:033003ffIm alten Thread gab krikan einen tollen Hinweis:
Zitat
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. :-\
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.
Andreas/Christian: Wie waers mit einem Attribut "noWNMI"?
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") ;D
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!
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.
Hi,
Zitat von: vga am 27 Februar 2016, 15:23:16
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...
ZWDongle_Write 0013190284082519 (d344759d)
Gruß,
Andreas.
Zitat von: rudolfkoenig am 27 Februar 2016, 15:18:02
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.