Fibaro motion sensor FGMS001 Gen5 (Zwaveplus)

I’m having the same issue as several others in this thread. I’m on OH2 running on RPi3. I’m not getting any results on movement. The temperature and lux appear to work correctly.

This thread is well over a year old, so an awful lot has changed. If you are not using the latest snapshot, then please update.

I ran all of the updates using the config tool on my pi and I’m still having the same issue as other people in this thread. The temp and lux work fine, but I don’t get any response on motion.

Please provide debug logs showing what is received when there is motion. If nothing is received, then it is likely a device configuration or association issue on the device, but in this case, the binding can’t do anything if there is no message from the device.

Hi, I bought three of these devices. They worked as expected for 24 hrs or so, then motion alarms are not being reported. @chris, i understand you are maintaining the binding database. What logs if any would you like?


We don’t know anything about your setup, openHAB version, os version, … to give you an appropriate answer.
As you can read in many, many zwave threads a DEBUG log is needed. Please search the forum on how to do that.
Also please read How to ask a good question / Help Us Help You

The binding debug logs, although my guess is that it won’t help if the device has stopped sending data, but let’s check.

@chris , I´m currently running version OHv: 2.4.0~S1461-1. with binding-zwave - 2.4.0.SNAPSHOT.
I been reading through the fibaro “eye” posts here and it looks like i experience similar issues.

In my script im checking for when Item change.

Item H_KitchenSensor_Motion changed from OFF to ON

I have several motion detectors of another brand and they are working as expected.

As i mentioned in the OP, the fibaro device “FGMS001 Motion Sensor, zw5 v3.3 EU” report the status change when its added to the system and for some time, until its silence.

As for visual observation.
The eye initially flash green when motion and report event ON/OFF as expected.
Then the eye flashes amber when motion, and no report.
Today it flashed green again, how ever with nothing in the logs as of status change.

Debug logs from when i triggered motion this morning.

N/A no events

trying to force logs by resetting device.

[10:06:29] openhabian@openHABianPi:/var/log/openhab2$ tail -f /var/log/openhab2/openhab.log | grep "NODE 14"
2018-12-16 10:07:52.424 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Application Command Request (ALIVE:DONE)
2018-12-16 10:07:52.426 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: resetResendCount initComplete=true isDead=false
2018-12-16 10:07:52.430 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Is awake with 0 messages in the queue
2018-12-16 10:07:52.432 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Start sleep timer at 1000ms
2018-12-16 10:07:52.435 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got an event from Z-Wave network: ZWaveNodeStatusEvent
2018-12-16 10:07:52.460 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 14: Node Status event - Node is AWAKE
2018-12-16 10:07:52.463 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Commands processed 1.
2018-12-16 10:07:52.466 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@161d86d.
2018-12-16 10:07:52.934 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: WakeupTimerTask 0 Messages waiting, state DONE
2018-12-16 10:07:53.435 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: WakeupTimerTask 0 Messages waiting, state DONE
2018-12-16 10:07:53.438 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: No more messages, go back to sleep
2018-12-16 10:07:53.440 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 14: Creating new message for application command WAKE_UP_NO_MORE_INFORMATION
2018-12-16 10:07:53.443 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: SECURITY NOT required on COMMAND_CLASS_WAKE_UP
2018-12-16 10:07:53.447 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Command Class COMMAND_CLASS_WAKE_UP is NOT required to be secured
2018-12-16 10:07:53.450 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: sendTransaction org.openhab.binding.zwave.internal.protocol.transaction.ZWaveCommandClassTransactionPayload@103801c
2018-12-16 10:07:53.454 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Bump transaction 668 priority from Immediate to Immediate
2018-12-16 10:07:53.458 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Adding to device queue
2018-12-16 10:07:53.461 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Added 668 to queue - size 2
2018-12-16 10:07:53.472 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 14: Sending REQUEST Message = 01 09 00 13 0E 02 84 08 25 76 36
2018-12-16 10:07:53.550 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 14: sentData successfully placed on stack.
2018-12-16 10:07:53.556 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: TID 668: Transaction not completed
2018-12-16 10:07:53.662 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 14: SendData Request. CallBack ID = 118, Status = Transmission complete and ACK received(0)
2018-12-16 10:07:53.665 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: resetResendCount initComplete=true isDead=false
2018-12-16 10:07:53.671 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Response processed after 166ms
2018-12-16 10:07:53.674 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: TID 668: Transaction completed
2018-12-16 10:07:53.677 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: notifyTransactionResponse TID:668 DONE
2018-12-16 10:07:53.681 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2018-12-16 10:07:53.687 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Went to sleep COMPLETE
2018-12-16 10:08:00.759 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Application Command Request (ALIVE:DONE)
2018-12-16 10:08:00.763 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: resetResendCount initComplete=true isDead=false
2018-12-16 10:08:00.766 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Incoming command class COMMAND_CLASS_DEVICE_RESET_LOCALLY, endpoint 0
2018-12-16 10:08:00.769 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: SECURITY NOT required on COMMAND_CLASS_DEVICE_RESET_LOCALLY
2018-12-16 10:08:00.771 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 14: Received COMMAND_CLASS_DEVICE_RESET_LOCALLY V1 unknown command 1
2018-12-16 10:08:00.774 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Commands processed 1.
2018-12-16 10:08:00.777 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1b6846.

So the very interesting thing here is that the device is saying it has been locally reset to factory defaults, so in this case, it will likely have lost its configuration (eg the association configuration) and this would explain the problem.

(please also use code fences when pasting logs - or format with the </> button - I’ve edited your post to do this so that it’s readable).

@chris Yes as it was absolute silent i manually resat the device this morning. So if i understand you properly, your suggestion is to recreate the device motion item binding or to re add the device to the controller?

The thing i find most interesting is that it did work, and then “died” without any layer8 interaction.

As i mentioned I have several EYE´s so I suggest I add another one, leave debugging on and update the thread with findings.

Thank you for beautifying my post. Its been a while since I was active on forums.

What do you mean by “layer8”?

Yes, if the device is loosing its configuration, or at least, it’s stopped sending the alerts, then we need to find out why. Either the device is doing something by itself (ie there’s a device problem) or the binding is doing something. If it’s the binding, then we need to get the logs to find out where it’s going wrong. If it is working, then capture the logs until it stops working, then we need to find if there are any commands sent by the binding that might reconfigure the device (eg association changes).

Human interaction. OSI model Phun.

Ok. I will add one of the other eyes for testing and dump the logfiles. This may take a few days.

I will keep you posted with any findings.

1 Like

Ok, not come across that before - I like it :slight_smile:

1 Like

f001dbg.log (421.7 KB)
Added Node 19. Its behaving now and i am tailing the logfile in the backgroud for updates.

I get alarm notifications.

As agreed I will let this run for testing purposes. Its currently in a room where events are frequently triggered.
This is not the same device, but it had the same symptoms as the other two.

Please investigate the logfile attached for any abnormal behavior.

And when you find that :unicorn:, jump on it’s back and fly it over the :rainbow:! I’ve been chasing it for a couple years now!

Please don’t filter the logs - you remove all the useful stuff and I can’t process them properly without the data that is received from the device as it’s a one sided story with only the TX data.

This has an initialisation of the device, and it looks fine as the associations seems to have been set correctly -:

Since the log doesn’t have the information from the device, I don’t see the final configuration, but at least from what I see here it looks ok.


The log is currently 76M and i cannot upload it here. I can put it on a dropbox or do you have a public share?

76MB is too big for me to process.

I would suggest to ensure you have some sort of log rotation so that files are limited to something like 10MB each (I thought by default that’s how logging was configured).

Alternatively (or additionally) if the log is full of stuff from other bindings and the system, then you can create a ZWave only log, or, you can filter the current log to only display ZWave logs (but don’t filter on a single node).

Ok :slight_smile: looks like default log rotation is 17M. I merged all logs to that 76M. There are 15 or so devices and they are a bit chatty now in debug mode. If we cant find the :unicorn: maybe the donkeycorn will do even if its not quite the unicorn we are looking for.

I´ll post the last logfile when it stop sending data. Maybe we can see what´s leading to its muteness.

So, maybe not two years… but losing associations (or what seemed like it) has affected me for a long while. Removing associations and then readding them corrected it, but with the number of devices I have, deleting/rediscovering the Things was easier. Status updates after manual operation continue to stop working occasionally, and seems to consistently correlate with updating the binding. My battery devices (using SENSOR_BINARY) and energy monitors are not afflicted with this. Currently, my Leviton dimmers and switches (using SWITCH_MULTILEVEL and SWITCH_BINARY) are not reporting. I’ve been watching the other threads about associations disappearing, in hope that this might be the same issue. I think this was the first report of how I was resolving this…