I totally admit that I am not as tech savvy like the experts in here but I am not too sure that the two sirens may be interfering with “each other”. As such just curious, you use the stock ST device type, right? I have only of this and it’s only about six feet away from the ST hub if that matters at all and have tons of other zwave powered devices in close proximity.
1 Like
These are the Aeon Labs z-wave gen 5 sirens, the ones in the official compatible list.
I would think the one alarm was just defective, if I didn’t also have problems with a siren I knew worked last week.
The reason it makes some sense to go to the cloud each time is because of the original smart pthings multiprotocol architecture.
They wanted to make sure that you could have a zigbee motion sensor trigger a Z wave siren and that the customer would not have to know that those are two different protocols.
There is no way for them to talk directly to each other.
The smartthings v1 hub is one plastic box, but it actually has three separate radios inside of it. One for Z wave, one for Zigbee and one for ethernet. The smartthings v2 hub added a radio for Bluetooth although that is currently inactive.
The original v one hub didn’t have the processing power to do anything much with the different signals. So The appropriate radio would realize it had received a message, and it would then send that message via ethernet to the cloud to actually figure out what it was for. And to be run through all of the connective logic that would allow a device of one protocol to trigger a device of a different protocol, But with all of the "only if "restrictions like mode, time of day, etc. Then the cloud would send the authorized messages back to the hub and say basically just “send this message to that device.”
The new v two hub has a more powerful local computer, so it could do more of the authorization logic itself, it just isn’t set up to do that right now.
If all you want is to have a Z wave motion sensor trigger a Z wave alarm, you can do that completely locally with Z wave association which doesn’t even go to the local hub first. The issue is what you want to start using conditionals to say which triggers you actually pay attention to.
For example, I have a motion sensor in the bedroom. In the evening, if it’s triggered it turns on the overhead light. This is when the mode is “night”. Then when I’m ready to go to bed, mode changes to “asleep.” Now the same motion sensor won’t change the overhead light, instead a night light on the wall will come on.
On top of that, the motion sensor is Zigbee and the switch controlling the nightlight is zwave, and the ceiling light is a Philips hue via a LAN connection to the Hue bridge. So three different protocols, two conditional states, two outcomes. All from the same devices.
That’s the logic that has to run somewhere. And because the smartthings V2 hub is inheriting the SmartThings V1 architecture, right now it runs in the cloud.
2 Likes
Not sure if you’re directing that at me or JD, but am assuming it goes to cloud. My Android app doesn’t have the ability to communicate directly to the Hub without the cloud.
Oops, just saw you did direct it to JD. Never mind.
Never mind! That was a stupid question from me! 
was just trying to learn somerhing.
Anything from the mobile app goes to the cloud first, there is no direct communication from your phone to your hub. Again, as Staples connection shows, that is possible to do, it’s just not the way SmartThings has done it.
They have told us that if your connection to the Internet is down from your hub, you will not be able to control anything from your phone. That’s why they suggest people preprogram minimotes for anything they might need to change manually. Assuming of course it’s eligible for local processing, which right now just means the smart lighting solution with some specific device types.
1 Like
Yeap. I figured. And deleted my stupid question. 
of course anything from the mobile app will go thru the cloud.
1 Like
I just decided to get a couple of minimotes.
Found the architecture description, which was very informative. There are some actions that occur directly between the hub and the devices, but we’re not sure what they are. We do know the SmartCam video stream is directly between the two, because one of the engineers confirmed it, and the OnHub tracked the direct relationship.
http://docs.smartthings.com/en/latest/architecture/index.html
But to return to the sirens, I’m having to assume the second siren is defective, and will need to return. I just don’t have a way to directly tell if the connection is the problem, or the device is the problem. Best to return, and try again.
It’s been a fascinating discussion, though. Highly informative.
1 Like
www.zwaveproducts.com typically has very good prices on the v1 minimotes, btw. With the firmware update (which they do before shipping), they work just like the much more expensive v2. The main difference is that the v1 only comes in white.
1 Like
I did find the way to look at events, and the second siren is not getting any events. The first one is, but not the second one. So this is either a problem between ST and the device,or the device is faulty.
I’m just going to exchange this one. If the replacement I get also has problems, then we know that ST has an issue.
And for what it’s worth, for all of this, I got it fixed.
Once I found the events, I noticed all the events were one type, Commands. But nothing from the device. I assumed that I did screw up the connection.
I found the instructions in how to remove the device, followed, and reset.
Works fine now.
Operator error. And now that I know where the events are in the web UI, I think I can debug these on my own now.
Thanks for patience and help, folks. It has been an informative discussion.
1 Like
This is a good FAQ to mark for future debugging. It’s in the Developers section of the forums.
1 Like