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
COMMUNICATION_ERROR
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 
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?
Its working with channel, idp and odp 0000
Another user told me that it is working for him, too. And he thinks that there is no signal coming back from openhab, that the Switch was set to ON/OFF. So the switch jumps back in the state that was set before.
Is there a simple solution to give back a feedback to f@h via the binding or openhab, that the switch was set to OFF or ON?
Virtual switches work both ways, sending commands / reading updates via websocket. Meaning, sending commands will work both from F@H as well as OH. Also, OH should read updates and update itself whenever (from whatever device) the virtual switch is triggered.
Scenes, as created from F@H though, will not be read by OH, as F@H scenes are not sending updates over websocket.
Hello everyone,
I found very good contribution the binding from @kjoglums. But unfortunately with my setup with only wireless devices I had many troubles. Therefore I created in the last weeks a free@home binding based on the official local API from Busch-Jaeger/ABB. The binding is REST for setting the values and the updates are running via Websocket.
If somebody interested I could like to provide the binding or share the source code.
However it is supporting currently only the switch-actuator and thermostat, because I have only these devices, but they are working stable in my test environment. I plan to add the dimmer and scene devices in the next days.
However some devices types will be still missing in my implementation, therefore I would like to ask your support to be able to implement the other devices as well. It would be a great help, if somebody could provide me a “device_list” from sagger.
and at last but not leat I would to say thank you to @kjoglums, his implementation gave a lots of ideas for the implementation.
Hi @UhA what a great achievement! I would be really interested in testing your new binding based on local API and also to support you with device list and config
Hey @UhA thanks for your implementation. If you share your source code, I would take a look in there as well