Are the retries necessary?

[rosswarren]

I added automatic retries because I get intermittent failures when communicating with my charge controller via my Raspberry PI Zero. I am not sure if these failures are expected or if it is a specific issue with my setup.

[hrford]

I have a RPi 1B (From 2012) which I could coax out of retirement?

[na7q]

Retrying is an absolute MUST. I on some occasions would get failures, for whatever reason with my very simple setups. On Pi's or other mini computers.
My more advanced setups, multiple devices are accessing the server via SSH to the server device that is connected to the controller. Retrying allows it work without issue. Never once had a problem since switching to this code that retries.

[hrford]

I feel that unbounded retries can cover up underlying issues.

In python, errors should be handled by exception and retry carried out only if necessary, not by default.

If the resource (device) is contended, of course retries would appear to make the problem "go away", but why is the resource contended in the first place?

In the example given by @na7q , they talk about multiple clients SSHing onto a host and (I assume) then trying to run the same code to access the device creating contention.

Using retries in this situation could lead to undeterministic results due to the ordering of commands so I feel should be avoided.

In this case, I think the actual fix is to write an aggregator and queue the commands avoiding retries entirely.

[na7q]

Part of my issue is running different software to pull data from the controller for different tasks. Since they are done at different intervals which eventually cross paths timewise, a simple retry like in this code was the perfect method. Before finding this repo, I consistently had missing data here and there. Even when I tried running my code manually. Using an exception and retry was more complicated and only presented more issues because some of us aren't fluid in python.
This repo resolved everything by 100% thanks to the reasonable usage of retries.

With the software I use (ham radio related) there is no reasonable or easy way to que anything to avoid the timing problems. Not everyone has the know how to extensively modify code either. I certainly don't. I make things work, not always pretty. I'm thankful for this code and the retries. It's well written and easy to modify to my needs anyway. I hope it stays the way it is.