Busch-Jaeger Free@Home

Correct.

For the motion detectors with actuator I managed to do a workaround, as within the F@H web service it is possible to set up a “trigger” along with actual motion detection (switch trigger). So now I have created some events/actions within F@H webservice which creates a trigger on motion which is recognised as the motion switch within the openhab binding.

Meaning I have now successfully implemented rules for my motion detectors (with relay) within OpenHab, even though not having the motion detectors directly wired to any lights.

@ruebox I’ve created an issue and uploaded the HAR file.

I’ve updated to Firmware 2.2.4 about 2 days ago.
I got the same Problems as phil2.

Maybe I can support you in reverse engineering:
As soon as I will find time this weekend I’ll look into the “Roller shutting” issue
and try to find out the adresses you mentioned.

1 Like

Any updates for this one?

I got the same issues updating to FW version 2.2.4, now not able to achieve bridge communication through OpenHab.

i am still on fw 2.1.7 but since some days, some of my blinds do not show any percentage anymore if they are moved via the physical switch of the blind.
i tried to remove the items and readded them.
any idea what could be the problem?
thanks a lot

Hi ruebox,

Is it possible to add the wireless actuators?

thanks

Hopefully a working fix for the F@H FW 2.2.4 version:

https://github.com/ruebox/openhab2-addons/issues/47#issuecomment-483874778

Hi guys,

Sorry for the long period of silence. The f@h binding is still maintained, but as it is a hobby project I could not react more fast.

@kjoglums: thx for investigating the changes that would be necessary to operate with the latest FW. Could you please provide me a pull request or at least a bit hub commit. I will then incorporate the changes to the head and generate a new marketplace package.
I will try to schedule this for the upcoming weekend.

@kjoglums: it would be great if you could beta test the version then.

Best

Hi there,

FYI. Just had a chat with @kjoglums who
provided code adaptions for supporting the
Latest FW. Big thx from my side.

We will try to incorporate @kjoglums changes into
The binding for providing a marketplace version
Supporting the latest FW and some other stuff.

Still takes a little bit of time … :slightly_smiling_face:

Best

Hi @kjoglums,

thanks for your great work. I updated today and works. I have only one issue.

This log entry every 1 - 3 seconds:

2019-04-26 21:14:06.814 [WARN ] [websocket.codec.XmppWebSocketDecoder] - Decoding stream feature

2019-04-26 21:14:07.114 [WARN ] [websocket.codec.XmppWebSocketDecoder] - Decoding stream feature

2019-04-26 21:14:10.466 [WARN ] [websocket.codec.XmppWebSocketDecoder] - Decoding stream feature

Do you know what is wrong? Or is it normal?

Hi @Jens_Hoffmann,

Yes, this is actually perfectly normal based on code as is.

I have made use of Rocks XMPP library which has an inbuilt websocket connection code. However, as our Busch-Jaeger Free@Home SysAp is following an old websocket connection protocol (compared to Rocks library which is using a more recent protocol, ref IETF), I was in need of modifying the Rocks library to be able to use the code for F@H.

As part of this work/debugging, I introduced log.warn to separate between the opening/binding stream and general stream (between SysAp and OpenHab), whereas general stream is stream acknowledged by the existing Rocks XMPP code. So, the warnings you see are just confirmations of actual stream received from F@H SysAp, which is acknowledged by the code.

Basically, we can remove the log.warn if you find it an annoying feature in the log. For myself I kept it, as I get a continuous verification that the F@H SysAp actually is sending response / updates.

1 Like

is the new market place version available?

Hello,

I have problem with the Dimmers -

I have two Items:

Dimmer Light_OB_barD “Bar” {channel=“freeathome:dimmer:ABB700C84689_ch0002:dimmer_value”}

Switch Light_OB_barS “Bar” {channel=“freeathome:dimmer:ABB700C84689_ch0002:dimmer_switch”}

Now when I click on the slicer for the Item Light_OB_barD (which is dimmer) it does nothing

2019-06-06 15:05:54.701 [ome.event.ItemCommandEvent] - Item ‘Light_OB_barD’ received command ON
2019-06-06 15:05:54.766 [nt.ItemStatePredictedEvent] - Light_OB_barD predicted to become ON
2019-06-06 15:05:54.918 [vent.ItemStateChangedEvent] - Light_OB_barD changed from 0 to 100

It seems that the dimmer_fading channel does not support ON / OFF commands? Would it be possible to implement ON/OFF for the dimmer but not in a way that it will set 0 or 100 value, but it will switch the Dimmer unit off using dimmer_switch ? (because I want to be able to switch off the light or ON the light with the latest dimmer value remembered.

FreeAtHome Binding v1.1.0-alpha @ Eclipse Marketplace

I am happy to announce that I have just published my latest version of the freeathome binding @ eclipse marketplace.

Thanks to the contribution of @kjoglums the binding now also supports FW versions >= 2.2.4 and is available via eclipse marketplace.

Please follow the installation instructions:

  • Activate Eclipse Marketplace in openhab with Majurity Level: Alpha
  • Install binding: Addons -> Bindings -> FreeAtHome -> Install
  • Add freeathome bridge
  • Start discovery

The binding is marked as alpha. It would be great to get feedback if the binding is working as expected.

Have fun and please report new issues via ruebox@github. Pull requests are also welcome.

1 Like

Finally yes :slight_smile: just uploaded the binding to marketplace.

@The_Spirit Do you still face this issue? Perhaps you have to recalibrate your raffstores via free@home webinterface. If you login to the f@h sysap and the raffstore icon shows a ?, no update events might be sent.

Hi @ruebox,
Thanks for all the effort to integrate Free@Home into OpenHab - this is amazing.

I’m missing some of my components which I found now as dummy items:

  • Sensoreinheit 2-fach_1002_ABB700D1D313
  • Bewegungsmelder_1008_ABB700D0AE97
  • Bewegungsmelder/Schaltaktor 1-fach_100A_ABB700D1184F
  • Fenster-/Türkontakt_2042_ABB700D2B07D
  • Binäreingang_4-fach, UP_B006_ABB2DFDE2B51
  • Sensor/Dimmaktor 2/1-fach_1019_ABB700D38993
  • Sensor/ Schaltaktor 2/1-fach_100E_ABB700D208A2
  • Sensor/ Schaltaktor 1/1-fach_100C_ABB700C87204
  • Sensoreinheit 1-fach_1000_ABB700D1EEDC
  • Sensoreinheit 2-fach_1002_ABB700D1D7C3
  • Sensor/ Schaltaktor 2/2-fach_1010_ABB700CEFF3A
  • Universalmelder_2042_ABB700D18000
  • Wireless_Sensor/ Schaltaktor 2/2-fach_2039_ABB700D29F22

Not so important:

  • free@homeTouch 7"_1038_ABB66754558C

As I’m not aware how to get the getAll.xml and I haven’t found it, I can’t add it here or on git. If this is required, please let me know to generate it or how to find it. Thanks.

Did anyone already installed the new firmware 2.3.0. And works it with the binding?

Thanks

I got the “automatic” update to version 2.3.1, and apparently Busch Jaeger/ABB has made changes to their websocket communication, although not in favour of official websocket protocol nor customized XMPP code which the updated F@H binding is based on. So my OpenHab setup is actually “broken” after the update.

I see a likely solution though. However, my Eclipse / OpenHab setup is outdated, so I do not have the ability to do any corrections / pull requests. So we have do rely on @ruebox to do the actual adjustments.

The issue seems to be related to the ID communicated in the handshake between F@H and OpenHab. As part of the customized XMPP library code, more specifically the ‘XmppWebsocketDecoder’, there is a customized code:

String ID = s.substring(s.indexOf("id")+4, s.indexOf("id")+40);

As I can interpret from the updated BJ/ABB approach, the code should be modified to:

String ID = s.substring(s.indexOf("id")+4, s.indexOf("id")+18);

At least it would be a starting point!

Hi,
I can build a new version this weekend. Thx @kjoglums for the hint. Could you tell ne the content of s?.thx best