Deconz OFFLINE - COMMUNICATION_ERROR Auth failed OH2.5M1

Hi Marc,

Yesterday my connection to deCONZ crashed again with the binding version I pushed recently. I added another tweak for it.

The failing sensor status after a restart of the binding is probably caused by the same cause - a connection timeout. Currently I have the slight feeling that the deCONZ REST interface cannot handle all the requests which are triggered during restart at the same time if you have a lot of devices and some of them may fail. If they do the connection to the websocket for the sensor will not be established for future updates. I changed that too. The sensor will now wait a little bit and schedule a new initialization of itself.

Hmm, i did loads of Bundle restarts, just to test what is happening. the last few worked perfect and all sensors are online.
I had a crazy one in between though, not sure what to make of it…

2019-09-24 20:40:53.095 [hingStatusInfoChangedEvent] - 'deconz:deconz:7c4f7818' changed from OFFLINE (CONFIGURATION_PENDING): Requesting API Key to OFFLINE (COMMUNICATION_ERROR): org.eclipse.jetty.io.EofException

==> /var/log/openhab2/openhab.log <==

2019-09-24 20:40:53.093 [WARN ] [internal.handler.DeconzBridgeHandler] - Authorisation failed

java.util.concurrent.CompletionException: org.eclipse.jetty.io.EofException

	at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:292) ~[?:?]

	at java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:308) ~[?:?]

	at java.util.concurrent.CompletableFuture.uniAccept(CompletableFuture.java:647) ~[?:?]

	at java.util.concurrent.CompletableFuture.uniAcceptStage(CompletableFuture.java:669) ~[?:?]

	at java.util.concurrent.CompletableFuture.thenAccept(CompletableFuture.java:1997) ~[?:?]

	at org.openhab.binding.deconz.internal.handler.DeconzBridgeHandler.requestApiKey(DeconzBridgeHandler.java:239) ~[?:?]

	at org.openhab.binding.deconz.internal.handler.DeconzBridgeHandler.lambda$0(DeconzBridgeHandler.java:119) ~[?:?]

	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) [?:?]

Caused by: org.eclipse.jetty.io.EofException

	at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:286) ~[?:?]

	at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:393) ~[?:?]

	at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:277) ~[?:?]

	at org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:380) ~[?:?]

	at org.eclipse.jetty.client.http.HttpSenderOverHTTP$HeadersCallback.process(HttpSenderOverHTTP.java:268) ~[?:?]

	at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:241) ~[?:?]

	at org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:224) ~[?:?]

	at org.eclipse.jetty.client.http.HttpSenderOverHTTP.sendHeaders(HttpSenderOverHTTP.java:62) ~[?:?]

	at org.eclipse.jetty.client.HttpSender.send(HttpSender.java:212) ~[?:?]

	at org.eclipse.jetty.client.http.HttpChannelOverHTTP.send(HttpChannelOverHTTP.java:85) ~[?:?]

	at org.eclipse.jetty.client.HttpChannel.send(HttpChannel.java:128) ~[?:?]

	at org.eclipse.jetty.client.HttpConnection.send(HttpConnection.java:201) ~[?:?]

	at org.eclipse.jetty.client.http.HttpConnectionOverHTTP$Delegate.send(HttpConnectionOverHTTP.java:253) ~[?:?]

	at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.send(HttpConnectionOverHTTP.java:122) ~[?:?]

	at org.eclipse.jetty.client.http.HttpDestinationOverHTTP.send(HttpDestinationOverHTTP.java:38) ~[?:?]

	at org.eclipse.jetty.client.HttpDestination.process(HttpDestination.java:347) ~[?:?]

	at org.eclipse.jetty.client.HttpDestination.process(HttpDestination.java:305) ~[?:?]

	at org.eclipse.jetty.client.HttpDestination.send(HttpDestination.java:295) ~[?:?]

	at org.eclipse.jetty.client.HttpDestination.send(HttpDestination.java:270) ~[?:?]

	at org.eclipse.jetty.client.HttpDestination.send(HttpDestination.java:247) ~[?:?]

	at org.eclipse.jetty.client.HttpClient.send(HttpClient.java:578) ~[?:?]

	at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:727) ~[?:?]

	at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:719) ~[?:?]

	at org.openhab.binding.deconz.internal.netutils.AsyncHttpClient.doNetwork(AsyncHttpClient.java:107) ~[?:?]

	at org.openhab.binding.deconz.internal.netutils.AsyncHttpClient.post(AsyncHttpClient.java:53) ~[?:?]

	... 8 more

Caused by: java.nio.channels.ClosedByInterruptException

	at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202) ~[?:?]

	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:511) ~[?:?]

	at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:266) ~[?:?]

	at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:393) ~[?:?]

	at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:277) ~[?:?]

	at org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:380) ~[?:?]

	at org.eclipse.jetty.client.http.HttpSenderOverHTTP$HeadersCallback.process(HttpSenderOverHTTP.java:268) ~[?:?]

	at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:241) ~[?:?]

	at org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:224) ~[?:?]

	at org.eclipse.jetty.client.http.HttpSenderOverHTTP.sendHeaders(HttpSenderOverHTTP.java:62) ~[?:?]

	at org.eclipse.jetty.client.HttpSender.send(HttpSender.java:212) ~[?:?]

	at org.eclipse.jetty.client.http.HttpChannelOverHTTP.send(HttpChannelOverHTTP.java:85) ~[?:?]

	at org.eclipse.jetty.client.HttpChannel.send(HttpChannel.java:128) ~[?:?]

	at org.eclipse.jetty.client.HttpConnection.send(HttpConnection.java:201) ~[?:?]

	at org.eclipse.jetty.client.http.HttpConnectionOverHTTP$Delegate.send(HttpConnectionOverHTTP.java:253) ~[?:?]

	at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.send(HttpConnectionOverHTTP.java:122) ~[?:?]

	at org.eclipse.jetty.client.http.HttpDestinationOverHTTP.send(HttpDestinationOverHTTP.java:38) ~[?:?]

	at org.eclipse.jetty.client.HttpDestination.process(HttpDestination.java:347) ~[?:?]

	at org.eclipse.jetty.client.HttpDestination.process(HttpDestination.java:305) ~[?:?]

	at org.eclipse.jetty.client.HttpDestination.send(HttpDestination.java:295) ~[?:?]

	at org.eclipse.jetty.client.HttpDestination.send(HttpDestination.java:270) ~[?:?]

	at org.eclipse.jetty.client.HttpDestination.send(HttpDestination.java:247) ~[?:?]

	at org.eclipse.jetty.client.HttpClient.send(HttpClient.java:578) ~[?:?]

	at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:727) ~[?:?]

	at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:719) ~[?:?]

	at org.openhab.binding.deconz.internal.netutils.AsyncHttpClient.doNetwork(AsyncHttpClient.java:107) ~[?:?]

	at org.openhab.binding.deconz.internal.netutils.AsyncHttpClient.post(AsyncHttpClient.java:53) ~[?:?]

	... 8 more

2019-09-24 20:40:53.241 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler DeconzBridgeHandler tried updating the thing status although the handler was already disposed.

At the moment i can’t duplicate that error though…

I think we can safely ignore that one for now. The interesting question is how did your sensors behave after it? Were the ONLINE and working or OFFLINE and not working?

OK, after a lot of tests, when i restart the system and sometimes randomly my bridge goes offline. it was timeout 2000ms or some like that. once the bridge is online, all things go online and stay online, till now. maybe we can increase the timeout for the bridge authorization…

Ah crap, now i had single switches offline again, although the gate was online.

A short heads up: I am running my modified version for nearly ten days know without an issue. Everything is working nicely. I had a minor issue after installing the binding because my host parameter contained “:” which has to be replaced by “” only now.

I am going to add a second port parameter for the websocket too. Afterwards I am fine with getting it merged into OH snapshot.

Thanks for testing.

3 Likes

Hi guys,
I use Conbee 2 and I have paired success the Xiaomi sensors (motion, shock, multi, door, etc.) with Phoscon app, and I see these sensors in OH.
But I cannot add to the Phoscon app the Xiaomi smart wall plug. The Phoscon app see the smart wall plug as a lights (?) and so I cannot see any on/off channel in OH.
(The Xiaomi smart wall plug must be compatible with ConBee 2, according to the technical information of the Dresden Elektronik.)

Do you have any idea? Thank you in advance!

Hmm, i only have OSRAM smart plugs and also those from Innr… They are lights in the phoscon app as well. I implement them by setting them up in the hue bridge as a 0010 Item

 0010 	Light_OSRAM_Plug_2		"Hue - OSRAM Power Socket (2)"		@ "Hue"	[ lightId="15" ]

and then in items i can use it as a switch

Switch	Power_Socket_Dining_Cupboard		"Steckdose (Essen) |Schrank|"		<control_switch_m_4>	(G_Power_Sockets,G_Dining)		{channel="hue:0010:phoscongw:Light_OSRAM_Plug_2:switch"}

maybe those little code snipets help you setup your power plugs

HI @cweitkamp

I am running DeConz 2.5 and facing the issue

2019-12-27 23:02:59.509 [hingStatusInfoChangedEvent] - 'deconz:deconz:homeserver' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): java.util.concurrent.TimeoutException: Idle timeout expired: 300000/300000 ms

Is there a fix or what can I do to prevent this in the future?

Kindly,
Woogi

Are you using config files or paper ui? I had a few struggles but it was due to some minor config file changes. It was related to the op address and port.

Hi @Thedannymullen,

thank you for the fast reply. I use .things .items .rules file but no cfg file for this binding.

Bridge deconz:deconz:homeserver [ host="192.XXXX", apikey="XXXXX" ] 

Which ports do you mean?

Bridge deconz:deconz:homeserver [ host="192.168.1.20", httpPort=8090, apikey="FFBxsfj" ] 
{
switch              CassidyRemote     "Cassidy's On/Off Switch"          [ id="3" ]
}

Notice the Http port. By default deconz runs on 80 I believe so does openhab. I change mine to 8090, but you must specify, unless you use port 80.

Hi @Thedannymullen,

changed the port to 80, no result, issue did pop up again. How do I know the right port? Am not aware that I changed some standard port. I reach OH by 8080…

Openhab is on 8080 thats true. how do you get to phoscon? That is the port that matters.

look in /lib/systemd/system – cat the file : deconz.service you should see the port deconz runs on there looks like this:

ExecStart=/usr/bin/deCONZ -platform minimal --http-port=8090

That is the port for your things file. You also need to verify deconz is running properly. You can do this by going to Http://deconzip:port/api/apikey

replace the IP and Port with yours as well as the API key from your things file.
If you don’t get a response of lots of json then deconz is messed up.

Hi @Thedannymullen,

Deconz.service provides the following:

[Unit]
Description=deCONZ: ZigBee gateway -- REST API
Wants=deconz-init.service deconz-update.service

[Service]
User=1000
ExecStart=/usr/bin/deCONZ -platform minimal --http-port=80
Restart=on-failure
StartLimitInterval=60
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_KILL CAP_SYS_BOOT CAP_SYS_TIME

[Install]
WantedBy=multi-user.target

so port 80 should be correct.

Entering Http://deconzip:port/api/apikey I receive a lot of stuff :smiley:, so this should be fine as well…

{"config":{"UTC":"2019-12-29T08:17:44","apiversion":"1.16.0","backup":{"errorcode":0,"status":"idle"},"bridgeid":"00212EFFFF03B617","datastoreversion":"60","devicename":"ConBee","dhcp":true,"factorynew":false,"fwversion":"0x260b0500","gateway":"192.168.178.1","internetservices":{"remoteaccess":"disconnected"},"ipaddress":"192.168.178.36","linkbutton":false,"localtime":"2019-12-29T08:17:44","mac":"b8:27:eb:33:e9:13","modelid":"deCONZ","name":"Phoscon-GW","netmask":"255.255.255.0","networkopenduration":60,"panid":29318,"portalconnection":"disconnected","portalservices":false,"portalstate":{"communication":"disconnected","incoming":false,"outgoing":false,"signedon":false},"proxyaddress":"none","proxyport":0,"replacesbridgeid":null,"rfconnected":true,"starterkitid":"","swupdate":{"checkforupdate":false,"devicetypes":{"bridge":false,"lights":[],"sensors":[]},"notify":false,"text":"","updatestate":0,"url":""},"swupdate2":{"autoinstall":{"on":false,"updatetime":""},"bridge":{"lastinstall":"2019-06-......
1 Like

I had similar problems so while waiting for it to be fixed I designed a Node Red flow that works flawlessly. It also sends more information than the binding via MQTT. The message format that will be sent looks like

Deconz/motion/"+mac

Deconz/contact/"+mac

I have had this running for months now with 0 issues. Attached is the flow that can be imported into Node Red.

flows.json (14.7 KB)

1 Like

@Woogi yes you should work! I can’t explain them why openHAB does not connect. That would be a question for one of the developers as they have more knowledge of the code.

My last suggestion stop openHAB , clean cache and restart. Other than that I am out of suggestions.

@jcf6288 thanks! I am going to give it a try I wanted to try node red for the xiaomi cube

@Thedannymullen did the clean cache, problem ist still there, but less often :smiley:. I am not that familiar with Node Red @jcf6288. How can I set this up? Where do I have to put it in?

thank you so far.

Did today a reinstall of the binding. Until now, problem solved, no issues so far :call_me_hand: