Busch-Jaeger Free@Home

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 :wink:
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:

  1. 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.

  2. 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 :slight_smile:

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.

Screenshot_Paperui

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"
      }
    }
  }

@Jens_Hoffmann
Appreciate your Postman input and for being of great help to further develop the binding. I have updated binding code in an attempt to include the lux value under odp as you have presented for motion detectors (see download further below).

The binding should then include the new feature by default for motion detectors, meaning thingtypeid “9008”, “1008” and “9009” (as presented in Paper UI inbox) if using autodiscovery. These motion detectors would be operating under ch0000 per default, with default set features/channels:

  • idp0000: Set value (on/off) for switch (it actually works forcing state change in OH)
  • odp0000: Read value (on/off) for switch
  • odp0002: Read value for lux

@NeoBlack
The binding code is also updated in an attempt to include Window sensors, based on above provided input.

Window sensors are introduced as a new thing selection. For autodiscovery, thingtypeid “2042” should be recognised as a window sensor. The window sensors would per default be operating under ch0001, with the following default features/channels:

  • odp0000: Read value (open/closed) for contact
  • odp0001: Read value for percentage

Please feel free to report any issues / non-working features.

F@H 2.5.4-SNAPSHOT.jar

1 Like

Sorry, missed out on a detail for the motion detector lux value. Try downloading from the link above once again.