Maybe we can add an CheckBox here, to distinguish between the “Fenster-/Türkontakt” and the “UniversalMelder”.
And we have to keep in mind, that the “Universalmelder” has an additonal binary Input, I don’t use it so I have no experience if/how it works with the binding.
And @kjoglums just another question.For a newbie like me it this thread here seems confusing. Maybe we could introduce a “Busch Jäger Binding” section here:
Introducing a check box would require the device to already be discovered/registerred, meaning it is not possible to have a checkbox to tick prior to having performed autodiscovery. Again, it would be just as easy to create the device manually.
When it comes to the Marketplace, it could be looked further into, if we should have a F@H section.
@kjoglums
Can you please give me a hint where to find your latest compiled bundle/jar file for openhab 3.2?
Thanks a lot.
I’m not sure if I understood it correctly.
The device is discovered automatically, but as “normal” window sensor.
“dummy Things” are disabled, and the result of the Scan is:
Yes, I believe the initial request was to include your “Universalmelder” for autodiscovery. However, devicetype 2042 is already set up by default as “Fenster-/Türkontakt”, i.e. the device will be discovered as a “Window sensor”, working under ch0001, odp0000 (switch status) and odp0001 (percentage value).
Next, what is requested is to add a checkbox to choose between “Fenster-/Türkontakt” and “UniversalMelder”. However, this would then happen after the device already has been discovered as a “Window sensor”. I.e. it would not be possible to add such a checkbox to something which isn’t discovered/defined yet. Meaning, there is not a good/known method how to separate between these 2 alternatives as part of the discovery process (maybe it could work checking device type name as part of scanning).
And trying to change a device which already has been defined as a different Thing type is likely to cause some issues from the binding point of view. Thus, the recommended approach is to delete the default discovered “Window sensor”, and to manually create a Thing suiting the “Universalmelder”. As you previously mentioned, your “Universalmelder” is working under ch0000, and receiving updates on odp0000. If you choose for instance a manual “Binary sensor” (create Thing, Free@Home, Add manually), input the device serial, and just change from odp000c to odp0000 you should have the device you are requesting.
@Olafsc @jannodeluxe @deigner
Have done some more adjustments/testing of the binding to autoupdate Virtual switches, and believe I have come to a solution (thus not requiring virtualDeviceEmulation).
Latest version of the binding:
org.openhab.binding.freeathome-3.3.0-SNAPSHOT.jar
Thanks - right now everything works fine with the Virtualdevices - i am reluctant to make changes to not risk issues?
Same here, but created a couple of new Virtual switches to use for binding update/testing. Confirmed working successfully with the new version of the binding, i.e. switchable with correct response on both OH / F@H side of things.
Hi Stian … Just tested your changes of the Binding. Seems to work now on both sides to update the switching-state.
You made my day.
Thanks a lot
Hi Stian,
i can also confirm that the switches works on both sides.
I’m not sure, but i think without the “virtualdevice emulation” i can’t use the virtaul switches by scene in f@h.
I triggerd de virtual device by scene to “ON” and do some stuff in OH3. I do this per scene, because i want to switch it on the Panel with a trendy icon 
When i save the Scene with virtual switch to “ON”, i cant’t save the “ON” status.
It is always OFF.
It is a small issue i detected, but i wanted to inform you …
Greets Stephan
I detected a minor flaw regarding scenes/virtual switches myself some time ago, so I made an adjustment, and put the update directly as an edit to Post.
Could you first try the latest version as posted? I also use virtual switches as part of scenes, without virtualdevice emulation, and the setup is working fine for me.
I already testet the newest version of the binding.
I also restartet f@h and OH3, everything works fine except the scene and virtual switches.
A litte thing goes wrong like explained.
<device zombie="false" serialNumber="xxxxx" virtualDeviceType="SwitchingActuator" nativeId="abc129" virtualDeviceTTL="-1" virtualDeviceLastRegistered="1654361181" interface="vdev:xxxxx" virtualDeviceEmulation=""/>
<device zombie="false" serialNumber="xxxxx" virtualDeviceType="SwitchingActuator" nativeId="abc124" virtualDeviceTTL="-1" virtualDeviceLastRegistered="1654361145" interface="vdev:xxxxx" virtualDeviceEmulation=""/>
<device zombie="false" serialNumber="xxxxx" virtualDeviceType="SwitchingActuator" nativeId="abc131" virtualDeviceTTL="-1" virtualDeviceLastRegistered="1654361091" interface="vdev:axxxxx" virtualDeviceEmulation=""/>
<device zombie="false" serialNumber="xxxxx" virtualDeviceType="SwitchingActuator" nativeId="abc125" virtualDeviceTTL="-1" virtualDeviceLastRegistered="1654361057" interface="vdev:xxxxx" virtualDeviceEmulation=""/>
<device zombie="false" serialNumber="xxxxx" virtualDeviceType="SwitchingActuator" nativeId="abc130" virtualDeviceTTL="-1" virtualDeviceLastRegistered="1654361018" interface="vdev:xxxxx" virtualDeviceEmulation=""/>
<device zombie="false" serialNumber="xxxxx" virtualDeviceType="SwitchingActuator" nativeId="abc132" virtualDeviceTTL="-1" virtualDeviceLastRegistered="1654360971" interface="vdev:xxxxx" virtualDeviceEmulation=""/>
<device zombie="false" serialNumber="xxxxx" virtualDeviceType="SwitchingActuator" nativeId="abc127" virtualDeviceTTL="-1" virtualDeviceLastRegistered="1654360902" interface="vdev:xxxxx" virtualDeviceEmulation=""/>
<device zombie="true" serialNumber="xxxxx" virtualDeviceType="WindowSensor" nativeId="abc1111" virtualDeviceTTL="0" virtualDeviceLastRegistered="1654359334" interface="vdev:xxxxx" virtualDeviceEmulation=""/>
Hi all,
I got every time same error message…
2022-06-27 11:00:05.956 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘freeathome:bridge:5a95606744’ changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): XMPP connection lost
…sometimes the freeathomeBridge works fine. After reboot or connection lost I´m not able to reconnect to the bridge. However the reinstalling of bridge doesn’t work. I tried both versions, org.openhab.binding.freeathome-3.1.0-SNAPSHOT 1 and org.openhab.binding.freeathome-3.3.0-SNAPSHOT.
What could I do?
System: Raspi 3+
Release = Raspbian GNU/Linux 11 (bullseye)
openHAB 3.2.0 - Release Build
Greets
Hi Andi,
i have had the problem, that my bridge after restart/reboot stayed offline.
Also sometimes the connection was lost without a reason.
My Reason:
I copied the Binding without stopping openhab.
As i noticed this was a possible error, i does it like recommended:
Stop openhab service, copy the jar file into the addon folder, start openhab service.
Additional i cleared the cache (also by stopping openhab).
Since a reboot everything works fine.
Thanks for your reply…
i will test it and report…
Greets
@Stephan-Prem
My virtual switches were working ok, both for individual switching as well as for scenes. Although, I was until just recently running SysAp version 2.6.4. After upgrading SysAp to 3.0.1, I am also experiencing the same problem as you with the virtual switches. All my virtual devices are set witout virtualDeviceEmulation.
So, virtual switches included as part of scenes are no longer triggered/changing states. What is strange though, is that individual switching still works fine. Need to look more into details to see what happens when scenes are triggered.
EDIT
It appears to be related to some changes made as part of the SysAp upgrade. Looking into the XMPP stream while triggering scenes, the only change recognised for the virtual switches after the upgrade is a change on ch0000/idp0003, however the value remains the same even if scene is triggering ON or OFF for the virtual switch, so there is no logical way having the binding updating state change. Physical devices included in scenes are still recognised with updates on channel/idp/odp required for state changes. Have forwarded the issue to the ABB developer team.
Hello guys…my name ist Thomas and i am new in this board and I want to install free@home on my OpenHab 3.3.
I have installed the binding for the device and installed the bride with the correct ip, tha API user and my passwort, so i thinks it is ok.
The bridge do not going online, the status os yellow and in the OH console i have follow mistake.
org.openhab.binding.freeathome.internal.handler.FreeAtHomeBridgeHandler
Can somebody help me, i don´t know what i should do.
Thanks and best regards, Thomas
same here. SysAP v2.
“[OH-safeCall-2] WARN org.openhab.binding.freeathome.internal.handler.FreeAtHomeBridgeHandler - Problems getting JID: java.util.concurrent.ExecutionException: java.net.SocketTimeoutException: Connect Timeout”
Your problem is that you are logging in with a usename unknown to the SysAp / username without installer rights (as set within the SysAp interface).