Elro Connects Binding (Beta)


All functionality in this beta version is now available in the snapshot version of openHAB. If you wish to use this enhanced version, please upgrade to the snapshot, or the next milestone version 3.3.0.M5 as soon as it is available. You can still manually download the beta binding jar from this post and drop it in your addons folder if you do not wish to upgrade at this point.

ELRO Connects Binding

The ELRO Connects binding provides integration with the ELRO Connects smart home system.

The system uses a Wi-Fi Hub (K1 Connector) to enable communication with various smart home devices.
The devices communicate with the hub using 868MHz RF.
The binding communicates with the ELRO Connects system and K1 Connector using UDP in the local network.
Optionally, the Elro Connects account can be used to retrieve the available K1 Connectors with their properties from the ELRO Connects cloud.

The binding exposes the devices’ status and controls to openHAB.
Console commands support adding and configuring devices on the hub.
The K1 connector allows setting up scenes through a mobile application.
The binding supports selecting a specific scene.

Many of the sensor devices are battery powered.

Supported Things

The ELRO Connects supported device types are:

  • Elro Connects account: account
  • K1 connector hub: connector
  • Smoke detector: smokealarm
  • Carbon monoxide detector: coalarm
  • Heat detector: heatalarm
  • Water detector: wateralarm
  • Windows/door contact: entrysensor
  • Motion detector: motionsensor
  • Temperature and humidity monitor: temperaturesensor
  • Plug-in switch: powersocket

accountis a bridge thing type that will allow allow automatic discovery and configuration of the available K1 connectors on the specified ELRO Connects account.
This bridge is optional.
It is used to discover the required K1 connector hub(s), using a call to the ELRO Connects cloud.
Without the account bridge, the connector bridge needs to be defined manually.
If no account bridge is defined, all communication between openHAB and the ELRO Connects system will be local, not using the ELRO Connects cloud.

The connector is the bridge thing representing a K1 connector.
All other things are connected to the connector bridge.

Testing was only done with smoke and water detectors connected to a K1 connector.
The firmware version of the K1 connector was at the time of testing.


The ELRO Connects account cannot be auto-discovered.
The account bridge is optional, but helpful to discover the K1 connectors on an ELRO Connects account and configure them.
All online K1 connectors configured on the account will be discovered.
Notice that K1 connectors in another network than the LAN will also get discovered, but will not go online when accepted from the inbox without adjusting the connector configuration (set the IP address).

The K1 connector connector will be auto-discovered when an ELRO Connects account bridge has been created and initialized.
It can also be configured manually without first setting up an account bridge and linking it to that account bridge.
Once the bridge thing representing the K1 connector is correctly set up and online, discovery will allow discovering all devices connected to the K1 connector (as set up in the Elro Connects app).

If devices are outside reliable RF range, devices known to the K1 hub will be discovered but may stay offline when added as a thing.
Alarm devices can still trigger alarms and pass them between each other, even if the connection with the hub is lost.
It will not be possible to receive alarms and control them from openHAB in this case.

Thing Configuration

ELRO Connects account

Parameter Advanced Description
username Username for the ELRO Connects cloud account, required
password Password for the ELRO Connects cloud account, required

K1 connector hub

Parameter Advanced Description
connectorId Required parameter, should be set to ST_xxxxxxxxxxxx with xxxxxxxxxxxx the lowercase MAC address of the connector. It will be discovered when an account bridge has been initialized. This parameter can also be found in the ELRO Connects mobile application
ipAdress Y IP address of the ELRO Connects K1 Connector, not required if connector and openHAB server in same subnet
refreshInterval Y This parameter controls the connection refresh heartbeat interval. The default is 60s
legacyFirmware Y Flag for legacy firmware, should be set to true if ELRO Connects K1 Connector firmware has version lower or equal to 2.0.14. If the connector is discovered from the account, this parameter will be set automatically. The default is false

Devices connected to K1 connected hub

Parameter Description
deviceId Required parameter, set by discovery. For manual configuration, use the ´elroconnects devices´ console command to get a list of available devices. It should be a number


ELRO Connects account

The account bridge thing does not have any channels.

K1 connector hub

The connector bridge thing has only one channel:

Channel ID Item Type Access Mode Advanced Description
scene String RW current scene

The scene channel has a dynamic state options list with all possible scene choices available in the hub.

The connector also has an alarm trigger channel that will get triggered when the alarm is triggered for any device connected to the hub.
This will also trigger if an alarm on a device goes off and the thing corresponding to the device is not configured in openHAB.
The payload for the trigger channel is the deviceId for the device triggering the alarm.

Smoke, carbon monoxide, heat and water alarms

All these things have the same channels:

Channel ID Item Type Access Mode Description
muteAlarm Switch RW mute alarm
testAlarm Switch RW test alarm
signal Number R signal strength between 0 and 4, higher is stronger
battery Number R battery level in %
lowBattery Switch R on for low battery (below 15%)

Each also has a trigger channel, resp. smokeAlarm, coAlarm, heatAlarm and waterAlarm.
The payload for these trigger channels is empty.

Door/window contact

The entrysensor thing has the following channels:

Channel ID Item Type Access Mode Description
entry Contact R open/closed door/window
signal Number R signal strength between 0 and 4, higher is stronger
battery Number R battery level in %
lowBattery Switch R on for low battery (below 15%)

The entrysensor thing also has a trigger channel, entryAlarm.

Motion sensor

The motionsensor thing has the following channels:

Channel ID Item Type Access Mode Description
motion Switch R on when motion detected
signal Number R signal strength between 0 and 4, higher is stronger
battery Number R battery level in %
lowBattery Switch R on for low battery (below 15%)

The motionsensor thing also has a trigger channel, motionAlarm.

Temperature and humidity monitor

The temperaturesensor thing has the following channels:

Channel ID Item Type Access Mode Description
temperature Number:Temperature R temperature
humidity Number:Dimensionless R device status
signal Number R signal strength between 0 and 4, higher is stronger
battery Number R battery level in %
lowBattery Switch R on for low battery (below 15%)

Plug-in switch

The powersocket thing has only one channel:

Channel ID Item Type Access Mode Description
powerState Switch RW power on/off

Console Commands

A number of console commands allow management of the Elro Connects K1 hub and devices.
This makes it possible to add new devices to the hub, remove, rename or replace devices, without a need to use the Elro Connects mobile application.
The full syntax and help text is available in the console using the elroconnects command.

Full Example


Bridge elroconnects:connector:myhub [ connectorId="ST_aabbccddaabbccdd", refreshInterval=120 ] {
    smokealarm 1 "LivingRoom" [ deviceId="1" ]
    coalarm 2 "Garage" [ deviceId="2" ]
    heatalarm 3 "Kitchen" [ deviceId="3" ]
    wateralarm 4 "Basement" [ deviceId="4" ]
    entrysensor 5 "Back Door" [ deviceId="5" ]
    motionsensor 6 "Hallway" [ deviceId="6" ]
    temperaturesensor 7 "Family Room" [ deviceId = "7" ]
    powersocket 8 "Television" [ deviceId = "8" ]


String Scene            {channel="elroconnects:connector:myhub:scene"}
Number BatteryLevel     {channel="elroconnects:smokealarm:myhub:1:battery"}
Switch AlarmTest        {channel="elroconnects:smokealarm:myhub:1:test"}


Text item=Scene
Number item=BatteryLevel
Switch item=AlarmTest

Example trigger rule:

rule "example trigger rule"
    Channel 'elroconnects:smokealarm:myhub:1:smokeAlarm' triggered
    logInfo("Smoke alarm living room")


Version 0.1

  • initial (beta) release

Version 1.0

  • released in OH 3.3M3

Version 1.1

  • Added signal strength device channel
  • Added K1 hub alarm channel with originating device ID payload
  • Added console commands to get devices on K1 hub and refresh device status
  • Added console commands to add, remove, rename, replace devices

Version 1.2

  • Added account bridge, support automatic discovery of hubs
  • Support older firmwares


binding jar

source code


Is it a zwave implementation?

No, it is not ZWave. I don’t know the specific protocol.

1 Like

Thanks Mark,

I’m interested in buying a couple of smoke detectors (+the hub). I’m wondering if the siren is implemented in each smoke detector, AND in the hub as well. And if they can sound independently OR together. Is it something we can configure?

And, more important as this seems not present in other detectors, we can trigger the siren also for other warnings. Is that correct?


Hi Andrea,

The siren is implemented in each smoke detector. When they are coupled with the hub, they will also all be coupled between them and will sound when one of them is triggered. They cannot sound independently when connected to the same hub. You could couple them to multiple hubs, but that would decouple their direct link, so they will not automatically sound together anymore (each set connected to different hubs independently).
The binding can trigger a test, which will sound all detectors connected to the same hub. The test sound is less loud than the real alarm signal (although I still find it more than loud enough). The test cycle takes about 40s, will sound all detectors, and cannot be interrupted.

The most important thing to me is the working of the smoke detectors when there is smoke, under all circumstances. That means they all sound, even when the hub is out (for instance, electricity is off because of fire). All the rest is extra. I find it very important they keep on working without the hub.

1 Like

Yes absolutely. The issue I see is, in case of emergency, you don’t know where is the fire (or where is starting), because they will sound all together.

Any possibility to solve it? To let openhab know where is the issue?

An idea should be monitoring the temperature. But if the temperature is already high, you don’t have any possibility to do anything


edit: wait, the sound is everywhere, but we should see where the smoke is detected right? Because only the affected detector will trigger the “smokeAlarm” channel, right?

Correct. And the sound from the triggering device should also be different, according to their FAQ.

1 Like

fantastic. I will give them a try. Just buying, I’ll let you know as soon as I’ll start the tests :slight_smile:

The first issue I see is: I have the K1 on a different subnet than OH3. And it seems they are not able to see each other.

Just to be clear: the application is working perfectly, and I’m now able to use the app on a different vlan/subnet. I’ve also added a smoke detector in the app, without any issue. At the moment the communication between OH3 and K1 is not working.

Is the binding considering the Mac address after “ST_” to try to find it in the lan? any chance to add the K1 IP directly? I think we should add a field “IP address” in the “Show advanced” features, before “Refresh interval”, just for people like me that has a complex network infrastructure at home. Otherwise, the normal “connector ID” should be fine, for “flat” deployments.

First impression of the product: pretty good.

I hope @Mherwege you can help us :slight_smile: :slight_smile: :slight_smile:

The binding finds the connector address by broadcasting an udp packet. Without this, the hub does not start communication. But you can change the broadcast address to include your subnet. It is a general openHAB network setting.

Not sure I understand. The broadcast is specific per subnet. I don’t think they will be able to work.

Perhaps you mean a multicast address?

My OH3 is on subnet A, the hub is on subnet B

Sorry, yes, a multicast address.

Mmm I don’t know how to solve it :frowning: Mmmmm… I don’t like too much to have OH on the same subnet of the IoT devices … mmm

Did you try as the default broadcast address setting in OH? Depending on your network, that may work.
I need to investigate if I can work with a fixed IP. Adding a parameter for it is not the issue. I am not sure it will work. I believe the app uses the cloud for connection when not in the same subnet, and I want to avoid that.

1 Like doesn’t work.

If you like to try to implement a fixed Ip, I can test for you


In the meantime I’ve moved the K1 in OH3 subnet, and it works like a charm.

Note: we need to add the Smoke Detector in the ELRO app before discovering in OH3.


Happy to hear it is working. I will see what I can do on the fixed IP.
Indeed, the binding does not implement connecting the detector to the K1 hub. That needs to be done in the app. Once it is there, it will be discovered. I will make that explicit in the doc.

1 Like

Another thing: wifi supported is WPA2.

WPA3 or WPA2-Enterprise not supported.

But no issues in case of hidden ssid (not recommended).

I have a test version with an extra IP Address parameter available. You can download it here. You will need to remove the bridge and recreate it for the extra (advanced) parameter to appear.

1 Like

Unfortunately I’m not able to test now, I’ll do my best in the next few days.

I’ve already changed my infrastructure to be fully compliant with the original version :slight_smile:

btw: I see there is a “trigger” channel SmokeAlarm, what is the output and how can I match it with an item? Sorry, I don’t have experience with trigger channels … can I use it only in a rule?

thanks again