Alert Summary Table: What am I missing?

I’ve created a bunch of SQLTags, I’ve set alarms on some of them. I have configured an Alert Storage Profile which seems to be working (lots of rows are been added to the db).

I’ve created the Alert Summary Table. I’ve bound the Alerts data to Tag history and select all available tags. (I now have 361 rows and 122 columns in the dataset)

But the table remains blank :scratch:

What am I missing?

Update:
I just found the Alert Log table. It looks like I should be binding to it, but it’s empty. I have set an alent on any change on a binary tag that is toggling every 2 seconds but still nothing is showing up :cry:

The alert status in Ignition is stored internally instead of in the database. You can get the status information out of Ignition with either the alert summary table component or the system.alert.queryAlertStatus() function.

You can also use your alert log table for alarm status by running a SQL query against it with a where clause that includes ‘CLEARED_TIMESTAMP is NULL’

[quote]I’ve created the Alert Summary Table. I’ve bound the Alerts data to Tag history and select all available tags. (I now have 361 rows and 122 columns in the dataset) [/quote]There isn’t really a link between History Tags and alarm history (except for the tag number). What are you trying to accomplish by joining these tables? Can you post the query so we can see why it is selecting no rows?

[quote="Robert.McKenzie"]The alert status in Ignition is stored internally instead of in the database. You can get the status information out of Ignition with either the alert summary table component or the system.alert.queryAlertStatus() function.
[/quote]
I'm trying to use the alert summary table but it's not showing me anything.
How would I use the system.alert.queryAlertStatus()?

ok, but this table is still empty. How does it get filled?

What I need is a how to guide. The docs explain what each property on the control is for. But I don't understand how to set it all up. What do I have to do to get the Alert Summary control to display all tags that are in alarm?

Update:
having read the manual on system.alert.queryAlertStatus(), I tried binding the example expression to the alert summary table. Alas, the function returned no rows. Does this mean that my alerting is not running?

I’ve sent an alert using the alert console and it showed up in the Alert Summary. So I guess my alerting system is working.

So why wouldn’t my tags be sending alerts? Does the (3rd party) SQL Tags driver have to send the alerts? I thought the SQLBridge module would read the tags and determine if an alert was required. This is not happening. Have I misconfigured my alerts? What should I check?

It appears that what I am missing is that the tags are been driven by an external driver. Currently when you do that ignition expects the external driver to handle all the scaling/alerting/etc.

Colby is working on a fix for me so that things work as expected. :prayer: :prayer:

Currently my tags show good in the database but are stale (500) when displayed.

What causes a tag to be stale?

Staleness is calculated off of the sqlt_sci table. A scan class is stale if “nextexecution < lastexecution+staletimeout”.

I suspect that something isn’t updating the sqlt sci table correctly, OR there are multiple entries in that table for the same scan class instance, confusing the system.

Regards,

With the help of b5203 I have sorted out most of my issues.
The big thing I missed was when you configure the realtime SQL tags provider, you can change the Driver name. You have to change it to be the same as the driver name you use to build the tags. (case counts!)

With b5203 I have my alerts. I have my scaling. I still have to play with latin1 chars.
So far: :thumb_right: :thumb_left:

Excellent, thanks for the update.

Is there any viable reason as to why the alarmlog in fpmi was utf8 and now alert_log in Ignition is latin1??

I only ask because I have some queries like this:

SELECT
  IFNULL((SELECT B.batch_number
    FROM dbdaq.batches B
    WHERE B.line_id=LEFT(L.PATH, 3)
      AND B.t_stamp < L.active_timestamp
    ORDER BY B.t_stamp DESC
    LIMIT 1), 'N/A') as Batch,
  L.ALERT_LOG_ndx as NDX,
  L.PATH,
  L.state_name AS AlarmName,
  L.active_timestamp as ActiveTime
FROM dbdaq.ALERT_LOG L

Notice the nested SELECT with the "=LEFT(L.PATH, 3)
that now have to be like this:

SELECT
  IFNULL((SELECT B.batch_number
    FROM dbdaq.batches B
    WHERE B.line_id=CAST((LEFT(L.PATH, 3)) AS CHAR CHARACTER SET utf8)
      AND B.t_stamp < L.active_timestamp
    ORDER BY B.t_stamp DESC
    LIMIT 1), 'N/A') as Batch,
  L.ALERT_LOG_ndx as NDX,
  L.PATH,
  L.state_name AS AlarmName,
  L.active_timestamp as ActiveTime
FROM dbdaq.ALERT_LOG L

because i get an error of:

Will it cause problems if I change it to utf8?

Probably because of me? :smiling_imp:

I have been pestering the devs for i18n/latin1 support. And they have been try to keep me happy. I suspect that there should be no problems. You can also try converting the old utf8 to latin1 so future upgrade are not a problem.

is there any BENEFIT of latin1 over utf8?

We actually haven’t made any changes to the database queries that create tables, and don’t specifically specify the encoding. Therefore, I’d have to guess that perhaps you’ve changed databases between PMI and Ignition and the default table encoding has changed between mysql versions? Or the mismatch is due to backup/restores? At any rate, we don’t specify the encoding, so that hasn’t changed on our side.

Regards,

I appreciate it colby. So latin1 versus utf8, shouldn’t be a problem? no advantage/disadvantage from one to the other?

The only benefit would be if you are storing latin1 chars.

My experience with MySQL is that latin1_swedish_ci is the default language. It seemed strange to me until I realized where MySQL was developed. There is a setting in the config file somewhere that allows you to set the default language. I’m with Colby in thinking that this was set in your old db but not your new one.

Follow this link for more info http://dev.mysql.com/doc/refman/5.0/en/charset-syntax.html

I am using the alert summary table and have 1 boolean tag that is configured to alert on change of state. It never shows up in the alarm summary. How do i configure alarms with descriprions for each column in the summary. There does not seem to be any alarm configuration screen in Ignition like other programs have. Can i import a bunch of alarms at the same time with csv?

Thanks,
Ronnie

OK, I figured out that the gateway needs to be restarted after adding these tags. It is showing the alarm in the summary now, but i still do not know how to change the text. Do i need to export the tags to a csv file and somehow change the descriptions there? where is this info?

The gateway should not need to be restarted after adding alert tags. Is it possible that your alert status screen wasn’t set to show “cleared and unacknowledged” alerts? If you look at the properties of the alert status table, you’ll see there’s a “filter” section. At the top of that window, on the far right, is a filter button on the property list- if you switch that to “all”, you’ll see additional options, including other filters.

Alerts are configured on tags, and tags can be imported through CSV. A different post here recently talks about how the CSV format for alerts is a little difficult (it’s condensed into a single field of the CSV), so I don’t know how helpful it would be to try to configure them in CSV, but it could be done. We’re going to improve this soon.

One thing to note is that you can select multiple tags at once for editing, though of course that’s only useful if the states on each of them should be the same.

Let me know if I missed anything!

Regards,

normally I use these column headings for alarms:
Timestamp, Control Panel #, Area, Tag, and Description

I see where I can change the headings in the properties, but I don’t see where I can put this info for each alarm tag.

How do I get more descriptive alarm info?

Ah, I see. Unfortunately, right now it’s not possible to define your own custom alert properties like this. It will be possible in 7.3 (July/August), but currently, you only have access to a few pre-defined properties.

Regards,