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.
And of course any other idea is also welcome.