Well, have a working version of the binding for OH 3.0 (initial version) which could be made available as jar file.
Although, after the M2 release, where /lib folders are excluded, I struggled at first to successfully build the binding for the new environment. After some workarounds, the builds are now successful, but now the problem/challenge is to get successful websocket / stream initation.
Hello Stian,
answer to my post from 27th October #404 and the following posts:
I hope this helps.
With best regards
Martin
For manually created Things, the ID of the device and channel will be set to default values and need to be updated manually.
For autodiscovered Things, the device ID and channel will be set automatically. Note: From inbox you could search for a specific device ID and see each thing type recognized for the device ID.
Hello Stian,
all my Things were autodiscovered. Device ID an channel of the binary-switch were not set automatically. All other things (switches, raffstore switches, thermostats) were set automatically.
With best regards
Martin
Then it could be you have some old binding stuff/uncleaned cache, i.e. your thing autodiscovered as “dummy thing” which use predefined values. The binding is set up to set actual values from autodiscovery also for binary switch.
Were you able to find out, why these XMPP-streams are logged to your syslog? I currently have the same issue right now. My log (syslog.log and daemon.log) is totally full of these “trash”-entries.
Best regards.
Hello Stian.
Have you already found a way to make the binding run stable under OH 3 M4?
With best regards
Hans
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
Daniel
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.
@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.