×

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

Bi-monthly release with minor bug fixes and improvements

Read More...

Full Automation and Weather handling in the Scheduler

  • Posts: 85
  • Thank you received: 40

Replied by Hans on topic Full Automation and Weather handling in the Scheduler

This is fixed now. (I forgot that you cannot ask INDI if a mount *is* parked, you have to look at things like park coordinates and tracking)

This is added.


I've also made all functions available from the command line for individual testing, and added cap support. This is the documentation so far :
./ekos_sentinel.py --help
usage: ekos_sentinel.py [-h] --indi_host INDI_HOST
                        [--indi_command_retries INDI_COMMAND_RETRIES]
                        [--debug] [--once] [--get_weather_safety]
                        [--get_mount_safety] [--get_cap_safety]
                        [--get_roof_safety] [--park_mount] [--close_cap]
                        [--close_roof] [--warm_camera]
 
EKOS Sentinel, version 1.0 .
EKOS scheduler in Kstars 3.2.0 waits for good weather before opening the observatory,
but does not close down when weather gets bad. That's where this script aims to help.
 
loop:
    weather safe ?
    yes:
        scheduler running ?
        yes:
            ok
        no:
            start scheduler
    no:
        scheduler running ?
        yes:
            stop scheduler
            park mount
            close cap
            close roof
            warm ccd
        no:
            ok
 
Instead of 'scheduler running ?' we have to use 'roof closed ?' for now.
Modify the static config in this script for your setup.
 
optional arguments:
  -h, --help            show this help message and exit
  --indi_host INDI_HOST
                        INDI server address
  --indi_command_retries INDI_COMMAND_RETRIES
                        try INDI commands this amount of times before giving
                        up, defaults to 1
  --debug               enable debug level verbosity
  --once                run only once, useful for debugging
  --get_weather_safety  for testing: only call get_weather_safety
  --get_mount_safety    for testing: only call get_mount_safety
  --get_cap_safety      for testing: only call get_cap_safety
  --get_roof_safety     for testing: only call get_roof_safety
  --park_mount          for testing: only call park_mount
  --close_cap           for testing: only call close_cap
  --close_roof          for testing: only call close_roof
  --warm_camera         for testing: only call warm_camera
 
Only --indi-host is required for normal operation, the rest is for debugging and testing

-- Hans
The following user(s) said Thank You: Derek, Ferrante Enriques
4 years 11 months ago #38799

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

  • Posts: 456
  • Thank you received: 76

Replied by Derek on topic Full Automation and Weather handling in the Scheduler

Hans,
Thank you!! Just looking at your ekos_sentinel script and the EkosDbus. This looks really good!!
Derek
4 years 11 months ago #38800

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

  • Posts: 249
  • Thank you received: 62

Replied by Ferrante Enriques on topic Full Automation and Weather handling in the Scheduler

Thanks Hans! Impressive evolution is such short time.
4 years 11 months ago #38802

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

  • Posts: 249
  • Thank you received: 62

Replied by Ferrante Enriques on topic Full Automation and Weather handling in the Scheduler

hi Hans,
i'm struggling to adapt your script to my setup, it's not as simple as adapting the initial configuration.
You are using Weather Meta, that driver is not extending the Weather base class. So there's not the standard INDI weather property available (that should be WEATHER_STATUS). This property should then have a State (I mean IPState) related to the weather condition.
I didn't succeeded yet replacing the Meta 'station_indexes' in your script with the standard WEATHER STATUS property.
Ferrante
4 years 11 months ago #38883

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

  • Posts: 85
  • Thank you received: 40

Replied by Hans on topic Full Automation and Weather handling in the Scheduler

I'll try to help.

Right, INDI Weather Meta Driver watches up to 4 weather drivers and report worst case of each in a single property.

I don't think that's how it works. I see for instance this :
indi_getprop | sort -u | grep WEATHER_STATUS
 
OpenWeatherMap.WEATHER_STATUS.WEATHER_FORECAST=Alert
OpenWeatherMap.WEATHER_STATUS.WEATHER_RAIN_HOUR=Alert
OpenWeatherMap.WEATHER_STATUS.WEATHER_SNOW_HOUR=Ok
OpenWeatherMap.WEATHER_STATUS.WEATHER_TEMPERATURE=Ok
OpenWeatherMap.WEATHER_STATUS.WEATHER_WIND_SPEED=Ok
 
Weather Meta.WEATHER_STATUS.STATION_STATUS_1=Alert
Weather Meta.WEATHER_STATUS.STATION_STATUS_2=Ok
Weather Meta.WEATHER_STATUS.STATION_STATUS_3=Idle
Weather Meta.WEATHER_STATUS.STATION_STATUS_4=Idle
 
Weather Safety Proxy.WEATHER_STATUS.WEATHER_SAFETY=Alert
So OpenWeatherMap which does <em>OpenWeatherMap : public INDI::Weather</em> also does not have a single WEATHER_STATUS property but has 5 sub properties.
Weather Meta has 4 of those, and Weather Safety Proxy has 1.

Can you show which exact property you're targetting ?


What I found is that no weather driver sets WEATHER_STATUS directly. They all use min and max parameters :
libindi/libs/indibase/indiweatherinterface.cpp:208
void WeatherInterface::syncCriticalParameters()
sets critialParametersL[i].s = IPS_ALERT;
if ((ParametersN[j].value < ParametersN[j].min) || (ParametersN[j].value > ParametersN[j].max))


ps. Have you tried adding weather meta and letting your weather driver report in there ?

-- Hans
Last edit: 4 years 11 months ago by Hans. Reason: fix
4 years 11 months ago #38894

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

  • Posts: 249
  • Thank you received: 62

Replied by Ferrante Enriques on topic Full Automation and Weather handling in the Scheduler


You are right, also WeatherWatcher has more than one parameter (3):
ferrante@astronuc:~$ indi_getprop  | grep WEATHER_STATUS
Weather Watcher.WEATHER_STATUS.WEATHER_RAIN_HOUR=Ok
Weather Watcher.WEATHER_STATUS.WEATHER_TEMPERATURE=Ok
Weather Watcher.WEATHER_STATUS.WEATHER_WIND_SPEED=Ok

I thought there was a 'state' parameter because reading the Dome base class (indi/libindi/libs/indibase/indidome.cpp, line 806):
crackIPState(findXMLAttValu(root, "state"), &weatherState);
It seemed to me that 'state' was about a global weather status.

Having understood how the properties are seen from the outside I would say the 3 above: WEATHER_RAIN_HOUR, WEATHER_TEMPERATURE and WEATHER_WIND_SPEED.
And as there's no single property to check, I would say if any of the 3 fails.

No I didn't. Thanks for the advice, that could solve the whole issue. But I also wanted to understand how INDI worked in this case.

Thanks
4 years 11 months ago #38911

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

  • Posts: 249
  • Thank you received: 62

Replied by Ferrante Enriques on topic Full Automation and Weather handling in the Scheduler

hi Hans,

I'm adapting the script to my setup, 2 out of 4 of my devices work:
1) Roof is ok. Only updating the property was needed:
INDI_DOME_PARK_PROPERTY = 'Talon6.DOME_PARK.PARK'

2) Weather is ok. Just used '_PARAMETERS' instead of '_STATION_INDEXES' :
WEATHER_WATCHER_PARAMETERS = {'WEATHER_RAIN_HOUR', 'WEATHER_TEMPERATURE', 'WEATHER_WIND_SPEED'}
And changed the variable names accordingly in the script.

3) Mount. I'm using 'LX200 10Micron' drivers. There's no PARK property there. Are you using the same driver?

4) Camera. The property 'ZWO CCD ASI071MC Pro.CCD_COOLER.COOLER_ON' is not listed using getprop with ASI071. Anyway when I execute the script it returns true but the cooler is still On. The only other property related to cooler is 'ZWO CCD ASI071MC Pro.CCD_COOLER_POWER.CCD_COOLER_VALUE' but doesn't change the cooler power neither.

5) Cap. Didn't test the cap.

Ferrante
4 years 11 months ago #38946

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

  • Posts: 85
  • Thank you received: 40

Replied by Hans on topic Full Automation and Weather handling in the Scheduler

Hi Ferrante,Great !

I would hope so, I get this :
indi_getprop | sort -u | grep 10micron | grep PARK
10micron.DOME_POLICY.LOCK_PARKING=Off
10micron.TELESCOPE_PARK.PARK=On
10micron.TELESCOPE_PARK.UNPARK=Off
What do you get ? Is your scope parked when you try this ? Or has the scope been parked with this instance of the INDI driver once ?

In the ZWO asi_ccd.cpp code we have
bool ASICCD::initProperties()
{
    INDI::CCD::initProperties();
 
    IUFillSwitch(&CoolerS[0], "COOLER_ON", "ON", ISS_OFF);
    IUFillSwitch(&CoolerS[1], "COOLER_OFF", "OFF", ISS_ON);
    IUFillSwitchVector(&CoolerSP, CoolerS, 2, getDeviceName(), "CCD_COOLER", "Cooler", MAIN_CONTROL_TAB, IP_WO,
                       ISR_1OFMANY, 0, IPS_IDLE);
 
    IUFillNumber(&CoolerN[0], "CCD_COOLER_VALUE", "Cooling Power (%)", "%+06.2f", 0., 1., .2, 0.0);
    IUFillNumberVector(&CoolerNP, CoolerN, 1, getDeviceName(), "CCD_COOLER_POWER", "Cooling Power", MAIN_CONTROL_TAB,
                       IP_RO, 60, IPS_IDLE);
As you can see there the CCD_COOLER parameter is IP_WO, a write-only parameter. You get to see these with indi_getprop when you add -w
indi_getprop -w | sort -u | grep CCD_COOLER
ZWO CCD ASI1600MM-Cool.CCD_COOLER.COOLER_OFF=On
ZWO CCD ASI1600MM-Cool.CCD_COOLER.COOLER_ON=Off
ZWO CCD ASI1600MM-Cool.CCD_COOLER_POWER.CCD_COOLER_VALUE=0
And writing to CCD_COOLER_POWER is indeed not allowed as it's IP_RO , Read Only.
But writing to CCD_COOLER.COOLER_ON should work still. If it does not then that is a ZWO ASI and/or INDI driver bug. You can file a bug for that ;-)

Neither can I, I don't have a cap (yet).

-- Hans
The following user(s) said Thank You: Ferrante Enriques
4 years 11 months ago #39016

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

  • Posts: 249
  • Thank you received: 62

Replied by Ferrante Enriques on topic Full Automation and Weather handling in the Scheduler

Hi Hans,
I'm getting the same result here. At first I was testing with the mount disconnected.
ferrante@astronuc:~/ekos_sentinel$ indi_getprop | sort -u | grep 10micron | grep PARK
LX200 10micron.DOME_POLICY.LOCK_PARKING=On
LX200 10micron.TELESCOPE_PARK.PARK=On
LX200 10micron.TELESCOPE_PARK.UNPARK=Off
I didn't know about the -w option thanks. I get the same result also here.
For the ASI 071 only the 'On' commands work.
I mean that for turning off the cooler this doesn't work:
indi_setprop -h localhost 'ZWO CCD ASI071MC Pro.CCD_COOLER.COOLER_ON=Off'
But for some reason 'turning on the off' is ok:
indi_setprop -h localhost 'ZWO CCD ASI071MC Pro.CCD_COOLER.COOLER_OFF=On'
Adapted your code to match this and works fine.
All the single devices are working as expected now, thanks for your advice.
Now I can test it on the field.
Ferrante
4 years 11 months ago #39041

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

  • Posts: 85
  • Thank you received: 40

Replied by Hans on topic Full Automation and Weather handling in the Scheduler

With EKOS 3.2.2 closing up the observatory again on bad weather (live tested and verified last night, yay !) I'll adapt sentinel to handle the that the mount may already be parked etc. so that sentinel turns into a second defense line, an independent safety mechanism.
-- Hans
The following user(s) said Thank You: Derek
4 years 11 months ago #39112

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

  • Posts: 1187
  • Thank you received: 370

Replied by Wolfgang Reissenberger on topic Full Automation and Weather handling in the Scheduler

Good news, that it is back working again. With the thoughts from here and from the Scheduler refactoring thread in mind, I started testwise to develop a dedicated tab for the observatory. Currently, it looks like this:



Within this module, I plan to embed the logic that currently sits inside of the Scheduler.

Feedback warmly welcome!

- Wolfgang
The following user(s) said Thank You: Alfred, Eric, Jarno Paananen, Ferrante Enriques
4 years 11 months ago #39113
Attachments:

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

  • Posts: 85
  • Thank you received: 40

Replied by Hans on topic Full Automation and Weather handling in the Scheduler

Hey that's great that you started this ! Please tell me this lives in a branch in github somewhere :) (we can arc it to phabricator later :-P )

We need to add things like which dome/roof driver is in use, make a distinction between roll-off roof and dome with shutter, which safety system is in use and what its status is (I see weather is already there), enable or disable closing on bad weather, we need a flexible close order (like dome park first, then close cap, then close shutter). And a hysteresis setting, like if we closed down and things are safe again wait with opening for X time. Retries, how many ? Logic like if dome park fails do we still want to try to close the shutter or not ? Maybe even pre and post scripts or curl calls per action. And a wake-human alerting system, which may be just another script to be called so to defer the actual implementation to the user. Do we need to support multiple mounts in an observatory here too ?

-- Hans
4 years 11 months ago #39119

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

Time to create page: 0.849 seconds