<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="">I’ve added UnregisterCommand() methods to ovms_command.{h, cpp}. I’ve also updated the vehicle_teslamodels code to UnregisterCommand in the destructor. I think that is cleaner. The unregistering of CAN buses already seems to be working properly, config parameters should persist (even without vehicle module loaded). I am still considering the situation with metrics (but tend to think that they should disappear when the vehicle module is unloaded).<div class=""><br class=""></div><div class="">I’ve also changed the vehicle_teslamodels code to use single voltage and temperate metric arrays (I think my previous dual voltage temperature arrangement was incorrect). I think these can now become standard metrics (one for battery voltage, and another for temperature). How about v.b.cell.voltage and v.b.cell.temp? The interpretation of those vectors (how many modules primarily - with the calculation of voltages and temperatures per module being dependent on the realtime size of each array) will still be vehicle dependent, and I guess the vehicle module can provide hints to our standard component for this. Perhaps we can just implement it in vehicle.{h, cpp}? I think this standard module can deal with:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">An interface for specific vehicle module to specify the number of modules, number of voltage measurements, and number of temperature measurements available.</li><li class="">Internal storage of cell voltages and temperatures.</li><li class="">Tracking of when all voltages and temperatures have been set, and these should be written to metrics (as a transaction).</li><li class="">Standardised command to display on terminal (like ‘xts bms’).</li><li class="">Web interface extensions (including the charting you have, a textual display, etc).</li></ul></div><div class=""><br class=""></div><div class="">I can handle all of the above, except the web interface. What do you think? Can these be standardised? Certainly for Tesla Roadster and Tesla Model S they appear to be able to be unified under one standard framework.</div><div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 8 Nov 2018, at 6:49 AM, 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="">
Mark,<br class="">
<br class="">
1) yes, we're approaching a generic form now. The chart currently
displays actual, min & max values from the arrays, and derives
the overall average value. It automatically adapts to the number of
voltages and temperatures stored in the arrays.<br class="">
<br class="">
It still lacks:<br class="">
a) Displaying max deviations, current standard deviation and max
standard deviation recorded.<br class="">
b) Displaying cell/module warn & alert status. These are
currently set metrics on the Twizy, could better be generalized as
arrays as well, i.e. 0=normal, 1=warn, 2=alert.<br class="">
c) SOH / capacity and internal resistance should be generally
available per cell as well (no data on these yet on the Twizy).<br class="">
<br class="">
And as this will visually overload the chart it will need some
buttons to show/hide the parts.<br class="">
<br class="">
A general vehicle base support for these metrics could automatically
keep min & max values, calculate deviations and derive
warn/alert status from these. So basically a vehicle adapter only
needs to provide voltages and temperatures (+ SOH and internal
resistance as available). The reset command then can also normally
just be a generalized version.<br class="">
<br class="">
2) I should add some basic documentation on this to the developer
manual (lacking time). For the RE tools I've got an API to inject
arbitrary data into the websocket stream on my todo list, so live
updates can be transported without polling.<br class="">
<br class="">
4) Interesting idea, similar to a reverse proxy. As the channel will
be very slow we will need to reduce the websocket update frequency,
make it configurable or maybe auto-adapt to the current speed. Also,
the proxy should cache static assets to speed up first time
connects.<br class="">
<br class="">
The v2 protocol using RC4 encryption is a bad base for this. What's
the current encryption on v3/MQTT?<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 07.11.18 um 01:50 schrieb Mark
Webb-Johnson:<br class="">
</div>
<blockquote type="cite" cite="mid:148E5D80-BC17-4A37-9EE6-ABF3D756DF5C@webb-johnson.net" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class="">Some questions/comments:</div>
<div class=""><br class="">
</div>
<ol class="MailOutline">
<li class="">I guess this is fairly generic. Voltages and
temperatures, with possibly a different number of readings for
each. Model S has two temperatures, but I guess we can just
treat those as interleaved. Could it be put into a reusable
component? Or could we have standard metrics for this now
(battery module voltages and temperatures)? Maybe a single
component that does all this (functions to set individual
voltages and temperatures, define the layout for display,
include web interface for chart and table, etc)?<br class="">
<br class="">
</li>
<li class="">I really need to look at integration of extensions
to the web interface. See how that is done. For my work on DBC
and RE tools, it seems easiest to just create a web interface
(rather than messing around with command line).<br class="">
<br class="">
</li>
<li class="">Regarding the registration of commands and metrics,
I am not sure if that is done correctly at the moment. In
particular in the case a vehicle module is loaded, unloaded,
then loaded again. It seems that RegisterCommand doesn’t do it
right, and the metric object creation needs a guard to make
sure the metric doesn’t already exist. I will try to tidy this
up in Model S code, as a reference, before moving on to
Roadster.<br class="">
<br class="">
</li>
<li class="">I really haven’t used the web interface much, as it
is not available over cellular. I was wondering if it could be
encapsulated somehow within the v2/v3 protocol, and made
available via the server? Something like <a href="https://api.openvehicles.com:8080/VEHICLEID" class="" moz-do-not-send="true">https://api.openvehicles.com:8080/VEHICLEID</a> tunnelled
through (with authentication at the server level using the
normal web server user account). Similarly for SSH access.
These are both simple tcp/ip connections, so presumably could
be injected into mongoose as fake connections. One possible
approach would be SOCKS, and there is some <a href="https://github.com/russdill/lwip/commit/dfeba616" class="" moz-do-not-send="true">reference code for LWIP</a>.
Another is TUN/TAP, again with <a href="https://github.com/russdill/lwip/commit/47ca42f8" class="" moz-do-not-send="true">reference code for LWIP</a>.
And then there is the standard PPP (although that would
technically then be PPP within tcp/ip over PPP within async
within GSM, which is a bit freaky).</li>
</ol>
<div class="">
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 7 Nov 2018, at 4:52 AM, 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=""> Mark,
Tamás,<br class="">
<br class="">
I've prepared a more or less generalized array version
of my Twizy battery chart
(OvmsVehicleRenaultTwizy::WebBattMon) for you. Easier to
collect the data from actual arrays than separate
metrics.<br class="">
<br class="">
This ZIP…<br class="">
<br class="">
<tt class=""><a class="moz-txt-link-freetext" href="https://dexters-web.de/f/ovms-dev/ovms.zip" moz-do-not-send="true">https://dexters-web.de/f/ovms-dev/ovms.zip</a></tt><br class="">
<br class="">
…contains my local ovms web test/development folder.
Unzip it into some local web server (needs to be run via
http for javascript), then open the folder from a
browser. You should see an OVMS web UI lookalike.<br class="">
<br class="">
Config → CellChart loads "cellchart.htm". The blue
button generates and injects test data. Should look like
this:<br class="">
<br class="">
<span id="cid:part2.4D578815.899B8026@expeedo.de" class=""><eoibkbnkbpofdlab.png></span><br class="">
<br class="">
Assuming you'll add some min/max records as well I left
that code including the reset button in there. If you
can't provide that yet, you can simply set min & max
= act in the get_xxx_data functions. Other than that you
should basically just need to change the metrics names.<br class="">
<br class="">
To generate C/C++ syntax from the file, use the script
bin/mksrc: "bin/mksrc cellchart.htm >cellchart.cpp".
The chart init URL needs to be changed for the
production environment (see comment), and the test data
generator can be removed. See
OvmsVehicleRenaultTwizy::WebBattMon for reference.<br class="">
<br class="">
Maybe I should add that stuff to the repository as well…<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 06.11.18 um 15:56
schrieb Mark Webb-Johnson:<br class="">
</div>
<blockquote type="cite" cite="mid:A3E51D64-D302-4DA6-8C8C-F170B87D445D@webb-johnson.net" class="">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8" class="">
<div dir="ltr" class="">Nice. I just implemented this
for Model S using your new metric type.</div>
<div dir="ltr" class=""><br class="">
</div>
<div dir="ltr" class="">96 individual brick voltages
for each of the bricks, plus two temperatures for
each of the 16 modules.</div>
<div dir="ltr" class=""><br class="">
</div>
<div dir="ltr" class="">Works well.</div>
<div dir="ltr" class=""><br class="">
</div>
<div dir="ltr" class=""><br class="">
</div>
<div dir="ltr" class=""><br class="">
</div>
<div dir="ltr" class=""><span style="-webkit-tap-highlight-color:
rgba(0,
0, 0, 0);" class=""><br class="">
</span>On 1 Nov 2018, at 5:58 PM, Michael Balzer
<<a href="mailto:dexter@expeedo.de" moz-do-not-send="true" class="">dexter@expeedo.de</a>>
wrote:<br class="">
<br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
Tamás,<br class="">
<br class="">
I've been creating separate metrics for all cell
values on the Twizy, but that only has 14 cells.<br class="">
<br class="">
We discussed this before, a better approach is
introducing a new metric class for arrays. I have
just done that for you, please pull.<br class="">
<br class="">
Usage example:<br class="">
<blockquote class=""><tt class="">OvmsMetricVector<float>*
vf = new
OvmsMetricVector<float>("test.volts",
SM_STALE_MIN, Volts);</tt><br class="">
<tt class="">vf->SetElemValue(3, 1.23);</tt><br class="">
<tt class="">vf->SetElemValue(17, 2.34);</tt><br class="">
<tt class="">float myvals[3] = { 5.5, 6.6, 7.7
};</tt><br class="">
<tt class="">vf->SetElemValues(10, 3,
myvals);</tt><br class="">
</blockquote>
With this data set, you get:<br class="">
<blockquote class=""><tt class="">OVMS# met lis
test</tt><br class="">
<tt class="">test.volts
0,0,0,1.23,0,0,0,0,0,0,5.5,6.6,7.7,0,0,0,0,2.34V</tt><br class="">
</blockquote>
…and in the web framework:<br class="">
<blockquote class=""><tt class="">metrics["test.volts"]</tt><br class="">
<tt class="">(18) [0, 0, 0, 1.23, 0, 0, 0, 0, 0,
0, 5.5, 6.6, 7.7, 0, 0, 0, 0, 2.34]</tt><br class="">
<tt class="">metrics["test.volts"][11]</tt><br class="">
<tt class="">6.6</tt><br class="">
</blockquote>
See template definition in ovms_metrics.h for
more.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 31.10.18 um 20:08
schrieb Tamás Kovács:<br class="">
</div>
<blockquote type="cite" cite="mid:CAGpaXUvDSUoq-=5XRSV-RdhiFwNVrCwdPL6BpDuHSZ5mXJqFWA@mail.gmail.com" class="">
<meta http-equiv="content-type" content="text/html; charset=UTF-8" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">I have a Peugeot iOn,
and i wan't to create own metrics for
battery temp (66 piece) and voltage (88
(old) or 80(new) piece) for all cell (and
show on web interface), and i don't
understand how can i create it. Now my data
in array-s from can messages 6E1-6E4.<br class="" clear="all">
<div class="">My git fork: <a href="https://github.com/KommyKT/Open-Vehicle-Monitoring-System-3/tree/peugeot" moz-do-not-send="true" class="">https://github.com/KommyKT/Open-Vehicle-Monitoring-System-3/tree/peugeot</a></div>
<div class="">vehicle_mitsubishi</div>
<br class="">
</div>
</div>
</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>
</blockquote>
<blockquote type="cite" class="">
<div dir="ltr" class=""><span class="">_______________________________________________</span><br class="">
<span class="">OvmsDev mailing list</span><br class="">
<span class=""><a href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true" class="">OvmsDev@lists.openvehicles.com</a></span><br class="">
<span class=""><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true" class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a></span><br class="">
</div>
</blockquote>
<br class="">
<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 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>
<br class="">
<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 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>