For reference as well: My esp8266 is at 2.7.1 and I haven't noticed esp8266 problems with it for OnStep or other projects. I think that's what all mine were built with. (That version is because I haven't bothered to upgrade or downgrade when I last installed it.)
Though I mostly haven't tested with a rotator, except simulated via USB.
Sorry I have some translation problems.
After 10 minutes of reading and google translation ending in total nonsense.
I more or less understand the rest but when it comes to "bail out" I have not idea what it could mean.
Any other wording for that?
To best explain my use of it, would be to return, escape, abort or stop (almost always early/generally before it's done/prematurely)
I'll note to try to avoid it in the future, because searching google I can understand your confusion! Several I didn't even think of, as a native speaker. Hopefully my explanation being a bit verbose above didn't confuse you or anyone else.
So in multiple day+ long tests, I see plenty of network timeouts, but 0 crashes, even while accessing it with multiple things. About 6-ish per hour at 2 second timeouts on my network.
I did go ahead and change to LOG_WARN and to return true to ReadScopeStatus. (Focusers/Rotators and such are still LOG_ERROR) so the scope doesn't go into error status.
Unless anyone sees a problem I'll see about a PR to main tonight.
NOTE: The logs will have a combination of INFO/WARN/ERROR. I mostly kept the wording the same, but I'm not sure I like it: This update aborted, will retry... (Kept the same for easy find/replace.)
Mount will not change state due to the LOG_ERRORs. (To prevent stopping captures, sequeneces, etc.)
Mount will not disconnect.
TODO (related or discovered due to this):
Convert the Focusers & such that are in functions other than ReadScopeStatus to others.
One issue is that the scope doesn't register as disconnect when on the network, I believe this is the case with the existing network code as well. (But you were more likely to have a crash than notice that.)
LX200 adjustable timeout. This is a bit trickier than I thought needing to touch a lot more things, so I'm going to make it separately. (This is IMO better than just OnStep, and will get all the LX200 functions we use, plus it should benefit anyone using a network adapter for an lx200, TeenAstro or others.)
Alain's investigations into the rotator differences on SWS vs direct.
Park: I'm not sure I'm understanding the process right (I don't use it normally), but when I set a position it's now slewing to it.
Question: Should I raise the network timeout from 2 sec to 3 sec or higher?
I see little reason to not keep the serial at 0.1 sec, I don't see errors with it, even on the slowest platform we have. There is one edge case: serial to wifi or bluetooth to serial might be slower, but only if it's setup as a serial port, as opposed to accessing the serial port over a network. I don't have a bluetooth serial module to test right now. (and I've had horrible luck with them.) That should be resolved with the adjustable timeout patch later on.
Thanks for looking into this in more detail, and finally solving the crashes.
Just to be clear, does the PR include only the different timeouts for network vs. serial?
Or does it also include checking the presence of the devices we know will cause timeouts if they a not there (specifically the return of :FA (focuser1), :fA (focuser2), and :GX98 (rotator)?
If the PR does not include those, then I really think these should be included.
I am testing your latest PR and so far do not notice any issue.
I am running it on two OnStep configuration:
- Without any Focuser / Rotator
- With a Focuser
Even the strange jump when Parking / Unparking is not there anymore.
I will leave those running some time but it looks like you fixed it.
The PR included that difference in timeouts, as well as a bunch of verification so that if there's a timeout it will warn, and abort the update.
It will probe and detect focusers and rotators, as has always been done. (Which on serial should amount to the 0.1 sec timeout, or 2 sec on network.) So yes, those will cause timeouts on startup.
I did add a little gating based on version to something with rotators. Up to V3 lacks the commands. rI rM rT and has no equivilent (at least in the current version and prior versions I looked at.) That and checking for OnStepX focusers (when version is OnStepX or unknown) are the only gating like that. As for the most part the commands are pretty consistent across versions.