Skip to content

EasyIQ (0001): surface API errors and schema mismatches at WARNING level - #355

Open
spraot wants to merge 1 commit into
scaarup:mainfrom
spraot:legacy-easyiq-error-surfacing
Open

EasyIQ (0001): surface API errors and schema mismatches at WARNING level#355
spraot wants to merge 1 commit into
scaarup:mainfrom
spraot:legacy-easyiq-error-surfacing

Conversation

@spraot

@spraot spraot commented May 11, 2026

Copy link
Copy Markdown

Summary

The legacy EasyIQ block (widget 0001) wraps the Events iteration in a bare:

try:
    for i in ugeplaner.json()["Events"]:
        ...
except KeyError:
    _LOGGER.debug("None")

Any non-Events response — including the EasyIQ error envelope {"ErrorCode": "1", "ErrorDescription": "..."}, which the API now returns aggressively for schools that have migrated to SkolePortal but still have widget 0001 listed — falls into the except and is logged at DEBUG level as the literal string "None". Downstream, the sensor attribute renders as just <h2> Uge NN</h2> for every child with no log line at default verbosity indicating why.

This PR makes two small additions, no behaviour change for happy paths:

  1. After the existing DEBUG dump of the response, detect the EasyIQ error envelope shape and log it as a WARNING naming widget id, child, institution header, week, ErrorCode and ErrorDescription.
  2. Replace except KeyError: _LOGGER.debug("None") with a WARNING that names the missing key and the response keys it did see — so the next EasyIQ schema change isn't silent either.

Genuine empty weeks for a child still produce no warnings (the date-format check still DEBUG-logs to a "None"-style line, just with more context).

Why

Filed as a follow-up to the drive-by suggestion on #352. The silent-failure mode cost a couple of hours of diagnostic time before enabling debug logging revealed the actual ErrorCode/ErrorDescription payload. Surfacing it at default verbosity should save the next person the same archaeology.

Test plan

  • Module syntax-checks clean (python3 -c 'import ast; ast.parse(...)').
  • Verified locally on HAOS against the equivalent surfacing path (applied as part of an earlier patch); the WARNING fires once per child per week when EasyIQ returns the license error, and the sensor body is unchanged for genuine empty weeks.
  • @MartinSaaby offered on Add EasyIQ SkolePortal support (widget 0128) #352 to verify the WARNING fires correctly on a SkolePortal-only school whose widget list still contains 0001.

The legacy EasyIQ block wraps `Events` iteration in a bare
`try ... except KeyError: _LOGGER.debug("None")`. Any non-`Events`
response — including EasyIQ's `{"ErrorCode": "1", "ErrorDescription": "..."}`
error envelope, which it now returns aggressively for schools that
have migrated to SkolePortal but still have widget 0001 listed —
falls into the except and is logged at DEBUG level as the literal
string `"None"`. Downstream, the sensor attribute renders as just
`<h2> Uge NN</h2>` for every child with no log line at default
verbosity to indicate why.

Two changes:

1. After dumping the response at DEBUG, detect the EasyIQ error
   envelope shape and log it as a WARNING naming widget id, child,
   institution, week, ErrorCode and ErrorDescription.
2. Replace `except KeyError: _LOGGER.debug("None")` with a WARNING
   that names the missing key and the response keys it did see —
   so the next EasyIQ schema change isn't silent either.

Same UX for genuine empty weeks (the date-format check still
debug-logs to "None"-like lines). No change to the rest of the 0001
flow, no new dependencies, additive only.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant