<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
PS: I've got an open fix to a ressource leak in pushover.cpp, if
you've been working on it, you can better integrate that as well:<br>
<br>
In SendMessageOpt(), the http and post ostringstreams won't get
deleted in the error branches.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 21.10.19 um 22:34 schrieb Michael
Balzer:<br>
</div>
<blockquote type="cite"
cite="mid:e0e78f35-e25d-f010-c826-e1e999513fa5@expeedo.de">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Marko,<br>
<br>
it's about saving RAM and CPU load, saving boot time and keeping
the processing queues as small as possible for the user
configuration. There should be no running tasks or registered
listeners if a service isn't activated, and buffers shouldn't be
preallocated etc.. Basically just the component resting in ROM,
waiting for activation by the user.<br>
<br>
But you're right, if the service has no permanent connection and
doesn't have a task or complex state, the explicit start/stop
scheme isn't strictly necessary and can be done implicitly by
listening to the config.<br>
<br>
Just take care to only register your notify reader once and reuse
the reader id on later reactivation. Reason: the notify registry
has no reusing mechanism but always allocates the next bit for a
new reader (and bits are limited).<br>
<br>
As a side note: if it's simply a https client wrapper, maybe the
manual send command shouldn't need an activated service at all?<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 21.10.19 um 21:51 schrieb Marko
Juhanne:<br>
</div>
<blockquote type="cite"
cite="mid:CAMmS7LpJSev=S3dtaech0-HuR9tTqBPC8SWpW20fv42F1bRUXQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div dir="ltr">Hi Michael,
<div><br>
</div>
<div>I've now made changes it so that sending notifications is
retried when connectivity is restored, and also made the
filtering smarter so that no unnecessary messages are
retained.</div>
<div><br>
</div>
<div>Before continuing with this service start/stop feature,
just wanted to make sure what is it we are trying to
accomplish. Is this to save memory and/or CPU cycles? I
mean, there is no persistent connection to the Pushover
service, but every notification/message is sent with a
separate connection. And there's also the "enable pushover
service" config to disable forwarding the notifications to
Pushover service. I could make it even faster/efficient via
deregistering the reader/event handler when the service is
disabled. <br>
</div>
<div><br>
</div>
<div>But I'm slightly tilted against to changing the Pushover
class to mimic OvmsServer (e.g. starting/stopping the server
by creating a separate instance), since then sending test
messages by console or web UI we need facilities to check if
server is running, and starting and stopping it on demand
via web UI and console etc.. IMHO this adds unnecessary
complexity, since Pushover class is basically just a https
client wrapper with a notification/event handler, the latter
which can be disabled easily.</div>
<div>But please correct me if I've overlooked something or if
you had something else in mind.</div>
<div><br>
</div>
<div>Best regards,</div>
<div>Marko</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Oct 19, 2019 at 1:41
PM Michael Balzer <<a href="mailto:dexter@expeedo.de"
moz-do-not-send="true">dexter@expeedo.de</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div> …or alternatively / additional to the pcp scheme
implement "start" & "stop" commands as shown by the
v2/v3 servers.<br>
<br>
<br>
<div>Am 19.10.19 um 12:38 schrieb Michael Balzer:<br>
</div>
<blockquote type="cite"> Marko,<br>
<br>
I guess you already saw my quick fix to the pushover
module. Failing to clear the "read" flag leads to
messages being held indefinitely by the notification
system.<br>
<br>
The fix is no real solution, as the current
implementation will drop messages being raised during a
network outage. A notify reader may use the "read" flag
to keep the messages on temporary loss of connectivity,
but it needs to retry sending itself. There is no
automatic re-delivery of messages. So you need to add
some flag telling the component to check for undelivered
messages, as is shown in the server v2 / v3 code.<br>
<br>
Also, as you're able to tell by your nice filter
mechanism if a notification should be sent to the
pushover service, you should check that filter already
in the filter callback. By doing so, messages without
actual readers won't be queued in the first place, so
that saves processing time and RAM.<br>
<br>
I was also surprised by the service running without
activation. The standard scheme for optional components
is to implement the "pcp" power control scheme and add
an AutoInit() integration.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div>Am 18.10.19 um 15:25 schrieb Michael Balzer:<br>
</div>
<blockquote type="cite"> The Pushover support isn't
enabled now in our default builds, because…<br>
<br>
a) MBEDTLS_PSK_MODES defaults to "no"<br>
b) MG_ENABLE_SSL also defaults to "no"<br>
c) OVMS_COMP_PUSHOVER would default to "yes" but
depends on a) + b)<br>
<br>
Should we set these to "yes" for the edge release now?<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div>Am 29.07.19 um 21:07 schrieb Marko Juhanne:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hello all,
<div><br>
</div>
<div>I've been wanting to have a bit more
configurable notification system on my mobile
phone compared to the OVMS mobile app (quiet
hours, different message priority levels,
override quiet hours with emergency priority,
custom sounds, persistent notifications
demanding acknowledgment etc). I already use
Pushover as notification platform for my home
automation system and it has worked nicely for
these two past years so I decided to port
Pushover client to OVMS as well.</div>
<div>
<div><br>
</div>
</div>
<div>For those who don't know, Pushover is a
notification platform that has apps for iOS and
Android. They also have a desktop (actually web)
application as well. You create an account and
then register your application. There's a 5 USD
per platform one-time fee, which I find quite
reasonable. Message limit is 7500 messages /
month / application. So if you have multiple
cars, you could register them as individual
applications. I'm not affiliated with the
company, just a happy customer.</div>
<div><br>
</div>
<div>There are now commits for Pushover support on
my fork (<a
href="https://github.com/mjuhanne/Open-Vehicle-Monitoring-System-3"
target="_blank" moz-do-not-send="true">https://github.com/mjuhanne/Open-Vehicle-Monitoring-System-3</a>).
It's up to date with the main branch, and has
the SWCAN commits as well. I would appreciate if
others could test it before making a pull
request, since there are now quite many
changes. I didn't want to add another http
client, so I used Mongoose. But then after
enabling SSL support using mbedssl I found out
that there's this client space "struct
mg_connect_opts" that will be too small (and
causes crash) if MG_ENABLE_SSL is not enabled
also in every component that uses Mongoose. </div>
<div><br>
</div>
<div>To configure Pushover, there's a new
Config/Notifications page on OVMS. You can
filter which notifications and events will be
relayed and select their priority levels
accordingly. I thought about using web config
pluging, but maybe we could integrate this page
to configure notifications for OVMS mobile apps
as well?</div>
<div><br>
</div>
<div>Best regards,</div>
<div>Marko Juhanne</div>
<div> <br>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com"
target="_blank" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>