There are several logging levels for output to the log, listed in decreasing order of severity..
error
warn
info
debug
trace
Is there, and if not could there be, some overall setting in an app to disable messages below a certain severity threshold? It would be really useful.
I have seen this post for specific debug handling, which could be used for other levels too but an inbuilt functionality would seem much easier. Maybe the selected level could be made available in any child apps/devices too.
This has been done (primarily with debug logs) in a lot of existing apps and drivers, including built in ones. The only one I know that does this level of granularity is the Lifx GOG driver I ported from ST. See the "logging" input, the log() and determineLogLevel() method in the driver below. I think this will do exactly what you are looking for.
Thanks, that looks like exactly what I need. I'll pinch it if I may.
My only point being that you have to add quite a bit of code to all your apps and drivers. I think it would be useful as a simple system level option that might then be enforceable on any child apps and devices you use.
I have already received approval from Mr. Vitale to pilfer the code at will. I would just add a comment giving him credit for the logging code somewhere. Seems like the right thing to do.
Absolutely agree. Couldn't hurt to ask via a feature request. I doubt it would be a priority but Chuck and Patrick have come through on lesser tasks.
Or you could do like Cobra and make a Parent app container for all your apps and drivers. I considered do this once but the maintenance would be too much and I only do this for fun. I use my Virtual Container driver to keep my drivers organized and simplified but that's as far as I'm willing to go.
I like that idea a lot. A per app/device Logging Level setting on the system side instead of app/driver side.
Then as developers we only focus on adding the messages - end user decides how much of them they want.
I would be inclined to add a lot more logging statements in my code if I didn't have to directly manage them.
As it is now, I do the same debug logging setting w/30 minute turnoff that most others do. But while developing I have a lot of trace and other logging in there that I have to strip out now - could just leave it in with this model...
Interesting .. the documentation , at least on ST shows 'info' as being more severe than 'debug' and the only less severe is 'trace'. With your implementation that implies 'trace' would suit you better than 'info'. I think, as I guess you do, the names used seem misleading - at least with 'info'.
It would have been nice to have something that logs green to be able to show 'success' more visibly - as I wade through my app it would boost my morale !
I consider ‘info’ to be just that information... e.g switch is on
Debug is a higher level.. e.g I’m inside the method that runs when I want switch to change to on.
I don’t generally use trace
Warn is the next highest and finally error
That's pretty much the standard for anyone coming from smartThings. The common levels are info, debug and warn. Personally, I've rarely seen warn and even less so with trace.
LOL...I do the exact same thing when I'm trying to find a problem that might be in the middle of a ton of logging. I pop a WARN in there so I can find that specific log easily. I remove it before I publish though.
The color scheme of the log level classifications is "locked", because it's part of the Groovy Environment of the hub itself, which apps and drivers have no access to, as far as I know.
To my knowledge [error] level messages generated by the hub's JVM cannot be silenced or suppressed, and that's a good thing, because they inform the developer (or unwitting user) of unexpected situations in the app or device driver code.
On the other hand, the output and management of [error] and any other level of log messages generated by apps or device drivers is totally left up to the developer / programmer. I can think of few cases on both the ST and Hubitat platforms where an app / device driver uses the full range of levels and makes use of a logging level "threshold" setting. Most seem to use just the [debug] and/or [info] levels for log messages, and if there's any user control, it's either a permanent or timer-based toggle setting.
If you're looking for a global setting to enable / disable certain levels of log message output, then you'd need to direct that request to Hubitat. I can see some advantages to that, but then there is of course the confusion that comes out of have two control points: globally as well as on a per app / per device basis. I don't think it would be a good idea for an app to have control over the log output levels of a device unless the device was specifically created by the app (e.g., a virtual device, or a bridged device controlling something connected to a third party server/system).
The ST docs differ in the severity hierarchy - debug sitting between trace and info
My thoughts were for debug level control at the app level - not globally, allowing a deeper level of debugging for specific apps. I also was talking about passing through comparable logging levels to devices and apps that were children of the app.
I have implemented this in my app, based on the ST docs, and using the LIFX code from Vitale
@kevin, for an entirely different reason I was looking through the Influxdb Logger app code and realized that it also used a similar logging hierarchy as the Lifx driver. Strange coincidence.
In a moment of frustration I went off track in one of my bug report threads somewhat recently and pointed out the lack of a system level threshold for logging as well as some of the OOB drivers/apps that are sort of chatty even if you turn all the logging off that's configurable for them.
I would eventually like to get to the point where my system is stable and my log is essentially clear of pretty much anything unless it requires intervention. In some systems you can choose to batch up logs above a desired level and email them or report on them or whatever. This would be my ultimate goal. I don't want to visit the log page unless I'm developing. I want Hubitat to tell me when I need to look at something.
That's why when I write drivers I don't allow suppression of warn or error level via a setting. If I put something at that level I think it should be seen always because I consider it to be important. I allow configuration of info, debug and trace. And at some point I may just remove the trace preference (keep the logs in the code but don't let the end user turn them on) because if you turn it on it can get really chatty and affect system performance.
(Resurrecting an old thread, since I didn't want to create another one on the same topic. Please close or redirect if this request has been resolved.)
I came across this discussion while looking for a system-wide logging level setting. While it doesn't seem to have been implemented yet, I came across the "Hubitat Variables" section under Settings. I'm wondering if we could use it as a global variable, which would (hopefully) be accessible to all apps, and can be used to set the logging level accordingly. We could agree on a standard naming convention like: "APPS-LOG-LEVEL" and "DEVICE-LOG-LEVEL", with values such as Trace, Debug, Warn, Info, and Error. Apps would still have to implement code to utilize these variables, but this would be common code now, which would benefit from multiple authors and reviewers.
@kevin You are indeed correct
I was wondering if it is a good idea to get others (and maybe even Hubitat folks themselves), to adopt a standard Environment Variable?
