Busch-Jaeger Free@Home

the deciveID is B008 not B007.

This ist one of the 8 switches found in the inbox. They are working.

But this is not working.

How can I identify idp/odp values. Is this only possible by ABB development program? I do not have a account.

Ah, ok, then I understand better.

Have you also tried creating (manually) a Wndow sensor for your binary? E.g. ch0000 / odp0000 / odp0001?

If still not working, we would need to find the correct idp/odp for the binary. Could either be found using web developer tools for your browser while logging in to your Sysap. You could see all messages happening on the bus (although encrypted), and you would need to identify the correct device / response. Alternatively, as the best option, would be the ABB developer program / using Postman software.

i just upgraded my system access point from 2.1.7 to 2.5.
so my connection is not working anymore.
what do i have to do, to make it work again?
Could not find a working info.
Thanks a lot,

Maybe same here, additionaly I rebooted my system incl. change of IP-Adress of my OH-Inst.

Well, little details/logs to go by…

Which OH version are you running? Have you been using the Paper UI installed version of the binding? If so, you would need to uninstall this version.

Then you could have tried the approach described further above in this thread, which is confirmed to work for SysAp 2.5.0 / OH 2.5.4 Release Build (summarised below):

  • ssh into OpenHab service
  • Stop OpenHab service: sudo systemctl stop openhab2.service
  • Remove old F@H jar file from your openhab2-addons folder (if present)
  • Remove tmp files: sudo rm -rf /var/lib/openhab2/tmp/*
  • Remove cache files: sudo rm -rf /var/lib/openhab2/cache/*
  • Remove backup files: sudo rm -rf /var/lib/openhab2/jsondb/backup/*
  • Remove cache: sudo openhab-cli clean-cache
  • Restart OpenHab service: sudo reboot
  • Recommended to update OH to 2.5.4 (if not already done)
  • Download and add jar file to your openhab2-addons folder: F@H 2.5.5-SNAPSHOT
  • If not able to establish connection, try rebooting OH once again
  • If still having problems to get your things ONLINE, enter openhab/karaf console and run
bundle:restart org.openhab.binding.freeathome

Sorry for my late reply. I didn’t have much time and in addition some problems to get the developer role. But finally I could follow your instructions. So here is the output of Postman. Seems the binary actuator is using output odp000c for the state.
I hope this helps for further developing of the binding. If you need more information let me know.
Once again many thanks for your work.

    "devices": {
        "channels": {
          "ch0000": {
            "displayName": "Küche",
            "floor": "01",
            "functionID": "000f",
            "inputs": {
              "idp0000": {
                "pairingID": 256,
                "value": ""
              "idp0001": {
                "pairingID": 272,
                "value": ""
              "idp0002": {
                "pairingID": 288,
                "value": ""
            "outputs": {
              "odp0000": {
                "pairingID": 1,
                "value": ""
              "odp0001": {
                "pairingID": 16,
                "value": ""
              "odp0002": {
                "pairingID": 32,
                "value": ""
              "odp0003": {
                "pairingID": 33,
                "value": ""
              "odp0004": {
                "pairingID": 2,
                "value": ""
              "odp0005": {
                "pairingID": 3,
                "value": ""
              "odp0006": {
                "pairingID": 40,
                "value": ""
              "odp0007": {
                "pairingID": 309,
                "value": ""
              "odp0008": {
                "pairingID": 4,
                "value": ""
              "odp0009": {
                "pairingID": 37,
                "value": ""
              "odp000a": {
                "pairingID": 38,
                "value": ""
              "odp000b": {
                "pairingID": 39,
                "value": ""
              "odp000c": {
                "pairingID": 53,
                "value": "1"
              "odp000d": {
                "pairingID": 6,
                "value": ""

Appreciate the update. I have now updated the binding with Binary Sensor as Thing type, having a “read output” channel for ch0000 / odp000c (odp000c with pairingID 53 would then be equal to window sensor). So your “B007” devices should now be autodiscovered as Binary Sensor (window sensor), and you should (hopefully) be able to read ON/OFF state:
F@H 2.5.5-SNAPSHOT.jar

And @MundM, based on the input provided for the “B007” Binary device, I have also tried the same input for the “B008” device. Meaning, the “B008” device should be discovered with 8 switch actuator channels, as before, but I have tried to also implement the binary channels. Based on your previous input, I have added autodiscovery for binary channels under ch0000-ch0007, then assuming odp000c (pairingID 53 = window sensor) would be providing ON/OFF state (as for the “B007” device).


for me does not funktion this combnination of odp and idp for windo sensor at by binary actor BI-M-4.0.1 with 4 channels.
I has tests some idp and odp combinations which also mentioned in this thread:

Could somebody help me how I can check/read out the correct odp/idp combination via Postman?
At the free@home userinterface i can follow the sensor by type 0x0035 for ON/OFF action.

Thank you for your help.


If you try the version from my previous post today, this version is updated to include Binary Sensor as Thing type, meaning combination Binary sensor / window sensor.

This version should enable you to create a Binary sensor manually, and you should be able to read state of your window sensor.

NOTE: If you have other devices connected to your binary, this will most likely not work according to the link you provided. Nor will the binding differentiate between NO / NC. To be able to handle different combinations by autodiscovery, we would need to get a list of devices as shown in Paper UI inbox when having dummy things enabled (i.e. to get deviceTypeID, deviceTypeName etc). For a given deviceTypeID (as shown in PaperUI inbox) we could then used the deviceTypeName to create correct things for given channels.


sorry maybe I´m a little bit confused. I used your new version and at the binary sensor have 4 inputs and I have 4 window sensors connetced (Channel a,b,c,d)

(post withdrawn by author, will be automatically deleted in 96 hours unless flagged)

Here the log of webinterface:

Within Paper UI, under Configuration/Things you could try to add a new thing (+ sign). Then you choose Free@Home and “add manually”. You should be able to choose “Binary Sensor” (which currently is set up to handle window sensors, meaning output state from odp000c).

For configuration, you enter the serial (ABB12345) for your 4-fach binary actor. Then, under Configuration Parameters, you set your desired channel, ch000a for instance (you repeat creating thing for each of your channels).

After new thing is created, you should be able to read state from your window sensor connected to your binary channel.

To be able to implement this as part of autodiscovery, I would need to see your inbox discovery similar to Link when you have “dummy things enabled” (configured under your bridge in Paper UI).


I had done this way with e.g ch0000, ch0001, ch0002 and ch0003…but no function.
Now I had checked with ch000b for example but no function :frowning:


Have you also tried to change the state of Binary sensor/window contact? Try to change from open to close or vice versa.

The binding is set up to read data from the F@H bus, but if there is no data to read for your specific binary sensor/window sensor, there will be no update in OH.

Yep…I`m walking to my window some times till the last 3 days to find the correct ipd/odp combination also using as switch and now as binary.
Done also at window at my kitchen…

I have no idea why no function.


I have found the problem :wink:
Now it function.

The odp must be in format “odp000C”, the “C” in big letter :wink: :slight_smile: :slight_smile:
It´s very important because in small letter does not function.


Appreciate the update. The binding in the link above is now updated with capital “C” for odp.

Also, for autodiscovery - would assume this would be the “B005” device? Does it have both 4 swtich channels and 4 binary channels, or only 4 binaries?


only 4 binaries and device shows to me as DUMMY thing “B007” before your sharing of update here:


Hi Stian,

with the newest version of the binding I get the following errors for all my thermostats. All other things works very well.

2020-05-10 19:28:53.418 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing ‘freeathome:thermostat:ABB700D00000’: null

java.lang.NullPointerException: null

at org.openhab.binding.freeathome.internal.FreeAtHomeUpdateHandler.RegisterThing(FreeAtHomeUpdateHandler.java:63) ~[?:?]

at org.openhab.binding.freeathome.internal.FreeAtHomeUpdateHandler.Register(FreeAtHomeUpdateHandler.java:56) ~[?:?]

at org.openhab.binding.freeathome.internal.handler.FreeAtHomeBaseHandler.registerUpdate(FreeAtHomeBaseHandler.java:93) ~[?:?]

at org.openhab.binding.freeathome.internal.handler.FreeAtHomeBaseHandler.initialize(FreeAtHomeBaseHandler.java:126) ~[?:?]

at sun.reflect.GeneratedMethodAccessor31.invoke(Unknown Source) ~[?:?]

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_252]

at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_252]

at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]

at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]

at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_252]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]

at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]