<html><head></head><body><div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div></div>
<div>Hi Michael,</div><div>Thanks for that clarification!</div><div>I missed this from the discussion before and I am glad it is taken care of. </div><div><br></div><div>Nikolay</div><div><br></div>
<div id="yahoo_quoted_1742596443" class="yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Tuesday, November 21, 2017, 7:01:46 PM GMT+1, Michael Balzer <dexter@expeedo.de> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div id="yiv7122332189"><div>
Hi Nikolay,<br clear="none">
<br clear="none">
it's a central benefit of the message queue/broker scheme to be able
to hold messages until they have been transmitted. The broker can
also transparently put the message queue on SD card if necessary or
configured. So yes, that's both already taken into account.<br clear="none">
<br clear="none">
The broker scheme also solves the issue of losing state data when
connectivity comes back much later -- the message has been produced
& queued at the time the event occurred.<br clear="none">
<br clear="none">
Regards,<br clear="none">
Michael<br clear="none">
<br clear="none">
<br clear="none">
<div class="yiv7122332189moz-cite-prefix">Am 20.11.2017 um 00:10 schrieb Nikolay
Shishkov:<br clear="none">
</div>
<div class="yiv7122332189yqt5366799385" id="yiv7122332189yqt52319"><blockquote type="cite">
<div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;">
<div>Hi guys, </div>
<div><br clear="none">
</div>
<div>I have been using ovms units for logging of trip data and
have had some non-consistent experiences when the ovms box is
loosing data connections. </div>
<div>Are there any provisions for synchronization of messages
that have not been delivered due to connectivity problems?</div>
<div><br clear="none">
</div>
<div>Another even more interesting situation is if there is no
SIM in the module, so you go for a drive and when you come
home the ovms uses the wifi to sync all the messages and
data. </div>
<div>Or is this already handled? I am not sure I understand all
the stuff that some of you guys write.</div>
<div><br clear="none">
</div>
<div>Nikolay</div>
<div><br clear="none">
</div>
<div class="yiv7122332189yahoo_quoted" id="yiv7122332189yahoo_quoted_1247077396">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div> On Saturday, November 18, 2017, 4:44:58 PM GMT+1,
Michael Balzer <a rel="nofollow" shape="rect" class="yiv7122332189moz-txt-link-rfc2396E" ymailto="mailto:dexter@expeedo.de" target="_blank" href="mailto:dexter@expeedo.de"><dexter@expeedo.de></a> wrote: </div>
<div><br clear="none">
</div>
<div><br clear="none">
</div>
<div>
<div id="yiv7122332189">
<div> Hi Mark,<br clear="none">
<br clear="none">
apologies as well, I'm quite low on spare time
currently :-/<br clear="none">
<br clear="none">
I agree it's better to implement the message broker
directly, as adding it later on would need changes to
all listeners.<br clear="none">
<br clear="none">
ACK on your thoughts, except a) the fixed alert texts
and b) the message producing scheme.<br clear="none">
<br clear="none">
a) Providing default messages for standard alert types
is good, but replacing them with custom message text
should be possible. I.e. the charge alerts need to be
specific for the Twizy. (When using commands for
message generation this would automatically be handled
by the vehicle specific "stat" command implementation)<br clear="none">
<br clear="none">
b) The point I don't see in the scheme of vehicles
sending messages to the broker instead of "get my
message" events/calls: the car does not know about the
verbosity levels needed by the broker's subscribers.
That's why I think it's better to let the broker fetch
the messages than to have the producer send them to
the broker.<br clear="none">
<br clear="none">
Example: the car raises a custom alert. The car
implementation wants to add detail info to the basic
alert if possible.<br clear="none">
<br clear="none">
An SMS channel has subscribed to the broker with
verbosity=minimal (140), and for example a shell and
an ssh session (thanks, Steven!) each have subscribed
with verbosity=normal (1024). So the broker knows it
will need messages of both 140 and 1024 char
verbosity.<br clear="none">
<br clear="none">
The car now sends the "get my alert" event (or call to
the broker). The broker in turn requests the alert
message from the car twice, one variant tailored for
verbosity=140 and another for verbosity=1024. It then
queues & delivers the message variants to the
listeners according to their verbosity levels and
finally discards them.<br clear="none">
<br clear="none">
As the verbosity is already part of the ovms_command
callback API, all command implementations should take
care of the message length limitation anyway, so can
easily be used for alert and notification generation
as well.<br clear="none">
<br clear="none">
<br clear="none">
Regards,<br clear="none">
Michael<br clear="none">
<br clear="none">
<br clear="none">
<div class="yiv7122332189moz-cite-prefix">Am
10.11.2017 um 07:07 schrieb Mark Webb-Johnson:<br clear="none">
</div>
<blockquote type="cite"> </blockquote>
</div>
<div> Apologies for the delay in getting back to you on
this.
<div class="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">So, let’s break the
requirements down:</div>
<div class="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">
<ol class="yiv7122332189MailOutline"><li class="yiv7122332189">Metrics -> v2
messages</li><li class="yiv7122332189">Push notifications (car
-> server -> apps)</li><li class="yiv7122332189">Error notifications (car
-> server -> apps)</li><li class="yiv7122332189">Historical data
submissions (car -> server, and presumably
later server -> apps)</li></ol>
</div>
<div class="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">Let’s go through them one
by one.</div>
<div class="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189"><u class="yiv7122332189"><b class="yiv7122332189">1. Metrics -> v2
messages</b></u></div>
<div class="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189"><u class="yiv7122332189"><b class="yiv7122332189">2. Push notifications (car
-> server -> apps)</b></u></div>
<div class="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189"><u class="yiv7122332189"><b class="yiv7122332189">3. Error notifications
(car -> server -> apps)</b></u></div>
<div class="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189"><u class="yiv7122332189"><b class="yiv7122332189">4. Historical data
submissions (car -> server, and presumably
later server -> apps)</b></u></div>
<div class="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189"><u class="yiv7122332189"><b class="yiv7122332189">v3 approach</b></u></div>
<div class="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">However, reviewing the v2
code, we do need something more sophisticated. Some
examples:</div>
<div class="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">
<ul class="yiv7122332189MailOutline"><li class="yiv7122332189">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 clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
</li><li class="yiv7122332189">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 clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
</li><li class="yiv7122332189">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">There are two possible
implementations of this, once a producer send in a
message.</div>
<div class="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">
<ol class="yiv7122332189MailOutline"><li class="yiv7122332189">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="yiv7122332189">The message is
maintained and queued centrally. Subscribers
then receive notifications of changes.</li></ol>
</div>
<div class="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">
<ul class="yiv7122332189MailOutline"><li class="yiv7122332189">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="yiv7122332189">An error alert. Similar
to the previous one, we just want to queue the
alert code, data.</li><li class="yiv7122332189">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="yiv7122332189">A status update. In this
case, the command callback makes the most sense.</li></ul>
</div>
<div class="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">Regards, Mark.</div>
<div class="yiv7122332189"><br clear="none" class="yiv7122332189">
<div>
<blockquote class="yiv7122332189" type="cite">
<div class="yiv7122332189">On 5 Nov 2017, at
10:23 PM, Michael Balzer <<a rel="nofollow" shape="rect" class="yiv7122332189" ymailto="mailto:dexter@expeedo.de" target="_blank" href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>>
wrote:</div>
<br clear="none" class="yiv7122332189Apple-interchange-newline">
<div class="yiv7122332189"> </div>
</blockquote>
</div>
</div>
</div>
<div>
<div class="yiv7122332189"> Sorry, I missed to explain
my previous thoughts.<br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
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 clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
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 clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
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 clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
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 clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
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 clear="none" class="yiv7122332189">
<div class="yiv7122332189">
<ul class="yiv7122332189MailOutline"><li class="yiv7122332189">ovms_server_v2 has a
BufferedShell object as the transmit queue
anyway<br clear="none" class="yiv7122332189">
</li><li class="yiv7122332189">RT vehicle module
sends a “xrt log RT-BAT-C” send.data event</li><li class="yiv7122332189">ovms_server_v2 calls
the “xrt log RT-BAT-C” command</li><li class="yiv7122332189">The command executes
and populates BufferedShell with textual data.</li><li class="yiv7122332189">ovms_server_v2 flags
internally for pending transmission &
returns from signal handling<br clear="none" class="yiv7122332189">
</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 clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
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 clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
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 clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
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 clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
Regards,<br clear="none" class="yiv7122332189">
Michael<br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
<div class="yiv7122332189moz-cite-prefix">Am
05.11.2017 um 13:48 schrieb Mark Webb-Johnson:<br clear="none" class="yiv7122332189">
</div>
<blockquote class="yiv7122332189" type="cite"> </blockquote>
</div>
</div>
<div> For <a rel="nofollow" shape="rect" class="yiv7122332189" target="_blank" href="http://send.info/">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">If there are cases where
this is vehicle specific, then the <a rel="nofollow" shape="rect" class="yiv7122332189" target="_blank" href="http://send.info/">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">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="yiv7122332189">
<ul class="yiv7122332189MailOutline"><li class="yiv7122332189">RT vehicle module sends
a “xrt log RT-BAT-C” send.data event.</li><li class="yiv7122332189">ovms_server_v2 receives
that event, allocates a BufferedShell object,
calls the “xrt log RT-BAT-C” command.</li><li class="yiv7122332189">The command executes and
populates BufferedShell with textual data.</li><li class="yiv7122332189">The command returns the
data to ovms_server_v2.</li><li class="yiv7122332189">ovms_server_v2 retrieves
the textual data from BufferedShell, sends it on
it’s way, then frees the BufferedShell object.</li><li class="yiv7122332189">The event signal returns
back to RT vehicle module.</li></ul>
</div>
<div class="yiv7122332189">All the above is happening
on the stack of the RT vehicle module (remember that
commands are expensive, memory wise).</div>
<div class="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">My question is what does
this give us, vs:</div>
<div class="yiv7122332189">
<ul class="yiv7122332189MailOutline"><li class="yiv7122332189">RT vehicle module builds
the textual data to send. Then signals event
send.data, passing that const char* as the
parameter.</li><li class="yiv7122332189">ovms_server_v2 receives
the send.data event, send the const char* data
on it’s way, then returns.</li><li class="yiv7122332189">The RT vehicle module
gets back control, and completes.</li></ul>
</div>
<div class="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">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="yiv7122332189"><br clear="none" class="yiv7122332189">
</div>
<div class="yiv7122332189">Why not just send the data
with the signal? What is the advantage of the
command callback arrangement?</div>
<div class="yiv7122332189"><br clear="none" class="yiv7122332189">
<div class="yiv7122332189">Regards, Mark</div>
<div class="yiv7122332189"><br clear="none" class="yiv7122332189">
<div class="yiv7122332189">
<blockquote class="yiv7122332189" type="cite">
<div class="yiv7122332189">On 5 Nov 2017, at
5:39 PM, Michael Balzer <<a rel="nofollow" shape="rect" class="yiv7122332189" ymailto="mailto:dexter@expeedo.de" target="_blank" href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>>
wrote:</div>
<br clear="none" class="yiv7122332189Apple-interchange-newline">
<div class="yiv7122332189">
<div class="yiv7122332189">Some thoughts
about how to implement vehicle
notifications and data logging. Please
check & comment.<br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
Concept:<br clear="none" class="yiv7122332189">
- handle all unsolicited transmissions
from vehicles by commands<br clear="none" class="yiv7122332189">
- vehicle module signals event if a
transmission is due<br clear="none" class="yiv7122332189">
- … with event data = command line to
generate output<br clear="none" class="yiv7122332189">
- listeners retrieve the transmission
content by executing the command<br clear="none" class="yiv7122332189">
- queueing for async delivery is done by
the listeners (i.e. through BufferedShell)<br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
→ any shell command can be used for
transmissions<br clear="none" class="yiv7122332189">
→ all transmissions can also be generated
on the shell / by script<br clear="none" class="yiv7122332189">
→ all transmission output can be sent to
any channel<br clear="none" class="yiv7122332189">
→ data logging on SD can be done
transparently by the system<br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
Interactive consoles can output
unsolicited transmissions by event type<br clear="none" class="yiv7122332189">
according to the current log level.<br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
Events:<br clear="none" class="yiv7122332189">
"<a rel="nofollow" shape="rect" class="yiv7122332189" target="_blank" href="http://send.info/">send.info</a>"
→ send text notification<br clear="none" class="yiv7122332189">
"send.alert" → send text alert<br clear="none" class="yiv7122332189">
"send.data" → send data record (CSV,
content part of v2 MP)<br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
Scheme:<br clear="none" class="yiv7122332189">
MyEvents.SignalEvent("send.<type>",
"command [args]");<br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
Examples:<br clear="none" class="yiv7122332189">
MyEvents.SignalEvent("<a rel="nofollow" shape="rect" class="yiv7122332189" target="_blank" href="http://send.info/">send.info</a>",
"stat");<br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
MyEvents.SignalEvent("send.alert", "xrt
batt status");<br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
MyEvents.SignalEvent("send.data", "xrt
log RT-BAT-C");<br clear="none" class="yiv7122332189">
→ command output:<br clear="none" class="yiv7122332189">
H,RT-BAT-C,4,86400,1,1,4025,3675,4045,5,14,14,19,1<br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
Regards,<br clear="none" class="yiv7122332189">
Michael<br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
-- <br clear="none" class="yiv7122332189">
Michael Balzer * Helkenberger Weg 9 *
D-58256 Ennepetal<br clear="none" class="yiv7122332189">
Fon 02333 / 833 5735 * Handy 0176 / 206
989 26<br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
_______________________________________________<br clear="none" class="yiv7122332189">
OvmsDev mailing list<br clear="none" class="yiv7122332189">
<a rel="nofollow" shape="rect" class="yiv7122332189" ymailto="mailto:OvmsDev@lists.teslaclub.hk" target="_blank" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br clear="none" class="yiv7122332189">
<a rel="nofollow" shape="rect" class="yiv7122332189moz-txt-link-freetext" target="_blank" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br clear="none" class="yiv7122332189">
</div>
</div>
</blockquote>
</div>
<br clear="none" class="yiv7122332189">
</div>
</div>
<br clear="none" class="yiv7122332189">
<fieldset class="yiv7122332189mimeAttachmentHeader"></fieldset>
<br clear="none" class="yiv7122332189">
<pre class="yiv7122332189">_______________________________________________
OvmsDev mailing list
<a rel="nofollow" shape="rect" class="yiv7122332189moz-txt-link-abbreviated" ymailto="mailto:OvmsDev@lists.teslaclub.hk" target="_blank" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a rel="nofollow" shape="rect" class="yiv7122332189moz-txt-link-freetext" target="_blank" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
<div class="yiv7122332189yqt3424795164" id="yiv7122332189yqtfd50058"><br clear="none" class="yiv7122332189">
<pre class="yiv7122332189moz-signature">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
_______________________________________________<br clear="none" class="yiv7122332189">
OvmsDev mailing list<br clear="none" class="yiv7122332189">
<a rel="nofollow" shape="rect" class="yiv7122332189" ymailto="mailto:OvmsDev@lists.teslaclub.hk" target="_blank" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br clear="none" class="yiv7122332189">
<a rel="nofollow" shape="rect" class="yiv7122332189moz-txt-link-freetext" target="_blank" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br clear="none" class="yiv7122332189">
<br clear="none" class="yiv7122332189">
<br clear="none">
<fieldset class="yiv7122332189mimeAttachmentHeader"></fieldset>
<br clear="none">
<pre>_______________________________________________
OvmsDev mailing list
<a rel="nofollow" shape="rect" class="yiv7122332189moz-txt-link-abbreviated" ymailto="mailto:OvmsDev@lists.teslaclub.hk" target="_blank" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a rel="nofollow" shape="rect" class="yiv7122332189moz-txt-link-freetext" target="_blank" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
<br clear="none">
<pre class="yiv7122332189moz-signature">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
</div>
</div>
<div class="yiv7122332189yqt3424795164" id="yiv7122332189yqtfd04996">_______________________________________________<br clear="none">
OvmsDev mailing list<br clear="none">
<a rel="nofollow" shape="rect" ymailto="mailto:OvmsDev@lists.teslaclub.hk" target="_blank" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br clear="none">
<a rel="nofollow" shape="rect" target="_blank" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br clear="none">
</div>
</div>
</div>
</div>
</div>
</blockquote></div>
<br clear="none">
<pre class="yiv7122332189moz-signature">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div></div></div>
</div>
</div></div></body></html>