Integration with IFTTT

I was a bit impatient waiting for the RADIORA2 IOT Gateway (coming in march), so I coded a quick hack to allow for me to send TELNET commands through the web using IFTTT/hook.io/etc.

Very simple... the device connects to my local lan, opens a TCP connection to the Lutron RadioRA2 controller, and then publishes a function through the Particle cloud to allow for any of the integrations to call it directly. Only one input: the command, which gets sent directly through to the telnet session. Haven't handled any error cases yet like reconnecting, but if someone wants to spend the time, please do so ;)

The code is available here (written for a Particle Photon):

https://github.com/rowantrollope/LutronController

Now I can turn my lights on/off with a GEO fence, and so on.

The code is extremely rudimentary (only one way), but can be improved by anyone who wants to make simple changes to allow for queries of device states and so on.

The only question I have for this community is how do you enumerate the NAMES of the devices and the ROOMS and so on? It doesn't seem to be possible with the telnet API.

Have made a bunch of modifications to the base code now. Robustness and reliability now vastly improved.

LutronController now will stay connected and publish events for every device level change.

So now you can set events both ways in IFTTT (watch for LUTRON device events, then take actions, setting other settings, etc).

First simple use case of this is a simple wireless button for turning on and off lights (For $15 vs. the many hundreds I had to pay for the Lutron wireless switches).

Second simple use case is to turn on the exterior lights based on GEOFENCE

Third simple use case of this is to have an iPhone app which allows me to read the settings for every light, save that as a scene and recall it at will... (also unsupported on current Lutron App)...

Rowan

Hey Rowan,

This is pretty cool. Do you have experience in programming languages? What language is this written in to communicate with the unit over telnet? Thanks for any help you can give me...

Jamie

Very cool! To get device names, I think you'll need to get the DbXmlInfo file over HTTP.

Quote:

---

Originally Posted by Feenypower

Hey Rowan,

This is pretty cool. Do you have experience in programming languages? What language is this written in to communicate with the unit over telnet? Thanks for any help you can give me...

Jamie

---

Looks very similar to programming arduino so I'd say object c, definitely some c language variant...

The protocol to speak to the repeaters via telnet is documented. A new revision just came out in January:

http://www.lutron.com/TechnicalDocum...ary/040249.pdf

There's no "programming language" involved here. It's just ASCII text commands. You could use any programming language to speak to it, provided you had one with a telnet library. Python, perl, C, Java, etc, it wouldn't make any difference.

Nor is there any specific programming language that the Bridges use to communicate to the cloud services Lutron is using. It's just a protocol, but it has not been documented anywhere by Lutron.

Quote:

---

Originally Posted by rowantrollope

Third simple use case of this is to have an iPhone app which allows me to read the settings for every light, save that as a scene and recall it at will... (also unsupported on current Lutron App)...

---

In fairness, Lutron's scenes aren't just on/off commands. They're capable of a lot more. That and a scene across multiple devices sends only ONE command on the wire. This allows controlling all of the lights together. This avoids the 'popcorn' effect where the commands are sent one-after-the-other. This also lessens the amount of programming and command traffic, potentially avoiding other complications.

It would indeed be convenient to have a simpler way for field tweaks to be done to lighting scenes. The windows program is currently the only way to do this. It's free and worth signing up and learning to use.

As for geo-fencing, bleh, nothing does geo-fencing well enough to be trusted. I'd love to have it, but basing it on a phone or other device without a LOT of additional programming logic ends up with it getting it wrong a LOT more than it ever gets it right. It gets even worse when you have multiple occupants, or have cleaning or other working personnel that need to be on site.

Quote:

---

Originally Posted by wkearney99

As for geo-fencing, bleh, nothing does geo-fencing well enough to be trusted. I'd love to have it, but basing it on a phone or other device without a LOT of additional programming logic ends up with it getting it wrong a LOT more than it ever gets it right. It gets even worse when you have multiple occupants, or have cleaning or other working personnel that need to be on site.

---

Slightly OT, but I've been using an app called Skylark on my phone to control home/away on my Nest thermostat for about two years now. (We have pets at home that trigger the Nest motion sensors and prevent it from handling home/away effectively by itself.) It understands that there are multiple phones in the household and only triggers away mode when all of them are outside of the geofencing radius. It has a guest mode that disables the geofencing when you have guests staying with you. It works extremely well and doesn't add any signigicant battery drain.


It doesn't work with RadioRA2 unfortunately. (I really wish it did!) But I just bring it up here in relation to your comment above. Geofencing CAN work very well if it is designed properly.

The "designed properly" problem plagues all kinds of things.

How something determines "presence" is like the question for the Fountain of Youth. Rumors of it exist, but it's never been found. Especially problematic when tools aren't available on enough platforms.

For me the big issue is false triggering, like leaving the house, but having forgotten something, coming right back within a few minutes. No need to have house start firing off a series of "welcome home" activities, or likewise have to then go do the departure ones all over again. Or your device battery dies and the system mistakes that for a departure since the device "is gone". Or, ugh, the list of wife-annoying potential problems is just too many to list.