Ferrante Enriques replied to the topic 'New EKOS Observatory module' in the forum. 3 days ago

hi Wolfgang,
Using Weather Watcher. But I can't recreate the status icon issue anymore. I will let you know if I understand the condition for this to happen.
Ferrante

PS: sent you a personal message on a related topic.

Read More...

Ferrante Enriques replied to the topic 'New EKOS Observatory module' in the forum. 3 days ago

hi Wolfgang,
tested the latest version, attached a screenshot.
The park delay on Warning / Alerts works just fine and it's great! thanks.
Minor issues:
- on startup the Weather status icon is not shown (see picture). But when status changes the icon is back.
- If the dome doesn't have shutter, the shutter controls on the right shouldn't be visible.
- I rather prefer a delay in seconds.

I'll write you a PM later.
Ferrante



Read More...

Ferrante Enriques replied to the topic 'New EKOS Observatory module' in the forum. 7 days ago

hi Wolfgang,
I've a roll of roof, and yes, Observatory works as expected with mine: unpark opens, park closes (*).
Moreover, opening is inhibited if weather is not ok.

(*) as you know there was recently a discussion whether or not this was the right approach.
ferrante

Read More...

Ferrante Enriques replied to the topic 'New EKOS Observatory module' in the forum. 7 days ago

hi Sterne Jaeger,

I cloned the repository and installed in my remote observatory and can confirm it works with 'real' devices too.
Weather status is read from weather station and changes status accordingly.
Dome (roof in my case) parks and unparks. Attached a screenshot when roof was unparking / opening.

Good job! thanks.
Ferrante



Read More...

Ferrante Enriques replied to the topic 'Partitioning the Scheduler code' in the forum. 2 weeks ago

I'll look at modifying the specification to make things clearer but if there is much more on this we should start a separate thread. This is only peripheral to partitionng the scheduler.

Good point, further discussion on how a roll off roof should park / close shutter should be moved to another thread.

For clients I would add the close shutter command to the make the observatory safe process. The dome park command can be left, domes may need it anyway.

Beside the specific topic, this has influence on the overall approach : will the new Observatory orchestrate steps of a 'shutdown' procedure leaving the implementation of shutdown inside individual drivers (like it is happening today) or will the Observatory effectively manage the single steps in detail?

Thinking about using these messages in the drivers I contribute to, I 'm in favor of the first: It helps to segregate duties among clients and devices (and among client and driver developers).
For example, if safety conditions in the Observatory are not met, that should trigger an agnostic 'shutdown' (or 'observatory not safe') message to the individual driver without any required knowledge of the shutdown procedure itself.
On the other hand, adding Close Shutter command to the client when there's already Park, means that part of the shutdown procedure logic would be implemented in the client.

Some domes require the shutter to close after the dome rotates to park position, others don't; roofs have a different behavior etc. And for me it is best to let the developer of the driver manage this procedure because he is the one who knows how the device works.

In the case of domes, until now, this 'shutdown' role was played by Park, even though in the specification Park was meant just to move to AZ park position.
I'd rather update the specification or even change the name Park but leave the park shutdown logic inside the driver.

Domes here are just an example, it would be true also for other devices involved in the Observatory (mounts, cameras, caps).
Ferrante

Read More...

Ferrante Enriques replied to the topic 'Full Automation and Weather handling in the Scheduler' in the forum. 2 weeks ago

Hi Hans,

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 ?

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

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

I didn't know about the -w option thanks. I get the same result also here.

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

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

Read More...