A power meter and a building management system (BMS) can both support Modbus TCP and still disagree about the register base, the word order of a 32-bit float, the unit and the sign of export. The connection works, a number appears on the dashboard, and the number is wrong.
When two products document the same protocol, transport and compatible roles, a connection route exists. That is enough to call them protocol-compatible. No generic laboratory test has to reproduce the pair first. The rest is project work: the point map, units, timestamps, quality rules and what happens when a link drops. The manufacturers' documents tell you the route exists. Commissioning tells you the installed points are correct. Record the two separately.
Example: active power from a meter
A meter publishes three-phase active power. The BMS must show it in kW and use it for a demand alarm. Each fault below still passes a basic "we can read it" check.
- Address base. The register list shows the value at register 3000 as FLOAT32. The list is 1-based, so the address on the wire is 2999. A client that sends 3000 reads the low word of this value and the high word of the next.
- Word order. The client assembles the two registers in the wrong order. The decode below shows the result.
- Unit. The register holds watts and the BMS point is labelled kW, so 42,700 W displays as 42,700 kW.
- Quantity. The register is total apparent power in kVA, not active power. At a power factor of 0.85 the reading is about 18% high.
- Sign. The meter reports export as a negative value. The destination treats all power as import and clamps negative values to zero, so export disappears.
- Double scaling. The 400/5 A CT ratio is set in the meter, which already reports primary current. The integrator also applies a multiplier of 80 in the client.
- Time. After a reconnect, the Gateway stamps buffered readings with the time it received them, so old data looks current.
- Staleness. The destination keeps the last value and does not mark it stale. The demand alarm never fires.
- Control. A write gets a protocol acknowledgement, but the equipment rejects it, a local override wins, or the equipment reverts later.
Decoding the value
An IEEE 754 single-precision float of 42.7 is the four bytes 42 2A CC CD. A meter that sends the high word first puts 0x422A in the first register and 0xCCCD in the second. The client's byte and word order decides what it reads:
| Order | Bytes as assembled | Decoded value |
|---|---|---|
| High word first (ABCD) | 42 2A CC CD | 42.7 |
| Words swapped (CDAB) | CC CD 42 2A | -107,614,544 |
| Bytes swapped in each word (BADC) | 2A 42 CD CC | 1.73 × 10⁻¹³ |
| Both swapped (DCBA) | CD CC 2A 42 | -428,165,184 |
A very large number or a value close to zero is the usual sign of an order error. Manufacturers use the ABCD labels inconsistently, so do not trust the label. Read a non-zero value that you can also see on the meter display, decode it in each order with the IEEE 754 float converter or Modbus register decoder, and keep the order that matches.
Energy counters have two further traps. A UINT32 counter in Wh rolls over at 4,294,967,295 Wh, about 4,295 MWh. A 500 kW continuous load reaches that in about 358 days. The receiver must treat a drop in the counter as a rollover or a meter reset, not as negative consumption. A FLOAT32 counter in kWh loses resolution as it grows. At 1,000,000 kWh the smallest step is 0.0625 kWh, so a one-minute delta on a 10 kW load (0.167 kWh) comes out as 0.125 or 0.1875 kWh. Take interval energy from an integer register when the meter offers one.
Eight layers of interoperability
The layers overlap, but separating them makes gaps visible.
| Layer | Questions to settle | Evidence to retain |
|---|---|---|
| Physical and electrical | RS-485, Ethernet, pulse, M-Bus or 4-20 mA? Which connector, pinout, reference, isolation, termination, bias, loop power and environmental limits apply? | Wiring drawing, interface specification, installation inspection and measured bus or loop checks |
| Link and network | Which serial settings, addresses, IP configuration, VLAN, routing, discovery and firewall paths are required? | Address plan, firewall rules, connection test and a packet or bus capture |
| Protocol roles and profile | Which side is client or server, publisher or subscriber? Which transport, version, profile, objects, function codes and optional services are implemented? | Interface documents for the exact model and firmware, conformance evidence and configured roles |
| Syntax and encoding | Which register base, byte and word order, signedness, string encoding, data type, array shape and null value apply? | Point map plus raw request and response examples with the decoded expected values |
| Semantics | Which asset, quantity, unit, scale, direction, state and calculation does each point represent? | Approved point schedule, unit and scaling rules, naming model and calculation revision |
| Time and quality | Does time come from the source or the receiver? How are bad, uncertain, missing, stale, substituted and late values shown? | Clock design, quality mapping, freshness limits and interruption and replay results |
| Security and authority | How are components identified, authenticated and authorised? Who issues, rotates and revokes credentials? Which writes are permitted and logged? | Trust model, least-privilege roles, credential procedure, audit record and failed-access tests |
| Operations and lifecycle | What happens during a link loss, restart, queue limit, firmware change, certificate expiry or product replacement? Who owns each layer? | Failure and recovery tests, version baseline, support and update terms, backup and rollback procedure |
The W3C Web of Things architecture keeps these concerns separate. A Thing Description lists a device's interactions, data schemas, protocol bindings and security metadata in one machine-readable file. That reduces custom discovery work. The consumer still has to support the same binding and use the described meaning correctly.
What each protocol leaves undefined
Each protocol standardises part of the stack. The manufacturer's documents and the project configuration define the rest.
Modbus
The Modbus Application Protocol Specification defines function codes and four data tables: coils, discrete inputs, input registers and holding registers. It does not say which value sits at which address, or its type, scale or word order. The manufacturer's register list defines those.
The 4x notation adds an addressing trap. Reference 40001 means holding register 1, which is address 0 in the request on the wire. Some manuals list 1-based register numbers and some list zero-based addresses. Some clients expect one convention and some the other. Edge expects the zero-based address, so reference 40001 is entered as 0. The Modbus address converter converts between the conventions. The Modbus function and exception codes decodes the error responses.
Writes have their own traps. Function code 06 writes one register and function code 16 writes several in one request. A 32-bit value written as two FC06 requests is not atomic: the first word can land and the second fail, which leaves a half-written setpoint. Some devices return a normal response to a write that they then ignore or limit. Read the target register back after every write. Edge pauses live reads on a connection for 2 seconds after a write by default, which gives a slow device time to apply the value before the readback.
On RS-485, bus time limits the point count. At 9600 baud with 11-bit characters, one request and response for a 60-register block take about 160 ms on the wire, before the device's own response delay. The RS-485 commissioning guide works through a complete polling cycle.
BACnet/IP
BACnet defines objects and properties. A meter's active power arrives as the Present_Value of an Analog Input object, with a Units property beside it. That removes the register-decoding problem. Other problems remain: which object instance holds which quantity, whether each device instance is unique on the network, and whether discovery broadcasts (Who-Is on UDP port 47808) reach across subnets.
A BTL listing covers the interoperability building blocks (BIBBs) and object types in its scope. It does not cover the object list of the device you install.
For control, BACnet uses a priority array with 16 levels. A write at priority 8 stays in force until something writes NULL at priority 8 to relinquish it. Agree which system owns each priority level and how it releases control.
MQTT
MQTT 5.0 defines topics, message properties, sessions and three quality-of-service (QoS) levels. It does not define what a payload means. Two systems can both support MQTT and disagree about topic hierarchy, schema, point identity, units, timestamps, retained messages and duplicate handling.
QoS 1 is at-least-once delivery. When an acknowledgement is lost, the sender resends and the receiver can get the same message twice. QoS 2 is exactly-once, but only for one hop: client to broker, or broker to subscriber. A subscriber that subscribes at a lower QoS receives the lower level. No QoS level proves that a sample was correct, that every sample became a message, or that the database stored it once. Put a source timestamp and a message ID or sequence number in the payload so the receiver can discard duplicates.
Sparkplug 3.0, published as ISO/IEC 20237:2023, fixes part of the gap for industrial data. It defines the topic namespace, a typed binary payload and birth and death messages. An edge node publishes an NBIRTH message that lists every metric it will send. It registers an NDEATH message as its MQTT Will, so the broker publishes it if the connection drops. Subscribers then know which values are stale. Sparkplug leaves units, sign conventions and asset identity to the project.
Transport security is a separate agreement. See MQTTS, MQTT over TLS.
OPC UA
The OPC UA vs MQTT vs Modbus guide compares the three protocols, and the node identity guide explains NodeIds and namespaces.
OPC UA carries more context than a register or an arbitrary message. Its DataValue pairs a value with a StatusCode, a source timestamp and a server timestamp. The top two bits of the StatusCode give its severity: Good, Uncertain or Bad. A variable can also expose its engineering units. The consuming application must still select the correct node, check the status before it uses the value, keep the relevant timestamp and decide what to do with Uncertain and Bad values.
The client and server must also agree a security policy and message mode, for example Basic256Sha256 with SignAndEncrypt, and trust each other's application certificates. Certificate validation depends on time, so a wrong clock on either side stops the session.
Zigbee and LoRaWAN
Zigbee 3.0 certification means a device joins a network and exchanges data through the Zigbee Cluster Library. It does not mean every value uses a standard cluster. A meter can report power through the Electrical Measurement cluster (0x0B04), which carries its own multiplier and divisor attributes, or through a manufacturer-specific cluster that only the maker's converter decodes. Before you buy, check which clusters and attributes the model uses. Apply the multiplier and divisor that the device reports, not a fixed constant.
LoRaWAN standardises the radio link, the MAC layer and device activation. The application payload is the manufacturer's own binary format. The codec that turns those bytes into values is software that someone must own, version and update. A firmware change that alters the payload layout breaks the codec without any error at the network server, which still delivers the uplinks. The device must also match the site's regional parameters, for example EU868, and its activation method. Using Zigbee alongside LoRaWAN compares the two networks.
Syntactic and semantic interoperability
Syntactic interoperability means the receiver can parse the data. Semantic interoperability means both parties give the parsed data the same meaning.
This JSON is valid:
{
"point": "P_TOTAL",
"value": 42.7,
"unit": "kW",
"time": "2026-09-19T10:15:00Z",
"quality": "good"
}It is not a complete contract. The receiver does not know which site, asset and measurement boundary P_TOTAL belongs to. It does not know whether the value is instantaneous or an interval average, whether positive means import or export, or how good was decided. time could be the measurement time, the calculation time or the Gateway's receipt time. The CT ratio and calculation revision are also missing.
ETSI SAREF is an ontology for this problem, with its guidelines published as ETSI EN 303 760. Each system keeps its own data model and maps to shared concepts. A project does not have to adopt SAREF to use the method: define each meaning once, then map every system to it. Direct field-name translations between each pair of systems grow as n(n-1)/2, so five systems need ten mappings and ten systems need 45.
Time and quality
Decide where each timestamp comes from. The source sets a source timestamp when it measures the value. The Gateway or database sets a receipt timestamp when the value arrives. After an outage, the two can differ by hours. Keep both when the protocol provides both, as OPC UA does. Never give a replayed value its receipt time.
Clocks drift. A meter clock that gains 2 seconds a day is a minute out after a month. That is enough to put readings near a boundary in the wrong 15-minute interval. Synchronise every clock that stamps data to the same NTP source, and measure the offset during acceptance. TLS and OPC UA certificate checks also fail when a clock is far out, and the fault then looks like a security problem.
Set a freshness rule at the destination. A workable rule is three reporting intervals: at a 60-second interval, a value older than 180 seconds is stale. Do not rely on the source side alone. Edge marks a Modbus device offline after two missed polls, with a five-minute minimum. A point polled every second can therefore be up to five minutes old before Edge flags the device.
Synthetic values need a flag that survives the whole path. Edge can fill short gaps by repeating, zeroing or interpolating values, and it marks those points _synthetic: true. A downstream database that drops unknown fields also drops the flag, and the filled values then look like measurements. Keep gap fill off for billing, alarms and control.
Conformance, certification and project acceptance
Each form of evidence answers a different question.
| Evidence | What it can establish | What it does not establish alone |
|---|---|---|
| Published interface documentation | A named product or family implements the transport, role and protocol needed for a connection route | The project point map, site configuration, installed performance or recovery behaviour |
| Conformance test | One implementation meets a test suite for a stated specification and scope | Correct interaction with every other implementation, or suitability for the project |
| Independent certification or listing | A recognised programme tested a named product and version against its published scope | Options outside that scope, application meaning, site configuration or end-to-end recovery |
| Multi-vendor interoperability test | The tested implementations work together for defined functions and conditions | Every model, firmware, network, payload, optional service or failure case |
| Factory or lab acceptance test | The project configuration gives recorded results in a controlled setup | Installation workmanship, site network conditions or long-term operation |
| Site acceptance test | The installed path meets the agreed normal and failure requirements | Compatibility after an uncontrolled change |
NIST's Smart Grid Interoperability Framework treats conformance and interoperability testing as complementary. The oneM2M interoperability test format requires each test to state its configuration, initial conditions, event sequence and expected results. Use the same four headings for site tests.
Procurement schedule
Ask every supplier or integrator to complete the same schedule before equipment is ordered.
| Item | Required project answer |
|---|---|
| Source | Manufacturer, model, hardware revision, firmware, interface option and current manual or register list revision |
| Destination | Application and version, driver or connector, expected role and supported profile |
| Connection | Physical interface, topology, addressing, serial or network settings and required network path |
| Point scope | Read points, writable points, alarms and events, and maximum update or poll load |
| Data contract | Identity, data type, encoding, unit, scale, direction, precision, valid range and enumeration meanings |
| Time | Clock source, source timestamp availability, time zone, expected latency and maximum age |
| Quality | Source states, destination mapping, stale rule, gap behaviour and substituted-value policy |
| Control | Permitted states or range, authority, interlocks, acknowledgement, readback and fallback state |
| Security | Device identity, authentication, encryption, credential owner, least privilege and audit record |
| Failure | Loss detection, buffering, queue limit, retry, duplicate and order behaviour, restart and resynchronisation |
| Lifecycle | Supported versions, firmware support end date, update owner, change notice, vulnerability process, backup, rollback and replacement path |
| Acceptance | Test owner, equipment, stimuli, expected results, tolerances, evidence and sign-off |
Mark an unknown answer as unknown. A blank cell tends to become an assumption on one side and a commitment on the other.
Twelve-step acceptance test
Use the exact hardware, firmware, interface documents and receiving application intended for the project. Capture raw data at the source, at each intermediate system and at the final destination.
- Record identity and configuration: model, serial number, firmware, interface document revision, Gateway and Edge versions, connector version and a configuration fingerprint.
- Prove the physical path. Inspect the wiring and topology. Check the serial and network settings. Show that the intended endpoints are the ones communicating.
- Trace every point from the destination back to the source register, object, channel or message, and to the physical asset label.
- Check encoding. Read two known non-zero values for each point. Compare register base, data type, sign, byte and word order, scale and enumerations.
- Check meaning. Confirm unit, direction, measurement boundary and calculation against a reference instrument or a controlled source.
- Check time. Compare the clocks. Introduce a known delay. Confirm that replayed data does not appear current.
- Check quality and stale state. Cause a source fault, an invalid value and a stopped update. The final application must show each one differently from a valid zero.
- Test permitted writes. Test authorisation, limits and interlocks. Record the request, the protocol response, the observed equipment effect and the final reported state.
- Break each link. Disconnect the field connection and the onward connection separately. Record loss detection, last-value treatment, buffering, alarms and local behaviour.
- Restore each link. Reconnect within and beyond the buffer window. Check order, duplicates, gaps, energy counter deltas across the gap and clearance of the stale state.
- Restart each component in turn, then restore from the documented backup. Check identities, point mappings, clocks, credentials and queued data.
- Apply one approved firmware or configuration change, then repeat the affected tests. Roll back if they fail.
The acceptance record for each path names the model, firmware and configuration revision, the receiving application and version, the points and cases that passed, the untested options, the date, the observer and the person who accepted each deviation. When a version, profile, point map or security requirement changes later, the record shows which tests to repeat.
Worked example: PowerLogic PM5000 to Edge
Schneider Electric documents the interfaces of the PM5000 family by model in its family material. The PM5110 and PM5330 have RS-485 Modbus RTU. The PM5560 adds Ethernet Modbus TCP. BACnet/IP is available on the PM5560 and PM5563 from firmware 2.3.0, according to Schneider's BACnet/IP note. Schneider publishes separate Modbus register lists for the PM51xx and PM53xx range and for the PM55xx, PM56xx and PM57xx range.
The PM5000 device guide gives three routes into Edge:
- Modbus RTU: Connect an RS-485 model to a ZMB-31. The ZMB-31 is a Modbus RTU master at 300 to 115,200 baud and reads up to 30 registers. It sends the values over the Zigbee mesh, so no data cable runs back to the Gateway.
- Modbus TCP: Connect an Ethernet model to the site network. Configure Edge as the Modbus client with the meter's IP address, port 502 and unit identifier.
- BACnet/IP: On a PM5560 or PM5563 at firmware 2.3.0 or later, configure the Edge BACnet/IP client to discover the meter and read its objects.
Commission one point before the rest. Record the complete catalogue number and firmware. Select the register list for that range. Check whether it gives 1-based register numbers or zero-based addresses. Map total active power as FLOAT32, read it under load and compare it with the meter display. If the site exports, check the sign during export. Then add the remaining points, and set the poll interval and stale rule for the complete point list.
Where the Device Directory lists an Edge device template for a model, the point map is already written. Otherwise the integrator writes it from the manufacturer's register list.
Control interoperability
For monitoring, acceptance ends when the destination value is correct and fresh. For control, you must also confirm the equipment state after each write.
A command goes through these stages:
- An authorised requester creates a command with an ID, a target, a value and an expiry time.
- The controller checks range, mode, interlocks and current authority.
- The controller sends the protocol write.
- The equipment acknowledges, rejects or times out.
- A readback or an independent process measurement shows whether the intended effect occurred.
- The system records any later override, supersession or loss of authority.
- A defined local state applies when the requester is not available.
A TCP success, an MQTT publication or a Modbus response does not prove that the plant reached the intended state. Edge reports the protocol acknowledgement for a Modbus write and does not read the value back itself. The integration must do the readback. For BACnet, also agree the priority level and the relinquish procedure, as described above.
Safety, protection and equipment-protection functions need their own qualified design. Do not delegate them to a monitoring path.
Open standards and vendor lock-in
An MQTT feed is open at the transport layer. If its payload is an undocumented binary format, or its topics encode asset identity that only the supplier's cloud can resolve, a new supplier must rebuild the point map from nothing. An open protocol reduces lock-in only when the buyer can also obtain and reuse:
- the complete point and object map;
- the protocol and profile configuration;
- certificates, identities and the credential-rotation procedure;
- data and event exports with units, timestamps and quality;
- rules, calculations and semantic mappings in a documented form;
- backups and a tested restore procedure; and
- support and security-update terms for the life of the asset.
A project-specific adapter can be easy to maintain when its input, output, tests and owner are documented.
NIST IR 8259 Rev. 1, published in April 2026, expects manufacturers to supply both security functions and the information customers need to use them. Record the firmware support end date and the credential-rotation method for each component in the procurement schedule. When a vendor stops issuing firmware, known vulnerabilities stay open. When a certificate expires without a rotation procedure, the link stops on that date.
EpiSensor hardware and Edge
EpiSensor sensors report over Zigbee to the ZGW-20 Gateway, which runs Edge. For third-party equipment, Edge takes these roles:
| Role | What Edge does | Boundary |
|---|---|---|
| Modbus TCP and RTU client | Polls configured registers from 1 s live stream to 24 h clock-aligned intervals. Batches contiguous reads up to the 125-register protocol limit. | 16-bit and 32-bit integers and FLOAT32. No 64-bit or string formats. |
| Modbus server | Holds the latest mapped Edge values in Modbus registers for a BMS or SCADA system to poll. | Listens on TCP port 10502 by default. The client sets the poll rate. |
| BACnet/IP client | Discovers devices and polls Present_Value of analogue, binary and multi-state objects. | Up to 16 devices with 64 points each. Polling, not change-of-value. No MS/TP or BACnet/SC. |
| OPC UA client | Polls configured NodeIds from 1 s to 24 h intervals. | Up to five server endpoints. |
| ZMB-31 interface | Reads Modbus RTU equipment on RS-485 and sends the values over the Zigbee mesh. | Up to 30 registers per ZMB. |
Onward flows publish selected points over MQTTS or HTTPS, or write them to files. Data and rules stay on the Gateway when the internet link is down.
Start with the BMS, SCADA and meter integration guide. Then bring the completed procurement schedule and the current interface documents to System Builder or a technical enquiry.
Common questions
What is interoperability in IoT?
It is the ability of the selected devices and systems to exchange information and use it correctly for a defined task, including after a link fault or restart. It covers the physical interface, protocol roles, data encoding, meaning, time, quality, security and lifecycle.
Does support for the same protocol guarantee interoperability?
No. Matching protocol, transport and role support means a connection route exists. The register or object map, units, scaling, timestamps, quality rules and any writes still have to be configured and commissioned.
What is the difference between conformance and interoperability testing?
Conformance testing checks one implementation against a specification. Interoperability testing checks named implementations together in a defined configuration. Neither replaces a site acceptance test of the installed path.
What should a multi-vendor IoT acceptance test include?
Exact models, firmware and configuration; a decoded comparison against a known value for every point; timestamps and stale handling; permitted writes with readback; each link broken and restored; and a restart and restore from backup.
Do open standards prevent vendor lock-in?
Only if the buyer also holds the point map, configuration, credentials, data exports and a tested restore procedure. An open transport with an undocumented payload can still be expensive to replace.