Jasem,

There have been many times that I could use something like that. Like for Arduino based projects, which reset when the port is opened, then haven't finished initializing before the driver sends a software handshake. Twice I've had to modify hardware to compensate for that.

I have an LX600 with a bad GPS. When it boots, it is set to go to the daylight savings prompt and wait for the date and time. That takes 20 to 30 seconds. The lx200autostar knows nothing about this process, so I can't load indi until after I have powered on, and run a program to initialize the date and time on the scope. It would be really nice to have a driver that could power up a device, delay some amount (like the 20-30 second initialization time of an unattended LX600), and run a script to initiailize it correctly before the LX200driver attaches and hogs the port.

I built an 8-port switchable power box that is used for that now, but I have a separate python app that has checkboxes to power on each port. I would much rather have a driver that I could interface the box with that would do what you have suggested. Or can that be accomplished with current power box interfaces?

Thanks,

So each driver may have something like this:

Pre Start Delay --> Pre-Start Script --> Post-Start Delay --> Post-Start Script

Would this be sufficient to cover all cases? Another challenge as well is that this must be supported locally and also remotely.

I'm in favor of incorporating it into the server as an automated script if the driver doesn't work, but I'm against adding the driver's parameters.

Even if you add a driver parameter, the problem will not be solved if the initial value is 0, and it will always cause a problem if the setting is initialized by a user who has not set it or an update.

The INDI driver has many problems with user settings being initialized on update.

I think that the user prefers a state where it works properly without setting the parameters of the control panel.

Jasem,

That would cover all of my use cases. I'm not familiar enough with the code to say where I think it should live.

Thanks,

It's implemented in GIT now. Please test.

Jasem,

I pulled the source and compiled libev, indi, indi-3rdparty, and kstars. Everything seems to run, but I don't see where the config for the delay is.

Edit your equipment profile ---> Scripts

Jasem,

Sorry it took so long, but I I had to build Kstars, indi, and the 3rd party drivers. It takes a while on the Raspberry Pi.

Editing the lx200autostar, I put a 30 second pre delay, then a bash script, with no post delay. It seems by the log file that it waited 30 seconds and then loaded the lx200autostar and the other 7 drivers. I'm not sure if that is what it is supposed to do.

Then I added a 10 second delay with no script to the pegasus_flatmaster driver, leaving the 30 second delay in the lx200autostar. That changed the load order, but not the behavior. It loaded the pegasus_flatmaster driver after 10 seconds, but also loaded the other drivers in the same second. It was as if the only delay it was seeing was the shortest one. I'm going by the log file - I can't actually verify that the 30 second delay did or did not happen. I also can't verify that the script actually ran. Does it wait until the script finishes before loading the driver?

I have attached the log file from the run where the Raspberry Pi was running Kstars and the indiserver.

I just tested again and it works fine. Did you save the profile after you made the changes in the script? You must save the profile otherwise the changes will not be saved. The logs show no delays nor logs at all. I just pushed a change to GIT to add more logs.

Jasem,

It was "Auto Connect". I had it turned off because I normally need to initialize the LX600. It worked perfectly. It ran the script and initialized the scope, then attached tthe driver.

Thank you for your work on this. I think it is a worthwhile addition. I've attached the log file in case you want to look it over after your additional logging.

Jasem,

One question...If it is indiserver doing this, is it reading the local database, and does that mean if I set it up on the Raspberry Pi it will still work if I connect remotely?

I've added this feature to StellarMate as well, so it can be done remotely. But this is not published yet, would be in SM OS v1.7.2 coming in a few weeks.