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?
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).
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.
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:
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.
@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â?
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:
@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.
