After upgrade f@h sysAP bridge offline

[phil0002]

After updating the FW of the sysAP from v2.1 to v2.2.4 the bridge is offline (Communication error)

The port numbers are the same as before (80, 5222, 5280). Please let me know if I can provide you more data or need more information.

What did: Login to the system (control, not configure), switched a light (2/2) on/off, switched a second light (1/1) on/off and pushed the shutter button a few times (up and

Archive 19-02-26 21-48-56.zip

[kjoglum]

To follow up with some troubleshooting: Obviously the SysAp link/authentication is broken with the 2.2.4 version (would assume the things/items would work as normal if the bridge got back online and ensuring link between the things and the bridge).

I have tried the following without success:

• Uninstall the FreeAtHome bridge under Things in PaperUI
• Cleared OH cache / tmp: https://community.openhab.org/t/clear-the-cache/36424
• Re-installed the FreeAtHome bridge as a Thing in PaperUI

Get the following errors from Openhab log: 2019-03-04 21:35:55.557 [ERROR] [home.handler.FreeAtHomeBridgeHandler] - Can not connect to IP gateway ==> /var/log/openhab2/events.log <== 2019-03-04 21:35:55.559 [hingStatusInfoChangedEvent] - 'freeathome:bridge:278377a1' changed from INITIALIZING to OFFLINE (COMMUNICATION_ERROR): Can not connect to SysAP with address: xxx.xxx.xxx.xxx ==> /var/log/openhab2/openhab.log <== 2019-03-04 21:35:55.560 [ERROR] [home.handler.FreeAtHomeBridgeHandler] - The connection was terminated due to HTTP error 404 ==> /var/log/openhab2/events.log <== 2019-03-04 21:35:55.580 [hingStatusInfoChangedEvent] - 'freeathome:bridge:278377a1' changed from OFFLINE (COMMUNICATION_ERROR): Can not connect to SysAP with address: xxx.xxx.xxx.xxx to OFFLINE (BRIDGE_OFFLINE): XMPP connection lost

[kjoglum]

Additional log error wrt discovery:

2019-03-04 21:35:00.913 [ERROR] [nternal.DiscoveryServiceRegistryImpl] - Cannot trigger scan for thing types '[freeathome:dimmer, freeathome:raffstore, freeathome:bridge, freeathome:thermostat, freeathome:dummy, freeathome:switch, freeathome:weather, freeathome:scene, freeathome:scenario_selector]' on 'FreeAtHomeBindingDiscoveryService'!

java.lang.NullPointerException: null at org.openhab.binding.freeathome.handler.FreeAtHomeBridgeHandler.getAll(FreeAtHomeBridgeHandler.java:263) ~[?:?] at org.openhab.binding.freeathome.discovery.FreeAtHomeBindingDiscoveryService.startScan(FreeAtHomeBindingDiscoveryService.java:57) ~[?:?] at org.eclipse.smarthome.config.discovery.AbstractDiscoveryService.startScan(AbstractDiscoveryService.java:211) ~[98:org.eclipse.smarthome.config.discovery:0.10.0.oh240] at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:381) [98:org.eclipse.smarthome.config.discovery:0.10.0.oh240] at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScans(DiscoveryServiceRegistryImpl.java:366) [98:org.eclipse.smarthome.config.discovery:0.10.0.oh240] at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:215) [98:org.eclipse.smarthome.config.discovery:0.10.0.oh240] at org.eclipse.smarthome.io.rest.core.internal.discovery.DiscoveryResource.scan(DiscoveryResource.java:97) [120:org.eclipse.smarthome.io.rest.core:0.10.0.oh240] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?] at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) [171:org.glassfish.jersey.core.jersey-common:2.22.2] at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) [171:org.glassfish.jersey.core.jersey-common:2.22.2] at org.glassfish.jersey.internal.Errors.process(Errors.java:315) [171:org.glassfish.jersey.core.jersey-common:2.22.2] at org.glassfish.jersey.internal.Errors.process(Errors.java:297) [171:org.glassfish.jersey.core.jersey-common:2.22.2] at org.glassfish.jersey.internal.Errors.process(Errors.java:267) [171:org.glassfish.jersey.core.jersey-common:2.22.2] at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) [171:org.glassfish.jersey.core.jersey-common:2.22.2] at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2] at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2] at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76) [20:com.eclipsesource.jaxrs.publisher:5.3.1.201602281253] at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:865) [85:org.eclipse.jetty.servlet:9.4.11.v20180605] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:535) [85:org.eclipse.jetty.servlet:9.4.11.v20180605] at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [186:org.ops4j.pax.web.pax-web-jetty:7.2.3] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) [82:org.eclipse.jetty.security:9.4.11.v20180605] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293) [186:org.ops4j.pax.web.pax-web-jetty:7.2.3] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) [85:org.eclipse.jetty.servlet:9.4.11.v20180605] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [186:org.ops4j.pax.web.pax-web-jetty:7.2.3] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.Server.handle(Server.java:531) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281) [75:org.eclipse.jetty.io:9.4.11.v20180605] at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) [75:org.eclipse.jetty.io:9.4.11.v20180605] at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) [75:org.eclipse.jetty.io:9.4.11.v20180605] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) [87:org.eclipse.jetty.util:9.4.11.v20180605] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) [87:org.eclipse.jetty.util:9.4.11.v20180605] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) [87:org.eclipse.jetty.util:9.4.11.v20180605] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) [87:org.eclipse.jetty.util:9.4.11.v20180605] at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) [87:org.eclipse.jetty.util:9.4.11.v20180605] at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:762) [87:org.eclipse.jetty.util:9.4.11.v20180605] at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:680) [87:org.eclipse.jetty.util:9.4.11.v20180605] at java.lang.Thread.run(Thread.java:748) [?:?]

[phil0002]

@ruebox we put all our hopes in you :-)

[kjoglum]

Totally agree :) See from normal web login to F@H that the hash key now is introduced automatically as part of the IP address (xxx.xxx.xxx.xxx/#). Not sure if this also was the case for FW 2.1, nor if this could affect OpenHab login, but found it worth mentioning.

[kjoglum]

Sorry for spamming this thread...

Quite frustrated over not being able to use Openhab with F@H 2.2.4, although with too little programming competence to be able to see / fix the real problem.

I have studied the source code, and based on the log message, the problem seems to be related to the "m_XmppClient.connect()" in the "FreeAtHomeBridgeHandler.java".

I tried to uninstall the FreeAtHome binding (PaperUI) and remove cache. When I reinstalled the binding, and using setup with installer jid, I get the following error messages (similar to what has been seen previously based on thread in openhab community):

2019-03-16 21:00:44.175 [ERROR] [home.handler.FreeAtHomeBridgeHandler] - Can not connect to IP gateway

2019-03-16 21:00:44.188 [ERROR] [home.handler.FreeAtHomeBridgeHandler] - javax.xml.bind.JAXBException: class rocks.xmpp.extensions.httpbind.model.Body nor any of its super class is known to this context.

Have been trying with different connection ports, 80, 5280, 5222, all with same results.

[kjoglum]

And wrt xmpp-websocket / BOSH, there is some description in the login.har file pointing in the direction of a recommendation for xmpp/bosh (maybe this has been the case all along):

"WebSocket also usually does not work well with reverse\n proxies, be sure to make extensive tests if you use one.\n \n There is no standard for XMPP over WebSocket. However, there is a\n draft (http://tools.ietf.org/html/draft-ietf-xmpp-websocket-00) and\n this implementation follows it.\n \n Tested servers:\n \n - node-xmpp-bosh (https://github.com/dhruvbird/node-xmpp-bosh) -\n "

[lassem]

I have in the past run Babbler (xmpp.rocks) with a BOSH connection. It's a trivial change to implement.

[kjoglum]

@lassem, and you have upgraded F@H FW to 2.2.4? Which version of xmpp.rocks do you use?

The FreeAtHome binding also use xmpp.rocks with BOSH connection (as it seems from the source code). Although version 0.6.2. See from mvn respository the latest version available is 0.8.1.

[lassem]

I have updated to 2.2.4, but I am currently not running OpenHab at all, but rather a Home Assistant setup coupled with https://github.com/jheling/freeathome

In order to run xmpp.rocks with a BOSH connection one merely has to use the BoshConnectionConfiguration.builder (https://sco0ter.bitbucket.io/babbler/xep/httpbind.html) instead of the default TcpConnection. It does, however, require changes to the code.

[kjoglum]

Well, a bit impatient here, so even though being completely noob at programming, I have "thrown my self" into the the Eclipse IDE game.

So, I have cloned the @ruebox binding, and I think (maybe) I have been able to adjust the code in order to be able to connect to the bridge again. So in basic, what I have done is:

• Downloaded 0.8.1 xmpp files in the /lib folder and "built path" as referenced library within the project. Thus deleting 0.6.2 files and deleting reference from @ruebox code. Thus also making adjustments to the MANIFEST file (reference).
• Made adjustments to the FreeAtHomeBridgeHandler and making BOSH as the only connection alternative (outruling Xmpp_Client TCP).
• Due to problems in Eclipse project I also had to make changes to the RpcManager coding.
• Managed to have a project free of problems (although with several warnings)

However, now my problem is to get the binding installed for PaperUI manual configuration of my bridge. After generating .jar file from Eclipse and placing within openhab/addons, no binding is showing up under PaperUI - Configuration - Bindings. Note, I kept my things/items from when the binding was working (hopefully just to link to newly configured bridge)I, and I now see from openhab log (even without configured bridge) that there is communication/status updates from the free@home things/items.

So not sure how to proceed. Have not found out how to push updates to my github respository for you guys to see the code as it seems as my only alternative is to push to @ruebox respository (assume this is an easy fix).

But hopefully @ruebox would be interested to see the changes to possibly make it as part of the marketplace binding..?

[codecamp-n]

Is there any progress on this, @ruebox? Looking forward for an update, too.

[kjoglum]

I have made some effort trying to get a working binding for F@H 2.2.4 FW version.

However, have been struggling, as it seems as XMPP over BOSH (at least using the Babbler library) is no longer possible. Meaning, connecting using http://localhost:5280/http-bind/ is no longer an option (as I have figured out). Neither does it seem as XMPP over TCP using port 80 is possible.

From browser login, it seems as XMPP over websocket is the recommended approach (localhost:5280/xmpp-websocket/). So, I have tried to transform the binding code to websocket connection, upgrading Babbler XMPP library to version 0.8.1 (library set up for XMPP over websocket based on standard protocols).

However, then the F@H bridge apparently follows an old version of the XMPP / websocket protocol, and I haven´t been able to customize the Babbler websocket code to match the code with the actual client/bridge stream. Starting to give up...

[kjoglum]

Well luckily I didn't just give up, as I was closer to the answer than I anticipated.

So, I now actually have a working F@H OpenHab binding for the 2.2.4 FW version. Meaning, the @ruebox code as "background", with some modifications still work. I (think) I have managed to transform the code using rocks xmpp 0.8.1 version, now aiming for xmpp over websocket (instead of xmpp over BOSH), customizing the rocks library due to the "strange" F@H xmpp protocol over websocket. So, my customized binding aim at connecting to "sysap_ipaddress:5280/xmpp-websocket", and at least for myself, I manage to connect to server and login, and to allow previous implemented xmpp protocol to communicate from/to OpenHab.

Need to test some more before I will make the .jar file available for download/testing. I control most of the things/items implemented for the marketplace binding, things discovery also works as before, however, see some of the scene activation is not working as supposed to with the new binding.

[danielboth]

Nice work @kjoglum! I just came here since this weekend my SysAP updated to 2.2.4 and guess what, I ran into the same issue connecting to the SysAP. Awesome to hear you have a solution ready, any chance you can push the code changes to a (new) repository already?

[kjoglum]

I haven't pushed the code changes to a new respository yet.

Wanted to wait for further testing, but realize it would be of benefit to get some external testing as well. So a preliminary solution could be to download the .jar file from: https://1drv.ms/u/s!Aoa2B3iUQJCngfFGvLDjIjVmLwIwMQ

Way of testing (at own risk) would be (assuming PaperUI approach):

• Uninstall FreeAtHome marketplace binding
• Remove FreeAtHome bridge from things (other F@H things/items can remain)
• Delete openhab2 cache/tmp files
• Reboot openhab
• Download jar and place in openhab2-addons folder (automatic binding install)
• Manual install bridge as thing within PaperUI:
  • SysAP Host = Local sysap IP address
  • Port = 5280
  • Login user = user with installer rights (should work as before)
  • Should then automatically create and open connection to ws://local_sysap_id:5280/xmpp-websocket/
• Connecting to server could take some time due to the websocket handshake / open stream features.
• When bridge (hopefully) appears online, it should be possible to allocate online bridge to the existing F@H things within PaperUI

Note: For some of mye existing rules, I had to run some activation/deactivation via PaperUI "control" to get the correct response from different switches.

[kjoglum]

And for the scenes to work, I had to reinstall scenes as things (from inbox) and update my .items file with the new reference.

[kjoglum]

Try to copy url and paste in browser.

[TheSpirit]

do the blinds work correctly again? i have the problem, when moving my blinds via the physical buttons, i do not see than change within openhab anymore. some info on this would be nice. thanks for your great work

[kjoglum]

Do not dare to say.

My primary objective for the new binding was to generate a working connection with the latest F@H FW version (2.2.4).

Also did some changes to the stanza code, but not sure if this improved blinds configuration/communication, neither do I have blinds myself to test with.

[danielboth]

Downloaded the new .jar file created by @kjoglum, after rebinding my things to the free@home bridge all works as before. Thanks again @kjoglum !!

[Stouni]

@kjoglum Sorry, your Link didn't work :-(

[kjoglum]

Need to copy url and paste in browser.

[Stouni]

I copied the url and paste in browser but there is nothing

[kjoglum]

Well, I am struggling to push my Free@Home Eclipse IDE project to my own github (both directly via Eclipse and also via Mac terminal), so sorry for spamming your account @ruebox.

At the same time I have made some changes to the binding as an effort to also enable discovery and implementation of 4.3" touch panels (DevideID = 1020) with integrated thermostat. Haven't been able to test fully, but hopefully the disovery and implementation works for others as well, and hopefully you can manage to download updated .jar file at either of the below locations:

Note: As this binding is intended as a fix for the F@H 2.2.4 FW version I have no idea how the binding will work under other FW versions.

https://1drv.ms/u/s!Aoa2B3iUQJCngfFHSNwWfAJ1KcRClw?e=gT7cz3

https://www.dropbox.com/s/49geswfztxmt1ry/org.openhab.binding.freeathome-2.5.0-SNAPSHOT.jar?dl=0

[danielboth]

Hi @kjoglum, maybe I can help to get your changes pushed to your own repository.

1. First of all, you need to have git installed locally, I'm assuming you already have, but just to be sure.
2. Fork the repository of @ruebox, this will create a copy of the repo to your account.
3. Create a local copy of your just created copy by creating a clone (git clone https://github.com/kjoglum/openhab2-addons.git
4. Create a new branch on your copy, for example: git checkout -b fix-sysap224-connection
5. Apply the changes to the code you did on the local copy
6. Stage the changes for commit (git commit -am "Fix for SysAp 2.2.4. connection issues") for example.
7. Push the changes to your branch: git push origin fix-sysap224-connection

Next we could then pull request your changes into this repository, but lets first get the steps above here done.

[kjoglum]

Appreciate your guidance @danielboth! My mistake (I believe) was to have cloned a openhab2 respository without the Free@Home addon, then trying to implement the F@H addon as part of this respository. Anyhow, it worked when cloning @ruebox respository.

So, I have now created my own github respository / branch for the F@H binding upgrade: https://github.com/kjoglum/openhab2-addons/tree/F%40H-2.2.4-Upgrade/addons/binding/org.openhab.binding.freeathome

Note that some of the reference / links still are referring to @ruebox version.

[Stouni]

@kjoglum Sorry, I have a Problem.

2019-04-20 14:09:12.055 [ERROR] [nternal.DiscoveryServiceRegistryImpl] - Cannot trigger scan for thing types '[freeathome:dimmer, freeathome:raffstore, freeathome:bridge, freeathome:thermostat, freeathome:dummy, freeathome:switch, freeathome:weather, freeathome:scene, freeathome:touch, freeathome:scenario_selector]' on 'FreeAtHomeBindingDiscoveryService'! java.lang.IllegalStateException: Cannot send stanzas before resource binding has completed. at rocks.xmpp.core.session.XmppSession.sendInternal(XmppSession.java:887) ~[?:?] at rocks.xmpp.core.session.XmppSession.trackAndSend(XmppSession.java:1002) ~[?:?] at rocks.xmpp.core.session.XmppSession.sendIQ(XmppSession.java:975) ~[?:?] at rocks.xmpp.core.session.XmppSession.sendAndAwait(XmppSession.java:824) ~[?:?] at rocks.xmpp.core.session.XmppSession.query(XmppSession.java:750) ~[?:?] at rocks.xmpp.core.session.XmppSession.query(XmppSession.java:735) ~[?:?] at rocks.xmpp.extensions.rpc.RpcManager.call(RpcManager.java:113) ~[?:?] at org.openhab.binding.freeathome.internal.handler.FreeAtHomeBridgeHandler.getAll(FreeAtHomeBridgeHandler.java:193) ~[?:?] at org.openhab.binding.freeathome.internal.discovery.FreeAtHomeBindingDiscoveryService.startScan(FreeAtHomeBindingDiscoveryService.java:60) ~[?:?] at org.eclipse.smarthome.config.discovery.AbstractDiscoveryService.startScan(AbstractDiscoveryService.java:211) ~[98:org.eclipse.smarthome.config.discovery:0.10.0.oh240] at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:381) [98:org.eclipse.smarthome.config.discovery:0.10.0.oh240] at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScans(DiscoveryServiceRegistryImpl.java:366) [98:org.eclipse.smarthome.config.discovery:0.10.0.oh240] at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:215) [98:org.eclipse.smarthome.config.discovery:0.10.0.oh240] at org.eclipse.smarthome.io.rest.core.internal.discovery.DiscoveryResource.scan(DiscoveryResource.java:97) [120:org.eclipse.smarthome.io.rest.core:0.10.0.oh240] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?] at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) [171:org.glassfish.jersey.core.jersey-common:2.22.2] at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) [171:org.glassfish.jersey.core.jersey-common:2.22.2] at org.glassfish.jersey.internal.Errors.process(Errors.java:315) [171:org.glassfish.jersey.core.jersey-common:2.22.2] at org.glassfish.jersey.internal.Errors.process(Errors.java:297) [171:org.glassfish.jersey.core.jersey-common:2.22.2] at org.glassfish.jersey.internal.Errors.process(Errors.java:267) [171:org.glassfish.jersey.core.jersey-common:2.22.2] at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) [171:org.glassfish.jersey.core.jersey-common:2.22.2] at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) [172:org.glassfish.jersey.core.jersey-server:2.22.2] at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2] at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2] at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76) [20:com.eclipsesource.jaxrs.publisher:5.3.1.201602281253] at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:865) [85:org.eclipse.jetty.servlet:9.4.11.v20180605] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:535) [85:org.eclipse.jetty.servlet:9.4.11.v20180605] at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [186:org.ops4j.pax.web.pax-web-jetty:7.2.3] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) [82:org.eclipse.jetty.security:9.4.11.v20180605] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293) [186:org.ops4j.pax.web.pax-web-jetty:7.2.3] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) [85:org.eclipse.jetty.servlet:9.4.11.v20180605] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [186:org.ops4j.pax.web.pax-web-jetty:7.2.3] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.Server.handle(Server.java:531) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281) [75:org.eclipse.jetty.io:9.4.11.v20180605] at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) [75:org.eclipse.jetty.io:9.4.11.v20180605] at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) [75:org.eclipse.jetty.io:9.4.11.v20180605] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) [87:org.eclipse.jetty.util:9.4.11.v20180605] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) [87:org.eclipse.jetty.util:9.4.11.v20180605] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) [87:org.eclipse.jetty.util:9.4.11.v20180605] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) [87:org.eclipse.jetty.util:9.4.11.v20180605] at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) [87:org.eclipse.jetty.util:9.4.11.v20180605] at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:762) [87:org.eclipse.jetty.util:9.4.11.v20180605] at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:680) [87:org.eclipse.jetty.util:9.4.11.v20180605] at java.lang.Thread.run(Thread.java:748) [?:?]

[kjoglum]

@Stouni apparently the websocket handshake / stream negotiation hasn't worked for you. I.e. there is an automatic stream negotiation created by the binding which needs to be completed before the actual connection / login will happen. That's the reason why you get "Cannot send stanzas before resource binding has completed".

Two things comes to mind:

1. Are you sure you have the F@H FW version 2.2.4 installed on your SysAp? That is the target FW version for the updated binding, as websocket connection apparently is the only approved method for connection after the upgrade. Using a regular web browser: (i) What does your browser respond if you try to enter: SysAP_IP_Address:5280/xmpp-websocket/ (ii) What does your browser respond if you try to enter: SysAP_IP_Address:5280/http-bind/

2. If you still think your SysAP has installed version 2.2.4, meaning websocket should be the way of connecting, I would recommend to uninistall F@H bridge in PaperUI, run OpenHab reboot and manually re-install the bridge again in PaperUI. As part of the manual re-install, also have a window open where you have the log running (i.e. OpenHab_IP_Address:9001). Would be interesting to see the steps after "initializing".

[Stouni]

@kjoglum The Firmware on my SysAp is the version 2.2.4.

1. What does your browser respond if you try to enter: SysAP_IP_Address:5280/xmpp-websocket/ It works! Now point your WebSocket client to this URL to connect to Prosody.

2. What does your browser respond if you try to enter: SysAP_IP_Address:5280/http-bind/ 404 Not Found. Whatever you were looking for is not here. It's behind you.

[kjoglum]

@Stouni Then for sure the websocket handshake / stream negotiation implemented in the binding should work.

Would then recommend the approach suggested under bullet 2 above, including deselecting "getall" when re-installing your bridge in PaperUI:

"I would recommend to uninistall F@H bridge in PaperUI, run OpenHab reboot and manually re-install the bridge again in PaperUI. As part of the manual re-install, also have a window open where you have the log running (i.e. OpenHab_IP_Address:9001). Would be interesting to see the steps after "initializing", i.e. how the stream flow develops (in your log file you should see an element like "<stream:stream....")"

[Stouni]

@kjoglum How can I deselect "getall"?

After rebooting OpenHab and manually re-install the bridge again in PaperUI, I get this in the log running:

2019-04-21 22:37:08.269 [hingStatusInfoChangedEvent] - 'freeathome:bridge:8b8ca22e' changed from UNINITIALIZED to INITIALIZING ==> /var/log/openhab2/openhab.log <== 2019-04-21 22:37:11.416 [INFO ] [rnal.handler.FreeAtHomeBridgeHandler] - Login: User with the current jid: *****@busch-jaeger.de 2019-04-21 22:37:11.419 [INFO ] [rnal.handler.FreeAtHomeBridgeHandler] - Login: Admin with the current jid: installer@busch-jaeger.de 2019-04-21 22:37:11.422 [INFO ] [rnal.handler.FreeAtHomeBridgeHandler] - Matching jid for login(Installer)
2019-04-21 22:37:11.425 [WARN ] [rnal.handler.FreeAtHomeBridgeHandler] - java.lang.IllegalArgumentException: jid must not be empty. 2019-04-21 22:37:11.436 [INFO ] [rnal.handler.FreeAtHomeBridgeHandler] - Login: User with the current jid: **@busch-jaeger.de 2019-04-21 22:37:11.439 [INFO ] [rnal.handler.FreeAtHomeBridgeHandler] - Login: Admin with the current jid: installer@busch-jaeger.de 2019-04-21 22:37:11.441 [INFO ] [rnal.handler.FreeAtHomeBridgeHandler] - Matching jid for login(Installer)
2019-04-21 22:37:11.448 [WARN ] [rnal.handler.FreeAtHomeBridgeHandler] - java.lang.IllegalStateException: You must be connected to the server before trying to login. Status is INITIAL ==> /var/log/openhab2/events.log <== 2019-04-21 22:37:11.455 [hingStatusInfoChangedEvent] - 'freeathome:bridge:8b8ca22e' changed from INITIALIZING to OFFLINE (CONFIGURATION_ERROR): Login on SysAP with login name: Installer (Login name could not be resolved) 2019-04-21 22:37:11.480 [hingStatusInfoChangedEvent] - 'freeathome:bridge:8b8ca22e' changed from OFFLINE (CONFIGURATION_ERROR): Login on SysAP with login name: Installer (Login name could not be resolved) to ONLINE ==> /var/log/openhab2/openhab.log <== 2019-04-21 22:37:11.570 [WARN ] [rnal.handler.FreeAtHomeBridgeHandler] - Could not successfully get the getAll.xml from sysAP. Can happen if connecting to server takes too long.

[kjoglum]

@Stouni

Sorry for my poor description. By deselecting "getall" I meant deselecting "Debug logging" in PaperUI (under input for bridge installation). I saw from your previous log, that the binding error was related to "getall" (which is an output automatically generated by the binding if selected as an option).

However, with the new input you provided, it seems as the problem is related to the user you are attempting to log in with in PaperUI. I.e. the user credentials filled in under "login name" is apparently not recognised as a user with actual "install" rights.

I see from the log that you for your SysAp have a Admin account and a regular login account. It also seems as you are using the regular account for PaperUI login, but is this an account with "install" role? You can check this by:

If you in your web browser enter: Sysap_IP_Address/settings.json, you will get to a page showing the users registered for your SysAp:

(i) If the account you are using to login to PaperUI is not listed as an "install" account you would need to either set up this account as "install" (in F@H bridge settings), or you would need to switch to using a "install" account in PaperUI. Ensure you are using "name" as "login name" in PaperUI. Based on the login name, the binding itself will find the associated jid (if the name provided is an actual account), and then also verify the account as an actual "install" account. (ii) If you already are using an "install" role as login in PaperUI, ensure you are using the "name" as login name in PaperUI (from settings.json described above). Based on the login name, the binding itself will find the associated jid (if the name provided is an actual account), and then also verify the account as an actual "install" account.

[Stouni]

@kjoglum Thanks a lot - it works!! GREAT

[voipmonitor]

@kjoglum - hi, I do not see https://github.com/kjoglum/openhab2-addons/tree/F%40H-2.2.4-Upgrade/addons/binding/org.openhab.binding.freeathome

have you ever uploaded it to your git repository please?

[kjoglum]

As for now, a working binding (jar file) compatible with F@H 2.2.4 and 2.2.5 (latest FW version), i.e. websocket connection, can be downloaded from the following locations: https://1drv.ms/u/s!Aoa2B3iUQJCngfFHSNwWfAJ1KcRClw?e=gT7cz3 https://www.dropbox.com/s/49geswfztxmt1ry/org.openhab.binding.freeathome-2.5.0-SNAPSHOT.jar?dl=0

@ruebox is working on merging the initial and revised binding, however, after the Openhab development upgrade (Eclipse IDE), we are "stuck" in the merging process. I attempted to start fresh, thus deleting my Github respository, but now have problems with the new Openhab development setup as the new setup requires a different skeleton compared to the previous setup.

[voipmonitor]

@kjoglum I wanted to do some changes in the dimmer_value to support ON/OFF commands or maybe if you can look at it and add this feature?

[ruebox]

@voipmonitor I generate a new binding jar based on the contribution of @kjoglum (PR #49) It would be great if you can check if this JAR is working with your B+J installation.

Regarding dimmer: What is your concrete request? If you would like to provide a source code contribution, you can just generate a pull request or please describe your idea / feature in more detail. Thanks a lot. Best, ruebox

[voipmonitor]

@ruebox the jar is directly in the pull request? I'm novice in the java development so I'm sorry for noob questions. The feature I need is:

freeathome:dimmer:ABB700C84689_ch0002:dimmer_value

this is dimmer value channel for dimming but it does not work when you send ON / OFF commands to it. In the android app if you configure dimmer (which is slicer) and you click on the row it sends ON / OFF command to this channel. I need that the command will be send like if you send ON / OFF to freeathome:dimmer:ABB700C84689_ch0002:dimmer_switch (dimmer_switch) - and not to substitute the ON to dimmer value 100 and OFF to dimmer value 0 - this is because if you switch the light off and on it will remember the last dimm value.

[ruebox]

hi @voipmonitor you will find the jar file in a comment of the pull request: https://github.com/ruebox/openhab2-addons/pull/48#issuecomment-487693308

I would highly appreciate if you could test the connection via websocket. If something is not working just leave me a note in PR #49.

[ruebox]

@voipmonitor: Regarding dimmer did I get it correctly that the current behavior is the following:

• e.g. dimmed to 50 %
• Switch off -> dimmer is switched off
• Switch on -> dimmer is switched on, but @ brightness = 100%

Requested behavior:

• e.g. dimmed to 50 %
• Switch off -> dimmer is switched off
• Switch on -> dimmer is switched on, but dimmed to 50 %

[voipmonitor]

@ruebox I have tested the jar and everything works as before, the only annoying line in log is: "2019-06-09 22:25:01.573 [WARN ] [websocket.codec.XmppWebSocketDecoder] - Decoding stream feature"

Regarding the dimmer -in the free@home - there is dimmer unit which can be switched on or off - and which can be set to specific dim value. If you turn off the dimmer (not via openhub but physically or via the freeathome native webpage) and turn it on again - it retains the last dim value. It does not change the dim value unless you specifically tell so.

In the openhab freeathome binding - I see that there are two channels - one for the setting dim value and one for the switch function. Now - I'm using for the dimmers slider in android UI where you can move it from 0 - 100 which is fine but if you want to turn it off and on again you have to add another item - switch. So now you have two items in UI - slider and switch. But one of the feature of the slider is (in the latest android UI beta) that if you click on the slider row it now sends ON / OFF commands to the Item (slider)- which is dimmer value (for example freeathome:dimmer:ABB700C84689_ch0002:dimmer_value) and the openhab sends ON / OFF commands to this channel - but it seems that this is not implemented in the binding. But - this must (or it should or at least to be configurable) be implemented not as setting 0 or 100 value but sending ON / OFF to the switch channel. So now you would have nicely working switch (on/off) in the slider which will preserve the last dimming value (normally at your home you are not moving with sliders or chaging dim values much - mostly you use switch on/off but sometimes you want to change the dim)

[ruebox]

@voipmonitor: Thx for testing. I generated a new release https://github.com/ruebox/openhab2-addons/releases/tag/v1.1.0-alpha that integrates the websocket support. I commented out the warn messages. Just install the binding via marketplace and check if it is working as expected. Thank you.

https://marketplace.eclipse.org/content/freeathome

Regarding dimmer: I created an issue #50 to track it. I would plan it for an upcoming release. Thx for proposing.