Notification based on presence and alarm system status

Hi, I read the news the other day that WebCoRE is apparently not going to work with SmartThings any more, So I am checking this out to see if SharpTools can help me with what I am looking for.

With WebCoRE, I am able to monitor my alarm system (Honeywell Vista) and have it take certain actions depending on its status. For example, if the system is “disarmed” and everyone’s presence is away, WebCoRE will notify me of this. It achieves this by re-running the piston every few minutes and looking at the above attributes and when true, I get a notification.

I gave this a try here and so far, I’ve been unsuccessful. I then broke it down to just one rule (if the alarm is disarmed for XX seconds, notify me.) Nothing happened. Then I tried to just use one presence status (if I am away for XX seconds, notify me.) SharpTools is able to correctly see all the attributes WebCoRE could see with the alarm system, as well as presence.

I did have an issue with WebCoRE not “seeing” any changes for the above attributes and the solution to this was running the piston every few minutes. I believe this is the same issue I’m having here. Since SharpTools is not seeing any “input,” nothing is happening.

Any suggestions?

Welcome to the community and thanks for posting. Can you share more details about the Honeywell Vista integration? Is it a community developed integration, and if so, can you share a link to the integration?

Thank you, appreciate it. Here’s the link. I can be more specific in the attributes I’m putting in, if needed.

Would you mind PM’ing the the ID of one of the simplified rules? I’d like to a take a closer look and compare it with the integration to see if there are any clues as to why event-based triggering doesn’t work, but the querying for the device state does.

Well, maybe this helps. I just did a test where I had it look for a change to “armed stay” and sure enough, I got immediate notification. I’m almost 100% sure now that I would need a way for it to “check” it every once in a while, otherwise it’s not “seeing” anything. I realize WebCoRE and SharpTools are different, but I think I’m almost there :slight_smile:

Can you share a screenshot of that simplified rule? Just trying to make sure I understand the difference between what’s working and what’s not? If I understand correctly, you have a trigger setup for a certain attribute changing to ‘armed stay’ and an action in the flow to send a notification?

If so, it sounds like the eventing stuff works at least for that attribute… so it would be a matter of figuring out what’s different between that and the initial attempts. Then we can build up from the basics to the more complicated rule you’re trying to achieve. :slight_smile:

Here’s the main part (the other part is just the notification part, which I know works.) I just made this simple.

With WebCoRE, I have it “execute” every couple of minutes. That is the key to getting it to work, otherwise it isn’t 'looking" and I get the same results. There’s no state changed involved.

Thanks for sharing. Is that the working one or the non-working one?

Can you share a screenshot of the other one so we can see what the differences are?

That shouldn’t be the case with a properly working driver. Based on the screenshots Phil shared in the other thread, it seems like event triggered rules in SharpTools should work as he showed some event triggered automations. The only thing I can think is that WebCoRE was running in Groovy and the Edge drivers were fairly new and the translation layer between the SmartThings Groovy environment and their next-gen environment was sometimes quirky with next-gen devices. As a new SharpTools users, you should be using our native next-generation connection, so it won’t have the same limitations as a Groovy SmartApp.

Hmm, interesting. Well, that was the only way I could get it to work. Nevertheless, I’m open to try another way to get it to work. The previous one was the non-working one.

Here’s a working version, that’s how I know SharpTools is properly seeing the status. I believe I used “changes to armed stay”…but the principle is the same. Any change in status is working.

OK, so the ‘changes to’ disarmed is working – it’s just the ‘stays’ disarmed for XX that’s not working?

Was the rule flow on the non-working ‘stays’ one just a single notification action as well? It would really be helpful to have the Rule IDs for the working and non-working version sent via PM (or at least a full screenshot of each rule) so I can see the details. More often than not, when we troubleshoot these things it ends up being some other nuanced detail that caused the issue.

Since the ‘changes to’ is working as expected, that means the event driven side of things is working as expected. Everything that goes in the Triggers section is event driven… so now we would just need to figure out why the rule with ‘stays’ isn’t working as expected.

Exactly. It was a little different on WC, as I used “is disarmed” over there. But again, it acted the same way as here - I had to add the “execute every…” to get it to work. I believe that it might have been that way even when I was on the Groovy version. I realize that it takes processing power on the system to execute automation every so often. I assume that option isn’t available? Let me send this to you.

I don’t see a message button.

I just sent you a PM that you can reply to. As a new community member, you might not have PM access yet. You can also send an email to if you prefer.