Busch-Jaeger Free@Home

kjoglums · November 26, 2021, 12:41pm

Uncertain what your issue is, as it appears like switching within sysap actually makes your switch (SwitchOnOff) change from 0 to 1…? Do you get a visual change from 0 to 1 for the switch in sysap? In that case it seems like the binding is working as it is set up to.

Due to the nature of virtual switches, as they are set up to report idp value and rely on outside control of odp value (opposite to regular hardware which reports odp values), the binding is set to listen for idp values, and reply with the same value for odp to get the visual switch change in sysap.

If you are not getting the visual change in sysap when operating the switch from sysap, you could try a couple of sysap reboots (known issue when new virtual switches are created). You could also try cache clean/OH reboot to ensure only the new part of the binding is running. Also try hitting the switch repeatedly in sysap to see if you get it triggered.

deigner · November 26, 2021, 2:15pm

This is the point: When I’m switching in SysAP (also several times), the symbol does not change. When I switch it in openHAB, the symbol in SysAP is changing without problems.
Therefore, I think, that the F@H binding does not react on the the idp from outside. When switching it from OH, then both commands (idp and odp) are sent out.
This you can also see in the F@H Monitor (see screenshots above)

I think, when the virtual switch is changing when triggering it from outside, then I think it is well initialized inside SysAP

Can I see it in any log, when a idp is coming into openhab?

kjoglums · November 26, 2021, 4:31pm

This is strange, I manage to operate my virtual switches both from OH side as well as from sysap side (getting symbol change in sysap when operating switch from sysap). I also tested creating a new virtual switch using Postman, doing a couple of sysap reboots, implementing the switch in OH, and the switch is operable from both sides.

Which FW version are you running for your sysap? I am on 2.6.4.

I think, when the virtual switch is changing when triggering it from outside, then I think it is well initialized inside SysAP

Not necessarily, as the OH command sent to sysap is unchanged throughout the binding changes. For the latest version of the binding, what is changed is how the binding reads idp values from virtual switches rather than odp values. So, cache clean/OH reboot would be advised.

The binding is set up to read/scan all websocket messages sent by sysap. In order to check otherwise, you would need to run a browser session with network inspector while logged into your sysap, to try to catch the websocket message generated when you trigger the virtual switch from sysap. Then you should be able to see a change to the idp value. The binding is set up to retrieve devices from every message, then check if the device is a “virtual switch”, and if so, check if the message for the device contains “idp” and thus handle accordingly to send an update to odp for the device.

deigner · November 26, 2021, 7:00pm

Very strange. Here, you can find the XMPP stream while I was clicking the switch in SysAP. Only two messages can be seen under the same device-serial no (6000853C358C)
XMPP_Stream.txt (2.4 KB)

SysAp: 2.6.4
Ident of Binding: 3.2.0.202109061500 (maybe you uploaded another version compared to what you are using currently)

I set up a completely new OH installation to be sure, that no influence from old version is available. And I did a lot of reboots of both systems.
I cannot really understand it.

kjoglums · November 26, 2021, 7:40pm

Exactly the same setup as mine (me having the SysAp v1, FW version 2.6.4).

Based on your XMPP stream, you are also getting idp updates as expected (switching from 0 to 1):

i=&quot;idp0000&quot; full=&quot;false&quot;&gt;&lt;value&gt;0

i=&quot;idp0000&quot; full=&quot;false&quot;&gt;&lt;value&gt;1

As the binding is set up to check if device serial is defined as “Virtual switch”, and if so, listen for idp value and send same value back to sysap odp, I am struggling to see why this doesn´t work in your case.

For your things list in OH, looking at the 6000853C358C device, is it listed as:

freeathome:virtual:YOUR_BRIDGE_ID:6000853C358C_ch0000

…and it is actually created as a Virtual Switch?

If so, there is no explanation why your device message would not be identified as a message coming from a Virtual Switch, thus reading the incoming idp value / sending update to sysap odp. My only suggestion would be to delete the virtual thing in OH, and scan/re-create the thing as virtual switch.

deigner · November 26, 2021, 11:30pm

Yes, I checked all the points.

Also have SysAP V1

So strange behaviour.

Do you have any suggestions, how to debug it more carefully?

Edit:
Here, you can find the config in SysAp-Backup-file:
(Compared to the “old” switch, only virtualDeviceEmulation is empty, which should be right in this case)

(devices manufacturer=“6000”>
(device zombie=“false” serialNumber=“600040CE52EE” virtualDeviceType=“SwitchingActuator” nativeId=“EignerVirtual0001” virtualDeviceTTL="-1" virtualDeviceLastRegistered=“1637531271” interface=“vdev:21d09388-aaff-4526-a9d8-60174ece2b59” virtualDeviceEmulation=“SwitchingActuator”/>
(device zombie=“false” serialNumber=“6000853C358C” virtualDeviceType=“SwitchingActuator” nativeId=“Christbaum1” virtualDeviceTTL="-1" virtualDeviceLastRegistered=“1637533003” interface=“vdev:21d09388-aaff-4526-a9d8-60174ece2b59” virtualDeviceEmulation=""/>
(/devices>

(replaced ‘<’ to ‘(’))

deigner · December 5, 2021, 12:17am

How can I check the Websocket messages directly? They are encrypted in my browser development-tools (here, using Firefox).

I’m continuously struggling, how to fix my problem

kjoglums · December 5, 2021, 9:48pm

You could try to enable console debugger (under bridge settings), and reboot OH as required. You should then get all websocket messages in openhab.log.

kjoglums · December 18, 2021, 9:37pm

@deigner
Have you figured out anything in your troubleshooting?

Today I tried creating a new Virtual Switch as well, using Postman, and as for you, I managed to operate the new switch from within OH, but struggled to operate the switch within sysap. Even after several sysap reboots.

As all my existing virtual switches have been working, I haven’t checked the sysap config file lately, which I did again today. Apparently, even though I deleted virtualDeviceEmulation="SwitchingActuator" as part of testing the new version of the binding, virtualDeviceEmulation="SwitchingActuator" had again been set for my existing switches. Which would explain why my existing switches have been workling all along. Implementing virtualDeviceEmulation="SwitchingActuator" for my new switch obviously also got my new switch operable from within sysap, for the new version of the binding.

Need to check with the Developer Team what causes this behavior, and why the switch is not operable from sysap without having virtualDeviceEmulation="SwitchingActuator, when the binding is set up to read idp value and autoloop to odp value, as recommended.

deigner · December 19, 2021, 12:21pm

Hello Stian …
I did a lot of researches, but did not find out the exact problem because my programming-skills are very very bad and I did not find the code which is responsible for the virtual switch in your github repo.

What I achieved is:
I was able to send the odp command via postman to F@H which toggled the switch. Therefore, I think it’s maybe a problem in the binding. (but I’m absolutely not sure)
What is also strange, that I cannot see the debug logs (logger.debug(“Virtual Switch ON {}”, idpChannel)) inside the openhab.log. Others, I can see there. So, setting of log:level should be correct. Maybe the idp message is not detected by the binding and no reaction is sent out.

When I have more details, I can let you know

ML1982 · December 23, 2021, 5:34pm

Hello,
I’ve problems with connecting to the SysAP

I’ve started openhab 3.2 with start_debug and the message is:
[OH-safeCall-1] WARN org.openhab.binding.freeathome.internal.handler.FreeAtHomeBridgeHandler - Problems getting JID: null

the correspondig message within the gui is:

generally the Connection to the RestAPI Works with NodeRed. I could write data to a virtuell weather station.

i’m using org.openhab.binding.freeathome-3.2.0-SNAPSHOT.jar on an Raspberry with the newest openhabian image. The Busch Jäger SysAp runs with the new 3.0 Firmware.

ML1982 · December 25, 2021, 6:06pm

i tried what is written in Post 352.
Now everthing is fine if i stop the openhab service and start openhab manually within a ssh session.

As soon as i start openhab as a service i got the error that is shown in the Screenshot above.

ML1982 · December 29, 2021, 9:15am

After a lot of reboots the System is running now.
I didn’t change anything and i’m afraid of rebooting again, but currently the system runs perfect.

kjoglums · December 29, 2021, 6:25pm

This would indicate some issues with the user account being used for log in. Is the account actually set as an installer account under sysap? You should be using a regular username, similar as the ones used to log into your sysap from a web browser, and the user name should have installer rights as set under sysap settings.

Also, just to simplify reboots/logins, you could try to disable Console debugger under your bridge thing settings in the gui.

ML1982 · January 10, 2022, 8:44pm

i just had the same problem. With changing the Channel to Ch0000 the Universalmelder works.

of course the percentage value doesn’t work, because the “Universalmelder” doesn’t have the percentage value rsp. an ajar state.

And i’m not using the additional external contact of the Unversalmelder. But the primary Contact works fine with the adjusted channel within the advanced configuration

@kjoglums is it this here, what u need for the implementation of the correct autodetect mechanism?
And is there any chance to get the battery state of a window or the universalsensor? The Busch Jäger WebGui shows the battery status in percent.

“ABBmySecret”: {
“floor”: “01”,
“room”: “09”,
“interface”: “RF”,
“displayName”: “BalkonTür”,
“unresponsive”: false,
“channels”: {
“ch0000”: {
“displayName”: “BalkonTür”,
“functionID”: “f”,
“inputs”: {},
“outputs”: {
“odp0000”: {
“pairingID”: 53,
“value”: “0”
}
}
},
“ch0002”: {
“displayName”: “ⓐ”,
“functionID”: “0”,
“inputs”: {
“idp0000”: {
“pairingID”: 256,
“value”: “0”
},
“idp0001”: {
“pairingID”: 272,
“value”: “0”
},
“idp0002”: {
“pairingID”: 288,
“value”: “0”
}
},
“outputs”: {
“odp0000”: {
“pairingID”: 1,
“value”: “1”
},
“odp0001”: {
“pairingID”: 16,
“value”: “0”
},
“odp0002”: {
“pairingID”: 32,
“value”: “0”
},
“odp0003”: {
“pairingID”: 33,
“value”: “0”
},
“odp0004”: {
“pairingID”: 2,
“value”: “0”
},
“odp0005”: {
“pairingID”: 3,
“value”: “0”
},
“odp0006”: {
“pairingID”: 40,
“value”: “0”
},
“odp0007”: {
“pairingID”: 309,
“value”: “0”
},
“odp0008”: {
“pairingID”: 4,
“value”: “0”
},
“odp0009”: {
“pairingID”: 37,
“value”: “0”
},
“odp000a”: {
“pairingID”: 38,
“value”: “0”
},
“odp000b”: {
“pairingID”: 39,
“value”: “0”
},
“odp000c”: {
“pairingID”: 53,
“value”: “0”
},
“odp000d”: {
“pairingID”: 6,
“value”: “0”
}
}
}
}
},

kjoglums · January 28, 2022, 2:13pm

We are getting closer as you have identified CH0000 as the correct channel, and receiving status updates (ON/OFF) on odp0000.

We would also need the devicetypeid to base auto discovery on, and the id you should see if you enable dummy things, and run a scan for things. Your universal device should show up in the discovery list as a dummy thing, with a name including the devicetypeid.

ML1982 · February 12, 2022, 3:16pm

i’ve enabled dummy things and started a scan.

but the device isn’t there:

kjoglums · February 12, 2022, 8:59pm

Likely due to the device already being defined manually as a Window sensor. Would then require a deletion of the existing Thing and do a new scan for Things.

openhab_knx · February 13, 2022, 5:28am

Stian,

i just want to say thank you for the great binding. I am using it to handle about 60 lights and shutters and it is working perfect.

Thank you

ML1982 · February 13, 2022, 2:43pm

here it is: