Is this typical behavior for HA?

Configuration
1

I have a Wink Hub 2 and I understand there is latency issues with Zigbee and to some extent Z Wave. I’m running HA on Mac OS X Sierra. And usually use it in Safari browser.

I have some Orsam Lightify lamps (2) and just added two GE in wall switches. On the Lightify (zigbee) when I turn the bulbs on they respond very quickly (quicker than my understanding of the latency issues) but the slider on HA will turn to say the On position, then the slider turn offs then about 5 seconds later slides back into the on position.

The GE lamps do the same thing only much quicker, however they don’t do it all the time. If I turn a light on first thing in the morning it also could turn on and the slider then go to off and stay there which makes me open the Wink app and set the light state and then all is seemingly well. It’s almost like it isn’t waking up correctly.

All I have for my wink settings is the access token.

Is there anything else to do or is this just normally the behavior with Wink Hub 2?

2

And I’ve just noticed my switch state when using the switches manually don’t report correctly to HA. I find some discussion on polling timing but they seem to be using the Z wave stick on Raspberry Pi. I’m using Wink Hub 2 and HA is on Mac OS X

3

With the latest Wink update and/or the latest HA version (they came out about the same time), there is an issue with the status from wink not getting reported to HA in a timely manner. I’m not sure which side of the equation the problem is. I’ve seen the On then off then on again behavior before. I’ve always attributed it to wink being a little slow responding. But since the latest version of Wink and HA, it’s started getting worse so that it’s actually impacting my automations.

4

I’ve found this to be pretty much standard ops with switches/lights via Wink. It’s gotten much better in my case since the last Wink HA update and doesn’t happen on all my devices. I always attributed this to the latency in sending the state to pubsub (pubnub?) and then getting the state returned to HA.

Perhaps @w1ll1am23 can comment on this and give a better explanation as to what’s going on.

5

If it is getting worse, it is probably a temporary issue that pubnub is having. I see some days where the pubnub updates are slower than other days.

The on/off/on issue is annoying, I will explain why that happens.

  1. user changes state
  2. Wink API gets a request for the state change and responds back to python-wink with the JSON state of the device. (This isn’t the new state, but the current state + the desired state)
  3. Pubnub gets that new state as well, and forwards to back to HA, which is what toggles the state back to off.
  4. Then… approximately 3-4 seconds later the state is actually changed and that state is pushed out over the pubnub network. pubnubsub-handler gets that state and pushed it over to HA which pushes it to python-wink, which updates it cached state and then HA pulls that state from python-wink.

Also I am not sure why it only happens with bulbs, but I think it is because switches just work quicker.

1 Like
6

That flow explains a lot :slight_smile:
Thanks

7

I updated the above post, in step 3. Pubnub is what is turning the light back off. I am not sure there is a way around this.

8

Thanks for looking into this. Does this issue occur with the Aeotec USB Z Wave stick? The way around it for me will be to ditch the Wink for Z Wave if so.

9

Well since most bulbs are ZigBee, the zwave stick won’t be able to control them. Based on my devices/testing I only see this issue with my bulbs which are all ZigBee.

You should see if your experience is better with the next release. It has a bug fix for state changes failing to update.

10

The two zigbee lamps I have are kind of working okay by my estimation. The GE Z wave switches I installed in the wall are problematic for me. When I turn them off manually they don’t report the correct state unless I restart HA. If the Aeotec stick fixes that I’m good.

11

Interesting. The zwave stick may fix that, but I am not sure, I don’t use one. Are you seeing any errors in your logs? It sounds like you may be having an issue that is already fixed in dev.

12

There’s a development branch of HA? How do I try it?

Right now I’m at work VPN-ing in my network and I have HA set up on Mac and Raspberry Pi. When the GE z wave lights misbehave I can open up the wink app and change state and then close the app and then the GE lamps work fine but only via HA. If I manually hit any switch it won’t report state without a restart of HA. I have a single switch in one room and a GE switch and add on in another room.

I have a Lifx bulb that works perfectly everywhere. Worst case I replace my Lightify lamps with Lifx but these GE switches are bought, paid for, and installed. I really need these guys to work.

From what I read in the forums here you can change the polling time with the Z wave stick. I’ve read several folks having success with the tweak added to the zwave configuration. I have a stick coming in the mail tomorrow.

13

I just found the dev update and am running it against my pi and rebooting now. Will see in a few how that works.

14

Okay I installed dev on my Pi and my kid is at home turning on and off the lights and it is working! At least so far. Slow but part of the slow might be me VPN-ing in with a crappy cell phone connection.

Now I have to figure out how to auto start the pi with the dev branch :slight_smile:

1 Like
15

So then I was right about this. I’m glad I’m starting to understand this better; working with you has been a big help.

16

I had my daughter run through another set of on off wait on off with all the switches and the add on switch and it is all working great with the dev branch on Raspberry Pi.

Now to back up configuration.yaml, wait for the update to stable and then go backwards. Even the Lightify lamps are behaving a little better.

Thanks for the help.

1 Like
17

This weekend’s the next release. Right???

18

Is it? There’s usually a PR for the new version in already before the weekend and I didn’t see one yet.

<checks github. shakes head>

Just went up a few hours ago! I guess we’ll have a short wait!

19

Can you downgrade from dev as per the instructions? Or just from stable to stable?

20

I have a repeatable example of this happening with a switch. It’s especially noticeable with dimmers. I have several GE Smart in wall dimmers. They turn on really fast. But when turning off, they dim to turn off. Watching the state changes, I send a command to turn off the switch with AppDaemon. The light turns off but I get a state change telling me that the light is on, but dimmer. Then after a variable amount of time (sometimes up to a minute) I get another state change message telling me that the new state if off.

2017-02-15 09:45:46.798158 INFO light_control: entity light.den_fan_light, old off, new on current state{'attributes': {'supported_features': 19, 'friendly_name': 'Den Fan Light', 'manufacturer_device_model': 'ge_jasco_dimmer', 'brightness': 48, 'device_manufacturer': 'ge', 'model_name': 'Dimmer'}, 'entity_id': 'light.den_fan_light', 'last_changed': '2017-02-15T15:45:46.776951+00:00', 'last_updated': '2017-02-15T15:45:46.776951+00:00', 'state': 'on'}
2017-02-15 09:45:46.802341 INFO light_control: entity=light.den_fan_light, old=off, new=on, attributes=state
2017-02-15 09:45:46.817661 INFO light_control: entity light.den_fan_light turned on
2017-02-15 09:45:46.820790 INFO light_control: light light.den_fan_light is a dimmer. Turning light 50
2017-02-15 09:45:46.822894 INFO light_control: light=light.den_fan_light brightness=50

Turned off Light Here and physically light dimmed out pretty quick, maybe 2 seconds.

2017-02-15 09:45:55.804223 INFO light_control: entity light.den_fan_light, old on, new on current state{'attributes': {'supported_features': 19, 'friendly_name': 'Den Fan Light', 'manufacturer_device_model': 'ge_jasco_dimmer', 'brightness': 25, 'device_manufacturer': 'ge', 'model_name': 'Dimmer'}, 'entity_id': 'light.den_fan_light', 'last_changed': '2017-02-15T15:45:46.776951+00:00', 'last_updated': '2017-02-15T15:45:55.782100+00:00', 'state': 'on'}
2017-02-15 09:46:23.302316 INFO light_control: entity light.den_fan_light, old on, new off current state{'attributes': {'device_manufacturer': 'ge', 'supported_features': 19, 'friendly_name': 'Den Fan Light', 'model_name': 'Dimmer', 'manufacturer_device_model': 'ge_jasco_dimmer'}, 'entity_id': 'light.den_fan_light', 'last_changed': '2017-02-15T15:46:23.287633+00:00', 'last_updated': '2017-02-15T15:46:23.287633+00:00', 'state': 'off'}
2017-02-15 09:46:23.304790 INFO light_control: entity=light.den_fan_light, old=on, new=off, attributes=state

The timing seems to vary on when the off state will be recognized, almost like there is a polling loop that is running and depending on where in that loop I issue the off command determines how long it will take before I get an off message.