Sluggish Performance With Wink & Z-Wave Devices

Okay, so I’m using a Wink Hub 2 as a bridge to talk to all (3) of my Z-Wave devices. I’m running into the issue where the response time is really sluggish, though. For the longest time, I’ve only had my door locks on it, so I had never really thought much of the delay until yesterday when I installed my first Z-Wave light switch (primarily to act as a repeater on the other side of the house to extend the Z-Wave network signal). If I try to toggle the Z-Wave light switch (it’s just a GE-branded Jasco 14294), it’s taking upwards of 5 seconds for the light to actually be triggered.

My thought process so far is that I have a really noisy network (So. Much. Broadcast. MDNS.). I mean, it’s pretty bad. I’ve been in the process of trying to stand up a separate IoT VLAN to put all of the IoT crap in where it is only able to reach the Internet and Home Assistant (I’ll statically assign a few client devices outside of that and granularly control access, but the idea is to shield the dumb devices from the noise, and my network from the dumb hackable devices).

Last night, I moved the Wink Hub 2 into the IoT VLAN, and now it can only talk to the Internet and Home Assistant. However, the lag hasn’t improved at all from what I can tell. If I open the Wink App and toggle the light, the lag isn’t as bad, so I think it might be something between Wink and Home Assistant. I don’t have anything else in the 900mhz spectrum, so I don’t think it’s lag on the Z-Wave network.

Additionally, I do have the local_control: True key:value set in my Wink component configuration, but that hasn’t seemed to help. It might be ignoring it now that it’s not on the same subnet. Perhaps I should multi-home my Home Assistant instance in both networks? I’m just looking for ideas here.

Yeah, not sure how local control will behave accross subnets that can’t talk. (I think I remember implementing a check to make sure HA and the hub are in the same network, but I don’t remember for sure. ) If it is trying to use local control that will slow things down because that call has to fail ~3 seconds and then fire the online request. So, try disabling local control.

It shouldn’t take that long for local or online through. I have heard that Wink is having troubles with pubnub (their push update service) and are trying to implement an in house push update service. So it is possible that its just an API issue? Seems like the app would have the same problem though.

Okay, so knowing about the timeout definitely helps me make some better sense of the delay when the hub is in a separate subnet. I think I’m going to try and multi-home my HA VM into both my access and IoT VLANs to see if giving it direct access in the same subnet will help, but I will definitely try turning local_control: off for now. I’m not seeing where pywink is checking for subnet consistency, but it’s definitely possible. Let me make some changes, and I’ll update this thread. Thanks for your help and all of the work that you do with integrating the Wink into HA.

Have you considered a cheap zwave stick to eliminate the Wink Hub and cloud hops all together?

That’s honestly what I would rather do. I don’t like the idea of a message having to go out just to come back in. If the Wink service is down, I’m screwed. It’s part of the reason I’m not a fan of Ring or Nest, but I still use their products.

The main reason I haven’t gone to just using an Aeotec stick is because of the way my HA instance is hosted. I’m running it in a VM on an ESXi host. Passing USB to the VM, and then to the Docker container running HA is a bit of a pain in the ass. I’ve thought about using some sort of USB over IP system, but it would still be a pain in the ass. You’ve got the right idea, but I’ve just made things overly complicated for myself, lol.

The other option is to use a Vera hub. It uses ethernet; and speaks Zwave; and 100% local. So from the HA instance it’s just a IP device to talk with so the VM/Docker stuff doesn’t get in the way.

But as a old Wink user I can tell you your world will change for the better once you get moved onto a Z-wave stick. So much better performance that things that were not possible become possible.

Did you have any zigbee devices?

I actually migrated from a Vera to the wink. My old Vera Lite didn’t speak Z-Wave plus, and I got the Wink to replace it.

One thing that I’ve been debating on is migrating my entire HA instance to a laptop so that I have an AIO device that essentially has a built-in UPS. That way I can run the entire setup with a Z-Wave stick and not have to worry about losing access to HA if something in my vSphere environment goes down.

I have 6 Phillips Hue bulbs spread across the house. They run in the 2.4ghz spectrum, though.

I have thought about moving to a zigbee/zwave local setup but I don’t think there are any good zigbee setups. Plus I am the main Wink dev so I don’t want to move over and not be able to troubleshoot

My preference would be to have local access to everything. As for ZigBee, I’m honestly not a big fan of it. There’s too much competition in the 2.4ghz spectrum. I like the fact that it’s an open standard and you don’t have to pay the Z-Wave Alliance money to use it in your product, but they could have picked a better frequency spectrum. However, the benefit is that 2.4ghz radios are cheaper thanks to the popularity WiFi and Bluetooth, and combined with the null licensing costs; ZigBee products are simply cheaper by design.

You’ve definitely been doing work on the Wink stuff ever since I’ve started using it. I can definitely understand your apprehension of moving to a different component/ecosystem when you’re already so familiar with Wink. While they have their flaws, it’s not a terrible system. I just wish they were a bit more open. There was a bit of a shakeup with the way that Vera/MiCasaVerde was structured and the direction that software was going in a couple of years ago, and that’s what made me switch. I’m honestly not sure which is better sometimes.

Oh, update on the lag. Setting the local_control back to False definitely cut that 3 second timeout delay, but there’s still a bit of a delay. Primarily in receiving status responses. Hit a light in HA, and the light responds a second later. However, the light takes a few seconds to update in HA. My only assumption is the delay is from going all the way out to Wink’s servers and back in.

Yeah that delay is from wink s being their update to pubnub and pubnub pushing the update out. Just too much bouncing around.

Yeah, so it’s out of our hands. I’ll go ahead and mark this thread as solved in case anyone else is running into this issue.