Fix space status widget - #5
Merged
Merged
Conversation
SpaceAPI 0.13 returns state as an object ({"open": bool, "lastchange": ts}),
not a boolean, so `data.state` was always truthy and the widget reported the
space as open regardless of its real state. Read `data.state.open`.
Fetch /api/spaceapi same-origin through the nginx proxy, and drop the
hand-written Cache-Control/Pragma request headers: they make the request
non-simple, and HA answers the resulting CORS preflight with 403 because its
allowed-header list is hardcoded. The ?t= cache buster already does the job.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Member
|
Thank you mighty robot. Looks like spaceapi on ha uses older version than on jessica. VS https://ha.base48.cz/api/spaceapi Also, only: |
Member
|
Older version of code (before a3c9184) doesn't use space api but it parses: But main question is: |
Member
|
This solves only the web part so it's LGTM. Other parts can be solved in different MR's. |
/api/spaceapi proxies to Home Assistant, which serves SpaceAPI 0.13 and fails validation against the current 15.json on api_compatibility. That field is a hardcoded constant in the integration (SPACEAPI_VERSION), so no amount of YAML reaches it. /api/base_status_spaceapi.json is regenerated every minute from the same Home Assistant sensor, validates clean against 15.json, and is already what the external directories read — mapall.space, HackerspacesGlobe, MapsOfMaking and MakersMap, ~2800 requests a day against 3 for the proxy. Both carry state.open, so this is a URL change and nothing else. It also drops the request-time dependency on Home Assistant: the file keeps serving the last known state if HA or the tunnel is down, where the proxy would fail the request. HA's own endpoint reports the space as open whenever the sensor is unavailable, which is the wrong direction for a door status.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The widget reported the space as open no matter what. SpaceAPI 0.13 returns
stateas an object, not a boolean, sodata.statewas always truthy.Three changes to
js/main.js:data.state.openinstead ofdata.state— the actual bug/api/spaceapisame-origin through the nginx proxyCache-Control/Pragmarequest headers: they make the requestnon-simple, and HA answers the resulting CORS preflight with
403 CORS preflight request failed: headers are not allowed: PRAGMA, CACHE-CONTROL.The
?t=cache buster already covers cache busting.Verified against the live endpoint: before this,
data.stateevaluated totruefor both an open and a closed space.Overlaps with #4
The same-origin switch here is the same change as #4. Merge #4 first and I'll
rebase, or close #4 in favour of this — either way works, just not both.
Follow-up, server side (not in this PR)
The nginx location from base48/servers-config@c340230 sets
Access-Control-Allow-OriginandContent-Typeon top of what HA alreadysends, so the response currently carries each of those headers twice
(
add_headerappends, it does not replace). Neither breaks the widget nowthat it is same-origin, but both are worth removing.
Also worth considering: the widget polls every 20s per open tab and the
location sets
no-storewithproxy_buffering off, so every poll from everyvisitor reaches HA. A short
proxy_cachewindow would cut that a lot.🤖 Generated with Claude Code