255 │ Active │ 80 │ 1.0.0.201906172005 │ FreeAtHome Binding
How does your items-file look like?
Anyone tested new Firmeware 2.5.0:
- https://www.busch-jaeger.de/files/files_ONLINE/SysAP_ReleaseNotes_DE-EN_V8_2CKA000673B9732_BJE.pdf
- https://www.busch-jaeger.de/produktuebersicht?tx_nlbjproducts_catalog[action]=show&tx_nlbjproducts_catalog[catBjeProdukt]=4660&tx_nlbjproducts_catalog[catStdArtikel]=9514&tx_nlbjproducts_catalog[controller]=CatStdArtikel&cHash=558ed29eb3d5db2cee7463b26d4a7c9d
I am running the latest version, the 2.5.4 version from Post #251.
For me, having autodiscovered things, my items file for a screen actuator look like:
Rollershutter SunscreenLivingroom_Stepwise "Shutter stepwise" {channel="freeathome:raffstore:ABB123456_ch0000:stepwise"}
Rollershutter SunscreenLivingroom_Complete "Shutter complete" {channel="freeathome:raffstore:ABB123456_ch0000:complete"}
Dimmer SunscreenLivingroomStue_Percentage "Percentage" {channel="freeathome:raffstore:ABB123456_ch0000:percentage"}
I just did an upgrade to 2.5.0 firmware version, using the latest 2.5.4 binding version, and everything seems to work as before.
1 Like
firmware 2.5.0 is working fine here, too.
1 Like
Could someone please tell me whether it is even possible to create things manually in the things file or whether it is only possible via autodiscover in Paper UI?
I read that there are bindings that can only do this via autodiscover.
I cannot find any references to this in the readmes for the bindings.
I tried to connect my bridge with firmware 2.5.0 and the latest snapshot of the add-on (org.openhab.binding.freeathome-2.5.4-SNAPSHOT.jar).
The connection is not working, the log shows this error:
2020-04-15 23:17:18.572 [INFO ] [rnal.handler.FreeAtHomeBridgeHandler] - Connecting to XMPP Client
2020-04-15 23:17:18.574 [WARN ] [ent.WebSocketConnectionConfiguration] - Websocket session being created: ws://192.168.178.201:5280/xmpp-websocket/
2020-04-15 23:17:18.599 [WARN ] [ent.WebSocketConnectionConfiguration] - Handshake response received from server
2020-04-15 23:17:18.600 [WARN ] [ent.WebSocketConnectionConfiguration] - Handshake succeded: Sec-Websocket-Protocol = XMPP
2020-04-15 23:17:28.586 [WARN ] [rnal.handler.FreeAtHomeBridgeHandler] - Problems connecting to SysAp:
rocks.xmpp.core.XmppException: javax.websocket.SessionException: CloseReason[1006,Closed abnormally.]
at rocks.xmpp.core.session.XmppSession.throwAsXmppExceptionIfNotNull(XmppSession.java:280) ~[xmpp-core-client-0.9.0-SNAPSHOT.jar:?]
at rocks.xmpp.core.session.XmppClient.connect(XmppClient.java:225) ~[xmpp-core-client-0.9.0-SNAPSHOT.jar:?]
at org.openhab.binding.freeathome.internal.handler.FreeAtHomeBridgeHandler.connectGateway(FreeAtHomeBridgeHandler.java:233) [bundleFile:?]
at org.openhab.binding.freeathome.internal.handler.FreeAtHomeBridgeHandler.initialize(FreeAtHomeBridgeHandler.java:114) [bundleFile:?]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.thingUpdated(BaseThingHandler.java:166) [bundleFile:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_212]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_212]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_212]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_212]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_212]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_212]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_212]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_212]
Caused by: javax.websocket.SessionException: CloseReason[1006,Closed abnormally.]
at rocks.xmpp.websocket.net.client.WebSocketConnectionConfiguration$2.onClose(WebSocketConnectionConfiguration.java:271) ~[?:?]
at org.glassfish.tyrus.core.TyrusEndpointWrapper.onClose(TyrusEndpointWrapper.java:1235) ~[?:?]
at org.glassfish.tyrus.core.TyrusWebSocket.onClose(TyrusWebSocket.java:106) ~[?:?]
at org.glassfish.tyrus.core.ProtocolHandler.close(ProtocolHandler.java:445) ~[?:?]
at org.glassfish.tyrus.core.TyrusWebSocket.close(TyrusWebSocket.java:240) ~[?:?]
at org.glassfish.tyrus.client.TyrusClientEngine$2$1.close(TyrusClientEngine.java:612) ~[?:?]
at org.glassfish.tyrus.container.jdk.client.ClientFilter.processConnectionClosed(ClientFilter.java:218) ~[?:?]
at org.glassfish.tyrus.container.jdk.client.Filter.onConnectionClosed(Filter.java:124) ~[?:?]
at org.glassfish.tyrus.container.jdk.client.Filter.onConnectionClosed(Filter.java:128) ~[?:?]
at org.glassfish.tyrus.container.jdk.client.TransportFilter$4.completed(TransportFilter.java:276) ~[?:?]
at org.glassfish.tyrus.container.jdk.client.TransportFilter$4.completed(TransportFilter.java:266) ~[?:?]
at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) ~[?:1.8.0_212]
at sun.nio.ch.UnixAsynchronousSocketChannelImpl.finishRead(UnixAsynchronousSocketChannelImpl.java:430) ~[?:1.8.0_212]
at sun.nio.ch.UnixAsynchronousSocketChannelImpl.finish(UnixAsynchronousSocketChannelImpl.java:191) ~[?:1.8.0_212]
at sun.nio.ch.UnixAsynchronousSocketChannelImpl.onEvent(UnixAsynchronousSocketChannelImpl.java:213) ~[?:1.8.0_212]
at sun.nio.ch.EPollPort$EventHandlerTask.run(EPollPort.java:293) ~[?:1.8.0_212]
at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112) ~[?:1.8.0_212]
... 3 more
Suppressed: java.lang.IllegalStateException: The connection has been closed.
at org.glassfish.tyrus.core.TyrusSession.checkConnectionState(TyrusSession.java:507) ~[?:?]
at org.glassfish.tyrus.core.TyrusSession.getAsyncRemote(TyrusSession.java:183) ~[?:?]
at rocks.xmpp.websocket.net.WebSocketConnection.write(WebSocketConnection.java:129) ~[?:?]
at rocks.xmpp.websocket.net.client.WebSocketClientConnection.send(WebSocketClientConnection.java:129) ~[?:?]
at rocks.xmpp.websocket.net.WebSocketConnection.closeStream(WebSocketConnection.java:100) ~[?:?]
at rocks.xmpp.core.net.AbstractConnection.closeAsync(AbstractConnection.java:111) ~[?:?]
at rocks.xmpp.core.net.AbstractConnection.close(AbstractConnection.java:136) ~[?:?]
at rocks.xmpp.core.session.XmppSession.closeAndNullifyConnection(XmppSession.java:1332) ~[?:?]
at rocks.xmpp.core.session.XmppSession.notifyException(XmppSession.java:1356) ~[?:?]
at rocks.xmpp.websocket.net.client.WebSocketClientConnection.lambda$new$2(WebSocketClientConnection.java:118) ~[?:?]
at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:760) ~[?:1.8.0_212]
at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:736) ~[?:1.8.0_212]
at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) ~[?:1.8.0_212]
at java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:1977) ~[?:1.8.0_212]
at rocks.xmpp.websocket.net.client.WebSocketConnectionConfiguration$2.onClose(WebSocketConnectionConfiguration.java:271) ~[?:?]
at org.glassfish.tyrus.core.TyrusEndpointWrapper.onClose(TyrusEndpointWrapper.java:1235) ~[?:?]
at org.glassfish.tyrus.core.TyrusWebSocket.onClose(TyrusWebSocket.java:106) ~[?:?]
at org.glassfish.tyrus.core.ProtocolHandler.close(ProtocolHandler.java:445) ~[?:?]
at org.glassfish.tyrus.core.TyrusWebSocket.close(TyrusWebSocket.java:240) ~[?:?]
at org.glassfish.tyrus.client.TyrusClientEngine$2$1.close(TyrusClientEngine.java:612) ~[?:?]
at org.glassfish.tyrus.container.jdk.client.ClientFilter.processConnectionClosed(ClientFilter.java:218) ~[?:?]
at org.glassfish.tyrus.container.jdk.client.Filter.onConnectionClosed(Filter.java:124) ~[?:?]
at org.glassfish.tyrus.container.jdk.client.Filter.onConnectionClosed(Filter.java:128) ~[?:?]
at org.glassfish.tyrus.container.jdk.client.TransportFilter$4.completed(TransportFilter.java:276) ~[?:?]
at org.glassfish.tyrus.container.jdk.client.TransportFilter$4.completed(TransportFilter.java:266) ~[?:?]
at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) ~[?:1.8.0_212]
at sun.nio.ch.UnixAsynchronousSocketChannelImpl.finishRead(UnixAsynchronousSocketChannelImpl.java:430) ~[?:1.8.0_212]
at sun.nio.ch.UnixAsynchronousSocketChannelImpl.finish(UnixAsynchronousSocketChannelImpl.java:191) ~[?:1.8.0_212]
at sun.nio.ch.UnixAsynchronousSocketChannelImpl.onEvent(UnixAsynchronousSocketChannelImpl.java:213) ~[?:1.8.0_212]
at sun.nio.ch.EPollPort$EventHandlerTask.run(EPollPort.java:293) ~[?:1.8.0_212]
at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112) ~[?:1.8.0_212]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_212]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_212]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_212]
I have not a JAVA developer, so the stacktrace is not helpful for me 
Anyone with an idea?
See post 239 (exact same error), with proposed solution in post 240, i.e. do a bundle:restart org.openhab.binding.freeathome from the OH console.
thank you, works well!
Is it possible to integrate the wireless window sensor?
I mean this component: https://www.busch-jaeger.de/produktuebersicht?tx_nlbjproducts_catalog[action]=show&tx_nlbjproducts_catalog[catBjeProdukt]=3660&tx_nlbjproducts_catalog[catStdArtikel]=3876&tx_nlbjproducts_catalog[controller]=CatStdArtikel&cHash=898316c3918f833e128df1a7a5e8e250
Window sensors are not integrated from before. However, it might be they are operating similar as a regular switch, and could be implemented as such.
Although, as could be read from previous posts above, you would need to identify the “devicetypeID” (from dummy thing name listed in PaperUI inbox). You would also need to identify which channel and idp/odp the window sensor is operating under (from SysAp monitor or using Postman software following ABB developer program).
ok, I will test this later today, if get it working, I will post an update, thx for your work and support here.
So, I collected some information about one of my window sensors:
Device: ABBXXXXXXXXX/ch0001
WindowDoor [0x0035] => 1
WindowPosition [0x0029] => 100% <=== Open
WindowPosition [0x0029] => 0% <=== Closed
0x0035: PID_WindowDoorSensor
0x0029: PID_WindowDoorPosition
Then I created a freeathome.things file:
Bridge freeathome:bridge:mybridge [host="192.168.178.xxx", port="5280", login="openhab", password="<password>", dummy_things_enabled="true"] {
Thing freeathome:switch:ABBXXXXXXXXX_ch0001 "Fenster: Balkon links" @ "LivingRoom" [DeviceID="ABBXXXXXXXXX", ChannelId="ch0001", dataPointId="idp0000", dataPointIdUpdate="odp0000"]
}
Then I added it to my sensors.items file:
Switch LivingRoom_WindowSensor "Balkon: links"
<switch> (LivingRoom, Sensors)
{channel="freeathome:switch:ABBXXXXXXXXX_ch0001:fh_switch_channel"}
If I use the sensor and open my window I get nothing in the logs, so it is not working yet.
My problem is, I have no idea which idp/odp values are correct one and which properties I have to set.
Also I am not sure, if the device type switch is correct.
Can anyone give me a hint where and how I can get the missing information?
The values above I have found in the monitor of the access point and on page I from ABB.
Well, then you have identified the channel in use by the window sensors, i.e. ch0001.
Although, still missing some missing/required input:
-
DevicetypeID as used by the binding to create/define things. See example in Post 222. You would need to enable dummy things for your bridge in Paper UI and do a discovery: Identify your window sensor(s) from inbox, and present your result.
-
Idp/odp in use
You can identify those using the Postman software, i.e. by following the ABB development program. Alternatively, when accessing your SysAp via a web browser, enable development mode/tools. Then you can identify the websocket session, and then you’ll be able to see all events/updates occurring. Further you can screen your window sensors searching by serial, and then you can identify idp/odp.
here we go:
This part is a bit tricky. I have no access to the AAB development programm (yet), I ask about 2 years ago, but the request was rejected. I asked again for access some days ago, but no response until now.
I also had the idea to get this information from the websocket connection, but the messages are encrypted, they looks like this:
<message id="stz317355" from="mrha@busch-jaeger.de" to="installer@busch-jaeger.de" type="headline"><event xmlns="http://jabber.org/protocol/pubsub#event"><items node="http://abb.com/protocol/update_encrypted"><item id="item317354"><update xmlns="http://abb.com/protocol/update_encrypted"><data>6JSupofMvh1Zahe6GshN7fF.....iQI/bmTlCE2DAbNXWyCr+NKxCZSxjP</data></update></item></items></event></message>
Is it possible to decrypt the messages?
How does this work? Which tools or commands can I use?
Hi Frank,
I have integrated this sensor in openhab. It pretty easy. All what you need is the device ID and you have to know that channel ch0001 represents the status of the sensor.
I always look up the device ID within the free@home webinterface under device configuration. There you can see for every device the ID. It is starting with ABBXXX.
In Paper UI go in the inbox, click the plus button, select the free@home binding, click “ADD MANUALLY” at the bottom and select Switch.
Here my configuration:
@kjoglums: Do you think it is possible to extend the function for this windows sensor? In Postman I recognized 3 different states of this sensor:
0 = closed
33 = tilted
100 = opened
With the solution as describe above I get only the states closed and opened (when opened or tilted).
Then we also have the idp/odp of the window sensor open/close, i.e. idp0000/odp0000, the same as a regular switch. Which will be required for binding implementation.
@Jens_Hoffmann
As a first instance, could you try to define the window contact as a dimmer instead? It operates under the same idp/odp for open/close (on/off), but has also some additional idps/odps with default values, including an odp for percentage value (i.e. defaults at odp0001). Would assume the percentage value also could reflect window contact state.
If the window contacts operate similar as a dimmer, i.e. under same idps/odps, it will be easy to implement them for auto discovery in the binding.
Assuming you also have the window contacts recognized as “Fenster/Tür_2042”?
Great Idea. It works. The Channel “Dimmer Value” shows now the values 0% = closed, 33% = tilted and 100% = opened.
I am not sure what you mean wit "Assuming you also have the window contacts recognized as “Fenster/Tür_2042”.
Just for information the Postman output for that device:
{
"XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX": {
"devices": {
"ABB700XXXXXX": {
"channels": {
"ch0001": {
"displayName": "Fenstergriff Terrasse EG",
"functionID": "0064",
"inputs": {},
"outputs": {
"odp0000": {
"pairingID": 53,
"value": "1"
},
"odp0001": {
"pairingID": 41,
"value": "33"
}
}
}
},
"displayName": "Fenstergriff Terrasse EG",
"floor": "02",
"room": "05",
"unresponsive": false
}
}
}
}
Thanks to @Cuver77 the configuration works perfectly. I am very new to openHab, so maybe this was also a reason for my problems.
Also many thanks also to @kjoglums for your support and work on this project.
Do you plan to add the window sensors into the add-on? If yes, I would wait before configuring all my sensors and could be your tester 
With the same workaround I was able to add my motion detectors with the on/off switch and the value for the current light level. until now I have always created the motion detectors as motion detectors and now as a dimmer. The light level is at opd0002.
And the Postman output for the motion detector witout actuator:
{
"XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX": {
"devices": {
"ABB700XXXXXX": {
"channels": {
"ch0000": {
"displayName": "Bewegungsmelder",
"floor": "04",
"functionID": "0011",
"inputs": {
"idp0000": {
"pairingID": 256,
"value": "0"
}
},
"outputs": {
"odp0000": {
"pairingID": 6,
"value": "1"
},
"odp0001": {
"pairingID": 7,
"value": "1"
},
"odp0002": {
"pairingID": 1027,
"value": "15"
}
},
"room": "0F"
}
},
"displayName": "Bewegungsmelder",
"floor": "04",
"room": "0F"
}
}
}