<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    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">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>