Heatweb BEMS Controller

From Heatweb Wiki
Jump to: navigation, search
Bemsschem1.png

Introduction

The Heatweb BEMS Controller is an open-protocol general purpose controller for the control and monitoring of equipment in heat networks.

  • Remote connectivity is provided using a built in 4G (LTE) GSM modem (Optional), with additional options for mesh radio to link multiple units via a single GSM connection. Remote tunnels can be activated providing secure access over temporary end-points.
  • Communications protocols of all types can be accommodated, with MQTT as the standard protocol. Each unit can host MQTT services both locally and on the internet using a fixed IP address or DNS services.
  • The controller can connect to all types of equipment from NTC sensors to Modbus enabled pumps, covering all types of analogue and digital signals.
  • Operational software is driven by Node-RED, backed up by a library of custom npm node packages to specifically support the various controller formats and connected equipment, as well as thousands of online training videos and resources including example projects.
  • The system operates completely licence and contract free, with options for support and training packages from Thermal Integration. Once setup and running the only costs incurred will be internet connectivity, and support as requested.
  • Touch screen display with customisable screens.
  • Out of the box can support most standard heat network controller functions. Newly developed functions can be applied as updates to existing equipment in the field.
  • Enables controls logic to be refined in use based on real-time feedback, then to be backed up and shared with others, providing the first ever open-source environment for the collaborative evolution of building (energy) management systems (to meet standards).

Case Studies

Hundreds of systems are already online in the field monitoring and controlling everything from HIUs to boilers.

The unique real-time unrestricted nature of the system has provided us with the type of data required for proper product development, more similar in nature to an laboratory test rig than a traditional BMS system. We have been able to continue monitoring every system that has ever gone in, and this has allowed us to analyse in fine detail just everything that has ever happened in the field, both before and after handover. We are then able to update software on control systems with functions developed to overcome problems or improve performance, using feedback to fine tune them until they can be demonstrated to work to perfection.

Some of the best case studies come from local authority contracts where there is a real desire to improve in-use performance and to gain a level of transparency. Some authorities have gone the distance and ripped out and replaced complete plantroom BMS systems with Heatweb control systems. For the first time ever they are able to see properly what is going on and have been able to achieve levels of performance (network return temperatures) not previously possible.

At the other end of the network Heatweb controllers are been used to fill-in the missing functions of index point DP sensing and bypass control, and one should not forget the HIUs - the Heatweb controller is at its core an HIU controller and HIU interface. Controllers have the ability to control systems using the same advanced logic that we used to achieve the best BESA results in the industry (since records began). As an HIU interface they allow one to add sensors to existing mechanical HIUs, or take over certain functions like valve control. For electronic HIUs they can act as a Modbus gateway, converting HIU data and commands into an open-protocol (so all HIU follow same data and command protocols). The open nature of the system allows manufacturers of HIUs (or any other kit) to write and deploy their own software modules, such as a mapping of Modbus Registers to standard protocol topics.

Heatweb controllers can also do substation or pump group control to a similarly advanced level of performance, with two or more controllers working together to create fully redundant systems.

A nice advantage of the Heatweb system is that it allows the data to speak for itself. Real life systems can be demonstrated as working at any time, so clients thinking of using this new technology don't need to take any risks. They know exactly what they are getting, how it works, and can pin down installation times and costs with ease. Indeed, we can supply both the equipment and training to allow one to do it yourself if competent but missing the know-how and technology.

Communications Hardware Interfaces

  • 4G Modem
  • Ethernet
  • WiFi
  • Bluetooth (with partner App)
  • RS485 (Modbus, M-Bus, bespoke protocols)
  • USB (for additional serial ports and communications devices)
  • Optional Mesh radio

Communications Protocols

  • Modbus
  • M-Bus
  • MQTT
  • REST API
  • HTTP/HTTPS
  • GET/POST
  • HIU RS485 protocols

The range of communications protocols can be quickly expanded using a variety of libraries, and functions can be written to handle bespoke protocols using any of the hardware interfaces.

MQTT data follows the standard heat network open-protocol using 5 topic levels:

network_id / node_id / device_id / data_group / key = value
e.g.  factory-B1/node0001/boiler1/dat/tF = 65.5    for the Flow temperature on Boiler 1 on the factory (Block 1) network.


The node_id refers to the network device (typically running Node-RED) that is posting the data and will be automatically added to posts.

See Heat Network Protocol for a more comprehensive description or the protocol - keys already exist for most related data.

Inputs & Outputs

The standard controller provides I/O to handle most applications, however further controller options increase the range of I/O as needed.

IMPORTANT! Some input settings require the input jumper to be manually changed.


Bcon2.PNG

Inputs and outputs can be setup on either the touchscreen or through other means.

The IO Setup screen provides a list of all system inputs and outputs, each individually accessible.

Hcon28.PNG


Each input or output has three representations:

  • Raw data is read as a voltage, a resistance, a contact, or communications protocol.
  • Readings are the calibrated output values, such as temperature, pressure, or on/off.
  • Output data takes the reading and gives it a meaning, such as Flow Temperature, or Return Temperature.

Each representation has a topic (for MQTT), a title, and units.


Hcon29.PNG


Standard

Suitable for HIU control or interfacing, remote sensing, Modbus interfacing, data routing, or as a user interface. Universal analogue inputs can cover most NTC or 0-10v sensor types, with 0-10v outputs for control. RS485 allows interfacing to other systems over Modbus, M-Bus, or other protocols.

  • Eight Universal Inputs:
    • 1K or 10K thermistors
    • 0-10V analogue inputs
    • Dry contact/counter inputs
  • Pluggable Connectors 26-16 AWG wires
  • Four AC Triac Outputs, 1A/24V
  • Four 0-10V Outputs
  • Four General Purpose LEDs
  • RS485 In and Out ports
  • 24VAC/DC Power Supply
  • Real Time Clock with Battery Backup
  • On board hardware watchdog
  • Resettable fuse
  • Status LEDs on all Digital Inputs and Outputs
  • TVS protection on all inputs
  • USB Connector
  • 2x HDMI Ports


Bmsio1.png

Bahspec.PNG

Optical Option

The following are instead of, or in addition to, the standard arrangement.

  • Four Optically Isolated Digital Inputs with status LEDs
  • Four 0 - 10V or ±10V Analog Inputs
  • Four Optically Isolated 4-20mA Inputs
  • Four Optically Isolated Open Drain Outputs, 24V/4A peak
  • Four 0-10V Analog Outputs
  • Four 4-20mA Analog Outputs
  • Four General Purpose LEDs
  • TVS Protection on all Inputs
  • RS485 Port


Relays Option

  • Eight RELAYS with Status LEDs and NO/NC contacts


Digital Inputs

  • Eight universal opto-isolated inputs 3V-24V or 120V-240V AC/DC


PWM Option

  • Eight relays with status LEDs and pluggable connectors
  • Eight layer stackable
  • Eight 12-bit A/D inputs
  • Four 13-bit DAC outputs (0-10V dimmers)
  • Four PWM 24V/4A open-drain outputs
  • Eight optically isolated digital inputs


PT Option

  • Two ADS1248 24 bit delta-sigma converters (four channels each)
  • Factory accuracy: 0.1%
  • Maximum accuracy (through calibration): 0.01%
  • Eight layer stackable to 64 RTD channels
  • RS485/MODBUS transceiver
  • PT100/PT1000 sensor selection
  • Contact closure/Event counters up to 100 Hz
  • Four Quadrature Encoder inputs

Accessories


Enclosures

Heatweb controllers come in a choice of enclosures to suit the application, as follows:

  • Basic (thin, external Modem)
  • Standard
  • Metal Panel

Heatweb Desktops

In order to pull the various screens a system may have together, we deploy html desktops providing remote access via a secure tunnel as needed.

Desktops can be customised and saved back to the device, allowing each desktop to act as a persistent point of organising system data.

Quick access is provided to the standard screens such as notes and custom values.

The screens below are from HIU systems.

Dt1.PNG

Hcon10.PNG


Standard Roles

Roles can be combined as required, up to the limits of available I/O. Note that I/O can be expanded as required (enclosure permitting).

Bemsschem1.png



Remote Sensor & Actuators

  • Temperature, Pressure and Differential Pressure sensing as required.
  • Valve control as required

For any remote sensing and control applications, data is published either to the local or a remote MQTT server, from where any device with permission can subscribe to a real-time low latency feed that is fast enough for tight control loops.


Hcon26a.PNG

HIU Interface

  • Can interface with electronic HIUs using RS485 protocols such as Modbus.
  • Bespoke protocols can be programmed in.
  • Add temperature sensing to mechanical HIUs.
  • Add various levels of pre-pay functionality or remote control.
  • Add remote alarming.
  • Auto-detect HIU Type from data

Hcon27.PNG


BMS Modbus Interface

  • Presents MQTT data from any device to a BMS system via Modbus registers
  • Read existing data points from BMS into MQTT data for additional monitoring and alarming facilities
  • Check correct functioning of BMS logic.


Modbus telegrams can be viewed to assist in setup.

Hcon35.PNG


Pressurisation Control

  • Extract Modbus data and volt free alarms from equipment
  • Add redundant pressure sensing
  • Recreate pressurisation set functionality
  • Pull together alarms from all pressure systems into one panel with custom graphics

Hcon41.PNG

Pump Controller

  • Control of pumps via on/off, 0-10v, or Modbus
  • Common makes of pumps can be managed out of the box, with registers pre-programmed
  • Pickup pump alarms
  • One second resolution on control and monitoring, allowing tight control loops to be properly analysed and commissioned

Hcon33.PNG

Boiler Sequencing & Buffer Control

  • Control of boilers via on/off, 0-10v, or Modbus
  • Add additional temperature sensors to both boilers and buffer stores
  • Control of loading valves via on/off, 0-10v, or Modbus
  • Weather compensate boilers and network supply temperatures using internet weather data
  • Pickup alarms and gas meter pulses
  • One second resolution on control and monitoring, allowing sequencing and temperature stability to be properly analysed, refined & proved.
  • Out of the box comes buffer control and sequencing that complies to CP1 design guidance

Group2.PNG

HIU Controller

  • Combine temperature and either pulse or analogue flow sensors
  • Control valves by either 0-10v or Modbus
  • Touchscreen user interface for HIU control.
  • Software can be updated to add new screens to touchscreen for functions such as central heating control or metering functions.

Substation Controller

  • Work with any combination of commercial sensors and actuators
  • Controllers can work in partnership sharing common sensor data and providing full redundancy
  • Evolved control logic with a track record in use, maintaining temperatures within 1C of target for years on end
  • Evolved change-over and duty/assist logic, refined in the field.


Room Thermostat

  • Simulate functionality of any type of room thermostat - hysteresis, chrono-proportional, weather compensated, optimum start.
  • Custom functionality, including pump speed control and self-learning
  • Can drive temperature control valves on underfloor manifolds
  • Multiple zone control from a single unit
  • Link to PIR sensors for occupancy detection
  • Provide users with remote control over heating via standard MQTT home automation apps


Heat Management

  • Provide access to heat meter data
  • Provide energy use screens with historical trends
  • Can simulate communications functionality of standard M-Bus masters, posting data as required in various formats.


MQTT Server & Data Routing

  • Provide secure licence-free M2M (machine to machine) low latency data communications
  • User management with password control
  • Access wildcards make setting up fine-grained security rules straight forward
  • Based on the worlds most popular IoT protocol (MQTT)

Setup and Remote Access

The Heatweb Controller is designed for rapid deployment and immediate remote support.

Startup procedure for remote access:

  1. Power up the system.
  2. On the screen menu (top left) select the Setup page.
  3. In the setup page, update the email address field where remote access details are to be sent to. More than one email can be entered using a commas to separate entries.
  4. Check that the system has internet - it will display the assigned IP addresses.
  5. Click on the Start Tunnel button and wait a few seconds for the screen to list the remote access details.
  6. Check your emails for a message containing the Heatweb Desktop for the controller, providing access to all systems.
  7. Open the attached html Desktop file for quick access to screens via the temporary secure remote tunnel (default 12 hour timeout).


The Desktop will provide access to additional setup and commissioning information as well as user instructions specific to the controller function (as dispatched).


Hcon9.PNG


Two tunnels are opened as standard - one to the standard browser interface (port 8000) and the other to Node-RED and the Node-RED dashboard (port 1880).

Hcon18.PNG


The html Desktop file is opened in any browser and provides links to the headline screens for the system. The links open in frames on the same page, or can be opened in new windows.

Desk1.PNG


Further settings are available vis the System Settings and Device Settings screens.

Hcon11.PNG


A list of other headline screens is automatically generated by the system based on detected devices. For example, where an HIU is connected the system determines the type of HIU from the data and then presents the correct system graphics, graphs and links to further help and documentation.

Setting up MQTT Broker Permissions

The MQTT Network screen provides forms for managing the local MQTT broker.

Permissions must be added before a device can connect.

Once stored, password cannot be retrieved.

Hcon43.PNG


Setting up MQTT Subscriptions

Each Heatweb Controller runs its own MQTT server, and can also establish connections to any number of remote MQTT servers.

Bmscoms1.png


Connections to MQTT brokers are created using the MQTT Connect screen on the controller.

As standard four broker slots are provided, comprising of two standard MQTT connections for LAN use, and two secure (MQTTS) connections for internet connections.

Connections to an MQTT broker require:

  • Server address
  • Port number
  • Username
  • Password


Broker listing provides basic details as well as a connection status.

Hcon36.PNG


Click on a broker in the list to access and edit details for each broker. Existing subscriptions and a summary of current traffic is provided.

Hcon39.PNG


Subscriptions for each broker can be added and edited, along with a local remapping of each topic level. Local mapping can be a replacement, or a prefix (by ending in a -)

Hcon38.PNG

Updating

Updating functionality is generally performed by performing an update to the node-red-contrib-heatweb library that runs in Node-RED and drives the back-end functionality.

Hcon13.PNG

Other libraries can be installed and updated via this same screen.

Heat Network Open Protocol

see Heat Network Protocol


Optimising GSM Signal

The Heatweb Controller is typically shipped with a GSM modem and will connect out of the box.

The Modem screen provides information regarding the GSM connection, including a graph of signal strength and data rates.


Hcon19.PNG


The following procedure is used for getting the best signal strength:

  1. On the screen menu (top left) select the Readings page.
  2. In the Readings page, type "signal" into the search box to filter readings.
  3. Click the GRAPH button next to signal strength.
  4. Test out various locations for best signal strength, allowing 30 seconds for graph to update each move.
  5. If required the antenna for the GSM can be extended from inside the enclosure to a better external location, again using the graph to obtain the optimum position..


Hcon15.PNG


Hcon16.PNG


Hcon17.PNG


Changing SIM APN

The following commands need to be sent to the modem:

AT+CGDCONT=1,"IPV4V6","<your_apn>"
AT+CGDCONT=6,"IPV4V6","<your_apn>"
AT+CGAUTH=1,1,”<apn_user>”,”<apn_password>”
AT+CFUN=0
AT+CFUN=1


Custom Values & Metadata

The Heatweb controller includes spreadsheet functionality to assist in managing data and editing JSON data files.

The key system spreadsheet is the Custom Values sheet, providing the facility to edit the list of custom control point values (metadata) that are posted at startup, at regular intervals. These will typically include values unique to the installation, such as location details and any commissioning values that need to be known on a controls level (Note there is a separate editable notes function).


Cvsheet.PNG


Data follows the standard heat network open-protocol using 5 topic levels:

 network_id / node_id / device_id / data_group / key = value


The node_id refers to the network device (typically running Node-RED) that is posting the data and will be automatically added to posts.

See Heat Network Protocol for a more comprehensive description or the protocol - keys already exist for most related data.

The following table explains the sheet columns:

Level Description.
Network A unique identifier for the heat network. Generally left blank to use system network id.
Device A network unique identifier for the connected device (e.g. HIU serial number) or sub-system (e.g. phex1) . If left blank the Node ID will be assumed.
Data Group The type of data. This is used for basic grouping, and for controlling data access (e.g. settings).. If left blank, the dat group (headline data) is assumed.
Key An identifier for the data field. REQUIRED.
Value The data..
Units Units for the data..
Title A description of the data point..

For individual HIUs, this sheet would typically be used to record the plot, the address, design setpoints, and property characteristics that may be useful in qualifying data, such as occupancy and floor area.

Data can be exported from the spreadsheet to a csv file, and data can be pasted from standard spreadsheet software into the sheet.

Screen Styling

Hcon21.PNG

The touchscreen user interface can be customised in a number of ways, including colour schemes, fonts, and background images.

A Light and a Dark style are available as starting points, with options provided to change the styling of individual element types.

Hcon26a.PNG


Hcon2.PNG Hcon20.PNG


DATA Storage

The Heatweb controllers can store data in various ways:

  • In volatile memory (RAM)
  • On an SD card or a USB storage device
  • To a remote database using any number of database nodes or standard methods (e.g. MQTT, MySQL or Dropbox)
  • To an instance of Heatweb running in the Cloud - this is the normal method of providing off-site access to all data and avoids overuse of SIM card data
  • Custom connections (e.g. to the Energy Saving Trust EMBED database or the SAP PCDB)
  • To the Inter-Planetary File System (IPFS) - this is peer-to-peer persistent storage system ideal for publishing persistent publicly accessible data

Generally, for operational purposes, long term data storage is only required on a few summary performance related data points. High resolution data on, for example, tap use, is only really useful in fault finding and it is possible to store approximately a week of data on all control points in RAM, providing a rolling storage of recent history.

Each data point is assigned a maximum number of points in memory, between 50 and 5000 typically.

Additional measures are taken to compress data and stretch the history. At regular intervals the system scans data points in memory and removes unnecessary points. With this method it is possible to keep up to a week of effectively high resolution 1s data in memory using far fewer data points. The logic can be customised to increase or decrease the filtering effect.

The graphs below show how over 1 week of data is held in memory, however resolution on data is maintained. The four values we are most interested in for radiator optimisation are the stat demand, setpoint temperature, return temperature and power. These are given more data points allowance so hold a longer history.

CHMOD18.PNG


CHMOD17.PNG CHMOD19.PNG

NTC Charts and Sensor Calibration

NTC calibration values are stored in Node-RED template nodes.

Nrntc.PNG


The contents of the template is a CSV formatted list of temperatures and resistance values.

Editntc1.PNG


The node editor allows you to enter notes, such as a link to the online sensor datasheets where data comes from.

Editntc2.PNG