菜单
Tail a Hubitat hub's live log or event websocket, filtered, and interpret it against the code to diagnose an app or driver. Use when the user wants to debug, watch logs, tail the log stream, see live events, or figure out why a Hubitat app/driver misbehaves.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Move every app reference from an old Hubitat device onto a new one — via Settings → Swap Device where possible, a virtual-device bridge or parking slot where the swap list blocks it, and a guided manual re-select where neither works. Use when the user wants to swap, migrate, replace, or move a device's references to a different device, re-home a device to a different hub over Hub Mesh, or asks why a device does not appear in the Swap Device list.
Diagnose Hubitat Z-Wave and Zigbee network problems — ghost/failed nodes, packet errors, weak routes, dead or unjoined Zigbee devices, devices that stopped responding to commands, a broken hub-mesh link, an unhealthy mesh. Use when the user wants to check mesh health, find ghost nodes, debug a flaky/slow/dead Z-Wave or Zigbee device, or figure out why the radio network misbehaves.
Safely remove a Hubitat device — enumerate where it's used, warn about the blast radius before deleting, verify references cleared after, and re-wire them onto a replacement device. Use when the user wants to remove, delete, retire, or replace a device, or asks what a device is used by before deleting it.
Update Z-Wave device firmware on a Hubitat hub via the native zwaveJS updater — discover installed versions, find vendor-latest firmware, stage it, and batch-flash safely with a radio-hang watchdog. Use when the user wants to update/flash device firmware, check which devices are behind on firmware, or fix a device whose issue a firmware update addresses.
Deploy a Hubitat app or driver's Groovy source to a hub and confirm it saved and runs by watching the log stream. Use when the user wants to deploy, push, upload, or install app/driver code onto a Hubitat hub, or iterate the edit-deploy-check loop.
Manage the hubs.json config that records how to reach each Hubitat hub by IP for code operations. Actions — init a config, add a hub, set the default hub, remove a hub, list hubs. Use when the user wants to configure, register, add, or list Hubitat hubs for deploy/pull/debug.
| name | debug |
| description | Tail a Hubitat hub's live log or event websocket, filtered, and interpret it against the code to diagnose an app or driver. Use when the user wants to debug, watch logs, tail the log stream, see live events, or figure out why a Hubitat app/driver misbehaves. |
Process steps in order. Do not skip ahead.
Hubitat has no debugger — diagnosis is log.debug plus the live stream (logging-conventions rule). This skill tails that stream and reads it against the source.
Read skills/_reference/endpoints.md before probing for any endpoint.
Establish what is wrong and which app/driver it concerns, and pick the socket:
logsocket — the debug/info/warn/error log lines (default; use for "my code does X wrong").eventsocket — device attribute events (use for "the attribute isn't updating / the event isn't firing").For a failure that already happened, reach for history instead of a live tail:
/device/eventsJson/<id> — when an attribute actually moved, and which app issued a command./hub/eventsJson — whether a platform update landed near the onset.Have the source in hand so the log can be read against it. Proceed to Step 2.
python3 .tessl/plugins/jbaruch/hubitat-dev/skills/_scripts/hub_logtail.py --ip <addr> \
[--socket logsocket|eventsocket] [--name "<name>"] [--min-level debug] [--seconds N | --follow]
Argument and output contract, filter semantics, and frame shape: skills/_scripts/hub_logtail.py module docstring, and skills/_reference/endpoints.md for the raw frame fields. Filter tightly — --name to the app/driver under test — so the stream is readable. Default is a bounded window; use --follow only when the user will actively trigger the behavior.
Proceed to Step 3.
While tailing, have the behavior exercised (press the device command, fire the app trigger, wait for the schedule). If the code lacks a log line at the point of doubt, add a guarded log.debug there (if (logEnable) log.debug "..."), redeploy with Skill(skill: "deploy"), and tail again. Proceed to Step 4.
A missing expected line means the branch wasn't reached; a groovy.lang.MissingMethodException or null error names the failing call. Cross-reference the groovy-gotchas and lifecycle rules — a handler that never logs is often the string-name, the first-run-installed(), or the 2.5.1 e.statusCode trap, where the NPE escapes the catch and kills the recovery below it.
A status is not a fact. Read lastPollDate, authTokenExpires, or an event date; treat a status label as cached state, never a probe. Verify an action by re-reading what it changed (/device/fullJson/<id>, /device/eventsJson/<id>), never by the app's own "I did X" line.
A value's timestamp is not a liveness signal. A frozen attribute's event date dates the last change, not the last report — a steady world and a dead integration look identical. Read liveness off a monotonic attribute (thermostatTime) or your own stamped read, never off a value's timestamp or an attribute merely named like one (lastPoll). Full split: rules/state-vs-attributes.md. Radios: rules/zwave-zigbee-mesh.md. Endpoint timezone and ordering splits: skills/_reference/endpoints.md.
Reconcile disagreeing sources before diagnosing. Proceed to Step 5.
State the diagnosis with the evidence (the frame that showed it) and the fix. Separate proven from inferred — name which claims a frame or a timestamp demonstrates, and which are correlation you have not bisected. If the fix is a code change, offer to apply it and redeploy. Finish here.