Probleme mit Fibaro FGMS001- NO_ACK

Begonnen von Mitch, 30 Oktober 2015, 08:59:13

Vorheriges Thema - Nächstes Thema

Mitch

Hallo Zusammen,

habe seit ein paar Tagen eine Fibaro FGMS001.
Läuft soweit gut, allerdings meldet er jede Nacht NO_ACK.
Wenn ich einen Tamper auslöse, geht er wieder.

Trotzdem meldet er Bewegung ohne Probleme.

Was könnte das sein?
FHEM im Proxmox Container

krikan

Ohne Details kann man/ich nur raten.
Liefere bitte mal Details: list, log in dem Fehler dokumentiert ist, ... http://www.fhemwiki.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F
Gruß, Christian

Mitch

Hier das Device:

Internals:
   .eventMapCmd nein:noArg Bewegung:noArg
   DEF        cfe3bfce 3
   IODev      ZWDongle
   LASTInputDev ZWDongle
   MSGCNT     811
   NAME       ZW_WZ_Kombisensor
   NR         807
   STATE      Motion: nein - Helligkeit: 2 Lux - Temperatur: 22.4 C
   TYPE       ZWave
   ZWDongle_MSGCNT 811
   ZWDongle_RAWMSG 0004000303200100
   ZWDongle_TIME 2015-10-30 08:58:49
   homeId     cfe3bfce
   lastMsgSent 1446190756.77085
   nodeIdHex  03
   CHANGETIME:
   Readings:
     2015-10-28 20:49:08   CMD             ZW_APPLICATION_UPDATE
     2015-10-29 22:59:50   alarm_type_00   level ff node 03 seconds 0
     2015-10-28 20:38:08   assocGroup_01   Max 05 Nodes 01
     2015-10-28 20:38:08   assocGroup_02   Max 05 Nodes
     2015-10-28 20:25:31   assocGroup_03   Max 01 Nodes 01
     2015-10-28 20:38:08   assocGroups     3
     2015-10-28 20:30:14   basicReport     ff
     2015-10-30 08:58:49   basicSet        00
     2015-10-28 20:25:34   battery         100 %
     2015-10-28 20:49:08   configAmbientIlluminationLevelAbove83 1000
     2015-10-28 20:49:09   configLEDBrightness 0
     2015-10-28 20:49:09   configLEDIndicatingTamperAlarm LEDIndicatesTamperAlarm
     2015-10-28 20:49:10   configLEDSignalingMode LongBlinkThenShortBlinkLEDColour10
     2015-10-28 20:43:03   configMaximumTemperatureResultingInRed87 25
     2015-10-28 20:43:03   configMinimumTemperatureResultingIn86 19
     2015-10-28 20:49:10   configMotionSensorSSensitivity 10
     2015-10-28 20:49:10   configNightDay  200
     2015-10-28 20:43:04   configTemperatureOffset 0
     2015-10-29 20:43:52   luminance       2 Lux
     2015-10-28 20:07:09   model           FIBARO System FGMS001 Motion Sensor
     2015-10-28 20:07:09   modelConfig     fibaro/fgms.xml
     2015-10-28 20:07:09   modelId         010f-0800-1001
     2015-10-30 08:58:49   reportedState   closed
     2015-10-30 08:58:49   state           closed
     2015-10-30 08:54:09   temperature     22.4 C
     2015-10-30 08:39:18   transmit        NO_ACK
     2015-10-30 08:39:16   wakeup          notification
     2015-10-28 20:43:04   wakeupReport    interval 7200 target 255
Attributes:
   DbLogExclude .*
   IODev      ZWDongle
   alias      Magic Eye
   classes    SENSOR_BINARY WAKE_UP ASSOCIATION BATTERY MULTI_CMD CRC_16_ENCAP MANUFACTURER_SPECIFIC VERSION CONFIGURATION MULTI_CHANNEL_ASSOCIATION SENSOR_MULTILEVEL SENSOR_ALARM BASIC
   eventMap   closed:nein open:Bewegung
   group      Magic Eye
   icon       im_eye2
   room       Homekit,Wohnzimmer
   stateFormat Motion: reportedState - Helligkeit: luminance - Temperatur: temperature
   verbose    3


Logs kann ich erst morgen liefern
FHEM im Proxmox Container

krikan

Bitte NodeId für wakeupNotification auf die ControllerNodeId setzen http://www.fhemwiki.de/wiki/Z-Wave#Wakeup-Ger.C3.A4te, wenn noch nicht geschehen.
Momentan sieht es laut Readings so aus, als ob der der Fibaro per Broadcast an 255 sendet:     
Zitat2015-10-28 20:43:04   wakeupReport    interval 7200 target 255
Vielleicht ist das schon das Problem.

Mitch

okay, habe ich geschickt, dauert halt bis ich Zuhause bin, bis es dort ist
FHEM im Proxmox Container

krikan

Zitat von: krikan am 30 Oktober 2015, 09:16:29
Vielleicht ist das schon das Problem.
Nach nochmaligen Nachdenken, bezweifel ich das es die Lösung ist. Ist trotzdem richtig und besser das zu ändern.
Tippe jetzt eher auf Empfangsprobleme, wenn NO_ACK regelmäßig auftritt. Aber auch das ist nur geraten, man müsste mal morgen ein log sehen und wissen worauf NO_ACK kommt.