[WIP] SmartThings Hello, Home Actions

[jnewland]

Two parts:

SmartThingsHelloHome.js

A SmartThings Hello, Home accessory for homebridge. Both on and off actions trigger named actions that are key to the SmartThings automation lifecycle.

HelloHomeBridge.groovy

A SmartThings SmartApp to be installed in your SmartThings account to generate authentication credentials and JSON config that can be copy/pasted directly into config.json. I'll probably move this to another repo shortly, but I wanted to include it here first so it was easily available for review.

Individual SmartThings 'things' aren't exposed at all in this version. That's going to be a lot more work, and this was enough to make it possible to turn all of the lights of from bed.

/cc @maddox since we talked about this a bit

[maddox]

Weird, your devices are basically actions. Weird right?

On May 16, 2015, at 8:52 PM, Jesse Newland notifications@github.com wrote:

Two parts:

SmartThingsHelloHome.js

A SmartThings Hello, Home accessory for homebridge. Both on and off actions trigger named actions that are key to the SmartThings automation lifecycle.

HelloHomeBridge.groovy

A SmartThings SmartApp to be installed in your SmartThings account to generate authentication credentials and JSON config that can be copy/pasted directly into config.json. I'll probably move this to another repo shortly, but I wanted to include it here first so it was easily available for review.

Individual SmartThings 'things' aren't exposed at all in this version. That's going to be a lot more work, and this was enough to make it possible to turn all of the lights of from bed.

/cc @maddox since we talked about this a bit

You can view, comment on, or merge this pull request online at:

#10

Commit Summary

add bridge to SmartThings Hello, Home actions
back out naming for now, homekit can handle that itself
new SmartThings app generates the full config necessary
rename
fix uri, improve logging
File Changes

A accessories/HelloHomeBridge.groovy (82)
A accessories/SmartThingsHelloHome.js (112)
Patch Links:

https://github.com/nfarina/homebridge/pull/10.patch
https://github.com/nfarina/homebridge/pull/10.diff
—
Reply to this email directly or view it on GitHub.

[nfarina]

So the homebridge "accessory" exposes a single "light bulb" with a switch, but that is just a proxy for executing an arbitrary set of SmartThings "actions"?

[jnewland]

So the homebridge "accessory" exposes a single "light bulb" with a switch, but that is just a proxy for executing an arbitrary set of SmartThings "actions"?

Exactly. Kind of a hack, for sure, but it's working great. Thoughts on a better way to represent triggering a stored action in another home automation platform? I think the use case might be common, but I totally understand if this isn't something you want to support.

I'm definitely interested in exposing individual supported devices in either this or a subsequent "accessory" as well. However, I'd really like to do that with one entry in config.json that queried the SmartThings bridge and then that exposed several accessories rather than a bunch of individual entries. It looks like getServices returns an array, but in my initial tests I wasn't able to make things work with multiple accessories. You interested in issues / PRs towards making that work?

[maddox]

Exactly. Kind of a hack, for sure, but it's working great. Thoughts on a better way to represent triggering a stored action in another home automation platform? I think the use case might be common, but I totally understand if this isn't something you want to support.

This probably isn't the answer you want to hear, but HomeKit supports it's own actions (scenes). So, you set up your devices so that HomeKit is aware of them, then you can add them to rooms (living room, family room), and the rooms to zones (upstairs, down stairs), and then assign characteristics of those devices to actions.

So like, you can create an action named Good Morning. Then you can set what the characteristics of each device is for that action (scene). Here's an example of one of mine:

TV Time

• bulb 1 - off
• bulb 2 - off
• bulb 3 - on, 50% brightness
• bulb 4 - on, 50% brightness
• bulb 5 - on, 50% brightness
• bulb 6 - on, 50% brightness

Then, you can tell Siri to do the action. "TV Time" or "Set TV Time"

This is a bit unfortunate because you have to program HomeKit separately from your other HA systems.

Setting actions in the HomeKitDemo app

Once you have devices reporting back, you'll be able to browse them and their characteristics. You can swipe the characteristic (power state, brightness) and pick Action. This lets you assign it to an action along with the value of that characteristic. It's a bit wonky of a flow, but that's how you do it.

[maddox]

So basically, what your shim is doing is letting actions masquerade as devices, just so you can expose them to HomeKit so you can enact them using Siri.

This isn't necessarily BAD. Because you go what you want. And it works. That's never wrong, heh. But it doesn't really map to how the other shims work, so that part is debatable. And above my contributor grade :)

[nfarina]

I'd really like to do that with one entry in config.json that queried the SmartThings bridge and then that exposed several accessories rather than a bunch of individual entries.

I would be very interested to know if this approach would work. It should be possible to expose separate "switches" for a single accessory. I don't see why the accessory couldn't be "lazily loaded" after first performing a call to SmartThings; although I suppose this may involve some modification to HAP-NodeJS.

[maddox]

This seems possible with just homebridge. It would take refactoring the whole project though I think. Instead of single devices in the config.json, you could instead have an item in it represent a sort of PLATFORM. Like, Wink, or SmartThings. Then instead of creating a device and passing config data into it, the convention would be that you're just passing in some other set of options (authentication creds most likely), and calling something that RETURNS device objects.

Then to implement it, you'd just fire your client to do a search for all devices, and return an array of them yourself, rather than the current approach of creating and caching each device.

Hmmm...

[jnewland]

This probably isn't the answer you want to hear, but HomeKit supports it's own actions (scenes)

Yeah, I got far enough to figure that out. Given that this is all beta level stuff, I didn't want to re-create scenes in Homekit. Maybe the best way to do make this PR fit more cleanly into the HomeKit domain while deferring the larger "bridge everything" project is to simply make it about hooking up single "switches" from SmartThings to "switches" in HomeKit. What would ya'll think about that? Hooking those switches up to perform actions would be up to the user, but I could still accomplish what I wanted and it'd probably be more generally useful.

Then to implement it, you'd just fire your client to do a search for all devices, and return an array of them yourself, rather than the current approach of creating and caching each device.
I don't see why the accessory couldn't be "lazily loaded" after first performing a call to SmartThings; although I suppose this may involve some modification to HAP-NodeJS.

We should all hang out. This is exactly what I'm thinking. I'll experiment and post more when I have time.

[nfarina]

Instead of single devices in the config.json, you could instead have an item in it represent a sort of PLATFORM. Like, Wink, or SmartThings. Then instead of creating a device and passing config data into it, the convention would be that you're just passing in some other set of options (authentication creds most likely), and calling something that RETURNS device objects.

This! I love the idea of a new type of "thing" in HomeBridge that represents a ... well, "bridge" ... instead of overloading the "single accessory" concept.

[maddox]

I think its doable. I'm going to spin something up tonight regarding this. If it makes it even close, I'll open a pull so we can move the discussion there.

[maddox]

I opened #12 for adding support for self fetching of all devices for a platform. We should probably move any discussion about it there.

[jnewland]

#13 is a way more reasonable approach. With that running, I was even able to accomplish my same switch -> "hello home phrase" hack with a handful of virtual switches and https://github.com/jnewland/SmartThings/blob/master/Switches.groovy.