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

Here is my log file.

Thank you, looks like indeed some checksum issue. However, the log does not show the response (my mistake). I've updated the driver to post the response before checking for the checksum. So the change is in GIT now and would be available in PPA tomorrow. At least we'll see the response and then find out why the checksum calculation is wrong.

If you know your way around GIT, you can test now and send the logs again.

I have now tried to update INDI with:and, but I am not sure if it worked, so here is my log file.

Hi there Antonio,
I'm also interested in your INDI driver for the roll off roof, using the Modbus protocol.

I have built, in my back yard, a roll off roof observatory, consisting of 2 rooms - the observatory room and a separated warmroom next to it.
The roof is driven by a TMT Automation Gate Opener and has 6 magnetic sensors to determine the position of the roof. Additionally, the observatory also has weather sensors (rain sensor, anemometer, thermometer, barometer and humidity sensor).
All the sensors and controls for the roof driver are wired in a control box in the warmroom. The observatory has wired ethernet network connections both in the warmroom and in the observatory room, all connected to the house LAN.

Presently, the roof driver and all the sensors are connected to an Arduino Mega microcontroller. The Arduino Mega is then connected to a Raspberry Pi via the Modbus protocol, using RS485 adapters (both Arduino and Raspberry are located in the control box in the warmroom).
I have written 2 INDI drivers (roof driver and weather driver) connected to the Raspberry Pi via ethernet. The Pi runs a small TCP server providing weather data, roof position information and takes roof open/close commands from the INDI drivers.

I am planning to change the configuration of the observatory by using 2 separate microcontrollers: one for roof control and one for weather data aquisition. I would like to connect the INDI drivers directly to the 2 microcontrollers via Modbus-ethernet, which I find rock-solid, thus bypassing the Raspberry Pi.