LoRaWAN platform, own network.

What is LoRaWAN?

LoRaWAN is a long-range, low-power radio network for battery devices that send small messages. It works in the licence-free sub-GHz band, which in Europe means 868 MHz, so nothing in the chain needs a SIM card or a monthly line rental. You mount the gateways yourself, which also makes the coverage yours to repair. Put one somewhere sensible and it will hear devices two or three kilometres away across a built-up town, and past ten over open ground; the meters underneath it usually reach 10–15 years on their original battery.

For metering and monitoring that combination is hard to beat. A water meter, a well-level sensor and a streetlight controller can share the same network, the same gateways and the same operating budget. Asker municipality has more than 20,000 water and energy meters split between LoRaWAN and wM-Bus; Hamar and Ringsaker share one network for 25,000 ultrasonic meters.

How it works on Divako

1. Device. The meter or sensor is provisioned with its keys – OTAA for almost everything, ABP where a device firmware still requires it. Devices import by EUI, CSV or API, and each one is bound to a profile from the device library, so its payload is already understood before the first uplink.
2. Network. The device sends a short uplink on 868 MHz. Every gateway that hears it forwards the message; the network server deduplicates, checks the frame counter and keeps one reading. Divako ships a network server, or takes traffic from the ChirpStack instance you already run.
3. Platform. The payload is decoded against the device profile and normalised: unit, timestamp, quality and metadata travel with every measurement. Gateway health, RSSI and SNR are stored alongside, so a degrading link is visible before it goes silent.
4. Analysis. Consumption, levels and alarm flags are checked per device type. Leak, burst, backflow, tamper and frost alarms route to email, webhook, MQTT or the incident system you already use.
5. Integration. The same readings leave over REST, MQTT, webhooks or SFTP, and through native connectors to billing systems such as Komtek and Gemini, SCADA or ERP.

What to watch out for

• A join loop is almost always DevNonce, not radio. A device that rejoins with a nonce the network has already seen is rejected, and it will keep trying until the battery notices. Clear the device’s join state on the network server after a hardware swap or a factory reset, rather than blaming the gateway.
• Range on a map is not range at the installation point. A meter in a basement or under a steel chamber lid can lose more signal in the last two metres than in the previous five kilometres. Plan gateways from where the devices actually sit, and check RSSI and SNR after installation, not before.
• ADR is not a substitute for a link budget. Adaptive data rate pushes a device up to a higher spreading factor when the link degrades, which costs airtime and battery. A fleet that has quietly drifted to SF12 is telling you a gateway is missing, not that the devices need new firmware.
• The reporting interval spends the battery, not the radio. Hourly reporting on a ten-year battery is a different device from one that reports every five minutes. Set the interval per device, and change it by downlink when you need detail for a while.