I also made the following improvements:

• Added a ThresholdHandler class to handle much of the work of ESS-based rules.
• Simplified the concrete filtered topic wrappers, making them specific to the ESS (they were more general than necessary).

In future work I hope to write a class to publish data for ESS alarm rule unit tests. Until then I'm only using multi-channel temperature topics because it's too much work to write a mix of those and humidity sensor temperatures (especially when picking a random value to be the pessimistic value).

Pull request: https://github.com/lsst-ts/ts_watcher/pull/42

Reviewed in GitHub. Impressive work!

I made the suggested updates (thanks for catching those). Jenkins is failing due to the known issue that ts_sal and ts_xml don't agree with each other but tests pass locally.

Release awaits ts_xml 10.1. I'll use DM-32270 for the releases

Regarding hysteresis, I do agree with need to include this whenever the alarm produces an action such as disabling the hexapod. Otherwise you can get excessively cycling. However, for a warning where no action is taken excessive cycling should not result and there is no real need to account for hysteresis. There is no real problem with a warning going on and off. Accounting for the hysteresis doesn't really cause any problems either so if you want to that is fine also.

I think even cycling of warnings will annoy the operators and make them stop paying attention. In any case I use one hysteresis value for all threshold levels, to simplify configuration.

Note: I have updated all ESS-based rules to allow specifying 3 thresholds: warning, serious, and critical. My assumption is that we will configure at most two of those levels (leaving the others unused). This allow us to make highest severity serious or critical by changing the configuration, which gives maximum flexibility. I am writing the configurations on DM-32495.