A heat network protocol based on standardised network control points and reporting methodology.
At its core this is a dictionary to describe data using standardised identifiers, to provide compatibility between systems and easy sharing of data.
The devices folder contains information for each type of device.
This project is based upon http://www.heatweb.co.uk/w/index.php?title=Heat_Network_Protocol
- camelCase naming.
- 5 levels of MQTT topic for a network (networkId / publisherId / deviceId / dataType / key).
- The standard data types are "dat" (readings), "stat" (statistics, calculations), "alarm", "system", "settings", "json", "set" & "cmd" (command). The list can be expanded, however data should be assigned a standard type if one fits.
- BMS data types include "sensor" (analogue in), "digin" (digital in) and "driver" (output).
- Each device will typically be assigned the following standard sub-topics to represent its type, name and state:
+/+/+/stat/state = on, off, ok, warning, or alarm
+/+/+/system/title = The name of the device
+/+/+/system/deviceType = device classes, e.g. "pump", "heatwebNode" or "airSource heatPump" - The networkId can contain dashes to create a network hirearchy, as would normally be described by further topic levels.
E.g. myNetwork-block1/riser1node/riser1node/system/deviceType - The publisherId is normally the device itself, the communications node the device is connected to, or is part of, but may be a different device publishing relevant data or commands to the device.
MQTT has been selected as a modern, light-weight, open protocol for network use, allowing for user management, assess rules, and wildcards. It is the standard IoT protocol.
All data requires describing:
- Where are we talking about - a network id
- Who is providing the data - a publisher id
- What it applies to - a device id
- The type of data
- A name - a data key
- A value
A 5 level MQTT topic allows all these basic requirements to be described in a way that can be filtered using wildcards for managing subscribtions.
The protocol data can easily be stored in software via a nested JSON object, or in a file system via a directory structure.
This project is organised to enable systems to automatically:
- Provide descriptions of topics
- Provide units of measurement
- Setup default values
- Setup calculated values
- Implement manufacturer specific topics using the system/deviceVersion topic
- Link to web based documentation such as manufacturers installation instructions
This project folder on GitHub contains JSON data files that describe the protocol, devices, and other useful data. These files can be imported directly info software such as Node-RED. Example Node-RED flows are provided under the examples folder to get you up and running handling live data in a matter of minutes.
If you already have your MQTT heat network up and running, the example flows include real-time dashboards to accesss data on the network. These can be used for remote monitoring, commissioning, or to enable custom alarm routes to be programmed. You will need server to know the server details and your personal credentials for access.
This protocol can also be used in conjunction with an array of apps for mobile devices, providing the topics required to access readings, or to send commands. Server details and personal credentials for access will need to be setup and provided by the network operator. Topics and Node-RED flows are provided within this protocol to enable pairing between users and devices using tapping functions (hot tap signals).
To access data on an MQTT server you will need:
- server address
- server port number
- user name
- user password
- list of topics you have permission for (this protocol helps there)
- boilerGroup
- boiler
- heatpump
- buffer
- hiu
- block
- substation
- pumpGroup
- pump
- pressure
- gas
- network
- plantroom
- onewire
- meter
- panel
- bypass
- filter