Now I seem to have HE working as I'd like it, I'm starting to optimise the hub.
How would I go about turning off debugging for a couple drivers that I have ported across from ST. One in particular, my home alarm (internal motion sensors) floods my logs with debug messages, and there is no option to turn off debugging in the device pages.
You must comment the debug lines of the code.
In a PC is easier, search for debug in the code and add // at the beginning of each debug line.
If you wish to "do it right" - you can find the correct code in Hubitat's source code that they've got on github.
In the preferences section, add:
input name: "debugOutput", type: "bool", title: "Enable debug logging?", defaultValue: true
in updated(), add:
unschedule() if (debugOutput) runIn(1800,logsOff)
Next, search/replace "log.debug" with "logDebug"
Finally, add these to methods somewhere convenient:
def logsOff(){
log.warn "debug logging disabled..."
device.updateSetting("debugOutput",[value:"false",type:"bool"])
}private logDebug(msg) {
if (settings?.debugOutput || settings?.debugOutput == null) {
log.debug "$msg"
}
}
The only log.debug you should have is that final line above... which is why you do the search/replace before adding the method. 
Nice, I could do that with any driver?
All developers should be doing that to all their drivers, in my opinion 
A consistent user interface would be enjoyable.
There's an additional part where the many log.???? needs to be reviewed and adjusted.
log.info seems to be exactly that.. info needed when debugging is off.
log.warn would be for problems (including "please update this code")
log.error That's obvious.
The code you posted above, it must go in each section or can I add it at the end of the driver code?
Remember, I'm dumb and I don't know any coding.
Thanks
I agree. I also think developers should be careful with log.info, too... There are a couple of drivers that log so much log.info it is ridiculous.
The first two are "inserts" -- you must put it inside a specific area.
The last you can add at the very end, for example.
I have this imaginary limit.. there should be 2-3 log.info's per driver. They are the ones that show in live logs and tell us things are working right. Can't have zero, but more than 3 is just clogging the logs, again, in my opinion. If we see a WARN, then I think turning on debug is advised, in order to give the best info to the developer.
I go back and forth on this...
For devices, if it is a sensor it should generate an event and not generate any log.info by default. If you need to troubleshoot, you turn on debug logging.
For apps, yeah it is really nice to get an "i ran" info, or something similar at times - and I often do that.
Thanks for this @csteele. This is just perfect. Exactly what I needed.
Modified and tested. Big thumbs up. Thank you.
Now, I'll change some log.debug to log.info (but only 2 or 3!).
Could this code be used in both drivers and apps?
Thanks
@stephack just added it to his Advanced Button Controller, for example.
I can't remember who originated it, but it's a good idea to add a URL to the top of driver/app pointing to the raw code such that it can be pasted into Hubitat's Import feature.
/* * Hubitat Import URL: https://raw.githubusercontent.com/stephack/Hubitat/master/apps/Advanced%20Button%20Controller%20(ABC)/Advanced_Button_Controller.groovy *
If you put something like that as the first line(s) of code, then updating is simply a matter of copying that URL from "yesterday's code" into the Driver/App Import Field. "Are you sure?" and click you're updated.
Pretty sure this was one of @ogiewon's brilliant ideas. If not, the runner up would have to be @Cobra.
Is this new?
Somewhat, yes
see the Import button there?
Same for driver code.
Not my idea!
I have all my urls on my website (and in my update code)
Andy
Download the Hubitat app
