hi Gunter,
Nice observatory you have there.
So, if I unterstand correctly, each of your RPIs is running an INDI server, the primary RPI ("RPI41") manages the telescope devices and the secondary ("allsky") manages the roof and other stuff.
Then those RPIs are chained so that the Kubuntu laptop Ekos client sees all the equipment.
The status of connect or disconnect you are referring to is the Dome Scripting Gateway (DSG for short) driver on Allsky? In these case, if the network connection is working fine, it should always be connected. I mean, DSG doesn't check if the roof device is available or not. Other drivers that directly connect to the device through a serial connection might return a 'disconnected' status if the device is for example not powered on.But DSG doesn't work this way, the device (roof) is decoupled from the DSG driver.
In other words, for DSG the connection only shows that the connection from the INDI server to the client is ok/ko.
Using DSG the only way to exchange information between INDI driver (and thus the Ekos client) and the device is through the indi-status file.
So status.py, open.py etc don't return
any value to INDI/Ekos directly, they can only update the indi-status file to provide information about the device.
For example: '1 0 0' means to Ekos that roof is parked (closed), while '0 0 0' roof unparked (open). If you are wondering what are the other digits meaning, remember that this is a Dome driver not just managing Roofs.
All the scripts (open, close, abort) don't really need a loop, so there's no harm in executing abort immediately after open.
I see it this way: 'open.py' should only trigger the relais that starts the roof motor and then exit. Then the user could run the 'abort.py' script by pressing 'abort' : the script simply triggers the relais that stops the roof drive and exit.
Remember, like said before, that both open and abort in this case don't return any value to INDI/Ekos, they can update indi-status though.
From this example it is clear that the information in indi-status is limited: You can read that the roof is unparked after pressing 'open' but you cannot see if it's running, aborted or fully open.
I've used DSG for three different observatory as a temporary solution while writing the INDI driver for the roofs (which I still recommend to you).
My approach is to make use of park and unpark to trigger the roof actions only and not to update indi-status.
Then status.py periodically reads the status from the device and writes it to indi-status, so that INDI/Ekos is aware of the roof status.
Finally abort.py is used....well, to abort roof motion.
If you start developing a roof driver I would recommend to start with:
github.com/indilib/indi/blob/master/drivers/dome/roll_off.cpp which I guess was the one you were referring to.
You don't need to send any parameters to the scripts: it is the INDI environment that automatically sends these parameters. They are two file names and file locations if I remember correctly.
All this is based on my maybe limited understanding of DSG. Others could jump in the conversation and add more insight.
I hope that in some way I understood your questions but please provide further information if it helps.
Ferrante