Telescope Control Plugin - INDI not available in Windows 64-bit Stellarium 24.4

[Malcolm Standring]

Hello,

I have been extensively using INDI to link to my ASIAir Plus (running HEQ5 Pro mount) from Windows, by (in ASIAir) enabling "EQMOD with SkySafari" (fires up local INDI server on ASIAir on port 7624), then setting up INDI in  Stellarium Telescope control on this port.

It has previously worked well for both tracking mount position and for GoTos.

I upgraded to 24.4 (64 bit) on Windows, and noted INDI option is now "missing", with release notes documenting "INDI support in Telescope Control plugin is optional now". It seems to be disabled in Windows build. Is this because of known issues, and is there any workaround e.g. downgrading to Stellarium 24.3? Happy to do a bit of experimenting if needed.

Lest this be viewed purely as a "gripe", let me say I am otherwise HIGHLY impressed with version 24.4, and it is a real tribute to all your hard work :).

[Georg Zotti]

It seems you are the first user ever to even report INDI usage on Windows... 

There are some software maintenance issues around INDI, but apparently no actual usage issues once building works, or else somebody would have called earlier. Given the role of INDI (described as doing roughly for Linux what ASCOM does for Windows), we had assumes it of less importance on Windows. (And yes, ASCOM also does not play nice with Qt6...)

Of course you can downgrade to 24.3 for now, which will not solve the problem though. In case you are able to use a compiler/building system, you could compile yourself and activate INDI, then try to build or make building successful, then report what has to be done on Windows. Is INDI something that has to be installed as Windows service like ASCOM, or are only headers missing to be included during building?

[Malcolm Standring]

Georg,

Enormous thanks for getting back so promptly, and thank you for your insights. Your response has made me question whether there may be a better way of achieving my "desired state" such as e.g. INDIGO. I will also take up your suggestions as well, given there are no known contraindications with an INDI client. In this case, it is ONLY an INDI client, not an INDI server that might be required for Windows. I have enough to go on for now, and wouldn't anticipate anything further needs looking at from a development perspective.

I have however put below some more detail on the use case for future consideration, and would be willing to be contacted to discuss further if appropriate. 

BACKGROUND:

(Note: I specifically refer to ZWO's ASIAIR telescope microcomputer, Linux-based, but much would be appropriate to other telescope microcomputers such as Astroberry - the majority seem to be Linux-based).

The ASIAIR includes its own "Star Atlas" and session planning tools, but compared to stand-alone applications such as Stellarium (other apps are available) these can be quite primitive, and many astrophotographers prefer to do session-planning in more fully-featured tools, uploading plans into the microcomputer. Originally this would have been simple textual CSV-like lists, but there has been a trend to try to get better integration. 

To this end, in the case of ASIAIR, ZWO added a telescope control "EQMOD with SkySafari", to allow SS users to control their telescope using the ASIAIR as a relay. I determined this appears to cause ASIAIR to run an INDI Server on e.g. port 7624. It was this I was connecting to from Stellarium using the INDI CLIENT in previous versions of Stellarium Telescope control. Both Cloudy Nights and StarGazers Lounge forums, for instance, contain a number of threads discussing trying to get Stellarium to play with the ASIAIR as an alternative to SS. I can confirm it is PURELY an INDI client (not server) required on Windows, so Telescope Control can talk to a relay microcomputer running Linux. 

That is the use case, so Stellarium e.g. on Windows can be used as a session planning tool backed by a linux-based telescope microcomputer. 

Using INDI is not necessarily the best way to achieve this, just that it has worked for me in the past. So I would say doing it through a Windows INDI client might not be the ultimate answer, but the use case I outline probably still exists. 

I confess, I do not understand what the current "External/Remote" option does, whether it can talk to a remote INDI server or not, but I'll probably try to experiment. Rather than a separate "INDI Client" option, would it for instance make sense to include INDI or INDIGO protocols within this option? I confess not yet knowing enough about this architecture, nor details of the various protocol options, but I'll do some more digging.

Finally, a big shout out for all the tireless effort you are all putting in to this product, it is something to be justly proud of!

Kind regards,

Malcolm Standring.

[Georg Zotti]

Connecting via INDI client protocol (just transmitting control signals) to the telescope is certainly better than connecting via Remote Desktop (permanent stream of graphics simulation screen output) to a small telescope computer running Stellarium with all its graphical bells and whistles. At least I just have not enough time to play with all this (too much time still goes into other parts of the program, which is so much more than just a telescope driver and observing planner...), but I think I can speak for the team and say thank you for your words of praise.  I hope the INDI and CMake experts will be able to re-enable Windows builds with INDI.

[Malcolm Standring]

Thanks Georg, I have down-graded to 24.3 (QT5 version, as occasionally I do use ASCOM), and last night's session the INDI telescope control worked flawlessly. 

Yes, Stellarium is far more than just telescope driver and observation planner as you say, as I am slowly discovering. It is testament that even on such a limited (and probably not primary) part of its functionality it positively shines.

 I will continue investigating better architectural options, and in the meantime I have a workaround I am delighted with.

A sincere thank you to yourself and the team.

Kind regards,

Malcolm Standring.