I just updated to 2.2.6.137 and now my z-wave switches changing state takes about 4 seconds for the rules to fire.
I can turn my Zigbee end table light on/off instantaneously using the Hubitat web interface (not dashboards).
I can turn my Hubitat Group containing two Zigbee end table lights on/off instantaneously using the Hubitat web interface.
If I turn on or off my dimmer, the end table lights group takes 4 seconds to respond. I am using Mirror Me app for this.
I also notice SharpTools is frequently timing out after a single command. I can send a single command without issue, but a 2nd command fails.
Q: Are there still issues being resolve in 2.2.6.137? I wanted to check here before asking sharp tool.io staff for help on their system, since I see slow performance of other things like the dimmer that controls my end table lights group.
I just updated both my hubs to 2.2.6.137 about 40 mins ago just checked most my Zwave and zigbee rules everything seems to be normal thus far. Physical operation seems the same as well. Have you shutdown & unplug your hub for a bit like a few minutes, might help
This is the first thing I would try. A reboot often helps a sluggish hub.
The first entry is the receipt of a new API Key on the Hub which would explain the three events within milliseconds after that not getting posted over successfully. Had you just reauthorized SharpTools before opening up the logs?
I agree. Except the update process reboots the hub. But I will try that. I just wish they would give us a bridge that is 2-3x faster with double the RAM. So many of the issues we experience would be better. I wonder what rule engine they use for their various rules too. I have always been fond of Drools because of their unique knowledge tree.
Thanks. I wanted to ask outside the other HE forums, because I notice the biggest impact was with rule, and with sharptools
This wouldn't solve whatever problem you have. Your hub is not lacking in computing horsepower or memory, unless you are banging the heck out of it with something external. If you're still seeing sluggishness like this, there is something else causing it. Usually it's one of a few things going on: (1) a messed up Z-Wave mesh, (2) database corruption, or (3) some device spamming your hub, possibly a LAN device or energy metering device. Number 2 can usually be fixed by downloading a backup of your hub, then doing a Soft Reset, followed by restore of that backup. Number 3 can be diagnosed by selective disabling of such devices, to find the cause. Logs can also help show where a lot of activity might be coming from.
Bruce,
I would absolutely agree, if turning those devices were slow to react on the devices tab, but they are instant. I turn on a switch, and instantly see the response in the device page. I go to the light or groups, and press the on or off, a d the result is instant. If I press the switch, and wait for the light to come on, it is taking 4 seconds (approx). The only thing between pushing the switch and the light coming on is the HE built-in app rules. This one in question is the mirror app. I would record a video, but I can’t upload videos. This has always been a problem that comes and goes. Without the ability to profile HE behavior, there is no way to test where exactly the issue is.
If it were a zwave issue, then the devices would express latent behavior, which it doesn’t.
Using a Dimmer Switch as a trigger to turn on a Group will often not be instantaneous. Often the device will not report its status as ‘on’ until the dimming ramp cycle completes. Also, sometimes the dim level of the dimmer will not update very quickly while the switch is ramping up.
Try changing the dim rate of the dimmer switch to 0, to see if the MirrorMe automation speeds up.
Please enable debug logging on the source device and all the target devices being used in mirror me, then turn the source device on, then off via the source device driver, then post the resulting live logs.
Yeah, the delay is entirely within the actual device response time, it's taking almost two seconds from the time the device is told to turn on to when it reports being on.
If you're trying to mirror one dimmer to another, and the source dimmer takes 2 seconds to report the level that it was set to, then the target devices aren't going to change their levels until 2 seconds later...
The timing drifts. Today it was faster than yesterday when I opened this. I think I may have to break down, and replace all my older Z-Wave devices with modern ones, but I fear even after doing so, things won't be much better. I am getting tired of buying things to improve stuff, and the results be negligible. But I will give the devs the benefit of the doubt, and replace them all.
Look, this isn't rocket science. You can't expect a fast response out of a device designed to be slow. There are lots of ways to accomplish what you want to do that would be basically instantaneous. You don't need to replace all of your devices, only the ones that you use to trigger automations. Consider other alternatives for triggering these automations.
One way to do it would be to put a micro dimmer in the box where the slow dimmer is, and put a Pico on the face of that box. Press the on button on the pico, and that triggers the automation, including the buried dimmer. Etc. Lots of ways to go.
It mole just stated from commanding the device to be on, and refreshing the status as on is where all the lag is. It can’t be both ways. If the hardware is taking 2-2.5 seconds for commanding it on to returning to the hub that it is on, how do any rules or software fix that? This system was crazy fast, but now it is getting slower with every update and I am being told by you it’s my hardware but. If your software. And now you are saying it’s your software. Which is it?
I like the system, and I even paid for both of your subscription services — one of which I cannot even use because of bugs I. Your system. Now, yet again, I am receiving the message its all my fault. I told it my switch, so I say fine I will change it but then you challenge my intelligence and act like this is easy stuff.
It may be easy for for you. But we do not have access to any tools to tell us where issues are. We cannot profile the system, and everything is my fault.
Thanks for handling support like that. It’s exactly what I want from a support request.
They are okay. But I don’t have a Lurton system, and for dimmers that aren’t z-wave. I prefer the hue dimmer. This is an issue of a gang box dimmer that does not control a load, because the lights aren’t wired to it in any way.
Understood. It is just that the Lutron equipment works so well in general. And the local LAN integration between the HE hub and the SmartBridge Pro2, or the Radio RA2 main repeater, is very fast and reliable. I have not have any automations fail to fire immediately when I trigger them with a Pico remote.
Have you tried using a Philips Hue 'Dimmer' in this situation specifically? Since there is no load connected to your existing Z-Wave Dimmer, you have nothing to lose, right? The Hue 'Dimmer' is just a Zigbee 'Button Controller' to the Hubitat hub. As such, it will be very responsive to user input as it will immediately send events, instead of waiting for the dimming up or down to be complete. Its worth a try to see if the issue changes in any way.
