[Ovmsdev] Notifications concept draft

Stephen Casner casner at acm.org
Mon Nov 6 01:27:55 HKT 2017 

One question regarding the command-callback approach: the results will
depend on conditions being stable between the event and the callback.

                                                        -- Steve

On Sun, 5 Nov 2017, Michael Balzer wrote:

> Sorry, I missed to explain my previous thoughts.
>
> 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).
>
> 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).
>
> 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.
>
> 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.
>
> 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.
>
>   * ovms_server_v2 has a BufferedShell object as the transmit queue anyway
>   * RT vehicle module sends a "xrt log RT-BAT-C" send.data event
>   * ovms_server_v2 calls the "xrt log RT-BAT-C" command
>   * The command executes and populates BufferedShell with textual data.
>   * ovms_server_v2 flags internally for pending transmission & returns from signal handling
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
> Regards,
> Michael
>
>
> Am 05.11.2017 um 13:48 schrieb Mark Webb-Johnson:
> > For send.info <http://send.info>, 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.
> >
> > If there are cases where this is vehicle specific, then the send.info <http://send.info> 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.
> >
> > 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):
> >
> >   * RT vehicle module sends a "xrt log RT-BAT-C" send.data event.
> >   * ovms_server_v2 receives that event, allocates a BufferedShell object, calls the "xrt log RT-BAT-C" command.
> >   * The command executes and populates BufferedShell with textual data.
> >   * The command returns the data to ovms_server_v2.
> >   * ovms_server_v2 retrieves the textual data from BufferedShell, sends it on it's way, then frees the BufferedShell object.
> >   * The event signal returns back to RT vehicle module.
> >
> > All the above is happening on the stack of the RT vehicle module (remember that commands are expensive, memory wise).
> >
> > My question is what does this give us, vs:
> >
> >   * RT vehicle module builds the textual data to send. Then signals event send.data, passing that const char* as the parameter.
> >   * ovms_server_v2 receives the send.data event, send the const char* data on it's way, then returns.
> >   * The RT vehicle module gets back control, and completes.
> >
> >
> > 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.
> >
> > 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.
> >
> > Why not just send the data with the signal? What is the advantage of the command callback arrangement?
> >
> > Regards, Mark
> >
> >> On 5 Nov 2017, at 5:39 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
> >>
> >> Some thoughts about how to implement vehicle notifications and data logging. Please check & comment.
> >>
> >>
> >> Concept:
> >>  - handle all unsolicited transmissions from vehicles by commands
> >>  - vehicle module signals event if a transmission is due
> >>  - ... with event data = command line to generate output
> >>  - listeners retrieve the transmission content by executing the command
> >>  - queueing for async delivery is done by the listeners (i.e. through BufferedShell)
> >>
> >>  → any shell command can be used for transmissions
> >>  → all transmissions can also be generated on the shell / by script
> >>  → all transmission output can be sent to any channel
> >>  → data logging on SD can be done transparently by the system
> >>
> >> Interactive consoles can output unsolicited transmissions by event type
> >> according to the current log level.
> >>
> >> Events:
> >>  "send.info <http://send.info>"      → send text notification
> >>  "send.alert"     → send text alert
> >>  "send.data"      → send data record (CSV, content part of v2 MP)
> >>
> >> Scheme:
> >>  MyEvents.SignalEvent("send.<type>", "command [args]");
> >>
> >> Examples:
> >>  MyEvents.SignalEvent("send.info <http://send.info>", "stat");
> >>
> >>  MyEvents.SignalEvent("send.alert", "xrt batt status");
> >>
> >>  MyEvents.SignalEvent("send.data", "xrt log RT-BAT-C");
> >>  → command output:
> >>    H,RT-BAT-C,4,86400,1,1,4025,3675,4045,5,14,14,19,1
> >>
> >>
> >> Regards,
> >> Michael
> >>
> >> --
> >> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> >> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> >>
> >>
> >> _______________________________________________
> >> OvmsDev mailing list
> >> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
> >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> >
> >
> >
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.teslaclub.hk
> > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
>

More information about the OvmsDev mailing list