carrascoacd
commented
3 years ago Thanks for your contribution @jaka87
I think this approach is less restrictive and will benefit some clients with a poor connection, but will prejudice others with better. Sometimes the commands take longer and never succeed due to "unexpected reasons" and retrying is the simpler and most effective approach, it does not prevent to have both types of clients working, though.
I think we can go with this then.
I will improve it if I detect problems by implementing an incremental backoff algorithm so the retries always increase the timeout, adapting the library automatically to the signal quaily.
I did a lot of testing these days. It turns out that in some cases connection is lagging quite a bit especially in bad weather. I initially tough that it may be so because of signal quality but it is not always the case. For example i had the station in my room with signal from 10-15 and it was working fine for many days, then i moved it outside where signal was around 20 but i got several errors and command had to be repeated... I tested in all sorts of weather snow,cold, fog, rain, you name it... I had to increase some of the timeouts by quite much but it's now working very well for me....
I was thinking what is the best solution for this? How far to increase the timeout, and how common are these interference in the network. Should we keep shorter timeout and just repeat if failed? Well in my case sometimes i coldn't receive data for several hours with shorter timeout. Then with increased id did work better but if command failed in some cases it had to be repeated for several times before it worked - meaning delay of several minutes. Therefore i rather put longer timeout. Few seconds more make all the difference (no repetition) and i dont see any drawback, since if the code is executed before timeout ends program will proceed further...