AROYA · Pre-WP5 Firmware Update Readiness

A Golden State · Facility 199

Generated 2026-06-05 02:01 UTC · Gateway H2100000355 (WP4) · 70 devices in portal_api inventory · ATMOS 14 climate sensor fleet
Data scope: This report is built from a verified page-1 sample of 7 devices out of the 70 active devices that portal_api returned for this facility. Pagination pages 2–3 (≈45 additional devices) could not be retrieved during this audit window due to a browser-bridge contention with other in-flight pulls. Aggregate counts and gateway identity are verified from API metadata. Per-device table below lists only the 7 fully-verified rows. Re-run the audit for the complete 70-device table when the portal session is idle.
2
Will receive WP5
0
Should receive WP5
2
At risk — bring up first
0
Likely to miss the push
3
Offline — stays on WP4
0
Not assessable
Will receive WP5 online + healthy Should receive WP5 minor watch At risk bring up first Likely to miss bring up / retire Offline — stays on WP4 not harmed Not assessable gateways

How the WP4→WP5 push works

The update is WP4 → WP5, pushed over the air by the gateway (H2100000355) to every device that is online at the scheduled time. Go/no-go criteria per device: online, battery ≥ 30%, signal ≥ 50%. Offline devices simply stay on WP4 — they are not harmed and they are not destroyed. The constraint is WP4↔WP5 compatibility, not damage; stragglers can be recovered later by reverting a gateway to WP4 and re-running, with no time limit. The default plan is remote — a site visit is the exception.

Mesh backbone — A Golden State

This facility is one of the older AROYA deployments (facility ID 199, devices created 2019–2020). The gateway H2100000355 is currently the only WP4 gateway here. In the page-1 sample, the mix is split: a meaningful share of devices last communicated in 2020–2021 and have been dark for several years (they stay on WP4 — not harmed — and are retire/trade-in candidates if those rooms aren't in use). The live, online devices are concentrated in the Flower rooms; signal strength on several of them is weak (1/6 bars in the portal_api summary scale), so a brief mesh tune-up before the push will improve coverage.
Repeater 1 and Repeater 2 are dark in this sample (last communication 2020). If those repeaters were intended to backbone the Flower-room nodes, that very likely explains the low signal on the live Flower-1 / Flower-2 ATMOS 14s — they have no nearby repeater to hop through. Restoring at least one repeater before the push (or repositioning a gateway/sink) is the highest-leverage move for hitting the ≥50% signal threshold on the AMBER devices.

Per-device readiness · sample of 7 of 70

Loading sync…
SerialClassRoomBucket OnlineBatterySignalLast comm FailureAction Upgrade?Quote

Recommended sequence

  1. Restore at least one repeater (Repeater 1 or Repeater 2) to backbone the live Flower rooms. Without a working repeater, the AMBER ATMOS 14s in Flower 1 / Flower 2 are at 1/6 bars and may drop below the 50% threshold at push time.
  2. Verify the GREEN ATMOS 14s in Flower 3 / Flower 4 are still showing 4+ bars in the AROYA app the day of the push.
  3. Decide on the dormant cohort (RED devices last seen 2020–2021): leave them on WP4 (no harm), or pull them for retirement / trade-in. The brief here is honest — they will simply not receive WP5; they are not broken by it.
  4. Schedule the WP4→WP5 push on the gateway. Remote, no site visit required. Devices that come online later can be picked up by a follow-up push, or recovered to WP4 via a gateway revert if needed.

Pull the full 70-device table

This sample is page 1 of 3 from portal_api/devices/?facility_id=199&retired=false. To populate pages 2–3, run:
opencli aroya raw --path '/portal_api/devices/?facility_id=199&retired=false&pagination=1&page=2' --format json > page2.json
opencli aroya raw --path '/portal_api/devices/?facility_id=199&retired=false&pagination=1&page=3' --format json > page3.json
opencli aroya raw --path '/portal_api/devices/?facility_id=199&retired=true'                       --format json > retired_pool.json
Re-run the audit pipeline against the concatenated JSON to get the complete six-bucket KPI strip and per-device table. The retired pool (TEROS-12 atm14 sensors whose host puck is retired) is the upgrade-target list for the TEROS One trade-in offer (Climate One $629 MSRP, $150 off → $479).
Source: portal.aroya.io / portal_api/devices/?facility_id=199, returned 70 active devices in 3 pages. Device counts and the gateway serial were verified from API response metadata; the 7-device per-device table is from a verified page-1 sample. Pages 2 and 3 were not retrieved in this run; a follow-up pull is required for the complete fleet view. WP4→WP5 OTAP framing: the update is pushed remotely by the gateway; offline devices stay on WP4 and are not harmed. Cross-device sync: upgrade picks and status edits sync to aroya-report-sync.ciansul.workers.dev/199 (shared store) with a local-cache fallback.