There's a rather large thread going for the Node-RED integration. Might try moving logic (automations) to NR and see if that improves your speed. Worth a shot at this point.
2 Likes
They finally contacted me. Their chromecast driver was the culprit. And i didn’t even realize i had that installed.
It is still a little slow but now well within a comfortable range.
1 Like
Out of context.
An HE hub with more RAM and more processing power.
2 Likes
I'm starting to feel the same about RM. Individual zwave commands are very fast when issued from the device driver page but string a bunch of commands together in RM and they crawl.. Anyone move away from RM for these reasons? I would prefer to execute these types of commands on the hub itself if possible, guess that means writing my own hard coded apps. Anyone have any thoughts on this?
my zave is also slow.. my zigbee is about .2 secs virt switch similiar times (as seen in hub watchdog tiinings)
just added an empty zwave plus test to the mix..
avg time about .5 secs.. not acceptable. it whows direct route to the hub wit 100k time?
A few quick suggestions:
- Divide and conquer. Use a C7 Hub to control your zwave devices. Use another hub to act on your rules. On the control hub, turn off zwave and zigbee.
- Move rules from RM to Simple Automation, Notifier, Motion Lighting, etc. Even if 1 RM = many SA
- All external control (e.g. Google, Alexa, Life360, Ecobee, etc.) on the other hub.
- Simplify, simplify, simplify.
- Measure before and after these type of changes with Hub Watchdog to see if they are having an impact.
- Don't forget to do a soft reset first, and check that your mesh is performing well.
i dont think its the rules or extenal control causiong the issue.. then zigbee would be slow as well.
Have you gone in an ran a z-wave repair operation yet? Any time you add or remove devices, you should run this. This is how z-wave re-maps the network for optimal routing. I have 19 Z-Wave switches (mostly Inovelli) and a few miscellaneous devices (like multisense 6, GE outdoor lighting plug, etc) and my z-wave is very responsive. I have seen z-wave behave slowly in the past, and learned that z-wave repair actually rebuilds the routing tables, and since following the mantra of repairing z-wave after any changes, this is not an issue.
For me, my Zigbee network is crazy fast on Hue, but sluggish on HE. All my motion/temp sensors and contact switches are all zigbee on HE network, and operate a little slower than I would like. The same is true for my Lightify LED lights. But everything I was able to move over to Hue Hub works crazy fast, and has a really smooth, nor organic feels I have moved all bulbs over to Hue (still working on that) and use my Inovelli dimmer as smart bulb controllers, so they only do on/off, but send the dimmer level changes to HE for my HE rules to control Hue dimming, and this works really well (when RM is behaving).
Lastly, I installed the DCM Rebooter app to auto-reboot my hub every morning at 3am. Until I did this, it would get to where a rule could take 3-4 seconds from activation to completion. Now it is much better.
Finally, I don't know if RM uses Drools, or another open source rules engine, or if it is a home grown rule engine. But this could be part of the delay as well. Rules engines like Drools build a knowledge tree of facts and properties to quickly identify while rules should be evaluated when an event occurs. If the rule engine relies solely on the hub's event bus to select rules to be executed, there could be performance bottlenecks here, and are necessary due to memory or storage constraints.. but all this is speculation at this point, since we don't know how RM was created.
Try the clean-up, and take care to make sure you don't have cyclical rules, like: Set Dimmer 2 to level of Dimmer 1 when Dimmer 1 level changes. And set Dimmer 1 to level of Dimmer 2 when Dimmer 1 changes. This can result is several unnecessary z-wave messages. Additionally, I considered the watchdog, but I don't need an app that intentionally places a load on my system, for the sake of measuring performance, so I went against the trend, and left if out of the equation. I can measure performance the manual way -- when I notice slowness on devices.
1 Like
zwave repair is not neessary for zwave plus devices.. almost all my zwave devices aer the plus variaty except for one or two sensors and one garage door opener.. the new switch is also swave plus.
I agree with moving web based integrations to another hub, but running rules on a different hub than the z-wave and Zigbee devices just adds network latency to the mix. To me this does not make sense. When it comes to performance, you want to put your rules engine as close to the bare metal as possible. These hubs have more than 1 core, and all I/O is buffered to some extent, so the hub should be more than capable of chatting with z-wave, and Zigbee whilst concurrently processing rules.
I also agree that RM seems to be a bottleneck and moving rules from RM to purpose built apps works better -- even if that means a few simple automation rules instead of a single RM rule. I am curious is this is part of the reason that the Button Controller app was brought back to life.
I have not seen anything about Z-Wave Plus to suggest that they do not need a repair.
I did find this, and there is a special not about Z-Wave Plus and non-plus devices, but that is not what you are eluding to.
Additionally, this article suggests the same... plus or otherwise.. run a repair to optimize the network routes
I know that you're not going to believe this, I certainly thought like you as well before I did it.
However, due to the relative speed of an instruction given by ethernet and the relative speed of a zwave switch, it can be MUCH faster to have the rules evaluated and run on a remote hub that doesn't have the devices. Network latency is not a factor. You have to try it and see. You won't regret it.
Move your rules that update zwave devices to another hub. You will see, that it's MUCH faster.
If you are saying to move a-wave devices Nd the rules that control them to their own device, the. I can see that working. But if you are suggesting, as per your prior comment, to but the z-wave devices in a different hub than the rules, then I will have to see it to believe it. Could be an excuse to buy the C7....
If you do go ahead and buy the C7, Then the smart thing to do is to move over to the C7 the zwave devices (and the zigbee devices). Then, with HubConnect, you can control them with your existing C5 Hub, and your existing rules.
Nonetheless, as per my previous note, do the simplification stuff first. Do a "soft reset" . Move the Simple Automation (wherever possible), use Notifier, Motion Lighting, Button Controller, etc. Maybe you won't need to buy that C7.
I will say that I absolutely cannot tell the difference between controlling devices from the hub they are joined to, or controlling them from the remote hub using HubConnect. All of my button controllers, RM4 rules, ML, SA, and motion/contact sensors are on the remote hub now, with all of my zigbee/zwave lights and groups/scenes on the server hub.
Wouldn't it be great if we actually had appropriate telemetry within HE to easily diagnose slowness issues? I wish the HE team would take this seriously. It would make all of our lives better.
How much faster? Very curious about this..
I'm sorry, I didn't measure so I can't give you an exact answer.
However, as I said previously do all the other initiatives first to get it back to working quickly.
If you find that it still is slow after all that work, then consider purchasing a C7 to be used just for "device control".
Also, there are other approaches to dividing up the load. One individual has a Hub for each floor in his house. Others (such as myself), use one hub for devices and one hub for control. One individual has one hub for zwave and one for zigbee. In other words, your mileage may vary - before going down this route, plan it out carefully.
I would like to also recommend an excellent response that I read some time ago. It posits that the reason for slowdowns is the lack of memory, and it gives a few practical suggestions on how to increase that memory:
[RELEASE] Hub Watchdog - Simple way to monitor if your hub is slowing down or not
Specifically this:
1 Like
If you can't tell the difference, why do you run it this way? Anyone else agree to move all app processing to a remote hub away from the hub that the devices are physically attached to? Ethernet and http are very fast so not concerned with latency?
Last December, after 6 months of daily reboots and problems with keeping Lightify and Hue button controllers attached to the hub, I decided that the easiest and cheapest solution would be to buy a second hub to put all end-devices on. This solution, for the most part, fixed the problem. Lights on Hubitat 1, devices that automate lights Hubitat 2. It seemed reasonable at the time to put rules that involved using Hub 2 devices on Hub 2, and rules that didn’t involve Hub 2 devices on Hub 1. After getting to the point where both hubs were running equally fast, I thought there must be a benefit to having the button controller and rule on the same hub as the device being controlled by it, so I had a couple Simple Automation rules on Hub 2, using a zigbee outlet plug on Hub 1 and button controller on Hub 2. I then moved the zigbee plug to Hub 2 so I could experience the amazing speed difference. There wasn’t any detectable difference. The outlet already switched on and off so fast that there really wasn’t any room for improvement. I’ve also tried this exercise with motion lighting and not seen any difference. My guess is that any latency introduced by having the rule on a different hub is negated by the extra bandwidth provided by the second zigbee radio. I will say that I haven’t tried having all of the devices in use by a rule on a different hub than the one the rule is on.
