Hi Thomas,

Thank you for the interesting question.

This is not possible at present for maintenance purposes.
During maintenance, it can be important to know the state of the element and what caused the state of said element to change at what specific time.
If we were to "hide" this behind a log level, we would often miss out on crucial events during support.

Nevertheless, I do appreciate that it can be frustrating to see the rest of the logging disappear behind a wall of these state changes logs (and I am sure you are not the only one struggling with this).

For your case, I would be inclined to check the configuration of the element as it is not expected to have very frequent element state changes.
Especially, since very frequent state changes can result in a "blinking christmas-tree" like effect, where the element is not really useful for monitoring, rather it sits there, filling up the alarms database.
The idea is partly, that the frequency of the alarms can be managed through the connector or the alarm template (e.g. hysteresis).

If the software currently does not allow for sufficient fine-tuning to diminish the number of element state changes, so that they become manageable, please communicate the use-case, so we can review what is causing the element state changes and how we can manage them better.

Thank you in advance!