Sites that drop offline: how collection should be designed

Shops, parks and sites often lack a stable network. Design collection as local cache, queued catch-up and idempotent reconcile. Do not pretend devices are always online.

Many plans assume “4G is always on.” The floor is: no signal at basement gates, metal shielding by the line, a cutover during construction, a router reboot at night. If collection only writes in the cloud, those hours of temperature, access and scans vanish. Tickets, attendance and stock then become fiction.

Floor devices and collectors need a weak-network design
01 CollectGates, sensors and PDAs first mint a sequenced event locally, whether the net is up or not.
02 Local queueOffline writes to an edge cache. The queue has capacity and a backlog alert; when full, keep critical events.
03 Catch-upOn restore, report in order. Retry on fail. Do not pop “uploaded” on the floor and pretend done.
04 Cloud ackThe server de-dupes by device + sequence. Local delete only after ack write-back.

The figure is the queue DaXi Technology uses on weak-network sites—not “connected to the cloud, done.” The stall is always step 2: is it in the queue, can it catch up, and will a retry double it.

If the protocol cannot be negotiated, offline fails too. A device that can only send to a vendor cloud, with no local cache API, stops collecting when the net dies. First ask whether the protocol allows edge store: If the device protocol is closed, can we still integrate. If a box locks data in a vendor app, you cannot change catch-up. Compare When a closed IoT box will not release your data.

Name what must not be lost offline, then choose how long to cache

Not every point needs the same backup. Access in/out, safety interlocks, energy peaks and missed-check photos usually must stay; decorative online-headcount can drop. Write a must-keep list, then choose hours, days or a count cap. When full: stop collect, overwrite oldest, or keep alerts only. A queue with no policy silently overflows over a holiday outage.

Catch-up must also de-dupe. The same heat rise twice can open two maintenance tickets; one miss and the board still looks fine. Events need stable IDs, an idempotent server, and merge rules on the ticket side. Noisy alerts often start here: The system never alerts, or alerts too much. How to diagnose. Devices online with people still staring is often an outage gap nobody filled: Devices are online. Why the floor still stares at screens.

The edge box itself needs disk, clock and power watched. A wrong clock scrambles catch-up order; attendance and trails will not match the shift. A USB-powered gateway dies when a welder starts. When 4G is capped, throttle catch-up: alerts and tickets first, curves later. Ops must see backlog count, not only “device offline” in the cloud. On reconcile, an outage window must show which minutes are missing. “The network was bad” will not satisfy finance or safety.

Live acceptance is not a lab green light. Do at least: unplug 30 minutes, power-cycle, catch-up across midnight, and a deliberate duplicate. Watch backlog, ack write-back, and whether the business side matches. DaXi Technology designs collection for the site network and will not write “always online” into a contract. To assess gates and sensors you have, go to Hardware-Software Integration and say which stretch drops offline.

A full queue needs a written policy. Catch-up merges by event

A full queue needs a written policy: stop collect, overwrite oldest, or keep alerts only. Holiday outages silently overflow; you notice three missing days of temperature on the first workday. The ticket side must merge by event ID—two tickets from one heat rise and the crew mutes notify.

Put the offline-collection call on your site gateway and queue

Which basement, line or park stretch drops, and which events must not be lost. Send the as-is; we will design for catch-up.

Contact Us

Email
service@wehoope.com
Phone
+86 139-2520-6166
Address
W903, Shenzhen-Hong Kong Industry-University-Research Base, No. 201 Gaoxin South 7th Road, High-tech Zone Community, Yuehai Subdistrict, Nanshan District, Shenzhen