Cross-System Switching

Figure 3 shows an example that demonstrates how different smart home systems can exchange data using ioBroker. In this example, the ioBroker system supports three systems:

Figure 3: Sample setup with ioBroker as the central agent.

• Harmony Hub – an add-on hub for a Logitech universal remote control
• KNX – a standards-based building automation system
• Philips Hue – a lighting device, or more precisely, the Hue bridge, which manages the lighting device.

Although all three of these systems speak different languages, ioBroker lets you manage all three collections through a single interface.

Before you can integrate these three environments through ioBroker, you must configure each of the environments individually. For this example, I did the following:

• Created a Television activity via the Harmony Hub.
• Created a KNX Television scene in the KNX system.
• Taught all lamps via the Hue bridge.

The automation part now consists of the user selecting the KNX Television scene by pressing the "Television" button on a Harmony remote control. The result of this scene is that the television switched on and the television lighting turned on via the Hue bridge.

The scene could also trigger other actions through the KNX bus, such as closing the blinds or dimming other light sources (outside the Hue system).

However, these transactions defined within the individual systems still have not achieved the integration possible through ioBroker. The ioBroker configuration will focus on building bridges between the Harmony Hub and KNX on the one hand and between KNX and the Hue system on the other.

Adapter Integration

In order for ioBroker to communicate with these subsystems, a total of four adapters are required:

• JavaScript: javascript (already exists after auto-discovery)
• KNX system: knx
• Logitech Harmony Hub: harmony
• Philips Hue system/bridge: hue

When installing the Philips Hue adapter, only the IP address of the Hue bridge is important (Bridge Address field); you either create a new user or enter an existing user in the Bridge Users field (Figure 4).

Figure 4: Configuring the Hue Adapter.

The Instances option in the sidebar menu should list the newly added adapter named hue.0 and the status LED should turn green to indicate that the connection to the host (the Hue bridge) has been established. The Harmony adapter instance is created just as easily. The dialog box only requires two entries: the hub user and the hub password.

Slightly more configuration overhead is required for the KNX adapter. The wizard expects the IP address of the KNX IP interface or the KNX IP router, the corresponding port (3671), and the physical KNX address of the interface (say, 1.1.249). The wizard also offers to include an existing ETS project file (format .knxproj). You can create the project file with the ETS software [3] via the export function. Importing the ETS file can take a few minutes on a small system such as a Rasp Pi.

The information in the KNX adapter configuration view (Figure 5) represents the KNX group settings contained in the ETS project file. The ioBroker objects that are created automatically after installing the adapters facilitate communication among the devices. Writing to one of these objects triggers an action on the connected system (such as retrieving a KNX scene). If the connected system generates information, the information is also reflected in an object within ioBroker.

Figure 5: Setting up the KNX adapter.

The JavaScript adapter is usually installed during the auto-discovery process. For more debugging when programming in JavaScript, it is a good idea to activate the Expert view in the ioBroker Instances tab. Once the Expert view is activated, you can raise the log level from Info to Debug, which provides better console output during JavaScript development.

If all adapters are configured correctly, the Instances view displays the green status LED for each adapter (Figure 6). By the way, you can also create multiple instances for an adapter. For example, a second existing Hue bridge could be included using the same procedure, but it would then have an instance name of hue.1 instead of hue.0.

Figure 6: All the required adapters are successfully integrated.

Communication via Objects

ioBroker automatically creates a large number of objects during the adapter installation. In the Object tab (Figure 7), you can open, modify, and inspect all objects in a hierarchical view. This central view of object data is one of the great strengths of ioBroker. In principle, the software handles the communication between the individual smart home systems. The view is refreshed automatically when objects change. It is also very easy to trigger an action in a connected system by manually overwriting the object value in the Value column.

Figure 7: Device control via the Object view.

Communication with an external device is easy. The following example is intended to switch on a Hue light. In the object view, expand the hierarchical list until you find the objects you are looking for. The hierarchy is structured differently depending on the adapter. For example, the path for a Hue light would look like this:

hue.0 | Philips_hue | Liv | pendant_lamp_front

The designations Liv (for living room) and pendant_lamp_front come from the Hue bridge configuration and reflect the user settings at the time of Hue system commissioning.

When the last hierarchy level is expanded, ioBroker displays the usable objects. At this point, it is sufficient to change the value for the object in the Value column from false to true to switch on the pendant_lamp_front (Figure 7). In response to this, the level object is automatically updated to 100 and bri (brightness) to 254.

Since the example is a multicolored LED luminaire, it makes sense to bring some color into play. If the effect object is described by the colorloop value, the Hue light permanently changes color. The value none stops the show. More information about the Hue color model is available at the Phillips Hue developers website [4].