Two Aeon alarms no longer working via SmartThings

It could be that interfacing between the Android app and the device goes through the cloud. The Android devices aren’t z-wave or zigbee compatible.

But if I have an alarm set to go off if a motion sensor detects movement, that should all be handled via the z-wave and/or zigbee signals, not the cloud.

Not in SmartThings.

The hubs radio can communucate directly to the local device, but first it goes to the cloud to make sure it has permission to talk to that device from the cloud account. And the code that formats the messages that get sent also runs in the cloud.

It doesn’t have to be done that way, as staples connect demonstrates, but it is the way SmartThings does it for most events at the present time.

Ouch. That’s definitely an extra burden.

1 Like

It is managed through the Android App that goes through the cloud. Also, it uses Wi-Fi for it’s connection to your network not Zigbee or Z-wave. I am sure that you know that though, just wanted to be sure. While I know you can manage it locally, it appears to need a port open on the router in order for it to work. At least it did with my setup (SMILE). I have not sniffed it to see if it is actually communicating to a Samsung Server someplace so you may be correct that it is not cloud based at all.

But, we know if it is connected to ST, that ST certainly is cloud based so the point is moot. You could if you want build a server local to handle the video etc from the camera, and just have ST connect via URL or Similar for video and images. I think the Foscams do that already?

Sorry I thought you were aware of that fact? Sorry I failed to explain how ST works for you. Thanks @JDRoberts for making it clear

1 Like

@Shelley_Powers I am stumped here. I just tried the test mode as well as triggering the alarm and it was like instant (absolutely no delay). And I am talking not even a second. Not sure if this matters, iOS here.

Yup, aware that the Android app connects through Wifi, but thought the hub and devices basically spoke directly to each other without having to go directly to the cloud in each communication.

I know that the SmartCam is speaking directly to the hub, the Google OnHub router actually demonstrates this–the device has like 68 GB of uploaded data, but the router only shows something like 8 GB total, for 17 or so devices, actually making it through the router. One advantage to the OnHub router, being able to see this activity. And the ST engineers actually corroborated this in another thread here in the community.

I can see managing everything through the app, but once the pieces are in place, it makes more sense to have the hub speak directly to the devices. For instance, if a routine is set up so that motion in one room after a certain time triggers security, in the form of lights being turned on, and alarms firing. The setup would be through the app, of course, but once set up, other than the devices communicating their state, is the actual triggering handled through the cloud? Or through z-wave/zigbee? It doesn’t make sense to go to the cloud, first, especially in a security situation.

I imagine the developer code has all the info on this. I should check it out.

I don’t know what’s happening with my set up this week. I had no problems with the one alarm before today. And I haven’t been able to get the second working, so am assuming it may be defective. Hard to say, though.

Ron, me too. I had no problems last week with the one alarm, but today, it’s appalling. And I can’t get the second one to work.

I’m wondering if the two alarms are interfering with each other?

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! :slight_smile: 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. :wink: 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