setGlobalVar() doesn't check the passed value against the hub variable's type, and it returns true whatever happens. A DateTime variable ends up holding any string, and a Number or Decimal variable ends up null. Maker API's /hubvariables/[name]/[value] endpoint behaves the same way and returns HTTP 200.
(report below with Claude Code's help)
How I found it: an app of mine cleared a DateTime variable with setGlobalVar(name, "") when it had no date to store. A Thermostat Scheduler period whose start time used that variable then made the scheduler's page throw an ArrayIndexOutOfBoundsException every time it rendered. The Hub Variables page shows that value as **bad DateTime**.
I tested every type with a throwaway app, which wrote a list of values with setGlobalVar() and read each one back with getGlobalVar():
| Type | Values that don't fit | Stored as | Returned |
|---|---|---|---|
| DateTime | "", "abc", 42, true, "2026-10-03", "14:00", "2026-10-03T14:00:00-04:00" |
the string, unchanged (page: **bad DateTime**) |
true |
| Number | 3.14, "3.14", true, "abc", "", a Date |
null |
true |
| Decimal | "1,5", NaN, Infinity, true, "abc", "" |
null |
true |
| Boolean | anything except true, "true", "TRUE" (e.g. "yes", 1) |
false |
true |
| String | anything | String.valueOf(value) |
true |
setGlobalVar() does reject some values: a null value and an unknown name return false and change nothing, and a value over 1024 characters throws IllegalArgumentException.
Connector devices (the generic "Variable" connector, given device commands such as setVariable) mostly behave the same:
| Connector | Values that don't fit | Result |
|---|---|---|
| Number | "", "abc", "3.14", "1e3", "true" |
variable becomes null |
| Decimal | "", "abc", "1,5", "NaN", "true" |
variable becomes null |
| Boolean | "abc", "yes", "1" |
getGlobalVar() reads false, but the Hub Variables page shows the raw string (abc) |
| String | over 1024 characters | ignored, no error |
| DateTime | setDateTime("abc"), setDateTime(""), setDate("abc"), setTime("abc") |
ignored, variable unchanged |
The DateTime connector is the only one that rejects bad input.
Expected behaviour. I'd expect setGlobalVar(), the connectors and Maker API to do what the DateTime connector already does: check the value against the variable's type and, if it doesn't fit, leave the variable unchanged. setGlobalVar() would then return false.
- Number: an integer, or a string that parses as one.
- Decimal: a finite number, or a string that parses as one.
- Boolean:
true/false, or"true"/"false"in any case. - DateTime: a
Date, or a string in the format the hub stores (yyyy-MM-dd'T'HH:mm:ss.SSSZ, including the date-only and time-only forms the Hub Variables page writes). The Hub Variables page already tells these apart from bad values. - Maker API: an HTTP 400 when the value is rejected, not 200.
- Connector commands: leave the variable unchanged, as the DateTime connector does.
Would you rather return false or throw, as the 1024-character limit does? Returning false would keep existing apps from breaking.
Bad values can already be stored on hubs, so it would also help if Thermostat Scheduler, and anything else that reads a DateTime variable, treated a value it can't parse as unset and didn't throw while rendering the page.
