Not a bad idea. Will probably take some refactoring. The current scheme is for all STS datums to be (value, text) tuples. If text is "OK" all is OK. If not, the text should help pin down the problem. We haven't figured the "helpful text" part out yet.....

I've looked more closely at the master branch, to understand what's the current development status.

Right now, the ActorRules  class is forwarding to STS the keywords listed in config/STS.yaml .

But I don't see any reference to config/keywordAlerts.yaml, am i missing something ?

I thought there was a non-LAM specific ticket for the alertsActor design, but evidently there isn't. But I'll add a couple of the top design points here, because of the differences between Subaru and LAM.

• the alertsActor is the only source of alerts for PFS. There may be internal PFS keywords which signal alerts, but they cannot be used except by the alertsActor.
• the alertsActor contains no mechanism for propagating alerts via text/email/etc. All it does is generate alerts for some external communication package.
• At Subaru, STS is the package which handles alert propagation/display/masking. The channel between the alertsActor and STS is an internal TCP socket.
• Each alert generated by the alertsActor must have an associated MHS keyword. [details elsewhere]
• the alertsActor should only operate on MHS keywords (or the lack thereof). It cannot use the archiver.

Yoshida-san provide an image of the STS to the LAM team. They need to review it with Craig. This should be done before 10 Feb.

Design to accommodate STS still needs to be thought through.

cloomis and hassan to discuss together to break down into smaller tickets

To be discussed with cloomis during LAM visit early May

@cloomis: Need to read YAML file with threshold and apply those thresholds to generate STS keywords.

done and tested before SM1 shipping