Connected Systems

From Heatweb Wiki
Jump to: navigation, search

Its now possible to do pretty much whatever you want when it comes to metering, monitoring, and home control, technically.

In terms of building services on heat networks, we have the following to consider:

  • Meter reading, for charging for energy
  • Prey-pay systems - requiring a means to isolate and a user interface to deal with emergency credit
  • Services commissioning and monitoring - via connection to the HIU (typically RS485)
  • Remote commissioning and monitoring (beyond direct wire to HIU)
  • Protocols for communication
  • Data volumes
  • Remote fault reporting vs regular maintenance
  • Network load management - via remote connection to HIU
  • Data protection
  • Anonymous data
  • Home control and room thermostat integration
  • Occupancy sensor link to HIU operation
  • Simplicity of use
  • Support


In a perfect world, you have a single wall display that fulfils the standard functions of room thermostat and timer, along with the billing functions, control over the HIU, and wireless link to property for communications.

All data is handled by a single platform that allows the user ultimate visibility and data protection, with just one interface to get to grips with for all services, and systems that affect energy efficiency working together.

A browser based interface is also desirable, enabling users to access the same functions over their mobile devices from anywhere.

We would like all protocols used for communication to be open, so they can be used contract free, and not rely on any one specific service provider for operation, but the system also needs to follow the latest security requirements.


What's Important

Home control is nice, and easy to provide, but is a feature that only a few will make use of for long. The key function it is used for is heating on and off control, but that is better suited to automated occupancy sensing.

What is important is making sure everything works properly in the first place, and been able to identify problems as they occur.

We would consider the primary objective of a system to be to prove everything is working 100% from the moment of commissioning.


Cables & Protocols

RS485

RS485 describes a 2-wire standard for serial communication where many devices share the same wires.

Only one device can talk at once, so software typically uses a master-slave setup, with the master directing things.

Used for Modbus, and for HIU communications.

Ethernet

Ethernet uses Cat5 and Cat6 cabling, comprising of 4 sets of twisted 2-core. It it used for standard TCP/IP network communications, and alongside WiFi, drives internet connected devices.

Optionally, Ethernet can carry power to devices, and is then referred to as PoE - Power Over Ehernet. Devices at both ends need to be PoE devices.

Modbus

Modbus is a serial protocol for communicating, typically over an RS485 cabling system, but can also be over TCP/IP (networks or the internet).

It is a master-slave setup, with devices having unique addresses, and data stored in numbered registers.

Modbus typically runs up to 32 devices.

MQTT

MQTT is a protocol for communication over TCP/IP networks, with a server and client. It uses a multi-level topic structure to communicate data, typically numeric or text values, but can be any serial data (such as HIU or Modbus) or encrypted data.

It works on a publish and subscribe system where devices can both publish and subscribe to any topics they have permission to do so. A single server runs the MQTT service, with a fixed address, and all other devices connect to that server. The server runs permissions and holds data, passing it on to any devices that are subscribed to the relevant topics.

The protocol allows for 3 levels of 'Quality of Service', or QoS.

  • The first is to send data once - so it is passed on immediately to any devices subscribed. If they miss it, then they miss it.
  • The second sends data more than once, ensuring a subscriber gets the message, but they may get it more than once.
  • The third sends the data once, and only once, but requires a response to guarantee delivery, holding data until all subscribers have received the message.

Data is as standard deleted one communicated, but a publishing device can ask for the data to be held permanently, so subscribers will receive the latest messages when they first subscribe (after a turn on or reboot). The MQTT server can itself retain data between restarts where set to.

Topics subscribed to can include level based wildcards, as can permissions, making MQTT a powerful tool for integrating security across devices, and filtering data. As such, MQTT is a new standard for IoT, home control, and SCADA systems.

Mosquito

Software that runs on a server and drives an MQTT service.

Node-RED

Software that runs on devices, or a server, with a front end for writing and editing that software. The front end provides a number of nodes that can be dragged onto a web browser canvas and wired together, then complied and published with a single click.

It's primary role in HIU systems is to route data, performing any calculations, timing functions, and general logic to signals, with the facility to write function nodes written in JavaScript. Also included are MQTT and serial port, in and out nodes, allowing direct communication with an MQTT server, Modbus devices, or HIUs.

Node-RED drives visual dashboards that can be viewed in a browser to monitor systems (SCADA).

Node-HIU

Node-RED software written by Thermal Integration for communicating with HIUs, and all other network functions.


Modbus vs MQTT

When it comes to connecting to HIUs, there are two options:

  • Modbus RS485
  • HIU RS485 + MQTT

Modbus is the simplest protocol, and the BMS standard. It has the advantage of sharing 2 wires between devices, however the master-slave arrangement limits the ability to monitor rapidly changing data. It can be implemented at an HIU level, with a Modbus Master for every 32 HIUs sharing the same 2 wires. The Master would typically convert data to Ethernet and to a TCP/IP server in a plantroom, or remotely.

The MQTT approach takes HIU data, every second, feeds it through Node-RED, and where required onto an MQTT service. 2 wires are required from each HIU to the Node-HIU Switch running Node-RED. Typically one Switch per 8 or 16 HIUs, with WiFi, Ethernet or GSM from there on.

We deploy the MQTT approach where possible for speed, as it allows a resolution of data far greater than Modbus, initiated from the device end rather than a Master. If no data is needed to be sent, there are no communications, but if events are changing fast, all new data is sent as it happens, throughout the system, both directions.

Key advantages of MQTT over Modbus:

  • High speed communications, initiated by sender.
  • Ability to track live loads and return temperatures.
  • Live VWART (return temperature) calculation on a network, that can be compared to live plantroom heat meter data to determine bypass flow - all flow not going through an HIU. This is to identify and alarm flushing bypasses left open.
  • Stored running VWART, so long-term efficiency of HIUs can be monitored.
  • Where we need to go to limited data GSM communications, the data usage can be entirely reserved for interesting HIU data and necessary traffic only.
  • Ability to generate a 1 second resolution DHW diversity dataset.
  • Unique HIU specific topics provide a transparent gateway for direct two-way serial communication to the HIU, allowing remote connection of manufacturers commissioning software.
  • Modbus systems can be remotely interfaced with via a Node-HIU-Modbus Gateway. This way heat meter data from a BMS can be fed back into Node-HIU and into alarm logic, and DP data from HIUs can contribute to pump control logic.
  • The Node-HIU Switches are powered over the Ethernet cable (PoE) so no power supplies are required if cabling is less than 90m between Node and a powered PoE Ethernet Switch.

Standard System Topology

File:HiucomsCP.svg

Common Topologies

File:hiucoms1.svg

Node-HIU GPRS Topologies

File:hiucoms2.svg

Node-HIU WiFi, Bluetooth & MQTT over GSM Topologies

File:hiucoms5.svg

  • Runs on standard Raspberry Pi
  • Provides two independent routes to the Internet - Bluetooth mesh, and users WiFi. The Bluetooth provides a permanent lower speed connection between systems and then out to the internet via any systems that have GPRS. The users WiFi provides separate higher data rates, and allows user interaction with system.
  • Two way communications along either route
  • No wiring infrastructure, other than power to riser nodes (can be solar powered)
  • Standardises on MQTT communications protocols for compatibility with other systems
  • HIUs, meters, and network sensors all covered
  • User provided with mobile phone dashboards interface over their WiFi network, covering HIU functions, meter readings, and room thermostat control
  • User has option to port forward to dashboard for remote home control
  • Low cost GPRS communications on Bluetooth mesh, typically under £5 per month per SIM, with one SIM per mesh
  • Self-learning central heating controls
  • Presence sensing using WiFi network

File:hiucoms6.svg

Node-HIU LoRaWAN Topologies

File:hiucoms3.svg

Our Experience

We now have a number of connected sites, and some benefits have become clear to us.

  • The need to 'send an engineer to site to see if', can all but vanish.
  • Having access to Differential Pressure and Primary Temperature data from a HIUs it very useful to fault find networks. There are often bypasses left open, or DP control over pumps not setup, or boilers that drop out, and been able to spot these problems as they happen can save a lot of hassle, especially when the alternative is reacting to user complaints the following day.
  • There are quite a few settings in a domestic system that it is useful to be able to adjust remotely. The most common would be hot water temperature, maximum heating temperature, and keep warm mode of operation and temperatures. Systems are designed for operation at the limits, but spend most of their time with different conditions, and remote connection allows the system to be adapted - without it the slightest change in parameters would require a site visit to every property. There are many heat networks out there that could be improved drastically in an instant, if only one could wave a magic want and drop central heating setpoints and turn off keep-warm in every property.
  • For the first few weeks of operation, having high resolution data on performance is the only way to detect every problem. Having access to all sensor data ensures that every single problem can be flagged the first time it occurs, and is the only way we know to guarantee everything is working perfectly. We can see far more remotely that the best engineer can determine from been present in a property. The one second data provided by HIUs can identify the following:
    • Domestic hot water response times, to catch any occurrences of delays, typically longer than 15 seconds.
    • Loss of pressure on a central heating system.
    • Loss of pump operation on a central heating system.
    • Low differential pressure at times of peak demand.
    • Blockages in pipework or open bypasses, from comparing DP readings at HIUs with nearby HIUs, and expected levels.
    • Incorrect operation of network DP control
    • Crossed pipework
    • Unbalanced radiator systems
    • Any component failures
  • If ever there is a complaint one can verify it, see the cause, and inform the correct engineer. In practice, this solid evidence trail of performance, or lack-of, prevents many arguments between parties, and helps maintain quality of service.
  • Communications networks do not need to be permanent. Indeed, 90% of their benefits come in the first few months following commissioning, where there are snags on the system to be hunted down. So, where the cost of a network infrastructure, or the management of ongoing services, is unattractive, the use of temporary GSM communications can be an attractive tool for proving a networks operation prior to hand-over. We supply GSM systems that connect to a group of HIUs, and provide all remote services. They would typically be installed in a riser, with 2 wire connection to each HIU. At the very least we would advise that the cable be put in place to keep options open, and allow an engineer to connect his laptop to an HIU from the riser.
  • Data rates can be cut to very little once a system is proven. Only problems need reporting, and with everything working properly to start with, they should be quite rare. As such it is worth looking at two data strategies where data is costly. This translates to separate SIM card contracts - unlimited data or PAYG SIMs for hand-over stages, with low data shared SIMs once up and running.
  • You can't rely on monitoring long-term, in terms of keeping an eye on it. This part needs to be automatic, so you can forget about it completely, and problems are flagged by email or SMS. At that point you can dig into records and see what happened. Other than that, you get a monthly report telling you how fine and dandy everything is.
  • Nothing focuses the mind on doing a decent job better than having your work monitored. Its like taking the new BESA HIU tests into the field, and can be a powerful force for improving quality.
  • Setting up alarms and routing them to different recipients based on various logic is the key to it all. When set up, systems can be forgotten about, and alarms relied on to trigger interventions. If conditions deteriorate, then backup recipients can be contacted.

Connected to HIU via Volt-Free

The most common reason to interface with an HIU is to turn central heating on or off. This is typically achieved using the volt-free connection to each HIU, and doe not require use of electronic communications. These terminals are usually connected to the volt-free switch on a typical room thermostat.

Nearly any control system, including home control systems, have a relay function that would be used for this method of control.

  • Standard programmable room thermostat or timer
  • Nest room thermostat (via hub)
  • Wondrwall room thermostat
  • Any control system with volt-free relay

Connected to HIU via RS485 and Node-HIU Switch

The Node-HIU Switches act as a bridge bewteen HIUs and other systems, most typically local or wide area networks. They are general purpose Linux based systems that can implement any open-protocol.

  • Ethernet and Wifi Systems connecting to Internet
  • Alexa, "Alexa, turn the heating up."
  • Any MQTT system
  • Modbus
  • Just about any protocol that exists

Connected to HIU via RS485

  • Enerza

LoRaWAN

Lorab.png


Raspberry Pi

Connecting systems is basically about routing data, and there is no operating system better suited than Linux.

Th Raspberry Pi is a mini computer that runs a version of Linux called Raspbian. It is the third biggest selling computer of all time, in just 5 years, recently overtaking the Commodore 64 at 12.5 million units. Windows PCs and Macs top the list.

The Raspberry Pi is a robust and reliable platform, with one weakness - the SD card can become corrupted if not powered down properly. However, it is easy to implement a read-only file system, where the SD card is never written to, removing this as a problem.

The beauty of the Raspberry Pi lies in its power to cost ratio. You effectively have at your disposal one of the most powerful software platforms ever seen, and a price tag of less than £40 for the most powerful model, and £5 for the most basic model. With computers now at this price tag, and the rate of technological change been so high in the fields of wireless networking, it no longer makes sense to design more costly control system that last 20 years. A lifetime of 10 years and a replacement cost of £10 will allow us to upgrade controllers as part of regular 5 year maintenance and keep pace with hardware and software development.