I'm Back Automation - What am I missing here?

SmartApps & Automations
1

Screenshot_20210212-233434_SmartThings
Screenshot_20210212-233434_SmartThings1440×3200 234 KB

So some behavior changed in last few weeks to a month. Now when ANY of the 3 “people” LEAVE, “I’m back” automation RUNS! Am I missing something here? It should only run when someone arrives — NOT leaves. Why would that be triggering it? Any insight or help?

I probably have to just re-think my logic and re-create this automation into multiple automations with pre-conditions perhaps. It’s so funny… these days when something comes up in SmartThings I don’t try to fix it right away. I just think it MAY fix itself as they keep having issues come up and then they they sometimes get fixed. I’m trying to save myself the aggravation & energy in trying to fix something that had previously worked for months and months.

Oh, and I’m not even going to waste keystrokes on the lousy and absolutely incompetent SmartThings support. They don’t even read the emails. They simply reply to uninstall and reinstall the app and then remove and re-create the automation. The definition of insanity is doing something over and over again and expecting a different result so I’m not going down that path again.

sigh

2

Add location mode away as a precondition in the if clause. It acts like a latch to prevent it from firing if its already set the location mode to home.

1 Like
3

Really? I’m surprised it hasn’t always run when someone leaves. If one of the conditions changes it has to run, otherwise how will it know if it needs to do anything?

4

I don’t want location mode away as a pre-condition b/c I need it to run (and turn off alarm) when I get home late from work some nights. I don’t believe I can have the alarm mode be a pre-condition unfortunately.

5

But your logic wouldn’t be true if it was just 1 person per automation then right? The condition is they are “present”. I guess I’m thinking about them being more of triggers then conditions?

6

You would just need to break this automation into multiples. One per person and have mode away or night in the IF statement.

7

Yes, that is probably the best way to do things if you want something to happen every time someone arrives and distinguishing from departures.

The trouble with automations in general is that it isn’t always clear how they are being implemented. It is perfectly possible for apps to subscribe to particular values of attributes, and also to specify that events have to represent a change. Specific values are OK for ‘if … then …’ type logic, but as soon there is an ‘else’ you need to subscribe to all the values. Also you aren’t always interested in changes in values, only that there is a new value. The more general purpose an app is, the less specific it is going to be, and the more you have do yourself to make sure it does what you expect.

2 Likes
8

Seems something on the backend has changed this as mine has recently started firing my I’m back when I leave the house.

9

Yeah. They definitely changed the behavior. Now the logic seems to look at ANY of your IF statements and if one of them CHANGES, yet another one is still TRUE then it will fire that automation.

I was able to fix it by breaking up the automation into 2-3 different ones.

1 Like
10

It may simply be an artefact of the migration to the Rules API.

We’ve certainly seen issues with location preconditions where they give the appearance of having been removed and behave like they have too (even if that isn’t actually the failure mechanism). That’s certainly a bug.

We’ve seen the Virtual Switch’s ability to act in a stateless fashion seemingly become a factor and typically causing loops, with the behaviour consistent with Automations no longer subscribing to just changes in attributes.

In this thread we’ve seen behaviour consistent with other changes in the subscription mechanism. Yes I’m surprised the Automations ever worked but I don’t mind accepting that they did if that is what other users say.

I’m seeing Automations now largely behaving like webCoRE would with equivalent pistons (and command optimisation disabled). I’ve always written Automations as if that were the case anyway.

2 Likes
11

But webcore lets your DEFINE each IF statement — CHANGES TO, CHANGES, IS, IS NOT etc etc. Total control and transparency. With automations, we really don’t know what they mean by a simple IF statement. Who knows, maybe they change the logic again. We’ll see…

2 Likes
12

Thats part of the exact problem @orangebucket is referring to. It’s behaving like WebCoRE but leaving us to guess which are triggers and which are conditions. I suspect because of ‘usability’ and not wanting to ‘confuse the user base’ with technical ‘jargon’ - unfortunately as you and he both correctly point out… It’s FREAKING IMPORTANT.

That said knowing the Automations moved into the Rules API with the last updates and Ady has a lot to do with Rules API - I’m not suprised it works that way and I can work with it now that I know what I’m looking at. I bet the app team abstracted (possibly on purpose) too much in the UI. - Just a guess.

3 Likes
13

There are things I am trying to say but I am struggling to say them so it is probably best I leave it.

2 Likes
14

Agree 100%. I can live with it now that I understand the logic. But don’t go changing the logic without telling us you changed the logic :slight_smile:

Since you guys are in many of the forums and are in the “know”… I read somewhere about changing my virtual switches to simulated switches instead for some reason. Any insight? Local vs cloud perhaps?

Thanks!

15

No, it’s because the “virtual switch” DTH processing broke in some as Yet unspecified way a few weeks ago so that now many Automations that were set up with the “virtual Switch” DTH started going into loops when the state changed.

The workaround was to change to using the “simulated switch“ DTH instead, which did not have the problem.

But it’s never been fully explained or documented, it was just a community – discovered workaround for the looping Which started to suddenly occur even in Automations which had worked just fine for more than a year. :scream:

Outage Affecting STHM and some automations (19 Jan 2021)

16

And has that all been resolved now?

17

No. People are still using the workaround.

18

Ah I can’t resist it …

The behaviour of the legacy ST platform is to suppress propagation of events when there isn’t a state change. So for the Simulated Switch DTH apps that subscribe to the switch can only ever see on, off, on, off etc. Nothing has changed about that.

The Virtual Switch DTH is different. It uses an option that flags all events as state changes. If you keep turning it on you will see on, on, on, on etc. Some call that being ‘Stateless’. Nothing wrong with that behaviour as it can be useful, and nothing has changed about that.

In the ‘new’ environment you can subscribe to all events, or you can choose to subscribe to only state changes. It isn’t clear how changes are identified. Nothing has changed about that.

A number of users adopted a method to expose their STHM status outside Automations using virtual switches to represent the 3 states being on or off. There were pairs of Automations that did, for example:

If STHM is disarmed then turn on Disarmed and turn off the other two.

If Disarmed is on then disarm STHM.

Well I don’t know know about you, but I just see a potential infinite loop there and so am on guard instantly.

So why wasn’t it an infinite loop?

Well if you used the Simulated Switch DTH or similar behaving ones, it wasn’t a loop because you only ever got the Disarmed switch on event once. The worst case was you could manually disarm STHM, the first automation set the switch, the second automation disarmed STHM again, and then if the first automation ran again and set the switch again the event never propagated. End of loop.

Lots of people used Virtual Switches though and they can keep sending on. So something else had to be breaking the loop. What was it?

Well it could be that you can only disarm STHM once. Except we know that’s not true.

It could be that the Automations were doing webCoRE style command optimisation and only, for example, turning stuff on when it is off. That would be unlikely though. WebCoRE has to pick and choose when to do that (you couldn’t do it with a button for example as the attribute never clears) and has to make it optional. That would be a daft thing to do in an intro level Automation.

What else is there? Well perhaps something is going on at the subscription level and only actual changes are being subscribed to. Not always, you couldn’t do that for a button for example, but sometimes. That’s maybe a possibility.

The bottom line is that I don’t actually know for sure why it worked. I don’t like not knowing, but that’s me.

So what changed? Well Automations moved to the Rules API. Now I only have a few Rules so am not an expert. However given it has to handle ‘if … then … else’ loops it certainly isn’t going to be limiting what it subscribes to by default. It has the same auto / always / never subscription option as webCoRE but I can’t see any option to only subscribe to changes.

Could it be that the mechanism that stopped the infinite loop was no longer there? I don’t know. Does it make any difference? Not to the logic per se. It makes a difference to when the Automation runs and tests its logic. Should that actually matter?

One piece of advice I give to users of webCoRE is to press the Test button now and again. If it results in something happening that you wouldn’t want it to, perhaps you need to think about beefing up your piston. Same with Automations but you have to imagine it at the moment. Shift happens.

2 Likes
19

Hopefully I’m not out of turn for mentioning, but @orangebucket has a banging STHM dth that works in the new app and does away with the extra 2 virtual switches, and WebCoRE can read it, it’s been working flawlessly for the last month, actually I think it should have its own thread because a lot of users could benefit from it.

20

'Tis this one …

https://github.com/orangebucket/Anidea-for-SmartThings/tree/master/devicetypes/orangebucket/anidea-for-security-system-helper.src?ts=4

It is a proof of concept as much as anything. What I haven’t nailed is instantaneously updating display of the STHM status in ActionTiles in a totally satisfactory fashion (the switches no longer being used as indicators). Ironically that is the only place I actually want to use it. I don’t, for example, want an arrival routine to disarm security, I want my security system to know I am arriving and disarm itself. I don’t need an arrival routine to know if my security system is alarmed, I’m still arriving regardless.

But we digress …

2 Likes