Compare

One Platform or Many Tools?

An honest look at the usual ways to read a mixed-protocol site, including when IoTServa is not the right choice.

Five Approaches, Side by Side

Question	IoTServa	One Tool per Protocol	In-House Scripts	Cloud-Only IoT Platform	Vendor BMS Add-ons
All six protocols in one view	Yes	No, one view per tool	Only what you build	Usually needs gateways, often partial	Usually that vendor and a few protocols
One tag model across protocols	Yes, names, units, quality	No	Whatever you design	Varies by platform	Within the vendor system only
Collects during an internet outage	Yes, with an edge gateway	Depends on the tool	Only if you build it	Often no, depends on a connection	Within the building network
Serial and local-only networks	Yes, drivers at the edge	Yes, for its protocol	Yes, if you write the driver	Needs a local gateway	Yes, for its own devices
Who maintains the drivers	IoTServa	Each tool vendor	Your team	The platform and gateway vendors	The BMS vendor
Control stays optional	Read-only by default per site	Depends on the tool	Whatever you build	Varies	Control is the main purpose

General descriptions of common approaches, not claims about any named product.

A dedicated tool for that protocol can be simpler. Choose a mixed-protocol platform when the second or third protocol arrives.

In-house development is justified when the logic is your competitive edge. You can still use IoTServa for the data and build on the API.

A cloud-only platform fits devices that already speak its protocol directly. It fits less well when serial and local protocols are involved.

Tell us which protocols are on site. We will scope a pilot that reads your real devices.