Being able to make a phone call would be valuable, thinking about failures or weather alerts while sleeping. I briefly looked into VOIP and Google voice earlier this week, but didn't see anything obvious that could make use of the closed system VOIP I use. But it seems like there should be something there. For now I'm just going to do something that results in a simple ` play /usr/share/sounds/KDE-Im-Phone-Ring.ogg` to wake me up.
If changes were to be made to the indi Dome code, having a third telescope option would be useful: ignore wait or block.
Park both dome and mount at the same time or wait on the telescope might depend on what is mounted. With a small refractor I have no collision issue, with an SCT it needs protecting.
For the weather alerts it obviously needs to work without the scheduler, so having the Observatory first park the mount and then the Dome seems clean.
It looks like the scheduler is already aware of the alert but I don't know how it responds to that.
If logic is to be placed in the Observatory to wait until the mount is parked before parking the Dome, perhaps the scheduler can respond knowing that. It does not seem much different than how it must presently resolve the parking of the Dome knowing that the Observatory is probably already doing that because a weather alert has happened.
Does anyone know what added value the Dome property Auto Park provides over the other Dome/Mount policy combinations. Is it just a if you want to do anything useful do it at your own risk kind of a setting.
Thanks for the TelescopeClosedLockTP property info.
The initial impression is that the Observatory closes the Dome and depends on the Dome and Telescope policy properties to determine correct behavior.
I am just starting to do some testing of the settings.
After the first few, a weather alert with roof open and mount tracking I have not found one that causes the Dome to wait on the mount.
Dome: telescope locks & auto park
Mount: dome parks
This combination prevents the Dome from parking and it appears that subsequent telescope snoops of the mount do not detect a need to initiate parking.
Dome: ignore telescope
Mount: dome parks
This combination will park both but it is a race. In my install the roof is heavy but moves fast and most likely hits the telescope.
Need to test again to see that the roof respects telescope blocks and auto park disable settings. It might be that the roof could benefit from a wait to park on the telescope option. If so they seem doable. I think the next thing to look at is the telescope snoop code. It will probably be getting information from the roof. Does it receive enough information from the roof to determine a weather alert is in effect and/or the roof would really like to close but can not until it gets itself parked. If its rule settings allow why does it not respect the Dome parks setting. When that is sorted then go back to the roof and make sure there is a mechanism to determine that the telescope is now parked and it can continue.
The caution comes from this being at a level above the individual mount and dome driver so any changes will possibly impact all telescope and roof characteristics.
Just took a look on the Dome side it seems like the implementation is in indidome.cpp Dome::ISSnoopDevice
Expect there will be something similar on the Telescope side. First glance it might not be so much a bug as a not implemented as assumed. Needs someone familiar enough with the code in depth to be able to make a relatively quick modification. Or time to study the interactions and use cases to not screw up actual Domes expected behavior with side effects.
Looking at it from an external view based on the work with the test cases. Can the desired behavior be described. And are any additional property values or snooping options needed to describe the rules.
I ran a test on my roof and it is more prone to damage than I expected.
Telescope's Dome policy: Dome Parks
Roof's Telescope policy: Telescope locks
With a open roof and mount tracking, I caused a weather alert. The telescope kept on tracking and the roof closed.
So the telescope did not get parked nor did the vulnerable telescope block the roof.
I was hoping the telescope would safely park which would release the lock and allow the roof to start to park.
But either the roof being blocked or the telescope given a chance to get parked would have been something.
What are you seeing that indicates a weather alert has been generated, something on a Metrostation panel, or in the log file? I suggest you change over to use the weather simulator where it is easy to generate a warning or an alert, see screen shot. See if the observatory panel then shows the results you generate and if there is any response from the roof.
No it will take into account the position of the mount if you have it set to do so. That is what the Dome's "Telescope locks" and the Telescope's "Dome parks" setting intend to take care of. Plus your telescope parked switch tied into the roof locked detection will keep your scope safe from the roof. But as far as I know the dome monitors the weather and the telescope monitors the dome. If that is correct the telescope will not park in bad weather unless the dome parks. Seemingly there is currently an issue in the implementation, see the current discussion.
I tested the roof closure to the extent that a mist spray on a rain detector closes the roof.
Do you get the Observatory module's weather indicator to turn red indicating an alert?
I notice you have the Observatory options set to not close the roof on a warning. So does causing a 100% cloud covering generate an alert or a warning?
Does the roof close if you generate an alert when the mount is already parked?
Also mixing and matching combinations with the weather simulator and the rolloff simulator with your custom drivers might help you determine if it is a setting and where the issue resides.
Only thought is to see if ~/.indi/CCD_Simulator_config.xml file syntax seems to be intact and includes something like:
<newNumberVector device="CCD Simulator" name="CCD_GAIN">
In the meantime if your notebook is local and you have some device that works in usb slot 0. Considering all usb ports are the same usb2/3. Confirm the usb 1 and 2 are working at the OS level without INDI by using the same device in those slots. If they do not work, boot into the UEFI or BIOS and look for USB related configuration options that might enable them. A stellamate or Raspberry pi 4 would look nice in a dome.
would start off with just the eq6 and qhy connected directly to usb slots without the hub, can you establish the qhy connection that way.
If not what does the indi control panel for the qhy look like, do you have some of the tabs showing?
If qhy is connected then connect and disconnect the hub to the other usb port can you identify it coming and going using the lsusb command.
You should provide more information. What operating system and version, the version of KStars. What is the second peripheral and to which USB port is it connected. Is there a corresponding INDI driver loaded and if so which port is it using. Then someone familiar with the operating system might be able to make a suggestions.