Menu
How to evaluate whether a cloud IoT API is permanently dead vs temporarily broken, and what to check before writing a new driver.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Pattern for keeping a rolling temperature-trend sample buffer in Hubitat state, computing slope over a configurable window, and classifying rising/falling/steady/unknown.
Implement Tuya Local v3.3 Groovy drivers on Hubitat using rawSocket, AES-128-ECB, queued retries, and defensive frame parsing.
Use Hubitat async HTTP plus a request queue to authenticate with Cognito, cache tokens in state, refresh proactively, and replay a single 401-failed request.
When two agents produce overlapping skills in one session, consolidate by merging unique content into the highest-confidence existing skill.
Never let cached-state dedup bypass session validity in cloud-backed Hubitat drivers.
Standard guard pattern for async HTTP response callbacks in Hubitat drivers
| name | cloud-killed-api-evaluation |
| description | How to evaluate whether a cloud IoT API is permanently dead vs temporarily broken, and what to check before writing a new driver. |
| domain | protocol |
| confidence | high |
| source | earned — MyQ/Chamberlain feasibility research, 2026-05-18 |
Use this skill when a user asks about writing a Hubitat driver for a device whose cloud API has been revoked, broken, or rate-limited to death by the manufacturer.
"Is the API closed by policy or broken by accident?"
| Signal | Broken by accident | Closed by policy |
|---|---|---|
| Company public statement | None | CTO/PR statement with reason |
| Developer page | Exists, possibly stale | 404 or "authorized partners only" |
| Community projects | Patching | Retired, forking to hardware alternatives |
| Time pattern | Intermittent breaks with repairs | Continuous escalation → final block |
| Partner program | Open/free | Commercial fee required |
MyQ is the canonical "closed by policy" case (October 2023, formal CTO statement, partner fee required, HA removed integration, homebridge-myq retired).
<brand>.com/developer, <brand>.com/api, <brand>.com/partnershome-assistant.io/integrations/<name>last commit on the canonical Python library (e.g., pymyq, python-ring-doorbell).When cloud is dead, the community almost always converges on local hardware:
Hardware alternatives expose documented local REST APIs that are:
Apply the hubitat-iot-consumer-auth-dead-ends skill:
Verdict as of 2026-05-18: Cloud API permanently closed.
When a hardware alternative runs ESPHome firmware, the REST API is standardized and stable.
Entity domains: sensor, binary_sensor, switch, light, cover, fan, select
Read state (GET):
GET http://<ip>/<domain>/<entity_name>
→ {"id": "cover/Garage Door", "state": "OPEN", "value": 1.0, "current_operation": "IDLE"}
Write/command (POST):
POST http://<ip>/cover/Garage Door/open → opens
POST http://<ip>/cover/Garage Door/close → closes
POST http://<ip>/cover/Garage Door/stop → stops
POST http://<ip>/switch/Dehumidifier/turn_on
POST http://<ip>/light/Main Light/turn_on?brightness=128
Note on entity name format (as of ESPHome 2026.8.0):
The id field in REST responses will switch to domain/entity_name format in ESPHome 2026.8.0, replacing legacy domain-object_id format. Any driver reading the id field should be aware of this migration.
Not usable from Hubitat: SSE stream at /events (streaming HTTP; Hubitat sandbox blocks persistent connections).
Poll pattern: asynchttpGet at 5-second intervals. HealthCheck Pattern A (full HealthCheck + ping() because it's local LAN).