Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] SmartThings Hello, Home Actions #10

Closed
wants to merge 6 commits into from

Conversation

Projects
None yet
3 participants
@jnewland
Copy link
Contributor

jnewland commented May 17, 2015

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.

img_0369

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.

img_0370

/cc @maddox since we talked about this a bit

@maddox

This comment has been minimized.

Copy link
Collaborator

maddox commented May 17, 2015

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

This comment has been minimized.

Copy link
Owner

nfarina commented May 18, 2015

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

This comment has been minimized.

Copy link
Contributor Author

jnewland commented May 18, 2015

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

This comment has been minimized.

Copy link
Collaborator

maddox commented May 18, 2015

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

This comment has been minimized.

Copy link
Collaborator

maddox commented May 18, 2015

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

This comment has been minimized.

Copy link
Owner

nfarina commented May 18, 2015

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 comment has been minimized.

Copy link
Collaborator

maddox commented May 18, 2015

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 comment has been minimized.

Copy link
Contributor Author

jnewland commented May 18, 2015

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

This comment has been minimized.

Copy link
Owner

nfarina commented May 18, 2015

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

This comment has been minimized.

Copy link
Collaborator

maddox commented May 18, 2015

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 maddox referenced this pull request May 19, 2015

Merged

Platforms #12

@maddox

This comment has been minimized.

Copy link
Collaborator

maddox commented May 19, 2015

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 jnewland referenced this pull request May 20, 2015

Merged

SmartThings platform #13

@jnewland

This comment has been minimized.

Copy link
Contributor Author

jnewland commented May 20, 2015

#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.

@jnewland jnewland closed this May 20, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.