BAOS KNX Integration with MyURemote

MyURemote KNX BAOS Home Control interface

Example of KNX control through BAOS in the MyURemote Home Control interface

This page explains in detail how MyURemote works with a KNX installation through a BAOS gateway, how datapoints should be structured in ETS, how commands and feedback are mapped, and what the practical difference is between 1-bit and 1-byte datapoints.

This documentation is intended for installers, advanced users and developers who want to configure KNX control correctly for use inside MyURemote.

Overview

MyURemote can control KNX functions through a BAOS IP gateway. In this setup, the BAOS gateway is treated by MyURemote as an IP-based controller. MyURemote does not communicate directly with ETS or with KNX group addresses in the traditional way. Instead, it sends and reads BAOS datapoint values through the gateway.

In practical terms, this means:

  • ETS is used to define the BAOS datapoints.
  • The BAOS gateway exposes these datapoints over IP.
  • MyURemote sends commands to these datapoints.
  • MyURemote reads feedback datapoints to keep the user interface in sync.

The current MyURemote implementation is based on a fixed datapoint mapping model:

  • Datapoints 1 to 80 are used as the main operational datapoints.
  • Datapoints 81 to 160 are used as status or feedback datapoints.
  • Feedback datapoints are mapped back to the main datapoints using a fixed +80 / -80 offset.

Example:

  • Main datapoint 1 has feedback datapoint 81.
  • Main datapoint 10 has feedback datapoint 90.
  • Main datapoint 44 has feedback datapoint 124.

General architecture

The full chain looks like this:

MyURemote App / Configuration Panel → MyURemote BAOS module → IP connection → BAOS gateway → KNX datapoints

The configuration happens in two different places:

  1. ETS / BAOS configuration
    Here the datapoints are created and assigned a type and a meaning.
  2. MyURemote configuration panel
    Here the BAOS gateway is added as an IP controller, commands are generated, and Home Control elements are linked to specific datapoint numbers.

How MyURemote sees a BAOS gateway

Inside MyURemote, a BAOS gateway is configured as an IP device. The gateway needs at least:

  • an IP address
  • a port number
  • the BAOS JavaScript module

Once configured, MyURemote can:

  • send write commands to a datapoint
  • read status blocks from the gateway
  • update the Home Control user interface with returned values

In the configuration panel, commands are stored in a very compact format such as:

  • 1-0
  • 1-1
  • 41-0
  • 41-128
  • 41-255

The meaning is simple:

  • the first number is the datapoint number
  • the second number is the value to write

So:

  • 1-0 means: write value 0 to datapoint 1
  • 1-1 means: write value 1 to datapoint 1
  • 41-128 means: write value 128 to datapoint 41

Important datapoint model used by MyURemote

The current MyURemote BAOS implementation is built around a fixed datapoint layout. This is important, because the software expects feedback datapoints to exist in a second range with an offset of 80.

Main operational datapoints

Datapoints 1 to 80 are treated as the main datapoints used by buttons, sliders and other Home Control elements.

These are the datapoints MyURemote sends commands to.

Feedback datapoints

Datapoints 81 to 160 are treated as the feedback datapoints.

These are the datapoints MyURemote reads back from the BAOS gateway to know the current state of lights, dimmers, screens and other functions.

Fixed mapping rule

The feedback datapoint for a main datapoint is calculated as:

feedback datapoint = main datapoint + 80

And when MyURemote receives feedback, it maps the datapoint back as:

main datapoint = feedback datapoint – 80

Examples:

  • Datapoint 1 ↔ feedback 81
  • Datapoint 2 ↔ feedback 82
  • Datapoint 19 ↔ feedback 99
  • Datapoint 41 ↔ feedback 121
  • Datapoint 44 ↔ feedback 124
  • Datapoint 50 ↔ feedback 130

This means that, for correct use with MyURemote, ETS should be programmed with this offset logic in mind.

Recommended ETS structure

Based on the current MyURemote BAOS implementation, the recommended structure is:

  • 1 to 40: binary command datapoints
  • 41 to 80: byte-based command datapoints
  • 81 to 120: binary feedback datapoints for 1 to 40
  • 121 to 160: byte-based feedback datapoints for 41 to 80

This structure is not just a documentation preference. It matches the way the current BAOS logic in MyURemote scans and maps datapoints.

In other words:

  • main command datapoints stay in the first range
  • feedback for those datapoints must exist exactly 80 positions higher

Why this layout is practical

  • It keeps command datapoints and feedback datapoints clearly separated.
  • It makes debugging much easier.
  • It fits directly with the current MyURemote polling and response parser logic.
  • It avoids confusion between operational values and status values.

Difference between 1-bit and 1-byte datapoints

A very important part of the setup is the distinction between 1-bit and 1-byte datapoints.

1-bit datapoints

1-bit datapoints are used for simple binary actions. They only have two possible values:

  • 0
  • 1

Typical examples:

  • light off / on
  • relay off / on
  • screen up / down
  • button action
  • toggle state

In ETS these are typically configured as a binary datapoint type such as:

  • DPT 01 – Binary – 1 Bit

In MyURemote these appear as commands like:

  • 1-0
  • 1-1
  • 2-0
  • 2-1

These are ideal for:

  • buttons
  • switches
  • small toggle controls

1-byte datapoints

1-byte datapoints are used when a function needs a value range rather than a simple off/on state.

A 1-byte value can contain values from:

  • 0 to 255

Typical examples:

  • dimmer level
  • light intensity
  • percentage control
  • position values
  • analog setpoints

In ETS these are often configured as:

  • DPT 05 – 1 Byte

In MyURemote, these can result in a large list of possible commands, for example:

  • 41-0
  • 41-1
  • 41-2
  • …
  • 41-255

In the Home Control interface these are typically used as sliders, where MyURemote displays a percentage while internally sending a value between 0 and the configured maximum.

How Home Control uses BAOS datapoints

Example in Home Control configuration

Below is an example of how Home Control elements are linked to BAOS datapoints in the MyURemote configuration panel.

MyURemote Home Control BAOS configuration

Each element is linked to a specific datapoint using the Param field. For example, Param: 44 means that the element controls datapoint 44 in the BAOS gateway.

In the Home Control page, each UI element is linked to:

  • a label
  • a type
  • an extender
  • a module
  • a domotics parameter
  • an optional maximum value

For BAOS, the important field is the domotics parameter. This parameter is the datapoint number used by MyURemote.

Example:

  • Param: 44
  • Max: 255

This means that the element controls datapoint 44 and that the UI should work on a range from 0 to 255.

Element types in Home Control

The Home Control code uses different UI element types:

  • type 0: slider for light-like values
  • type 1: slider for screen / shape-like values
  • type 2: small button
  • type 3: large button

In practical terms:

  • 1-bit datapoints are usually linked to button-style controls
  • 1-byte datapoints are usually linked to slider-style controls

How writing works

When a user touches a button or moves a slider in MyURemote, the system builds a BAOS write frame and sends it to the BAOS gateway.

Internally, the important logic is:

  • take the datapoint number
  • take the requested value
  • build a BAOS message
  • send it over IP to the configured gateway

For binary datapoints, the values are usually:

  • 0
  • 1

For byte datapoints, the values can be:

  • 0 to 255

MyURemote clamps values safely to a valid byte range, which means values lower than 0 become 0 and values higher than 255 become 255.

How reading and feedback works

Feedback is one of the most important parts of the BAOS integration.

MyURemote does not simply assume that a sent command succeeded. It also polls status datapoints from the BAOS gateway.

Polling model

The current implementation reads feedback datapoints in blocks of 20.

It cycles through the feedback range and reads:

  • 81 to 100
  • 101 to 120
  • 121 to 140
  • 141 to 160

The returned datapoint IDs are then mapped back to the original main datapoints by subtracting 80.

This is why the feedback range must be programmed consistently in ETS.

Why feedback is necessary

  • to show the real state of a light
  • to show the current dim value
  • to update button states correctly
  • to keep sliders synchronized
  • to reflect changes made outside MyURemote

For example, if a light is switched on by another KNX button or logic rule, MyURemote can still show the correct status if the BAOS feedback datapoint is updated.

Recommended practical setup in ETS

When preparing a BAOS gateway for use with MyURemote, it is recommended to define the datapoints in a structured way.

Suggested layout

Binary command datapoints

  • 1 = kitchen light
  • 2 = pool shutter
  • 3 = spare
  • 4 = kitchen speakers
  • 5 = terrace speakers
  • 6 = pool speakers
  • 7 = all kitchen lights
  • 8 = all outdoor lights
  • 9 = all off
  • 10 = small curtain street side

Byte command datapoints

  • 41 = terrace lights dimmer
  • 42 = kitchen table dimmer
  • 43 = stairs dimmer
  • 44 = bar spots dimmer
  • 45 = kitchen oven dimmer
  • 46 = kitchen TV dimmer
  • 47 = spare
  • 48 = hallway lights dimmer
  • 49 = spare
  • 50 = living dimmer

Binary feedback datapoints

  • 81 = feedback of datapoint 1
  • 82 = feedback of datapoint 2
  • 83 = feedback of datapoint 3
  • 84 = feedback of datapoint 4
  • 85 = feedback of datapoint 5
  • 86 = feedback of datapoint 6

Byte feedback datapoints

  • 121 = feedback of datapoint 41
  • 122 = feedback of datapoint 42
  • 123 = feedback of datapoint 43
  • 124 = feedback of datapoint 44
  • 125 = feedback of datapoint 45
  • 126 = feedback of datapoint 46

Using a fixed structured layout is strongly recommended. It keeps installation, configuration and troubleshooting much easier.

How commands are configured in MyURemote

Example configuration in MyURemote

Below is an example of how BAOS datapoint commands are configured in the MyURemote configuration panel.

MyURemote BAOS command configuration

Each datapoint can have multiple command values. For binary datapoints (1-bit), typically two values are defined (0 and 1). For byte datapoints (1-byte), a full range of values (0 to 255) can be available.

Once the BAOS gateway is added in MyURemote, commands can be defined for each datapoint.

For 1-bit datapoints

Normally, two commands are sufficient:

  • Value 0
  • Value 1

Example:

  • Datapunkt 01 Value 0 → 1-0
  • Datapunkt 01 Value 1 → 1-1

For 1-byte datapoints

A full byte range may be made available.

Example:

  • Datapunkt 41 Value 000 → 41-0
  • Datapunkt 41 Value 001 → 41-1
  • Datapunkt 41 Value 128 → 41-128
  • Datapunkt 41 Value 255 → 41-255

In Home Control, these values are usually not selected one by one by the user. Instead, the slider generates the correct value automatically.

How slider values are handled

For slider elements, MyURemote shows a percentage to the user, but internally it can work with a maximum value such as 255.

Example:

  • 0% → value 0
  • 50% → value about 127 or 128
  • 100% → value 255

This allows a simple and user-friendly interface while still working with the BAOS datapoint value range expected by the KNX side.

Best practices

  • Always keep command datapoints and feedback datapoints clearly separated.
  • Use a strict +80 mapping for feedback datapoints when the installation is intended for MyURemote.
  • Group binary and byte datapoints logically.
  • Use clear descriptions in ETS so every datapoint remains understandable.
  • Reserve spare datapoints for future expansion.
  • Keep naming consistent between ETS and MyURemote.
  • For dimming or variable values, use byte-based datapoints with a defined maximum value.
  • For buttons and toggles, use binary datapoints.

Common mistakes

  • Using feedback datapoints in the same range as command datapoints.
  • Forgetting the +80 offset required by the current MyURemote implementation.
  • Using a 1-bit datapoint where a byte value is needed.
  • Using a byte datapoint where only binary switching is intended.
  • Assigning the wrong Home Control parameter number.
  • Forgetting to define feedback datapoints, resulting in incorrect UI status.

Developer notes

The current MyURemote BAOS implementation builds BAOS write and read frames manually. Write commands send a datapoint number and value to the gateway. Read operations poll blocks of feedback datapoints and then map them back to the original UI elements.

The response parser expects datapoint value responses and returns compact arrays in the format:

[key, value, key, value, ...]

For BAOS status reads, the received datapoint number is converted back to the Home Control datapoint using:

mapped datapoint = feedback datapoint - 80

This is the reason the ETS structure must match the expected feedback range.

Conclusion

MyURemote can work very efficiently with KNX through a BAOS gateway, provided the datapoints are structured correctly.

The most important rule is:

Use datapoints 1 to 80 for the main functions and datapoints 81 to 160 as the corresponding feedback range.

Within that structure:

  • binary functions should use 1-bit datapoints
  • variable values should use 1-byte datapoints
  • feedback should follow the same numbering with an offset of 80

When this structure is respected, MyURemote can send commands correctly, read back current status, and keep the Home Control interface synchronized with the KNX system.