Hello,
I’m trying to visualize some alerts configured in OpenHistorian on Grafan panels. For each PMU I have two alerts related to the Frequency :
- high frequency : Signal PMU_Frequency greater than 50.2 Hz during more than 0.5 sec.
- Low frequency : Signal PMU_Frequency lower than 49.8 Hz during more than 0.5 sec.
In grafana, the alerts are diplayed with a red vertical bar. the problem comes from the fact that it is always the same description of the alert that is displayed in both cases (high or low frequency) : the description of the high frequency alert.
(Note : for the test I put in fact 49.98 HZ for the low treshold frequency and 50.02 Hz for the high treshold one).
On the test we can see that it is the description of the high threshold alert that is displayed when it should be the low one.
In OpenHistorian, the correct alert is displayed in Monitoring > View Alarm Status
Maybe this issue is due to the fact that in the DB both alerts (in alarm table) have the same TagName / SignalID / AssociatedMeasurementID values ? Only the ID and Description values are differents.
Thanks by advance for any help you could provide 
Regards
This is most likely an issue in your setup of the Alarm.
in the Alarm Table of the Database and the Historian. The SignalID should not be the same.
When you create the Alarm in the openHistorian manager you should use a unique Tag Name. Usually the one that gets generated automatically as you fill out the other fields works.
Hello,
Thank you for your reply. To create the alarms, I used the default process and let OpenHistorian generate all the values requiered. In made this actions
- I selected the signal (both two alerts high and low frequency are related to the frequency ; that’s why we have the same SignalID value in the DB. Because there’s only one Frequency signal related to a PMU ; I don’t know how to put a different SignalID for the two alerts related to the same PMU Frequency).
- I specified the operation : ‘greater than’ for high frequency alert ; lower than for the low one.
- I specified the alarm point, the hysteresis and the delay as well.
- I entered a specific Description for both
- I specified the criticity (the same for both alarms)
- I enabled the alerts then created the associated measurement.
Note that when we specified the Signal, The TagName is completed automaticaly. Because the Signal is unique for both alerts (frequency), the TagName proposed by OpenHistorian is the same : [ALARM_SEVERITY]:[PDC_NAME]![PMU_NAME]:FREQ
What surprised me is that OpenHistorian manager is showing the correct alarm in the monitoring > view alarm status panel. The problem is only in the description of the alarms that is show in Grafana Dashboard : the wrong one is shown).
I think (but need confirmation) that the problem is more with the management of alarms via annoations in Grafana; or their management by the OHSTAT DataSource connector in Grafana.
Regards
You are partially correct with regards to the Grafana datasource having the issue.
Generally the openHistorian Alarms consist of 2 signals or points. (1) the signal you are Alarming on (the same frequency in your case) and (2) a point to store the Alarm (naming based on the PointTag Field).
For retrieving the Alarm there are 2 different ways of doing it. The Manager (in monitoring > view alarm status) pulls the current alarms from memory. This means it does not care about the Tag name because it only needs to know whether the alarm is currently active.
Grafana on the other hand pulls the data from the stored point (or signal). This means if both of your alarms save to the same point Grafana won’t be able to distinguish between the two. Because there is no way for Grafana to know which description to grab it will just pick the first one (the high one in your case),
If you change the Point Tag in the Alarm setup to be unique this is resolved because then the alarms are saved as 2 separate signals meaning Grafana would be able to distinguish between the two. Note that this does not fix any instance of the Alarm going off in the past since these are already saved to the original point (or signal).
I suspect you found a bug in the Manager where we did not account for the possibility of 2 Alarms with the same severity and the same signal being set up. You should be able to get around this by manually renaming the PointTag to something unique (e.g. add _LOWER and _UPPER at the end)
Thank you for your very comprehensive response. I will do so and report if that works as expected.
Regards
I managed to create my alarms correctly. To do this I first tried to modify the Tag Name field in the manager by adding _UPPER and _LOWER to the existing alarms but it did not work: the TagName field is updated in the ALARM table, but not in the PointTag field of the MEASUREMENT table that refers to it. Besides, I noticed that in this table the SignalID field of the existing measurement is included in the AssociatedMeasurementID field of the ALARM table for both the _UPPER signal and the _LOWER signal (unless it is the reverse; I can no longer verify). One of them refers to the 2 measurements ; the other refers to any.
I then proceeded to delete all the records from the ALARM and MEASUREMENT tables in relation to these alarms and have them properly recreated from Manager; taking care to add _LOWER and _UPPER to the Tag Name from the first recording (so that the PointTag of the Measurement table is identical to the TagName of the ALARM table, renaming wouldn’t work after this first record).
The automatic generation of the Tag Name being very practical, could I suggest to complete the current template [SEVERITY]: [SIGNAL] by adding at least [OPERATION]?
Indeed, there is no interest in setting the same severity for the same operation with a different alarm point. On the other hand, we will often have to position for the same severity on the same signal on different operations.
But that’s just a suggestion
Anyway thank you for taking my remark into consideration.
Regards
