FIbaro motion sensors only reporting ALARM class

Hello,

I’ve recently bought a few Fibaro motion sensors which are running the 3.2 firmware. I’m having varing degrees of success setting them up. Some of them will only report ALARM with a value of 0 on motion, and the same when motion is ‘cancelled’. Others are reporting both BASIC and ALARM for motion, although the BASIC classes report as 0 and 255. Does anyone know why these sensors are doing this?

2016-09-03 18:52:45.538 [DEBUG] [eController$ZWaveReceiveThread:1530]- Receive Message = 01 0F 00 04 00 1C 09 71 05 00 00 00 FF 07 08 00 65
2016-09-03 18:52:45.539 [DEBUG] [eController$ZWaveReceiveThread:1446]- Receive queue ADD: Length=1
2016-09-03 18:52:45.539 [DEBUG] [b.z.i.protocol.ZWaveController:1194]- Receive queue TAKE: Length=0
2016-09-03 18:52:45.540 [DEBUG] [o.b.z.i.protocol.SerialMessage:243 ]- Assembled message buffer = 01 0F 00 04 00 1C 09 71 05 00 00 00 FF 07 08 00 65
2016-09-03 18:52:45.540 [DEBUG] [b.z.i.protocol.ZWaveController:1195]- Process Message = 01 0F 00 04 00 1C 09 71 05 00 00 00 FF 07 08 00 65
2016-09-03 18:52:45.540 [DEBUG] [b.z.i.protocol.ZWaveController:194 ]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 1C 09 71 05 00 00 00 FF 07 08 00
2016-09-03 18:52:45.540 [DEBUG] [ApplicationCommandMessageClass:40  ]- NODE 28: Application Command Request (ALIVE:DONE)
2016-09-03 18:52:45.541 [DEBUG] [ApplicationCommandMessageClass:58  ]- NODE 28: Incoming command class ALARM
2016-09-03 18:52:45.541 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 28: Received Alarm Request
2016-09-03 18:52:45.541 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 28: Alarm report - Value = 0
2016-09-03 18:52:45.541 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:113 ]- NODE 28: Alarm Type = General (0)
2016-09-03 18:52:45.541 [DEBUG] [b.z.i.protocol.ZWaveController:648 ]- Notifying event listeners: ZWaveAlarmValueEvent
2016-09-03 18:52:45.541 [DEBUG] [.z.internal.ZWaveActiveBinding:449 ]- ZwaveIncomingEvent
2016-09-03 18:52:45.541 [DEBUG] [.z.internal.ZWaveActiveBinding:466 ]- NODE 28: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 0
2016-09-03 18:52:45.542 [DEBUG] [ApplicationCommandMessageClass:89  ]- Transaction not completed: node address inconsistent.

Thanks for the help

Take a look through the documentation to see if there is a command that allows you to use a different command class. We had a similar discussion this afternoon about the Fibaro motion sensor and there is a command that allows you to use the BINARY_SENSOR command class instead.

The base issue is that these devices use the NOTIFICATION class and I’d (ideally) prefer not to add that to OH1.

Sorry to be needy but could you let me know which documentation please? This is my item definition

Contact  DownstairsToiletMotion         "Downstairs Toilet Movement: [%s]"          <present>   (MultiSensors)   { zwave="28:0:command=basic" } 
Number  DownstairsToiletAlarm            "Downstairs Toilet Alarm: [%.1f]"             <fire>      (MultiSensors)   { zwave="28:command=sensor_multilevel,sensor_type=25" }
Number  DownstairsToiletLux              "Downstairs Toilet Lux: [%.2f Lux]"         <sun>       (MultiSensors)   { zwave="28:command=sensor_multilevel,sensor_type=3" } 
Number  DownstairsToiletBattery              "Downstairs Toilet Sensor Battery: [%d %%]"        <energy>   (MultiSensors)    { zwave="28:command=battery" } 
Number  DownstairsToiletTemperature             "Downstairs Toilet Temperature: [%.1f °C]"  <temperature> (MultiSensors) { zwave="28:command=sensor_multilevel,sensor_type=1" }

Thank you Chris

This is the previous discussion this afternoon - I suspect it’s the same sensor as you have -:

Take a look at that thread and see if it solves the issue.

Thanks for the reply.

It looks like the troublesome device in that post is a Fibaro door/window sensor, rather than the motion sensor.

Thanks

Well, I’d check the manual to see if the same configuration setting exists - there’s a lot of commonality between Fibaro device firmware.

Take a look at parameter 12 in the FGMS - this looks like it should allow you to use the BASIC class with group 2.

Had a go at changing parameter 12 to every option available but no success. Also tried to exclude and include again, but still no luck. Can’t see anything in the manual that sounds similar to parameter 20 for the door/window sensor.

I fired up the Zensys-tool, and can see that ALARM events are sent by the motion sensor, but they have different values depending on whether its detecting motion or cancelling motion.

Could it be that the z-wave binding needs updating? I’m running version 1.9.0.201608130112

Thanks again for the help

Can you provide a debug log showing what the device sends for parameter 12? It looks like it should send the BASIC device class according to the manual, so you should be able to use command=BASIC?

Updating the binding won’t help…

I get BASIC commands if I put the controller into group 2, but should it not receive them in group 1? At least not as alarms?

According to the manual, this is a function of group 2 - that’s what parameter 12 says -:

This parameter determines the command frames sent to 2nd association group (assigned to PIR sensor).

You’ll have to forgive me sorry, I’m not especially familiar with z-wave. My understanding is that group 1 will get all the information, but you can put other devices into group 2 and 3 to trigger actions e.g. group 2 can control a light.

So are you saying that the controller should by design be in group 2 to get motion updates?

Normally you would use a certain group for the controller - on Fibaro devices it’s normally either group 1 or 3. Often it’s also called Lifeline. However, that doesn’t stop you using another group, or even two groups. So I would consider using group 2 to get the motion alarms, and then group 1 for other notifications if needed.

If is like my device, you can try with this

5 Command Options:
Which commands to send when PIR motion sensor triggered OZW Ideal Value is Binary Sensor Report
Last Update: 2016-09-03 23:46:07

Try to change this parameter.

But motion is a nightmare in this device. I think for enable the motion, you have to be lucky. Plug usb, disable PIR, enable PIR,… Try a lot of time … and maybe will work :slight_smile:


This is a thread on domoticz, but the problem is the same ( the device )…

1 years ago, after 1 month, i enabled the sensor… but last week I excluded the device from network and included another time… but the nightmare is began another time

Hi everyone,

Thanks for the help. I think I have it working now, but to do so I’ve put the controller in the 4th and 5th association groups which are backwards compatible motion and tamper groups meant for non z-wave plus devices. I now get SENSOR_BINARY and SENSOR_ALARM reports.

I’m still interested to know whether this is how its meant to work? I always get an ALARM message on motion and motion cancellation with a value of 0, but I think the hex data in the messages are different. I’ve put the details below:

Motion:
> 2016-09-04 07:32:48.493 [DEBUG] [.z.internal.ZWaveActiveBinding:466 ]- NODE 32: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 0

2016-09-04 07:32:48.493 [TRACE] [.b.z.i.c.ZWaveConverterHandler:358 ]- Getting converter for item = KitchenLux, command class = ALARM, item command class = sensor_multilevel
2016-09-04 07:32:48.493 [TRACE] [.b.z.i.c.ZWaveConverterHandler:358 ]- Getting converter for item = KitchenTemperature, command class = ALARM, item command class = sensor_multilevel
2016-09-04 07:32:48.493 [TRACE] [.b.z.i.c.ZWaveConverterHandler:358 ]- Getting converter for item = KitchenMotion, command class = ALARM, item command class = sensor_binary
2016-09-04 07:32:48.493 [TRACE] [.b.z.i.c.ZWaveConverterHandler:358 ]- Getting converter for item = KitchenAlarm, command class = ALARM, item command class = sensor_alarm
2016-09-04 07:32:48.493 [TRACE] [.b.z.i.c.ZWaveConverterHandler:358 ]- Getting converter for item = KitchenBattery, command class = ALARM, item command class = battery
2016-09-04 07:32:48.494 [DEBUG] [ApplicationCommandMessageClass:89  ]- Transaction not completed: node address inconsistent.
2016-09-04 07:32:48.550 [DEBUG] [eController$ZWaveReceiveThread:1530]- Receive Message = 01 09 00 04 08 20 03 30 03 FF 15

And motion cancellation:
> 2016-09-04 07:33:19.020 [DEBUG] [.z.internal.ZWaveActiveBinding:466 ]- NODE 32: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 0

2016-09-04 07:33:19.020 [TRACE] [.b.z.i.c.ZWaveConverterHandler:358 ]- Getting converter for item = KitchenLux, command class = ALARM, item command class = sensor_multilevel
2016-09-04 07:33:19.020 [TRACE] [.b.z.i.c.ZWaveConverterHandler:358 ]- Getting converter for item = KitchenTemperature, command class = ALARM, item command class = sensor_multilevel
2016-09-04 07:33:19.020 [TRACE] [.b.z.i.c.ZWaveConverterHandler:358 ]- Getting converter for item = KitchenMotion, command class = ALARM, item command class = sensor_binary
2016-09-04 07:33:19.020 [TRACE] [.b.z.i.c.ZWaveConverterHandler:358 ]- Getting converter for item = KitchenAlarm, command class = ALARM, item command class = sensor_alarm
2016-09-04 07:33:19.020 [TRACE] [.b.z.i.c.ZWaveConverterHandler:358 ]- Getting converter for item = KitchenBattery, command class = ALARM, item command class = battery
2016-09-04 07:33:19.020 [DEBUG] [ApplicationCommandMessageClass:89  ]- Transaction not completed: node address inconsistent.
2016-09-04 07:33:19.077 [DEBUG] [eController$ZWaveReceiveThread:1530]- Receive Message = 01 09 00 04 08 20 03 30 03 00 EA

Is the Receive Message significant?

Thanks