Known discrepancies
Places where the runtime, the TypeScript types and in-product prose disagree.
This page is generated by the docs exporter's drift check, plus hand-written notes. Each entry disappears automatically once the platform fixes it.
| Kind | Subject | What | Ticket |
|---|---|---|---|
undeclared-runtime-global | sendLocationEvent | sendLocationEvent exists at runtime but is not declared in ambient.d.ts, so TypeScript authors do not see it. | — |
undeclared-runtime-global | getEntityIds | getEntityIds exists at runtime but is not declared in ambient.d.ts, so TypeScript authors do not see it. | — |
unreachable-host-command | getMode | Host command "getMode" is registered by SmartAppRunner but no isolate helper calls it, so smart-app code cannot reach it. | — |
note | temperature units | ambient.d.ts says temperature reads and writes are in the location's unit system; the smart-app AI prompt says all DSL temperatures are °C. Until the platform team confirms which is true for state reads versus setTemperature service data, treat temperatures as being in the location's unit system (getUnitPreferences()), which is what the runtime types document. | DX-9 |
note | runOnce | The type accepts string | Date, but the helper ignores anything that is not an ISO string. Pass date.toISOString(). | DX-15 |
note | AI prompt vs runtime | The in-product AI assistant prompt documents defaultValue, filter: { domain }, a semver version on definition, setBrightness, and event.target; the runtime uses default, domainFilter / deviceClassFilter, a hub-assigned integer version, turnOn({ brightnessPercent }), and { entityId, oldState, newState } events. This site documents the runtime behaviour. The legacy filter object is still accepted and normalised; defaultValue is ignored. | DX-4 |
note | input hydration | Inputs of type domain, mode, hub, app, accountUser* and object are never hydrated as globals and must be read from settings. | DX-11 |