Slow Hub - better tools to diagnose slow running devices/apps

Its soo difficult. There is no way of knowing if we are overoading our hub or not? Is the CPU at near 100% in which case off load a bit. Is the memory near capacity? is network (zigbee, ethernet, z-wave) near 100%? I understand that some people are buying 2nd hubs but I am hesitant to convince my self "Hey, the product that worked well for months is now less reliable, the solution must be to invest more in the same product?"

I have been moving rules out of RM, using simple automation and also using the "Button controller app". More complicated homeMade apps, I have moved to a raspberry pi running python.

I have a lot of tasmotta devices on my system and am thinking that the ethernet maybe a pinch point (the web interface on the hub can slow down and rebooting resolves the issue). I am going to write a tasmotta driver using MQTT as this would limit the hubs ethernet traffic to only 1 IP address which is on the same LAN hub as the hubitat. It is going to take a lot of work and may yeild no change whatsoever (as I don't know if the LAN port of my hub is at capacity or not)

I'll feedback when I have some results

I was rebooting daily as well 7 months ago. I decided to add another hub and put all of my 70+ zigbee end devices as well as most automations on the new hub to control my zigbee lights and z-wave plus devices via HubConnect. The new hub has never experienced a slow down, but the original C-5 hub gets rebooted weekly or it slows down. Rebooting daily is terrible; not only from a reliability standpoint, but also because the mesh never seemed to have time to stabilize and response times were slower.
I just use RM to reboot the hub at 4:00am Wednesday and Sunday and I haven’t seen a slowdown (except when I disabled this rule, which is how I know it takes a week) since adding the new hub.

What's the emerging technology? Smart home tech goes back at least to X10 which started in the 70s and both Z-Wave and Zigbee were introduced in the 90s. Though that still seems like yesterday to me, that's 20+ years ago!

If the issue is software (which is pretty much what the HE team has said so far), throwing hardware at it is the worst thing you can do. It just masks the problem instead of resolving it.

Yeah it seems mostly software related. Although the big players also want to introduce a new device standard/protocol and are still iterating their devices quite rapidly. And it's clear from the numbers of start ups and shutdowns in the industry that HA is definitely still an emerging, immature technology space.

... the DIY space is where these problems exist.

So,

I have re-written my tasmota driver to use a MQTT server, so far so good. Switches are lightning fast and I now don't need to run an automated refresh to know the switch status as it parses via MQTT. The hub now only talks to one IP address (the raspberry running the MQTT server) which should lift some load off the hub's LAN card

Increased the CPU load on my raspberry from 5% to 7% so I can not see that being the entire solution.

Are you using web sockets when connecting to HE? Or are using a client on the HE hub?

So my original tasmta driver used sendHubCommand to send an HTTP get to the tasmota device's web server. so a "192.xxx.xxx.xxx/cmnd=power%20on" to switch on or cmnd=power to get switch status etc.

I have now setup an MQTT server on my raspberry. And modified my tasmota driver use that server:

  • the intialise() routine of the driver sends the MQTT config commands via HTTP to the tasmota to setup the MQTT server
  • I have then used the MQTT commands (detailed here MQTT Interface - Hubitat Documentation) to send commands to the tasmota and parse the replies

This works really well, I get an instant parse with the new switch value when a tasmota device changes state (even if done locally) as I am not relying on a "runEvery... ()" to fetch the switch status

Driver code below (if your interested)

Nice, can you send the raspberry pi code as well? Is your MQTT server written in node.js?

Nevermind, I want to do something different. I'm striving to use the HE streaming event socket when connected to a node.js server . Likewise, I want to be able to send commands back into the specific HE hub using the node.js server. It's kind of like HubConnect, but without all the overhead...

Why not just create a "Remote Client" app that speaks the protocol.. like dan.t did with Homebridge? The HubConnect API is documented... for exactly this purpose. :slight_smile: At least that way all the Select Devices portion is done for you.

Additionally, there is a HubConnect proxy for NodeJS and it has a built in WebSocket.

Hi,

I used the "off the shelf mosquito server": Introduction to IoT: Build an MQTT Server Using Raspberry Pi

Its Really easy to setup and then it sits in the background doing the work for you. The additional benefit is my python scripts can now get the info from MQTT as well therefore avoiding 2 devices (hubitat and python) poling the same tasmota device.

I believe I'm looking for a more generic solution. Using web sockets we have a way to extract all events to a node server while caching state.. Sending commands from the node server back to HE via web sockets is where I'm struggling... Maybe that is where things break down meaning there is no way to send a device event generically from a HE smart app. Meaning, the devices within the HE app need to be inputs... I realize maker will allow http commands, but I want sockets!

Something like the linux top command would be nice to get an initial idea of what's consuming hub resources when it's slow.

Useless.. sorry :frowning:

All it would tell you is what you already know.. that Java is running, Java is using all the resources.

1 Like

The tool would have to something that works within the JavaVM that the platform runs on. top or htop wouldn't be informative in this instance.

1 Like

Oh OH I know lets run Dynatrace within the hub and then the license alone would cost more than the hub!!!!! Everyone would get a MUCH more expensive hub with ability to see resource usage!

Reality is that running a trace attached to the JVM would require even MORE resources bogging down the hubs even more.

1 Like

jmap output could be useful, but not easily interpretable by the end user ....

1 Like

After reading through many hub slow down threads, I have decided to stick with HubConnect and move all RM rules to a dedicated hub for processing.

Question - in order to achieve the lowest latency possible and reduce the probabiilty of a hub slow down, should I move all zigbee devices including my Hue hub lights to their own dedicated hub and then disable each respective radio? 80% of my devices are zwave...

My current setup:

(8) Hubs (yes, 8 hubs, I'm sure Hubitat Inc. loves it!)

  1. HubConnect (some RM Rules)
  2. 1st Floor (zigbee and zwave devices with a splash of RM)
  3. 2nd Floor (zigbee and zwave devices with a splash of RM)
  4. Custom-Apps (very risky apps with high poll frequency)
  5. Media-Apps (Sonos, Harmony Hubs)
  6. Cloud-Apps (SharpTools, Google Assistant)
  7. Alexa-1 (dedicated hub for controlling TV channels in specific room on separate Amazon account, Alexa turn on ESPN...)
  8. Alexa-2 (same as above, only for Master Bedroom)

My God. Eight hubs and you are still worried about performance?!? I'm still debating adding just one more due to the occasional seizures and slowdowns! :man_shrugging: