<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Apologies for the delay in getting back to you on this.<div class=""><br class=""></div><div class="">We’re up to the stage now where we have to determine how best to implement this. The rest of the ovms_server_v2 stuff is pretty much done.</div><div class=""><br class=""></div><div class="">So, let’s break the requirements down:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">Metrics -> v2 messages</li><li class="">Push notifications (car -> server -> apps)</li><li class="">Error notifications (car -> server -> apps)</li><li class="">Historical data submissions (car -> server, and presumably later server -> apps)</li></ol></div><div class=""><br class=""></div><div class="">Let’s go through them one by one.</div><div class=""><br class=""></div><div class=""><u class=""><b class="">1. Metrics -> v2 messages</b></u></div><div class=""><br class=""></div><div class="">I think this works pretty much ok at the moment. The metrics have modified flags, and ovms_server_v2 (and others) can get notified whenever a metric is modified. We can either issue the update immediately, or delay it for later transmission.</div><div class=""><br class=""></div><div class="">The way we do it at the moment in ovms_server_v2 is to delay until the next poll. I think that should be ok. 99% of the time, if a bunch of metrics are updated, they’ll all make it into the same update. If not, it shouldn’t do too much harm (just client app screen will get two updates, rather than one). For ovms_server_v3, most likely these are going to go out immediately, via MQTT, as they are changed.</div><div class=""><br class=""></div><div class=""><u class=""><b class="">2. Push notifications (car -> server -> apps)</b></u></div><div class=""><br class=""></div><div class="">In v2, these are fixed strings sent by net_msg_alert() - but originally raised by net_req_notification(). It is a simple bit - set it and at some time later the alert will be sent then the bit cleared. It seems that the twizy vehicle also manually sends push alerts as well.</div><div class=""><br class=""></div><div class="">For v3, I think we need something similar. The ability to queue a notification message (with a timeout would be helpful) and have it delivered as a push notification. I suggest we have standardised message types, plus the ability to send any custom string. It would be good to de-duplicate based on the message type, and rate limit.</div><div class=""><br class=""></div><div class=""><u class=""><b class="">3. Error notifications (car -> server -> apps)</b></u></div><div class=""><br class=""></div><div class="">In v2, these are (code,data) sent by net_msg_erroralert() - but originally raised by net_req_notification_error(). There is some logic (that doesn’t work very well) to try to stop duplicate (repetitive) alerts, but essentially it is implemented by setting a code, and at some time later the error notification will be sent then the code cleared.</div><div class=""><br class=""></div><div class="">For v3, I think we need something similar. I think this can be merged in with push notifications, as it is pretty similar. It is also interesting how we can deal with OBDII DTCs, as they seem to have a similar requirement.</div><div class=""><br class=""></div><div class=""><u class=""><b class="">4. Historical data submissions (car -> server, and presumably later server -> apps)</b></u></div><div class=""><br class=""></div><div class="">In v2, the logging.{h,c} module provides functions to put a log message into the queue, and then is polled by the net framework to send outstanding log messages. It seems that the Twizzy vehicle also manually send historical data submissions as well.</div><div class=""><br class=""></div><div class="">For v3, I think we need to make a generic module to handle this. Something that can queue a message, and have it reliably delivered at some later point in time.</div><div class=""><br class=""></div><div class=""><u class=""><b class="">v3 approach</b></u></div><div class=""><br class=""></div><div class="">I think that we can do something along the lines of what you are suggesting, but that all three should fit into a standardised structure and queueing mechanism.</div><div class=""><br class=""></div><div class="">Looking through the way things were done in v2, and what we now know we need, I suggest that overloading the events system is not necessary. On the producer side, we can simply have commands to raise these alerts/error/historical-data. On the custom consumer side, we expose it to scripts very simply.</div><div class=""><br class=""></div><div class="">However, reviewing the v2 code, we do need something more sophisticated. Some examples:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">We really need to de-duplicate and/or rate-limit notifications. Particularly Error notifications. Sometimes the car goes crazy and outputs multiple alerts (not always the same code), and those get delivered as a stream of annoying push notifications. We need something like syslog in unix - where rather than giving you 1,000 lines saying the same thing, it says something like “1,000 copies of X were raised”.<br class=""><br class=""></li><li class="">It would be good to have timeouts, and possibly time stamps. Sometimes you have no connectivity, then five hours later when it comes back you get an alert that charging was interrupted. It would be good to have a timeout on a message (don’t bother to send it if it can’t be sent in the next 5 minutes), and timestamps (so if message is not sent in realtime, when it is actually sent, it has a timestamp added to show when).<br class=""><br class=""></li><li class="">We need more reliable delivery. Historical data has ACKs for this. I think for PUSH, we can do something similar, using v2 protocol PINGs. The car can send the push notification, followed by a v2 ping. If it gets an ack, it can assume the notification message was received.</li></ul></div><div class=""><br class=""></div><div class="">The ESP32 platform has plenty of power for this. We just need to be careful with RAM usage. Perhaps we can overflow to flash, if necessary? Anyway, that can be hidden inside the specific implementation.</div><div class=""><br class=""></div><div class="">There are two possible implementations of this, once a producer send in a message.</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">Each subscriber gets a copy of that message, and is responsible for all the above maintenance as well as queueing for delivery.</li><li class="">The message is maintained and queued centrally. Subscribers then receive notifications of changes.</li></ol></div><div class=""><br class=""></div><div class="">Implementation #2 is my preference. Having a centralised middle queue between the publishers and subscribers means we only need to queue once. Rather than each subscriber having to handle its own queueing. Given the RAM constraints, I really think this is the best approach. We’ve already done something similar for metrics, and that is very frugal on RAM for the modification monitors.</div><div class=""><br class=""></div><div class="">Regarding the method of gathering the data to send, I think we can be flexible. Support fixed IDs, static text, and callback commands (just a type+data storage structure). When the subscriber calls the method to retrieve the actual data, the centralised approach retrieves the data and returns it to that specific subscriber. Some examples:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">An alert that charging has been interrupted. We just want to queue it using a pre-defined fixed type (associated with a fixed message). We don’t need command callback, or anything more complex.</li><li class="">An error alert. Similar to the previous one, we just want to queue the alert code, data.</li><li class="">A piece of historical data. In most cases, the data is a textual string that is just queued when it is raised (for example, a drive log).</li><li class="">A status update. In this case, the command callback makes the most sense.</li></ul></div><div class=""><br class=""></div><div class="">Does that meet your requirements? I don’t mind taking on the implementation of the central queue code. The ovms_server_v2 should be simple.</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 5 Nov 2017, at 10:23 PM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
Sorry, I missed to explain my previous thoughts.<br class="">
<br class="">
First of all, this is not about atomic updates of single metrics,
those can be done completely independant of the vehicle
implementation through the metrics system. This is about text
notifications/alerts and pushing structured data/logging objects
(historical messages).<br class="">
<br class="">
Most of my push notifications, alerts and data updates are vehicle
specific, and most do already have a "pull" command interface as
well. For example the output of "power report" will also be sent as
the trip efficiency notification after a drive, and "batt status" is
used for the battery alert. Just like the standard "stat" command is
also used by the "charge" notifications (just with slightly
different content on the Twizy).<br class="">
<br class="">
I think that's a pattern, as most textual status command outputs
will be usable for notifications and alerts as well. So generalizing
this was the main idea. I don't know if using the commands for
scripting and logging does offer an advantage, just added that as
another potential benefit.<br class="">
<br class="">
Automatic notifications on metrics change would require all metrics
updates to be organized so that the "trigger" metric is updated
after all other metrics required by a message. So the vehicle
developer always needs to be aware of this implicit logic. Also a
vehicle module may find it necessary to send a notification
independant of the value change for the "trigger" metric.<br class="">
<br class="">
Independant of the signal source (event/metric), transmissions of
any type cannot be done synchronously in any listener, both because
it would be executed in the sender context and because any
transmission channel needs to cope with temporary connection losses,
so needs to queue the data anyway. So the "send" event listeners
should always just fetch and queue the message during event
handling. I.e.<br class="">
<div class="">
<ul class="MailOutline">
<li class="">ovms_server_v2 has a BufferedShell object as the
transmit queue anyway<br class="">
</li>
<li class="">RT vehicle module sends a “xrt log RT-BAT-C”
send.data event</li>
<li class="">ovms_server_v2 calls the “xrt log RT-BAT-C” command</li>
<li class="">The command executes and populates BufferedShell
with textual data.</li>
<li class="">ovms_server_v2 flags internally for pending
transmission & returns from signal handling<br class="">
</li>
</ul>
</div>
If many such channels turn out to exist in parallel, a message
broker may step in place for the queueing. The LogBuffers class
already has a producer/consumer pattern, so the broker could manage
the buffers for all channels.<br class="">
<br class="">
The major problem I see with sending the data with the signal is a
conflict with the verbosity concept: at the time of the signal
creation, the sender is not aware of the verbosity required for the
individual listeners. So the sender would need to fill a message
structure containing variants for all verbosity levels for any
notification, which may be unnecessary overhead for most cases.<br class="">
<br class="">
That is, unless we drop the verbosity concept for unsolicited
messages. It may be irrelevant for notifications and alerts, it sure
is for data? An SMS channel for example can use just as much
characters as fit, as notifications and alerts will normally contain
the most important info at the beginning.<br class="">
<br class="">
The minor problem I see is again the additional memory needed -- as
the channels will need to buffer the message anyway, the sender can
write directly to the buffer. That's minor, the memory would just be
needed for the signal transport.<br class="">
<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 05.11.2017 um 13:48 schrieb Mark
Webb-Johnson:<br class="">
</div>
<blockquote type="cite" cite="mid:3CA04D7E-E6A1-44E0-9409-2B998DB4EFF0@webb-johnson.net" class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
For <a href="http://send.info/" class="" moz-do-not-send="true">send.info</a>,
I think it would be much better if the ovms_server_v* code could
work out for itself what needs to be sent. Have a look at
MetricModified() that I’ve just committed, as a starting point.
(Sorry, I’d started work on that last night, but hadn’t committed
yet. Done now.) Suggestion is to put the logic on ovms_server_v*
MetricModified() rather than the individual vehicle modules.
Things like if the car is turned on we should notify the apps, are
universal.
<div class=""><br class="">
</div>
<div class="">If there are cases where this is vehicle specific,
then the <a href="http://send.info/" class="" moz-do-not-send="true">send.info</a> mechanism you suggest is
ok; but I still think it better we don’t do this. Remember
ovms_server_v3 is going to work differently (individual metrics,
rather than groups). So, for vehicle specific cases (in
particular for metrics not in metrics_standard.h) this approach
is fine, but for standard metrics I suggest we use
MetricModified() in ovms_server_v2.</div>
<div class=""><br class="">
</div>
<div class="">I like the idea of using events for send.alert and
send.data. But not sure of the purpose of a command feedback for
this. From what I can see, this means (for example):</div>
<div class="">
<ul class="MailOutline">
<li class="">RT vehicle module sends a “xrt log RT-BAT-C”
send.data event.</li>
<li class="">ovms_server_v2 receives that event, allocates a
BufferedShell object, calls the “xrt log RT-BAT-C” command.</li>
<li class="">The command executes and populates BufferedShell
with textual data.</li>
<li class="">The command returns the data to ovms_server_v2.</li>
<li class="">ovms_server_v2 retrieves the textual data from
BufferedShell, sends it on it’s way, then frees the
BufferedShell object.</li>
<li class="">The event signal returns back to RT vehicle
module.</li>
</ul>
</div>
<div class="">All the above is happening on the stack of the RT
vehicle module (remember that commands are expensive, memory
wise).</div>
<div class=""><br class="">
</div>
<div class="">My question is what does this give us, vs:</div>
<div class="">
<ul class="MailOutline">
<li class="">RT vehicle module builds the textual data to
send. Then signals event send.data, passing that const char*
as the parameter.</li>
<li class="">ovms_server_v2 receives the send.data event, send
the const char* data on it’s way, then returns.</li>
<li class="">The RT vehicle module gets back control, and
completes.</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">The only advantage for using commands, that I see,
is being able to test this easily as a developer. But given the
overhead, I can’t see the benefit outweighing the overhead.</div>
<div class=""><br class="">
</div>
<div class="">We could, of course, have commands for things like
PUSH notifications, that could be used by scripts. Or
alternatively, the script could just raise the event itself.</div>
<div class=""><br class="">
</div>
<div class="">Why not just send the data with the signal? What is
the advantage of the command callback arrangement?</div>
<div class=""><br class="">
<div class="">Regards, Mark</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 5 Nov 2017, at 5:39 PM, Michael Balzer
<<a href="mailto:dexter@expeedo.de" class="" moz-do-not-send="true">dexter@expeedo.de</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Some thoughts about how to implement
vehicle notifications and data logging. Please check
& comment.<br class="">
<br class="">
<br class="">
Concept:<br class="">
- handle all unsolicited transmissions from vehicles
by commands<br class="">
- vehicle module signals event if a transmission is
due<br class="">
- … with event data = command line to generate output<br class="">
- listeners retrieve the transmission content by
executing the command<br class="">
- queueing for async delivery is done by the
listeners (i.e. through BufferedShell)<br class="">
<br class="">
→ any shell command can be used for transmissions<br class="">
→ all transmissions can also be generated on the
shell / by script<br class="">
→ all transmission output can be sent to any channel<br class="">
→ data logging on SD can be done transparently by the
system<br class="">
<br class="">
Interactive consoles can output unsolicited
transmissions by event type<br class="">
according to the current log level.<br class="">
<br class="">
Events:<br class="">
"<a href="http://send.info/" class="" moz-do-not-send="true">send.info</a>" → send
text notification<br class="">
"send.alert" → send text alert<br class="">
"send.data" → send data record (CSV, content
part of v2 MP)<br class="">
<br class="">
Scheme:<br class="">
MyEvents.SignalEvent("send.<type>", "command
[args]");<br class="">
<br class="">
Examples:<br class="">
MyEvents.SignalEvent("<a href="http://send.info/" class="" moz-do-not-send="true">send.info</a>",
"stat");<br class="">
<br class="">
MyEvents.SignalEvent("send.alert", "xrt batt
status");<br class="">
<br class="">
MyEvents.SignalEvent("send.data", "xrt log
RT-BAT-C");<br class="">
→ command output:<br class="">
H,RT-BAT-C,4,86400,1,1,4025,3675,4045,5,14,14,19,1<br class="">
<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
-- <br class="">
Michael Balzer * Helkenberger Weg 9 * D-58256
Ennepetal<br class="">
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<br class="">
<br class="">
<br class="">
_______________________________________________<br class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.teslaclub.hk" class="" moz-do-not-send="true">OvmsDev@lists.teslaclub.hk</a><br class="">
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></body></html>