I can test with my mount/scope and obsy side by side so no collision can occur but, unfortunately I have never used the scheduler (tried quickly without success 30 minutes ago) and must figure out how to use it. Furthermore, I won't be able to test for a few days. I would have loved to but I will be away from my setup.
Makes a lot of sense to me.
Would it also make sense to make it an orderly 'shutdown' procedure that could also be used when the scheduler or the user has finished its tasks for the night? Not wanting to overly complicate things though.
Thanks for the clarification and for correcting my comment re: use of 'command' instead of 'snoop'.
So, if I get it correctly, mount and dome/roof should snoop on one another to make sure no action is taken that could create a dangerous situation. Could we use a "Collision Avoidance" snoop property that could be set for roofs (or domes) that do not have the appropriate clearance to park without problem? This could help set the correct sequence of events when unparking/parking.
From what I remember when I looked at the code, there are 2 file sets (.h and .cpp) to look into. As 'wotalota' mentionned, there is "indidome.h and .cpp", as well as "inditelescope.h and .cpp", in the ".../libindi/libs/indibase/" directory, on the mount side. I could not find the way policies are executed in those files or how the park messages are passed to one another, or from another driver (e.g. weather related).
Logically, if a dome/roof park command is issued (from user or weather station), the driver should make sure that the mount is parked before parking and if not, a park command shall be issued to the mount and completed before the dome/roof is closed. From what 'Gonzothegreat' and me have observed, it seems that the order is not respected.
As I mentionned in another related thread, I unfortunately do not have the expertise to dig into the problem efficiently and come up with a solution quickly but I would hope the solution is not too far away.
Thanks for everybody's input and help.
I think the problem can be solved and I would like to put my knowledge into it but, unfortunately, I lack expertise in coding, particularly C++, and a lot of the KStars/EKOS/INDI wisdom that would help make the task easier but I would hope that help is available from people who face the same situation. We have to find the person(s) who can help to "mettre l'épaule à la roue" (put one's shoulder to the wheel) and find the solution which I think may be simpler than expected.
I may be wrong in my thinking but ket's hope not.
I started looking at the parking policies some time ago, documenting it with video sequences of my 'clamshell' observatory and mount (mount was outside the obsy for obvious reasons). Unfortunately I had something else to take care of and, for that reason, I did not have time to finish the work .
There are a number of cases, for roll-off and clamshell observatories, where collision will likely occur between mount and roof as the roof may park, as you observed, before the mount does (see the video at indilib.org/forum/domes/6476-dome-parkin....html?start=12#53277 ) . I looked at the roof and mount code to see if I could find where the park commands are issued, given specific policies, but I did not find anything obvious. Nevertheless, if a park command is issued for the roof, either from the user, or a weather station warning of bad weather, the roof shall not close before a mount park command has been issued and the mount has completely parked.
If anyone wants to help on this issue, an Issue Hunt ( indilib.org/forum/development/7275-issue...velopment.html#56469 )will likely be put in place that will hopefully generate interest, as this is a problem that must be of concern to a number of people.
If you go into the Alignment (bullseye) tab of EKOS (have to connect mount, camera and astrometry), you click on the options button (bottom right) and you will see an Index Files tab on the left that will allow you to select and download the astrometry files. From there you will be able to select the Index Files Location that may give you 2 choices: 1) "/usr/share/astrometry" for which you likely do not have write permission, and 2: "/home/yourhomedirectory/.local/kstars/astrometry" for which you shall have write permission. Select the "/home/yourhomedirectory/.local/kstars/astrometry" from the list. You should be able to tick the file selection and download should start soon after.
If you prefer to have all the files in /usr/share/astrometry, you can always sudo move them afterward but you may have to change ownership and permissions.
Olivier and Wolgang,
I am not sure that there is a defective or badly connected sensor as I observed the same behavior with my Nano version but not with the Wemos version of Weather Radio.
If there is a sensor I would suspect of causing the delay, it is the TSL2591 as, depending of sky brightness, its integration time may not be negligible (600ms) and the sensor may need its integration time and gain to be adjusted a number of times in order to give a meaningful reading, particularly in darker conditions.
From what I vaguely remember with my Arduino Nano version of the later versions of Weather Radio, even issuing commands directly, using the serial console of the Arduino IDE, did not work well. The first command sent returned the correct info but further commands seemed to be queued somewhere and never be replied to or returned invalid data.
As far as referencing the pressure to sea level value, that's the logical thing to do.
Sorry for not replying since yesterday, was on the road.
Since I moved to using a Wemos D1 Mini, I haven't had any problem but my Weather Radio (version 1.3) has been offline for sometime since I am (very) slowly working on finishing my observatory. I must admit that I much prefer the way Weather Radio is impletemented vs MeteoStation, based on 'firmata', which is heavier and makes difficult adding functionnality. Furthermore, I had more and more connection problems with MeteoStation, which made the change to Weather Radio a welcomed solution.
Thanks for the excellent work Wolgang.
Just wondering if, like the Windows StarGo software, the INDI driver for the Avalon Stargo supports the Mount Model feature of the EKOS Align tab.
As, among other things, I needed to implement fail safe features to my observatory (close call), I am (very) late with the testing of the dome and telescope parking policies which I need to finish. Sorry about that.
I can look into adding the issue to the IssueHunt to attract interest into solving the problem, hoping that it can be a rapid fix to what can be an hazardous situation, for the equipment.
I had the same problem with Weather Radio and Arduino Nano since the WiFi feature has been implemented. There must be something in the code (WiFi related probably) that causes that. Wolfgang, the author of Weather Radio, may be able to shed some light.
Since I had some WEMOS D1 Mini, I used one and I got Weather Radio working correctly with INDI. If you have access to one, you can give it a try.