I’ve added an alarm to a Tag.
But how do I get a new line in my message (the text I type in “Display path” or “Custom message”? Now the text is 1 line while I want a couple of empty lines in my message.
\n Doesn’t work.
A little late, but I was trying to accomplish the same thing with SMS messages and found a solution so I figured I’d share. This only applies to the notification block inside of an alarm pipeline, not a custom message inside of the tag’s alarm configuration.
Create a script block in your pipeline and add the following:
event.set('newline', '\r\n')
Then in the notification block’s Message field you can add {newline} wherever you need a line break. For example:
[{eventTime|hh:mm:ss}]{newline}Alarm "{name}" at "{displayPath}" transitioned to {eventState}.
2 Likes
Thanks for this. I’m curious though - why does this work? Does using a {property} just escape the literal string interpretation of the message, while writing \r\n doesn’t?
That’s a great question and one I don’t have the answer to. My guess would be that the message field is stripped of invalid/unsupported characters or ignores escaped text before the {property} is evaluated.
1 Like
@wrooney thanks for the work around.
One problem I have run into is that Android SMS clients and iPhone SMS clients appear to behave differently.
- Android (Pixel 2 XL, Android 11) experiences the issue as described above, line breaks in the configured message are ignored and the text is displayed as one long line.
- iPhone (iPhone 12) however shows the line breaks as configured in the editor.
Moreover when the SMS notification was received on the iPhone was then forwarded from the iPhone to the Android phone, the same message, that shows properly, with line breaks, was displayed without line breaks on the Android phone. Forwarding an SMS notification from Android to iPhone showed the same disparity.
So, for the work-around to apply equally well to both I am left with the situation of having to to add {newline} where I want the line break and removing the actual line break in the text editor so that iPhones don't show double line breaks.
@Loek , @Cory.grube @wrooney can you confirm what type of phone you had the issues on (Android, iPhone, other)?
I suspect this is related to the end-of-line character sequence that ignition is using to send the text message and how it is interpreted differently by different SMS clients.
So, just spit-balling here... but is it possible that the developer was testing using iPhone only and that line breaks are implemented in the actual outgoing message using carriage-return '\r' only (Mac/Apple standard) instead of newline '\n' character (Unix/Linux/Android standard) standard or both '\r\n' (Windows Standard, but would presumably work for both Android and iPhone SMS clients).
Actually it appears that modern Apple OS's use newline '\n' as the end-of-line character sequence.
@PGriffith are you able to investigate/explain why the line breaks don't display correctly on Android SMS clients (tested on Android 11 and ignition 8.1.18) but do on iPhone clients? I suspect this is easily resolved by having Ignition use '\r\n' as the end-of-line character sequence for the outbound SMS message.
It's possible, certainly. Internally the message is built using \n, it looks like. If you enable acknowledgement, do the system-added messages space out correctly below your content?
You can try setting the alarm.Notification.Sms and child loggers to TRACE; you'll get some more information about the message processing/building.
Unfortunately setting the alarm.Notification.Sms and alarm.Notification.Sms.GatewayHook loggers to TRACE provides no additional output the log.
There is no option to enable acknowledgement in the notification profile (Twilio Account)... perhaps this issue is specific to the Twilio module?
Recognizing my own mistake I am enabling TRACE level logging for Twilio loggers.
Ah, well. You just said "SMS", so I went down the rabbit hole to find out what our Airlink SMS module does. Twilio's going to be a totally different code path.
Sorry as the SMS (Twilio account) was configured by others I sort of forgot there were multiple SMS implementations myself. Do you have any insight into the Twilio module code base, or is that entirely third party?
I'm running into real oddities where sometimes it (my Android phone) does recognize the line breaks and sometime it does not after minor tweaks to the message content. Output to the trace logger varies also. Can't detect a repeatable pattern just yet. I'll report back when I can.
twilio.TwilioNotificationProfile on TRACE should have logger.trace("Message evaluated to '{}'.", evaluated);, showing you what the expression valuation resulted in.
It does, sometimes... I was mainly watching wrapper.log and had some inconsistent and weirdly formatted output there
Gateway log viewer:
Wrapper.log
'. alarm-pipeline=X Test Pipeline - TB, project=[hidden], alarm-source=default/_Test-TB/TestBool/Alarm, alarm-name=Alarm are testing 4 lines
INFO | jvm 2 | 2022/10/14 16:14:44 | D [t.TwilioNotificationProfile ] [21:14:44]: Sending notification to '[hidden]'. alarm-pipeline=X Test Pipeline - TB, project=[hidden], alarm-source=default/_Test-TB/TestBool/Alarm, alarm-name=Alarm
Line 4: C vm 2 | 2022/10/14 16:14:44 | D [t.ConnectedTwilioAccount ] [21:14:44]: Sent SMS: Line 1: Hello we are testing 4 lines
In an unrelated matter, my telecom decided to filter my incoming SMS due to the unusual number of messaged received which put a damper on my trial and error testing. For now the {newline} work-around and removing all actual line breaks in the editor is providing consistent results I need, and trying to find rhyme or reason to the line break inconsistencies observed was not proving fruitful.
We'll be standing up some new gateways in the coming months and perhaps I'll revisit this then.
1 Like