How to read the "logs"

So my hub set up has been fairly stable for quite a while. A few small additions and edits over this past year. All of a sudden things stopped working. I'm not sure what possessed me, but I checked the logs (not something I do routinely/often), and I noticed a lot of red "error" tags after the date/time.

I reset the hub a few days ago, and everything seems to be functioning as it should be. Still waiting a few more days to be sure, since not all of my rules have run yet (because waiting for trigger).

I went to check the logs now, and mostly the tags now read white "info" with quite a few blue "debug" scattered through each day. Those devices seem to be working properly. Is this an issue? Is there something I need to do about this?

I'm not sure what a "normal" log looks like.

thanks

Normal can, to some degree, be what you want it to be, in terms of how many logs you see coming through. Most info and debug logs are normally nothing to worry about, they are there if you want to know when things are occurring, but I like to keep my logs relatively "clean", often turning off the logging for devices and apps when I don't need it for any debugging / troubleshooting. I only learned recently if you click on the debug / info text your device or app that the log relates to will open in another browser tab. You can then, in most cases, adjust logging preferences to suit your needs, e.g. enabling or disabling info logging.

Most of the time logs will tell you what the issue is exactly. You may not understand it all the time, but you can post it in the community and someone will. How to collect information for support - Hubitat Documentation explains how the HE logs work. You can also look at past logs and enter the search term error. If the buffer hasn't purged, you might still find your error in there.

Clicking on the app or driver ID on the left will show you in the list above where the error is coming from. Then you can look at the error and see if you can determine what might be the cause. Typically, it isn't just the app or driver itself if it was working before without error. Not that it can't be, there are specific cases where a custom app or driver can begin to cause errors over time. But most commonly, it will be that a device or a connection to something IP based is down and that causes the error. But without the logs, it's going to be hard to tell what's going on.

2 Likes

To add to the above, Hubitat convention for when device logging is enabled is that:

  • "debug logging" is enabled for 30 minutes after a new device install or if manually enabled any time after, then it automatically turns off; and
  • "info logging" (or "descriptionText logging") is enabled by default and can be changed by you at any time (and will remain as such until you change it).

Hubitat convention for what these kinds of logs do is generally that:

  • debug logs show messages coming in from devices (e.g., a Z-Wave report) and how they get parsed (or don't); generally they are most helpful for the driver author or someone who knows how the device or driver is likely to function, but they may be helpful for you to some extent too; for some drivers, they also show what commands are executed when (so may be helpful if you're not sure what an app is doing with the device--but, again, not all drivers do this); and
  • info logs show device events (true to its other name, usually the "description text" you'd also see on the "Events" tab on the device page, or a reasonable description of the event in any case)

For apps, there is less of a convention, but I think most built-in apps don't log much by default and have options to control what they do. For community code of any kind--apps or drivers--the above conventions may...vary. :slight_smile: Many, however, also follow the above. Occasionally a stock driver logs something unexpected, too--maybe staff forgot an if on the line of code that prints the log, for example. So, that raises a question: what device is this (or really, what driver is it using) and what is the log entry you see?

Or to summarize all this: seeing debug logs isn't "bad" per se (though it is unusual if you didn't enable them or recently add a device), and seeing "info" logs is normal unless you turn them off--for devices (apps, again, may vary but most have options too).

Finally, there are a few other log levels you may see: trace, warn, and error. There isn't really a convention for when "trace" is used, but if any apps have "extreme/verbose" logging as an option, that is what some may choose. Warnings and errors are probably bad, but you'll have to look into them to see for sure ("unhandled" errors--thrown by the platform on behalf of the app/driver and not logged by the app/driver itself--probably are bad, though you can't really tell the difference without the code in front of you; but Hubitat uses the "warn" level for the "hey, debug logging is getting automatically disabled now" message for some reason, too, so...).

1 Like