dss 1.14.4.1, openhab 2.4.0
Unfortunately this binding has been creating a lot of headaches lately. After the latest update on my digitalstrom software the dreaded “configuration pending” message took over again! the “funny” thing is, that other apps that also use the token don’t quit but continue to work. why?
I need road side asstistance as now all the connections between my homematic and digitalstrom items are interrupted, for example presence simulation.
Michael: can you help, please?
Hi
I had the same bad idea to upgrade dss to 1.14.4.1 and see the same problems with openhab 2.3.
Any help or tip is very welcome; thanks.
One of the developers provided a pull request which should solve the issues. It is under review and should be available soon.
How soon is “soon”?
It is included in the Milestone 5 build of openhab, which has been announced a couple of days ago.
Hello Hans-Jörg. Thanks for your swift reply. I know that I am too stupid for this whole project even though I am relentlessly reading the docs. But how in the world should I get that “Milestone 5” into my installation? I have no clue!
Hi Marc,
nobody says you are stupid.
Before using in production, I would setup a test environment and give the M5 a try.
That’s how I always do it.
Well I know I am as I tried to get the latest milestone into my OH setup. But obviously I managed to kill the whole system. I now get tons of errors such as:
2018-11-01 11:45:26.318 [ERROR] [org.jupnp.transport.spi.StreamClient] - Request: HttpRequest[GET /HNAP1/ HTTP/1.1]@cafedd failed
java.lang.NullPointerException: Missing SslContextFactory
at java.util.Objects.requireNonNull(Objects.java:228) ~[?:?]
at org.eclipse.jetty.io.ssl.SslClientConnectionFactory.<init>(SslClientConnectionFactory.java:50) ~[75:org.eclipse.jetty.io:9.4.11.v20180605]
at org.eclipse.jetty.client.HttpClient.newSslClientConnectionFactory(HttpClient.java:1155) ~[71:org.eclipse.jetty.client:9.4.11.v20180605]
at org.eclipse.jetty.client.HttpDestination.newSslClientConnectionFactory(HttpDestination.java:138) ~[71:org.eclipse.jetty.client:9.4.11.v20180605]
at org.eclipse.jetty.client.HttpDestination.<init>(HttpDestination.java:95) ~[71:org.eclipse.jetty.client:9.4.11.v20180605]
at org.eclipse.jetty.client.PoolingHttpDestination.<init>(PoolingHttpDestination.java:25) ~[71:org.eclipse.jetty.client:9.4.11.v20180605]
at org.eclipse.jetty.client.http.HttpDestinationOverHTTP.<init>(HttpDestinationOverHTTP.java:32) ~[71:org.eclipse.jetty.client:9.4.11.v20180605]
at org.eclipse.jetty.client.http.HttpClientTransportOverHTTP.newHttpDestination(HttpClientTransportOverHTTP.java:51) ~[71:org.eclipse.jetty.client:9.4.11.v20180605]
at org.eclipse.jetty.client.HttpClient.destinationFor(HttpClient.java:539) ~[71:org.eclipse.jetty.client:9.4.11.v20180605]
at org.eclipse.jetty.client.HttpClient.send(HttpClient.java:572) ~[71:org.eclipse.jetty.client:9.4.11.v20180605]
at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:727) ~[71:org.eclipse.jetty.client:9.4.11.v20180605]
at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:680) ~[71:org.eclipse.jetty.client:9.4.11.v20180605]
at org.jupnp.transport.impl.jetty.JettyStreamClientImpl$1.call(JettyStreamClientImpl.java:149) [219:org.jupnp:2.4.0]
at org.jupnp.transport.impl.jetty.JettyStreamClientImpl$1.call(JettyStreamClientImpl.java:1) [219:org.jupnp:2.4.0]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Again, I have no clue how to fix this. A search did not even point me to one solution. So, openhab ceased to work today. The annoying thing is the amount of time I invested to get all the scripts…
Hm, don’t know what happend, but that is exactly why I asked to setup a test environment.
Even if you have an apt-get installation, you could do a second install following the instructions under manual install.
Here are some basic steps:
Make a directory under /opt, e.g. /opt/openhab-2.4.0.M5
extract the downloaded openhab-2.4.0.M5.zip into that folder
change ownership to user and group opnehhab
mark all files as executable
stop running openHAB service
start the test environment by using start_debug.sh
Do basic setupsteps in PaperUI and install the digitalsstrom Binding.
Se how it works …
Any luck with a test environement ???
Hello Hans-Jörg. No, I was busy all day long today. Plus I am around 4000 Kilometers from home… I do have an vpn connection though. I will give it a try tomorrow.
Hello Hans-Jörg
I gave it a try. My level of Linux knowledge is clearly not enough to get this done… Thank you for your help, anyways. What I will do when I go home next time is starting with a fresh stable openhab installation, trying to incorporate all my previous work. I hope this will restore most of the funcionality I had two weeks ago (before the dss update). But clearly, the digitalstrom binding is not well enough supported for my knowledge level. I am not complaining, this is the difference between a paid-for product and a freebie. However I would rather pay but safeguard my time investment.
I tried M5 yesterday and since months the bridge and all things appear "ONLINE", great.
Controlling things is also possible but unfortunately the status of things gets not updated. e.g. if I activate the scene "Away" all lights turn physically off, but unfortunately the status appears still as ONLINE in openHAB.
Thanks for your feedback. Was your dss autodiscovered with M5?
For me it seams that M5 is not working with my older dss firmware.
No, I needed to add it manually in PaperUI.
Hello.
I have updated to the M5 Snapshot.
Now my digitalStrom is online. Great. But i have to change from “dss.local.” to my IP-Adress of the DigitalStromServer.
With “dss.local.”
“Status: ONLINE - CONFIGURATION_PENDING Checking configuration…
HIDE PROPERTIES
serverCert”
Is this a bug or is it new?
From Browser dss.local. works fine.
Thanks for the Work.
I can confirm it’s working with 2.4.0.M5 and digitalstrom1.14.4.1 and with dss.local (changed the hostfile)
There is yet some strange behaviour:
server loses its connection after som time, only working again after emiting passsword and username again
Server was not autodiscovered. And no status update when turning of with manual switch.
Every month or so, the same ugly message… This is by far the most annoying binding, I must say that now. And even though I offered a bounty, nothing has improved. Does anyone have a fix for the time being?
This time it chokes here:
2019-01-07 15:45:22.160 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.IllegalArgumentException: illegal IPv4 address
at java.net.HostPortrange.<init>(HostPortrange.java:142) ~[?:?]
at java.net.URLPermission$Authority.<init>(URLPermission.java:486) ~[?:?]
at java.net.URLPermission.parseURI(URLPermission.java:454) ~[?:?]
at java.net.URLPermission.init(URLPermission.java:170) ~[?:?]
at java.net.URLPermission.<init>(URLPermission.java:166) ~[?:?]
at sun.net.www.protocol.http.HttpURLConnection.URLtoSocketPermission(HttpURLConnection.java:1084) ~[?:?]
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1034) ~[?:?]
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:177) ~[?:?]
at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:162) ~[?:?]
at org.eclipse.smarthome.binding.digitalstrom.internal.lib.serverconnection.impl.HttpTransportImpl.checkConnection(HttpTransportImpl.java:380) ~[?:?]
at org.eclipse.smarthome.binding.digitalstrom.internal.lib.serverconnection.impl.DsAPIImpl.checkConnection(DsAPIImpl.java:695) ~[?:?]
at org.eclipse.smarthome.binding.digitalstrom.internal.discovery.BridgeDiscoveryService$1.getThingUID(BridgeDiscoveryService.java:76) ~[?:?]
at org.eclipse.smarthome.binding.digitalstrom.internal.discovery.BridgeDiscoveryService$1.createResult(BridgeDiscoveryService.java:61) ~[?:?]
at org.eclipse.smarthome.binding.digitalstrom.internal.discovery.BridgeDiscoveryService$1.run(BridgeDiscoveryService.java:57) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
i just installed the new version yesterday and configured it, so far no problems yet… for me any new problems would be bad news, because digitalstrom is the core of my smart home. Maybe look at some professional software like IPSymcon?