×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Full Automation and Weather handling in the Scheduler

  • Posts: 85
  • Thank you received: 40
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 10 months ago by Hans. Reason: fix
4 years 10 months ago #38894

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

  • Posts: 249
  • Thank you received: 62

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 10 months ago #38911

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

  • Posts: 249
  • Thank you received: 62
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 10 months ago #38946

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

  • Posts: 85
  • Thank you received: 40
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 10 months ago #39016

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

  • Posts: 249
  • Thank you received: 62
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 10 months ago #39041

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

  • Posts: 85
  • Thank you received: 40
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 10 months ago #39112

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

  • Posts: 1185
  • Thank you received: 370
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 10 months ago #39113
Attachments:

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

  • Posts: 85
  • Thank you received: 40
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 10 months ago #39119

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

  • Posts: 1185
  • Thank you received: 370
Last edit: 4 years 10 months ago by Wolfgang Reissenberger.
4 years 10 months ago #39122

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

  • Posts: 85
  • Thank you received: 40
Awesome. Do you generate kstars/ekos/observatory/observatory.ui with some tool ? and if so how does that work ?
4 years 10 months ago #39242

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

  • Posts: 1185
  • Thank you received: 370
I use QTCreator for development. It contains a graphical editor to generate the XMLs.
4 years 10 months ago #39245

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

  • Posts: 112
  • Thank you received: 9
Hi,

I was wondering if someone can help me understand the logic behind the Ekos Scheduler. In the attached screenshot I added eight targets to a schedule and assigned each Priority to 10 and constrained Altitude > 30, also Twilight is unchecked since I am using simulators. Thanks to all those who contributed to this thread. Lots of activity up until 6 months ago.

Right now the time is 0830 on December 11th. It is true that four targets meet the criteria of Altitude > 30: NGC 2683, NGC 2903, NGC 2841, and NGC 3198.

I was expecting the scheduler to bubble those four targets to the head of the job list with a Start Time of now; after all, they are visible. Instead it says I need to wait 7 hours for M33 to come around to the east again. I've tried clicking buttons to alter the behavior but the only control I seem to have is changing the priority. The up and down arrow buttons don't appear to do anything.

I was hoping to create a schedule of hundreds of targets and have the scheduler run those jobs that meet my criteria (including also weather.) For example if it is cloudy at sunset it would wait until the weather cleared at say 2am. If the weather goes from good to bad then suspend imaging, close the dome, and wait for conditions to improve again.

I'd like to run the Scheduler once, and have Ekos work continuously, day after day, waiting for darkness and good weather, and when that happens check to see which of the targets meet the criteria (i.e. Altitude > 30), and then begin imaging.

I understand that it is a lot to ask for but I was wondering what the roadmap looked like. Thank you, again.
4 years 3 months ago #46815
Attachments:

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

Time to create page: 1.013 seconds