[Ovmsdev] Notifications concept draft

Michael Balzer dexter at expeedo.de
Sun Dec 10 00:06:56 HKT 2017

Some application & V2→V3 transition notes on this:

  * "info" = free form text notifications, standard priority -- this is a new V3 type, mapped to class "I" push notifications
  * "alert" = free form text notifications, high priority -- this is the class "A" push notification
  * "error" = structured error notification (push class "E"), the message needs to be formatted as "<vehicletype>,<errorcode>,<errordata>"
  * "data" = historical data update, CSV structured as "<type>,<recordnumber>,<lifetime>,<data…>"

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.

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.

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

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.
→ 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

"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.

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…).

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.


Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20171209/21530e6b/attachment.htm>

More information about the OvmsDev mailing list