In previous versions you could make a custom message and imbed a tag value in that custom message.
I don’t see if you can do that in the new notification block in 7.6. It looks like just alarm states as there is no tag picker in the new method. Can you imbed a tag value in the message area of the new notification block?
Well, typically you’re going to want the value that caused the alarm, which is available via the {eventValue} property. Is that what you’re looking for?
This is what our messages typically look like now, are you saying we wont be able to do this anymore?
subject:
{86201/Location} Pressure Alarm
message:
Value = {[Value]}
Low Setpoint = {86201/APLOW}
High Setpoint = {86201/APHIGH}
Alarm State = {[State_Name]}
Alarm Status = {[Alarm_Type]}
First off, we have to clarify where things are happening, and where they’re defined, and what’s different than before:
Emails are sent by Email Notification Blocks. The block defines a subject and message. These are evaluated according to each alarm that is pass through them. The can reference properties of the event. Referencing tag values here probably wouldn’t make sense, because the tag value wouldn’t really apply to all of the different alarms coming through. Basically, it’s best to think of this message like the “default” alarm message in pre-7.6 version.
On the alarm you can define properties, including custom properties, which can be just about anything (and can reference tags, properties, etc), and in turn you could reference these in your notification block, if you wanted. HOWEVER…
There is also the idea of “extended configuration” properties, which is not fully implemented in the version that is currently up. These are properties on the alarm that are added by other systems. For email, there will be “Custom Subject” and “Custom Message” properties that will be added. If these are filled in, the email block will use them, otherwise they’ll use the default. When you upgrade and your alarms are converted, these properties are currently created- it’s just that they currently show up as associated data, since we haven’t connected the dots yet.
Ok, so long story short, everything will continue to work as it did before. It’s just that now you have more flexibility in defining the default message for an email notification profile.
Regards,
The “extended config” properties that I mentioned above will be available in the next update, which we’ll put up monday.
Regards,
[quote=“Colby.Clegg”]First off, we have to clarify where things are happening, and where they’re defined, and what’s different than before:
Emails are sent by Email Notification Blocks. The block defines a subject and message. These are evaluated according to each alarm that is pass through them. The can reference properties of the event. Referencing tag values here probably wouldn’t make sense, because the tag value wouldn’t really apply to all of the different alarms coming through. Basically, it’s best to think of this message like the “default” alarm message in pre-7.6 version.
On the alarm you can define properties, including custom properties, which can be just about anything (and can reference tags, properties, etc), and in turn you could reference these in your notification block, if you wanted. HOWEVER…
There is also the idea of “extended configuration” properties, which is not fully implemented in the version that is currently up. These are properties on the alarm that are added by other systems. For email, there will be “Custom Subject” and “Custom Message” properties that will be added. If these are filled in, the email block will use them, otherwise they’ll use the default. When you upgrade and your alarms are converted, these properties are currently created- it’s just that they currently show up as associated data, since we haven’t connected the dots yet.
Ok, so long story short, everything will continue to work as it did before. It’s just that now you have more flexibility in defining the default message for an email notification profile.
Regards,[/quote]
will these extended configuration properties be included in a csv export of a tag? currently, we just export out a tag folder, search and replace the devicename, then import back in and all of the alerting configuration for the device is correct. will things stay the same in that regard or will we now have to do some additional configuration with the new alerting system?
They’ll be included in the export. One small side note, which I know will draw some reaction: tag export has been switched to XML in 7.6. CSV will work for import, but XML was a much better format for representing the tag structure and new alarming. For what you described, it has almost no impact, you can still search/replace the device name as before.
Regards,