Organic chemist in the pharmaceutical industry => industrial processes => industrial automation => PLC's => home automation => Hubitat...
3 Likes
Oh - you're a real chemist!!
2 Likes
Looks like fun.
1 Like
I feel like I have noticed a difference for the better recently, also. ....could be all in my head though.
I make wine in my bathtub on weekends. Can I join the club? 
5 Likes
Ha ha ha. That's the best type of chemistry. I'm a consumer tho' not a manufacturer 
I did try to make white wine once and it ended up tasting like rat's pee (I imagine) 
6 Likes
My visualization of this was both hilarious and disturbing.
Nice recovery 
4 Likes
48 HR UPDATE: OK, so yesterday was entirely clear of slowdowns. beginning after the nightly maintenance, occasional slowdowns began to appear, not in any way constant or catastrophic, but they were visible as shown below. This used to happen as the slowdowns ramped up but they happened within a 24 hour period, and this is 48 hours. This might suggest an issue which is caused during nightly maintenance.
This is still better than before but it looks like slowdowns might be increasing a bit. I will update you in 24 hours.
LJ
Oh! How I wish my Zwave numbers looked like that!
If I may be so bold as to ask:
- How many zwave devices do you have on that hub?
- what else do you have on that hub?
- Approx. how big is your database? (from the settings -> restore/backup)
UPDATE: Well things continued to deteriorate rapidly yesterday. From my last post, things got progressively worse, to the point that it was essentially in a constant state of slowdown again. I checked my panels and that did not appear to be related this time. The system restarted the Hubitat processes in the evening and after maintenance. Only the one after maintenance shows on the table below. After the maintenance and restart this morning things look better again. So, basically 36 hours after the update to 2.2.2.126 the system was forced to reboot. That is better than I was experiencing in the past, but about the same as what is now being reported by others here. I was very excited about the one day without any slowdowns, but it looks like we have only peeled back a couple of layer of the onion. Love the improvement, and looking forward to more.
LJ
Device Counts:
Zwave - 61 Devices
Zigbee - 18 Devices (not including the 45+ Hue Zigbee devices running on a Hue hub connected to HE)
**Virtual and Internet Connected devices ** - 145 devices
What else do I have on the hub:
Number of Apps and Child apps: 41 apps, many of them with multiple child apps. Among the apps are Echo Speaks, HubConnect, Multiple apps from BPTWorld and Cobra, and many others. Not running Webcore yet but I loved it on Smartthings.
Rules: 57 RM Rules, 21 Simple Automation Rules
Size of Database: 47459760
Does that help? How about you? What are you running?
LJ
Have you a a virtual device on hub watchdog, I would be interesting to see them side by side to see if its the hub or part of it (z-wave)?
I'm curious as occasionally my z-wave becomes unresponsive occasionally (only a shutdown and pull the power fixes it) but zigbee and virtual all good
Edit also found closing all dashboards completely on all devices significantly reduces my lock frequency
No virtual, but I will set one up and report back.
LJ
also found closing all dashboards completely on all devices significantly reduces my lock frequency
My numbers
I just have this sneaking suspicion that there is something wrong in my database. I've got roughly the same number of devices (around 60 zwave, around 50 zigbee). On this hub, I have basically no rules. Everything is done on another hub using hubconnect.
However, I have used this hub over time to test out many devices. I have always tried to remove them by excluding them from the mesh. Occasionally, (before I knew better), the power was abruptly cut off. With all those devices that used to be there, my database is at 24GB, or 5-6 times the size of your database.
Could it be that Hubitat doesn't delete all references to devices when they are removed from the mesh? Could that be the source of my slowdowns? Is the extraordinary size of the database a reason for slowdown? (I have used PC Controller software to remove all phantom nodes from my zwave mesh. Over time, there has probably been around 10 of them).
I'm going to find out!
When the new C7 hub arrives, I'm going to move all my zwave devices to it.
After I do that, I will turn off zwave on this hub - maybe the size of the database will go down dramatically as a result. When it gets down to around 4GB, perhaps I won't have any slowdowns.
This is what I have on that hub: (in apps)
and this is what my zwave watchdog is:
24GB database size? The hub only has 1GB RAM and 8GB of eMMC flash storage. My guess is your database is 24MB Instead of GB?
3 Likes
As a matter of interest my db was 42meg.
I stopped all logging, even text logging, where I could on all my devices and apps.
My db is now 27meg.
I'm trying to only have logging on for new devices and apps for a short period and monitor the logs. If nothing untoward appears in the logs I then turn logging off.
I'm not saying this will help but if you have something doing excessive logging I would have thought it would slow things down.
Just my twopence worth. 
2 Likes
You are very right, a slip of the zeros. My apologies.
I have been told that database size is a function of devices and events.
Also, that after a certain size, the log is re-written, so that it can only be a certain maximum size.
1 Like
Also every device is different, on my zigbee I bought some cheap standard 3.0 ones, it average around 0.5 sec , whereas when I used a ST plug it was 0.2 seconds. Sat next to each other
Prity much all loging disabled
I think that database size is somewhat correlated with number of devices.
The question is: is database size correlated with slowdowns?
I think that the more obvious answer is that it is highly correlated with with mesh issues.
No issues = no slowdowns.
So, I believe it's critically important to make sure that you have no mesh issues.
1 Like
