Why every self-storage facility needs a Bluetooth fallback

The problem: access control without reliable internet

Most modern access control systems communicate via the cloud. That’s convenient — all access rights are centrally managed, logs are immediately available, and remote management works from anywhere. But there’s a catch: if the internet connection fails, many systems fail too.

In self-storage, this scenario occurs more often than one might think. Thick concrete walls, underground car parks, industrial estates on the edge of town — all situations where mobile coverage is unreliable. A gateway that relies solely on LTE can fail precisely when a tenant urgently needs access.

How Bluetooth fallback works

sedisto uses a hybrid architecture. The gateway communicates primarily via LTE or fixed network. In parallel, it maintains a local Bluetooth cache with all current access rights.

When a tenant opens the door via the sedisto app, the request is first sent to the cloud — for logging and plausibility check. If the cloud is unreachable, the app automatically switches to Bluetooth mode: the gateway checks the locally cached rights and opens the door directly.

The transition is seamless. The tenant sees no error message, no waiting time, no difference. Only the log entry later shows that the operation ran offline.

What is cached locally?

The local cache in the gateway stores:

• All active access rights (tenant ID, unit, valid from/to)
• Blacklisted tokens (blocked tenants, revoked access)
• Pending events that still need to be synchronised

The synchronisation between cloud and local cache runs continuously — not in hourly batches, but event-driven. Every booking, every cancellation, every rights change is pushed to the gateway within seconds. The cache is therefore almost always up to date.

The case for Bluetooth: numbers from practice

At AlpinBox Innsbruck, 180 garages are secured via sedisto. The facility is located in a valley with limited mobile coverage. In the first 90 days after installation, there were 23 LTE interruptions — each lasting between 3 and 47 minutes.

In all 23 cases, the Bluetooth fallback jumped in without interruption. Not a single tenant was locked out. The log shows that 97 door openings took place via the local fallback during these periods.

Without the fallback, that would have been 97 frustrated calls to the operator.

What operators should pay attention to

Not all Bluetooth fallbacks are created equal. There are several key differences:

Cache freshness: How quickly are new bookings and cancellations applied to the local cache? With sedisto, this happens event-driven within seconds. Some competitors only synchronise hourly — which means an emergency block may not take effect locally for up to 59 minutes.

Cache depth: How far back does the local cache go? Does it also contain future bookings, or only currently active rights? For facilities where tenants sometimes book shortly in advance, the cache must also cover the near future.

Fallback transparency: Does the app communicate to the tenant that it’s operating in offline mode? Or does it stay silent? sedisto opts for a neutral UX — no error message, no notification. The access simply works.

Conclusion

Bluetooth fallback is not a luxury feature for special cases. For any facility with uncertain connectivity — and that’s most of them — it’s operational insurance.

The question is not whether you need a fallback, but how good it is. How fresh is the cache, how quickly does it synchronise, how transparently does it handle the transition? These are the criteria that matter in practice.