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.
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, 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):
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:

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@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@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev



_______________________________________________
OvmsDev mailing list
OvmsDev@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