Detailed Logging?

Is there any kind of detailed logging we can see to know what's going on with our hubs. There are times my hub seems to be running quite slow via web interface so I'd like to see what's going on. Checking the System Events and Logs does not reveal anything unusual.

For example, its taking between 8-12 seconds to switch from the Dashboard, Device, Apps, and Settings Tabs.

Nope. It has been asked before and there are no more tools other than the built in logs that we have access to.

There are actually a few threads on the forums with users that have similar issues. I recommend scanning them and jumping on one of those to see if you can find a solution.

Usually this is the result of a custom app, custom driver (rarely a builtin app/driver).
Some have reported temperature affecting hub performance.
Some have had bad zwave/zigbee devices affect their hub.

Lots of info out there though to help.

I would sure like to know what's causing the hub to slow down. For instance, is it some app recently installed, a recently configured rule, a noisy device, or maybe something external to the hub like my network. Really hard to debug.

Not exactly logging in a diagnostic sense, but if you'd like to send some or all of the device events off board you can use this to graph what devices and quantify of events are being generated. This uses Maker API + Node to feed events and event metrics into influxdb so you can graph it with Grafana. I wrote this project to graph temperature/power from devices connected to the Hubitat, but it sends sounds summary stats of events to influx every 15 minutes. They're broken down by type, device and finally device + type.

Keep in mind, a lot of events don't generate always log messages. This is a graph of my system, and you can see the large number of events the washer power monitor generates when the washer is running. The measurement is events per 15 minute period.

1 Like

Iโ€™m not having any issues currently but I agree that this would be a good feature. A way to turn on logging for every event fired would allow for quick troubleshooting of performance issues.

Many of us are doing this via web sockets that are exposed on the HE hubs. I am personally using NodeRed to push event and log data into a MySQL database on my NAS.

My hub is dog slow after a couple days between a boot. For example, it takes about 15 seconds to switch from the apps tab to the devices tab and the same going back or refreshing the browser while on a tab. I posted this in support but didn't get any response from the HE team.

Email support:
support@hubitat.com

Are your automations also slow, or is it only the web interface? If it is only the web interface, it's possible that you've run into a known network incompatibility issue for which there is a simple solution. Tagging @bobbyD.

I have still been encountering random slowness that seems to creep up out of no where. Rebooting and powering off do not resolve the issue. What does seem to resolve the issue at least for a while is performing a soft reset. If you look below you can see the results after I performed a soft reset on the 11/23/19 the response drops considerably and back to normal.

No new apps/drivers have been added/remove and no new automation's have been created.

I see no errors or signs of issues in the logs.

Here is 7 day logs:

Here is 30 days, you can actually see the change in response time from when it was normal (around 500ms) to over 4 seconds and then back to normal after the soft reset.

@raidflex I agree and I think our graph look similar, if you limited the Y axis it would be more clear.

For mine, I suddenly see a random increase in ~latency across most systems. Though it feels very pronounced in RM4, where most things are suddenly 400ms slower. All my zigbee, zwave latency is measured in RM4. Even pure groovy app latency increases, though much less dramatically. I have similar graphs every time this happens, it's pretty consistent.

When you look at system metrics I don't see any particular increase in events from any device (there's been more motion since I've been home more):

I'm a little surprised this has lasted as a bug for as long as it has. Even if support couldn't reproduce it locally, and didn't have enough remote health metrics, surely they could just with permission ssh into a hub experiencing issues and get enough details from the jvm to do some basic debug...? Well, easier said that done.