<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Some application & V2→V3 transition notes on this:<br>
<ul>
<li>"info" = free form text notifications, standard priority --
this is a new V3 type, mapped to class "I" push notifications<br>
</li>
<li>"alert" = free form text notifications, high priority -- this
is the class "A" push notification<br>
</li>
<li>"error" = structured error notification (push class "E"), the
message needs to be formatted as
"<vehicletype>,<errorcode>,<errordata>"</li>
<li>"data" = historical data update, CSV structured as
"<type>,<recordnumber>,<lifetime>,<data…>"<br>
</li>
</ul>
Note that while "info" is a new notification class, clients &
Apps (should) already display them as standard notifications.
Basically a client shall display anything received as a push
notification to the user, the push class should only be used as an
optional indication for the message type and priority.<br>
<br>
V2 had a simple concept of enabling/disabling info notifications
(feature #14), but the type of a message was only known to the
module, clients had to guess it from the content.<br>
<br>
As the server treats all MP-0 messages as comma separated values,
and MP-0 does not provide any field encapsulation, notifications
cannot transport comma "," and newline (LF) characters. You don't
need to take care of that when sending text notifications, they will
automatically be transcoded replacing "," by ";" and LF by CR.
Clients can revert the transcoding of CR, but not ";". That's just a
limitation of the V2 protocol, V3 may allow unchanged transport of
arbitrary messages.<br>
<br>
This is not new to V3, just a reminder: stick to the GSM-7 character
set when creating text notifications that may be sent via SMS. GSM-7
has some (possibly surprising) limitations like not allowing
backslash "\" or degree "°" characters.<br>
→
<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/GSM_03.38#GSM_7-bit_default_alphabet_and_extension_table_of_3GPP_TS_23.038_.2F_GSM_03.38">https://en.wikipedia.org/wiki/GSM_03.38#GSM_7-bit_default_alphabet_and_extension_table_of_3GPP_TS_23.038_.2F_GSM_03.38</a><br>
<br>
<br>
"error" and "data" messages will not be transcoded but delivered as
submitted. You may use any structuring for the <data> field,
but it may not contain newline (LF) -- CR is allowed. Good style is
sticking to the CSV structure though, as this will make processing
the data easy for clients.<br>
<br>
In V2 you could send multiple data update rows at once (if you took
care not to exceed the CIPSEND limit depending on the cellular
network…).<br>
<br>
V3 does not allow multiple data rows in a single notification to be
able to track their successful delivery. If you need to send
multiple records at once, submit each as a single notification. The
Twizy battery monitor contains an example for this.<br>
<br>
<br>
Regards,<br>
Michael<br>
<br>
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>