HA stops reporting Wink state changes

Configuration
482

That is truly odd!

483

You know me, so you know that fits.

1 Like
484

I have 3 Wink lights in 2 tabs and all 3 don’t report the status correct in the HA frontend.

485

Hi,

I have run the journalctl and output the result into a log file.
Then I searched via “cat ha.log | grep Traceback” and it didn’t give me any results.

486

Okay, and you are seeing these

[pubnubsubhandler] Polling the API

in the log? No errors around those? I guess it could not be a Traceback. Maybe? not sure about that.

487

Just this:
root@orangepipcplus:~# cat /tmp/ha.log | grep Polling

Feb 24 04:01:19 orangepipcplus hass[32578]: 17-02-24 04:01:19 INFO (Thread-582) [pubnubsubhandler] Polling the API
Feb 24 05:01:19 orangepipcplus hass[32578]: 17-02-24 05:01:19 INFO (Thread-596) [pubnubsubhandler] Polling the API
Feb 24 06:01:19 orangepipcplus hass[32578]: 17-02-24 06:01:19 INFO (Thread-610) [pubnubsubhandler] Polling the API
Feb 24 07:01:19 orangepipcplus hass[32578]: 17-02-24 07:01:19 INFO (Thread-624) [pubnubsubhandler] Polling the API

488

Can you manually check before and after one of those lines for anything that stands out? Or if you want, you can just send me the log.

489

The only thing what stands out is this part of the log (journalctl):

Feb 24 07:06:16 orangepipcplus hass[32578]: 17-02-24 07:06:16 DEBUG (EndpointThread-Subscribe-0) [pubnub] GET https://ps.pndsn.com/v2/subscribe/sub-c-f7bf7f7e-0542-11e3-a5e8-02ee2dda$
Feb 24 07:06:20 orangepipcplus hass[32578]: {‘errors’: , ‘data’: {‘gang_id’: None, ‘icon_id’: ‘61’, ‘last_reading’: {‘brightness_updated_at’: 1487944595.999607, 'desired_powered_ch$
Feb 24 07:06:20 orangepipcplus hass[32578]: {‘errors’: , ‘data’: {‘gang_id’: None, ‘icon_id’: ‘61’, ‘last_reading’: {‘brightness_updated_at’: 1487944614.407949, 'desired_powered_ch$
Feb 24 07:06:21 orangepipcplus hass[32578]: {‘errors’: , ‘data’: {‘gang_id’: None, ‘icon_id’: ‘61’, ‘last_reading’: {‘brightness_updated_at’: 1487944588.491643, 'desired_powered_ch$
Feb 24 07:06:21 orangepipcplus hass[32578]: {‘errors’: , ‘data’: {‘gang_id’: None, ‘icon_id’: ‘61’, ‘last_reading’: {‘brightness_updated_at’: 1487944800.5158858, 'desired_powered_c$
Feb 24 07:06:21 orangepipcplus hass[32578]: {‘errors’: , ‘data’: {‘gang_id’: None, ‘icon_id’: ‘61’, ‘last_reading’: {‘brightness_updated_at’: 1487945175.716062, 'desired_powered_ch$
Feb 24 07:06:21 orangepipcplus hass[32578]: 17-02-24 07:06:21 DEBUG (EndpointThread-Subscribe-0) [pubnub] GOT {“t”:{“t”:“14879451810688012”,“r”:1},“m”:[{“a”:“3”,“f”:512,“i”:"ba93c3d3$
Feb 24 07:06:21 orangepipcplus hass[32578]: 17-02-24 07:06:21 DEBUG (EndpointThread-Subscribe-0) [pubnub] GET https://ps.pndsn.com/v2/subscribe/sub-c-f7bf7f7e-0542-11e3-a5e8-02ee2dda$

I have this in the log only once.

490

If anyone is interested, I broke something when adding support for Robot and Scenes (Shortcuts) like I said above this isn’t in production or even dev yet so it isn’t causing anyone but me an issue. Fix is here Set api fetch default endpoint by w1ll1am23 · Pull Request #75 · python-wink/python-wink · GitHub

491

Not sure if this will be helpful @w1ll1am23 , but when HA stops updating the state of devices, you can manually go in and refresh to get the current state. By this I mean going in to HA, and clicking on services under “Developer tools”. Set domain to “Wink” and service to “refresh state from wink”. This will update the front end to show the current state of everything. It will only work that one time though. You have to go in and manually refresh every time a state changes.

So it is still able to pull the state from Wink, just not automatically. Excerpt from logs when this happens is below:

17-02-24 14:44:21 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 47745321785776: Received {'type': 'call_service', 'service_data': {}, 'id': 10, 'service': 'refresh state from wink', 'domain': 'wink'}
17-02-24 14:44:21 INFO (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=wink, service_call_id=47744465105360-129, service=refresh state from wink, service_data=>
17-02-24 14:44:21 INFO (Thread-8) [homeassistant.components.wink] Refreshing Wink states from API
17-02-24 14:44:22 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_executed[L]: service_call_id=47744465105360-129>
17-02-24 14:44:22 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 47745321785776: Sending {'type': 'result', 'result': None, 'id': 10, 'success': True}
17-02-24 14:44:36 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 47745322095448: Connection closed by client 
17-02-24 14:44:36 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 47745322095448: Closed connection

I am heading out for the weekend, so I will not be available to assist any more until Sunday

492

That’s a good point. I would think if the polling of the Wink API was going to fix this problem, that issuing the service you mentioned (which gets the states from the API) would fix this.

493

Seems like the deeper we dig, the more confusing it gets.

What about coming at it a different way? Since there are some people that are not having an issue, maybe it has to do with the setup.

  • I am running HA in a docker container on an unRAID system (6.3.1)
  • Pulled using Homeassistant/home-assistant:latest (docker version 1.12.6)
  • HA version 39.1
  • To connect wink component I am using email, password, client secret, and client ID
  • Wink Hub SW version 3.5.20
  • Probably not as relevant, but using DuckDNS for domain and LetsEncrypt for SSL

Not sure what else would be useful, but if anyone can confirm what is same/different on their builds and if they are having the issue or not, it may be helpful.

One thing I noticed was that during startup, it would load a component and then state that the component was already loaded. Anybody else seeing that?

494

I’ve seen that in the past, when I had multiple versions of the component out there. I’ve started running this script whenever components can’t load.

(homeassistant_venv) homeassistant@hass2:~$ cat reload_deps.sh 
pip3 uninstall $1
pip uninstall $1
sudo pip3 uninstall $1
sudo pip uninstall $1
pip3 install --upgrade --target=/home/homeassistant/.homeassistant/deps $1==$2

I think this removes the component from anywhere else it may reside on the system, and then forces it to install it in the deps directory under home assistant so home assistant can find it. It requires the component name and version as command line arguments.

./reload_deps.sh component x.y.z for example

495
  • Running HA on Ubuntu 16.04
  • Running dev most of the time usually update every couple days
  • Using email, pass, client secret, and client ID
  • Wink Hub 1 running 3.5.20
  • Using LetsEncrypt for SSL behind an Nginx proxy.

And I am not having this problem.

496

You and I couldn’t have more different setups yet I’m getting issues too.

  • HA is directly running on Windows Server 2012
  • Using the latest version from pip, 0.38.3
  • To connect to my Wink, I use the access token method
  • Wink Hub 2 is version 3.5.23
  • Not using SSL and accessing HA internally

I can also say that I’ve been trying mitigation strategies and gotten some strange results. I’m using a cheap Android tablet as a “control hub” to manually turn stuff on and off. It’s where I have the Wink app installed. Every time I open the app, I get the loading circle in the top right, it never goes away. Sometimes closing and reloading the app will clear it. In spite of that, opening the app fixes my HA issues.

What I did is setup a Tasker task to open then close the Wink app every hour. This has worked perfectly for three days straight until this morning, where HA stopped reacting again, but this time the app wasn’t fixing it. I opened it like three times, force closed the app, nothing would do it. I had to open the Wink app on my phone to get it to work.

All of this makes me feel like there’s something up with the Wink Hub and app themselves and maybe HA is just highlighting the issue. There’s a difference in behavior between my tablet and my phone which was largely cosmetic but seems to have real effects on occasion.

I also tried using a packet capture app on my tablet to see just what the Wink app was doing, but that seems to consistently break the Wink app’s ability to communicate with the Hub.

497
  • Running HA on a pi3 with Debian Jessie
  • Running release most of the time but as of late I am holding on 0.38.3
  • Using email, pass, client secret, and client ID
  • Wink Hub 1 running 3.5.20
  • Using LetsEncrypt for SSL, no proxy.

And I am not having this problem either. Strangely enough, Wink@Home is reporting one Hue lightstrip on that actually isn’t, but HA’s Wink is reporting correctly.

498

Running HA on an Orange Pi PC Plus with Armbian
Running release - at the moment on 0.38.3
Using email, password and in the past email, client secret and client ID.
Wink Hub 1 running 3.5.20
No SSL.

I tried different ways to setup the wink integration but have the issue after approx. 6 hours.
Tested the same setup on an LeMaker Guitar running Armbian. Same issue.

499

Running:

  • HASS AIO 0.39.1
  • Pi 2
  • Jessie
  • Wink Hub v2 FW 3.5.23
  • No SSL (was using LetsEncrypt subdomain of my dev server)
  • HASS Wink with User, Pass, Secrets.

No issues (with Wink) since January.

I too have old devices still showing up in Wink@Home.

500
  • Running HASS AIO 0.38.4
  • Pi 3
  • Jessie
  • Wink Hub v2 3.5.23
  • LetsEncrypt for SSL, EntryDNS for domain
  • HASS Wink with email, pass, client secret, and client ID

I’ve only been running HA for a month or so, but I’ve had the issue since the beginning.

501

I think this may have had something to do with the AWS failures yesterday. I had problems with Wink and other service connections to Alexa and Google Home. Since AWS is back my Wink@Home is correct.