You may could help to narrow down the timeout problem and try to find some reproducible indicators due to the fact that more users have this problem. Lets try to find a pattern, which gives an indication where to locate the problem.
I’m using a OH framework build-in class (HttpUtil) to implement the http calls, so I won’t expect an issue there, because other bindings use the same cass
Im my setup this problem occurs very rarely (1 time since 2 weeks), that makes it hard to diagnose/debug it
From what I know it’s not related to the OH version (2.4, 2.5), device type or firmware version, runtime environment, but who knows without having a statistic
A good next step would be to create a matrix to find a pattern. If you want to help I need the following information
OH version (2.4, 2.5M3…M6, 2.5.0, 2.5.1-SNAPSHOT etc.)
Runtime environment (RPI with Debian Strech, openHABIAN, macOS, Windows x.y, Synology etc.)
Device type (Shelly 2.5, Flood…) and firmware version and number of devices on the network
WiFi signal strength
How was the thing added (Auto-Discovery, Manually in PaperUI, .things definition)
Where you see timeouts (discovery, commands, status polls)?
Do you have enabled MQQT and/or Coap on the Shelly device?
Do you have enabled CoIoT events in the thing configuration?
What has already been verified?
You should also link the channels signalStrength, timeoutErrors and timeoutsRevoered. This will provide some statistical information.
In parallel I’m in contact with the Shelly developers to evaluate a potential issue on the device side. As I learned http REST calls are more resource consuming on the device side and could also cause synchronization issues if the device has to handle multiple requests at the same time (which should not be the case when only using the binding).
Please also check to upgrade to firmware 1.5.7 (latest release), this eliminates the factor firmware version from the equation.
Maybe just quote the list above in your answer and fill in the information you could provide.
This is a special buld, don’t use it when you not want to test the timeout issue!
Please note: It’s a 2.5.1-SNAPSHOT build, if you are still using the 2.5.0-SNAPSHOT jar delete this from the addons folder before copying the 2.5.1-SNAPSHOT into it
@javaboon Could you please provide the output of /settings and /status for the Door Sensor so I could started integrating those devices. I need /status when window is open and closed.
@Matt4 Did you verified the DEV build? This should work now (new option in thing config)
@Polo or @Tomibeck I started working on this. It’s included in the DEV build, waiting on feedback.
I have just started testing with shelly and am facing the timeouts and can somewhat reproduce them. Can I use the special build of the binding on normal 2.5.1 OH system? If so, how? And how can I revert back to the original 2.5.1 shelly binding after tests?
I do not want to go on an OH snapshot.
(sorry, I am not so experienced with the OH dev and snapshot builds)
yes, the DEV builds are fully compatible to the OH release build, but you can’t install it with PaperUI, you need to deinstall the version included with the 2.5.0 or 2.5.1 release. The READMEbeta describes the installation - no magic if you follow the steps. You’ll find all files in my myfiles repo.
I’m hight interested in the result to
a) confirm that this approach solves it and work on some details (error handling) or
b) it doesn’t work and I revert the code change
You have to uninstall the binding using the addons menu and after that you can copy the special build (the jar file) into the addons folder.
I also do have some timeouts from time to time (openHAB 2.5.0 on Synology NAS with Shelly binding 2.5.0, Shelly 1 with password protection). Then I have to go into edit mode on the Shelly binding and just save it without any changes. Doing so my Shelly 1 gets back online immediately. Furthermore I noticed that this procedure do also recheck for new firmware (today 1.5.8 was released].
In fact this forces a thing re-initialization (with a good chance to succeed), but I won’t expect this to be a permanent solution. As I said some users (like me) see those problem very rase, others very often and 1 user is even not able to discover the device.
The DEV build uses nativ Java support rather than the OH build-in HttpUtil class. The change should be transparent, so I expect no function difference, but want to see if this eliminates the timeouts (I’m expecting this).
Please do not use this build if you want to discover password protected devices. That’s one of the details, which is missing in this build - proper handling of error codes, e.g. 403 unauthorized, which then activates the special discovery until you set the credentials in the thing config. Once the device gets ONLINE after the discovery it should work also with this build.
You need also to install the Californium libs - see the READMEbeta
Thans for the heads-up. I added this hint to the READMEbeta
I am really sorry, but I fear to de-stabilize my production openHAB system when following the READMEbeta instructions. AS openHAB is used in my home for multiple things, I do not want to test this in my production environment. I do not have a test environment. As soon as the binding is released or runnable in the unchanged openHAB 2.5 I will update and test.
As said, I am really sorry and hope that someone else may help.
I may be able to test, if the dev-binding would support gson 2.8.2.v20180104-1110 (I have installed this in my current openHAB system) - I also have californium 2.0.0 installed.
Does it support gson 2.8.2.v20180104-1110 (READMEbeta says it needs 2.8.5)
And: Could I leave my Shelly Thing and Items as they are? (or do I really need to clear the database cache etc.?)
I really want to help, but want to not de-stabilize my openHAB.
The binding has no specific dependency on 2.8.5, but I suppose the 2.5 DEV environment defines this.
openhab-cli and cleaning the JSON DB ist nit a must, more to be on the safe side. Usually I don‘t do this either, but just copy the jar in the addons folder. However, esp. when switching the 2.5 release version (which goes into the cache and SHOULD be deleted when uninstalled) to the DEV version in the addons folder there might be a left over.
Deleting the thing is usually uncritical. OH still keeps the channel/item linkage incl channrl names and restores them once the thing is re-added. If you do not delete the thing it will work, but you can‘t access the new channels timeoutErrors and timeoutsRecovered, which are helpful for analysis.
It will help if you do this test, but I also understand that you are afraid of issues. I don‘t expect them, but can‘t commit to it.
Deinstalled original Shelly binding, stoped openhab service, copied Snapshot binding jar file is in addons folder, restarted openhab service, but not active and not visible in PaperUI and therefore cannot search for thing.Even after Linux reboot the binding is not active.
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?
