Busch-Jaeger Free@Home

Hello Stian.

Have you already found a way to make the binding run stable under OH 3 M4?

With best regards

I am working on it, but keep struggling with dependencies/JAXB implementation due to core/distro changes made for the OH 3.0M versions.

Will post the result if/when I make a break-through.

Hi all!

I’m new here and just starting to setup OpenHAB with my Busch Jäger installation. So far it works fine! Thanks a lot for all the efforts!

I’m wondering how I can use my Sensors (6221/1.0 & 6221/2.0) in OpenHAB rules? They are just deteced as Dummy Things. Do I have to set them up as manually as a Window Sensor?

Beste regards

Continuing the discussion from Busch-Jaeger Free@Home:

Hi @kjoglums I recognized that I have to add all my actuators manually (dimmer, shutter, switches) because I have a decentralized installation of Busch-Jaeger free@home:

In the model this combo devices are represented in the model as:
ch0000 -> sensor rocker left (functionID 1)
ch0003 -> sensor rocker right (functionID1)
ch0008 -> actuator (e.g. here dimmer) (functionID 12)

Why are these combo devices are not parsed and auto discovered. I would have assumed at least the actuator channels come up as they have the most value inside open hab. But also the sensor rockers could be used to control out of free@home towards open hab.

If I see right it would be the best way to parse all supported devices by function ID nevertheless in which physical product of BJ they are exposed?

You are probably right that FunctionIDs would be the best approach for getting all possible devices/functionality autodiscovered. However, this would require some heavy code refactoring.

As per now, the binding autodiscovery is based on sending a “get all” request to the bridge, and a list of devices is received and parsed into correct Thing type. It is the parsed DeviceTypeId which is used to categorize devices into correct OH Thing type, whereas the OH Thing type then automatically is set up with default channels and idp/odp known for the device.

If the parsed DeviceTypeId is not recognised from autodiscovery, the devices will end up as Dummy item in your inbox. It should be fairly easy to update the binding if the DeviceTypeId is provided (as shown from inbox discovery). Wireless DeviceTypeId “A039” is for instance already included for autodiscovery.

Your DeviceTypeIds ‘1000’ and ‘1002’ is not set up for autodiscovery in the binding as per now, that is why you see the sensors as Dummy item. You could set up the devices manually, and then I will try to include the DeviceTypeIds for autodiscovery in a new version of the binding.

That would be great. But to be honest, I do neither see sensor nor actuator auto discovered for this devices in my inbox. I have no dummy device in my inbox. But I see the rest like virtual switches, scenes and all thing pass through Philips hue.

That is why I really started to set up my devices totally manually by adding e.g. dimmer by dimmer and fill the “thing template”

Then it could be your devices are recognised/set up as a different Thing type. You could then search within inbox for ABB serial to check what your devices are discovered as.

i see no devices related to that with ABBxxxxxxx serial number in my inbox. That is why I started to do it manually

That is really strange, as every device connected to the SysAp is sent from the SysAp and parsed as part of the “get all” request. Are you sure you have enabled Dummy things? I.e. selection (show more) when creating bridge in Paper UI.

Finally, after quite a cumbersome road to get the F@H binding fit for OH 3.0.x, I believe I have a version which could be made available for testing purpose.

Note: It will only work for OH 3.0.x.

Please feel free to test, and report any issues/problems.


1 Like

@kjoglums thanks for your update.

I’m not able to connect to my sysap in OH3. In the Webinterface the Thing shows


Can not connect to SysAP with address: 192.x.x.x

In the logfile:

2020-12-28 17:02:03.289 [WARN ] [ent.WebSocketConnectionConfiguration] - Websocket session being created: ws://192.x.x.x:5280/xmpp-websocket/
2020-12-28 17:02:03.298 [WARN ] [ent.WebSocketConnectionConfiguration] - Handshake response received from server: [xmpp]
2020-12-28 17:02:03.300 [WARN ] [ent.WebSocketConnectionConfiguration] - Preparing to open Websocket Stream Session
2020-12-28 17:02:08.118 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'freeathome:bridge:freeathome' takes more than 5000ms.

I’m using SysAP2 with Firmware 2.6.0.

Do you have any idea or do you need more infos?

I’m having the same error with OH3, SysAp1/Firmware 2.5.5, but not always!

A restart of the bridge does not seem to have any effect, but often after one or two restarts of OpenHab itself the connection works. Seems to be some kind of race condition…

This seems to be related to a known issue also for OH 2.5.x, believed to be related to JAXB startup. Would suggest trying a couple of OH reboots.

Alternatively, try enabling debugging to provide more details for the bridge initialisation process.

Hello there :slight_smile:

I’m using openhab3 with the new binding for openhab3. I’ve got a problem, that a virtual switch, which is created in f@h, can’t be switched. So if it is OFF and clicking on it in the App, it is written that something will be processed and then the switch is at OFF again and doesnt switch to ON. After using the swagger to set the switch to ON with the lokal API, the switch in f@h app is ON. But if i want to set it to OFF, using the app, it is not possible.

So it looks like the binding is not compatible with the virtual switch and lokal API?

Someone got the same problem?

Thank you!

The binding is local based only, reading/sending updates via websockets over local network.

I am still on F@H 2.5.5 firmware version (SysAp 1), and my virtual switches were created using cloud FHAPI, and my virtual switches work as supposed. Uncertain if virtual switch created using local API differ in any way. Would not assume so, as SysAp still would report updates via websocket.

Did you autodiscover virtual switches within binding?

How can i set it to autodiscover in openhab3? Is it “Dummy things enabled”?

From Settings/Things you can add (+) and run a scan for all F@H Things.

Virtual switches should be discovered as such, but you should also have dummy things enabled for your bridge to see if they are discovered differently from binding defined virtual switches.

There isnt a problem in finding the virtual switches. The Problem is, that the virtual switch cant be switched using the App or Webinterface. So it looks like openhab is not able to give a feedback to the switch or something like that. Another user told me that it is possible with openhab 2.5.11

So could it be that there is a problem with openhab3?

The reason for asking was to check if virtual switch generated via local API was discovered differently than virtual switch generated via cloud FHAPI. Apparently, your virtual switches are discovered correctly.

As mentioned, my virtual switches work as before, also in OH 3.0, so I do not believe there should be an issue related to version.

Could you check what channel and idp/odp your virtual switch operate under?