jbaruch/hubitat-dev
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
hubitat-dev
Context for developing and debugging Hubitat Elevation apps, drivers, and the hub environment. This plugin does not write your Groovy for you — it makes an agent write it correctly: the sandbox constraints, lifecycle idioms, and capability contracts that the platform enforces but the docs bury, plus thin mechanisms for the deploy / log-tail / lint loop the hub gives you no official API for.
Grounded against real hardware: Hubitat C-8 Pro, platform 2.5.1.125, local network, Hub Security off. The code-editor and logging endpoints it drives are undocumented and version-sensitive — see reference/endpoints.md for what was verified and when.
What it covers
- Authoring — apps and drivers are single Groovy 2.4 files run in a locked-down sandbox. The rules encode what that sandbox forbids and the idioms that keep an app from silently doing nothing.
- Deploy / pull — push source to a hub and pull it back over the same undocumented HTTP endpoints HPM and the VS Code extension use, with the
versionoptimistic-concurrency token handled for you. - Debug — tail the hub's
/logsocketand/eventsocketwebsockets (structured JSON, no library needed) and read them against the code. - Lint — catch the sandbox violations and silent-failure traps (bad imports, handler-name typos, capability→command gaps, the
installed()/updated()first-run trap) before you paste. - Test — take apps and drivers off-hub for real unit tests.
Rules
All rules are always-on — installing the plugin means you want this context.
| Rule | Purpose |
|---|---|
| sandbox-constraints | What the Groovy 2.4 sandbox forbids — no user classes, threads, sleep/println; the 197-class import allow-list. |
| app-lifecycle | App callbacks and the installed()→updated()→unsubscribe() idiom that keeps an app from silently doing nothing. |
| driver-lifecycle | Driver callbacks, the capability contract (declare = must implement), and the parse() dispatch pattern. |
| logging-conventions | The logEnable/txtEnable toggles and the runIn(1800, logsOff) auto-disable idiom. |
| state-vs-attributes | Attributes via sendEvent (subscribable) vs. state/atomicState (private, JSON-serializable). |
| groovy-gotchas | Silent-failure traps the compiler misses: string handler names, 0-is-falsy, null device inputs, reserved names. |
| multi-hub-topology | Code is per-hub-by-IP, devices can mesh; local-no-security assumption; the deploy version token. |
Skills
| Skill | Use when |
|---|---|
| scaffold | Generating a correct app or driver skeleton from declared capabilities, self-checked with the linter. |
| deploy | Pushing app/driver source to a hub and confirming it via the log stream — no browser copy-paste. |
| debug | Tailing the log/event websocket, filtered, and reading it against the code to diagnose. |
| lint-review | Linting Groovy for sandbox violations and silent-failure traps, then judging each finding. |
| test | Setting up offline unit tests (biocomp/hubitat_ci) so logic is exercised off-hub. |
| hub-config | Managing hubs.json — register, list, and set the default hub (action router). |
Typical loop: scaffold → lint-review → deploy → debug, with hub-config set up once and test for anything with real logic.
Installation
tessl install jbaruch/hubitat-devHubs
Hub code operations are per-hub by IP (there is no mesh for code — only for devices). Hub connection details live in a hubs.json config the hub-config skill owns. Local network, no Hub Security assumed.
- Workspace
- jbaruch
- Visibility
- Public
- Created
- Last updated
- Repository
- https://github.com/jbaruch/hubitat-dev
- Publish Source
- GitHub
- Badge