Device & Network Health Audit

Cannapproach — CCMS

Wirepas mesh connectivity audit · facility 4549 · isolating the room-level signal drops reported during the gateway changeover
FacilityCannapproach – CCMS (4549) Rooms monitored8 (Fiacre FR1–FR7 + Joe's Demo) Devices23 sensors/climate · 6 gateways Generated2026-06-23 03:39 UTC Prepared forMichael Nguyen WindowLive snapshot + ~24h history
Verdict Room signal map Signal trends Gateways & changeover Mesh routing Root cause What to do Method & data quality

Verdict

Mesh backbone
Healthy
4/6 gateways online · batteries 93–100%
Rooms down
FR6
both radios offline since 06-23 01:33
Rooms marginal
FR7
−86 dBm · link 54% · holding
Rooms strong
FR1–FR5 · Joe
−41 to −61 dBm · link 99–100%
FINDINGThe mesh isn't broken — the problem is two rooms that never re-converged after the gateway swap.
27 of 29 devices are online and reporting, batteries are full (93–100%), and five of eight rooms sit at a strong −41 to −61 dBm with 99–100% link quality. This rules out a facility-wide RF or backbone failure.
The connectivity complaints are localized to FR6 (down) and FR7 (marginal) — the two rooms whose gateway was changed over on 2026-06-22. When the two old gateways were unplugged (~14:40) and the two new ones activated, the FR6 node never cleanly re-attached to a sink. It is currently split between the old gateway (H2110001287) and the new one (H2200001038), its link quality fell to 0, and it dropped off the mesh at 01:33 on 06-23.
This matches exactly what you described: "the two rooms closest to the new gateway have the weakest signal." That is counter-intuitive but expected for a Wirepas mesh mid-changeover — and there are two compounding physical reasons covered below.

Room-by-room signal map

Signal bars are AROYA's 0–8 radio indicator (8 = strongest). Link% is the worst node in the room. Gateway = the sink each room's nodes are anchored to right now.

RoomOnlineSignal (0–8)LinkAnchored gatewayStatus
Fiacre FR13/3881%H2200001039HEALTHY
Fiacre FR23/3577%H2200001039HEALTHY
Fiacre FR33/3560%H2200001039HEALTHY
Fiacre FR43/3563%H2200001039HEALTHY
Fiacre FR53/3468%H2110001287HEALTHY
Fiacre FR60/230%H2110001287DOWN
Fiacre FR72/2154%H2200001038MARGINAL
Joe's Demo4/46100%H2110001266HEALTHY
Unassigned4/6

Signal trends — healthy vs. marginal vs. failed

Three representative rooms over the last ~24 hours. FR1 is a healthy reference, FR7 is the marginal room, FR6 is the room that went dark.

Radio signal strength (dBm — higher is better)

Reference bands: ≥ −70 strong · −70 to −80 OK · −80 to −88 marginal · below −88 approaching the 802.15.4 noise floor. FR6 decays to ≈ −91 dBm then goes silent; FR7 hovers at −86 to −90; FR1 sits at a comfortable −41 to −61.

Link quality (% — higher is better)

Mesh travel time (route-cost proxy — lower is better)

FR6's travel time spikes toward 64 (vs ≈0.02 for healthy rooms) — the signature of a node thrashing across a long, unstable route before it dropped.

Gateways & the 06-22 changeover

Six gateways are provisioned. Four are online; the two that went offline yesterday afternoon are the old units that were swapped out when you activated the two new gateways.

GatewayStateIPFWLast seenRole
H2110001266ONLINE192.168.100.89WP28 min agoExisting — serves Joe's Demo
H2110001287ONLINE192.168.99.232WP28 min agoExisting — serves FR5 & old FR6 route
H2200001038ONLINEWP29 min agoNEW — serves FR7 + one radio of FR6
H2200001039ONLINE192.168.50.16WP28 min agoNEW — serves FR1–FR4 (replaced old GW on 192.168.50.x)
H2100005595OFFLINE192.168.50.175WP212.9 h agoOLD — went offline 06-22 14:43 during changeover
H2110001269OFFLINE192.168.100.186WP213.0 h agoOLD — went offline 06-22 14:40 during changeover
NOTEThe blank IP on H2200001038 is an unpopulated inventory field, not a fault.
A missing ipAddress in the device record does not mean the gateway is off the internet — backhaul can be cellular or another path — and it has nothing to do with the Wirepas mesh, which is a separate 2.4 GHz radio network that is not IP-based. It is not treated as a cause in this audit.

Mesh routing — who's anchored where

Each node's current sink (anchored gateway) vs. the gateway it is actually hopping toward (next-hop sink). A mismatch = the node is caught between two gateways.

RoomDeviceModelStateNext-hop sinkAnchored gateway
Fiacre FR1H3440013462nodeonlineH4210006646H2200001039 SPLIT ROUTE
Fiacre FR1H4210006646h421onlineH2200001039H2200001039
Fiacre FR2H3440015299nodeonlineH4210005930H2200001039 SPLIT ROUTE
Fiacre FR2H4210005930h421onlineH4210005159H2200001039 SPLIT ROUTE
Fiacre FR3H3440015383nodeonlineH4210005159H2200001039 SPLIT ROUTE
Fiacre FR3H4210005159h421onlineH2200001039H2200001039
Fiacre FR4H3440014929nodeonlineH4210004507H2200001039 SPLIT ROUTE
Fiacre FR4H4210004507h421onlineH2200001039H2200001039
Fiacre FR5H3440014928nodeonlineH4210005146H2110001287 SPLIT ROUTE
Fiacre FR5H4210005146h421onlineH2110001287H2110001287
Fiacre FR6H3440014948nodeOFFLINEH2110001287H2110001287
Fiacre FR7H3440014947nodeonlineH2200001038H2200001038
Joe's DemoH3310009922nodeonlineH2110001266H2110001266
Joe's DemoH5200001002h520onlineH2110001266H2110001266
Joe's DemoH8200001003nodeonlineH2110001266H2110001266

FR6's two radios disagree — one points at the old gateway H2110001287, the other at the new H2200001038. That split is the stuck route.

Root cause

CAUSE 1Stale Wirepas routes didn't re-converge after the gateway changeover.
Wirepas mesh nodes are deliberately conservative about switching parents — they hold their existing route until it degrades enough to force a re-cost. When the two old gateways were unplugged and two new ones came up at the same time, FR6 lost its parent mid-stride and is now oscillating between the old sink (H2110001287) and the new one (H2200001038) instead of committing to the strongest one. It never settled, link fell to 0, and it dropped. FR7 made the jump to the new gateway but is sitting at the edge of its range.
CAUSE 2The nearest mesh parent may be out of child slots.
Every Wirepas router (a gateway sink or a repeater) can carry only a finite number of child nodes. If the closest parent already has its slots filled by the devices that joined first, a late-joining node like FR6 gets bumped to a weaker/longer route — or can't hold a slot at all and bounces. Right now the near new gateway's sink (H2200001038) is already carrying both of FR7's radios plus one FR6 radio, while FR6's other radio is parked back on the older gateway H2110001287. That split is exactly what slot contention next to a freshly-added gateway looks like. Treat as a hypothesis to confirm with Wirepas mesh diagnostics on-site.
CAUSE 3 · possibleAntenna geometry could be working against the room directly under the gateway.
A whip/dipole antenna radiates in a doughnut pattern with a dead zone straight along its axis. If the gateway antenna points straight down, the room directly beneath sits in that null — so "right on top of FR6" can actually be poor geometry. Worth checking, but secondary to the route reset and slot-capacity items above — verify antenna orientation on the walkthrough.

What to do — prioritized

PriorityActionWhy / expected result
P0Reset the FR6 node (power-cycle / pull and re-seat). You already flagged this — it's the right call.Forces it to drop the stale hop path and re-attach to the strongest current sink. Expect FR6 back online within a few minutes of re-join.
P0If a reset doesn't hold, test for mesh slot contention — free a child slot near the new gateway (briefly power down a non-critical neighbor, or point FR6 at a less-loaded parent) and see if FR6 joins cleanly.Confirms or clears the slot-capacity theory. If FR6 holds once a slot frees, capacity is the limit and a dedicated repeater for FR6/FR7 is the fix.
P1Re-aim the gateway antenna so FR6/FR7 are in the radiation lobe, not under the tip — mount the antenna vertical with the gateway offset from directly-overhead, or angle it toward the rooms.Moves the dead rooms out of the antenna null. Same guidance applies to the Climate One and Teros antennas you asked about.
P1Place the incoming repeaters in the FR5–FR6–FR7 weak cluster, mid-span between the new gateway and the dead rooms — not next to the already-strong FR1–FR4.Adds a healthy hop where the mesh is thin. Repeaters near strong rooms add nothing.
P2Confirm the two offline gateways are intentionally retired and mark them retired in AROYA if so.Stops nodes from costing routes through stale sinks during re-convergence.
P2Hold off on raising reporting intervals until the mesh stabilizes.Faster reporting in a weak/thrashing room increases congestion and makes drops worse. Tune cadence after FR6/FR7 are solid.
P3Re-audit in 24–48 h after the reset (and any mesh rebalance).Confirm FR6 is back online and FR7's dBm improves off the new gateway.

Method & data quality

ItemDetail
Live device snapshotAROYA SPA /devices/?facility=4549 — online state, signal bars, link quality, next-hop, anchored gateway, battery, last-communication, firmware. Pulled 2026-06-23 03:39 UTC.
Signal historyAROYA /public_api/devices/<id>/chart/ in 2-day chunks — series: signal (dBm), link_quality (%), travel_time (route cost), radio_power, battery_v. The chart endpoint retains roughly the last 24–36 h at fine cadence, which covers the changeover window.
Rooms chartedFR1 (healthy reference), FR6 (failed), FR7 (marginal). Remaining rooms summarized from the live snapshot.
Climate One (h421)Reports a consistent low signal-bar reading across all rooms and does not expose the same radio chart series; it is mains/PoE-powered and is reporting on schedule, so it is treated as informational, not a fault.
Not directly measuredWirepas child-slot capacity and physical antenna orientation were inferred from the routing table and your on-site notes — confirm with mesh diagnostics on a walkthrough. The blank gateway IP field is not used as evidence (it does not indicate internet or mesh state).

Connectivity terms used as AROYA does: a device that drops off the mesh has gone silent / needs to re-attach to a sink; it is not damaged and rejoins on reset. No firmware change is involved in this issue.