Thanks Alain for explaining how the bug is manifested/expressed.
Thanks Jasem for fixing it.
I hope that stable packages are built in the coming couple of weeks or so.
The "telescope connection disappearing" issue is in KStars, not INDI?
Yes, now that I tried a couple of times, the connection info is shown and can be changed.
I guess we need to report this to Jasem, so it is fixed before the next packages are built. Right?
Jasem merged the PR from James.
So I updated from Jasem's repo, then compiled it and testing now over WiFi.
There are no timeouts.
One very important and confusing change: there is no way to change the connection at all since all the fields are missing now.
Here is a screenshot to better show what the issue actually is.
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.
Yes, I am using ESP8266 Board Manager version 2.4.2, and it works.
Espressif, the company that makes the ESP8266 and ESP32, does not have a good track record for stability on newer versions. They always introduce problems. The classic case of good hardware but inferior software.
I think there are two separate things here:
1. Investigate what is different in SWS vs. USB (and even the older WiFi addon)
2. Proper device detection (rotator, focuser, and in the future thermometers, and other features), and not polling devices that are not there.
Task 1 is a technical development task to get to the bottom of why SWS delays responses. Howard gave some clue in the thread I linked to earlier.
Task 2 needs to eventually go into Jasem's repo, because it is the efficient way of doing things. Only 10% or 20% of OnStep users have a rotator, so why make INDI "too chatty" for something that is not there. The focusers are used more, but most users who have them has only one. So why poll the second one? And so on.
I am okay with delaying task 2 until you get to what the underlying issue for task 1. But task 2 must go in for efficiency's sake.
Thanks for digging into this. Yes, I suspected that delayed results going to the subsequent commands would crash (e.g. expecting a number on Cmd1, which times out, then Cmd3 gets it, and things go haywire.
So yes, buffer clearing is a good idea, but how long would one wait? SWS has a default of 200 ms timeout, plus the time a command takes on OnStep. It varies. Maybe 250 ms minimum timeout is safe? I don't know.
Yes, if you bypass the Wemos you will get different results. The thing is, the Wemos runs new software (SWS) which has some internal processing, and is a bit different from the addon. So what you are seeing is probably buried in SWS somewhere.
Regarding the rotator, are you testing with the conditional GX98 code? If not, then yes, the :r commands will take a long time and cause problems.
I don't have much to add here, so will wait until the experts finish their analysis.
In the meantime, should Alain push the small GX98 patch to Jasem, to prevent having others report the same issue?
My log verbosity is 'regular'.
The park function works normally initially (except for that jump that Alain reported. I see it too).
There is no crash (at least for a few minutes).
Then I unparked, then slew to the other side of the meridian. All normal.
Then issued a park command and waited for maybe 10 minutes and it did not happen.
Now that I try to remember, the crash happened the next day from trying to park. Maybe because the position was under the horizon (or so INDI thought it was).
Will leave it like that, and test tomorrow.
Sorry, nothing definitive here.
Not really 'at will'. It takes some 5 minutes or so after I park, and after the coordinates are different from what OnStep actually reports, then it crashes.
I will park and see if it happens again.
After I purged, I never parked. Just "return home", and everything was normal.
So my scenario is different that yours.
There is still a bug that happens after parking (wrong coordinates reported in KStars, but not in other client applications) and crashing.
I think the crashing is related to the wrong coordinates somehow.
The puzzle is what happens after parking that triggers all this. It is not parking itself, but something following or relating to it.
More iterations of testing with "return home" after Park data was purged, show everything working normally. No crashes.
So it has something to do with Parking, which is not part of my actual workflow since I don't have an observatory.
That last problem of wrong pointing, and probably the crash, has to do with parking.
I pressed "Purge data" from Site Management -> Park Options, slewed to Arcturus, then Altair, then told it Return Home, and all worked as it should.
So there is a separate issue that is related to parking.
Here is another puzzle.
After doing some testing, and then telling the mount to move back home, the crosshairs were wrong.
They were below the horizon towards the east.
Here is what INDI was showing just before it crashed.
At the same point, querying the mount from a python script showed the proper Alt and Az:
0.040 GR 11:13:36#
0.070 GD +90*00:00#
0.050 GZ 000*00:00#
0.049 GA +43*25:07#
So something in INDI is messed up.
Upon restarting KStars and INDI, the RA/DEC were correct and incrementing.
So something else is going on.