There is already the optional protection built in between the roof and the mount. The roof has the Mount Policy propertyand the mount has the Roof Policy property. So a parked roof can prevent the mount from unparking/moving? And the upnarked mount can stop the roof from closing. Adding external sensors to detect park would ensure the mount is not reporting parked state when it is unparked. Don't know if that is a thing or not.
If KStars fails I think the Watchdog driver will go a long way to letting you do a safety shut down using the built in capabilities. indilib.org/aux/watchdog.html.
Perhaps you could write a driver to handle your power detection requirements and it could in turn initiate a shut down by notifying the watchdog like the weather drivers do.
The rain detection might not need special handling, if things are not working normally then the obs should already be shutting down.
If some processing does need to be outside of Ekos for the rain or other reason, it could be handled by a script or external program. I can't find the forum discussion, but attached is a script user Haans provided. I edited it for local equipment. It is interesting, demonstrating what kind of control can be applied. Don't know off hand how much if any of Ekos that needs to be running for it to work. But could always use a script to locate running processes and kill them off before starting a new subset to work with.
I just started following this post recently and found out that I could replace the python based "Dome Scripting Gateway" that I use with my "roll-off' with your rolloffino based driver.
My small, remote observatory uses a split roof on rails driven by linear actuators. To either open or close the roof, I need to activate two relays, one for direction that reverses the actuator polarity and the other to provide power. As your Arduino code uses one relay per roof function (one for opening, one for closing), I wonder if you would have any suggestions to implement two relays functions. I could modify the Arduino code so much to make it specific for my need but I ideally want to keep the code structure intact except for the specifics needed for my application.
Do you hold both relays on until a fully open or fully closed switch is sensed? If so that would be the first thing to tackle. Most examples assume some controller will take care of stopping the roof. We would need to respond to the driver that the command had been accepted then monitor for when to turn off the relays. Becasue it is relatively a long time to open/close additional requests will be coming in from the driver if only to get the state of the switches. But need a quicker response to a fully closed state than the driver polling so needs to be done locally.
Can we map the commands open, close abort to the relays you presently activate?
Is there a sequencing requirement such as direction before power?
Open: Relay 1 close Relay 2 on
Close: Relay 1 open Relay 2 on
Then to stop or abort Relay 2 is turned off and Relay 1 is left in whichever state it was previously set to.
If it is something like the above and movement needs to be stopped when the limit switches are activated it would be good to have an example for that. Be glad to take a shot at it if you are not in a hurry.
I use a 'DIRECTION' as well as an 'ACTIVATION' relay to open or close the roof.
To open, I only activate the ACTIVATION relay as the NC position of the DIRECTION relay wires the power of the linear actuators (I have 2) to extend. To close, the DIRECTION relay is activated prior to the ACTIVATION relay, to reverse the polarity of the actuators, thus retracting it. The actuators have limit switched to turn them off when the end-of-course is attained but I do not have access to those. I know that the roof is opened or closed when the respective roof limit switches are set to ground (pull-up used) but the Arduino code needs to wait a few more seconds as the roof hits the limit switches before being fully opened or fully closed. The opening and closing functions are blocking so I can't really issue an abort or stop command unless I make some changes that may be a bit more complex. I hope my explanations are clear, if not do not hesitate to let me know.
Open: DIRECTION relay OFF, ACTIVATION relay ON
Close: DIRECTION relay ON, ACTIVATION relay ON
Abort: ACTIVATION relay OFF
Is there a regular polling of the limit switches from the indi driver? If so, I can simplify my code and rely on the driver to know if the roof is fully opened or fully closed. That would simplify things.
Gilles, Yes that is clear and the limit switches simplify things. And yes the driver will be polling waiting for the fully opened/closed switches to be set. My initial note for this was to add some extra definitions but I'll ask some more questions when when I walk it through the code a bit. We need to figure out whether its a replacement of the current Arduino code or a merge. If you have local control buttons that need to be retained or other needs, having a copy of the existing code would help with that and minor stuff like pin assignments, active high or low on the switches.
Moving forward with the Arduino code. I can set the relays to their correct states for opening and closing the roof, as well as the limit switched status. The remaining issue is to reset the relays to their inactivated states, i.e. NC. I am not sure where in the code I should put the "put relays to sleep" function. I tried where the limit switches are checked but no luck. I need to put that code in a place that gets executed 'often' and need to add a small delay, as the limit switched change state before the roof is fully opened or closed.
I have attached my adapted version of the rolloff.ini.standard code if it may help. And I am running a mock-up Arduino roof controller with LEDs as relay indicators and wires as switches.
Last edit: 2 months 2 weeks ago by Gilles Gagnon. Reason: Added more info
I would tend to approach it using new interrupt routines. Setting the relays to a neutral state could be fired by your fully opened, fully closed switches not the delayed polling from the driver. I'd like to do a generalized version of this but wouldn't get to it until maybe the weekend. If you need an extra delay after the switches close then instead of the interrupts perhaps just add switch checking in the loop routine. You could set a flag to let the loop routine know movement has started could also indicate whether opening or closing. Routine commandReceived could be used to check for OPEN or CLOSE and set the flag. The loop period could be shortened when waiting for movement than the normal nothing happening loop timer.
Edit. The setting of the relays to a non active state would be done directly without sending anything back to the driver. If you use the relay routines need to stay away from the Ack/Nak routines. The driver will be polling the switches independently but everything is driven by the loop routine polling so should not be any conflicts.