Early access — limited places for founding customers
LoRaWAN, from sensor to decision. Without the integration nightmare.
HOVDB deploys your LoRaWAN network end to end, from the radio audit to long-term maintenance, with an AI supervision layer that already spots problems early and explains them in plain words.
Site
Simulated example, territory. Cross-section of a town hall with heating and water meter sensors, and a pressure sensor in a valve chamber on the water main under the street. Pressure sensor 0B94 sends a reading of 3.1 bar to gateway GW1 on the roof. Fleet: 47 of 48 devices online. One alert: device 3F2A, at SF12 through gateway GW2.
Insight
Device 3F2A drains its battery about 3× faster than similar devices since it moved to SF12.
Evidence: SF12 since 09:10, battery 3.08 V, RSSI −117 dBm. Drain estimated from airtime.
Recommendation: check the antenna on gateway GW2, or relocate the sensor.
Your network shouldn't start from scratch
Sensors, gateways and network servers often come from different vendors, and making them work together is left to you. Public networks can change owners, terms or end dates, and the customers running on them rarely have a say. Few organisations have a radio engineer on staff, so coverage is often estimated rather than measured. Surveys, configurations and integrations tend to be redone for each project, which makes deployments slow and costly. And once a network is live, failures often go unnoticed until the data stops.
One chain, from the first survey to the managed network
HOVDB runs every step of a LoRaWAN deployment, so you deal with one accountable partner instead of a supplier per layer.
The deployment chain: a sensor sends its data over LoRa radio to a gateway, which forwards it over IP to the network server, then to your application and your dashboard. Step 1, RF audit, covers the sensor and the gateway. Step 2, hardware sourcing, covers the sensor and the gateway. Step 3, network provisioning, runs from the gateway to the application. Step 4, AI supervision, runs from the network server to the dashboard. Step 5, managed service, covers the whole chain.
1RF audit
Coverage is measured on your site, so gateway count and placement rest on data, not guesses.
2Vendor-agnostic hardware sourcing
Sensors and gateways chosen for your use case, from whichever vendor fits it.
3Network provisioning
Gateways registered, devices joined and data delivered to your application, on the network server you choose.
4AI supervision
When something drifts, you get a plain-language explanation and a next step.
5Managed service
Maintenance, replacements and network changes, handled end to end after go-live.
Supervision that tells you what to do next
Two capabilities run today, two are being built. Early access customers help decide what ships next. Each capability is released when it holds up on a real network, not before.
- Predictive maintenanceIn production
- Batteries and failing sensors get replaced on a schedule you set, before readings stop arriving.
- Fleet anomaly detectionIn early access
- Flags the device behaving differently from its peers, with the reason it stands out, so nobody has to read every log.
- Gateway placement optimisation through propagation modellingIn development
- Built to show where gateways should go, and how many you need, before anyone climbs a roof.
- Natural-language assistant for network operatorsIn development
- Built so operators can ask in plain words, like “which sensors went silent this week?”, and get answers without writing queries.
Built for the networks you run
Typical sensors and what changes for each audience. Three of them match a scene in the console above.
Connected territories
- Typical sensors
- Water network pressure, public building heating and water meters
- What changes
Local authorities and syndicats mixtes run one network they own and control, across water, buildings and street assets.
Agritech
- Typical sensors
- Soil moisture, weather stations, tank levels
- What changes
Irrigation and refills follow measured field data, with coverage planned for the distances involved.
Industry 4.0
- Typical sensors
- Cold room temperature, tank levels, machine vibration
- What changes
Sites are monitored without pulling cable through a working plant.
Building and energy
- Typical sensors
- CO₂, occupancy, energy meters
- What changes
Facility teams act on measured use rather than estimates.
Environment and utilities
- Typical sensors
- Air quality, river and groundwater levels, utility meters
- What changes
Assets spread over wide areas keep reporting, with supervision (in development) built to flag failures early.
The photographs in this table illustrate each sector. They are not HOVDB sites or deployments.
Regional frequency plans
LoRaWAN runs in licence-exempt sub-GHz bands that differ by region.
- EU868863–870 MHz
- US915902–928 MHz
- AS923915–928 MHz
- AU915915–928 MHz
One founder, hands on every deployment
Bao HOFounder, HOVDB
I have spent four years taking IoT projects from proof of concept to field deployment. At CNRS in Grenoble I designed a self-powered LoRaWAN sensor that reads Linky meters, funded by Enedis and patented in 2022. At Optimiz Network I ran smart city and smart metering projects and won three public tenders; at Wi6labs I have led smart meter programmes for clients including SAUR and Socomec. HOVDB is where I do that work directly, for the organisations that need it.
I have run LoRaWAN platforms and deployments hands-on, and I research how people come to trust automated systems. That is why every dashboard and every AI output here is built to be understood: what it saw, why it matters, what to do.
Early access is limited because I onboard every customer personally.
Where the experience comes from
HOVDB is new and has no customers yet. These are the roles behind it, and the organisations whose projects they were — named as the employers and clients they were, not as HOVDB customers.
- 2020–2021CNRS, Grenoble
Research engineer
Designed a self-powered LoRaWAN sensor that reads Linky electricity meters over the TIC interface: electronics, embedded firmware and the full device-to-application chain. Funded by Enedis and patented in 2022.
- 2021–2022Optimiz Network, Saint-Étienne
IoT project manager
Ran smart city and smart metering projects from proof of concept to deployment, read the technical specifications behind public procurement, and wrote the technical responses that won three public tenders.
- 2023–presentWi6labs, Rennes
IoT project manager
The link between embedded and cloud teams and the end client on smart metering programmes for SAUR and Socomec. Wrote the specifications for sensors, gateways, firmware, LoRaWAN configuration and RF requirements.
Written references for all three roles are available on request.
Works with
HOVDB connects to the network server and tools you already run, or sets them up for you.
- Network server
- ChirpStackThe Things StackThingPark
- Application
- MQTT
- Dashboard
- Grafana
- Network server
- ChirpStackThe Things StackThingPark
Your devices are provisioned on the one you run, or on one HOVDB sets up.
- Application
- MQTT
Uplinks reach your application over MQTT.
- Dashboard
- Grafana
Grafana reads your data through MQTT or a time-series database.
What founding customers get
Founder pricing, locked in
Your price is agreed with me directly and stays fixed for the whole of your first contract. There is no public price grid.
Priority onboarding
Your deployment is scheduled first, and the founder runs it with you.
A real say in the roadmap
What your network needs shapes what gets built next.
Get early access
Leave your work email. The founder replies personally to talk through your network.
Prefer to talk first? Talk to the founder.