I have a situation where the Dome controller I’m writing the software for has two safety checks. One is low battery voltage and the other is a rain sensor.
When the voltage is low the dome will refuse to rotate (don’t want to damage the battery if it’s on a battery system) and the shutter will refuse to open (though it’ll still try to close).
The other is the rain sensor triggering will make the shutter close and refuse to re-open until the status is cleared.
This is great but because they aren’t separate ASCOM safeties there’s nothing in the Dome implementation that lets a client check for these conditions and the Supported Actions list would only be useful if the client knew to look for them.
What was suggested to me was to have the driver throw an InvalidOperationException with a string explaining the reason. With POTH a dialog appears without showing the reason. With SGP there’s no indication in the UI, just a refusal to move the related part. If logging is turned on then the exception with the reason is in the log.
I’m not really liking this situation since many users never bother learning how to look at logs never mind turning them on.
So my suggestion is to somehow show that there’s an error/exception in the device UI and maybe show the text the exception supplies?
Having said that, I don’t know if any other controllers include these kinds of safety checks or the setups use separate safeties with their own drivers so it might not be worth the effort.