Busch-Jaeger Free@Home

@kjoglums I tested it, I will gladly share feedback on a github issue as mentioned above.

I have not tried free@home binding using jar file directly. @kjoglums, I can also help you with some changes to get this binding working effectively. I will use the binding from your link and update you back.

will this binding be available through openhab repo directly in near future!

Feel free to comment.

As mentioned previously, there are no immediate plans to try to implement the binding into the official OH repo. This is due to a couple of things:

  1. The binding makes use of the XMPP.rocks library. Although the library is customised to be able to achieve websocket communication with the F@H SysAp (F@H not following official websocket protocol). Hence, a /lib folder with the customised library is included in the binding. Uncertain if this will be approved according to OH guidelines.
  2. Heavy revision/refactoring of the code will be required in general to meet OH developing guidelines.

As of now, the binding code could be found:
OH 2.5.x

OH 3.0

Hi Stian,
I finally had the chance to try to integrate my roller shutters again … Unfortunately they are not working yet. I’m running on F@H 2.4.2 and updated OH to 2.5.8, your binding and the Homekit bridge (2.5.8). All things are online and I can control all things in PaperUI. Also, all things are working through Homekit - Except for the roller shutters. I have no idea of what I am doing wrong. I can configure the shutter through Homekit and see the communication on the log viewer. All seems normal, but the shutters are not moving … Do you have any idea? Any help is greatly appreciated … Thanks

I seem to be getting closer to identifying the problem:
Homekit sends absolute positions when controlling blinds / roller shutters, whereas the f@h bridge only understands UP and DOWN.

Can someone confirm that? Is there a way to adapt that??

Thanks for your help!

Uncertain how HomeKit communicates/interacts with openHAB, but would suggest looking into OH Transformation Services, alternatively use rules to convert commands.

Btw: The F@H binding also supports absolute position through the percentage channel. So a rule to convert from HomeKit commands to F@H commands should be fairly easy:

rule "Roller shutters"
  Item Your_HomeKit_Item received command
  Your_F@H_Raffstore_Percentage_Item.sendCommand(receivedCommand as PercentType)
1 Like

Stian, you’re the best! Works like a charm!!! Thank you so much!!

Can you explain your solution in detail ?

I Couldn´t realize my shutters :frowning:

Dimmer GF_LivingRoom_Shutter_Percentage “Wohnzimmer Prozent” (gShutter, GF_LivingRoom) {homekit=“WindowCovering, WindowCovering.TargetPosition, WindowCovering.PositionState, WindowCovering.CurrentPosition” [DECREASING=“DOWN”,INCREASING=“UP”]}

I only can see the Status in percentage

Hi all,

just wanting to let you know, that I had the same issue with the Bridge (XMPP connection lost / can not connect to SysAP with address …) after I updated openHAB to version 2.5.9 (coming from 2.5.5 with Binding version 2.5.5).

I then updated the binding to 2.5.9 (found in that thread) and also run an update on the B+J side (now version 2.5.4).

I was still getting the errors and all my B+J devices were offline.

Doing the procedures outlined in the thread did not help initially (Busch-Jaeger Free@Home)

In my successful attempt to get B+J back to work, I created a completely new user on the B+J SysAP side (simple name, simple pw), just for the openhab integration (Installer Account Type (as it also was with the user before)). I then followed the steps again (remove bridge, stop openHab, remove tmp, cache, backup, restart openhab). Install bridge in PaperUI with new browser (not using the same ThingID!) and subsequently editing all my things to let them know their new bridge. This worked for all things except the raffstores: here I had to recreate the things completely and then update the new thing number in my items file to get them back to live. (Fun Fact: to be able to remove the old raffstores, I had to edit them, link them to the new bridge and only then I was able to remove them…). I guess the raffstore piece is related to the latest changes reg. raffstore percentage action I read here in the thread.

All in all: a lot of work and experiments after such a mundane task like updating openHab to a current (stable) version. But happy it works again :slight_smile:

Hope that my post can be of help to someone who is stuck with the same or similar issues.

1 Like

How did you config. Your shutters :slight_smile:
See my post above :frowning:
How dir you config it for homekit

You need to address your question to @Trinity, as he is the one using HomeKit.

Hello guys,

anybody here, who is running the free@home binding with Busch-Jäger Software version 2.5.5?
Actually, my bridge is not working neither on my raspberry nor on my Synology NAS.

Do only I have this problem or also anybody else?

About the error: “XMPP connection lost”
Can I see any log-file for the XMPP-connection?

Here, you can find my log:

2020-10-18 14:36:41.180 [hingStatusInfoChangedEvent] - ‘freeathome:bridge:d6e6d481’ changed from UNINITIALIZED (DISABLED) to INITIALIZING

2020-10-18 14:36:41.888 [WARN ] [ent.WebSocketConnectionConfiguration] - Websocket session being created: ws://

2020-10-18 14:36:41.999 [WARN ] [ent.WebSocketConnectionConfiguration] - Handshake response received from server

2020-10-18 14:36:42.015 [WARN ] [ent.WebSocketConnectionConfiguration] - Handshake succeded: Sec-Websocket-Protocol = XMPP

2020-10-18 14:36:46.345 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing ‘freeathome:bridge:d6e6d481’ takes more than 5000ms.

2020-10-18 14:36:52.133 [hingStatusInfoChangedEvent] - ‘freeathome:bridge:d6e6d481’ changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): XMPP connection lost

2020-10-18 14:36:52.530 [hingStatusInfoChangedEvent] - ‘freeathome:bridge:d6e6d481’ changed from OFFLINE (BRIDGE_OFFLINE): XMPP connection lost to OFFLINE (COMMUNICATION_ERROR): Can not connect to SysAP with address:

As mentioned previously in this thread: Do yet another OH reboot when you see the XMPP connection lost error.

Hello Stian,

Thanks for prompt Feedback. I did several reboot via command sudo reboot, but it was not working after this.
But yesterday evening, I did an reboot with unplugging the Power supply from the raspberry. This helped and the bridge went ONLINE. Don’t know, what’s the difference.

So, I also can give Feedback, that Version 2.5.5 of Free@Home is working with the binding.



i use version 2.5.9 of the free@home binding on my Openhab version 2.5.9 on my Raspberry Pi. I create the items with visual studio code. A part of my item-file:

Switch Fenster_Buero “Bürofenster” {channel=“freeathome:binary:ABB…_ch0000:binary_switch_channel”}
Switch Lampe_Buero “Bürolampe” {channel=“freeathome:switch:ABB…_ch000C:fh_switch_channel”}

At first it was possible to switch on the light in the basic UI with the item Lampe_Buero and with the item Fenster_Buero. If i open or close the window, there are no changes at the switch-butten in the basic UI. In free@home everthing is fine, no conections between the two switches with actions,scences etc. In the free@home-app i can also see, if windows are open or close.
After a reboot of openhab and free@home i can only switch on the lights in the basic UI with the item Lampe_Buero, but no more with the item Fenster_Buero. If i open or close the window, there are still no changes by the switch button in the basic UI.
Please tell me what i can do, that i can see in the basic UI, if the window is open or closed.

Thank you very much

What is the DeviceTypeId (as recognised from autodiscovery using Paper UI)? ch000C is not in use by any of the things as covered by the binding autodiscovery.

DeviceTypeId “2042” is recognised as a window sensor, operating under ch0001, using odp0000 for reading switch status (open/close) and odp0001 for reading percentage value.

DeviceTypeId “B005” & “B007” (single window sensor) is recognised as binary sensor operating under ch0000. “B008” (8-fach actuator with 8 binary channels) is also recognised as binary sensors, operating under ch000 + i (i being the number of channel being used). odp000C is used to read status ON/OFF.

I do not have the window sensor / binary switch myself, but would try a item configuration like:

Window sensor


Hello Stian,

thanks you for your answer. I have the 8-fach actuator with 8 binary channels.
I give you some screenshots form an other binary channel, because with this channel i did not any tests. So this channel is original, but i have the same problem. I hope, this is better for you, because my english is not the best.

The things:
see Bild 1 below

If i edit this thing:
see Bild 2 below

The item:
see Bild 3 below

If i create a item in Visual Studio of the chanel, the item is:

Switch ⒶWohnGekipptSensorSchaltaktor88FachREGB008ABB21[DELETED]51Ch0005BinarySwitchChannel “Activate” {channel=“freeathome:binary:ABB21[DELETED]51_ch0005:binary_switch_channel”}

I change this to:

Switch fBad2 “Bad 2” (Fensterpruefung) {channel=“freeathome:binary:ABB21[DELETED]51_ch0005:binary_switch_channel”}

So i think, i have the last configuration, that you mean, but if i open the window, there are no changes in the Basic UI.

The configuarion in free@home is this an in works in free@home:
see Bild 4

I have a ch000C in every 8-fach actuator. It is the first Switch (2. = ch000D; 3 = ch000E; 4. = ch000F; 5. = ch0010; 6. = ch0011; 7. = ch0012; 8. = ch0013)
see Bild 5

This 8 channels are fine.

I hope, the images help.

The B008 device is previously confirmed to be working under ch000 + i, using odp000C to read output status ON/OFF. Sure the window you are testing has the sensor connected to ch0005?

You could test this easily: From SysAp webinterface, settings, free@home monitor, “Start” - Open your window and see what is reported in the monitor. You should then see device serial / channel being activated.

Hello Stian,

yes, the window i tested is connectet with ch0005.
I also tested version 2.5.5 of the binding and clear al caches like your description vom Jan 5 (Post 179). No changes. After that i made a upgrade back to version 2.5.9. No changes at the binaryswitch, but now i have the problem with one light too (only one, all other work fine) . So i think, there ist something wrong in my system.
In the next days i make everything new (fresh install of openhab) and then i will see, what happen.

I found the error with the light-switch. It was my fault (typing error - i deleted one letter in the channel).
I made a fresh install of openhab (now to version 2.5.10), but the binary-switches are still without function.