Alarm Misses Commands (alarm, strobe, off) - Solution

Devices & Integrations
1

I wanted to share… My internet not the fastest in rural area. From this inferred that cloud does not verify activation of devices, just simply sends command. Luckily we can check current/last value of device.

Wish the motion sensor would verify sent message, sometimes I get alarm when not needed going off for missed message to cloud. Cannot help that, can only help from cloud to device.

Here is a snippet to resolve alarm not being turned on and/or off sometimes when commanded.

Note: you could recursively call “runIn” (inside while loop) as well but did not want to use any tasks with limit of 4. Changed my mind (edit below)

def alarms_both() {
log.debug “alarms_both”
settings.alarms?.both()
pause(1000)
settings.alarms.each {
if ( it != null && it.latestValue(“alarm”) != “both”) {
it.both()
runIn(1, alarms_both, [overwrite: true])
}
}
}

Repository of SmartThings

2

The problem with your solution is that it will easily hit a 20 seconds execution time limit and then your app is toast.

3

A hack is never a good solution. But rather crash app then miss turning on or off alarm when a not nice person enters my home.

Through testing it recovers by 3 or 4 attempts. I was thinking to break loop after 3 strikes your out but above point trumped that idea.

5

Wow… Interesting observation and hack.

Verification of the receipt of sent Events is a universal issue. @JDRoberts can explain why the behavior you’ve implemented is not inherent to the platform, but I think it should be added as an optional feature.

ie, For every Command for which the physical Device has some acknowledgement indicator, you should be able to ask the Platform to guarantee delivery via automatic internal retry.

As a partial proof of concept, you could implement your hack in the Device Handler instead of the SmartApp.

Add a Command called “demandAlarm()” which waits for Attribute update…? I suppose it is just as likely to timeout, hence why it should be an integrated feature with a timeout duration parameter…?

6

Ouch! I read the original post, thought: “Mesh,” thought about starting that discussion, decided against it, and now here we are. LOL! :sunglasses:

OK, assume you live in a remote outpost in Alaska in a protected region and your only source of energy is solar. (Shipping costs mean a AA battery costs $15 and environmental conditions mean the batteries don’t work great anyway.)

Now design a sensor net.

Every message sent costs energy. So you don’t poll. You don’t send “message received” acknowledgements. You don’t check battery status more than once every few days.

You let your sensors sleep as much as possible. At the maximum practical interval, the sleepy sensor wakes up, checks delta against its maximum practical threshhold for the use case, if and only if the delta exceeds the threshhold send the briefest possible message, then the sensor goes back to sleep.

Nobody waits for anyone else, nobody sends extra acknowledgements, nobody cares if some other device is offline for minutes or even hours.

Energy use is maximized with very cheap devices. It’s a beautiful thing, from an engineering standpoint. :sunglasses: :dizzy::dizzy::dizzy:

That’s mesh. Zwave and Zigbee as used in home automation. Cheap devices, very low energy draw, minimal human maintenance required.

What you don’t get is what WiFi babies grew up on: realtime monitoring and continuous status updates. But that comes at a cost. Higher energy costs, higher individual device costs, much more complexity all around.

You want that, you can have it. Apple’s HomeKit has it baked in. They’re assuming WiFi babies will never be able to make the adjustment to a mesh mindset. So their sensors will cost considerably more and their energy draw will be much higher. But you’ll have realtime monitoring.

If you have a use case that requires realtime monitoring and acknowledgement of every message, use WiFi devices. (Or zigbee in a star topology, which ST does not support.) But don’t deploy mesh and then try to turn it into something else. The results will not be pretty.

FWIW

(My first commercial install was in a nuclear power plant. I understand there are use cases that require realtime monitoring. But you don’t solve them with mesh.)

1 Like
7

Ideally, the Customer should be able to configure the level of battery use vs. reliability that is optimal for their requirements.

In this example (and many others), I think a lot of us might lean towards activating some amount of network-level “acknowledge / retry” if it were available as an option.

Why can’t the topology offer flexibility of this sort?

8

You could widen the blade of a screwdriver so it would work better as a hammer–but then it would be a worse screwdriver. Better to just get a hammer instead.

One of the great strengths of SmartThings is that it’s a multi protocol system. You don’t have to design a single universal protocol. You can use wifi devices (through cloud to cloud), zigbee devices, zwave devices.

If V2 allowed support for websockets then we’d start getting even better LAN integration. That’s what I want: commitment to a better toolkit.

I’m not going to start wearing stilettos because they make a better hammer. LOL :wink:

1 Like
9

I disagree with the analogy.

The OP @justinlhudson has a pretty good “tool” at his disposal (a Z-Wave alarm unit, of which there are few or no affordable and integrated alternatives available), and has managed to hack a hammer out of the toolkit we thankfully have available to us (the SmartApp or Device Handler).

SmartThings could expand their “toolkit” to fashion and share the best possible hammer compromises, given the constraints, and make it available with disclaimers that the heel may break. :high_heel: :hammer:

I really wish I could come up with a simpler analogy.

10

@JDRoberts a good engineer knows how to create anything with the tools given. Be it a screw driver or a shoe. I would throw a shoe at a valve if it meant making sure a valve opened to cool the rods in a nuclear plant (not real-time but just in time).

I know of cases of writing reliability code over UDP instead of using TCP, but the device only talks UDP so you work with what you have…

@tgauchat I agree a reliability verse power drain option would be nice. I also agree most of use would lean to realibitlty. As it is more annoying to goto phone app to turn on a light that should have turned on or try to stop the alarm because the baby and wife are screaming at me. :smile:

I will not post again, as it seems to be a battle of opinion now. God forbid I gave mine…

1 Like
11

An emergency’s an entirely different situation.

Anyway, like I said, I didn’t originally intend to post. But there are plenty of WiFi motion sensors and alarms and other devices available if the latency and nonserial nature of mesh bug you too much. Both Dlink and WeMo make them, among other brands.

ConnectSense is another popular line of WiFi based sensors, pretty much all the same types as the zigbee ones that work with ST, including moisture sensors. You get near continuous updates. But you pay $150 and up per sensor, and they go through batteries pretty fast.

Everybody has their own priorities in terms of what they want and what they’re willing to settle for. But many people don’t realize they bought a motorcycle when they’re used to having a car.

All I’m saying is that for many people the path to rainy day satisfaction may not be through putting an enclosure on the motorcycle.

But everybody’s different. If you’re happy with what you’ve got, go for it. :sunglasses:

12

Opinions are actually really appreciated here… Just don’t be put off by differing ones also shared.

I disagree with @JDRoberts’s “all or nothing” approach to this Topic.

Your solution demonstrates that some higher level of reliability is necessary in some scenarios and you have implemented a workable hack.

I simply would like to see this hack as being a “proof-of-concept” for a slightly more robust and Platform integrated solution and can perceive that the Device layer could be enhanced to support it.

13

@tgauchat Agreed I was edgy by end of day… life… :slight_smile:

Reading through again I really liked the idea of putting it at the device level, making Reliability flag option. Hoping when v2 Hub comes out (though I will wait until a migration tool comes out with it, maybe) that missing motion sensor will be resolved by being on my local network and more then likely this condition as well with the alarm.

2 Likes
14

Yeah, this is one of those philosophical divides that @tgauchat and I will probably always be on opposite sides of. Not really a big deal either way.

An engineering friend saw this exchange and sent me a reminder, “Peking Duck.” An argument that used to continually arise at work, with no possible resolution.

It’s a reference to vegetarian food. In parts of China there is a tradition of preparing elaborate multi-course vegetarian feasts with many dishes made to look, smell, and taste as much like famous meat dishes as possible, right down to the crackling “skin” on the Peking Duck course. A practice which tends to horrify some vegetarians from other cultures. :wink:

image.jpg1000×750 135 KB

It’s not that one way is right and the other is wrong, just that they’re on opposite sides of a philosophical divide.

I’m the kind of engineer who tremendously admires solutions that fit just the right piece into each puzzle, building on the inherent strengths of the manufacturer’s intended design. (I’m also, as people have undoubtedly noticed, extremely satisfied by solutions that meet codes and standards without sacrificing usability or budget.)

So I like mesh networks to utilize the unique strengths of mesh.

But, yeah, “Peking duck.” If you want to spend the time and effort to make a mesh device look and act like it’s in a star topology, and you’re willing to pay the costs, who am I to say otherwise? Carry on. :sunglasses:

2 Likes