I’ve been getting that one too.
Going to send an email out to pubnub to let them know how it is going. Can you confirm if everything is still working okay?
No pubnub errors since the change. Thanks for your help on this. 
1 Like
Fantastic. More than happy to help, want to make the Wink component the best it can be.
Finally in a position to test this now so I have installed it and am restarting - will let you know how things shake out.
Sorry for the delay - I’ve been struggling with trying to get moved over from WiFi to Ethernet and had to give up. For some reason I cannot get eth0 to work with a static IP.
So far so good, except I get a configurator message about wink.fan not being set up properly. I know you have a PR to put fan support in but I don’t have any Wink supported fans so I’m not sure how I got that message or how to remove it. (Unless it sees the fan attribute in my ecobee3 as a ‘fan’?)
It seems much snappier now and switch states seem to update quicker. So far no error messages.
Cool, glad it is working better. You can ignore the fan error, that is because you are missing the new files needed for fan support. It is basically trying to call fan/wink.py which doesn’t exist. If you want you can change the wink.py in your custom_compoents directory and remove the ‘fan’ from the end of the list towards the top of the file.
Took that out and restarted now everything’s groovy again. 
It could be my imagination but Wink feels so much more responsive, both in the time it takes to respond to a command and the time it takes for a state to show updates. Is it?
I m not sure, mine has been pretty snappy for awhile now but I wasn’t getting the errors you guys are. I wonder if so of your pubnub issues were because of being on WiFi?
For the static IP I assume you are trying to set it on the pi? Have you considered setting it statically with your router?
So I have all of my devices setup on my router in dhcp with a specific mac/IP combo. That way all of my devices just use dhcp, no changes on the device, but they always get the same address.
Well that was one of the reasons I wanted to try moving over to rule that out. I’ve been having some issue with things timing out in the logs and I wanted to make sure I wasn’t adding to the Wink issue by having the Pi on WiFi.
I have a FiOS router and it’s not the most user friendly thing in the world so I’d have to figure it out, but I can’t see why setting eth0 to the old IP of the Wifi, then blacklisting the Wifi modules so they don’t load and clearing the DHCP caches didn’t seem to work for me. Even rebooted the router.
I guess I need to look into this again…
Because in the scenario you seem to describe, the router could then re-issue that IP to somebody else at some later time causing a conflict. The two options when setting a static on a device is, assign the mac address in the router as a reserved IP/MAC, or, assign your static outside of the pool that is reserved by the router for assignments.
Thanks guys; I think I have figured out how to get this set up in my router and I’ll give this another shot.
Proposed steps:
-
Set up the mac for eth0 in router to use the current Wifi’s IP (because I have a number of things tied to that IP address like AWS, port forwarding rules, etc.
-
Set up eth0 on the Pi to be active again and use DHCP
-
Blacklist the WiFi modules again and then shut down the Pi
-
Plug in the ethernet cable and restart
-
Profit???
Does that sound right?
Yupp, looks good to me.
Yep. If it’ll let you reserve the IP address while in use. Can’t see why not.
With an active DHCP server you’re gonna get a conflict unless it’s out of the IP range. Sounds like you want a specific IP though.
Yeah; I’d like to use the IP the WiFi connection is currently using so I don’t have to go and change everything else that is associated with it like port forwards and other things that caused HA to have a fit when I brought up the eth0 by itself with the new address.
I might give this a shot tomorrow then. I think I’d like to move my Acurite weather interface off the router and put the Pi in it’s place so it’s right off the router instead of the switch on the other side of the office.
- realized I hijacked the thread with my IP problems - SORRY!
Back on subject, I still have received no Wink errors or issues and everything seems to be working better than usual on the Wink side.
Awww, crap snacks!
Went to my page this morning and saw that my Osram landscape lights were still reading “On”. Tried to turn them off and it just went back to On state. Checked the lights themselves and they were off.
Found this in my logs:
17-01-09 19:08:35 pubnub: take message interrupted: 'NoneType' object has no attribute 'loop'
Dang, okay can you verify that you have pubnubsubhandler version 0.0.7? Should see it in your deps folder.
Yep. Folder date is from yesterday when I restarted with the new code in custom_components so that checks out.
Also missed this, which was right above it - sorry:
17-01-09 19:08:34 homeassistant.components.wink: Error in pubnub JSON for Wink Relay hub polling API for current state
Anything else I can look at?
Nope, that’s all I need. I’ll forward it on to pubnub and see what they say.