Difference between revisions of "Open Control Architecture"

From Open Source Controls Wiki
Jump to navigation Jump to search
Line 60: Line 60:
*'''''set''''' (change a setting)
*'''''set''''' (change a setting)
*'''''system''''' (software and networking) }}
*'''''system''''' (software and networking) }}
{| class="wikitable"
!Group
!Description
|-
|dat
|General data from sensors and equipment
|-
|stat
|Statistical, summary and calculated data, as well as general information (that may change)
|-
|settings
|Equipment settings
|-
|set
|Command to adjust a persistent setting (remains after restart)
|-
|cmd
|Command to perform an action.
|-
|warning
|Warning (of a failure)
|-
|alarm
|Alarm (a failure e.g. equipment goes out of warranty terms)
|-
|system
|Data relating to communications
|-
|info
|Information that cannot change (not implemented yet, with ''stat'' been used as default)
Argument to move serial numbers, manufacturers and models to ''info''
|-
|pcdb
|PCDB formatted data
|}
{{Block | Attributes for data may be loaded from a central index (GitHub hosted), providing additional information such as units and descriptions.  This is to avoid the need to locally describe data, and to assist in compatibility. }}{{Block | Within Node-RED, data and attributes are stored within the '''''global.readings''''' object.  
{{Block | Attributes for data may be loaded from a central index (GitHub hosted), providing additional information such as units and descriptions.  This is to avoid the need to locally describe data, and to assist in compatibility. }}{{Block | Within Node-RED, data and attributes are stored within the '''''global.readings''''' object.  



Revision as of 23:27, 4 June 2022

Controls software is written in Node-RED.
Software works through packets of data (messages) passing along virtual (and real) wires, from one node to another.

A node can be:

  • a function block within Node-RED
  • an instance of Node-RED
  • any point (server or device) in the communications network
Topology6a.png
Each instance of Node-RED has an identifier, stored under global.node
Communications between systems is performed using MQTT using a standardised 5 level topic structure. network / node / device / group / key.
Bmscoms1.png



Systems run a local MQTT broker to distribute data both internally and to enable external subscriptions.
The external network identifier, used for all data published to external MQTT brokers, is stored under global.networkId
In the real world, devices and networks are nested - a building may have a network ID, but this may be fed from a plantroom, also with its own identity. To accommodate nested networks, a dash is used to prefix topics (and hence the network ID) as they pass through to a Cloud Server.
myNetwork/plantroomNode/plantroomNode/system/title= "Main Plantroom Controller"
block1/blk1node/blk1node/system/title= "Block 1 Controller"

Adding a prefix to sub-networks ensures networks remain unique on a higher level server. E.g. There may be two unconnected networks with sub-networks called "block1".

myNetwork-block1/blk1node/blk1node/system/title= "Block 1 Controller"
anotherNetwork-block1/blk1node/blk1node/system/title= "Block 1 Controller"
Data from within a node or from connected devices is assigned a local network identifier of "local" (stored under global.localNetworkId) so that the node's external network identifier can be changed without affecting internal software. Separate internal and external identifiers also allows for separate message rates, where local traffic can be high speed. Node-RED is used to apply Reporting By Exception rules, to limit traffic to significant values (e.g. 0.25C), and save bandwidth.


Mqtt6a1.png Handler0.png


Within Node-RED a Message Handler Node is used to handle data generated locally.
Handleroptions.png
  • The Node has two outputs - one for local traffic, and one for external traffic.
  • Report by exception rules are applied to external traffic.
  • The Node formats topics to the five level standard, adding group and device if missing.
  • The Node stores data into global.readings, along with any attributes within the incoming message, as well as timestamps.
  • Additional routing can be performed within Node-RED, including selection of retained vs fire & forget routes.
Handler1.png


Where a number of nodes sit on a Local Area Network (LAN) it is common to use a central local MQTT broker.
Mqtt6a.png
Handler3.png
Traffic can be routed to a Cloud MQTT broker by the use of MQTT Bridges. These run on an MQTT broker, and can re-publish messages filtered by topic (networkId) to another broker. Bridges are managed outside of Node-RED.
Handler7.png
Additional Report By Exception rules can be applied inline.
Handler5.png
On larger networks where data is shared between local nodes, Reporting By Exception can be centrally managed using a Node-RED instance, along with any additional MQTT broker functions such as providing backup routes.
Mqtt6a2.png
Handler6.png
Handler4.png
Cloud based instances of Node-RED, as used on this Wiki, are often used to pull together data from various MQTT brokers into one place.
Handlercloud.png
The topic group is used to define the type of data. Values include:
  • dat (operational data)
  • stat (statistics and status)
  • settings
  • cmd (a command)
  • set (change a setting)
  • system (software and networking)
Group Description
dat General data from sensors and equipment
stat Statistical, summary and calculated data, as well as general information (that may change)
settings Equipment settings
set Command to adjust a persistent setting (remains after restart)
cmd Command to perform an action.
warning Warning (of a failure)
alarm Alarm (a failure e.g. equipment goes out of warranty terms)
system Data relating to communications
info Information that cannot change (not implemented yet, with stat been used as default)

Argument to move serial numbers, manufacturers and models to info

pcdb PCDB formatted data
Attributes for data may be loaded from a central index (GitHub hosted), providing additional information such as units and descriptions. This is to avoid the need to locally describe data, and to assist in compatibility.
Within Node-RED, data and attributes are stored within the global.readings object.

The current data can be viewed in the data explorer.

Readings1.png

Historic data is saved into the global.readingsHistory object, in the same structure as global.readings, but containing an array of timestamped values.
Persistent settings for a node (or application) are held on disk and in the global.settings object. This is for local operational settings.

Settings have a type, may have maximum and minimum values, units and a title. Certain types require additional fields such as select from a list settings.

The snapshot below shows a variety of setting types including numeric/text values, html, or JSON objects and arrays.

Settings3.png

Persistent settings for local devices are held on disk and in the global.deviceSettings object, and are specific to a device (or node).
Data within the readings object is nested according to the topic (excluding the node as more than one node may publish data on a device).
e.g. a message with a topic myNetwork/node123/myDevice/dat/outputTemperature  would be stored in (global).readings.myNetwork.myDevice.dat.outputTemperature.value

Internally, message topics can be truncated and the network and node will be filled in. The data group will be assumed to be "dat" if not supplied, representing operational data.

e.g. a message with a topic setpoint  would be stored in (global).readings.local.myNode.dat.setpoint.value


The following code could be used to read data and its attributes for output.

 var localNetworkId = global.get("localNetworkId");
 var node = global.get("node");

 var reading = global.get("readings." + localNetworkId + "." + node + ".dat.outputTemperature");

 var output = "The value of " + reading.title + " is " + reading.value + reading.units;  
 // "The value of Output Temperature is 35°C