Thanks for the info, I will give this a try this weekend.
Mine is working fine, thanks for sharing. It would be good to put the
access and refresh tokens somewhere other than the thing definition. I
like to keep my config in a bitbucket repo and I don’t really like having
tokens like that in source control…having said that, I don’t really know
if there is a way to store the token somewhere like userdata or something.
It seems that a good contribution to openhab might be some kind of secure
storage of credentials
A couple other things I noticed is that when I restarted my openhab, the
hub and light ‘things’ are showing as UNINITIALIZED even though they appear
to work. Seems like there might be some boiler plate initialization that
needs to be done. I’m a little new to openhab, so perhaps someone else
knows the part that missing there. You’ve also got some info level
debugging that shows up on startup that tests all inboxed objects against
I’ve got some weirdness going on with my hub itself (I assume unrelated to
the plugin) where it seems to go offline periodically even though it has a
strong wifi signal and doesn’t appear have anything wrong with it when it
starts up. I put in a call to support, but would be interested if others
are finding the same issue. Everything works again when I recycle the
power on the winkhub.
Thanks again for adding this.
Hey, thanks for the help guys, I’m now able to add my Wink1 Hub and some light bulbs through the openHAB interface, and now I can control my lights. With a proof of concept going, I’ll start digging through github to see what I can contribute.
That’s weird… It looks like an issue in the PubNub API but it’s not clear to me what could cause this (and this is only a warning).
Ha, that’s good to know! I’ll send a PR asap then, thanks.
Good to know that it’s working for you too! I’ve also observed that the devices temporarily appear as UNINITIALIZED after restarting OH, I need to find a way to tell OH2 to wait for the hub to be initialized before restoring any of the other devices.
And here’s the (WIP) PR: https://github.com/openhab/openhab2-addons/pull/2317 !
EDIT: Didn’t worked, there’s apparently some issues, looking…
Hi Seb! Thanks for responding and sorry to create distractions from your renovations! Thanks to all for the instructions/compiling/other help as well. I will try to install and see how I make out. Looking forward to seeing this officially supported!
I had this problem with one of the two v1 hubs I have (rooted). Moved it around to several locations but could never get it to be reliable. Seemed to happen after upgrading my wifi network but could have been unrelated. I upgraded to a v2 and it has been rock solid since then.
Good news, the compiled binary is now available in the Artifactory! Now I’ll just have to clean my code, add more tests and document it to turn this WIP into a real PR
So glad you guys are working in this. I just purchased the Wink 2 (partially because I saw that you were working on support and wanted to be able to do more sophisticated things down the line). Going to setup the Wink 2 tonight, with a few basic bulbs, then a thermostat is next followed by garage door sensors/control. My plan is to get things working on a basic level with the Wink 2 hub, then “graduate” to doing some more sophisticated things with rules (i.e. garage door being left open and etc.) with OH2. QUESTION: Is this binding ready for testing (maybe in the alpha/beta state) or is it still too early?
This binding should work fine to control some basic light bulbs / dimmers. I’m using it right now to control both a dimmable light bulb and an in-wall dimmer and it works fine! I’d love to try to handle RGB light bulbs (e.g. the Hue) but I don’t have any
I’ll try to add support for more devices but most of the things that I have are already compatible with OpenHab (e.g. my Nest thermostat, my Insteon stuff…), so I don’t really need to use Wink for them.
The next thing that I’ll add is a support for the “remotes” objects , you can see the full list of device types in the Wink API doc: http://docs.winkapiv2.apiary.io/#reference/device/wink-devices
My goal is that the API will be clear enough so anyone who want to add support for a device type will be able to do it relatively easily (assuming some programming knowledge).
Thanks so much for the personal reply. Working with light bulbs for now would be great. I’m just trying to take some baby steps. I got OH running on the Pi2, so I got that far. Hoping to set the Wink2 up tonight. I’ve I can just take small steps over time that is fine. I’m not a dev, but can do some scripting and such, so by reading enough examples and forums I can figure most things out. So to set this up, I just #1. go to the Artifactory link, download the JAR. #2. Copy it to the Pi add ons folder (in my case: openHAB-share\openhab2-addons, I can see this folder via Samba) #3. Reboot the Pi. #4. Go to the OH web dashboard/Paper and follow the typical instructions to add a binding. #5. then go follow directions else where to interact with bindings/device? Does that sound correct?
That seems correct! I don’t think that you need to restart OH for it to pickup the binding (I usually just drop it in the addon directory and it get picked up automatically).
In the PaperUI you should be able to click on “Search For Things” and see your devices (I need to make sure that the hub is the first device that you see, i.e. that you don’t see the other stuff if the hub isn’t configured). You’ll need to get your access_token and refresh_token with the Home Assistant webapp: https://home-assistant.io/components/wink/
I’ve enabled the issue tracker on my GitHub fork if people want to report some bugs that should be fixed before pushing this to OH.
Ha! Sorry I just saw this! Thanks for helping me!
I doesn’t look like you can do a fork of a fork on Github… Not sure what’s the best way to collaborate…
@Kai : what’s the best way for Scott to help me? Should I try to finish my initial version of the binding asap so Scott will be able to fork the main repo instead of trying to fork my fork?
Thank you, sir! That is exactly what I needed to know. It might be a week or so, but I will definitely report back.
Scott can for the official repo and add your fork as a git remote to it. He can then simply check out your branch, add commits to it and push it to his fork in Github. From there, it is possible to create a PR against YOUR fork, which you can then review and merge (which will make Scott’s commits become part of the “main” PR against the official repo). Sounds complicated, but it is really rather straight forward Maybe this stackoverflow post explains it better than me.
Perfect, @scooter_seh are you comfortable with this approach? Your contributions are welcome!
I think I can figure it out. I just have to spend some time working on it.
I was able to control a light with it, so I’m psyched! Will try to do a full implement over the weekend to see how things work. Very excited as this appears to control my Commercial Electric downlights - hopefully it’ll control color temperature…