<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">Am 25.05.2018 um 04:25 schrieb Mark
      Webb-Johnson:<br>
    </div>
    <blockquote type="cite"
      cite="mid:2F1E0E24-7D70-4EBF-AB53-093EAD46FCEB@webb-johnson.net">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      Re-visiting this, we don’t seem to have done the ‘low SOC’
      notification yet. Should be quite simple, so I will handle this.</blockquote>
    <br>
    OK.<br>
    <br>
    <blockquote type="cite"
      cite="mid:2F1E0E24-7D70-4EBF-AB53-093EAD46FCEB@webb-johnson.net">
      <div class="">We’re also not handling the module reset correctly
        and issuing charge notifications when the module starts up. This
        is more tricky. Should we just suppress all notifications within
        the first N seconds after boot-up (to give the vehicle modules
        time to set things correctly). Or should we only notify if this
        is not the first time the value has been set (add a modification
        count to the base metric system so we can see how many times the
        value has been modified)?</div>
    </blockquote>
    <br>
    I solved that for the Twizy by initializing to the empty state (key
    0) and not setting the charge state until it actually changes.<br>
    <br>
    If the reset happens during a charge, I get a new charge start
    notification, but that is OK as it also informs me that the charge
    monitoring had a reset and could not record the full process. If
    that would be suppressed, I would need a dedicated "I crashed"
    notification.<br>
    <br>
    Adding change counters just for this seems to be unnecessary
    overhead. Not sure if we can use external RAM for metrics.<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <blockquote type="cite"
      cite="mid:2F1E0E24-7D70-4EBF-AB53-093EAD46FCEB@webb-johnson.net">
      <div class="">Regards, Mark.<br class="">
        <div class=""><br class="">
          <div>
            <blockquote type="cite" class="">
              <div class="">On 25 Apr 2018, at 2:45 PM, Michael Balzer
                <<a href="mailto:dexter@expeedo.de" class=""
                  moz-do-not-send="true">dexter@expeedo.de</a>>
                wrote:</div>
              <br class="Apple-interchange-newline">
              <div class="">
                <meta http-equiv="Content-Type" content="text/html;
                  charset=utf-8" class="">
                <div text="#000000" bgcolor="#FFFFFF" class=""> We can
                  also add the "sufficient SOC/range reached"
                  notifications, the low SOC alert and the low 12V alert
                  to the framework.<br class="">
                  <br class="">
                  Porting the low 12V detection is on my list for
                  today/tomorrow. For the sufficient SOC/range
                  notifications, I currently still (mis-)use the topoff
                  state, which is irritating to users.<br class="">
                  <br class="">
                  Notification config should include a channel selection
                  for each, so users can choose which of them to get by
                  SMS. May be combinable, i.e. instead of a bool, use a
                  set of ("ip", "sms")?<br class="">
                  <br class="">
                  Regards,<br class="">
                  Michael<br class="">
                  <br class="">
                  <br class="">
                  <div class="moz-cite-prefix">Am 25.04.2018 um 03:13
                    schrieb Mark Webb-Johnson:<br class="">
                  </div>
                  <blockquote type="cite"
                    cite="mid:53F5886B-6F46-42F9-B7BB-6B23D9D19B44@webb-johnson.net"
                    class="">
                    <meta http-equiv="Content-Type" content="text/html;
                      charset=utf-8" class="">
                    It is time to implement vehicle notifications
                    (charge started, charge completed, charge
                    interrupted, etc) in the vehicle modules I am
                    supporting. It seems that this can be done in the
                    vehicle.{h,cpp} framework in a standard manner, and
                    work across all vehicle types. However, I guess that
                    will break any notifications already being produced
                    by other vehicle types.
                    <div class=""><br class="">
                    </div>
                    <div class="">My suggestion is:</div>
                    <div class=""><br class="">
                    </div>
                    <div class="">
                      <ol class="MailOutline">
                        <li class="">A config parameter ‘notifications’,
                          with individual instances to turn on/off the
                          notifications. Default is all enabled.<br
                            class="">
                          <br class="">
                        </li>
                        <li class="">OvmsVehicle::MetricModified picks
                          up metric changes and issues the standard
                          notifications (checking ‘notifications’
                          parameter appropriately).</li>
                        <ul class="">
                          <li class="">charge_mode=>charging: Notify
                            charge started</li>
                          <li class="">charge_mode=>topoff: Notify
                            charge started</li>
                          <li class="">charge_mode=>heating: Notify
                            battery heating started</li>
                          <li class="">charge_mode=>done: Notify
                            charge completed</li>
                          <li class="">charge_mode=>stopped: Notify
                            charge interrupted</li>
                          <li class="">valet_mode=>on: Notify valet
                            mode enabled</li>
                          <li class="">valet_mode=>off: Notify valet
                            mode disabled</li>
                          <li class="">alarm=>on: Notify alarm is
                            sounding</li>
                          <li class="">alarm=>off: Notify alarm is
                            off<br class="">
                            <br class="">
                          </li>
                        </ul>
                        <li class="">All the above should be suppressed
                          for the initial setting of each parameter. I
                          will have to look into metrics to see how best
                          that should be done; one neat way is to keep a
                          modification count (rather than the current
                          m_defined boolean).</li>
                      </ol>
                    </div>
                    <div class=""><br class="">
                    </div>
                    <div class="">Does that make sense? Any
                      objections/suggestions?</div>
                    <div class=""><br class="">
                    </div>
                    <div class="">Regards, Mark</div>
                    <div class=""><br class="">
                    </div>
                    <br class="">
                    <fieldset class="mimeAttachmentHeader"></fieldset>
                    <br class="">
                    <pre class="" 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 class="">
                  <pre class="moz-signature" cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
                </div>
                _______________________________________________<br
                  class="">
                OvmsDev mailing list<br class="">
                <a href="mailto:OvmsDev@lists.openvehicles.com" class=""
                  moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
                  class="">
                <a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
                  class="">
              </div>
            </blockquote>
          </div>
          <br class="">
        </div>
      </div>
      <!--'"--><br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <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>