Logging best practices

💬 Lounge
1

As a general rule should we have device and app debug and text logging on or off? Does it bog down the hub? Should it be used for troubleshooting only?

2

Off, probably, yes

4 Likes
3

I turn virtually all logging off. I only turn it on when I am diagnosing, or while writing/setting up/editing rules and so on.

2 Likes
4

Pretty much all devices seem to default to description text logging ON. I guess I will go one by one and turn it off.

5

My drivers do the following based on user selection:

  • default: debug logging off, info logging on.
  • If debug logging is turned on, it is for 30 minutes only.
  • Users can select if they want info logging.
    Personally after several test days, I turn off all info/debug logging using error and warn logging for reporting exceptions.

Logging impact is probably minimal unless you have A LOT OF ACTIVITY on the interface.

Dave

2 Likes
6

I turn mine off on everything unless I'm having a problem. I typically leave my locks to log, but nothing else. Another vote for off. If you're not checking it then why have it runnning?

2 Likes
7

It is nice to quickly check if you have suspicions that something didn't work rule/device. (text logging) without having to go in and turn it on and recreate the problem again.

But if it will potentially slow things down I will turn it off.

8

There shouldn't be any significant impact on the hub as far as we've been told, unless there's actually a problem with the app or device (e.g., if it's a chatty power-metering Z-Wave device and is, indeed, spamming your network with multiple reports every second or two...turning off info/descriptionText logging may hide symptoms of the problem but not actually fix it). "Past Logs" are periodically pruned to a specific size, so there's little need to worry about normal logs "filling up" anything.

As noted above, most drivers start with debug logging enabled on installation and then automatically turn off 30 minutes later (after either that or a later manual enabling). These are generally only useful if you are troubleshooting something with the driver author or knowledgeable enough about the device or protocol and what to see what the driver is really doing (e.g., is it getting a Z-Wave report but not parising it correctly, or does nothing come in at all?).

Info/descripionText logging defaults to on and will remain that way unless you change it. What you prefer is up to you; personally, I like to leave mine on because it gives me a way to look through "Past Logs" to see something resembling all-device history (if that motion lighting app didn't turn off the lights, did the sensor report an "inactive"? does the light say it turned off but really didn't?)--easier than digging through each device page. Just my preference. Also, it's the default and easier to leave that way. :laughing:

There is less of a standard here for apps. Many don't log anything unless specifically enabled; some (especially ports of ST apps) are a bit chatty and may or may not be disable-able. I generally minimize or disable logging for apps (again, often the default) unless I have a reason to care, like troubleshooting a Rule or Lock Code Manager.

4 Likes
9

Wanna know what's chatty? Those little aeotec multi 6's. Man they'll clog up the traffic if you let them. Definitely turn those off.

10

Did you notice anything parituclarly chatty with yours? I noticed my temperature reporting threshold was very low, so mine was sending a lot of temperature events (not insane but maybe one every few minutes). Thankfully, it was USB-powered, but I wonder if that was the cause of my battery woes with that thing in the past...anyway, setting that parameter correctly "fixed" this for me (I guess it's not necessarily a problem, but I see no reason to create more Z-Wave traffic than you need). In any case, the place to address this kind of thing is definitely on the device side; disabling logging to hide the problem won't do anything to fix it. :slight_smile: (One reason I like to leave this enabled. Also showed me a chatty ZEN15, which Zooz just released a firmware update to fix--check it out if yours consdiers any change away from 0 Watts to be Z-Wave-worthy regardless of your percent/Watt settings, like you might notice if it's hooked up to a device that's "off" but only has a soft switch.)

11

Yah, I use my aeotecs to control ceiling fans and lux, so I want it to report on small changes because it only varies by a small number in my house because of the lighting. So I set it to report on smaller changes. But even if one is set (usb powered) to report often on one, it talks about everything once a minute. blah blah blah blah all the time. So all logging is off with them. I tend to keep everything off unless I add something new. Then I might enable it for a little while until I'm confident that things are as I would expect them to be.

12

Does anyone what "Enable descriptionText logging" does exactly?

13

In the stock drivers (and what IMHO would constitute a well written community driver), the "descriptionText logging" option will write an "info" log any time the driver causes the platform (Hubitat) to generate an event for the device. For example, here's something you might see if a motion sensor becomes active, generating a "motion: active" event:

[info] Starway Motion is active

If you are not familiar with where the above screenshot comes from, this is from "Logs" in the left-side menu.

14

@bertabcd1234 that makes sense, thanks!