# node-red-contrib-gps4net

## Description

This repository contains custom Node-RED nodes for GPS4NET, designed to manage the G4NRHT family of temperature and humidity sensors. These nodes facilitate communication over the CAN-BUS.

The nodes **g4nrht-decode** and **g4nrht-encode** are responsible for these communication aspects. They translate the interactions into usable Node-RED messages that can be used for monitoring or configuring networks of sensors.

The node **g4nrht-dashboard** provides a GUI interface for browsers. It leverages the **g4nrht-decode** and **g4nrht-encode** nodes to configure the network of sensors connected to it.

## Dependencies

No dependencies are required to install these nodes. However, for these nodes to function, a working CAN-BUS connection must be provided via any transport protocol (e.g., MQTT).

## Dependencies

There are no dependencies needed for installing these nodes.
However for the functioning of these nodes there must be a working CAN-BUS connection provided via any transport protocol (MQTT etc).

### Installation & Configuration

To install the nodes and use the provided examples, you can install them via the Manage Palette -> Install (tab) -> Search for "gps4net" and click "install".

![Installatin via pallete](/images/install.png)
Alternatively, you can install by running the following command in your terminal:

```
npm install node-red-contrib-gps4net
```

## Usage for g4nrht-decode and g4nrht encode nodes

Examples are provided with the import function to help you get started.

Usually, the two nodes are used together. The **g4nrht-decode** function is responsible for translating (decoding) CAN frames to higher-level data, such as messages with a topic and payload that can be used in any Node-RED flow.

The **g4nrht-encode** does the opposite, receiving high-level messages tailored for the RHT sensors and translating them into CAN frames to be used for configuring the temperature and humidity sensors.

**g4nrht-decode** is a node that decodes CAN frames from G4NRHT temperature and humidity sensors to higher-level data.

![Adding example flows](/images/import_examples.png)

The provided example flow gives a working example that must be connected to a CAN-BUS network, either directly or via any other transmission protocol that transports the CAN frames, such as MQTT.

![Example of the flow](/images/decode_example.png)

In this example, we have removed the links for in and out CAN-BUS communication with socketcan connections, but these can be easily substituted for MQTT connections or any other type.

![Example of the G4NRHT decode and encode nodes connected using socket can](/images/decode_socketcan_example.png)

When used together, these nodes can extract meaningful real-time data that can be parsed, graphed, stored, and tailored to any use case. To support this, the **g4nrht-decode** node has rules that can be applied to parse its output to a specific payload if we are only interested in a few parameters. The rules can sort by PSN (product serial number) if one is specified, or can apply filter rules to all sensors as described below. The outputs will be generated as you create new rules so that you can directly use the filtered message.

![Example of rht-decode rules](/images/decode_settings_rules.png)

## Usage of the g4nrht-dashboard

The **g4nrht-dashboard** has a fully functioning GUI dashboard implemented that uses the **g4nrht** encode and decode nodes as its inputs and outputs. Its example can be imported in the same way as described above, and the comments will guide you in linking the two flows together.

![Image of the g4nrht-dashboard node](/images/dashboard_flow.png)

The node exposes all the available configuration functionality of a **g4nrht sensor** and is ready to use as soon as it is linked to the **g4nrht example** provided. The GUI is built with native Node-RED GUI components that can be changed with any tailored solution as long as the topic conditions described in the outputs/input section are met. The node comes with an HTML template as a color theme that can be customized according to your needs.

![Image of the dashboard deployed on local host](/images/dashboard_configuration_ui.png)

-   The core functionality relies on querying (reading) the configuration of a sensor and writing it (programing it). The dashboard simplifies this process and provides a graphical interface.

-   **Refresh** the node will place the devices on the network in programming node and listen to their messages. This shall trigger the psn list to be built. A graphical
    After a shor while 30-40sec the device enumeration should be complete. The sensors will be commanded to exit programming mode after 5 minutes of innactivity.
    -   While reading the list / in programming mode a spinner will be displayed at the right of the button.
-   **Query device** selecting the desired PSN and quering (reading the device), the node will trigger a enter programming mode and wait for the selected device to answer. After the device has responded succesfully it will send query messages to the **g4nrht-encode** that will be translated into can frames and interpret the answers it receives from **g4nrht-decode**, it shall do so until all the configuration parameters are queried. Then it will exit programming mode.
    -   While querying a spinner will apear near the refresh button (signifing the network is in programming mode) and near the selected PSN.
-   **Program device** After the parameters have been read, the user can then change them and press the program device button a enter programming mode will be sent via the encode node and after the sensor responds that it is in programming mode a sequence of programming messages will be sent with confirmation. After each programming step is confirmed the sensors will be transmitted exit programming mode can frame.
    -   While programming a spinner will apear near the refresh button (signifing the network is in programming mode) and near the selected PSN.
-   The exact composing of messages and their topics is described in the inputs/outputs of the **g4nrht-dashboard** section.

## **g4nrht-decode**

### Inputs

-   CAN frame

    payload object

    The input is in the form of a JSON object in **socketcan** format, with the following content:

    ```
    {
        timestamp: 1680699437931,
        ext: true,
        canid: 0x18ff8100,
        dlc: 8,
        rtr: false,
        data: [2,1,0,7,116,96,51,88]
    }
    ```

    -   **canid** - The standard or extended CAN id.
    -   **ext** - Set to true if this is a extended id frame. False otherwise.
    -   **rtr** - Specifies a remote transmission request frame if set to true.
    -   **dlc** - Number of databytes.
    -   **data** - An array with data or null or an empty array if no data.
    -   **timestamp** - Relative timestamp in microseconds

### Outputs

#### Rules

Each rule is a composite filter that sets up an additional output and has two settings:

1.  **PSN** - The sensor's PSN or `FFFFFFFF` for any of the sensors
2.  **Metric** - The metric that one wants on the output: temperature, humidity, I/O voltage values for the different scenarios: instantaneous samples, average values, alarm values when a temperature, humidity or I/O alarm is triggered. By default the metric is set up to output full message objects.

-   Full message

    payload object | number

    by default the node translates and outputs every message that is given on the output in a JSON object with the following keys:

    -   **psn** - The sensor's PSN (product serial number), 4 byte hex string.
    -   **type** - The message type, string.
    -   **epoch** - The UNIX epoch of the message, integer.

    Additional keys will also be present depending on message type, described in the **Unsolicited messages** and **Command messages** sections. If any other metric than _Full message_ is selected, the payload will contain an integer or a floating pint number representing the selected metric's value. The _dew point_ metric os computed based on the temperature and humidity.

    topic string

    the message topic is uses the following format:

    -   `PSN` if the output is configured to supply the full message.
    -   `PSN/metric` if the output is configured to supply a temperature, humidity or I/O voltage value.

#### Unsolicited messages

These messages are sent by sensors operating in reporting mode at configured intervals or when certain events take place, for instance when an alarm triggers or when the sensor network is placed in a different operating mode. Additional fields specific to each of the unsolicited message types are detailed below.

##### insth

Instantaneous temperature and humidity message

-   **ins_temp** - The instantaneous temperature in °C.
-   **ins_rh** - The instantaneous relative humidity in %.

##### avrth

Average temperature and humidity message

-   **avg_temp** - The average temperature in °C.
-   **avg_rh** - The average relative humidity in %.

##### insio

Instantaneous analog input voltage message

-   **ins_io1** - The instantaneous voltage on the sensor's IO1 port in V.
-   **ins_io2** - The instantaneous voltage on the sensor's IO2 port in V.

##### almt

Temperature alarm message

-   **action** - Event type, integer.

    -   16 - temperature over maximum threshold
    -   17 - temperature under maximum threshold
    -   18 - temperature under minimum threshold
    -   19 - temperature over minimum threshold

-   **alm_temp** - The temperature in °C upon triggering an alarm, float.
-   **max_temp_th** - Maximum temperature threshold in °C, float.
-   **min_temp_th** - Minimum temperature threshold in °C, float.

##### almh

Relative humidity alarm message

-   **action** - Event type, integer.

    -   32 - humidity over maximum threshold
    -   33 - humidity under maximum threshold
    -   34 - humidity under minimum threshold
    -   35 - humidity over minimum threshold

-   **alm_rh** - The relative humidity in % upon triggering an alarm, float.
-   **max_rh_th** - Maximum relative humidity threshold in %, float.
-   **min_rh_th** - Minimum relative humidity threshold in %, float.

##### almio

Analog input voltage alarm message

-   **action** - Event type, integer.

    -   48 - IO1 voltage over maximum threshold
    -   49 - IO1 voltage under maximum threshold
    -   50 - IO1 voltage under minimum threshold
    -   51 - IO1 voltage over minimum threshold
    -   52 - IO2 voltage over maximum threshold
    -   53 - IO2 voltage under maximum threshold
    -   54 - IO2 voltage under minimum threshold
    -   55 - IO2 voltage over minimum threshold

-   **alm_io1** - The IO1 voltage in V upon triggering an alarm, integer.
-   **alm_io2** - The IO2 voltage in V upon triggering an alarm, integer.
-   **max_io1_th** - Maximum IO1 voltage threshold in V, integer.
-   **min_io1_th** - Minimum IO1 voltage threshold in V, integer.
-   **max_io2_th** - Maximum IO2 voltage threshold in V, integer.
-   **min_io2_th** - Minimum IO2 voltage threshold in V, integer.

##### sysevn

System events message

-   **action** - Event type, integer.

    -   64 - reset or power on event detected
    -   65 - programming mode enabled
    -   66 - programming mode disabled
    -   67 - maintenance mode enabled
    -   68 - maintenance mode disabled

-   **sys_cnf** - System configuration, integer. Options listed below:

    -   snsr_ena - sensor enabled
    -   io1_mntc - assign IO1 as input for enabling maintenance mode using an external switch
    -   io2_mntc - assign IO2 as input for enabling maintenance mode using an external switch
    -   avg_val_evt - use average temperature and humidity values for alarm event detection
    -   temp_c_bcd - sensor temperature format is °C; in BCD
    -   temp_k_bin - sensor temperature format is K x100 in binary

-   **alm_cnf** - Alarm configuration, integer. Options listed below:

    -   led_temp_alm - enable LED blink when the temperature alarm is triggered
    -   led_rh_alm - enable LED blink when the humidity alarm is triggered
    -   led_io_alm - enable LED blink when the IO alarms is triggered
    -   io_temp_alm - temperature events trigger the alarm's assigned IO
    -   io_rh_alm - humidity events trigger the alarm's assigned IO
    -   io_io_alm - IO events trigger the alarm's assigned IO

-   **io_fltr** - Time interval in seconds for the IO voltage hold timer, float.

##### sysstat

System status message

-   **sys_stat** - System status, integer. Options listed below:
    -   ovr_max_temp_th - over maximum temperature threshold
    -   und_min_temp_th - under minumum temperature threshold
    -   ovr_max_rh_th - over maximum humidity threshold
    -   und_min_rh_th - under minumum humidity threshold
    -   ovr_max_io1_th - over maximum IO1 voltage threshold
    -   und_min_io1_th - under minumum IO1 voltage threshold
    -   ovr_max_io2_th - over maximum IO2 voltage threshold
    -   und_min_io2_th - under minumum IO2 voltage threshold
    -   snsr_act - sensor is active
    -   alm_ind_led - the alarm condition is indicated by the LED, as indicated by the **alm_cnf** parameter
    -   heat_act - the sensor's built-in heater is active
    -   alm_ind_io - the alarm condition is indicated by an assigned IO, as indicated by the **alm_cnf** parameter
    -   snsr_mtnc - sensor operating in maintenance mode
    -   snsr_prog - sensor operating in programming mode

#### Command messages

These messages are sent to place the sensor network in programming mode or in reporting mode. When the network is operating in programming mode, command messages are sent to query or program the different parameters for each sensor. While operating in programming mode, each sensor also broadcasts unsolicited **prog** messages with a particular action field. Additional fields specific to each of the command message types are detailed below.

##### prog

Programming messages. The sensors network needs to be operating in programming mode in order to respond to command messages.

-   **action** - Action type, integer.
    -   0 - wku: enable programming mode
    -   1 - slp: disable programming mode
    -   240 - keepalive: sent every 250 ms by the first sensor that received the wku command
    -   241 - imalive: sent every 250 ms by each sensor that is operating in programming mode

##### sysset

System configuration messages. See the **sysevn** message above for details about the **sys_cnf** and **alm_cnf** options. To change any of those options using action type 2, one needs to supply the message type and the **sys_cnf**, **alm_cnf** and **io_fltr** in addition to the modified option.

-   **action** - Action type, integer.

    -   0 - query parameters
    -   1 - query response
    -   2 - program parameters
    -   3 - programming confirmation

-   **sys_cnf** - System configuration, integer.
-   **alm_cnf** - Alarm configuration, integer.
-   **io_fltr** - Time interval in seconds for the IO voltage hold timer, float.

##### tmpcal

Temperature calibration offset messages. Programming this parameter will add the value of the calibration offset to the reported temperature. Be aware that the relative humidity and dew point calculations are also negatively impacted by programming a non zero value.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   1 - query response
    -   2 - program parameter
    -   3 - programming confirmation

-   **temp_cal_ofst** - Temperature calibration offset in °C, float -327.68..+327.67

##### instset

Broadcast and sampling interval for the instantaneous temperature and humidity message **insth**.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   1 - query response
    -   2 - program parameter
    -   3 - programming confirmation

-   **ins_int** - sampling interval in seconds, integer 0..16383.75

##### avrset

Broadcast and averaging interval for the average temperature and humidity message **avrth**.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   1 - query response
    -   2 - program parameter
    -   3 - programming confirmation

-   **avg_int** - averaging interval in seconds, integer 0..655350

##### almtsetmax

Maximum temperature threshold for triggering the **almt** alarm event messages.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   1 - query response
    -   2 - program parameter
    -   3 - programming confirmation

-   **max_temp_th** - maximum temperature threshold in °C/K, float -273.15..382.2

##### almtsetmin

Minimum temperature threshold for triggering the **almt** alarm event messages.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   1 - query response
    -   2 - program parameter
    -   3 - programming confirmation

-   **min_temp_th** - minimum temperature threshold in °C/K, float -273.15..382.2

##### almhsetmax

Maximum relative humidity threshold for triggering the **almh** alarm event messages.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   1 - query response
    -   2 - program parameter
    -   3 - programming confirmation

-   **max_rh** - maximum humidity threshold in %, float 0..100

##### almhsetmin

Minimum relative humidity threshold for triggering the **almh** alarm event messages.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   1 - query response
    -   2 - program parameter
    -   3 - programming confirmation

-   **min_rh** - minimum humidity threshold in %, float 0..100

##### almio1set

Maximum and minimum voltage thresholds for triggering the **alm_io1** alarm event messages.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   1 - query response
    -   2 - program parameter
    -   3 - programming confirmation

-   **max_io1_th** - maximum voltage threshold on IO1 in V, integer 0..99
-   **min_io1_th** - maximum voltage threshold on IO1 in V, integer 0..99

##### almio2set

Maximum and minimum voltage thresholds for triggering the **alm_io2** alarm event messages.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   1 - query response
    -   2 - program parameter
    -   3 - programming confirmation

-   **max_io2_th** - maximum voltage threshold on IO2 in V, integer 0..99
-   **min_io2_th** - maximum voltage threshold on IO2 in V, integer 0..99

##### sensorcure

Sensor curing messages. Activates the sensor's heating element.

-   **action** - Action type, integer.

    -   2 - program parameter
    -   3 - programming confirmation

-   **heat_intst** - heater intensity, integer 0..15

##### maintset

Maintenance mode triggering voltage threshold.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   1 - query response
    -   2 - program parameter
    -   3 - programming confirmation

-   **max_mntc** - maximum voltage for triggering maintenance mode in V, integer 0..99
-   **min_mntc** - minimum voltage for triggering maintenance mode in V, integer 0..99

## g4nrht-encode

**g4nrht-encode** is a node that encodes CAN frames for G4NRHT temperature and humidity sensors.

### Inputs

-   Message

    payload object

    by default the node translates and outputs every message that is given on the output in a JSON object with the following keys:

    -   **psn** - The sensor's PSN (product serial number), 4 byte hex string.
    -   **type** - The message type, string.

    Additional keys for programming parameters should also be present depending on message type. These are described in the **Command messages** section.

#### Command messages

These messages are sent to place the sensor network in programming mode or in reporting mode. When the network is operating in programming mode, command messages are sent to query or program the different parameters for each sensor. While operating in programming mode, each sensor also broadcasts unsolicited **prog** messages with a particular action field. Additional fields specific to each of the command message types are detailed below.

##### prog

Programming messages. The sensors network needs to be operating in programming mode in order to respond to command messages.

-   **action** - Action type, integer.
    -   0 - wku: enable programming mode
    -   1 - slp: disable programming mode

##### sysset

System configuration messages. To change any of those options using action type 2, one needs to supply the message type and the **sys_cnf**, **alm_cnf** and **io_fltr** in addition to the modified option.

-   **action** - Action type, integer.

    -   0 - query parameters
    -   2 - program parameters

-   **sys_cnf** - System configuration, integer. Options listed below:

    -   snsr_ena - sensor enabled
    -   io1_mntc - assign IO1 as input for enabling maintenance mode using an external switch
    -   io2_mntc - assign IO2 as input for enabling maintenance mode using an external switch
    -   avg_val_evt - use average temperature and humidity values for alarm event detection
    -   temp_c_bcd - sensor temperature format is °C in BCD
    -   temp_k_bin - sensor temperature format is K x100 in binary

-   **alm_cnf** - Alarm configuration, integer. Options listed below:

    -   led_temp_alm - enable LED blink when the temperature alarm is triggered
    -   led_rh_alm - enable LED blink when the humidity alarm is triggered
    -   led_io_alm - enable LED blink when the IO alarms is triggered
    -   io_temp_alm - temperature events trigger the alarm's assigned IO
    -   io_rh_alm - humidity events trigger the alarm's assigned IO
    -   io_io_alm - IO events trigger the alarm's assigned IO

-   **io_fltr** - Time interval in seconds for the IO voltage hold timer, float.

##### tmpcal

Temperature calibration offset messages. Programming this parameter will add the value of the calibration offset to the reported temperature. Be aware that the relative humidity and dew point calculations are also negatively impacted by programming a non zero value.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   2 - program parameter

-   **temp_cal_ofst** - Temperature calibration offset in °C, float -327.68..+327.67

##### instset

Broadcast and sampling interval for the instantaneous temperature and humidity message **insth**.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   2 - program parameter

-   **ins_int** - sampling interval in seconds, integer 0..16383.75

##### avrset

Broadcast and averaging interval for the average temperature and humidity message **avrth**.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   2 - program parameter

-   **avg_int** - averaging interval in seconds, integer 0..655350

##### almtsetmax

Maximum temperature threshold for triggering the **almt** alarm event messages.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   2 - program parameter

-   **max_temp_th** - maximum temperature threshold in °C/K, float -273.15..382.2

##### almtsetmin

Minimum temperature threshold for triggering the **almt** alarm event messages.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   2 - program parameter

-   **min_temp_th** - minimum temperature threshold in °C/K, float -273.15..382.2

##### almhsetmax

Maximum relative humidity threshold for triggering the **almh** alarm event messages.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   2 - program parameter

-   **max_rh** - maximum humidity threshold in %, float 0..100

##### almhsetmin

Minimum relative humidity threshold for triggering the **almh** alarm event messages.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   2 - program parameter

-   **min_rh** - minimum humidity threshold in %, float 0..100

##### almio1set

Maximum and minimum voltage thresholds for triggering the **alm_io1** alarm event messages.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   2 - program parameter

-   **max_io1_th** - maximum voltage threshold on IO1 in V, integer 0..99
-   **min_io1_th** - maximum voltage threshold on IO1 in V, integer 0..99

##### almio2set

Maximum and minimum voltage thresholds for triggering the **alm_io2** alarm event messages.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   2 - program parameter

-   **max_io2_th** - maximum voltage threshold on IO2 in V, integer 0..99
-   **min_io2_th** - maximum voltage threshold on IO2 in V, integer 0..99

##### sensorcure

Sensor curing messages. Activates the sensor's heating element.

-   **action** - Action type, integer.

    -   2 - program parameter

-   **heat_intst** - heater intensity, integer 0..15

##### maintset

Maintenance mode triggering voltage threshold.

-   **action** - Action type, integer.

    -   0 - query parameter
    -   2 - program parameter

-   **max_mntc** - maximum voltage for triggering maintenance mode in V, integer 0..99
-   **min_mntc** - minimum voltage for triggering maintenance mode in V, integer 0..99

### Outputs

-   CAN frame

    payload object

    The output of this module in the form of a JSON object in **socketcan** format, with the following content:

    ```
    {
        timestamp: 1680699437931,
        ext: true,
        canid: 0x18ff8100,
        dlc: 8,
        rtr: false,
        data: [2,1,0,7,116,96,51,88]
    }
    ```

    -   **canid** - The standard or extended CAN id.
    -   **ext** - Set to true if this is a extended id frame. False otherwise.
    -   **rtr** - Specifies a remote transmission request frame if set to true.
    -   **dlc** - Number of databytes.
    -   **data** - An array with data or null or an empty array if no data.
    -   **timestamp** - Relative timestamp in microseconds

## g4nrht-dashboard

**g4nrht-dashboard** takes the data provided by the decode node and allows the reading and programming of a connected temperature and humidity sensor using a simple dashboard.

The dashboard node is design to operate by reading existing parameters of a specific sensor identified by PSN and then writing parameters to that specific sensor.

### Inputs

The input node has a dual role. First role is to receive the messages coming from the g4nrht-decode node. The messages received from the decode node follow the JSON object comprised from a payload with different values and a topic.

Incoming messages take the form of a JSON object with the following keys:
**payload**:

-   Message

    payload object

    Input message payload takes the form of a JSON object with the following keys:

    -   **psn** - The sensor's PSN (product serial number), 4 byte hex string.
    -   **canid** - The sample's CAN ID, optional.
    -   **epoch** - The sample's epoch time, 4 byte integer.
    -   **type** - The message type, string.

Additional keys for parameters will also be present depending on message type as described in g4nrht-decode. These are described in the **g4nrht-decode** node.

The second role is to receive the messages from the GUI elements (or simple messages injected by user) and act accordingly by triggering sequences of messages sent to the encode node.
The messages have a structure that follows these rules:

-   **Message**

    -   **topic** - Incoming messages will have a topic reflecting the ui element control type usually a string type.
    -   **payload** - will usually contain only the numeric or boolean value corresponding to the topic

### Outputs

The output of the first output is connected to the **g4nrht-encode** and sends the messages needed to comunicate/program with the sensors. The other outputs serve a simple message structure to generic gui elements.While the generic gui elements do not require a topic to receive data and display it they do require they send data with a topic so they may be recognised from other messages using the input node.

-   **Message**

    payload object

    Output message payload takes the form of a JSON object with the following keys:

    -   **psn** - The sensor's PSN (product serial number), 4 byte hex string.
    -   **canid** - The sample's CAN ID, optional.
    -   **epoch** - The sample's epoch time, 4 byte integer.
    -   **type** - The message type, string.

Additional keys for parameters will also be present depending on message type as described in **g4nrht-decode**.

```
{
    topic: "sensor_enable",
    payload: true|false
}
```

### Topics and command sequences triggered by GUI elements

The name of topics is described below, along with the action sequence it triggers.

```
{
    topic: "refresh",
    payload: true|false
}
```

Using a boolean value of `true` or `false` shall trigger a search of sensor PSNs on the CAN bus, shall clear all node variables, place the sensors in programming mode and wait for their response. After the dropdown is filled with sensor PSNs, it shall exit the programming mode.

```
{
    topic: "query_psn",
    payload: true|false
}
```

Using a boolean value of `true` or `false` shall trigger the query of a specific sensor, reading its configuration settings.

If the sensor in the CAN bus is not in programming mode, it shall be switched to programming mode. After the sensor's response, commands shall be sent to query its configuration. Finally, when the query sequence is complete the sensor will be switched back to reporting mode.

```
{
    topic: "begin_programming",
    payload: true|false
}
```

Using a boolean value of `true` or `false` shall trigger programming of a specific sensor using the settings displayed on the GUI.

If the sensor in the CAN bus is not in programming mode, it shall be switched to programming mode. After the sensor's response, commands shall be sent to query its configuration. Finally, when the query sequence is complete the sensor will be switched back to reporting mode.

```
{
    topic: "sensor_enable",
    payload: true|false
}
```

The `sensor_enable` message enables sensor reporting. This issues a message of the **sysset** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "maint_mode_io1",
    payload: true|false
}
```

If IO1 is triggered it will place the sensor into maintanence mode. This issues a message of the **sysset** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "maint_mode_io2",
    payload: true|false
}
```

If IO2 is triggered it will place the sensor into maintanence mode. This issues a message of the **sysset** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "instant_average_val",
    payload: true|false
}
```

Changes between instantaneous or average value reporting. This issues a message of the **sysset** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "kelvin_celsius_select",
    payload: true|false
}
```

Changes between Kelvin (default) or Celsius temperature reporting. False for celsius, true for Kelvin. This issues a message of the **sysset** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "temp_led_blink",
    payload: true|false
}
```

Toggles if the LED should blink when one of the temperature thresholds is exceeded. This issues a message of the **sysset** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "humidity_led_blink",
    payload: true|false
}
```

Toggles if the LED should blink when one of the humidity thresholds is exceeded. This issues a message of the **sysset** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "io_led_blink",
    payload: true|false
}
```

Toggles if the LED should blink when one of the I/O voltage thresholds is exceeded. This issues a message of the **sysset** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "temp_io_event",
    payload: true|false
}
```

Toggles if an I/O event is triggered when one of the temperature thresholds is exceeded. This issues a message of the **sysset** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "humidity_io_event",
    payload: true|false
}
```

Toggles if an I/O event is triggered when one of the humidity thresholds is exceeded. This issues a message of the **sysset** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "io_event_alarm",
    payload: true|false
}
```

Toggles if an I/O event is triggered when one of the I/O voltage thresholds is exceeded. This issues a message of the **sysset** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "io_filter",
    payload: numeric
}
```

The `io_filter` value (in seconds) is used to avoid false alarms. The voltage must hold the cross-limit value for a specified time interval defined by this parameter. This issues a message of the **sysset** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "temp_cal",
    payload: numeric
}
```

The `temp_cal` temperature calibration offset is always expressed in in °C/K regardless the bit set in the parameter. The default value is 0 as the sensor is factory calibrated. This issues a message of the **tmpcal** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "inst_threshold",
    payload: numeric
}
```

The `inst_threshold` parameter represents the sampling and transmission interval (in seconds) of the instantaneous temperature and humidity. This issues a message of the **instset** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "avg_threshold",
    payload: numeric
}
```

The `avg_threshold` represents the averaging and transmission interval (in seconds) of the average temperature and humidity. This issues a message of the **avrset** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "almt_set_max",
    payload: numeric
}
```

The `almt_set_max` parameter represents the maximum temperature threshold (in °C/K) used for triggering the alarm. This issues a message of the **almtsetmax** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "almt_set_min",
    payload: numeric
}
```

The `almt_set_min` parameter represents the minimum temperature threshold (in °C/K) used for triggering the alarm. This issues a message of the **almtsetmin** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "almh_set_max",
    payload: numeric
}
```

The `almh_set_max` parameter represents the maximum humidity threshold (in %) used for triggering the alarm.
This issues a message of the **almhsetmax** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "almh_set_min",
    payload: numeric
}
```

The `almh_set_min` parameter represents the minimum humidity threshold (in %) used for triggering the alarm.
This issues a message of the **almhsetmin** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "max_io1_th_threshold",
    payload: numeric
}
```

The `max_io1_th_threshold` parameter represents the maximum IO1 voltage threshold (in V) used for triggering the alarm. This issues a message of the **almio1set** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "min_io1_th_threshold",
    payload: numeric
}
```

The `min_io1_th_threshold` parameter represents the minimum IO1 voltage threshold (in V) used for triggering the alarm. This issues a message of the **almio1set** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "max_io2_th_threshold",
    payload: numeric
}
```

The `max_io2_th_threshold` parameter represents the maximum IO2 voltage threshold (in V) used for triggering the alarm. This issues a message of the **almio2set** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "min_io2_th_threshold",
    payload: numeric
}
```

The `min_io2_th_threshold` parameter represents the minimum IO2 voltage threshold (in V) used for triggering the alarm. This issues a message of the **almio2set** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "activate_sensor_cure",
    payload: true|false
}
```

This toggles a resistive element in the sensor that heats it in order to facilitate condensation evaporation o that it does not adversely influence humidity readings. This issues a message of the **sensorcure** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "trigger_spinner",
    payload: string
}
```

Using a string value of `working` or `done` it shall trigger the spinner element to indicate that an action is being performed on the sensor, such as a read or write operation.

```
{
    topic: "min_maintenance_interval",
    payload: numeric
}
```

The `min_maintenance_interval` represents the minimum voltage threshold value (in V) for triggering maintenance mode. This issues message of the **maintset** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "max_maintenance_interval",
    payload: numeric
}
```

The `min_maintenance_interval` represents the maximum voltage threshold value (in V) for triggering maintenance mode. This issues message of the **maintset** type, with its content as described in **g4nrht-decode**.

```
{
    topic: "sensor_cure_confirmation",
    payload: boolean
}
```

The `sensor_cure_confirmation` parameter indicates the if the sensor has entered curing mode. The sensor switch curing mode off by themselves after completion.

```
{
    topic: "sensor_maintenance_confirmation",
    payload: boolean
}
```

The `sensor_maintenance_confirmation` parameter indicates the if the sensor has entered mainenance mode.
No matter whch sensor is selected, all of the sensors on the CAN bus will enter maintenance mode.

```
{
    topic: "dropdown_list",
    payload: array
}
```

This control allows the querying or programming of a specific sensor, using an array of strings (detected sensor PSNs). This list is always generated at the start of the flow or by pressing the refresh button. The dashboard places the sensors on the CAN bus in programming mode and waits for their responses to add them to the list. It checks that no new PSN announces itself by waiting for each sensor to announce itself three times and then exits programming mode, allowing sensors to return to normal operation.

```
{
    topic: "query/programming mode ready confirmation", payload: true|false
}
```

This control indicates whether the selected sensor has entered programming mode.

```
{
    topic: "sensor id label confirmation",
    payload: string
}
```

This control displays the selected sensor's PSN.

```
{
    topic: "switch_programming_mode",
    payload: true|false
}
```

This control triggers programming mode manually. It's generally used for debuging purposes and not present in the example dashboard. This issues a message of the **prog** type, with its content as described in **g4nrht-decode**.

### Additional notes

The dashboard node works in conjunction with the **g4nrht-decode** and **g4nrht-encode** nodes, forming a system that allows for easy sensor configuration and monitoring.

Please refer to the respective nodes for more detailed information about their functions and how they interact with this node.

Ensure that your sensor and CAN bus are properly set up and functioning correctly before using this node.

Proper usage of this node and the programming functions it provides will ensure optimal performance of your sensor and network.
