AROYA · Device Fleet Health Audit

JARS Cannabis — Chino Group Ventures LLC · Facility 4666

Generated 2026-06-10 21:55 UTC · 116 physical devices (218 raw rows incl. folded sensors) · 30-day window, sampled at 4 points
91
Healthy
8
Healthy — minor watch
0
At risk — bring up first
2
Likely to miss the push
12
Offline / dark
3
Not assessable
Healthy online & reportingMinor watch one metric soft At risk troubleshootFailing intervene / retire Offline / dark no data flowingNot assessable gateways
Mesh backbone: 101 units are online and communicating, so the gateway can push a WP5 version update to them at a scheduled time. This fleet is current-generation hardware and is already running WP5 across the board — the question is version currency, not a WP4→WP5 migration. Devices offline at a push simply stay on the version they run (unchanged — not harmed). Verify the sinks/gateways in the AROYA app first.

Firmware versions on site (all WP5 generation)

Every radio on site is WP5-generation hardware. Versions below are the per-device application firmware from portal_api; sinks report the WP mesh stack itself. Version drift on one mesh is worth sweeping: nodes are split across versions — 70 node(s) run an older version than the newest on site (1.4.1.0). Whether to schedule a sweep is the operator's call; the readiness buckets below say who would receive it.
ClassFW versionUnits
Climate One (PoE climate station + EE894)1.2.2.06
Gateway (mesh → cloud)3
Substrate node (radio + TEROS-12)1.3.0.070
Substrate node (radio + TEROS-12)1.4.1.027
Substrate node (radio + TEROS-12)1
Repeater (range extender)1.3.0.06
Sink (mesh root)5.2.0.533
Gateways carry ggVersion 2 (no per-device app firmware exposed). Folded sensors (TEROS One / EE894) run on their host radio's firmware. Hybrid-capable gateways (H22x) — if present on an account — can run WP4+WP5 simultaneously when on a WP5 firmware version; confirm gateway capability with AROYA support.

Fleet composition & sensor coverage

Your fleet lists 6 radios as “repeaters”, but the serial prefix tells the real story: 6 are range-extenders only (H110…) and 0 are climate stations (H111…) — a repeater-class radio with an Atmos-14 attached. Of the 0 climate stations, 6 are fully healthy, 0 have the Atmos-14 offline while the radio is up (reseat/replace the sensor — the radio still takes firmware), and 0 are entirely dark. Across the 98 substrate nodes, 85 have a reporting probe, 1 are alive but the probe isn’t reporting (reseat the probe), 10 are dark with the node, and 2 have no probe paired.

Methodology — dual-stack pull (aroya_sdk v0.1.0 ⇄ traditional pipeline)

This audit was pulled twice, side by side: the canonical skill pipeline (paged public_api + resumable_pull, workers=4) as system of record, and the new aroya_sdk Python SDK as the validation stack. With the OpenCLI browser bridge down, the SPA leg ran through the SDK's HTTP SPA layer using the app JWT — no browser required. Every cross-check passed.
CheckTraditionalaroya_sdkResult
Device inventory (unique ids)2182180 diffs, 0 field mismatches
Room roster2323identical
Telemetry spot-check (3 devices, same 24h window)1440/0/219 pts1440/0/219 ptspayload MD5 identical 3/3
Silent-device recheck (34 devices, clean 2-day window)ran via SDK2 false-deads recovered (both TEROS One probes)
Live online state (SPA /devices/, via SDK spa layer)30-day telemetry buckets124 live rows12/12 offline units confirmed offline
Firmware versions (portal_api, 242 rows)per-device version/pvVer/hwVer merged into every unit row112/116 units versioned (gateways report ggVersion 2)
Probe→radio linkageserial-derived (sensor serial encodes host radio serial), SPA-independent102/102 linked (100%)

TEROS One & Climate One upgrade planner

This fleet is already fully upgraded. All 96 substrate probes are TEROS One (ter15) and all 6 climate stations are Climate One (EE894) — there are no TEROS-12 or Atmos-14 trade-in candidates at this facility. The planner below stays for completeness; expect zero eligible rows.
Tick the “Upgrade?” box on any sensor — including working ones. TEROS-12 → TEROS One (choose Dual or Single per sensor); Atmos-14 → Climate One. The quote totals exactly from your picks. Pricing is fixed (below).
TEROS-12 sensors (→ TEROS One)
Atmos-14 sensors (→ Climate One)
0
Ticked for upgrade quote
$0
Total trade-in quote
TEROS One Dual $458 $608 MSRP · save $150
TEROS One Single $319 $419 MSRP · save $100
Climate One $479 $629 MSRP · save $150
$0
TEROS One: 0 single + 0 dual — save $0
$0
Climate One: 0 × $479 — save $0
$0
Total saving vs MSRP ($0) — time-limited

How WP5 version updates work & how to prepare

This fleet is current-generation hardware (H343 nodes, H340 repeaters, H421 Climate Ones) and already runs WP5 everywhere — there is no WP4→WP5 migration to plan. What matters is which WP5 version each device runs and whether a version update should be pushed. A version update goes over the air through the gateway to every device that is online and communicating at the scheduled time (go/no-go: online, battery ≥ 30%, signal ≥ 50%). Devices offline at that moment simply stay on the version they already runnot harmed, just not updated. Updates are normally run remotely; keeping the fleet online is the site's responsibility.

  1. Bring as many devices online as possible before any scheduled push. Work the "Offline" and "At risk / Likely to miss" lists — replace batteries and shore up signal so each meets online + battery ≥ 30% + signal ≥ 50%. Every device up at push time receives the new version; every device down keeps its current one.
  2. Decide what to retire instead of recovering. For dead units you won't bring back, plan a retirement/replacement rather than spending effort reviving them.
  3. Confirm the gateways/sinks are online in the AROYA app. The gateway carries the push; verify the backbone before the scheduled update. The gateways here report ggVersion 2; sinks run WP stack 5.2.0.53.
  4. Keep the mixed-version window short. Stragglers can be updated later once they're back online — but long-running mixed firmware versions on one mesh can cause connectivity quirks, so sweep the fleet to one version where practical.

By room

Bay 6
21 0 0 0 0 1
Bay 1
99 0 0 0 0 0
Bay 10
11 0 0 0 0 0
Bay 11
10 0 0 0 0 1
Bay 12
11 0 0 0 0 0
Bay 2
87 1 0 0 0 0
Bay 3
99 0 0 0 0 0
Bay 4
88 0 0 0 0 0
Bay 5
11 0 0 0 0 0
Bay 8
11 0 0 0 0 0
NURSERY A
10 0 0 0 1 0
ZZZ
5942 6 0 2 9 0
(infrastructure)
1511 1 0 0 2 1

By device class

Substrate node (radio + TEROS-12)
9878 8 0 2 10 0
Repeater (range extender)
65 0 0 0 1 0
Gateway (mesh → cloud)
30 0 0 0 0 3
Sink (mesh root)
32 0 0 0 1 0

Every device — readiness, sensor, action & your status

Set “Your status” as you work the floor — revived items drop off the active list, and upgrade picks feed the planner above. Your changes save in this browser; click Export to send the snapshot back for the next pull.
Connecting…
0ticked for upgrade TEROS One $0Climate One $0 Total quote $0 Save $0 vs MSRP Resolved 0
Device (operator sees)ClassFW verOnlineReadiness RoomSensor BattRSSIGaps Last (h)Most-likely failure / action Upgrade?Your status
One row per physical device. A TEROS-12 / Atmos-14 is folded into the radio it plugs into (sensor.puck). Class by serial prefix (the API hides a climate station as a “repeater” when its Atmos-14 is offline): H31x/H32x/H34x = node, H111 = climate station, H110 = repeater, H21x = gateway, SINK = sink. TEROS One upgrade applies to TEROS-12 substrate sensors; the planner totals trade-in cost from what you mark. Your status edits and upgrade picks sync across every device that opens this link (shared store), with a local cache when offline; Export gives a JSON snapshot the next data pull reconciles against. Readiness reflects the OTAP go/no-go — a device receives a WP5 version update only if it's online with battery ≥ 30% and signal ≥ 50% at the scheduled push; otherwise it stays on the version it already runs (unharmed). This fleet is all WP5-generation hardware; the audit is about version currency, not a WP4→WP5 migration. Firmware versions come from portal_api (`version` per device); live online state from the SPA /devices/ endpoint. Telemetry: AROYA public API, 30-day window sampled at four 2-day windows; silent devices re-pulled on a clean recent window. Flags (telemetry proxy for the go/no-go): battery crit<3.0/warn<3.2 V; RSSI crit<-95/warn<-85 dBm; link crit<40/warn<60; travel crit>60/warn>30 s; last-seen >48 h = offline.