Measurement data types

Data type helps to determine how to interpret received bytes on the Modbus client side. If incorrect data type is used in case of user custom mapping configuration, e.g., unsigned type for negative values, it may lead to incorrect value interpretation on Modbus client side. Also, incorrect length (16-bit instead of 32-bit) can be a source of incorrect data interpretation (value cannot be encoded correctly as it is out of the data type’s specific value range).

dataType value	Description	Registry size	Value range
int16	16-bit signed integer	1	-32768 — 32767
int32	32-bit signed integer	2	-2147483648 — 2147483647
uint16	16-bit unsigned integer	1	0 — 65535
uint32	32-bit unsigned integer	2	0 — 4294967295
int64	64-bit signed integer	4	-9223372036854775808 — 9223372036854775807

Note: For uint32 and int32 registry size is 2; this affects the next address value in the sequence of addressing. Example: if a measurement initial offset is 1 and its dataType is uint32 (registry size 2) then the next measurement offset must be 3 (offset plus registry size). In case of address overlapping an error message will be reported in Modbus configuration GUI and both overlapping registries will not be available for Modbus requests (ILLEGAL_DATA_ADDRESS exception).

Example usage:

{ 
  "inputRegisters": {
    "offset": 30000,
    "1056849": {
      // CO2: 1 register long, values 0--65535
      "co2": { "dataType": "uint16", "offset": 4 }, // address 30004
      // RH: 1 register long, values 0--65535
      "humidity": { "dataType": "uint16", "offset": 1 }, // address 30001
      "offset": 0,
      // Temperature: 2 registers long, values -2147483648--2147483647
      "temperature": { "dataType": "int32", "offset": 2 } // address 30002
    }
  }
}

Measurement value multiplier

On the Modbus server side, before the value is assigned to the registry, it is multiplied depending on the measurement precision. To retrieve the original measurement value, the received value must be divided by the specified multiplier constant. Multipliers can be found in the auto-generated registry mapping configuration file. Same multiplier values must be used in a custom user-specified mapping configuration file.

Example:

{ 
  "inputRegisters": {
    "offset": 30000,
    "1056849": {
      "co2": {
        "dataType": "uint16",
        "multiplier": 1,
        "offset": 4
      },
      "humidity": {
        "dataType": "uint16",
        "multiplier": 10, // divide by 10 to get humidity
        "offset": 1
      },
      "offset": 0,
      "temperature": {
        "dataType": "int32",
        "multiplier": 1000, // divide by 1000 to get temperature
        "offset": 2
      }
    }
  }
}

Example: if original temperature is -40.5 and multiplier is 1000, then stored value is -40500 which may require int32 data type (int16 would not hold that value).

The JSON structure fields "sensorName" and "groupName" do not affect sensor configuration on JSON file upload when custom mapping configuration is being used. These fields are not updated in the custom mapping file if sensor information is changed in the base station sensor settings. Changes are updated only in the auto-generated address-to-measurements mapping configuration file.

Additional example:

{ 
  "inputRegisters": {
    "6292285": { // Sensor 60033D; Address: 20000
      "battCharge": { // Address 20003: divide by 100 to get battCharge in fraction
        "dataType": "int32",
        "multiplier": 100,
        "offset": 3
      },
      "offset": 0,
      "rssi": { // Address 20005: measurement rssi in dBm
        "dataType": "int32",
        "multiplier": 1,
        "offset": 5
      },
      "time": { // Address 20007: measurement time in seconds
        "dataType": "uint32",
        "multiplier": 1,
        "offset": 7
      },
      "vwc": { // Address 20001: divide by 1000 to get VWC in fraction
        "dataType": "int32",
        "multiplier": 1000,
        "offset": 1
      }
    },
    "offset": 20000
  }
}

Sensor UID readable from Input registers (from v4.9.x)

Sensor UID (HEX UID represented in decimal format) can be read from Input registers. In the sensor’s object it is nested as an object named "uid".