<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="">For <a href="http://send.info" class="">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="">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><blockquote type="cite" class=""><div class="">On 5 Nov 2017, at 5:39 PM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">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="">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="">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="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></div></div></body></html>