×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

What is the point of Device manager in Kstars

  • Posts: 268
  • Thank you received: 72
Hi

I use the Device Manager heavily when developping! With this manager I'm able to connect directly a running INDI-server through the "client"-tab.

But, I realized a flaw in the list of drivers: New versions are not reflected! I found the file "indidrivers.xml", but changing the content seems not to change the displayed information. So my question is, how the manager is fetching the information of the actual drivers?

Thanks for enlightment
Antonio
Last edit: 4 years 3 months ago by Toni Schriber.
4 years 3 months ago #46440

Please Log in or Create an account to join the conversation.

  • Posts: 983
  • Thank you received: 375
It's looking for separate .xml files for non-core drivers in /usr/share/indi
4 years 3 months ago #46446

Please Log in or Create an account to join the conversation.

  • Posts: 268
  • Thank you received: 72
So "indidrivers.xml" under "/usr/share/kstars" is obsolet? Why the file keeps beeing updated?

Follwing your statement I examined the XML-Files in "/usr/share/indi". It's strange: They are all updated with the correct version numbers, but the INDI control panel keeps on displaying the old numbers! For the moment i cannot analyze the source code, so I'm wondering what's going on.

Thanks for further enlightenment!
4 years 3 months ago #46508

Please Log in or Create an account to join the conversation.

  • Posts: 983
  • Thank you received: 375
I know that /usr/share/indi/ is populated with:
- drivers.xml which contains core indi drivers (installed with indi-bin), and
- separate .xml file for each of 3rdparty drivers (each installed separately)

I'm not sure about /usr/share/kstars/indidrivers.xml - maybe Jasem aka @knro will be able to comment on that.
The following user(s) said Thank You: Craig
Last edit: 4 years 3 months ago by Radek Kaczorek.
4 years 3 months ago #46528

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
indidrivers.xml is certainly not obsolete. It is a very important file. This file is how KStars can list drivers for remote INDI Servers in the INDI profile and connect to them, even though your current computer doesn't have those drivers installed. If KStars does not have that file, then the drivers listed under "remote" would only include the drivers which are actually installed on the computer you are currently using. For an example, let's say you have a raspberry Pi and it has an SBIG driver on it. You are accessing it from your laptop that doesn't have 3rd party drivers installed. So that means that it can't see the xml file for SBIG since it isn't on the computer. So when you select "Remote" in the INDI profile, you can't select an SBIG camera in the profile to start it up, since it isn't in the list.

There are some drivers that can't be installed on some systems and not on others because the don't compile or work on that system. This file makes it possible to use those drivers remotely.

The file should not prevent other XML files from being loaded, so if you have custom drivers or 3rd party drivers that aren't from the 3rd party Repo. But it should make it possible to load drivers that aren't on your system so you can run them remotely.
The following user(s) said Thank You: Radek Kaczorek, Craig
4 years 3 months ago #46529

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226
Thank you Rob. I found that information worth investigating for myself. As I have not done much with the remote features to date. Now, I found I can indeed connect to a remote profile running drivers that are not installed locally. However the local server has a bad habit of overwriting the remote profile's driver list if it is started locally, and not from within the remote web manager that is fully aware of the available remote drivers.
In other words, I find I must have the INDI server start via the Web Manager and connect to the already running server from the local machine, otherwise only locally available drivers are started, and the profile itself is overwritten without the remote drivers.

Is this typical behaviour? This doesn't seem to be optimized to me. I shouldn't have to redo the profile whenever I accidentally attempt to connect to a remote server with more available drivers that was not already started in advance.
4 years 3 months ago #46569

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
Ok, there is probably room for improvement. This was Jasem's solution to the problem 2 years ago when I told him about the issue with remote drivers not showing up because they had no xml file on the local system. There may be better ways to fix it or it could probably be improved upon. I can let him know there is an issue with overwriting drivers.
4 years 3 months ago #46575

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226
Sounds good. Perhaps when a remote profile is selected in EKOS, the start button should command the server to start, rather than start the local version of the profile.
Which is another oddity IMHO, why is it necessary to populate drivers locally for a remotely configured profile at all? I found I can leave everything blank, other than the 'mandatory' CCD driver. The remote server just ignores it and connect the remote drivers that are started in advance. Surely a matching a profile name is sufficient to select what profile to start on the web manager server.
Local EKOS with it's limited driver list could probably do away with any local configuration power over the web manager's profiles. There by only supporting configuring from within the web manager with all available drivers and eliminate any confusion.
4 years 3 months ago #46577

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
So you are correct if you are connecting to an already running INDI server on the remote device. If you connect to that running INDI Server, KStars will get the information about the running drivers not whatever ones you select in the profile on the local machine.

But, if you connect using Ekos and tell it to use the INDI Web Manager, you can configure everything from within Ekos. You can set up your profile exactly the way you want to on your local machine, and then when you tell it to start, the Web Manager on the remote machine will update your profile on that remote machine to reflect the profile you selected. If the profile doesn't exist on the remote machine, it will be created. Then the selected and updated profile on the remote machine will be used to start the INDI server.

So it is very important actually. And it is a much simpler way to work with the web Manager.
4 years 3 months ago #46583

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226
Ok. But the problem is not all the drivers are necessarily available on the local system when creating a remote profile.
For the record I was experimenting with KStars on Windows.
4 years 3 months ago #46584

Please Log in or Create an account to join the conversation.

Currently KStars does not load profiles from a remote Web Manager server. Implementing this shouldn't be too difficult, but it just needs time.

Right now, if you create a remote profile and no local version is available, this is where the drivers in indidrivers.xml are used. This was proposed by Robert a couple of years ago and appears to be working well for most people. If it is not there, you can simply put the device label as well.

Device manager is no longer used, but is kept for testing purposes for when you need to connect to INDI without Ekos.
4 years 3 months ago #46654

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226
I just tried out a couple things and have found a reasonable work around for creating a profile with a non-local INDI driver that does not require the remote server to be run in advance.
It turns out manually filling in the name of the driver will do the trick, even if the local machine is not able to list it.

Incidentally I also attempted to describe a remote driver with driver1@remotehost:port first, but it was not effective.
4 years 3 months ago #46844

Please Log in or Create an account to join the conversation.

Time to create page: 0.366 seconds