How to set endpoint in groups?

[MartinF]

For reliability reasons I need Fibaro smoke sensors to communicate directly with Aeotec Siren 6 (without the controller). If I add the Siren to Group 2 (fire alarm) in Domoticz the siren will go off, but with the wrong sound. To make it play the emergency sound the endpoint needs to be set to 8. Because the siren device number is 7 I have tried to assign ”7.8” as the group number In the dialog box. ”7.8” is btw also an option available for the smoke sensors in the groups dropdown menu of the Open Z-Wave UI, which I’ve tried as well. No matter how I do it, the result is the same: 7.8 Is accepted but registered as ”7”, without the endpoint specified.

BTW: an odd thing in the groups interface is that only one device has the Controller-lifeline set to "1.1", while the others are set to 1.

Ideas anyone?

[rasper]

I am trying to achieve the exact same thing. I also associated the Siren 6 to group 2 (and also group 4 to be sure) of a Fibaro smoke sensor. When I test the smoke sensor, I see the "Smoke Alarm: Smoke test" coming in in Domoticz from the Aeotec Gen 5+ zwave usb stick. But the siren does not go off, not even with the wrong sound. I do have a virtual switch in Domoticz for ringing a doorbell sound on the Siren 6 and this works fine, so the device is working. Also if I shake the Siren 6 I do see a tamper alarm coming into Domoticz. For some reason the Siren does not get the trigger from the Fibaro or is unable to handle it.

What version of Domoticz are you running and did you make any specific settings on the Fibaro or the siren? I am running 2022.1 stable.

BTW, my siren also shows 1.1 as lifeline and I am also unable to add eg 34.1 as a node to the group 2 of the smoke sensor.

[MartinF]

I have the same version, 2022.1 Stable. To make it work, you need to set the smoke sensor in broadcast mode.

My guess is that the problem is related to OZW, which complicates things because it’s deprecated.

[rasper]

Strange, I did put the fibaro in broadcast mode:
13. Alarm broadcast: Smoke ACTIVE, tamper INACTIVE

Still no luck, the siren remains completely silent with a smoke alarm test.

- Which Zwave stick do you use?
- Do you have the siren in group 2 of the smoke sensor only or also in group 4 or other groups?

[MartinF]

…and it will not broadcast anything unless it detects true smoke. Pushing the test button will not make it broadcast.

[MartinF]

Anyone, please: how to set endpoint in groups?

[rasper]

For what it is worth:
- I migrated a test pi to Z-Wave js ui instead of OZW
- With MQTT autodiscovery Domoticz found a series of devices: volume sliders for each endpoint and binary sensor for each endpoint. However no devices to switch the siren endpoint on or off.
- I connected Home Assistant to the same zwave js ui instance and through the direct interface to HA from zwave js ui a lot more devices were discovered. For each end point a volume sliders, a binary sensor, an on/off switch, and a device that let's you select the tune to play when the end point gets activated.

Not sure (yet) why Domoticz autodiscovery does not add the same set of devices that HA does. Spinning up a docker with HA for just the siren 6 could of course work but is quite some overhead. You could use Domoticz<>HA integration though to set the endpoint tone and volume.

HA and domoticz screenshots below:

Screenshot 2022-11-26 at 16.22.38.jpg (288.6 KiB) Viewed 627 times

Screenshot 2022-11-26 at 16.18.50.png (303.51 KiB) Viewed 627 times

To also answer the initial question on setting endpoints in groups, I suspect (but not tested) that zwave js ui supports this:
Maybe it would also work to just change the sound for the 1st endpoint with HA?

Screenshot 2022-11-26 at 16.37.09.png (85.76 KiB) Viewed 625 times

[rrozema]

The number you enter into the group is the node Id that a notification message should be sent to. So assuming you have 2 devices, for example:
- a sensor device which has node Id 5 and it defines a group 2 for notifications. And
- a siren device which has node Id 6.
You would add 6 to the group 2 of node 5. This will result in node 5 sending some notification to node 6 whenever it finds the criteria have been met for sending such notification (these criteria may depend on settings in node 5).
What action node 6 takes upon receipt of this message (i.e. which sound your siren emits) depends on the type of notification sent by node 5. This is defined by the firmware of node 5. For some device types this may be configurable in the settings of your sensor (node 5 in my example) but often, especially for cheaper types of sensors, this is hard coded into the devices firmware and can not be altered: A smoke sensor will emit a smoke notification message, a water sensor will send a water(leakage) notification message, a doorbell will send a visitor notification message, a motion(pir) sensor will send a motion detected notification. The siren can respond differently to each of these types of notification messages. But it doesn't have to: again this depends on the firmware built into the siren. Plus, depending on the implementation the developer of the siren device chose, it may or may not have settings for you to influence this behavior.


The reason why you see some nodes that are listed with 1.1 where most nodes are listed with 1, is that those devices with 1.1 implement multiple instances in their NIF. I personally think this is a long time error, as it suggests that the controller would have multiple instances and instance 1 of node 1 should be addressed, which is most of the times not true because the controller only has 1 instance. But anyway, that .-notation is not meant to be used in the way you suggest.