I'm sucking on clorine gas atm so head is wonky - (okay, cleaning my bathroom and the clorox and 409 mixture is potent).
I'd love to see all developers use the same techinques for logging.
Info - normal - on, off, state change etc.
Trace - used for breakpoints - ie; you are in xxx routine'
Warn - error or problem condition
Debug - command output structure
Either when I mod someones work or install something -
invariably I get logs that 'will turn off in 30 mins' (uh. no one asked you too turn them off OR on), or hitting the config button generates trace and debug and warnings, or there are just no preference switches at all.
Wouldn't it be nice if all drivers used built in pre-built inputs? Hopefully with all defaults set false except Info?
Markus did em right, and there are some exceptionally well done implementations but wow, everyone seems to approach it differently.
Can't we just all get along? Maybe a community shared library? #include BirdsLikeWires.library at the top of your code? it's a thought anyway
Probably not - at least not in the context of your OP.
Hobbiest programmers will always do it "the way they know how" / can brute force make it work. And honestly, debug/trace events are more for them than you, so I'm not sure most of them would care if it is how you would prefer it to be or not. I don't mean that in a negative way, either.
It never hurts to try and ask for consistency, but to expect it across a fleet of programmers with various skills and experience is likely futile.
I do agree that driver writers should be encouraged to use the in-box capabilities instead of custom commands whenever possible.
Go ahead and write one, I guess. Maybe people will use it, maybe they won't. No one is stopping you though if you think it is a worthwhile enterprise. De facto standards are often made organically after there is a work product multiple people glom onto (e.g. HPM).
And don't get me wrong, I'm not trying to be negative. But questions like "shouldn't we all use a shared library" elicit responses similar to when people ask "shouldn't we have a community wiki?" or "shouldn't there be a list of all community made apps and drivers somewhere?".
Sure - go ahead and make one...
But in reality often those people that are saying "shouldn't we have one" really mean "could someone else do all the work in making one, spend their free time maintaining it for the next 3-5 years, and give it to me to use for free?".
I'm NOT saying that is what you are doing, rather just explaining why for me that question yields the answer I gave.
I agree with @JasonJoel that asking people to be consistent is less likely to achieve what you are after, but if you make it easier by way of a common bit of code people can include, along similar lines to the way HPM has become ubiquitous, then you may get more traction. Admittedly HPM has a slightly more appealing outcome of ease of distribution of drivers and apps.
I'd add that I have similar feelings around code that does not provide me the ability to turn off the various logging produced by the driver or app. Consistency is one thing, but having control of any sort if also nice as a starting point.
This is standard stock driver behavior for debug logging, and most well written community drivers emulate it for that reason. Specifically, debug logging is enabled upon adding a device and any time you manually enabled it, then scheduled to automatically disable itself after 30 minutes, due to the fact that it is normally needed only for short-term troubleshooting to make sure the driver is functioning correctly for the device. "Info" or descriptionText logging (for events, basically what you're describing) is enabled by default and remains enabled until disabled.
Apps vary a bit more and tend to offer different types of logging based on functionality. Some drivers may also vary a bit, though this convention is a lot stronger for devices than apps. Certain methods may log something regardless of settings (e.g, it can be helpful to know when an app or driver is re-initialized or "updated"/saved), but this would generally not be spontaneously generated without user action.
But, of course, community code may vary quite a bit, likely for the reasons mentioned previously. The thought is certainly nice, regardless of what may or may not happen, even if I'd personally not count on much for the same reason (but do think emulating stock behavior is a good idea for most apps and drivers).
Actually a good idea. But, this is an example why un-mandated standards often die. There are better ways but no way to readily update/implement the standard to all developments.
For a platform like Hubitat the best way would be for set of helper functions (standardPreferences, standardLogging, etc) that the developer calls from the code. Then as the staff decides to change the "standard", it automatically disperses to the community drivers and apps. Of course - it would take a lot of time for existing apps/drivers to be updated to use this standard. Additionally, probably an UNREASONABLE request to the staff.
I have wanted to get away from the two "standard" toggles for a while. Partly because I use the trace logging for debugging a lot but previously I had it as a commented out line in the code. Its easier to turn on from the UI per device. Also I wanted to let people pick the auto-off time. I started working on my own driver library for my common stuff and I came up with this for logging. Got rid of the other toggle and added two new settings.
What do you all think?
My other thought was to just have one setting with the permanent log level and then have a command button to set a temporary elevated level if needed but the command button was ugly and bothering me.
What if I, as a user, wanted to log both Error AND Debug, for example? Is there a way to set two or more log levels at the same time, or is it just one at a time?
That seems smart! Would there ever be a use-case where I would want just TRACE information; but it might be difficult to "follow" because of the other log levels cluttering the log file?
Yes as @anon47916022 said it would log anything from the level you set and lower. The way I do my logging Info > Debug > Trace all compliment each other so it is good to have them all on if you need the most logging. Error and Warn are used for exactly that, errors or critical warnings.
Info - status changes and other general info
Debug - events where status does not change (or forced events). Other info thats helpful for troubleshooting but you don't necessarily want to see in the logs all the time.
Trace - Logs info for nearly every function with the parameters sent to it. Useful for heavy programming debugging only. Used to "trace" the code as it moves through functions.
