If the roof controller is a custom one,  you will have to write your own indi driver to manage it from ekos. As an alternative  I suggest to use the Dome scripting gateway driver that only requires custom scripts (in any language) as interface to the dome.

Sometime you'll have to restart all devices if needed. Have you considered power hubs like Pegasus upb, ip controlled plug (eg EZoutlet) or observatory controllers like Lunatico Dragonfly?

Thank you for the tip, I think I will use the Dome Scripting Gateway, the roof will be controlled by a Siemens LOGO, so I think it's easier to implement that with Python. For restarting the devices, the company Baader installed a remote Switching Device(www.gude.info/monitoring/remote-io/exper...-control-2302-1.html), but I haven't figured out how to use it with INDI, it has a HTTP Interface(wiki.gude.info/EPC_HTTP_Interface), so it probably could be done but I haven't figured out how yet.

I am wondering which is the recommended set-up:

Use INDI/kstars/ekos on your local computer <---indi--> remote computer <-> Observatory

or use VNC or similar:

VNC client <---- pictures of desktop --> remote computer (with indi locally) <-> Observatory?

I would say your first suggestion is better, If you install INDI Web Manager, you can start INDI without using things like VNC or SSH. You also can use the INDI Watchdog Device (www.indilib.org/aux/watchdog.html), which wouldn't be possible if you use VNC(It would be pssible but useless). So in my opinion, install INDI on the remote computer and connect to it from you local computer via Kstars/Ekos. That's at least what I think, if I'm wrong, please correct me.

in my experience it depends on network latency and bandwidth. If you separate the client from the server on different PCs, then all communication has to go through the network.
So, when guiding, all pulses travel back and forth and tracking could be affected by high latency; when focusing all images have to be send to the client consuming bandwidth etc.
If it's a LAN or a fast internet connection first option could work just fine.
In a remote location where only satellite network works the only way is connecting through a remote session on a local computer.
I switched from first option to the second when I moved my telescope from a 100Mb/s observatory to a remote one where connection speed (shared!) is 3Mb/s at best.
 

For an automatic observation (without a human intervention) I thing it's better to install Ekos int the remote site, since you eliminate one point of failure (internet connection). 
Also, this allows you to connect from different locations/computers without having to install/configure Ekos in many computers.

On the other hand, the indi webserver option provides more security if multiple users have access to the telescope, avoiding any uauthorized user mess up the remote computer.

Take a look to Indihub (indihub.space) , and may give a try to taste what indi webserver can deliver.

 

Hi Nicholas

A warm welcome to the INDI-Comunity from my side too!

I'm the responsible of the observatory of a grammar school in Switzerland about 15km from my home. Like you I wanted to be able to control all devices remotely trough the intra-/internet. I was using LINUX for more than 20 years and so I decided to deploy a LINUX-driven PC at the observatory. Four years ago I installed the KStars/EKOS/INDI-Combo and I never regretted it!

Perhaps the most interesting point for you is our twofold rolloff roof controlled by a Siemens LOGO for which I wrote a driver that works seamless with the INDILIB framework. Due to the lack of a good documentation I didn't yet publish it but the driver works very stable and reliable. It is using the 'modbus'-protocol to connect to the LOGO via 'ethernet' and control two relays (open roof / close roof) by internal flags. Additionally there are 4 switches checking the position of the two parts of the roof individually.

I think there should be no problem to adapt the driver for your needs. If you are interested I can push the programming code to my repository on GITHUB so you can check it.

   

By the way: We are using 'indi-web' to connect a KStars/EKOS-Client to the INDI-Server working on a NUC in the observatory. (The NUC and all the devices are always powered on.) This works outstanding well! There is only one drawback, when I'm working over the internet: If the connection is slow the internal guiding failes because there are time lags for the correcting pulses. Using the PHD2-server on the NUC however solves this problem. It would be nice if we had some sort of an "internal guiding server" in INDILIB communicating with an corresponding EKOS-client similar to PHD2.

Antonio

Hello Antonio,
Thank you very much for your response. I would really appreciate it if you could push the code to a Github Repository, that would be great. And also thanks for the tipp with the PHD2-Server, that could be really useful.

I have left a message for you in the chat.

I have just installed INDI and wanted to connect to the devices, but I'm not able to connect to the Planewave EFA and the Planewave Delta-T Heater. I always get the error "Invalid Checksum". Could anyone help me?

I have also checked with the Planewave Software that Heater and Focusser are working, so the problem is on the INDI/Linux Side

Please turn on the logging (INDI + Focuser + Auxiliary) and then share the logs: indilib.org/individuals/logs-howto.html