Because you just paired the 2nd siren, it joined with an Edge driver. Anything added now gets paired with an Edge driver. If you look at the 3-dot menu, top right, you’ll see that the newer siren has a “Driver” menu, indicating it’s using Edge.
If you are missing capabilities with the Edge driver, I’d look in the ST community to see if the manufacturer or anyone has written a custom driver for it. ST default drivers do not typically include all the features. For that, you need one from the manufacturer or from someone that has written a driver to include advanced capabilities.
Yes, it sounds like it joined with an edge driver. Is there something about the approach with the Super Tile and commands not working for you with this device?
Yeah, I want to be able to set both devices to “STROBE” only. Interestingly, I am able to create a RULE to set the new device to “STROBE” only - but it isn’t working…
Well, I believe the original device is using a Groovy Device Handler. Samsung is deprecating Groovy drivers and implementing Edge drivers. So as part of this transition, SmartThings has written a set of default Edge drivers that are designed to give basic functionality to devices. But SmartThings also allows 3rd parties, manufacturers and others, to write Edge drivers to be used with those same devices. These 3rd party “custom” drivers improve upon SmartThings’ basic driver, often exposing more capabilities.
Here is a generic example for a siren. You add the siren, it pairs with an Edge driver, and it works. But maybe you’ve heard the siren is capable of producing different sounds, but you don’t see any way of picing those sounds in your settings. So then you research to see if the manufacturer or a developer has designed a custom Edge driver for your siren. If one exists, you can then load that custom Edge driver and switch to it via the app. Improving upon SmartThings’ default driver, that Edge driver adds settings to allow you to pick different sounds.
I’m not saying that’s the case with your specific siren, but it’s worth taking a look around. On the other hand, if you’re happy with how the more recently added siren is working, leave them alone. SmartThings will eventually convert the older siren to an Edge driver without you having to do anything.
That’s weird as it doesn’t match the documentation which indicates devices with an Alarm capability should support a siren() and strobe() command in addition to the both() command.
If you end up posting in the SmartThings community about it, please post a link to the discussion here as I would be interested in following along.
No, I think that’s reasonable. Either the manufacturer or SmartThings would need to support the additional strobe() and siren() commands or someone in the community would have to build a driver that supports it.
You can follow the link in my previous reply – it’s pointing to the documentation for the capability. The edge driver implements that capability, so we would have expected it to properly support all documented features of the capability.
This Edge driver is using the internal Z-wave defaults for the ‘alarm’ capability. Basically, when you write an Edge driver, you can either build custom commands/logic or you can use built-in features when they are available. Take a standard capability like “Switch” – if your driver registers that it wants to use the Z-wave Switch capability, then the driver subsystem automatically takes care of handling on() and off() commands as well as reacting to the switch attribute state changing – this is possible because these things are (relatively) standardized within Z-wave. From a quick glance at these Z-wave Siren drivers, it looks like they’re leveraging the system’s default Z-wave Alarm implementation… but I don’t know that the internal implementation is actually documented anywhere.
UPDATE:
The ST app still shows the 2 devices differently (as noted in “Siren Strobe - 1” & “Siren Strobe - 2” above; #1 has 4 states, and #2 has 2 states.)
The SharpTools Rule still shows both devices to be set to each of the 4 states.
The following SharpTools Rule does work as hoped, and makes the new device follow whatever action the old device is executing…
