Yes I do.
Cool, thats what I expect. It is really strange that you donāt see a sensor for the office remote, but you were getting an error about it before. Is the remote still paired?
Yup. Working like a charm. Paired to wink and controlling 2 GE link bulbs. I have another just like it controlling 2 Cree Connected bulbs. A bunch of picos too. All working fine.
Do you see the remotes in wink@home? If so any chance you could send me the JSON from wink@home for the two remote types?
Did you get it?
Sure did, thanks. Going to add some code into python-wink to ignore them so this doesnāt happen again somehow.
Thanks!
No problem.
HEY! That may explain something else then. I noticed @kevince52 has two binary sensor keys,
binary_sensor.key_1 off
binary_sensor.key_2 off
I have those same two entities and have even posted here asking if anyone knew what they were. Do either of you have any idea where they came from or do you think they could be related in any way to the Relays?
Itās been driving me crazy for months because they just showed up. And I donāt use any secure keys for ZWave.
Yeah they are key codes for a Schlage lock in my case.
Do you have a door lock?
YES!!! AND ITāS A SCHLAGE!!!
OMG, this has been driving me crazy. Do you have your lock paired via ZWave or via Wink?
Wink. I do have OZW but only one device. If I go too far from my Pi it loses connection.
Man, you have no idea how long Iāve been trying to figure those damn things out. Then they must have came over in one of the Wink.py updates, like when the temp sensors showed up for the GoControl PIRs.
Iām so happy right now!! BTW, do you have any idea what they are showing the state of? I really only use one key code as I am alone. Just curious how you knew what those were; I looked everywhere for some kind of documentation of them - it was making me nuts.
Thanks SOOOO much!
When you enter the code that sensor will turn on for a moment. That allows you to trigger events based in who unlocked the door.
I added support for these awhile back, probably my fault for not documenting it well.
I do have 2 codes in mine. 1 my wife and I use and 1 for anyone else that can be reprogrammed. I donāt use them but assumed they did what @w1ll1am23 said.
Oh man, I thought that was something only the ZWave guys could get from the lock; this clears up a whole lot for me.
I almost deleted it from Wink and was going to move it over to ZWave because I thought I was missing something. Turns out I had it all the time.
Thanks so much!
Still seeing similar behavior on the latest stable release 0.36. I setup a command line sensor that looks for that error in the log and notifies me. Each time it fails (sees the log error) I verify if the Wink components are no longer updating in HA.
Did your changes make it into .36? Not in a hurry to update. Just wondering. Got an odd wink error I havenāt seen recently:
Traceback (most recent call last):
File "/usr/lib/python3.4/asyncio/tasks.py", line 233, in _step
result = coro.throw(exc)
File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/core.py", line 1049, in _event_to_service_call
yield from service_handler.func(service_call)
File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/components/light/__init__.py", line 243, in async_handle_light_service
yield from light.async_turn_off(**params)
File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/helpers/entity.py", line 363, in async_turn_off
None, ft.partial(self.turn_off, **kwargs))
File "/usr/lib/python3.4/asyncio/futures.py", line 388, in __iter__
yield self # This tells Task to wait for completion.
File "/usr/lib/python3.4/asyncio/tasks.py", line 286, in _wakeup
value = future.result()
File "/usr/lib/python3.4/asyncio/futures.py", line 277, in result
raise self._exception
File "/usr/lib/python3.4/concurrent/futures/thread.py", line 54, in run
result = self.fn(*self.args, **self.kwargs)
File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/components/light/wink.py", line 115, in turn_off
self.wink.set_state(False)
File "/home/hass/deps/pywink/devices/standard/bulb.py", line 90, in set_state
"desired_state": desired_state
File "/home/hass/deps/pywink/api.py", line 39, in set_device_state
headers=API_HEADERS)
File "/srv/hass/hass_venv/lib/python3.4/site-packages/requests/api.py", line 124, in put
return request('put', url, data=data, **kwargs)
File "/srv/hass/hass_venv/lib/python3.4/site-packages/requests/api.py", line 56, in request
return session.request(method=method, url=url, **kwargs)
File "/srv/hass/hass_venv/lib/python3.4/site-packages/requests/sessions.py", line 488, in request
resp = self.send(prep, **send_kwargs)
File "/srv/hass/hass_venv/lib/python3.4/site-packages/requests/sessions.py", line 609, in send
r = adapter.send(request, **kwargs)
File "/srv/hass/hass_venv/lib/python3.4/site-packages/requests/adapters.py", line 497, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: EOF occurred in violation of protocol (_ssl.c:600)There are changes, yes. Hopefully they address the pubnub issues. I think the issue you are seeing is from polling the api really quickly during startup to get all devices. I see it sometimes and am able to get around it with a few restarts. I made a change in the PR I am working on to cache the response to only poll the api once during startup which should hopfully prevent this.
Sorry, I just reviewed that traceback a little more, that does look different. I am thinking it was an issue on winks side. Maybe they were too slow to respond. Is this continuous or did you only see it once?