Abode contact sensors replacing ST (Iris) sensors

Im considering removing my ST (Iris) sensors from my windows and doors and replacing them all with ones for my Abode system. Only because I dont like the look of 2 sensors on all my windows and doors. It would also cut down on the cost of batteries!

I have approximately 12 Iris contact sensors that ‘would’ go to virtual contacts via the UDTH:

My thought process behind this:
Create a virtual contact sensor to replace each Iris sensor.
Use IFTTT to tie the Abode sensors to Virtuals
Replace the Iris contact sensors with the virtual sensors within all my pistons/automations.

An example of a rule I have is for turning off the HVAC if any window is open, and back to auto when all windows are closed.
If I created a virtual contact I could set up a IFTTT of: If (Abode) formal living rm right is open, then turn on (open) formal living rm right contact sensor. Then make sure my piston for “Window open, HVAC off” is updated accordingly with the new virt contacts

As it sits right now, I use a couple virtual devices with Abode via IFTTT for my Smarttiles dashboard. If Abode alarm is activated, then switch on Alarm Activated (Virtual Device in ST), and If Abode mode changes to standby/Armed, then turn off/on Armed Abode (virtual device in ST)

Other than cloud failure, what would be the negative to this?

@SBDOBRESCU, thoughts? (I still have to set up a virtual switch to re-arm after it disarms if we arrive after its in armed-home mode)

1 Like

Some additional lag if that matters.

1 Like

Cloud failure and high maintenance requirements to keep your system functional are the only two big obstacles. Other that that, I am back at ST/Abode mode synchronization via CoRE to IFTTT and it has been working very well for last couple of weeks. This may be the quickest way to do it. AND you may not even need to create a gazillion virtual devices to increase your point of failure. You can create local variables for each Piston based on Maker input…

1 Like

If I knew how to successfully use Maker to this capacity Id be all over doing this!!! Unfortunately I cannot seem to grasp the concept very well. I find myself to be a quick study so maybe I havent truly focused my time in figuring this out.

Fortunately for me, I dont see any more lag than ST proper, when using IFTTT.

Have you figure out how to enable IFTTT in CoRE?

Yes Its enabled and I fiddled with it while I had a crazy toddler in the house.

Let me know how I can help. I am telling you, @ady624 's CoRE/IFTTT integration was brilliant and once you create a piston, you’ll realize how easy it is to use it…

1 Like

Oh, know exactly how that went :slight_smile: I have two of those around daily…:slight_smile:

2 Likes

Will do. When I get time tonight, Ill see about setting one up myself and see if I can figure it out. If I have to lock myself in my office, I will.

Is there a limit to how many virtual device ST can handle?
Would it be best to just create a virtual switch for the contact sensors, so IFTTT can “control” them? (instead of using the UDTH)

So…the only thing you need to know, really is to match names in CoRE to IFTTT :smile:

No really, here are picture for mode sync pistons and recipes…

Pics updated @Turb02

What is a virtual switch lol…I am using uDTH for everything virtual. IFTTT can flip them on and off like a regular VS…but if everything you do is in CoRE, you don’t need to create anything other than the Piston

Elaborate on this please. Why would this make it higher MX than how it is today?

The IFTTT maker service/channel is just a way for IFTTT to send or receive a Web request.

Core now has the ability to receive these web requests directly.

So you can use the maker channel as the “that” in an ifttt applet and it will send the request to core who will know what to do with it once it gets it. That’s why you don’t need the virtual switch. :sunglasses:

1 Like

Well you depend on Abode channel to work, the ST channel to work. The IFTTT service to be up and running, the ST cloud to function properly so that your virtual devices update…And all of these x 2 because you have incoming events and outgoing events. And IF one of these fails, then you are left out in the dark which one did. Been there, done that. Got frustrated and quit synchronization for a while, but got bored and started over in @bamarayne ’ s style.

What’s my style? I’m confused…

This is where I got confused during my initial death match with Maker (and my daughter).

When I get out of work, Ill post a screenshot of a piston, if someone can walk me through modifying it to use maker and not have to create virtual devices[quote=“JDRoberts, post:13, topic:65426”]
That’s why you don’t need the virtual switch
[/quote]

…to start over …but you haven’t done it in a while…that doesn’t mean you don’t own the copyright anymore. Just ask @JH1

1 Like

Yeah… It’s been awhile…It’s all been running really good. I finally worked everything down to very simplistic and powerful automations… I went through the CoRE thread yesterday just to keep from getting rusty…

1 Like

So this goes back to my statement of other than cloud failure? I mean, arent we all betting on the cloud being available, for a lot/all of HA. Anything in CoRE relies on the cloud…right? Regardless if IFTTT is in the mix.

Well, yeah…but then you add two more clouds to the mix…IFTTT & Abode…