Good News:
I have it Running with the jar file. Problem was That californium was deinstalled when I deinstalled the Original 2.5.1 Shelly bundle. Installed the Tradfri bundle to get back californium and now the Shelly Snapshot Binding is running.
Bad News: Timeouts are still happening.
Sorry for typos. Had the wrong auto correction installed on iPad. Fixed now
Today I can do no more testing. Will followup tomorrow.
iff you are familiar with Wireshark it would be good if you let it run for a while and the trying to match the timestamp of the message with the section of the packet dump. One reasons could be a protocol issue. As I learned HttpUtil checks the header and explicitly waits for the number of bytes. Maybe there is an issue in the Shelly implementation causing this effect,
Good news: There is no single timeout message in the openHAB log any more. regardless how much and how quickly I switch the shelly 2.5 with firmware 1.5.9 - everything switches as quickly as the shelly can (in roller shutter mode).
The debug channels Timeouts and TimoutsRecovered are all the time during switching at zero ‘0’.
But I was not able to get Wireshark capturing the packets. I am not experienced in using Wireshark. In my setup I may would have to do more network re-config than I can/want to do to capture these packets. Therefore I would looking forward for someone else to do such captures.
@markus7017 would you be able to create me a private build of the binding that is similar stable to the release 2.5.1, but with the fix? Or could I use the current one until you have released an official fix in an upcoming openHAB release?
I did some testing with the DEV build in combination with the Shelly RGBW2.
I still can get the shelly to perform a reboot (to crash) if I do very quick changes in color, brightness, etc. The only difference I saw is that there is no more timeout log message (and password protected devices are not working, but I think you already mentioned that).
2020-01-24 13:51:42.423 [hingStatusInfoChangedEvent] - 'shelly:shellyrgbw2-color:fenster' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Es trat ein unerwartetes Problem beim API-Zugriff auf. Überprüfen Sie die Logdatei für genauere Informationen.
I thing the connect timeout is the phase while the device is rebooting. This usually takes between 5-15sec.
Do you see “xxx: Alarm condition: RESTARTED” in the log. You could also link the channel uptime. If the device restarts this values gets resetted and starts over (that is the condition checked by the binding).
Coap and mqtt are disabled. The only things I changed are the wifi settings, the NTP server and I set a login password. I don’t use the shelly app / shelly cloud.
Is Cloud enabled? Could you try to disable the Cloud function and repeat the test?
It seems that the device is not able to handle http requests (REST) while the device sends data to the cloud.
I uploaded a DEV buld to myfiles with increased timeouts (connect 30s, read 6s). @Nightman@Chris_si Could you please verify this build.
I will try this new build of the binding, but maybe not before weekend.
@markus7017
I have just done another test with the current (not updated) dev build of your binding.
Reproducable timeouts happen, if I use the Shelly 2.5 as it was configured from the binding (http:// entries in the Actions section of the Shelly enabled and set).
As soon as I disable all Actions in the Shelly (using the webinterface of the Shelly 2.5) I do not see any timeouts in the openHAB log any more, regardless how much and how quickly I switch.
My conclusion: Timeouts are happening due to the actions ‘callback’ of the Shelly (bug in binding or openHAB or openHAB-system OS?) or during the Shelly doing the actions ‘callback’ (bug in Shelly firmware?).