> For the complete documentation index, see [llms.txt](https://docs.mclimate.eu/mclimate-enterprise/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mclimate.eu/mclimate-enterprise/configuration-and-management/buildings/building-dashboard/connectivity-center.md). # Connectivity center The Connectivity Center is a single dashboard inside the building view that tells you, in plain numbers, how well the LoRaWAN network in this building is performing right now. It rolls up every device into one health badge, shows you which gateways and which devices are dragging the score down, and lets you click into any device to see the history behind its connectivity. \ You do not need to know anything about LoRaWAN to read it. The health badge tells you the headline; the rest of the page is there when you want detail. {% hint style="info" %} The chart itself is for a time period not the current moment, for example (day, week, etc.) {% endhint %} ## Where to find it Open a building from the Buildings list. Below the building header and the action buttons (Billing, Users, Schedule profiles, Firmware Management, Rules, Hydraulic Balancing) you will see a collapsible section called "Connectivity center". Click the title to expand or collapse it. \ Below it you will also find the "Mold detection summary" and "Floor plans" sections. ## The Building Connectivity Health header At the top of the Connectivity Center is a wide card that summarizes the whole building. From left to right: * **Building connectivity health:** a colored dot plus a label - "All good", "Degraded", or "Critical". This is the headline. If it is green, the network is healthy. If it is orange or red, scroll down. * **Devices online:** how many of the devices the system thinks are reachable, out of the total. The percentage underneath is the same number expressed as a share. * **Degraded:** how many devices are technically online but showing one of three problems - a weak radio signal, lossy uplinks (frames are being dropped), or a stale "last active" timestamp (the device has gone quiet for more than 24 hours even though the online flag is still true). * **Avg signal:** the average RSSI - the radio signal strength - across every device in the building, measured in dBm. Less negative means stronger. As a rough guide, -70 dBm is excellent, -90 dBm is normal, -110 dBm is poor. * **Avg packet loss:** the average share of uplink frames that have not arrived at the gateway. Below 1% is the LoRaWAN quality-of-service target; above 5% counts a device as "lossy". \ Underneath, if any gateways are dragging the building down, you will see "Top problem gateways" - up to three chips, each showing the gateway name, how many of its devices are offline, and its average RSSI. These are the first places to investigate.

Connectivity Center overview with health header, chart, and the Summary tab.

{% hint style="info" %} How the three health states are decided\ **All good:** nothing is off and only a tiny fraction of devices (less than 3%, and fewer than 3 in absolute terms) is degraded.\ **Degraded:** 3 or more devices are offline, OR 3+ devices are degraded-but-online, OR the share of either exceeds 3% of the fleet.\ **Critical:** at least 35% of the fleet is offline, OR at least 35% is degraded-but-online. These thresholds are deliberately tolerant. A single dead device in a 200-device hotel should not paint the whole building red. {% endhint %} ## The chart On the left below the health header is a line chart of how many devices were online over the selected period. The blue line is the current period; an optional grey dashed line shows the comparison period for the same metric. Above the chart are two date pickers and a percent-difference badge: * **Today:** the active period. Click it to pick another preset (Today, Yesterday, Last 7 days, Last 30/90 days, Last month, Last year) or a custom range. * **No comparison:** the comparison period. Choose "Previous period", "Previous year", or "No comparison". The grey dashed line on the chart shows whatever you pick. * **Percent badge:** a green up-arrow or red down-arrow with a percentage, showing how the average for the current period compares to the comparison period. \ The small icon at the top-right of the chart toggles between "split" and "full-width" layouts. In full-width mode the chart takes the whole row and the events table drops below it. ## The events table To the right of the chart is a table with three tabs. ### Logs tab The raw connect/disconnect events for the selected period. Each row is a single event: which device, what happened ("connected" or "disconnected"), and when. Useful when you want to see exactly when a disconnect happened and look for patterns across the fleet. ### Summary tab (shown above) One row per device that had at least one disconnect in the selected period. Columns are: * **Device:** name and icon, with a small horizontal timeline underneath that visualizes connected (green) and disconnected (red) periods over the active range. Clicking a row opens the Device deep-dive. * **Offline Time:** how long this device was disconnected in total during the period, in days/hours/minutes/seconds. * **Disconnect Events:** how many times the device went from connected to disconnected. A high number with short individual outages usually points to a marginal radio link, not a broken device. * **Online:** the device’s current state (Online or Offline). If you have just opened the page it may take a few seconds for this to settle while the per-device telemetry catches up. * **Last SF:** the spreading factor used on the most recent uplink. Higher is slower and more robust; lower is faster and more efficient. See the technical appendix for what SF actually means. * **Last FrameCount:** the device’s uplink counter at the time of the most recent uplink. Useful as a sanity check that the device is incrementing as expected. ### By gateway tab A roll-up by gateway, sorted with the worst gateways first. For each gateway you see: * **Gateway:** the gateway name. A small subline shows the worst device on that gateway (the one with the lowest RSSI) and its current signal, so you can immediately see whether the problem is the gateway itself or one specific marginal device. * **Devices:** how many of the gateway’s devices are currently online out of its total, with a color-coded bar (green ≥ 95%, orange ≥ 80%, red below 80%). * **Avg Signal:** the gateway’s average RSSI across all devices that talk to it. Colored neutral above -95 dBm, orange between -95 and -110, red below -110. \ Connectivity Center - documentation. * **Avg Packet Loss** (loss): average uplink packet loss across the gateway’s devices. Neutral below 5%, orange between 5 and 10%, red above 10%.

Events table on the By gateway tab. Gateways are sorted worst first, with the worst device per gateway shown in the subline.

### Device deep-dive Clicking any row in the Summary tab opens a modal that drills into that single device. It is the answer to the question "OK - what was the signal doing in the run-up to this disconnect?". #### Historical range At the top of the modal are three buttons: * **Selected period:** the same range the rest of the Connectivity Center is showing. * **Last 24h:** reframe the device-level view to the last 24 hours regardless of what the outer page is showing. Useful for "what happened in the run-up to right now?". * **Last 7 days:** broader context. The signal-strength chart and the recent-events list both rescope to whichever pill is active. #### Seven stat tiles * **Online:** the freshest state the system can derive - rom the latest connectivity event when one is available, falling back to the stored online flag otherwise. * **RSSI:** the radio signal strength on the most recent uplink, in dBm. * **Link margin:** how many dB of headroom the device has above the minimum signal its current SF can decode. Green means comfortable headroom (≥20 dB), neutral means usable but limited (8–20 dB), red means edge-of-coverage (<8 dB). * **Last SF:** the spreading factor on the most recent uplink. ADR will adjust this automatically. * **Packet loss:** the uplink packet-loss percentage from the latest telemetry. * **Gateway:** which gateway is currently relaying this device’s uplinks. * **Last active:** a human-readable "X hours ago" plus an absolute timestamp. Computed from whichever source is freshest — the latest log row or the stored last-active flag. #### Signal strength over time A line chart of every RSSI sample for the device in the active range. Two things are layered on top: * **Red dashed vertical lines:** every disconnect event in the range. When there are 5 or fewer the lines get an "Offline" label; otherwise they’re unlabeled to avoid stacking labels on top of each other. * **Orange dashed horizontal line (when shown):** the "edge" of coverage at the device’s dominant spreading factor in this range — the level below which the link starts dropping frames. See the technical appendix for the formula. Hovering any point shows the exact RSSI, SF, gateway, frame count, and timestamp for that uplink. Useful for matching specific dips to specific gateways or times.

Device deep-dive for an HT LoRaWAN sensor. The red annotation marks a disconnect event; the tooltip shows the per-uplink RSSI, SF, gateway and frame count at the hovered point.

#### Recent events list Up to the 25 most recent connect/disconnect events for this device in the active range, newest first. Lets you read the device’s state transitions like a log even when the chart annotations get dense. \ A "Open full device view →" link at the bottom of the modal takes you to the device’s standalone dashboard for deeper inspection. ### What to do when health is "Degraded" or "Critical" A short playbook for the most common patterns. #### The whole building just went Critical * Check the "Top problem gateways" chips. If one gateway has many offline devices on it, the gateway itself is probably down — verify the gateway is powered and on the network. * If multiple gateways across the building are degraded simultaneously, the cause is usually upstream — the LoRaWAN Network Server, internet, or building-level networking. * If the offline devices are spread evenly across gateways, look for an external event (planned outage, fire alarm test, power event in the building). #### Health is Degraded but devices are mostly online * The "Degraded" tile splits the number into "weak signal · lossy · stale". Click into the Summary tab and sort by Offline Time to see which specific devices are misbehaving. * For weak-signal devices, open the device deep-dive and look at the signal chart. If the RSSI is hugging the orange "edge" line for its SF, the device is at the edge of coverage - moving it, the gateway, or the antenna will help. ADR will eventually push it to a higher SF but the device will use more battery. * For lossy devices with a healthy signal, check the gateway view - if the same gateway is also lossy, the gateway's backhaul is the suspect, not the device. #### A device keeps flapping (many disconnect events, short outages) * Open the device in the deep-dive and look at the signal-strength chart over Last 7 days. * Dips that line up with disconnect lines suggest a marginal link — the device is at the edge of what its current SF can handle and ADR has not yet stabilized it. * Disconnects with steady RSSI usually point to interference or contention rather than coverage. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.mclimate.eu/mclimate-enterprise/configuration-and-management/buildings/building-dashboard/connectivity-center.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.