Review of the OpenThings protocol.
- Sending reports (temperature, power, etc) and receiving simple commands,
- P2P and star network topologies (one device is master, others slave),
- Basic message structure + CRC,
- No ack,
- Can be implemented on top of any protocol including RF.
- List of records
All messages are point 2 point, no broadcast and are always between the master and a slave.
Parameter type identified with a single char that also mandate the unit. Format of the parameter not mandated.
Join protocol doesn't seem to include the concept of binding: how do we ensure a set of leaf nodes only talk to a known master?
Supports management values:
- Report Period
- Battery Level
- Alarm (e.g. low battery, power fail, over temperature, tamper)
Manufacturer ID is globally unique number allocated by Sentec.
Records can be sent as:
- Unsigned integer (big-endian, shifted options not clear)
- Signed integer (2-complement, shifted options not clear)
- Floating point (IEEE 754-2008)
Applicability to OpenTRV
The OpenThings protocol is designed for communication between low power leaf nodes and a local master / concentrator. It is not designed for communication with a data platform.
- Works over any network protocol, including RF
- Matches OpenTRV current network topology (star)
- Large list of metrics that covers OpenTRV requirements + possibility for extension
- Two-way protocol that supports control of individual nodes
- Support for management meta-data such as battery power and alarms
- No provision for binding between node and concentrator
- Some protocol optimisation currently done by OpenTRV (e.g. C16) may be difficult to implement
- Some restrictions on how data can be sent for devices that have multiple sensors of the same type (e.g. 2 temperature sensors)