<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><blockquote type="cite" class=""><div text="#000000" bgcolor="#FFFFFF" class="">I solved that for the Twizy by initializing to the empty state (key 0) and not setting the charge state until it actually changes.</div></blockquote><div class=""><br class=""></div>Really trying to avoid that. The idea of the metrics system was to just have the vehicle modules simply set the metric value, and have the metric system itself handle whether it was changed, unit conversion, etc.<div class=""><br class=""></div><div class="">Looking at the implementation, we have:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class="">public:</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class=""> OvmsMetric* m_next;</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class=""> const char* m_name;</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class=""> metric_unit_t m_units;</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class=""> std::bitset<METRICS_MAX_MODIFIERS> m_modified;</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class=""> uint32_t m_lastmodified;</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class=""> uint16_t m_autostale;</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class=""> bool m_defined;</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class=""> bool m_stale;</span></font></div></div></blockquote><div class=""><div><br class=""></div><div>I think all we would have to do is add a ‘bool m_firstdefined’, with appropriate logic. True the first time it is defined, but false for subsequent changes. Vehicle module can use this to not issue those charge notifications if firstdefined. Not sure about byte alignment on those m_defined and m_stale bools - they don’t seem optimal the way they are. I think we can probably do this with zero additional ram requirement.</div><div><br class=""></div><div><blockquote type="cite" class=""><div text="#000000" bgcolor="#FFFFFF" class="">Not sure if we can use external RAM for metrics.</div></blockquote><br class=""></div><div>I don’t see why not. I’ll have a look at it as part of this work.</div><div><br class=""></div><div>Regards, Mark</div><div><br class=""><blockquote type="cite" class=""><div class="">On 25 May 2018, at 3:39 PM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">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="">
<br class="">
<div class="moz-cite-prefix">Am 25.05.2018 um 04:25 schrieb Mark
Webb-Johnson:<br class="">
</div>
<blockquote type="cite" cite="mid:2F1E0E24-7D70-4EBF-AB53-093EAD46FCEB@webb-johnson.net" class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
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 class="">
OK.<br class="">
<br class="">
<blockquote type="cite" cite="mid:2F1E0E24-7D70-4EBF-AB53-093EAD46FCEB@webb-johnson.net" class="">
<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 class="">
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 class="">
<br class="">
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 class="">
<br class="">
Adding change counters just for this seems to be unnecessary
overhead. Not sure if we can use external RAM for metrics.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<blockquote type="cite" cite="mid:2F1E0E24-7D70-4EBF-AB53-093EAD46FCEB@webb-johnson.net" class="">
<div class="">Regards, Mark.<br class="">
<div class=""><br class="">
<div class="">
<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 class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
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 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="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></body></html>