I've got HubConnect live and running. I have recreated some dashboards to now include the devices on the server as well as those on the client. Pretty slick. Now I only have a single set of dashboards and don't have to jump from one hub to the other.
What are others moving to server control in order to avoid having to pull up the client? I'm wondering if I should move my lighting apps and RuleMachine rules over to the server and afterwards deleting them from the client just to keep everything in one place. OTOH, once created, I don't really have to deal with these types of things so is it worth the bother? Just getting opinions.
1 Like
Everyone's needs differ, but I've focused on keeping the Remote Hubs as FAST as possible. With Motion sensors and Door/Window sensors (cause) on the same hub as the switches and dimmers (effect) then I can tie cause and effect via SimpleLighting/Motion Lighting/RM.
Z-Devices (Zwave & Zigbee) are relatively slow devices. Relative to LAN / WiFi speeds and CPU speed. Hurry up and wait.. wait really really fast, but still.. it's a lot of waiting before the next Z-Device packet can be sent, especially if there's a ton of received Z-Device traffic too (Thanks chatty power monitor devices!!)
The Hub's CPU has plenty of unused cycles to process events that arrive via the LAN (aka HubConnect). It's very common to have our hubs polling LAN or Internet services. Google Home, Amazon Alexa, and Weather. Add in some "display" services such as Dashboard, and Homebridge, and there's a massive opportunity to have the CPU be doing something else when the next free slot in the Z-Device comes around.
For that reason, I built my set of hubs around the Z-Devices first. (I'm 88% ZWave, just barely using Zigbee) and I only allow HubConnect, RM and Lutron on my ZRadio hubs. Everything else is on the server/coordinator hub.
1 Like
