Is anyone working on a binding for a rooted Wink hub?

Add-ons Bindings
1

I did some searching in the forums but didn’t find anyone talking about the wink hub.

The Wiki has a couple of pages under Application Integration for the wink hub, but they’re really workarounds, not a real binding.

I was thinking I’d try to put together a binding but I don’t want to duplicate the effort if someone else is already working on it.

1 Like
2

The issue you will likely find is that it won’t be a “binding for rooted wink hub”, its going to be “binding for rooted wink hub that has interface installed onto it”.

Short of using the exec binding to ssh into the hub and execute aprontest, the Wink hub has no interface on it that you can tie into. It does however have a web server & PHP support, so building a simple API to aprontest is rather trivial. I believe some actually already exist. However, just keep in mind that at that point, you are creating a binding for that specific API, not for the more generic rooted Wink hub.

As I mentioned already though, you can also just use OH’s exec binding to interface with the hub over SSH to execute aprontest. This doesn’t require installing anything extra onto the hub. It will however not be as responsive as using a simple HTTP API due to the overhead of setting up SSH connections VS. http(s) connections.

3

I see two possible future directions for using a rooted Wink hub:

  1. Wait and see what direction Flextonics will take in finishing or not finishing the partially implemented (but disabled) local control API which was part of the last hub update. Flextronics is the company Wink hired to do the heavy lifting for the design and manufacture of the hub itself so they have a vested interest in selling more hubs. From what we know the local API runs under node.js and from what I can tell from looking at the code they are trying to stick fairly close to the existing public API which is already using with Wink@Home, and to a limited extent with OpenHAB and other HA platforms.

  2. Make use of node.js and create an open local API which will end up offering more functionality than the officially released one.

While future direction #1 is pretty clean and easy, future #2 would be a better bet for the Maker community.