Richard Horn thanked Hans in topic INDI DSLRs FAQ 2 months ago

Hans replied to the topic 'Full Automation and Weather handling in the Scheduler' in the forum. 3 months ago

sterne-jaeger wrote: github.com/sterne-jaeger/kstars/tree/ekos_observatory

Awesome. Do you generate kstars/ekos/observatory/observatory.ui with some tool ? and if so how does that work ?

Read More...

Hans replied to the topic 'Full Automation and Weather handling in the Scheduler' in the forum. 3 months ago

sterne-jaeger wrote: ... I started testwise to develop a dedicated tab for the observatory.

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

Read More...

Hans replied to the topic 'Full Automation and Weather handling in the Scheduler' in the forum. 3 months ago

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

Read More...

Hans replied to the topic 'Full Automation and Weather handling in the Scheduler' in the forum. 3 months ago

Hi Ferrante,

fenriques wrote: 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:
<code>INDI_DOME_PARK_PROPERTY = 'Talon6.DOME_PARK.PARK'</code>
2) Weather is ok. Just used '_PARAMETERS' instead of '_STATION_INDEXES' :
<code>WEATHER_WATCHER_PARAMETERS = {'WEATHER_RAIN_HOUR', 'WEATHER_TEMPERATURE', 'WEATHER_WIND_SPEED'}</code>
And changed the variable names accordingly in the script.

Great !

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

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 ?

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.

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 ;-)

5) Cap. Didn't test the cap.

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

-- Hans

Read More...

Eric thanked Hans in topic Partitioning the Scheduler code 3 months ago

Hans replied to the topic 'Partitioning the Scheduler code' in the forum. 3 months ago

TallFurryMan wrote: Hans, do you agree to make your Ekos Sentinel a parallel project to what is done in that Observatory module?

Yes that was my intention. To follow any upcoming EKOS' observatory close down changes and keep it only as a failsafe system for the cases where EKOS does not close down while it should. (I consider this to be a different situation from an EKOS crash where the INDI watchdog driver can kick in.)

We would follow the same approach as the Ekos Internal Guider developed in parallel to Linguider and PHD2.
That means your project needs to formalize a notification interface, and that means Observatory needs to clearly separate its safety management to accept external services. That would be a benefit for both I think.

That sounds perfect. Where are the parts of the Linguider/PHD2 interfaces that EKOS uses described ?
Ekos Sentinel can now only command the scheduler to start or stop. It cannot ask what the scheduler is doing. The new observatory module should have an API where external programs can query these things, and it would be great if the observatory module could inform sentinel that it is going to do something, and that it expects to take X seconds at max. I propose I add a REST API interface to Sentinel for this.

-- Hans

Read More...

Hans replied to the topic 'Full Automation and Weather handling in the Scheduler' in the forum. 4 months ago

fenriques wrote: i'm struggling to adapt your script to my setup, it's not as simple as adapting the initial configuration.

I'll try to help.

You are using Weather Meta, that driver is not extending the Weather base class.

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

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 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 OpenWeatherMap : public INDI::Weather 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.

I didn't succeeded yet replacing the Meta 'station_indexes' in your script with the standard WEATHER STATUS property.

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))

-- Hans

Read More...

Hans replied to the topic 'Partitioning the Scheduler code' in the forum. 4 months ago

sterne-jaeger wrote: From my perspective, the Scheduler remains the top level controller, even if we separate for example the observatory management. All these other modules should work on their own with the Scheduler orchestrating them.

In my opinion a weather/safety tab need to be able to guarantee safety, and thus stop or pause the scheduler (and park stuff) when conditions are not safe. As such it is the top level controller.
Safety includes manual sessions where the scheduler is not even used. When someone just manually uses the other tabs to open the observatory, point the telescope, etc.

-- Hans

Read More...

Hans thanked Eric in topic Partitioning the Scheduler code 4 months ago

Hans thanked Eric in topic Partitioning the Scheduler code 4 months ago

Eric thanked Hans in topic Partitioning the Scheduler code 4 months ago