Bikeep circuit boards on the production line, with the Bikeep logo printed on a green PCB
News

Why a scaling bike parking network needs IoT, not Bluetooth

One procurement question that looks like a hardware detail decides what the next ten years cost to run: how does the lock talk to the world?

Most of this market answers with Bluetooth Low Energy. The lock talks to a phone, and only to a phone. For one bike barn behind one office, that is a defensible answer. For a network — twelve sites now, sixty in five years, three kinds of structure, four stakeholder groups — it is the decision operators come to regret. They usually regret it in year three, by which point changing the answer means changing the hardware.

What a Bluetooth-only system quietly commits you to

In a BLE design the rider's phone is the network. Nothing about the site is known unless somebody is standing next to it with the app open, Bluetooth on, the right permissions granted and a working app version installed.

Follow that through to its operational consequences and the list is longer than it first looks:

  • No live state. Occupancy, faults and alarms exist only in the device until a phone happens to collect them. There is no availability to publish, no dashboard, no evidence base.
  • No remote action. A resident who cannot get their bike out at 19:00 is a van the next morning, not a click.
  • A firmware update is a site visit. Multiply that by every site in the network, every time.
  • One access method. The rider without a smartphone, without data or without the app is not served — which is a problem for anyone specifying public infrastructure.
  • A theft is discovered by its victim. The device has no way to tell anyone anything.

None of this is a flaw in Bluetooth. Bluetooth is a short-range radio doing exactly what it was designed to do. The mistake is asking a local radio to be the management layer for a fleet.

What changes when the device has its own connection

An IoT station carries its own industrial cellular gateway with dual-SIM failover between mobile operators. It does not wait for a rider to arrive before it has an opinion about its own health. It reports heartbeat, signal quality, firmware version, supply voltage, and lock and door state continuously, and it accepts commands from the other direction — unlock, lock, reset, power-cycle, reconfigure, update.

bikeep-locker-app-access.webp

Two design details make that practical rather than fragile. Inside the site, the Main Controller talks to each door's Smart Controller over a wired CAN bus rather than radio, so actuation is immediate and deterministic rather than dependent on a handshake succeeding. And the credentials live locally: the Main Controller caches up to 50,000 access codes on the device itself, so if the cellular link drops the site keeps admitting cardholders and queues its sessions until connectivity returns.

Connectivity is what makes the network manageable. It is not what makes the door open.

Ten thousand interventions that did not need a van

This is the argument that survives contact with a budget, and it is measurable.

Across the Bikeep network in the twelve months to 1 August 2026, operators and support staff performed 4,104 remote unlocks — each one a rider released from a desk — and issued 5,970 remote power-cycle and modem-reboot commands to recover devices without anyone attending site. Just over 10,000 interventions in a year, on a network spanning more than 40 countries.

In a BLE architecture, most of those are either a truck roll or an unresolved complaint. That single line is usually the difference between a distributed network of facilities being affordable to operate and being quietly abandoned.

Telemetry also changes the visits that do still happen. Mechanical damage, vandalism and cable faults will always need a technician — but the technician arrives with the right part, at the right dock, for a fault detected when it occurred rather than when the fourth user complained. On the Bikeep Console, a degraded site is visible before anyone reports it.

A device that can raise its own alarm

A connected dock detects and forwards its own security events in real time: enclosure opened, cable cut, lock physically forced, tamper. It also reports its own technical distress — a controller not responding, a camera offline, UPS power lost, supply voltage low.

Each goes to the console and to nominated recipients while it is happening, alongside an audible alarm on site. Defined conditions trigger automated responses with no human in the loop at all, around the clock — overstay notifications to owners, device recovery routines, escalation to the operator.

rox-bike-locker-app-access.webp

A Bluetooth lock has no channel on which to say any of this. The security model of a BLE-only installation rests on the lock being hard to break; a connected one rests on the lock being hard to break and on somebody knowing within seconds that it is being tried.

Adoption is an architecture decision, not a marketing one

The failure mode of underused bike parking is rarely a shortage of spaces. It is the cost of trying it once.

Because the station is connected, four independent access methods run off one account system — app, contactless 13.56 MHz RFID/NFC card, QR, and push-to-start — so a resident with no smartphone can be issued a card and park the morning they sign up. And because state is known centrally, live availability appears in the Bikeep app before anyone leaves the house. Neither is possible when the phone is the only channel to the device.

The behaviour that follows shows up in the numbers. The platform has recorded more than 1.5 million parking sessions from over 98,000 riders, and of 55,482 rider ratings, 97% were five stars. In Metro Vancouver, the TransLink deployment has held 99.6% uptime over 90 days, grew annual sessions 56% from 2024 to 2025, and starts 46% of its sessions between 5am and 9am, 83% of them on weekdays. That is a commute pattern, not a novelty curve — and it is the figure a transit planner should ask any vendor for.

Reliability is the precondition for all of it. A rider who finds a dead locker once on a wet Tuesday takes the car for months.

One platform, any manufacturer's hardware

Most vendors here sell a structure with a lock attached. Bikeep sells the access and management layer, and the hardware is an implementation of it — which is why the same console, app, card and data pipeline run across docks, smart bike parking, lockers, hangars, e-bike and scooter charging, and bike rooms, cages and shelters built by other manufacturers.

Bikeep is the only platform in this market that will onboard a third party's device over MQTT, the standard messaging protocol for IoT and industrial automation. A gate, counter, sensor, light or access reader from another supplier joins the same open API and the same operator view, without a bespoke integration project each time.

For a buyer the consequence is commercial rather than technical: the technology layer and the structure are genuinely separable. A city can standardise access, user experience and data across a whole network and still tender each structure competitively — and the supplier who wins on fabrication price does not force a new platform, retrained staff and a second app for cyclists. In Metro Vancouver, docks, smart lockers and bike rooms already run as one system on one console.

Why we build our own electronics and firmware

Bikeep is also the only company in this category that designs its own circuit boards and writes its own firmware rather than wrapping software around a bought-in lock module. That sounds like an engineering preference. It is really a control argument.

When the boards and the firmware are ours, "hold the lock three seconds longer", "support this city's card scheme", "add a fire-safety relay", "make this alarm less sensitive" are releases on our own roadmap — not a negotiation with a component supplier who has other customers and other priorities. Nearly 3,900 Bikeep boards report to the platform and are updated over the air from it, which is what makes a fix reach a whole fleet instead of a spreadsheet of sites awaiting a visit.

That is only possible at a certain scale. Firmware maintenance, security patching and a 24/7 monitoring stack are fixed costs — affordable spread across a network in more than 40 countries, unaffordable for a regional entrant. For a ten-year asset, a supplier's scale and market longevity are not vanity metrics. They are the reason the software will still be maintained in year eight.

Forty countries is the argument

Bikeep systems operate in more than 40 countries — New Zealand, Australia, Canada, the United States, Norway, Sweden, Denmark, the Netherlands, Germany, Estonia, Finland and the United Kingdom among them — through Nordic winters, coastal salt, dense transit interchanges and off-grid sites running on solar and battery with no trenching or electrical permit.

The reference list is the point. Bay Area Rapid Transit, TransLink in Metro Vancouver, Govia Thameslink Railway, the City of Oslo, Reykjavik, Tallinn, Stockholm, London, Auckland and Christchurch are not pilots. They are agencies and cities that ran a procurement, a privacy review and an IT review, then operated the result for years across transit and municipal networks.

What to ask before you specify a system

The useful question is not which radio the lock uses. It is what this network will need to do in year eight. If the answer includes more sites than you have today, more than one kind of structure, riders without smartphones, availability published as open data, security updates, a service level you have to evidence, or integration with a system that does not exist yet — then the radio is a detail and the management layer is the asset. Specify the layer.

A Bluetooth-only system optimises the first installation. An IoT platform optimises the operating life of the network. Those are different purchases, and only one of them scales.