Connect
Native drivers talk to each device the way it expects, on the network it is already on. Discovery finds what is there, profiles describe what it means.
- BACnet
- Modbus
- KNX
- MQTT
- LoRa
- BLE
BACnet, Modbus, KNX, MQTT, LoRa and BLE devices, read, normalized and put to work from one place.
6
Protocols read natively: BACnet, Modbus, KNX, MQTT, LoRa and BLE
1
Tag model, so a temperature looks the same whichever protocol sent it
3
Ways to deploy: on an edge gateway, on your own server, or in the cloud
4
Ways to use the data: dashboards, alerts, rules and an open API
Most sites run at least three of these protocols side by side. IoTServa exists so that the people who need the data do not have to learn all of them.
A chiller, a power meter, a hotel room and a tank sensor can all measure temperature or energy. Each one describes it in a different way, so combining them usually means a different tool per protocol.
Object analog-input 3, property present-value.
Holding register 40012, two words, word-swapped.
Group address 1/2/5, datapoint type 9.001.
A topic string and whatever payload the vendor chose.
A few bytes on a port, decoded by a payload decoder.
A GATT characteristic or an advertising packet.
Pick a protocol to see how a native address becomes a named, typed tag.
Read chillers, air handlers and VAV boxes over BACnet/IP and BACnet MS/TP, with COV subscriptions so changes arrive when they happen.
site.tower-a.ahu-02.supply-air-temp
13.4°C
Sample addresses are illustrative. Real tag names follow your site, building and equipment naming.
Read the BACnet PageThree jobs, done once, whichever protocol a device speaks.
Native drivers talk to each device the way it expects, on the network it is already on. Discovery finds what is there, profiles describe what it means.
Every reading becomes a tag with a name, a unit, a timestamp and a quality flag, placed in your site, building and equipment hierarchy.
Show it, alert on it, trend it, automate with it, or hand it to another system. The same tag drives all of them.
Each protocol has its own pitfalls. We build around them instead of hiding them.
Listen to KNX group telegrams over KNX IP, map group addresses from your ETS project, and control rooms from one place.
Explore KNXYears of battery, kilometres of range.
Explore LoRaTags, beacons and nearby sensors.
Explore BLERead chillers, air handlers and VAV boxes over BACnet/IP and BACnet MS/TP, with COV subscriptions so changes arrive when they happen.
Explore BACnetPoll Modbus RTU and Modbus TCP devices, decode registers with the right word order and scaling, and publish clean engineering values.
Explore Modbus
Subscribe to any broker, publish normalized data back out, and keep topics, QoS and retained state under control.
Explore MQTTEverything between the device and the decision, built to work together.
Protocol drivers that run beside the equipment.
One shape for every reading, whatever protocol sent it.
The right view for each role, and an alert only when it matters.
Your data, available to the tools you already use.
Describe a device model once, reuse it everywhere.
Brokers, LoRaWAN networks, BMS and your own tools.
Real sites are never a single protocol. These are the places where combining them pays off first.
HVAC, metering and lighting from different vendors, in one view.
Drives, meters and PLCs trended together, with alarms that mean something.
Generation and consumption reconciled in one view.
Temperature coverage for cold rooms, with sensor health tracked.
Rooms, plant and meters across many buildings.
Sensors across land where Wi-Fi and cables never reach.
A pilot reads your real devices against written criteria. Then you decide.
Agree what the pilot must prove, and on which devices.
Drivers and profiles set up against your real equipment.
Readings checked against known values in real operation.
Results measured against the criteria. You choose the next step.
Run protocol drivers on a gateway at the site, keep history on your own server, or use the cloud. You choose, and you can mix.

Practical guides from the engineers who read them every day.
BACnet and Modbus are both common in buildings and plants. Compare their data models, networks and where each one fits.
Read the Guide
KNX controls rooms, BACnet controls plant. See how they differ and why many buildings run both.
Read the Guide
LoRaWAN devices and gateways must use the right regional plan. Learn why Malaysia uses AS923 and what to check before buying.
Read the GuideThe short version of what people ask before a pilot.
IoTServa is an IoT platform that reads devices speaking BACnet, Modbus, KNX, MQTT, LoRa and BLE, turns every reading into one consistent tag model, and puts the data to work in dashboards, alerts, rules and an open API.
BACnet (IP and MS/TP), Modbus (RTU and TCP), KNX (through KNX IP), MQTT (as a client of any broker), LoRaWAN uplinks, and Bluetooth Low Energy through BLE gateways.
No. IoTServa reads the devices and systems you already run. It sits beside your BMS, PLCs and gateways rather than replacing them.
At the edge on a gateway or industrial PC, on a server in your own premises, or in the cloud. Many sites use an edge gateway for protocol work and a server for history and dashboards.
Both are possible, and writes can be disabled per site. A monitoring-only project stays read-only until you decide otherwise.
Request a pilot. Tell us which protocols and devices are on site, and we scope a small pilot that reads your real equipment before anything larger is agreed.
Tell us which protocols are on site. We will scope a pilot that reads your real devices.