we’re currently working with this sensor using the zwave binding and discovered that, during inclusion mode, the controller (node_1_0) is put only in association group 1. With this configuration, however, we’re not able to receive smoke and tamper alarms (even after changing config option 13 to receive them), as they seem to no be sent to the association group 1.
Putting the controller also in group 4 (SENSOR_ALARM_REPORT for fire alarm) and 5 (SENSOR_ALARM_REPORT general) enables it to correctly receive those kind of events as soon as they’re triggered.
Putting it in groups 2 and 3 makes it able to receive BASIC commands about those alarms, but these packets do not trigger a status change in the channels of the thing.
Looking at the database XML file for this devices, I found the property
<property name="defaultAssociations">1</property>
which, I guess, binds the controller only to association group 1 when including the device into the network.
Given the aforementioned findings, would it be advisable to add the controller also to groups 4 and 5 by default?
To answer your question: yes, it makes sense to add controller to groups 4 and 5.
While we could have a (more or less academic) discussion on which device or database or other instance should define or override other defaults, it seems that everyone needs to add these associations to get the device to work properly. Me, too, and I know of a number of people to have hit that problem, I also remember there’s a lengthy thread on this.
So doing so by default will ease quite some people’s life.
Not sure, though, if and if so how that can actually be done in the database.
(multiple of those XML lines ? is that property being used at all ?) @chris, you probably know…
Looking at the device page on the DB,I guess one needs to set the Controller flag to yes to put the controller’s node inside a group by default.
Let’s hear from @chris, though…
No problem.
What I meant was to also set the association groups 4 and 5 as defaults for the controller when configuring the device, as these are essential for receiving smoke and tamper alarms; this last one needs also option 13 to be set to something different than 0, but the association group could be set nonetheless I guess.
What do you think about it?
Are you sure these are really needed (I’m also not sure if we are talking about OH1 or OH2?).
Normally, only the lifeline group is required. If you add associations into multiple groups, then you will likely get multiple alarms… Maybe on this device you need multiple groups, but it’s not normally the case for Fibaro devices.
The reason I ask about OH1 and OH2 is this device probably uses the NOTIFICATION command class which is about to change in OH2 and this may also impact this.
We performed several tests with this device on an ESH-based runtime (I guess this currently is kinda similar to OH2) and we were able to receive the correct alarm notifications only when the controller was also in groups 4 and 5. Otherwise, we received nothing, not even in the DEBUG logs. We also had some trouble getting the inclusion done with this device on several occasions, but this is another issue.
We tested the device using openzwave too and found that it works out of the box because it sets those 2 additional groups by default when including the sensor into the network.
Looking at the descriptions for the association groups in the device manual:
Fibaro Smoke Sensor allows for the associations of five groups.
1st group – Lifeline. Reporting device state. Only one device - Z-Wave network
controller may be set in this group. It’s not recommended to modify this association
group.
2nd group – Smoke Alarm. Sending the BASIC SET control command once smoke is
detected. Its value may be modified in advanced parameters (see section XVI). Group
may control up to five on/off devices.
3rd group – Tamper. Sending the notification NOTIFICATION REPORT (TYPE =
BURGLAR, EVENT = PRODUCT COVERING REMOVED) to associated devices once
casing opening is detected. Up to five devices supporting casing opening command
(NOTIFICATION REPORT) may be included in this group.
4th group – Smoke Alarm. Sending the notification SENSOR ALARM REPORT (TYPE
= SMOKE ALARM) to associated devices once smoke is detected. Up to five devices
supporting SMOKE ALARM command may be included in this group
5th group – Tamper. Sending SENSOR ALARM REPORT notification (TYPE =
GENERAL) to associated devices once casing opening is detected. Up to five devices
supporting SENSOR ALARM REPORT command may be included in this group.
I get that the NOTIFICATION CC is only sent to devices associated to the third group. Is this correct?
This is not normally how it works, but maybe it’s changed. Normally, the lifeline group will get all the events, and the other groups allow for specific events - normally targeted toward controlling other devices.
I totally agree with you, as we’ve seen other devices happily sending events to the controller with it being only in the first association group, but this device seems to behave differently.
Interesting, your conclusion seems correct…
How new is the new in [quote=“chris, post:12, topic:13942”]
(which is the new NOTIFICATION version)
[/quote]
? Is this in recent snapshots of the zwave binding?
It’s just the same command class, but Sigma renamed it. It’s partly supported in the current version, but not very well. There’s an outstanding PR to improve this, but I’m waiting until Kai produces the Beta4 version before merging it as there are likely to be some changes needed… This should be in the next couple of days…
).