Hi.
A while since I have posted here, but now I have a nice diff to the inditelescope and indidome, that I hope will be adopted
I'm posting here in case there is some clarification needed before adding a pull request on git.

Why:
On my observatory unparking mount while dome is parked or even worse parking dome when mount is unparked, will lead to an 100% guarantied collision.

What:
inditelescope has new options in option tab
Ignore dome | dome locks | dome parks | both (the last two)

* Ignore dome = default same as usual.
* dome locks = mount cannot unpark if dome is parked
* dome parks = if the dome and mount is unparked and the dome starts parking, the mount start parking.
In some cases this could be great, but if dome parks faster then mount.....
* both = dome locks & dome parks

indidome has new options
ignore telescope | telescope locks

* ignore telescope = default
* telescope locks = do not park dome if mount is unparked. Hovever this will tell the mount to park (the first attempt) if inditelescope is set to dome parks | both. The second time (if mount is done parking) the dome will park.

How to use it in a telescope or dome driver?
do not park if
INDI::Telescope::isLocked() == true
INDI::Dome::isLocked() == true
The autopark in inditelescope is just snooping so a dome does not have to think about it.

Funny enough I started on the telescope part first, then I worked on the dome part, and was having issues when I came to test on the RollOff Simulator. After some digging I found that an similar solution was implemented in that driver under the name Scope Aware. Cannot remember seeing it before, but perhaps I have!?
Anyways I think such a function is more suited to be in the super class, and not have to be implemented in every hardware specifik driver.

I removed the implementation in the RollOff Simulator and added new code to RollOff | Dome Simulator, to show how easy it can be used.
Also did the same to Celestron GPS and Telescope Simulator.

Any questions, let me know. Feel free to test it.
It's implemented on commit 4dcc62b4f592647b692c27c4a944b98db20cecc9

Seems nice to me.

Looks good! Great work. Only issue so far (I need to test it later) is triggerSnoop, you should never use indi_getprop within driver. Do you have a race/unknown condition going on?

Looks good and yes this is a problem that many people with non dome observatories have.
We need to think the solution through a bit more to ensure it works for everyone.
This will hopefully avoid people going off implementing their own custom solutions (like I did )

One possible problem I would have is with:
For me, if EKOS is guiding, then this would result in equipment damage. Here is why,,, EKOS guiding must be stopped before my mount (celestron cpc1100) can park. The problem is, if I try to park the scope while guiding, the scope moves a couple of degrees, stopps then says 'park complete' Then if the roof closed it would hit the scope . Maybe this option could work for other people, but it needs a very clear warning.

Also, I think using indi_getprop within a driver may tightly couple the 2 drivers which may go against the overall architecture.

Derek

Well, another idea is to move this logic to the client since it "sees" all and knows what's going on, or "can" know what's going on at least. But then each client has to implement it separately on their own. Of course, for something like "Stop" guiding, this can never be done at the driver level.

Hi.
Did not realize parking when guiding could be an issue.

The triggerSnoop function is for the cases when (as example) the dome driver connects first, then the telescope driver starts.
In that case the dome driver will 'get' the parkstatus for the telescope when it connects, as telescopes parkstatus is updated and snoopable.
However the telescopedriver does not 'get' the domes parkstatus, as it's not updated (changed) when the telescope connects.
Thats what triggerSnoop fixes? Issuing a getprop on the domes parkstatus will tell the dome to send it and the telescope can snoop.

Also works the other way if telescope connects before dome.
The IsLocked boolean is initialized to true, so if the telescope connects and the dome fails to connect, the telescope assume dome is locking (as there is no way of knowing). This can be suppressed by temporary setting dome locking to ignore dome.

If there is a better way to active snoop on a property that is not updated / changed, then it could be used instead of the getprop in the triggerSnoop function

I do like the idea ofthough.

However I have a feeling that the client should be responsible for the more complex orchestrations.

Derek

So yes there is a better way, but it was never developed before. I spent the last couple of hours trying to figure a minimal and elegant way to achieve this. At any rate, update libindi and the way you "triggerSnoop" now explicitly, that is, if you want to see the value immediately, then just send a regular IDSnoop(..) call with the device name and the property required.

Try it out and let me know if it works.

I also think it is critical to add dire warnings when any option besides ignore is selected.

Added warnings, and changed triggerSnoop to use IDSnoopDevice, witch worked great

Looks good, if there are no other objections from other members, please submit it as a PR.

Cool, no objections

Just to clarify.
I made a new branch with 'git checkout -n branch-name'
Then added changes 'git add .'
Then committed 'git commit -m "message"'
then 'git push' gives me this error:

warning: push.default is unset; its implicit value has changed in
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the traditional behavior, use:
git config --global push.default matching
To squelch this message and adopt the new behavior now, use:
git config --global push.default simple
When push.default is set to 'matching', git will push local branches
to the remote branches that already exist with the same name.
Since Git 2.0, Git defaults to the more conservative 'simple'
behavior, which only pushes the current branch to the corresponding
remote branch that 'git pull' uses to update the current branch.
See 'git help config' and search for 'push.default' for further information.
(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
'current' instead of 'simple' if you sometimes use older versions of Git)

fatal: The current branch telescope-and-dome-locks-oposite has no upstream branch.
To push the current branch and set the remote as upstream, use

git push --set-upstream origin telescope-and-dome-locks-oposite

So, should I use 'git push --set-upstream origin telescope-and-dome-locks-oposite' log on to github and create pull request?
From my googeling ths is the correct way, but figured I should check first