Industrial Wireless RS485 Modbus Transmitter User Manual

Explore the Industrial Wireless RS485 Modbus Transmitter Capabilities

Device Overview

The NCD Industrial Wireless RS485 Modbus Transmitter (PR55-88F) transforms Modbus devices into seamless wireless nodes, enabling effortless integration into the NCD wireless network and eliminating the need for cumbersome wired connections. .

Instead of relying on a central gateway to constantly request data, the Industrial Wireless RS485 Modbus Transmitter operates as the “Master” of its own RS485 loop. It bridges the gap between legacy hardware and modern wireless networks by operating autonomously on a user-defined schedule.

  • Industrial Grade IoT Modbus RS485 To Wireless Converter
  • Works With VFD, PLC, SCADA systems
  • Works With HVAC Control Systems
  • Ideal For MODBUS-RTU Communication Over Wireless
  • Convert any RS485 Sensor/Device into a Wireless Sensor/Device
  • API communication over Wireless for Robust Reliability
  • Operating Temperature Range -40 to +85 °C
  • 5V-24VDC Input Voltage Range

Hardware Controls

RESET Button

The RESET (R) button will power cycle the sensor. When the sensor first powers up it will send a sensor_mode message with the mode of RUN.

CONFIGURATION Button

The CONFIGURATION (C) button serves two functions.

The first is change the mode of the sensor when pressed immediately after a power cycle of the sensor. See section Configuration Button Timing Overview for more information on this.

The second is to test for the presence of power on the sensor. If the CFG button is pressed the TEST LED on the board will light up indicating that the board has power. If no LED comes on check that the Power Switch is in the correct position and that the battery/power supply is good.

Click to Expand

Hardware Mode Selection

Run Mode

Run Mode is the default state of the sensor when powered up. No hardware interaction is necessary to enter this state other than power. Pressing the Reset (R) button will restart the sensor and put it in the RUN Mode state if no other buttons are pressed.

Configuration Mode

Configuration Mode is the state in which the sensor enters in order to change the sensor’s configurable parameters such as; Baud Rate, Stop bit, Modbus Function Code, Reporting Interval, Transmission Power, Network ID,etc.

You can enter in this mode manually by pressing and releasing the RESET button, device will enters RUN mode, then it will transmit sensor data and finally enters into configuration mode (sync mode). Sensor enters into configuration mode automatically every 1 hour.

This is a temporary mode that is not intended for long-term operation. device will returns automatically to Run mode after a successful configuration in order to resume normal operations.

Factory Default/Reset

A Factory Reset of the sensor will revert all changes and configurations made to the sensor to their default settings from the Factory. Immediately after a factory reset the sensor will go into Configuration Mode in order to be reconfigured with the desired settings.

You can perform a Factory Reset using the following sequence:
 
  • Press and release the RESET button
  • Wait for a second, then press and hold the CONFIGURATION button
  • Hold the CONFIGURATION button for about 20 seconds
  • Release the CONFIGURATION button
  • Wait for 3-5 seconds
  • Press and release the RESET button.

Default Factory Configuration

ParameterDefault ValueUnitNote
Baud Rate9600bps
Stop Bit1bit
Parity BitNone
RS485 Rx Timeout2000milliseconds
Bootup Time0 (Disabled)seconds
Slave ID (Address)1
Sub Device Type0
Number of Read Retries0
Read Parameter (FC)0x03 (Read Holding Register)It support:

Read Holding Register
Read Input Register
Read RegistersDisabledMax. 32 Registers
Modbus Register Address (1-32)0Max. 32 Registers

Software Integration - Node-Red Overview

We built our primary software drivers into a software system called Node-Red. Node-Red is a visual based drag-and-drop low/no code flow builder. It allows you to build simple or complex logic and data dissemination applications quickly and easily. It can integrate with third party software/cloud services using a number of protocols such as MQTT, HTTP(S), TCP, UDP, and OPC UA.

For more information and a general introduction on what Node-Red is and how it works you can view Node-Red’s official web site at https://nodered.org/.

All Enterprise Gateway we offer will come with Node-Red and our library running as a service by default to allow quick and easy access to Node-Red and the sensor data from our sensors. If you are using your own gateway or computer you will need a USB or Ethernet Modem, Node-Red, and our library @ncd-io/node-red-enterprise-sensors.

You can find our library on Node-Red with the name: @ncd-io/node-red-enterprise-sensors

In this section will will go over the nodes introduced by our library, what kind of data they will provide your flow, and how to use them.

Wireless Gateway Nodes

Wireless Gateway Nodes are a virtual representation of the wireless protocol connected to your Gateway. They will output all incoming data from the wireless network and all of the sensors on that network into the connected flows from a single entry point.

This is the recommended method for ingesting data from large numbers of sensors at a single location in order to simplify data handling and reduce the complexity of the resulting flow.

Wireless Gateway Node Statuses

Wireless Gateway nodes have multiple states they can show in Node-Red to indicate their current mode or functionality.

Wireless Gateway Ready State

When the Wireless Gateway Node’s status indicates “Ready”, as shown in the picture on the right, it means that the wireless network is successfully connected to Node-Red and is ready to receive data from the sensor(s). Sensors that support SYNC messages can be automatically configured while in this mode if a corresponding Wireless Device node is configured to do so. See section Sensor Configuration Processes for more information.

Wireless Gateway in the Ready State
Wireless Gateway Configuring State

When the Wireless Gateway Node’s status indicates “Configuring”, as shown in the picture on the right, it means that the wireless network is successfully connected to Node-red and is ready to configure any sensors entering Configuration Mode.

Any sensor put into configuration mode through the use of the Reset and CFG buttons will be seen by the gateway while in this mode. If Node-Red has a corresponding Wireless Device node for the sensor reporting in then Node-Red will begin configuring that sensor if set to do so. You can enter Config mode or leave Config mode to resume Normal Operations using the button on the left side of the node.

When the Wireless Gateway is in this mode the Wireless Network will change to the Configuration Network. This means that the network ID will change to 7BCD.

Wireless Gateway in Configuration Mode
Wireless Gateway Failed to Connect State

When the Wireless Gateway Node’s status indicates “Failed to Connect”, as shown in the picture on the right, it means that Node-Red was unable to connect to the wireless network. This usually indicates that incorrect settings were used while configuring the Gateway.

For more information on configuring your Wireless Gateway Node’s communications see section Wireless Gateway Node Configuration.

For more information on troubleshooting your Wireless Gateway Node’s communications see section Troubleshooting

Wireless Gateway node Failed to Connect State
Wireless Gateway Connecting State

When the Wireless Gateway Node’s status indicates “Connecting…”, as shown in the picture on the right, it means that Node-Red is waiting to initialize the connection to the Wireless Network. This state will last for 5 seconds before Node-Red attempts to open communication to ensure that all hardware and software is initialized.

No incoming or outgoing data will be handled while in this state.

Wireless Gateway Node Connecting State
Wireless Gateway No State

When the Wireless Gateway Node has no status indication, as shown in the picture on the right, it means that the node is not configured properly and no communications have been indicated for the node. For more information on configuring the Wireless Gateway Node see section Wireless Gateway Node Configuration.

Wireless Gateway Node Messages

All messages from the Wireless Gateway Node will come through as Javascript Objects and are output by default as JSON representations when viewed or sent over most protocols. In Node-Red the primary object to reference the message will be msg. You can access sub-properties using msg.payload or msg.payload.nodeId etc.

modem_mac Message

A modem_mac message indicates the unique address of the wireless module connected to the Wireless Gateway Node. This message is sent when Node-RED is deployed and when the Wireless Gateway is put into Configuration Mode or Ready Mode by using the embedded Wireless Gateway node button. An example modem_mac message can be found on the right.

  • topic
    • Indicates the type of message this is
  • payload
    • Contains the unique address of the wireless module on the Wireless Gateway Node
  • time
    • Timestamp of the message
				
					{
  "topic": "modem_mac",
  "payload": "00:13:A2:00:41:F5:2C:D3",
  "time": 1721424259706,
  "_msgid": "83ad39df1328dea7"
}
				
			
Wireless Gateway Processed Sensor Data Message

Sensor data is the primary message that will come from a Wireless Gateway Node. These messages can be discerned from other message types by the topic which will always be “sensor_data”

To the right is an example of a Sensor Data message.

  • nodeID
    • A user configurable parameter allowing a user to input a simple id for a particular sensor
    • For a unique identifier it is recommended to use the “addr” property as it is tied to the individual sensor’s wireless module and will always be unique
  • firmware
    • This identifies the firmware version of the sensor sending the packet
  • battery
    • The current voltage level of the batteries at the time of transmission
    • The batteries that come with the sensors drop off quickly once they reach 2.6 volts
  • battery_percent
    • The current battery percent at the time of transmission
  • counter
    • The number of transmissions since boot or counter rollover
    • The counter will rollover after a counter value of 255
  • sensor_type
    • The machine identifiable type of the sensor
    • It is recommended to use this property to dictate dashboard generation and/or data integrity checks
  • sensor_data
    • Object containing all sensor data related to this sensor
    • See section msg.payload.sensor_data Breakdown for more information
  • sensor_name
    • Human Readable Sensor Type Identifier
  • type
    • An easily passed message type declaration
    • This property will be a duplicate of msg.topic
  • addr
    • The unique identifier of the sensor that transmitted the data
  • received
    • Epoch indicator of when the data was received by Node-Red
  • original
    • Auxiliary information on the packet and underlying protocol
  • modem_mac
    • The unique identifier of the Gateway/Modem that received the data
    • Primarily used to tie locations/projects to sensors/sensor data
				
					{
  "topic": "sensor_data",
  "payload": {
    "nodeId": 0,
    "firmware": 7,
    "battery": "3.28",
    "battery_percent": "98.56",
    "counter": 26,
    "sensor_type": 539,
    "sensor_data": {
      "subdevice_type": 0,
      "number_of_registers": 0,
      "status_24_31": 0,
      "status_16_23": 0,
      "status_8_15": 0,
      "status_0_7": 0,
      "data": [
          0: 0,
          1: 0,
          2: 0,
          3: 0,
          4: 0,
          5: 0,
          6: 0,
          7: 0,
          9: 0,
          10: 0
          ...
       ]
    },
    "sensor_name": "RS-485 Modbus Wireless Converter",
    "type": "sensor_data",
    "addr": "00:13:a2:00:42:37:73:52",
    "received": 1721424191583,
    "original": {...},
    "modem_mac": "00:13:A2:00:41:F5:2C:D3"
  },
  "time": 1721424191584,
  "_msgid": "d7f3341ef39225df"
}
				
			
Wireless Gateway Processed Sensor Data Breakdown
  • sub_device_type
    • Byte to indicate what kind of User-defined Modbus RTU device it’s connected to.
  • number_of_registers
    • The number of registers read, up to a maximum of 32 registers in one operation.
  • status_0_to_31
    • Represents the status of the registry query: 0 indicates no error, while 1 indicates an error.
  • data
    • A variable-length array, it contains the value obtained from the Modbus-RTU registers as requested by the user.
Wireless Gateway RUN Message

A RUN message received simply indicates that the sensor indicated in the msg.payload.mac is powered up and communicating with the wireless network. An example RUN message can be found on the right.

  • topic
    • Indicates the type of message this is
  • payload
    • Contains the primary data of the message
  • payload.mac
    • Indicates the unique address of the sensor sending the mode message
  • payload.type
    • Indicates the type of sensor sending the mode message
  • payload.nodeId
    • A user configurable parameter allowing a user to input a simple id for a particular sensor
  • payload.mode
    • indicates the current mode of the sensor
  • payload.lastHeard
    • Timestamp of the message
				
					{
  "topic": "sensor_mode",
  "payload": {
    "mac": "00:13:a2:00:42:37:73:52",
    "type": 539,
    "nodeId": 0,
    "mode": "RUN",
    "lastHeard": 1721424191056
  },
  "time": 1721424191056,
  "_msgid": "f41dad7923ece27c"
}
				
			
Wireless Gateway PUM Message

A PUM message indicates that the sensor indicated in the msg.payload.mac has been factory reset. A PGM message will come from the sensor immediately after a PUM message is received so you can configure the factory reset sensor. Even if no configuration is triggered by the subsequent PGM message a reset of the sensor is required after factory reset to resume normal operation. An example PUM message can be found on the right.

  • topic
    • Indicates the type of message this is
  • payload
    • Contains the primary data of the message
  • payload.mac
    • Indicates the unique address of the sensor sending the mode message
  • payload.type
    • Indicates the type of sensor sending the mode message
  • payload.nodeId
    • A user configurable parameter allowing a user to input a simple id for a particular sensor
  • payload.mode
    • indicates the current mode of the sensor
  • payload.lastHeard
    • Timestamp of the message
				
					{
  "topic": "sensor_mode",
  "payload": {
    "mac": "00:13:a2:00:42:37:73:52",
    "type": 539,
    "nodeId": 0,
    "mode": "PUM",
    "lastHeard": 1721424191056
  },
  "time": 1721424191056,
  "_msgid": "f41dad7923ece27c"
}
				
			
Wireless Gateway Sync Check In Message

This sync_check_in message reports sensor information and allows for sync initialization if configuration changes are necessary.

A sync_check_in message indicates that the sensor is in RUN mode, but is entering a temporary state where it can be configured. The sensor will send the sync_check_in message on boot (after RUN and sensor_data messages) and once an hour after boot to check in. Once the sensor sends a sync_check_in message Node-RED has 2 seconds to respond with a configuration Master Command.

If Node-RED has a Wireless Device node with Mac Address, Auto Config and OTF Config selected corresponding to the sensor that sent the sync_check_in message then Node-RED will begin to configure that sensor.

An example sync check-in message can be found on the right.

  • topic
    • Indicates the message is a sync message
  • payload
    • Contains the primary data of the message
  • payload.type
    • Indicates the type of sync message.
  • payload.address
    • Indicates the unique address of the sensor sending the sync message
  •  payload.sensor_type
    • Indicates the type of sensor sending the mode message
  • payload.human_readable object
    • It contains the human readable data, display configuration set up on the sensor at the time of the sync transmission.
  • payload.human_readable.core_version
    •  
  • payload.human_readable.firmware_version
    • The actual firmware version running on device.
  • payload.human_readable.sensor_type
    • Displays the sensor type.
  • payload.human_readable.tx_lifetime_counter
    • Tracks the total number of data packets transmitted by the CPU since the device first booted
  • payload.human_readable.hardware_id
    • This value indicates the hardware version of the device
  • payload.human_readable.network_id
    • This value indicates the network Id configured on the device, by default all ncd devices uses 0x7FFF.
  • payload.human_readable.destination_address
    • Shows the current destination address configured on the sensor. The default setting is broadcast mode “00:00:FF:FF”
  • payload.human_readable.node_id
    • A user configurable parameter allowing a user to input a simple id for a particular sensor
  • payload.human_readable.report_rate
    • Specifies the data transmission interval in seconds.
  • payload.human_readable.register_to_read
    • Specifies the total number of registers to read on interval in the Register Reads field.
  • payload.human_readable.modbus_register_x
    • Specifies the Modbus Register Address (0-based offset) to read (1-32 Registers).
  • payload.human_readable.baud_rate
    • Specifies the baud rate value configured.
  • payload.human_readable.bootup_time
    • Specifies the delay interval (in seconds) that the transmitter waits after powering on the connected Modbus device before issuing the first command.
  • payload.human_readable.slave_address
    • Specifies the unique Slave Modbus device address (Slave ID) for the transmitter.
  • payload.human_readable.rs485_rx_timeout
    • Specifies the maximum time (in milliseconds) that the device will wait to receive a response from the RS485 field device via the serial port after it sends command.
  • payload.human_readable.sub_device_type
    • Specifies the user-defined byte used to identify the specific type of Modbus RTU device connected.
  • payload.human_readable.read_retries
    • Specifies the maximum number of attempts the device will make to perform a Modbus RTU register query.
  • payload.human_readable.modbus_command
    • Specifies the the Modbus Function Code configured.
  • payload.human_readable.parity_bit
    • Specifies the parity bit configured.
  • payload.human_readable.stop_bits
    • Specifies the stop bits configured.
  • payload.machine_values
    • The Raw data the sensor reports
  • description
    • Indicates information about the current sync message.
				
					{
  "topic": "sync",
  "payload": {
    "type": "sync_check_in",
    "address": "00:13:a2:00:42:35:89:86",
    "sensor_type": 536,
    "human_readable": {
      "core_version": 23,
      "firmware_version": 7,
      "sensor_type": 127,
      "tx_lifetime_counter": 13,
      "hardware_id": {
        "data": [ 99, 61, 0]
      },
     "network_id": "7fff",
     "destination_address": "0000ffff",
     "node_id": 0,
     "report_rate": 900,
     "register_to_read": "0",
     "modbus_register_1": 0,
     "modbus_register_2": 0,
     "modbus_register_3": 0,
     "modbus_register_4": 0,
     "modbus_register_5": 0,
     "modbus_register_6": 0,
     "modbus_register_7": 0,
     "modbus_register_8": 0,
     "modbus_register_9": 0,
     "modbus_register_10": 0,
     "modbus_register_11": 0,
     "modbus_register_12": 0,
     "modbus_register_13": 0,
     "modbus_register_14": 0,
     "modbus_register_15": 0,
     "modbus_register_16": 0,
     "modbus_register_17": 0,
     "modbus_register_18": 0,
     "modbus_register_19": 0,
     "modbus_register_20": 0,
     "modbus_register_21": 0,
     "modbus_register_22": 0,
     "modbus_register_23": 0,
     "modbus_register_24": 0,
     "modbus_register_25": 0,
     "modbus_register_26": 0,
     "modbus_register_27": 0,
     "modbus_register_28": 0,
     "modbus_register_29": 0,
     "modbus_register_30": 0,
     "modbus_register_31": 0,
     "modbus_register_32": 0,
     "baud_rate": "9600",
     "bootup_time": 0,
     "slave_address": 1,
     "rs485_rx_timeout": "2000 msec",
     "sub_device_type": 0,
     "read_retries": 0,
     "modbus_command": "Read Holding Register 0x03",
     "parity_bit": "None",
     "stop_bits": "1 bit",
    },
    "machine_values": { ... }
  },
  "description" : "...",
  "packet_info": {
      "ack": 0,
      "broadcast": 0,
      "type": ""
      }
  "time": 1781217138869,
  "_msgid": "33fd88e3ea54492c"
}
				
			
Wireless Gateway Assertion Reason Message

A Assertion Reason message will be used for debugging purpose, It will show the code line number and function name.

An example Assertion Reason message can be found on the right.

				
					{
  "topic": "assert_rsn",
  "payload": {
    "addr": "00:13:a2:00:42:37:73:52",
    "type": 539,
    "nodeId": 0,
    "line_number": 1435,
    "function_name": "app_start_fly_timer"
  },
  "time": 1721424191767,
  "_msgid": "5f6f01b6651b2f82"
}
				
			

Wireless Node Configuration

Wireless Gateway Edit Pane

You can edit a Wireless Gateway node by double clicking on it once placed in a flow. Below is a description of the primary elements of this edit pane corresponding to the elements numbered to the right.

  1. Name
    • An arbitrary name given to this node
  2. Serial Device*
    • A drop down to choose between configured communication interfaces
    • The default Serial Device for our Enterprise Gateways is “/dev/ttymxc2”
    • To add a new configuration option you will want to choose “Add new ncd-gateway-config…” from this dropdown
  3. Serial Device Edit Icon
    • Clicking this icon will take you to a submenu to edit the particulars of the device chosen in the Serial Device dropdown
    • To add a new configuration option you will want to choose “Add new ncd-gateway-config…” from this dropdown
    • For More information on the submenu this icon bring up see section ncd-gateway-config Nodes​
  4. Output data from Unknown Devices
    • Enabling this feature allows other devices using the Digimesh wireless protocol to send their data to Node-Red
    • When selected, data from unknown devices will be output from a secondary output
Number diagram of Wireless Gateway Node edit pane

Wireless Device Nodes

Wireless Device nodes are a virtual representation of a single sensor or a type of sensor. These nodes will output all sensor data and configuration messages from the sensor.

Wireless Device nodes are the primary method of configuring individual or groups of sensors. Their message structure is slightly different from the data coming from a Wireless Gateway.

Wireless Device Node Statuses

The Wireless Device node will display a status based on the last message received to easily identify what is going on with the sensor. Below we will cover each status the Wireless Device node can enter and what it means.

Running Mode

When the Wireless Sensor Node’s status indicates “Running”, as shown in the picture on the right, it means that the wireless sensor has successfully sent at least one packet to the configured Wireless Network. The packet must be a sensor_mode message with a mode of RUN or a sensor_data message.

Wireless Device in Run Mode
No Mode

When the Wireless Sensor Node has no status, as shown in the picture on the right, it means that the wireless sensor has not sent a packet over the wireless network since Node-Red was run. The packet must be a sensor_mode message with a mode of RUN or a sensor_data message.

Wireless Device node with no status
FLY Mode

When the Wireless Sensor Node’s status indicates “FLY,” as shown in the picture to the right, it means the sensor has sent a sync message to check in for an Over-the-Air (OTA) configuration, and the synchronization process has been successfully completed.

Wireless Device with Status of FLY in Node-Red
Config Mode

When the Wireless Sensor Node’s status indicates “Config Mode”, as shown in the picture on the right, it means that the wireless sensor has sent a PGM packet to the receiver and is ready for configuration.

If this Wireless Device node has Auto Config enabled then Node-Red will attempt to configure the device with the settings configured in the Wireless Device edit pane.

Wireless Device Node Messages

Wireless Device Sensor Data Message

Sensor data is the primary message that will come from a Wireless Gateway Node. These messages can be discerned from other message types by the topic which will always be “sensor_data”

To the right is an example of a Sensor Data message.

  • topic
    •  Indicates the type of message this is
  • data
    • Contains the sensor data and all other pertinent details of the sensor
  • data.nodeID
    • A user configurable parameter allowing a user to input a simple id for a particular sensor
    • For a unique identifier it is recommended to use the msg.data.addr property as it is tied to the individual sensor’s wireless module and will always be unique
  • data.firmware
    • This identifies the firmware version of the sensor sending the packet
  • data.battery
    • The current voltage level of the batteries at the time of transmission
    • The batteries that come with the sensors drop off quickly once they reach 2.6 volts
  • data.battery_percentage
    • The current battery percent at the time of transmission
  • data.counter
    • The number of transmissions since boot or counter rollover
    • The counter will rollover after a counter value of 255
  • data.sensor_type
    • The machine identifiable type of the sensor
    • It is recommended to use this property to dictate dashboard generation and/or data integrity checks
  • data.sensor_data
    • Object containing all sensor data related to this sensor
    • This property is a duplicate of the payload property
  • data.sensor_name
    • Human Readable Sensor Type Identifier
  • data.type
    • An easily passed message type declaration
    • This property will be a duplicate of msg.topic
  • data.addr
    • The unique identifier of the sensor that transmitted the data
  • data.received
    • Timestamp of the message
  • data.original
    • Auxiliary information on the packet and underlying protocol
  • data.modem_mac
    • The unique identifier of the Gateway/Modem that received the data
    • Primarily used to tie locations/projects to sensors/sensor data
  • payload
    • Object containing all sensor data related to this sensor
    • See msg.payload Breakdown for more information
  • time
    • Timestamp of the message
				
					{
  "topic": "sensor_data",
  "data": {
    "nodeId": 0,
    "firmware": 10,
    "battery": "3.28",
    "battery_percent": "98.56",
    "counter": 26,
    "sensor_type": 539,
    "sensor_data": {
      "subdevice_type": 0,
      "number_of_registers": 0,
      "status_24_31": 0,
      "status_16_23": 0,
      "status_8_15": 0,
      "status_0_7": 0,
      "data": [
          0: 0,
          1: 0,
          2: 0,
          3: 0,
          4: 0,
          5: 0,
          6: 0,
          7: 0,
          9: 0,
          10: 0
          ...
       ]
    },
    "sensor_name": "RS-485 Modbus Wireless Converter",
    "type": "sensor_data",
    "addr": "00:13:a2:00:42:37:73:52",
    "received": 1721424191583,
    "original": {...},
    "modem_mac": "00:13:A2:00:41:F5:2C:D3"
  },
  "payload": {
      "subdevice_type": 0,
      "number_of_registers": 0,
      "status_24_31": 0,
      "status_16_23": 0,
      "status_8_15": 0,
      "status_0_7": 0,
      "data": [
          0: 0,
          1: 0,
          2: 0,
          3: 0,
          4: 0,
          5: 0,
          6: 0,
          7: 0,
          9: 0,
          10: 0
          ...
       ]
  },
  "time": 1721424191584,
  "_msgid": "48e99332fc104565"
}
				
			
Wireless Device Sensor Data Breakdown
  • sub_device_type
    • Byte to indicate what kind of User-defined Modbus RTU device it’s connected to.
  • number_of_registers
    • The number of registers read, up to a maximum of 32 registers in one operation.
  • status_0_to_31
    • Represents the status of the registry query: 0 indicates no error, while 1 indicates an error.
  • data
    • A variable-length array, it contains the value obtained from the Modbus-RTU registers as requested by the user.
Sync Check In Message

This sync_check_in message reports sensor information and allows for sync initialization if configuration changes are necessary.

A sync_check_in message indicates that the sensor is in RUN mode, but is entering a temporary state where it can be configured. The sensor will send the sync_check_in message on boot (after RUN and sensor_data messages) and once an hour after boot to check in. Once the sensor sends a sync_check_in message Node-RED has 2 seconds to respond with a configuration Master Command.

If Node-RED has a Wireless Device node with Mac Address, Auto Config and OTF Config selected corresponding to the sensor that sent the sync_check_in message then Node-RED will begin to configure that sensor.

				
					{
  "topic": "sync",
  "type": "sync_check_in",
  "address": "00:13:a2:00:42:35:89:86",
  "sensor_type": 536,
    "human_readable": {
      "core_version": 23,
      "firmware_version": 7,
      "sensor_type": 127,
      "tx_lifetime_counter": 13,
      "hardware_id": {
        "data": [ 99, 61, 0]
      },
     "network_id": "7fff",
     "destination_address": "0000ffff",
     "node_id": 0,
     "report_rate": 900,
     "register_to_read": "0",
     "modbus_register_1": 0,
     "modbus_register_2": 0,
     "modbus_register_3": 0,
     "modbus_register_4": 0,
     "modbus_register_5": 0,
     "modbus_register_6": 0,
     "modbus_register_7": 0,
     "modbus_register_8": 0,
     "modbus_register_9": 0,
     "modbus_register_10": 0,
     "modbus_register_11": 0,
     "modbus_register_12": 0,
     "modbus_register_13": 0,
     "modbus_register_14": 0,
     "modbus_register_15": 0,
     "modbus_register_16": 0,
     "modbus_register_17": 0,
     "modbus_register_18": 0,
     "modbus_register_19": 0,
     "modbus_register_20": 0,
     "modbus_register_21": 0,
     "modbus_register_22": 0,
     "modbus_register_23": 0,
     "modbus_register_24": 0,
     "modbus_register_25": 0,
     "modbus_register_26": 0,
     "modbus_register_27": 0,
     "modbus_register_28": 0,
     "modbus_register_29": 0,
     "modbus_register_30": 0,
     "modbus_register_31": 0,
     "modbus_register_32": 0,
     "baud_rate": "9600",
     "bootup_time": 0,
     "slave_address": 1,
     "rs485_rx_timeout": "2000 msec",
     "sub_device_type": 0,
     "read_retries": 0,
     "modbus_command": "Read Holding Register 0x03",
     "parity_bit": "None",
     "stop_bits": "1 bit",
    },
    "machine_values": { ... }
  },
  "description" : "...",
  "packet_info": {
      "ack": 0,
      "broadcast": 0,
      "type": ""
      },
  "time": 1781217138869,
  "_msgid": "33fd88e3ea54492c"
}
				
			
Sync Acknowledgment Message

A sync acknowledgment is received from the sensor in response to a configuration command. This message provides the current sensor status or reports any errors encountered during the configuration process. You may verify the current sensor configuration by examining the human_readable property within the message.

An example of a Sync Acknowledgment message is provided for your reference on the right.

				
					{
  "topic": "sync",
  "type": "sync_acknowledgment",
  "address": "00:13:a2:00:42:35:89:86",
  "sensor_type": 539,
  "payload": {
    "type": "sync_acknowledgment",
    "address": "00:13:a2:00:42:35:89:86",
    "sensor_type": 539,
    "response_bytes": [ ... ],
    "human_readable": { ... },
    "machine_values": { ... }
  },
  "description" : "...",
  "sent": [...],
  "packet_info": {
      "ack": 0,
      "broadcast": 0,
      "type": ""
      },
  "time": 1781217138869,
  "_msgid": "33fd88e3ea54492c"
}
				
			
Sync End Message

Sync process finished. Sensor is reporting its new values after Sync and resuming normal operations.

User can find the new settings after sync into “human_readable” property.

				
					{
  "topic": "sync",
  "type": "sync_end",
  "address": "00:13:a2:00:42:35:89:86",
  "sensor_type": 539,
  "payload": {
    "type": "sync_end",
    "address": "00:13:a2:00:42:35:89:86",
    "sensor_type": 539,
    "human_readable": { ... },
    "machine_values": { ... }
  },
  "description" : "...",
  "sent": [...],
  "packet_info": {
      "ack": 0,
      "broadcast": 0,
      "type": ""
      },
  "time": 1781217138869,
  "_msgid": "33fd88e3ea54492c"
}
				
			
Sync Response Success Message

Indicates that the sync configuration is complete and displays the specific values and properties applied to the settings.

				
					{
  "topic": "sync",
  "type": "sync_response",
  "address": "00:13:a2:00:42:35:89:86",
  "sensor_type": 539,
  "payload": {
    "address": "00:13:a2:00:42:35:89:86",
    "sensor_type": 539,
    "values": { ... },
    "pass": { ... },
    "status": "Success",
    "exit_otn_mode": { ... }
    },
  "time": 1781217138869,
  "_msgid": "33fd88e3ea54492c"
}
				
			
Sync Response Skip Message​

A “Sync Response Skip” message indicates that the settings currently active within the corresponding Wireless Device node already match the sensor’s actual configuration. Consequently, the library bypasses the synchronization process. This functionality allows the library to verify if the sensor’s reported configuration aligns with the desired parameters, thereby optimizing the process by skipping redundant updates.

If you encounter this message, it confirms that the sensor is already configured with the desired settings as defined in the sync message.

				
					{
  "topic": "sync",
  "type": "sync_response",
  "address": "00:13:a2:00:42:35:89:86",
  "sensor_type": 539,
  "payload": {
    "address": "00:13:a2:00:42:35:89:86",
    "sensor_type": 539,
    "info": "Reported configurations match desired configurations. Skipping Sync."
    },
  "time": 1781217138869,
  "_msgid": "33fd88e3ea54492c"
}
				
			

Configuration Options

Our Node-Red library lets you configure any of sensor easily, simply by adjusting a few fields in your Node-RED flow and triggering a configuration update either through the CFG button on the sensor or waiting for a FLY (sync) message sent every hour during normal operations (or when the device is reset).

You can edit a Wireless Device node by double clicking the node once it is placed in a flow.

Primary Configurations

These configurations are responsible for configuring the Wireless Device node and how node-red should interact with the sensor.

  • Name
    • Arbitrary name of this node
    • Primarily used for easy identification in the flow
  • Serial Device*
    • The primary communication interface used to receive data from the sensor
    • Clicking the edit icon will take you to a submenu to edit the particulars of the device chosen in the Serial Device dropdown
    • To add a new configuration option you will want to choose “Add new ncd-gateway-config…” from this dropdown
    • For More information on the submenu the edit icon brings up see section ncd-gateway-config Nodes​
  • Serial Device for Config
    • A secondary communication interface used to configure sensors without losing sensor data
    • If no option is selected the communication interface selected under Serial Device will be used for configuration
    • A second modem will be required to make full use of this option
  • Mac Address*
    • Using this field allows you to choose a specific sensor that corresponds to this Wireless Device node
    • A search icon on the right can be clicked to search for Wireless Devices that the Serial Device has heard from to auto fill information for that device
  • Sensor Type*
    • This field limits the sensors that correspond to this Wireless Device node to a particular type of sensor
  • Auto Config
    • Checking the box next to this field tells Node-Red that the sensor(s) corresponding to this Wireless Device node should be configured when put into Configuration Mode manually
  • OTF Config
    • Checking the box next to this field AND having Auto Config checked tells Node-Red that the sensor(s) corresponding to this Wireless Device node should be configured when a FLY message is detected
NCD Wireless Device node Modbus Transmitter
  • Wait for Network Formation
    • This option sends three commands to all local devices on the wireless network to help form the mesh network
  • Destination Address
    • This option will tell the sensor to ONLY send its data to a single receiver
    • For more information on how to get the Address of the receiver module connected to Node-Red see section Wireless Gateway modem_mac Message
  • Network ID
    • This option allows you to change the Network ID that the sensor will use to report its data while in RUN module
    • You will need to make sure that a Gateway or Modem is configured to use this network ID in order to receive sensor data from it after configuration
  • Node ID
    • Node ID allows you to set an easy to understand unique ID for a particular sensor
  • Power
    • This option allows you to set the transmission power level of the sensor
  • Retries
    • Sets the maximum number of retries the sensor will attempt before considering a packet transmission failed
General Configurations for Wireless Device nodes

Sensor Specific Configurations

Set Baud Rate

Configure the communication speed for the RS485 port

NCD Modbus RTU Node-RED Configuration example 1
Set Stop Bit

Configure the cthe stop bit signals the end of a data byte.

NCD 539 Set Stop Bit
Set Parity Bit

Configure the the Parity bit.

NCD 539 Set Parity
Set RS485 Rx Timeout

Sets the maximum time (in milliseconds) that the device will wait to receive a response from the RS485 field device via the serial port after it sends command.

NCD 539 Set rs485 Rx Timeout
Set Boot Time

Sets the delay interval (in seconds) that the NCD transmitter waits after powering on the connected Modbus device before issuing the first command. This delay ensures the external Modbus device has sufficient time to complete its internal initialization sequence before the transmitter begins polling.

NCD 539 Set Bootup Time
Set Slave ID

Configures the unique Slave Modbus device address (Slave ID) for the transmitter.

NCD Modbus RTU Node-RED Configuration example 1
Set Sub Device Type

A user-defined byte used to identify the specific type of Modbus RTU device connected. This parameter is essential for correctly decoding incoming messages and distinguishing between different devices on the network.

NCD 539 Set Sub device Type
Set Number of Read Retries

Sets the maximum number of attempts the device will make to perform a Modbus RTU register query.

NCD 539 Set Number of Read Retries
Set Read Parameter

Sets the Modbus Function Code.

NCD Modbus RTU Node-RED Configuration example 3
Set Read Registers

Set the total number of registers to read on interval in the Register Reads field. Set the individual Registers to read below in the correspond Register field.


Register Read Field: Set the individual Modbus Register to read.

NCD Modbus RTU Node-RED Configuration example 4
NCD Register to Read Address Example PR55-88F

Sensor Configuration Process

OTF Automatic Configuration

This sensor supports configuration while in Run Mode. We call this configuration OTF or On the Fly. This configuration is initiated by a SYNC message from the Sensor with the topic of sync. These messages are sent over the standard Run Mode wireless network so there is no need to change the Wireless Gateway nodes mode or manually manipulate the buttons on the sensor.

Sync messages are sent once an hour and on boot and tell Node-RED that the sensor is ready for configuration changes. Node-RED has two seconds to respond with a configuration command or extend this temporary configuration mode.

If you have a Wireless Device node with Mac address, Auto Config and OTF Config corresponding to the sensor that sent the sync message then Node-Red will begin configuring that sensor according to the settings entered on the Wireless Device node.

See section Primary Wireless Device Node Configurations for more information on how to set up a Wireless Device to configure a sensor.

Example Auto Configuration Process​

If you have entered the sensor Mac Address, selected the Auto Config and OTF Config boxes, your sensor will pick up any configuration changes you have made to the Sensor Specific parameters and automatically apply them.

This process is not immediate and requires the device send a sync Message to the Gateway (this happens once every hour or when the device is reset).

Once the sync message has been received the device will enter OTN mode (indicated by a corresponding message) and update any parameters that have been changed. 

Once done the device will continue its normal operating with the updated parameter values.

Let us look at an example to better illustrate how the process should work out.

Step 1

Draw and drop a Wireless Device node and connect a debug node at the Wireless Device node, then double click on Wireless Device node to access its properties. Enter the Mac Address of the target sensor, check the two boxes, the one next to “Auto Config” and the one next to “OTF Config”. This will allow the device to work in a mode where it will Automatically pick up the configuration changes.

NCD Wireless Device node Modbus Transmitter
Step 2

Select the parameter you want to modify.

Let’s go to the “Baud Rate” and change its value. This parameter determines the baud rate value for the RS485 Serial Communication.

The default value is 9600 baud rate, let’s change it to 115200 baud rate.

Make sure you check the “Active” check box, this will let the sensor know that it needs to update this parameter.

Select the value from the drop down menu, in this case 115200.

Press the “Done” button to close the Wireless Device node.

Press the “Deploy” button so you can update the flow.

NCD type 539 Baud Rate configuration Example
Click to Expand
Step 3

Reset the sensor in order to trigger a sync message (configuration mode).

(this will speed things up so you don’t need to wait for the 1 hour automatic sync message time).

You will receive a series of messages into debug window, which are normally sent after deploy and the sensor starts (modem_mac, RUN, sensor_data, then sync_check_in).

NCD Node-RED Flow Configuration Example
NCD 539 Sync Process Example

The most important element here is the sync_check_in message, which reports the device’s current configuration at the moment it is transmitted. You can view an example of this message on the right for your reference.

Once the sensor sends a sync_check_in message, Node-RED receives it and compares the sensor’s current settings with your newly desired settings. If they do not match, Node-RED recognizes that an update is needed and automatically sends a master command to apply the new configuration.

For example, in this specific case, the sensor’s current baud_rate is set to 9600, but we want to update it to 115200. Because Node-RED detects this difference, it will automatically initiate the sync configuration process to update your device.

				
					{
  "topic": "sync",
  "type": "sync_check_in",
  "address": "00:13:a2:00:42:35:89:86",
  "sensor_type": 536,
    "human_readable": {
      "core_version": 23,
      "firmware_version": 7,
      "sensor_type": 539,
      "tx_lifetime_counter": 13,
      "hardware_id": {
        "data": [ 99, 61, 0]
      },
     "network_id": "7fff",
     "destination_address": "0000ffff",
     "node_id": 0,
     "report_rate": 900,
     "register_to_read": "0",
     "modbus_register_1": 0,
     "modbus_register_2": 0,
     "modbus_register_3": 0,
     "modbus_register_4": 0,
     "modbus_register_5": 0,
     "modbus_register_6": 0,
     "modbus_register_7": 0,
     "modbus_register_8": 0,
     "modbus_register_9": 0,
     "modbus_register_10": 0,
     "modbus_register_11": 0,
     "modbus_register_12": 0,
     "modbus_register_13": 0,
     "modbus_register_14": 0,
     "modbus_register_15": 0,
     "modbus_register_16": 0,
     "modbus_register_17": 0,
     "modbus_register_18": 0,
     "modbus_register_19": 0,
     "modbus_register_20": 0,
     "modbus_register_21": 0,
     "modbus_register_22": 0,
     "modbus_register_23": 0,
     "modbus_register_24": 0,
     "modbus_register_25": 0,
     "modbus_register_26": 0,
     "modbus_register_27": 0,
     "modbus_register_28": 0,
     "modbus_register_29": 0,
     "modbus_register_30": 0,
     "modbus_register_31": 0,
     "modbus_register_32": 0,
     // This is the setting we want to to set in this example
     "baud_rate": "9600",
     //------------------
     "bootup_time": 0,
     "slave_address": 1,
     "rs485_rx_timeout": "2000 msec",
     "sub_device_type": 0,
     "read_retries": 0,
     "modbus_command": "Read Holding Register 0x03",
     "parity_bit": "None",
     "stop_bits": "1 bit",
    },
    "machine_values": { ... }
  },
  "description" : "...",
  "packet_info": {
      "ack": 0,
      "broadcast": 0,
      "type": ""
      },
  "time": 1781217138869,
  "_msgid": "33fd88e3ea54492c"
}
				
			
				
					{
  "topic": "sync",
  "type": "sync_response",
  "address": "00:13:a2:00:42:35:89:86",
  "sensor_type": 539,
  "payload": {
    "address": "00:13:a2:00:42:35:89:86",
    "sensor_type": 539,
    "info": "Reported configurations match desired configurations. Skipping Sync."
    },
  "time": 1781217138869,
  "_msgid": "33fd88e3ea54492c"
}
				
			

Once Node-RED sends the master command with the new desired settings, the sensor will respond with a sync_acknowledgment message, followed by a sync_end message, and finally a sync message with a “success” status. This sequence indicates that the configuration process is complete.

NCD Type 127 Configuration Example

After the sync configuration has finished, you can verify the new sensor settings by expanding the sync_end message in the debug window. There, you can review the human-readable properties to see the actual configurations applied to the sensor. In this example, the baud_rate will now show as 115200.

				
					{
  "topic": "sync",
  "type": "sync_end",
  "address": "00:13:a2:00:42:35:89:86",
  "sensor_type": 536,
  "payload": {
    "type": "sync_end",
    "address": "00:13:a2:00:42:35:89:86",
    "sensor_type": 127,
    "human_readable": {
      "core_version": 23,
      "firmware_version": 10,
      "sensor_type": 536,
      "tx_lifetime_counter": 13,
      "hardware_id": {
        "data": [ 99, 61, 0]
      },
     "network_id": "7fff",
     "destination_address": "0000ffff",
     "node_id": 0,
     "report_rate": 900,
     "register_to_read": "0",
     "modbus_register_1": 0,
     "modbus_register_2": 0,
     "modbus_register_3": 0,
     "modbus_register_4": 0,
     "modbus_register_5": 0,
     "modbus_register_6": 0,
     "modbus_register_7": 0,
     "modbus_register_8": 0,
     "modbus_register_9": 0,
     "modbus_register_10": 0,
     "modbus_register_11": 0,
     "modbus_register_12": 0,
     "modbus_register_13": 0,
     "modbus_register_14": 0,
     "modbus_register_15": 0,
     "modbus_register_16": 0,
     "modbus_register_17": 0,
     "modbus_register_18": 0,
     "modbus_register_19": 0,
     "modbus_register_20": 0,
     "modbus_register_21": 0,
     "modbus_register_22": 0,
     "modbus_register_23": 0,
     "modbus_register_24": 0,
     "modbus_register_25": 0,
     "modbus_register_26": 0,
     "modbus_register_27": 0,
     "modbus_register_28": 0,
     "modbus_register_29": 0,
     "modbus_register_30": 0,
     "modbus_register_31": 0,
     "modbus_register_32": 0,
     // This is the setting we changed
     "baud_rate": "115200",
     //------------------
     "bootup_time": 0,
     "slave_address": 1,
     "rs485_rx_timeout": "2000 msec",
     "sub_device_type": 0,
     "read_retries": 0,
     "modbus_command": "Read Holding Register 0x03",
     "parity_bit": "None",
     "stop_bits": "1 bit",
    },
    "machine_values": { ... }
  },
  "description" : "...",
  "sent": [...],
  "packet_info": {
      "ack": 0,
      "broadcast": 0,
      "type": ""
      },
  "time": 1781217138869,
  "_msgid": "33fd88e3ea54492c"
}
				
			

Troubleshooting

Check Sensor Power

Press the CFG button on the sensor. If the TEST LED on the sensor lights up then the sensor has power. If the LED does not light up try swapping out the battery.

If the LED still doesn’t light up after changing the battery contact us for additional troubleshooting steps.

Factory Reset Sensor

If the power tests above show that power is on and the TEST LED lights up then you can attempt a factory reset. There are certain configurations that can be made to the sensor that will prevent data from being received properly such as Destination Address and Network ID. A factory reset will revert these to default settings.

  1. Factory Reset the Sensor
    • Factory reset by pressing and release the RESET button, wait for a second, then press and hold the CONFIGURATION button, hold the CONFIGURATION button for more than 15 seconds, release CONFIGURATION button, then Wait for 3-5 seconds, finally press and release the RESET button.
  2. You should receive a sensor_mode message with the mode of PUM and then a second sensor_mode message with the mode of RUN
    • It is recommended to have a Debug node connected directly to the Wireless Gateway node to see these messages

Multiple Gateways

If you have multiple Gateways in the vicinity of a sensor that is having issues you will need to make sure that only one Gateway is set to configure these sensors using OTF Config. Multiple OTF Configuration attempts simultaneously will cause failures during configuration.

Additionally if one Gateway is setting the Destination Address or Network ID of the sensor it will prevent the other Gateways from seeing its sensor data or being able to perform OTF Configurations to that sensor.

The recommended resolution is to make sure that only one gateway is set to configure the device. If communications are down to the intended receiver perform a factory reset of the device.

See section Hardware Mode Selection for more information on performing a factory reset.

Move Devices Closer

Its possible that there was an environmental change at the install location that is causing the Wireless range of the sensor to be reduced. To check for this it is recommended to move the sensor closer to approximately 3 feet or 1 meter from the gateway and press the RESET button to see if the sensor_mode message with the mode of RUN is received.

If it is determined that it is a range issue you can check that the antenna is fully seated. If there appears to be no issue with the antenna this can usually be resolved by adding a Repeater between the Sensor and the Receiver/Gateway running Node-Red.

If the range is limited to a few feet contact us for additional troubleshooting steps.