×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

scheduler: remote starup/shutdown script

  • Posts: 2255
  • Thank you received: 223
I'm not sure if this is available or not, if not then here's what I believe would be a good thing.
The ability to run a remote startup/shutdown script.

In the scheduler, the path to the script should have the option of: remote / local
and if remote is selected, have a new box appear to enter and store the ssh key.
5 years 8 months ago #27915

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

  • Posts: 1029
  • Thank you received: 301
I think this was discussed in the past. Basically, the method is to ssh to the remote and execute commands from the shutdown script. General agreement is that this is not user-friendly and too techie. Thus the best we can do for now is to install a default script that is ineffective but documents how to do various things. Did not touch that yet, so if anyone is willing to start, welcome.

-Eric
5 years 8 months ago #27957

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

  • Posts: 2255
  • Thank you received: 223
ah ok, so what I could do instead is write a simple client side script to ssh to the remote server and execute a remote script then?
5 years 8 months ago #27963

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

  • Posts: 1029
  • Thank you received: 301
That's really all there is to it, yes.

-Eric
5 years 8 months ago #27965

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

  • Posts: 2255
  • Thank you received: 223
I still think this would be a nice feature to have.
5 years 8 months ago #27967

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

That's what I use in my script. It SSHes to execute remote commands. Never had issues.
5 years 8 months ago #27998

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

  • Posts: 1029
  • Thank you received: 301
General question is whether a script that manipulates remote stuff should be located locally. If we consider a private single-user setup, restriction is weak. If we consider a public multi-user setup, then it makes sense to store the script on the remote, and enforce its execution when a client disconnects.

We have two issues here. First when we shutdown the observatory, the client executes a local script with commands for the remote (granted, this can be a set of commands in a remote script). Second, with ssh we are using a parallel method to the INDI protocol, that needs arguably user-friendly configuration.

Weighting those, the answer could be to add a checkbox "Shutdown remote with watchdog", and leave the script box primarily intended for local activities. The watchdog could execute the same script when called voluntarily and when triggering on inactivity. We'd keep the ssh solution at hand, and add a cleaner feature for end-users.

What do you think?

-Eric
5 years 8 months ago #28003

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

That's quite a smart way to do it! Use the remote watchdog driver to execute the shutdown script. If this can be added without complicating the scheduler GUI then it's great.
5 years 8 months ago #28004

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

  • Posts: 1029
  • Thank you received: 301
Also the INDI watchdog driver should only become IDLE when the client explicitly says so, or when the shutdown procedure is done. Right now it is also switching to IDLE when the client disconnects, this is probably incorrect.

-Eric
5 years 8 months ago #28008

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

  • Posts: 2255
  • Thank you received: 223

Would you be willing to share your startup script please so that I can understand how you wrote it.
5 years 8 months ago #28319

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

There is really nothing special. You just need something like this (eg on my observatory):
ssh -t ikaruspi.local 'indiserver -v indi_simulator_ccd'

So it's ssh -t host command
Last edit: 5 years 8 months ago by Jasem Mutlaq.
5 years 8 months ago #28359

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

  • Posts: 2255
  • Thank you received: 223
My script, work in progress...
root@heidenrod-obs:/home/scheduler# more obs_up.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
 
import os
import time
import sys
import pykush
import wiringpi
 
wiringpi.wiringPiSetup()
#set ROOF pin 0 - 1 to OUT
##wiringpi.pinMode(0, 1)
##wiringpi.pinMode(1, 1)
#set EQ5 pin 2 to OUT
wiringpi.pinMode(2, 1)
#set Atik314 pin 3 to OUT
wiringpi.pinMode(3, 1)
 
 
def rain_check():
        print "Checking for rain"
        io = wiringpi.GPIO(wiringpi.GPIO.WPI_MODE_PINS)
        rain_check = io.digitalRead(6)
        if rain_check is 0:
                ykushon("YKC4434")
		time.sleep(2)
                ykushon("YKC4445")
		time.sleep(2)
		eq5()
		time.sleep(1)
		Atik314()
                exit(0)
        else:
                print 'Raining'
        exit(1)
 
def ykushon(serial_number):
        yk = pykush.YKUSH(serial=serial_number)
        yk.set_allports_state_up()
 
def eq5():
	eq5 = wiringpi.GPIO(wiringpi.GPIO.WPI_MODE_PINS)
	eq5.digitalWrite(2,0)
 
def Atik314():
        atik314 = wiringpi.GPIO(wiringpi.GPIO.WPI_MODE_PINS)
        atik314.digitalWrite(3,0)
 
rain_check()
root@heidenrod-obs:/home/scheduler#

It does check the rain sensor first, if it's wet then nothing happens (ie: nothing gets started), if it's dry then it start the two ykush boards, then turn on the mount and CCD power.


tested, so far so good...
Last edit: 5 years 8 months ago by Gonzothegreat.
5 years 8 months ago #28486

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

Time to create page: 0.608 seconds