-
-
Notifications
You must be signed in to change notification settings - Fork 33.8k
Support for Wink local control #8607
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
Conversation
@w1ll1am23, thanks for your PR! By analyzing the history of the files in this pull request, we identified @fabaff, @balloob and @rmkraus to be potential reviewers. |
It works, but it actually seems slower in some cases than running non local. This could be just a 'feels like' thing and I'll need to do more testing. But I am able to control all switches and lights so far. Other than that, it works and there are no errors to report. |
Still working and no errors. Still on the slower side though. |
@rpitera thanks for testing. I agree it is slow at times. It might be something we should continue to leave defaulted to off. I did notice a strange issue with mine the other day where the requests being made to the hub weren't responding. Power cycled my hub and it started working again. Going to put a fix in to python-wink for timing out after a few seconds and then sending the request online. |
I'm guessing the real value of this won't be realized until Wink's API goes down. Assuming this will still allow you to control some things, right? In that case, it may be worth leaving activated. |
It should work, yes. However the updates are still handled by pubnub so state changes won't be picked up. Maybe polling should be enabled when local control is enabled? |
I don't think it would have a performance impact. Let me know and I'll test it. |
951aafc
to
2df2c4b
Compare
@rpitera Looks like polling the hub doesn't work too well. The hub doesn't keep up well and it starts dropping those requests. However, the local request appear to return quick enough in most cases to update the device from the requests response. This should mean that in the event of a Wink API outage the state changes should keep working. I updated python-wink to forward all failed local request online as well. So if there are any errors during the local call the request should get sent online in ~ 3 seconds. In this event the state change will be much slower, but it should eventually happen. |
* Support for Wink local control
I'm waiting on Wink to send me my tokens so I can't use this yet, but has anyone tested this with a Wink Relay instead of a Hub v1 or v2? |
@xelprep the relay doesn't support local control. I have not personally tried it, but I was informed by the person to figured it out, that the relay doesn't respond. That means relays are hardcoded to not even try local control with python-wink the library homeassistant uses. |
* Support for Wink local control
Description:
Support for Wink local control on Wink hub v1 and Wink hub v2
This supports lights, locks, and switches.
The default is to have local control disabled. It will only be enabled if the below config is used.
You also must be using some form of oauth for this to work, the username and password authentication will not work and is disabled even if the below config is used.
I would love for some people to test this as I have only done limited testings
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here>
Example entry for
configuration.yaml
(if applicable):Checklist:
If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
tox
run successfully. Your PR cannot be merged unless tests pass