Context for developing and debugging Hubitat Elevation apps, drivers, and hub environment — sandbox constraints, lifecycle idioms, capability contracts, plus grounded deploy/log-tail/lint mechanisms.
81
94%
Does it follow best practices?
Impact
27%
Average score across 2 eval scenarios
Advisory
Suggest reviewing before use
The only debugger Hubitat gives you is log + the live log stream (ws://<hub>/logsocket, see reference/endpoints.md). Logging discipline is load-bearing, not cosmetic.
log.error, log.warn, log.info, log.debug, log.trace — each tagged by level in the Logs page.info for user-meaningful state changes, debug for developer detail, warn/error for problems. Never log secrets or tokens.Nearly every community driver and app exposes two boolean preferences and guards its chatty logs on them:
input name: "logEnable", type: "bool", title: "Enable debug logging", defaultValue: true
input name: "txtEnable", type: "bool", title: "Enable descriptionText logging", defaultValue: trueif (logEnable) log.debug "..." and descriptive info with if (txtEnable) log.info "...".def updated() { if (logEnable) runIn(1800, logsOff) }
void logsOff() {
log.warn "debug logging disabled"
device.updateSetting("logEnable", [value: "false", type: "bool"])
}logEnable guard but typically leave it to the user to disable rather than auto-timing-out.log.debug at the point of uncertainty (raw parse input, a computed value, a branch taken), deploy, then read the log socket against the code — that is what the debug skill does. Remove or guard the noise before shipping.