I tried upgrading from OH 2.4.0 to 2.5.0, but got the same “Timeout while waiting on advertised authentication mechanism” (also running OpenHabian). This issue relates to the implemented rocks.xmpp library, and furthermore Jaxb / xml stream. OH 2.5.0 was just released, and uncertain what changes were made which breaks the F@H binding.
I am trying to figure out the issue, but remain on OH 2.4.0 stable release for now as the F@H binding then runs with success.
I’ve got the same problem.
New user, running on OH 2.5.0 on Ubuntu to SysAp 2.4.0
2019-12-27 12:16:54.908 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing ‘freeathome:bridge:2674b18d’ takes more than 5000ms.
2019-12-27 12:16:55.032 [WARN ] [rnal.handler.FreeAtHomeBridgeHandler] - Bridge connection lost. Updating thing status to OFFLINE.
2019-12-27 12:16:55.033 [WARN ] [rnal.handler.FreeAtHomeBridgeHandler] - Could not successfully get the getAll.xml from sysAP. Can happen if connecting to server takes too long.
==> /var/log/openhab2/events.log <==
2019-12-27 12:16:55.033 [hingStatusInfoChangedEvent] - ‘freeathome:bridge:2674b18d’ changed from INITIALIZING to OFFLINE (COMMUNICATION_ERROR): Can not connect to SysAP with address: 10.100.100.134
after downgrading i still get an error but another one:
==> /var/log/openhab2/events.log <==
2019-12-27 14:15:19.170 [hingStatusInfoChangedEvent] - ‘freeathome:bridge:933a1e30’ changed from INITIALIZING to UNINITIALIZED (HANDLER_INITIALIZING_ERROR): rocks.xmpp.core.session.Module: Provider rocks.xmpp.core.session.CoreModule not a subtype
Removed the addon, deleted misc cache and temp as reported earlier in this post and, added addon, restarted, added thing
==> /var/log/openhab2/openhab.log <==
2019-12-27 14:18:09.514 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing ‘freeathome:bridge:933a1e30’ takes more than 5000ms.
2019-12-27 14:18:09.696 [WARN ] [home.handler.FreeAtHomeBridgeHandler] - rocks.xmpp.core.session.NoResponseException: Timeout while waiting on advertised authentication mechanisms.
==> /var/log/openhab2/events.log <==
2019-12-27 14:18:09.697 [hingStatusInfoChangedEvent] - ‘freeathome:bridge:933a1e30’ changed from INITIALIZING to OFFLINE (COMMUNICATION_ERROR): Can not connect to SysAP with address: 10.100.100.134
==> /var/log/openhab2/openhab.log <==
2019-12-27 14:18:09.700 [WARN ] [home.handler.FreeAtHomeBridgeHandler] - Could not successfully get the getAll.xml from sysAP. Can happen if connecting to server takes too long.
Strange, based on your debug log, where you still have Timeout while waiting on advertised authentication mechanisms, it seems like you haven´t fully been able to clean cache.
For me, running OpenHabian, the following steps enabled me to run F@H binding successfully after downgrading from OH 2.5.0 to 2.4.0:
Yes I am using OH 2.5, I think (latest OpenHabian release).
I am a bit confused when it comes to version numbers. OpenHabian (what I’m using) uses 1.x version numbers; now 1.5 is the latest version. But this contains OpenHab 2.5 I assume. But since I don’t know how to downgrade I just picked the OpenHabian v1.4.1 version for the RPI to see if that helps…
Well, that didn’t help; downloaded an older OpenHabian (1.4.1) image but it still installs the latest OpenHab version (2.5); now the question is; how do I downgrade openHAB 2.5 to 2.4 ?
EDIT: Nevermind; a downgrade is more simple then I thought. Just had to run
sudo apt-get install openhab2=2.4.0-1
Now I’m running OpenHab 2.4 and configured the FreeAtHome bridge and it went online instantly :D.
Then I finally believe I made a breakthrough to update/enable Free@Home binding for OH 2.5.0. I myself have been struggling getting the binding running with 2.5.0, and have been “stuck” at OH 2.4.0. If others would be willing to test, the jar file could be downloaded at:
Add jar file from link above to openhab2-addons folder
Try to create new bridge from PaperUI (using thing ID from before to enable automatic link to existing things)
If not able to establish connection, try rebooting OH once again
With successful connection, existing things should be automatically re-linked with the “new” bridge as long as the initial thing ID has been used during configuration in PaperUI.
Note
New OH 2.5.0 users, without having existing F@H setup in OH could do a fresh setup adding the jar file from link above into openhab2-addons folder and setting up bridge in PaperUI and performing an inbox scan for things to add.
Additional features from 2.4.0 version
Disovery/implementation of virtual switches as created from ABB development program
Disovery/implementation of motion detectors without relay
Yes, I have successfully created virtual switches under F@H SysAp (following ABB developer program), and I have implemented the switches in OH through revised code (as implemented in jar file from previous post).
Although, I also struggled in the beginning, and was in dialogue with ABB developers to trouble shoot issues. This was in the phase between SysAp version 2.3.2 and 2.4.0, and the issues should be resolved for SysAp 2.4.0 (at least for me). My issue was that I did not get the correct setup for the fhapi “user” under SysAp setup (as illustrated in the ABB tutorial) although following ABB guide, and I was not able to write/put anything to SysAp (using Postman). Got it working, and still works.
Next challenge for me, after having created virtual switch from Postman, was to be able to operate the switch under SysAp. The switch was found and implemented in SysAp, but it was not possible to perform state change (ON/OFF). I had to reboot SysAp, and eventually was able to operate switch, and could then implement switch in OpenHab.
So I have to contact the ABB developers to solve my issue. Which way did you use to contact the support? I didn’t find any contact information in the developer portal.
Well, actually, if the scene is activated on the F@H side (i.e. via F@H switch, action etc), the F@H SysAp does not report the actual update/state change for the scene, and will thus not be able to trigger a OpenHab rule as you try to achieve. If the scene is triggered from OpenHab side, the update/state change for the scene should be reported.
For my own setup, I have created virtual switches (using the ABB developer program), which again are linked to the scene in F@H SysAp (virtual switch ON/OFF). I.e. when scene is triggered from the F@H system, the belonging virtual switch is switched ON. The virtual switches are included in the OpenHab setup, and these switches report “ON/OFF”, and could be used to trigger rules similar to what you try to achieve.
Also, I see you are using “Item FFFF4800003”, but is this item actually linked to a channel of your scene thing?
For instance, for one of my scenes, I have linked an item AltAvActivate which is linked to my scene thing as follows:
When you activate a regular F@H switch (e.g. regular relay switch, dimmer switch etc), either via hardware switch or F@H app, the activation is reported by F@H SysAp (ON/OFF, dimmer value etc), and is transmitted from F@H to OH. However, scene activation itself on the “F@H side” (switch, F@H app etc) is not reported by the F@H SysAp (only state change of the things/channels involved in the scene), and there is thus “nothing” to transmit from F@H to OpenHab for scene activation, and one would therefore not be able to track/log scene activation as a ON/OFF feature. That is the reason why I have linked virtual switches to my scenes, to be able to detect actual scene activation from “F@H” side.
That is true: You will only be able to create virtual switches by connecting to SysAp via cloud. I.e. you need to follow the 3 steps shown in the bottom of page Sign up / Request / Subscribe. Then you will need to download the Postman software and follow the ABB Tutorials.
The cloud connection is only required for the creation of the virtual switches. Once the switches are created, and recognised in the SysAp GUI, you can play around with the switches under regular running environment.