Autohome works well, I've had to use it a few times after I've messed up the mount state somehow (usually cutting power at wrong time). If the mount is pointing totally wrong way, I usually first manually run the scope roughly in the right position so that it doesn't hit the pier or anything while it finds the home sensors. As said I have the older EQ8, but as far as I know it should work the same with EQ8-R too if the mount code has been added so that the driver detects the capabilities correctly.
My older model only has USB in the handset so I need to still use the same RJ45 EQDir cable I used with HEQ5, but EQ8-R has additional USB-B in the mount as well and can be used directly with EQMod with just USB-A-B cable. Difference is that baud rate needs to be set to 115k instead of 9600 used with EQDir cable but otherwise it should work exactly the same.
You should always park the mount before turning off power and start from the same position when turning power back on, otherwise the model doesn't work. I used HEQ5 in remote observatory for a few years and usually only made a new alignment model if I had physically moved the mount and everything worked just fine.
I switched from HEQ5 to EQ8 (the older model) and at least there is was very much plug & play, nothing changed except additional capabilities like possibility to autohome (which is very useful in a remote observatory) and so on.
Not sure about best as I don't have experience with any other wheels, because my Starlight Xpress USB wheel has worked flawlessly and doesn't require any external binary blobs to compile as it's a simple HID device.
Stellarium has had support for INDI in the telescope control plugin for a while, I'm not 100% sure, but I think it's included in the Windows version too:
Thanks, that is useful information, I usually run Debug builds, have to try with Release too. The binary sizes are in line with what I have on x64 and ARM, release version does inline a lot more stuff (it uses -O3 optimization level by default) which causes the size to balloon quite a bit. Optimizing for size (CMAKE_BUILD_TYPE=MinSizeRel) might actually be better in that case.
Thank you, especially out.log looks interesting, everything seems to go normally, the dome connects and commands seem to get valid data, but then it just dies.
<message device="ScopeDome Dome" timestamp="2021-08-25T18:02:32" message="[DEBUG] read response: 8056"/>
2021-08-25T18:02:32: Driver ./indi_scopedome_dome: stderr EOF
<delProperty device="ScopeDome Dome"/>
2021-08-25T18:02:32: Client 0: queuing <delProperty device='ScopeDome Dome' name=''>
2021-08-25T18:02:32: Driver ./indi_scopedome_dome: restart #1
This shows the driver has crashed and indiserver restarts it.
2021-08-25T18:02:32: Driver ./indi_scopedome_dome: pid=6114 rfd=3 wfd=7 efd=8
2021-08-25T18:02:32: Client 0: sending msg copy 1 nq 9:
<message device="ScopeDome Dome" timestamp="2021-08-25T18:02:32" message="[INFO] Steps per revolution read as 8056"/>
If you can run the indiserver under gdb, that would show where the driver crashes and would help fix the issue.
The command line for gdb needs a few flags, something like: gdb --eval-command=set follow-fork-mode child --args indiserver -v ./indi_scopedome_dome
then type "run" and connect normally to indiserver and if/when the driver crashes, "where" would show the place and stack trace.
Hm, unfortunately the log doesn't quite tell me enough to pinpoint the issue, it seems to be sending dome steps per revolution calibration value to the client, but I can't think of a reason why the ISState would be invalid in that case. Enabling driver debug logging from Ekos might show a bit more, but I fear it would need a bit more debug prints or running under debugger to find the issue. Have you compiled the driver (and INDI) yourself or are you using PPA package?
Your EQMod driver has been built against newer base INDI library than what you have installed in the system. So either you can try to update them both or build from source yourself so that they match.
The libasi package also contains libraries for ZWO EAF focuser, EFW filter wheel and USB-ST4 interface in addition to the camera library and I've just increased the package version number every time one or more of them updates instead of using some magic number derived from four different version numbers . So it's purely coincidental that the numbers happen to be close, earlier ZWO used date based versioning but recently moved to similar increasing versioning.