DJP
August 29, 2026, 4:49pm
1
Hello
New app to support the Divoom Pixoo 64 with a focus on stability and ongoing maintenance. An older community app exists but hasn’t been updated in a while and may be unreliable depending on your setup.
Version 0.1.1 is live :
The Pixoo 64 is a 10.3” Wi-Fi pixel art display featuring a 64×64 LED matrix. It’s commonly used to showcase pixel art, act as a pixel clock, or display live information (social media counters, gaming stats, etc.). My main use case is displaying album artwork from my Ap…
It seems to work great for users but I’m getting crash reports for the past week or so with an information I don’t understand :
Error: Invalid Driver ID: dishwasher
at ManagerDrivers._getDriverManifest (/app/packages/homey-local/lib/AppProcess/node_modules/@athombv/homey-apps-sdk-v3/manager/drivers.js:210:13)
at ManagerDrivers.getDriver (/app/packages/homey-local/lib/AppProcess/node_modules/@athombv/homey-apps-sdk-v3/manager/drivers.js:223:10)
at Object.fromJSON (/app/packages/homey-local/lib/AppProcess/node_modules/@athombv/homey-apps-sdk-v3/lib/SDK.js:327:38)
at /app/packages/homey-local/lib/AppProcess/node_modules/@athombv/homey-serializer/src/index.js:180:37
at walk (/app/packages/homey-local/lib/AppProcess/node_modules/@athombv/homey-serializer/src/traverse.js:24:18)
at walk (/app/packages/homey-local/lib/AppProcess/node_modules/@athombv/homey-serializer/src/traverse.js:41:23)
at walk (/app/packages/homey-local/lib/AppProcess/node_modules/@athombv/homey-serializer/src/traverse.js:41:23)
at traverse (/app/packages/homey-local/lib/AppProcess/node_modules/@athombv/homey-serializer/src/traverse.js:61:16)
at HomeySerializer.__parse (/app/packages/homey-local/lib/AppProcess/node_modules/@athombv/homey-serializer/src/index.js:176:12)
at HomeySerializer.parse (/app/packages/homey-local/lib/AppProcess/node_modules/@athombv/homey-serializer/src/index.js:167:27)
Obviously I have 0 reference to dishwasher in my code so I wonder if it’s an issue related to Homey or another app, rather than mine.
thanks
Did you copy an example maybe from anywhere?
Is your source code on Github? Maybe I can take a look
DJP
August 29, 2026, 7:32pm
5
I’ve juste looked a bit at open issues on the SDK and it seems related to this:
opened 10:41PM - 31 Jul 26 UTC
## Summary
An unresolvable typed `Device` reference in an inbound IPC message t… hrows **synchronously** inside `HomeyClient._onMessage`, *before* the message type is examined and before the request-rejection chain runs. Because the throw happens during message parsing rather than inside a Flow/capability listener, app code cannot catch it, and the uncaught synchronous exception can terminate the entire app's Node process — so a single stale saved reference can take down an app process and temporarily affect every device that app manages.
## Environment
- Homey Pro mini 2025 (`homey6q`), Homey firmware 13.4.0
- Reproduced with a published app (`com.teslemetry`) on both v1.0.4 and v1.0.5
- Apps SDK v3 (source-parity established against the `ghcr.io/athombv/homey-app-runner` image: the observed crash stack matches `HomeyClient.js:95`, `SDK.js:328`, and `Driver.js:258-264` exactly)
## What happens (code path)
1. Homey sends the app an IPC message whose payload contains a value tagged as a typed `Device`.
2. `HomeyClient._onMessage` (≈ `HomeyClient.js:92-96`) **parses/revives the message before it examines the message type** and before the request's rejection handling.
3. Reviving the typed `Device` argument goes through `SDK.fromJSON` (≈ `SDK.js:328`), which calls `driver.getDeviceById(data.id)`.
4. `Driver.getDeviceById` (≈ `Driver.js:258-264`) indexes its private `#devicesById` map and **throws** `Error: Could not get device by id` when the runtime ID is absent.
5. That throw is synchronous and occurs before any app card/capability listener and before `HomeyClient` can reject the request, so nothing in app code can catch it. The result is an uncaught synchronous exception that can crash the app's Node process.
## Reproduction
The reliable trigger is a persisted reference that outlives the device it points to:
1. Pair a device, then create a Flow action/condition that references it as a device argument.
2. Remove and re-pair the device. Re-pairing assigns a **new** Homey runtime device ID even if the app returns a stable pairing `data.id`, so the old Flow reference can no longer resolve.
3. Run / test / update / autocomplete that stale Flow card. The inbound message carries a typed `Device` argument for the now-missing runtime ID, which takes the `SDK.fromJSON` → `getDeviceById` route above and throws during parse.
A minimal behavioral reproduction of the boundary (against the SDK's own serializer): a stock throwing `getDeviceById` lookup causes the synchronous throw and the request listener is **never** called; making the lookup return `undefined` instead lets the listener run and the request rejects cleanly with a structured `Error`. This isolates the crash to the throw-during-parse behavior.
## Expected vs actual
- **Expected:** the stale/broken Flow card is rejected (or surfaced as broken/repairable), the app stays alive, and unrelated devices are unaffected.
- **Actual:** an uncaught synchronous exception is raised before any app listener, and the whole app process can terminate.
## Impact
One stale saved reference (e.g. a Flow card pointing at a removed-and-re-paired device) can crash an app process that is otherwise healthy, temporarily disrupting every device that app manages — not just the card that was run.
## Suggested fix
1. In `HomeyClient._onMessage`, wrap message parse/revival in a try/catch so a parse/revival failure is returned as a **structured request error** (a rejected request) rather than propagating as an uncaught synchronous exception.
2. On device deletion, invalidate or mark saved/queued references (Flow cards, pending requests) as broken so a re-paired device's stale references do not revive into a throwing lookup.
Either change independently prevents the process-level crash; together they also give the user a repairable-card experience instead of a silent app restart.
I’ve uploaded the code on github anyway if you want to have a look.
DJPWeb/Homey-DivoomPixoo64: Homey Pro app to manage Divoom Pixoo64
