Sluggish performace on 1.1.2.121

📢 Feedback
21

Would be nice if there are HUB performance information on the web interface. Things like memory usage would be nice so we can track it.

4 Likes
22

heres a similar request i had made some time back. though i should add personally have not seen my hub slow down with the .121 release.

3 Likes
23

Hopefully not deviating too far off the subject. But is there any way to receive warnings or alerts (pushover via webcore) if the hub hangs or drops offline? Had this happen to me last week whilst out of the country. I could have had some one reboot it if I was aware.

24

A screen displaying Linux 'top' data would be very nice to have.

Things I'd like to see are:

  • CPU Usage (Total, and by core)
  • Memory Usage
  • Flash Storage Usage
  • CPU Temperature (if available)
  • Network Usage statistics (LAN)
  • Zigbee and Z-Wave responsiveness (if such a metric exists. if not - make one up by sending a command to the Zigbee/Z-Wave stick and measuring the time it takes to process it)
  • Some sort of system resource utilization by App (built-in and custom)

Just a wish list... :wink:

3 Likes
25

I imagine you could rig up something via ifttt...

26

Thx Mike, I'll have a tinker

27

I went back to 1.1.1.119 -- seems faster but will see if it misses routines

28

heres my current reboot hub on hung while away from home plan:

  1. hubitat hub powered by plug that is connected to smartthings hub
  2. smartthings hub powered by plug that is connected to hubitat hub

works like a charm … so far. :smiley:

2 Likes
29

Haha I like it. Sadly, my ST is now decommissioned :slight_smile:

1 Like
30

I didn't think I'd ever need to be looking at a wifi socket, but this could close the gap I have. Thx for provoking the thought :slight_smile:

1 Like
31

yeah i would definitely go with the wifi outlet … not a fan of the this … that service.

1 Like
32

Any updates on this issue?

33

Per @bravenel and @bobbyD ...most of us rolled back to 119. Now waiting for the next release and hopefully a fix. :sunglasses:

34

Bored this morning so I thought I would give @halfrican.ak idea a try. I upgraded to .121 again and then deleted the Nest Integration. Everything is running much better. VERY snappy!

Going to add it back in but only add my thermostat for now.

35

I couldn't roll back as there was an issue with the Zen Thermostat. I moved the presence app to WebCore and it works every time now. So there may be something changing with the presence code? And, I narrowed the front door issue to my Z-Wave lock. The contact does cause the virtual switch to fire. So, I just wait a few seconds and manually lock the front door if it doesn't.

36

I'm wondering how many of us that are having this issue were using the nest "presence" feature? I for one was using it, perhaps that's the culprit? Seems like might explain why some users aren't seeing a problem especially if they are only integrating cameras and protects?

1 Like
37

I'm using the nest integration with a thermostat and protect. I'm using a custom command to set the nest presence using rm. So far no issues.

38

I was before rolling back.

Since re-updating my hub to .121 I just have my Nest E in the app. Everything is great so far. Tomorrow I'll try to add in a Protect and see how that goes.

Also, just saw another post by Bruce...for the record I don't have webcore installed and haven't for a couple of versions. Took a month but everything is now in RM. :slight_smile:

39

I was having performance problems until I uninstalled Webcore. When I went back to RM, everything is much faster.

I have noticed, however, that when I first get up in the morning, the first time I go in the bathroom the rule to turn on lights by motion takes a while to fire. After the first activation, it's snappy again. Could the hub be "sleeping"? The logs show the motion is detected immediately, but the rule doesn't trigger.

1 Like
40

No, the hub doesn't sleep. Something else is causing this.