Most of the functionality implemented in rts2-xmlrpcd.

Currently, RTS2 has only one way to notify external user if something happens - preprogrammed emails can be sent. Those are currently sent on dome events (dome opened, closed, restarted) for some domes and on targets events (target observations started, first image received, observations ended, all images processed). Text of the message is fixed inside RTS2, and to change it, it must be located in code and RTS2 must be recompiled.

It is clear that this approach was far overcome in current RTS2 use. More robust, configurable and modular approach is needed. It is also clear that sending of an warning email can be easily handled by bash scripts, or any other scripts, and must not necessary reside inside RTS2.

The major question is how values should be inserted into text that will be generated. Either internal RTS2 expansion can be used, which will generate text and pass this expanded text to the script, possibly on standard input. Or those values can be passed as environment values to the script and it can use them.

Using RTS2 expressions following template can be written:

Dear user,

dome on telescope Bootes was opened. State of end switch 1 is $DCM_ENDSWITCH1$, end switch 2 is $DCM_ENDSWITCH2$.

This will be passed on standard input of script, which might look like:

#!/bin/bash
 
mail -s "RTS2 trigger" test@example.com

with possible switches in the script based on trigger type, passed as argument.

The same can be governed only by script:

#!/bin/bash
 
echo "Dear user,
 
dome on telescope Bootes was opened. State of end switch 1 is $DCM_ENDSWITCH1, end switch 2 is $DCM_ENDSWITCH2." | mail -c ...

First form is more compact, distribute text string generation and processing of generated string.

Second form allow better changes, and also single script can be used to send an email and send SMS through other programm with different text in SMS.

First option is better if we decide to implement RTS2-Jabber server, which will distribute messages to Jabber - as text will be generated inside RTS2. If we use second approach, we can still achive that by having a small programm which will connect to rts2-jabber server and stream a message inside it. rts2-jabber server is envisioned as it might work as interface for distributing triggers through world and using something faster then email.

I am more happy with the second options, but would like to see comments before making final decision.

Stdout should be written to log as DEBUG, stderr most probably as ERROR or WARNING.

Following functions must be implemented in order to allow generic handling of triggers:

changes to Rts2ConnFork so it will allow checking for stderr

most robably will include change in Rts2Conn, rewrite of buffer processing which is now quite messy

new configurations options for triggers, most probably I will put all to new section called triggers, but I am not sure about those. Should dome settings be in [dome] section or should they be in [triggers] as dome_open etc. ?

changes to utilsdb and dome, so they will use new interface instead of old one

documentation of new interface in rts2.ini and affected processes