Duplicate events from some of my FGMS001 multi sensors

[wega3k 0]

Hi.

 

I have 5 FGMS001 talking to OpenZwave via an Aeotec z-stick gen5. I have a couple of door locks and a siren on the Network too:

 

Please login or register to see this image.

 

 

Node Id	Basic Type	Generic Type	Product	Name	Location	Value	Last Heard	Status
1 *LB	Static Controller	Static PC Controller	Aeotec Z-Stick Gen5				00:35:53	Ready
2 BR+	Z-Wave+ node Reporting Sleeping Slave	Home Security Sensor	FIBARO System FGMS001 Motion Sensor	Office Multi		off	18:04:31	Sleeping
9 FBR	Routing Slave	Secure Keypad Door Lock	Assa Abloy Yale Keyfree Connected Smart Lock	Downstairs Side		234	15:37:31	Ready
10 LBR+	Z-Wave+ node Always On Slave	Siren	Aeotec DSD31 Siren Gen5			off	15:08:39	Ready
11 BR+	Z-Wave+ node Reporting Sleeping Slave	Home Security Sensor	FIBARO System FGMS001 Motion Sensor	Games Room Multi		off	16:26:25	Sleeping
14 BR+	Z-Wave+ node Reporting Sleeping Slave	Home Security Sensor	FIBARO System FGMS001 Motion Sensor	Kitchen Multi		off	15:35:21	Sleeping
15 BR+	Z-Wave+ node Reporting Sleeping Slave	Home Security Sensor	FIBARO System FGMS001 Motion Sensor	Hall Multi		off	16:52:50	Sleeping
16 FBR	Routing Slave	Secure Keypad Door Lock	Assa Abloy Yale Keyfree Connected Smart Lock	Front Door		12	15:39:20	Ready
17 BR+	Z-Wave+ node Reporting Sleeping Slave	Home Security Sensor	FIBARO System FGMS001 Motion Sensor	Kitchen Multi		off	16:37:35	Sleeping
18 BR+	Z-Wave+ node Reporting Sleeping Slave	Home Security Sensor	FIBARO System FGMS001 Motion Sensor			off	17:11:20	Sleeping

One of them (node 15 - Hall Multi) works as expected, however all of the others give duplicate events. I note that node 15 in the routing table above has only one route where as the others have multiple routes.

 

Here are some example duplicates:

 

2017-01-30 16:37:35.572 Info, Node017, Received SensorMultiLevel report from node 17, instance 1, Luminance: value=0lux
2017-01-30 16:37:35.572 Detail, Node017, Refreshed Value: old value=3, new value=0, type=decimal
2017-01-30 16:37:35.572 Detail, Node017, Changes to this value are not verified
2017-01-30 16:37:35.572 Detail, Node017, Notification: ValueChanged
2017-01-30 16:37:35.608 Detail, Node017,   Received: 0x01, 0x0c, 0x00, 0x04, 0x00, 0x11, 0x06, 0x31, 0x05, 0x03, 0x0a, 0x00, 0x00, 0xdd
2017-01-30 16:37:35.609 Detail,
2017-01-30 16:37:35.609 Info, Node017, Received SensorMultiLevel report from node 17, instance 1, Luminance: value=0lux
2017-01-30 16:37:35.609 Detail, Node017, Refreshed Value: old value=0, new value=0, type=decimal
2017-01-30 16:37:35.609 Detail, Node017, Changes to this value are not verified
2017-01-30 16:37:35.609 Detail, Node017, Notification: ValueChanged
2017-01-30 16:37:35.647 Detail, Node017,   Received: 0x01, 0x0c, 0x00, 0x04, 0x00, 0x11, 0x06, 0x31, 0x05, 0x03, 0x0a, 0x00, 0x00, 0xdd
2017-01-30 16:37:35.647 Detail,
2017-01-30 16:37:35.647 Info, Node017, Received SensorMultiLevel report from node 17, instance 1, Luminance: value=0lux
2017-01-30 16:37:35.648 Detail, Node017, Refreshed Value: old value=0, new value=0, type=decimal
2017-01-30 16:37:35.648 Detail, Node017, Changes to this value are not verified
2017-01-30 16:37:35.648 Detail, Node017, Notification: ValueChanged
2017-01-30 16:42:32.373 Detail, Node015,   Received: 0x01, 0x0f, 0x00, 0x04, 0x00, 0x0f, 0x09, 0x71, 0x05, 0x00, 0x00, 0x00, 0xff, 0x07, 0x08, 0x00, 0x76
2017-01-30 16:42:32.373 Detail,

2017-01-30 14:57:55.421 Info, Node017, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Burglar event:8, status=255
2017-01-30 14:57:55.421 Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
2017-01-30 14:57:55.421 Detail, Node017, Changes to this value are not verified
2017-01-30 14:57:55.421 Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
2017-01-30 14:57:55.421 Detail, Node017, Changes to this value are not verified
2017-01-30 14:57:55.421 Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
2017-01-30 14:57:55.421 Detail, Node017, Changes to this value are not verified
2017-01-30 14:57:55.422 Detail, Node017, Refreshed Value: old value=0, new value=8, type=byte
2017-01-30 14:57:55.422 Detail, Node017, Changes to this value are not verified
2017-01-30 14:57:55.422 Detail, Node017, Notification: ValueChanged
2017-01-30 14:57:55.422 Detail, Node017, Notification: ValueChanged
2017-01-30 14:57:55.422 Detail, Node017, Notification: ValueChanged
2017-01-30 14:57:55.422 Detail, Node017, Notification: ValueChanged
2017-01-30 14:58:34.656 Detail, Node017,   Received: 0x01, 0x10, 0x00, 0x04, 0x00, 0x11, 0x0a, 0x71, 0x05, 0x00, 0x00, 0x00, 0xff, 0x07, 0x00, 0x01, 0x08, 0x75
2017-01-30 14:58:34.656 Detail,
2017-01-30 14:58:34.656 Info, Node017, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Burglar event:0, status=255
2017-01-30 14:58:34.656 Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
2017-01-30 14:58:34.656 Detail, Node017, Changes to this value are not verified
2017-01-30 14:58:34.656 Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
2017-01-30 14:58:34.656 Detail, Node017, Changes to this value are not verified
2017-01-30 14:58:34.656 Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
2017-01-30 14:58:34.656 Detail, Node017, Changes to this value are not verified
2017-01-30 14:58:34.656 Detail, Node017, Refreshed Value: old value=8, new value=0, type=byte
2017-01-30 14:58:34.656 Detail, Node017, Changes to this value are not verified
2017-01-30 14:58:34.656 Detail, Node017, Notification: ValueChanged
2017-01-30 14:58:34.656 Detail, Node017, Notification: ValueChanged
2017-01-30 14:58:34.656 Detail, Node017, Notification: ValueChanged
2017-01-30 14:58:34.656 Detail, Node017, Notification: ValueChanged
2017-01-30 14:58:34.697 Detail, Node017,   Received: 0x01, 0x10, 0x00, 0x04, 0x00, 0x11, 0x0a, 0x71, 0x05, 0x00, 0x00, 0x00, 0xff, 0x07, 0x00, 0x01, 0x08, 0x75
2017-01-30 14:58:34.698 Detail,
2017-01-30 14:58:34.698 Info, Node017, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Burglar event:0, status=255
2017-01-30 14:58:34.698 Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
2017-01-30 14:58:34.698 Detail, Node017, Changes to this value are not verified
2017-01-30 14:58:34.698 Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
2017-01-30 14:58:34.698 Detail, Node017, Changes to this value are not verified
2017-01-30 14:58:34.698 Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
2017-01-30 14:58:34.698 Detail, Node017, Changes to this value are not verified
2017-01-30 14:58:34.698 Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
2017-01-30 14:58:34.698 Detail, Node017, Changes to this value are not verified
2017-01-30 14:58:34.698 Detail, Node017, Notification: ValueChanged
2017-01-30 14:58:34.698 Detail, Node017, Notification: ValueChanged
2017-01-30 14:58:34.699 Detail, Node017, Notification: ValueChanged
2017-01-30 14:58:34.699 Detail, Node017, Notification: ValueChanged

 

This isn't expected behaviour is it?

[wega3k 0]

my understanding is, all routing in zwave is source based and if an ack is not received, it will retry via another route, but these seem to send via all routes every time. The only one which doesn't have the problem is the one which has a single route.

[petergebruers 1,268]

Long shot, It may be related to a bug that manifests itself if you set lux reporting < 50. You wont find the problem with the info you gave... because HC does not have that log and the problem doesn't manifest itself in the same way. I think it's solved on firmware 2.7 or 2.8. Sorry I can't be more specific, it's all too long ago. Do you know someone with a HC, to upgrade the sensor?

[petergebruers 1,268]

BTW yes. these sensors first try direct connection, then al routes via neighbors, and if all fail, I think they even broadcast.

[wega3k 0]

Hi, thanks for your response. Does that bug you mentioned manifest on all event types or just lux, as I see the problem with all types?

 

Regarding the firmware version, I'm not sure how to determine this, but I presume they're all 3.2 or higher as I bought them in June last year and they were all ZWave+ branded.

[petergebruers 1,268]

If my memory is correct, certain settings caused the sensor to send "too many updates, too fast". The official (and confirmed) advice before the update was: if you want fast updates, leave parameters default but set wake up to the desired update interval. Meaning, "minutes". Anyway, this was observed for the non-Zwave-Plus version, and I don't know if the 3.X shared this bug... I think you can find out: if you set parameters to default (e.g. Lux reporting: 200) then the bug disappears.

For the moment, I'm rather going with your theory of "network issues"... But then it seems odd, none of the direct & routed packets get ack... but they do arrive at the controller? Is some device in between buggy? What happens if you power down all your mains nodes? BTW I'm responding on a phone, I need te check your first post on a PC when I'm home... 

Edited January 31, 2017 by petergebruers

[wega3k 0]

I did wonder if the intermediate devices could be buggy. Unfortunately the openzwave log file doesn't show acks.

 

I'm going to try a couple of things:

 

1. Power down intermediate devices like you say. Will do it one by one and see if the number of duplicates goes down by the number if intermediates that are powered down.

2. Borrow an aetec multi sensor and see if, with the same intermediates, it also gives duplicates.

 

 

[petergebruers 1,268]

Good luck. If it's a MS6, firmware 1.08 was released a while ago   

[wega3k 0]

I forgot to report my findings. I found the following back in February:

 

1. With the intermediate devices powered down, I still got the duplicate packets from the Fibaros. The number of packets received for each event continued to match the number of routes in the MS6's routing table.

2. I borrowed an Aeotec multi-sensor. It acted correctly and with multiple routes available, only one packet was received by my Aeotec Z-Stick based Domoticz server.

 

On that basis I will raise the matter with Fibaro and the retailer I bought them through.

Edited June 11, 2017 by wega3k

[wega3k 0]

I have now solved this issue (props to Vesternet support - great customer service).

 

The duplication was caused by

 

Please login or register to see this link.

 - in addition to group 1, the OZW config was making the controller a member of association group 4 (see the default=true). Removing this fixed the issue.

[petergebruers 1,268]

6 minutes ago, wega3k said:

I have now solved this issue (props to Vesternet support - great customer service).

 

The duplication was caused by

 

Please login or register to see this link.

 - in addition to group 1, the OZW config was making the controller a member of association group 4 (see the default=true). Removing this fixed the issue.

 

That's good news. Thanks for reporting back! I had thought about this being the cause... but I dismissed it! Long time ago, I tested another fibaro device and I added the controller to the reporting group plus some other group. I didn't get duplicates so I thought: "Well, this is clever, the device doesn't send the same message twice". Maybe my conclusion at the time was wrong, or maybe this behaviour depends on the firmware (and device) or the SDK used to build it. I learn at least one new thing about Z-Wave every week.

 

Edited June 13, 2017 by petergebruers