Busch-Jaeger Free@Home

Historically, the XMPP over websocket (local communication) has been working successfully for both SysAp v1 and SysAp v2, and is still confirmed working for SysAp v1 FW 3.1.0. Meaning, a lot of SysAp v2 users have reported binding to work successfully. If XMPP over websocket is broken for SysAp v2, this might have something to do with the latest FW upgrade.

Further on, following https://developer.eu.mybuildings.abb.com/documentation SysAp v1 has been fitted for cloud API whereas SysAp v2 has been fitted for local API. As @jannodeluxe points out, the XMPP interface is undocumented, but has still provided local communication with SysAp (working independently from the cloud API / REST API).

What I meant by having integrated cloud API: I have used the cloud API (also using Postman) to create virtual devices, whereas the binding is set up to autodiscover these devices as such, i.e. virtual devices.

Looking for a solution using the REST API only, you should have a look at https://community.openhab.org/t/busch-jaeger-free-home/31043/453?u=kjoglums

1 Like

I’ve a SysAp 2, last week i made the latest FW Upgrade to Version 3.1.0 Revision 9754, and the binding still works fine. So I can confirm that the latest FW on a SysAp 2 works with the binding.

I also tried Busch-Jaeger Free@Home - #453 by UhA several times, but it doesn’t work.

1 Like

Hi Stian, I finally tried to update to your latest 3.3.0 binding in the post above, but got a Status:

UNINITIALIZED

HANDLER_INITIALIZING_ERROR

rocks.xmpp.core.session.Module: rocks.xmpp.core.session.CoreModule not a subtype

Error. I am on OpenHAB 3.3.0 release build. The previous version you once build for me worked fine so far.

EDIT: After restarting the raspi / linux reboot it eventually worked, no idea what changed. Resolved.

Olaf

1 Like

Like before, it is a good idea to try a couple of reboots if only getting Initializing, Uninitialized or OFFLINE as part of startup. Also try the sequence between stop openhab.service and remove cache as described under Link if the problem persists.

As a side note: I am unable to get any response from the ABB Developer team wrt virtual switches, and their changed behaviour as part of the latest FW upgrades when it comes to response/status update when included in F@H scenes. So, we are status quo when it comes to a fix/solution, as the virtual switches are reporting value 20 on ch0000/idp0003 regardless if the switch becomes ON or OFF as part of scene triggering.

Hello,

just for information if someone else has the same problem. I found out the idp adresses of the wireless comfort thermostat. With this it is possible to controll the thermostat over openhab. However it was not possible for me to detect the odp adresses therefore you will not get any updates from the system e.g. current room temperature.

Have a look at Link and search for «Thermostat» to see default idp/odp values for wired devices, and see if there any obvious correlations.

I see that idp values appear to be offset by 7, possible also for odp values
?

Hello everybody,

I am absolutely new to the community. I set up an raspberry pi 4b 4GB with openhab 3.3.0.
Now i would like to use the free@home binding because I have this System in my house.
Using putty on my Windows 10 PC i downloaded the “org.openhab.binding.freeathomesystem-3.4.0-SNAPSHOT.jar” file in my addon folder using the command:

cd /usr/share/openhab/addons
sudo wget “https://github.com/andrasU/openhab-free-home-binding/blob/main/org.openhab.binding.freeathomesystem-3.4.0-SNAPSHOT.jar”

from Link

The file seems to be very new just 3 days old. But I wasn’t able to download the 3.3.0 version from kjoglums because I could not make it work with the provided link via putty. And since I am on a Windows PC I wasn’t able to transfer the file without putty. Can anybody provide a Link ending with .jar?

Anyways. If I restart openhab I can not add the bridge in things. Absolutely nothing happend.
Has anybody any Idea. I would love to use the binding.

Thanks in advance and sorry for the maybe very basic problem.

The version you are referring to, the @UhA version of the binding, is based on REST API, and I have no clue if/how the binding works.

For the other version, it can be downloaded as described under link. Since you are running RPi, you could easily set up samba share, and put the jar file into the openhab/addons folder.

Thanks Samba was the key. I was able to install your binding from the Link.
For anybody who might encounter a similar problem:
I followed the instructions from the following Link.
But I wasnt able to access the addons direcotry (/usr/share/openhab/addons).
Solution here was to add the “Netzwerklaufwerk” “\192.168.x.xxx\openHAB-addons”
With user .\openhabian
pw: openhabian

Then i just copied the file from the link above. Worked like a charm.
I also checked the directory via putty and now the binding file was in green color.
When I was adding the other binding via putty it was in red colored writing.
Thanks

1 Like

Hello everybody,

I do not want to hijack this thread. But this is true I made an other version of f the free@home binding and I am using this binding since some weeks without any problem.

This binding is based on the REST API for setting values and Event Socket communication is used for status updates. This current version is complete re-design of the first my binding which I developed because I cannot make working the binding from @kjoglums on my Raspberry. (sorry
 but it was maybe my fault :slight_smile: )

The usage of the current version is very simple, it needs only configuration of the SysAP (gateway) the further devices and channels are detected automatically, no user interaction or any additional configuration is needed.

The automatic detection is based on the REST API available function ID and pairing ID information. Due to this the binding can adapt itself and able to detect and control new/unknown devices.

Further on the binding is not splitting the multi-channel free@home devices into multiple but single channel Things, this means a 4xChannel actuator will be kept as one multi-channel Thing. For this it is important to give a name to the channels on the free@home dashboard, because it is used for the openHAB representation.
Introduce new Input/Output (Sensor/Actuator) functionalities is very simple, it just needed to define on which channel, and which “idp/odp” are used for the communication.

I made my test based on my free@home system and based on some shared configuration file.

If somebody would like to have a binary to test, to try it, I am happily sharing my current binary build.
In case of any question, or request to implement a new feature please contact me, the best would be in private message.

and again
 I did not wanted to hijack this thread.

Thank you

@UhA
i would like to test ist. can u provide me the binary?
And maybe we could open another thread?

I started a new thread for the free@home with official api
Here

you can find every information to it in the new thread. also the current builds and the current binaries.

Thank you for the interest

Hi everybody, hi Stian!
I use the Binding and everything works fine so far.
Now I have a new project: Use the Free@Home API to create a Virtual Device in Free@Home - a “EnergyInverterMeterBattery”. First step worked fine.
Then I try to pass all values from my Fronius-inverter to that Device, as described here via Openhab (Fronius-Binding show all values) and Nodered (via openhab2-get2-nodes and http request). Goal is to show all those values on my Free@home-7-panel in the living room. I was able to reach that goal partly.

The problem is, that it seems, that Free@Home does not create or use or pass all necessary Datapoints (e.g. for power consumption live or aggregated) - or I cannot use Nodered correctly


Now I want to test, if I can create the “EnergyInverterMeterBattery” directly also in Openhab using your binding, maybe the passing of the values is more easy, when I stay in Openhab and do not have to go via nodered.

The Device “EnergyInverterMeterBattery” is not discovered by the Free@home-Binding. And Manually, as far as I understand, it is only possible to create all the things listed in the Binding (e.g. “raffstore”, “dummy”, “weather” etc). What about other Virtual Devices, like “EnergyInverterMeterBattery” (or others listed here: [F@H IP-Adress] /swagger/fhapi). Is there a trick to achieve a Thing named “EnergyInverterMeterBattery”, where you can cover the serial number and different Channels and ODP to adress the different values?

Using the Snapshot-Version 3.3.0.

Sorry for the long description, I hope I described my problem understandable. Thank you for reading
!

The only virtual device currently supported by the binding is virtual switches. However, even these devices have limited functionality, as the ABB/Busch-JĂ€ger team has changed the behavior of these devices as part of the latest FW upgrades, i.e. the devices do not report status updates over local websocket when included in scenes etc, and it is thus not possible to get a successful interaction between OH and SysAp.

Also, this version of the binding does not support local API (which seems to be a prerequisite for your goal), as it is based on XMPP over local websocket.

OK, thank you for your answer!

Update: I successfully integrated not only my Solar-Inverter but also 3rd-Party-Sensors (Netatmo) for Humdity, CO2, Temp etc. (and all values which I gather thanks to OH) as Virtual Machines in Free@Home.

If you®re interested, I combined a “How-To” for the 3rd - Party - Sensors here.

Any experience with B&J FW 3.1.2?
I’m running 2.6.4 currently without any problems

I installed it since yesterday. No problems so far, but I don’t have any wireless devices in use.

Greetings

1 Like

Hi
I upgraded to FW version 3.1.2 recently and from that time my connection between openhab and sysapp doesnt work. It looks there is some problem to access local API. I still didnt figure out.
I dont know how to downgrade that firmward without any demage so it is very difficult to confirm.

did you tried a restart of openhab?

I also updatet to 3.1.2 today and i have no problems.