[Ovmsdev] Notifications concept draft

[Mark Webb-Johnson]

For 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 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> 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"      → 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", "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
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20171105/6a44fedb/attachment.htm>