Device Logging "Cost" - 'debug logging' vs 'description text logging' vs 'route and LQI logging'

Wondering if the above subject has ever been outlined in one place.

Found myself trying to figure out which of my rules triggered a ZigBee device at I time I didn't expect and I couldn't find the logging I thought I'd find to help track that. I saw when the device was turned on but not how. Eventually I noticed where I had a rule that applied earlier than what I thought (Evening, Night).

BUT back to the point....this led me to look at the logging settings on the subject device's screen; I suspect if the "debug logging" was ON I'd of seen what I was looking for.

But what is the HE resource cost of each of these three logging options when they are ON. I currently have "description text" and "route and LQI" ON most all I think (haven't looked at all).

Thanks. Didn't find this as a headline topic anywhere although I'm sure it's discussed here and there in the body of a few threads.

Debug logging generally shows messages being received on the hub from the device. It is particularly useful when troubleshooting driver behavior, e.g., if you have a switch that you think should be reporting as on but the driver isn't parsing it into an event on the hub side. This could help you (or really, more likely the driver developer) figure out why. Some drivers also log when commands are sent from the hub, which I happen to find helpful, but not all drivers do this, especially older drivers (it seems to be mostly newer Z-Wave drivers).

Description text logging gets logged as the "info" level in "Logs," and it generally shows what events got generated by the driver: things like switch on/off, button presses, power/energy reports, color changes, etc.--basically what the "debug" messages actually got parsed into. For most users, this is generally the most helpful. But note that it does not show what commands were sent to the device, just how information that is (usually) received from the device got parsed into an event on Hubitat, if it did at all. If a switch is already on and you send an on() command, nothing will normally change, so you won't get an event (or an info log). This is generally the same information you can find historically on the "Events" page for a device, though the events page is authoritative and logging the descriptionText column from there (hence the name of this preference) is just a convention.

Debug logging is, by default (and convention) enabled when a device is installed and then disabled after 30 minutes. It can also be manually re-enabled from the preference and, again, will be automatically disabled after 30 minutes. Description text logging is enabled by default when a device is installed and remains as such until manually disabled. This is stock Hubitat driver behavior, and a convention for (IMHO) well-written user drivers, but keep in mind that custom code can do whatever it wants here, and you may find community developers who don't follow these conventions.

"Route and LQI logging" is not a standard feature of any built-in Hubitat drivers I know of. Is that community code?

In any case, back to the core of the question: we've been told that the impact of logging on your hub should be minimal. (They've written more on this, but a quick mention from staff that I found with a search is here: Sometimes rules not running - #9 by bravenel). If you see frequent log entries, you probably have a "chatty" device that could be a problem on your network regardless of whether logs are enabled (the fact that they aren't enabled might just hide it better). Device stats from the "Logs" page would be a better indicator of hub impact. Past logs are pruned after a certain size, and live logs only stay for as long as you have the page open, so impact there should also be minimal over time. (But cutting down on log entries may help you see more history, which can be helpful for troubleshooting things that happened in the past.)

It sounds like you're trying to figure out what app is acting on a device. Logs (or event history) for a device won't help with that--commands aren't events (though they may eventually cause an event to happen) and devices don't know which app sent a command. The best way to figure that out is probably to look at the "In use by" section on the device page and see what apps are there, then consider turning on logging for those apps (most apps have various logging options) if that alone isn't enough to figure out the behavior you see. A log from an app is going to be more helpful than a log from a device.


OK now THAT'S a nice sticky for this subject in the "Get Started" category. Bits of piece of this was certainly here and there but this summed it up nicely.

The Route and LQI Logging option is in there on the stock Ikea Tradfri Control Outlet driver, likely others.

And yes, I was looking to see which App, or rule therein, was causing the device state change. Wasn't hard to find with manual inspection, it just got me thinking about the logs, their use for such analysis, and resource consumption while enabled. I see now I was expecting entries where they wouldn't be.