Offering to implement the Wink Hub 2 bindings


I recently got a Wink Hub 2 and I’d love to integrate it with my setup (OH2), as there’s apparently no binding for it yet I’m offering to start working on it.

I’ve already done some local testing and I’m able to connect to the hub, list the devices etc (haven’t tried to push a command yet but it shouldn’t be too complicated). I’m also looking at their subscription service (based on pubnub) to be notified when a device state change. The only downside of my approach (and of this hub API in general I think) is that it relies on the cloud (I haven’t find a way to query the hub directly yet).

What’s the typical process to work on a new binding? Should it be first approved by the project’s maintainers or should I just do it and send a pull request? (I also want to make sure that nobody’s already working on it, if it’s the case then I can maybe just help this person).


1 Like

The best approach I’ve seen here is to:

  1. Start a discussion here
  2. Implement a prototype
  3. Post the prototype to the discussion thread for testing purposes
  4. Once OK with the testing and having an initial version, submit a pull request
  5. Wait for approval

You’ve started 1 so I think you are well on your way.

While I and others would much rather have a way that didn’t require a cloud service, we are all aware that isn’t always possible and there are several bindings that require cloud services to work as well.

Sounds promising as I think the current binding requires one to root their hub to make it work (could be wrong on that, don’t have one so haven’t really kept up).

Yeah, rooting the hub was required with the first version, the new hub is called ‘Wink Hub 2’ and there’s no way to root it yet.

Even if there was a way to root it I’m not sure that everyone really want to go this way, afaik it requires to open it and to do some soldering :confused: so it’s not accessible to everyone (and it obviously break the warranty). The latency of their cloud service seems pretty good (but I’ve a pretty good internet connection), so I’m not too concerned about the performance of it (but I don’t know how reliable it is).

I’d really like to not use the cloud service, but I’ve looked at the TCP traffic going to the hub and everything’s encrypted, so I’m not convinced that we’ll be able to find a ‘clean’ way to do it (i.e. even if I find the encryption key and the structure of the messages then I don’t think that I’ll be willing to publish this code, I prefer to stick with the official API).

I’ve started to work on the binding, so I’ll share the prototype as soon as I’ve one :slight_smile:, feel free to contact me if you want to help or if you have some suggestions/comments!


I would very much like to contribute. I don’t have any experience with openHAB, just installed it and realized that there is no Wink API integration at this point. I need it because it is the only way for me to get my cameras to send me motion detection events. I was planning to setup the development environment and start looking at some samples for ideas, but it would certainly be better to join someone with experience and help.

Hi Tony!

Thanks for offering to help! I’ve been quite busy last week (travelling) but I’ve still made some progress on the bindings, most of the code lives in my fork here:

Note that this code isn’t really documented yet, I’ll clean it up and some comments as well as some details about the architecture of this binding later this week.

Note that in its current implementation the binding works by polling (rather than being interrupt driven), and so I’m not sure that you’ll be able to get a notification when an event is detected (you can regularly poll the camera to check if it’s detecting something but that doesn’t seem ideal :slight_smile: ).

I think that in order to get a notification you’ll need to use their PubNub subscription service, in theory you should be able to subscribe to an item when you set it up in OpenHab2 and be notified when its state change. In practice it’s not that easy, adding a dependency to the PubNub library in my binding introduced a lot of dependency issues so I gave up, but if you can get it to work that’d be awesome! I’ve tried to do this but I gave up (I wanted to focus on writing a really simple binding first, and then add the fancy stuffs), you can check this commit for some idea on how I was trying to do it.

I think that you should start by trying to use the PubNub subscription service independently of OpenHab (in a simple Java project) to make sure that it can achieve what you’re trying to do (getting notifications when a there’s motion event). If you’re familiar with Python you can use this API (or this one) to handle the communication with the hub.

Note that for all of this you’ll need to get your client_id / client_socket pair from Wink, you can get them by sending an email to or by pinging them on Twitter.

I’ve made progress on the bindings (I can now setup the hub, discover the light bulbs I have and control them in OH2), but it looks like I’ll need to get the PubNub integration to work if I want to avoid polling the devices for their state (I thought that there was a BaseThingHandler method to refresh the channel state when it appeared in the UI, it look like I was wrong).

I’ll take a look at this later this week.

I got it to work!

Did you get PubNub to work? I started looking at the PubNub API (4.4.1) and will try to work on the stand-alone version as you suggested.

Yes, I’ve a PoC of PubNub working in my binding implementation, it was much easier than I thought.

I’ve refactored and commented my code a little bit yesterday, I’ll try to make more progress today. I think that you should start setting up your OpenHab Dev environment now, once I’m done commenting and refactoring I’ll need some help to implement the handlers specific to each device type.

I just wanted to double-check my understanding that we are going to be using “Sign in directly using password flow” call:
“client_id”: “consumer_key_goes_here”,
“client_secret”: “consumer_secret_goes_here”,
“username”: "", [to be configured by user]
“password”: “password_goes_here”, [to be configured by user]
“grant_type”: “password”

  • It is unclear if we should request a single client_id / client_secret for openHAB?
  • I have come across some plugins (for other home automation servers that used client_id and client_secret from Wink IOS/Android apps. Is this a viable strategy?

Hum, I thought that the client_id/client_secret pair was tied to your hub and that because of that we wouldn’t be able to use a common one, but I might be wrong (and I probably am! Haven’t really looked at this). That’d be ideal!

I think that I’ll provide both options, sign in with your account information or just provide the authentification and the refresh token.

I’ve reached out to Wink to see if we can use a single client_id/client_secret pair for all the users of this binding, I’ll update this thread once I have an answer.

In the meantime, does someone know if we can use the redirect_uri approach? I’m not really familiar with Oauth2 but I think that it’d be preferable (rather than asking the users to store their password in clear text in the config file)


Here is what I got from Wink support.

Thanks for your interest in the Wink API! You’ll receive your personalized credentials in about one to two weeks, but first we’ll need just a little more info:

  • The email address associated with your Wink account
  • The name of your application
  • A brief description of your application
  • Any associated websites

It seems that the client_id/client_secret is allocated per “application/website” and not per user/device, so I think if you already got one from Wink for openHAB, we should be able to hardcode it into the plugin.

Awesome, I’ll wait for a direct confirmation that I can share my client pair before pushing it to Github but it’ll make the setup of the binding much easier!

I just realized that the “sign in directly using password flow” is discouraged:
      “This request is rare. Clients are generally not permitted to use this flow.”

Instead it seems that we should use the redirect URI approach:

I’m still relying on the client_id/client_secret pair in my app for now (as I’m not really familiar with the Oauth2 flow), but other than that it’s working fine, I’ve a 2-way communication between OpenHab and Wink (changing a light brightness in Wink update the status in OpenHab and vice-versa), the discovery service works fine and I just need to add more comment and documentation.

Only the light bulbs items are supported for now, I’m working on also supporting the remotes but after that I’m not sure of which device type I’ll add.

The code for the binding lives here: , I’ll finish my cleanup and I’ll send a PR.

is this effort still underway? I’m very interested in getting OH2 working with my original Wink hubs…

Yes I’m still working on it (in fact I’m mostly using it now, it works fine on my side). I need to clean the code a little bit and push it to the main OH2 repository.

Note that this is only for the Wink Hub 2, I don’t know if it’ll work with the original hub (but it shouldn’t be too hard to add support for it if the original hub supports the new Wink API.

Currently the binding support any “light” item that you can add in Wink (regardless of the device’s type) and the remotes.

Note that I’m on vacation with limited internet access this week, I’ll try to finish the v1 of this binding next week.

Cool. Let me know if there is anything I can do to help test. Will buy a Wink 2.0 hub if necessary.

Also interested! looking to buy one, thanks!