Awesome, I am glad we were able to achive some progress. Let me know if you bump into any issues.
Launching INDI-server and INDIhub agent from the INDI Web Manager - is better and easier. I will update manual on a web site with this flow.
Could you please share screenshot from KStars/Ekos INDI-panel? - I'd like to check if loaded devices match to the drivers indihub-agent read from indi-server (I have it from your other screenshots). Thank you.
Also, something according to screenshots - it is better to keep in secret public endpoints (host:port) when share-session is started (they are for you for your guests only). These endpoints have some protection from muss-use - they are randomly generated, assigned to IP from where 1st connection open, ephemeral and hard to guess but if someone knows it and session is still active, then it will be possible to connect remotely. I guess you don't want some stranger to open/close your dome
Another things to NOTE: video-streams from cameras are not supported by indihub-agent at the moment. I've done some work for this but it wasn't requested so it is still in a queue with low priority.
The terminal output with indihub-agent looks good to me. The client (KStars) closed connection so it closed it to indi-server appropriately. According to Ctrl+C - it is fine to use it stop indihub-agent, it should shutdown gracefully.
We just need to figure out why KStars crashes (the stack trace shows some pretty low-level QT/Cocoa stuff).
Two things to try:
- when you create profile in Ekos, try to skip all your equipment selection except some CCD (i.e. Altair) - it needs at least this one just to save profile. The equipment will be loaded dynamically - checkbox "Site info" makes it to do so. I've never tested case when this checkbox is on and also some equipment was selected. I am not sure but it might make it crash.
- my KStars (MacOS) installation is pretty old - Version 3.4.3. I will try to upgrade and replicate your situation
According to stellarmate - all you need to run stellarmate are indihub-agent connected to indiserver. (you don't need to run KStars on stellarmate).
On the local PC - you run KStars and create Ekos profile for remote connection (from my previous message).
So the connection schema looks like this:
KStars(local PC) <---> Intentet <---> indihub-agent(stellarmate) <---> indi-server (stelatmate) <---> equipment
Aha, looking at you terminal screenshot I see that share-session was started successfully.
Now, on your remote PC you would need to launch KStars/Ekos and create profile for your remote-connection - please see attachment with arrows where you need to enter information. The save this profile and try to connect. You should see all your equipment in Ekos controlled remotely.
That api-port=8787 is internal thing not needed by guest, sorry it is confusing (that port actually used to communicate with indihub-agent from INDI Web Manager if you decide to use it). All guest would need to know is INDI-server public host node-1.indihub.io and port 53362. Please note - this public host and port is alive as long as indihub-agent is running that session, if you stop and start indihub-agen in share-mode again then it will be other host and port.
Hope that helps!
According to guiding - I would try 1st KStars/Ekos internal guiding to have remote access working.
I've noticed on your screenshot PHD2 icon, indihub-agent actually can provide to PHD2 remote access as well, so guest can create remote profile in KStars/Ekos with PHD2 guiding.
Looks like the share-session started successfully (it showed "node-1.indihub.io:53023" public endpoint which can be used by guest in KStars/Ekos).
According to "API-server error: listen tcp :2020: bind: address already in use" error
- looks like agent was already running in a background or in other terminal? indihub-agent starts server on a port 2020 and that port was already taken.
Try command "ps -ef | grep indihub-agent" to see if it is already running (i.e. it could be launched from INDI Web Manager).
If you are sure that no other copy if indihub-agent is running that would mean some other program on stellarmate takes that port. Not a big deal though, you can use "-api-port=N" parameter where N is some other free port, i.e. 8787 or something.
Looks like the issue was solved!
The "share" mode is mostly to invite guests to use your equipment but you could use it remotely yourself if equipment is automated enough (dome and etc.)
Just to confirm your setup:
- I see you are running indihub-agent on stellarmate from command line
- you use INDI Web Manager and have it running on the same stellarmate
indihub-agent has special parameter "indi-server-manager" where you put host and port of INDI Web Manager. The default value for this parameter is "raspberrypi.local:8624" - that's why it is trying to connect there but looks like it is not the right host.
Can you try:
/home/stellarmate/Public/indihub-agnt-raspberrypi/indihub-agent -indi-profile=NMCosmos -indi-server-manager=localhost:8624
Please note: the default mode of the agent is "solo" (image contribution) which can be changed via command parameter to open access for sharing equipment, you can find more info about modes here github.com/indihub-space/agent#indihub-agent-modes
Yes, we do have all hosts in DB but we need a UI to present them in a usable way. Good timing, we are focusing to release Web UI in around 1st week of October! There will be directory of observatories where you can find and request share session.
Also, with that release we are going to introduce sign up and sign in asking hosts for email, after sign in you can add you equipment (if you have indihub-agent installed) and then you appear in the directory of observatories.
I spent most of the time this summer to make sure traffic can be processed with the minimum of computational resources. Unfortunately, had to stop the imaging processing pipeline process and development as it is getting too expensive, I will need to rethink and optimize it. So all integration with 3d parties is postponed (temporarily). The good news - share session traffic communication is very light wait and doesn't require any significant computational power.
I will post here when UI is ready to test.
p.s. meanwhile let me know if you want to be a guest to use my equipment - I will be glad to set it up and can message you connection string!