This is actually a really clever approach; I hadn't considered querying the Ekos engine "just-in-time" via API after launching the script to get parameters from it. The timing might be a bit tricky; you'd need to set it up as a pre-capture script and have it fork so control returns from the script, then wait a short amount for the exposure to start and then query the value, then ensure the script finishes at approximately the same time as the fake main exposure, but with a bit of tweaking this would likely do the trick.
I'm not currently using the RTS trick described in this post as I've switched over to a camera with proper driver support so I can plate solve, but if I end up running my old camera piggyback for widefield exposures on the same mount then this approach should let me synchronize exposures between the two units with minimal additional configuration. Thanks for the great idea!
Are you confirming that these fields no longer support parameters being passed, then, when the previous post-capture script field did?
I would consider it perfectly adequate to be able to pass a single string parameter; as you say, it's possible to pack an arbitrary number of fields/variables into a structure like JSON that's passed this way if needed, and if you're writing the receiving script yourself you can build it to decode whatever is passed pretty easily. This would only be slightly less convenient for people trying to trigger a pre-built command provided by somebody else without having to write their own wrapper, but if it's easier to support a single parameter than an arbitrary number then that wouldn't be a showstopper
In a previous version of Ekos, I had been using the post-capture script with a command like the following:
2021-05-16T01:33:43 Executing post capture script rts_shutter.py 120 2021-05-16T01:33:43 execvp: No such file or directory 2021-05-16T01:33:43 Post capture script finished with code -1.