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.
74
93%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
The only debugger Hubitat gives you is log + the live log stream (ws://<hub>/logsocket, see skills/_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.