Settings

Settings

Example settings file (in yaml notation):

There are 2 main keys: the devices and mappings key.

• devices: each controlled device is listed with its configuration parameters.

• mappings: the controls between the devices are mapped together.

Devices

The type of the device must match the plugin name.

The name of the device can be anything, but must be unique.

Further options are dependent on the plugin, please read the plugin’s documentation for more information.

Mappings

The name of the mapping can be anything, but must be unique. The from: name and to: name must match the name given to the device in the devices setup. The address specifies the i/o port number (modbusTCP), alias (nion) or name (websocket) of the specific io. See the plugin specific documentation for details.

The type specifies the type that the plugin sends or expects, is required and can by any of:

• bool → bool
• int8 → uint8_r
• int16 → uint16_t
• float → double
• string → string

Types can be converted to one another in most cases, check the relevant plugin documentation for details.

Multiple similar mappings can be generated using the loop map.

The loop map has to contain a start and end key with integer value. For every whole integer between the start and end (including both start and end values) a mapping will be created with the name, from and to key & value pairs as specified. In the mapping name and addresses a formula can be included. It must be wrapped in $(). The variable i in this formula will be replaced with the index value of the loop. The simplest example of this would be the formula $(i) which will return only the index of the loop. Being a formula, you can also make it something like $(i + 2) which would result in a value of 3 when the index is 1. A looped mapping can be specified directly on the loop element as a single mapping, or as a list of mappings with an extra ‘mappings’ key (see the settings.yml example below).

Configuration Example

settings.yml

verbosity: info # <1>

# These are the default settings for the
# Prometheus metrics server and endpoint
metrics_bind_address: 127.0.0.1:8080
metrics_endpoint_url: /metrics
metrics_enabled: true

devices:
  - type: modbusTCP
    name: Arbitrary_Unique_Name_1
    verbosity: debug # <2>
    options:
      ip: 10.0.0.1
      port: 502
      scan_rate: 50
  - type: modbusTCP
    name: Arbitrary_Unique_Name_2
    metrics: false
    options:
      ip: 10.0.0.2
      port: 502
      scan_rate: 50
  - type: nion
    name: node1
    options:
      ip: 10.0.0.3
      port: 1633
      username: defaultuser
      password: ''
  - type: websocket
    name: websocketserver
    options:
      ip: 10.0.0.1
      port: 5005
      server_name: myserver

mappings:
  - name: test
    from:
      name: Arbitrary_Unique_Name_1
      type: bool
      address: 1
    to:
      name: Arbitrary_Unique_Name_2
      type: bool
      address: 1
  - name: test2
    from: { name: Arbitrary_Unique_Name_1, type: bool, address: 2 }
    to: { name: Arbitrary_Unique_Name_2, type: bool, address: 2 }
    mutation: not(i) # <3>
    when: i # <6>
  # A single mapping using a loop from 0 to 7
  - loop:
      start: 0
      end: 7
      name: mapping-$(i)
      from:
        name: Arbitrary_Unique_Name_1
        type: bool
        address: $(i) }
      to:
        name: Arbitrary_Unique_Name_2
        type: bool
        address: input_$(i+2) }
  # Multiple mappings using the same loop, from 0 to 7
  - loop:
      start: 0
      end: 7
      mappings:
        - name: mapping-input-$(i)
          from:
            name: Arbitrary_Unique_Name_1,
            type: int16
            address: $(i)
          to:
            name: Arbitrary_Unique_Name_2
            type: int8
            address: input_$(i+2)
          mutation: scale(i, int16, int8) # <4>
          when: i > 3 # <7>
        - name: mapping-output-$(i)
          from:
            name: Arbitrary_Unique_Name_2
            type: int8
            address: output_$(i+2)
          to:
            name: Arbitrary_Unique_Name_1
            type: int16
            address: $(i }
          mutation: scale(i, int8, int16) # <5>

1. verbosity level - can be any of silent, critical, warning, info, debug
2. the verbosity level can be overwritten on a per plugin instance basis; the same rules apply
3. this mutation inverts the value send to the to plugin
4. this mutation scales the 16bit value on the from plugin to a 8bit value for the to plugin
5. this mutation scales the 8bit value on the from plugin to a 16bit value for the to plugin
6. with the when: i, only rising edges will be sent out, only when the received value is true it will be passed along to the receiver.
7. the when is processed before the mutation, in this example you can imagine filtering out some background noise from an analog input, before scaling it with the mutation.

More information on mutations, and a reference of all supported constants, operators and function can be found on the mutations page

There are also some license related arguments which you can find in the licensing section.