[Ovmsdev] Custom metrics

Mark Webb-Johnson mark at webb-johnson.net
Sun Nov 11 15:10:20 HKT 2018


Looking at the discussion with Michael back in May, we came to some conclusions for this. I was happy back then with using ‘cell’ rather than ‘module’ as the naming, because (a) we are talking about cell/brick/module level here, not pack, and (b) it is shorter. It seems that the twizy has:

xrt.b.cell.01.volt.act                   3.995V
xrt.b.cell.01.volt.max                   4.12V
xrt.b.cell.01.volt.maxdev                0.01V
xrt.b.cell.01.volt.min                   3.795V
...
xrt.b.cell.cnt                           14
...
xrt.b.cmod.01.temp.act                   17°C
xrt.b.cmod.01.temp.max                   23°C
xrt.b.cmod.01.temp.maxdev                1°C
xrt.b.cmod.01.temp.min                   16°C
...
xrt.b.cmod.cnt                           7
...
xrt.b.pack.1.temp.alerts
xrt.b.pack.1.temp.max                    23°C
xrt.b.pack.1.temp.min                    16°C
xrt.b.pack.1.temp.stddev.max             1°C
xrt.b.pack.1.temp.watches
xrt.b.pack.1.volt.alerts
xrt.b.pack.1.volt.max                    57.6V
xrt.b.pack.1.volt.min                    52.8V
xrt.b.pack.1.volt.stddev.max             0.005V
xrt.b.pack.1.volt.watches                1,2,4,5,6,7,11,12,14
xrt.b.pack.cnt                           1
...
xrt.b.soc.max                            100%
xrt.b.soc.min                            69.78%

Trying to come up with a standard representation for this (so everyone can use a shared library, and share output displays), that works across all vehicles... Assuming we have one-dimensional arrays for different types of measurement (for voltage, temperature, etc), measurements are taken at the group of cells level (with perhaps different groupings for different readings), and aggregations/limits being automatically calculated, I think this has:

v.b.c.voltage

Vector<float> metric type array of voltage measurements

v.b.c.temp

Vector<float> metric type array of temperature measurements

Aggregations / limits

We could have v.b.c.voltage.min, v.b.c.voltage.max, v.b.c.voltage.maxdev, v.b.c.temp.min, v.b.c.temp.max, and v.b.c.temp.maxdev if we wanted to store these. Presumably they could be automatically calculated? I am guessing ‘min’ is the minimal value seen, and ‘max’ the maximum?

Setting as a batch

The way I’ve implemented the Model S is to keep a bitmap of values set. For example, say we have 32 cell voltage measurements. Every time we set a voltage measurement, we set the appropriate bit. When the bitmap is full, zero the bitmap, then set the metric in bulk (setting the entire vector). That seems to work well for Model S at least. The aggregations/limits would be calculated (and set) when the batch is ready. I suggest something like:

OvmsVehicle::SetCellVoltage(int index, float value);
OvmsVehicle::SetCellTemperature(int index, float value);

Arrangement

My thinking is that the count of measurements available can be defined when the module initialises. We can also simply count the size of the vectors, to know that. The issue is the cell/brick/module/pack arrangement; How many voltage or temperature measurements per module, how many modules in the pack, etc. I think we need to tell the system (a) the number of readings expected, (b) the number of readings per module, and (c) a hint to say how many readings to show per row. I suggest something like:

OvmsVehicle::SetCellArrangementVoltage(int readings, int readingspermodule, int readingsperrow)
OvmsVehicle::SetCellArrangementTemperature(int readings, int readingspermodule, int readingsperrow)

Commands

Once the above is defined we can have a ‘vehicle bms status’ command to show the status (like the Tesla Model S one shown here, albeit more polished):

   -------------------------------
 1 | 3.981 V | 3.981 V | 3.981 V | 29.5 C
   | 3.981 V | 3.981 V | 3.981 V | 30.3 C Max
   -------------------------------
 2 | 3.981 V | 3.981 V | 3.982 V | 29.4 C
   | 3.981 V | 3.981 V | 3.981 V | 29.8 C
   -------------------------------
 3 | 3.982 V | 3.982 V | 3.981 V | 29.1 C
   | 3.981 V | 3.981 V | 3.982 V | 29.7 C
   -------------------------------
 4 | 3.982 V | 3.982 V | 3.982 V | 28.9 C Min
   | 3.981 V | 3.982 V | 3.982 V | 29.7 C
   -------------------------------
 5 | 3.982 V | 3.982 V | 3.982 V | 29.0 C
   | 3.982 V | 3.981 V | 3.981 V | 29.6 C
   -------------------------------
 6 | 3.982 V | 3.982 V | 3.982 V | 29.3 C
   | 3.982 V | 3.982 V | 3.982 V | 29.6 C
   -------------------------------
 7 | 3.981 V | 3.981 V | 3.981 V | 29.0 C
   | 3.981 V | 3.981 V | 3.981 V | 29.6 C
   -------------------------------
 8 | 3.982 V | 3.983 V | 3.982 V | 29.2 C
   | 3.983 V | 3.982 V | 3.982 V | 29.9 C
   -------------------------------
 9 | 3.982 V | 3.982 V | 3.981 V | 30.0 C
   | 3.982 V | 3.981 V | 3.981 V | 29.7 C
   -------------------------------
10 | 3.979 V | 3.980 V | 3.979 V | 29.1 C
   | 3.980 V | 3.979 V | 3.979 V | 29.8 C
   -------------------------------
11 | 3.980 V | 3.981 V | 3.981 V | 29.1 C
   | 3.981 V | 3.981 V | 3.981 V | 29.4 C
   -------------------------------
12 | 3.981 V | 3.982 V | 3.981 V | 29.1 C
   | 3.981 V | 3.981 V | 3.982 V | 29.3 C
   -------------------------------
13 | 3.982 V | 3.983 V | 3.982 V | 28.9 C
   | 3.982 V | 3.982 V | 3.982 V | 29.4 C
   -------------------------------
14 | 3.981 V | 3.982 V | 3.982 V | 29.3 C
   | 3.982 V | 3.982 V | 3.982 V | 29.5 C
   -------------------------------
15 | 3.981 V | 3.982 V | 3.981 V | 29.6 C
   | 3.982 V | 3.981 V | 3.981 V | 29.9 C
   -------------------------------
16 | 3.982 V | 3.982 V | 3.982 V | 29.5 C
   | 3.982 V | 3.981 V | 3.981 V | 29.8 C
   -------------------------------
   Tmin: 28.9  Tmax: 30.3  Vmax: 3.983  Vmin: 3.979  Vmax-Vmin: 0.003  Vtot: 382.23

Another variant of this display would be:

   ----------------------------------------------------------------------------------
 1 | 3.981 V | 3.981 V | 3.981 V | 3.981 V | 3.981 V | 3.981 V | 29.5 C. 30.3 C Max |
   ----------------------------------------------------------------------------------
 2 | 3.981 V | 3.981 V | 3.982 V | 3.981 V | 3.981 V | 3.981 V | 29.4 C  29.8 C     |
   ----------------------------------------------------------------------------------
 3 | 3.982 V | 3.982 V | 3.981 V | 3.981 V | 3.981 V | 3.982 V | 29.1 C  29.7 C     |
   ----------------------------------------------------------------------------------
 4 | 3.982 V | 3.982 V | 3.982 V | 3.981 V | 3.982 V | 3.982 V | 28.9 C Min  29.7 C |
   ----------------------------------------------------------------------------------
 5 | 3.982 V | 3.982 V | 3.982 V | 3.982 V | 3.981 V | 3.981 V | 29.0 C  29.6 C     |
   ----------------------------------------------------------------------------------
...
   ----------------------------------------------------------------------------------
16 | 3.982 V | 3.982 V | 3.982 V | 3.982 V | 3.981 V | 3.981 V | 29.5 C  29.8 C.    |
   ----------------------------------------------------------------------------------
   Tmin: 28.9  Tmax: 30.3  Vmax: 3.983  Vmin: 3.979  Vmax-Vmin: 0.003  Vtot: 382.23

(The vehicle itself having the control via the SetCellArrangement methods)

To provide a baseline usage case, the Tesla Model S has:

96 bricks in the pack
6 bricks in each module
16 modules in the pack
Each brick has one voltage measurement (so, 96 individual voltage measurements)
Each module has two temperature measurements (so, 32 individual temperature measurements)
That means:
OvmsVehicle::SetCellArrangementVoltage(96, 6, 3)
OvmsVehicle::SetCellArrangementTemperature(32, 2, 1)

Tesla Model X seems identical to Model S.

I am still working on reverse engineering the Tesla Roadster, but it seems to have:

99 bricks in the pack
9 bricks in each module (aka sheet)
11 modules in the pack
Each brick has one voltage measurement (so, 11*9 = 99 individual voltage measurements)
Each module has four temperature measurements (so, 11*4 = 44 individual temperature measurements)
That means:
OvmsVehicle::SetCellArrangementVoltage(99, 9, 9)
OvmsVehicle::SetCellArrangementTemperature(44, 4, 4)

For other cars that support cell-level measurements, do they fit this representation? If so, can we fill in the following for each car, to see how it fits in?

XX cell groups in the pack
XX cell groups in each module
XX modules in the pack
Each cell group has one voltage measurement (so, XX individual voltage measurements)
Each module has four temperature measurements (so, XX individual temperature measurements)
That means:
OvmsVehicle::SetCellArrangementVoltage(N, Y,  Z)
OvmsVehicle::SetCellArrangementTemperature(N, Y, Z)

If they don’t fit, what changes are needed to make it work?

Regards, Mark.

> On 11 Nov 2018, at 12:16 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
> I originally thought ‘brick’, or ‘module’ rather than ‘cell’, but happy with either. These are readings for groups of cells, rather than whole pack.
> 
> Tesla Model S is 16 modules. 6 voltage readings, and 2 temperatures, per module.
> 
> What is Kia Soul arrangement?
> 
> Regards, Mark
> 
>> On 10 Nov 2018, at 11:26 PM, Henrik Scheel <henrik.scheel at spjeldager.dk> wrote:
>> 
>> Hi Mark.
>> 
>> Good idea with a generic array type metric, and standard metrics for common EV features!
>> 
>> Just a quick note:
>> The Kia Soul EV vehicle module will be able to utilize these metric-arrays. However, on the Soul, the voltages are for each physical pair of cells connected in parallel, and the temperatures are for 6 battery modules, and for the battery cooling air inlet. 
>> 
>> So, for the Kia Soul EV, the name “v.b.cell.temp” would be misleading, as each measured module temperature is representing the state for 16 pairs of cells.
>> 
>> Aside from that, I am all for mapping the values in these new standardized metric types. Currently, the temperature average is calculated and mapped to a metric, and the 96 cell voltages are unmapped for Kia Soul EV.
>> 
>> Best regards,
>> Henrik
>> -- 
>> 
>> Venlig hilsen / best regards 
>> Henrik R. Scheel
>> 
>> Spjeldager Consult ApS
>> Spjeldager 9 
>> DK-2630 Taastrup 
>> CVR: 34491399 
>> T: +45 2720 9828 
>> http://www.spjeldager.dk/
>> 
>>> Den 10. nov. 2018 kl. 15.34 skrev ovmsdev-request at lists.openvehicles.com:
>>> 
>>> Send OvmsDev mailing list submissions to
>>>   ovmsdev at lists.openvehicles.com
>>> 
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>   http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>> or, via email, send a message with subject or body 'help' to
>>>   ovmsdev-request at lists.openvehicles.com
>>> 
>>> You can reach the person managing the list at
>>>   ovmsdev-owner at lists.openvehicles.com
>>> 
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of OvmsDev digest..."
>>> 
>>> 
>>> Today's Topics:
>>> 
>>> 1. Re: Custom metrics (Mark Webb-Johnson)
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> 
>>> Message: 1
>>> Date: Sat, 10 Nov 2018 22:34:46 +0800
>>> From: Mark Webb-Johnson <mark at webb-johnson.net>
>>> To: OVMS Developers <ovmsdev at lists.openvehicles.com>
>>> Subject: Re: [Ovmsdev] Custom metrics
>>> Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11 at webb-johnson.net>
>>> Content-Type: text/plain; charset="utf-8"
>>> 
>>> 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).
>>> 
>>> 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:
>>> 
>>> An interface for specific vehicle module to specify the number of modules, number of voltage measurements, and number of temperature measurements available.
>>> Internal storage of cell voltages and temperatures.
>>> Tracking of when all voltages and temperatures have been set, and these should be written to metrics (as a transaction).
>>> Standardised command to display on terminal (like ?xts bms?).
>>> Web interface extensions (including the charting you have, a textual display, etc).
>>> 
>>> 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.
>>> 
>>> Regards, Mark.
>>> 
>>>> On 8 Nov 2018, at 6:49 AM, Michael Balzer <dexter at expeedo.de> wrote:
>>>> 
>>>> Mark,
>>>> 
>>>> 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.
>>>> 
>>>> It still lacks:
>>>> a) Displaying max deviations, current standard deviation and max standard deviation recorded.
>>>> 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.
>>>> c) SOH / capacity and internal resistance should be generally available per cell as well (no data on these yet on the Twizy).
>>>> 
>>>> And as this will visually overload the chart it will need some buttons to show/hide the parts.
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> The v2 protocol using RC4 encryption is a bad base for this. What's the current encryption on v3/MQTT?
>>>> 
>>>> Regards,
>>>> Michael
>>>> 
>>>> 
>>>>> Am 07.11.18 um 01:50 schrieb Mark Webb-Johnson:
>>>>> Some questions/comments:
>>>>> 
>>>>> 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)?
>>>>> 
>>>>> 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).
>>>>> 
>>>>> 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.
>>>>> 
>>>>> 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 https://api.openvehicles.com:8080/VEHICLEID <https://api.openvehicles.com:8080/VEHICLEID> 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 reference code for LWIP <https://github.com/russdill/lwip/commit/dfeba616>. Another is TUN/TAP, again with reference code for LWIP <https://github.com/russdill/lwip/commit/47ca42f8>. 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).
>>>>> 
>>>>> Regards, Mark.
>>>>> 
>>>>>> On 7 Nov 2018, at 4:52 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>>>>> 
>>>>>> Mark, Tam?s,
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> This ZIP?
>>>>>> 
>>>>>> https://dexters-web.de/f/ovms-dev/ovms.zip <https://dexters-web.de/f/ovms-dev/ovms.zip>
>>>>>> 
>>>>>> ?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.
>>>>>> 
>>>>>> Config ? CellChart loads "cellchart.htm". The blue button generates and injects test data. Should look like this:
>>>>>> 
>>>>>> <eoibkbnkbpofdlab.png>
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> Maybe I should add that stuff to the repository as well?
>>>>>> 
>>>>>> Regards,
>>>>>> Michael
>>>>>> 
>>>>>> 
>>>>>>> Am 06.11.18 um 15:56 schrieb Mark Webb-Johnson:
>>>>>>> Nice. I just implemented this for Model S using your new metric type.
>>>>>>> 
>>>>>>> 96 individual brick voltages for each of the bricks, plus two temperatures for each of the 16 modules.
>>>>>>> 
>>>>>>> Works well.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On 1 Nov 2018, at 5:58 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>>>>>>> 
>>>>>>>> Tam?s,
>>>>>>>> 
>>>>>>>> I've been creating separate metrics for all cell values on the Twizy, but that only has 14 cells.
>>>>>>>> 
>>>>>>>> We discussed this before, a better approach is introducing a new metric class for arrays. I have just done that for you, please pull.
>>>>>>>> 
>>>>>>>> Usage example:
>>>>>>>> OvmsMetricVector<float>* vf = new OvmsMetricVector<float>("test.volts", SM_STALE_MIN, Volts);
>>>>>>>> vf->SetElemValue(3, 1.23);
>>>>>>>> vf->SetElemValue(17, 2.34);
>>>>>>>> float myvals[3] = { 5.5, 6.6, 7.7 };
>>>>>>>> vf->SetElemValues(10, 3, myvals);
>>>>>>>> With this data set, you get:
>>>>>>>> OVMS# met lis test
>>>>>>>> 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
>>>>>>>> ?and in the web framework:
>>>>>>>> metrics["test.volts"]
>>>>>>>> (18) [0, 0, 0, 1.23, 0, 0, 0, 0, 0, 0, 5.5, 6.6, 7.7, 0, 0, 0, 0, 2.34]
>>>>>>>> metrics["test.volts"][11]
>>>>>>>> 6.6
>>>>>>>> See template definition in ovms_metrics.h for more.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Michael
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Am 31.10.18 um 20:08 schrieb Tam?s Kov?cs:
>>>>>>>>> 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.
>>>>>>>>> My git fork: https://github.com/KommyKT/Open-Vehicle-Monitoring-System-3/tree/peugeot <https://github.com/KommyKT/Open-Vehicle-Monitoring-System-3/tree/peugeot>
>>>>>>>>> vehicle_mitsubishi
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>>>>> _______________________________________________
>>>>>>>> OvmsDev mailing list
>>>>>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>>>>>> 
>>>>>> -- 
>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>>>> 
>>>> -- 
>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>> 
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20181110/b17e54e7/attachment.html>
>>> 
>>> ------------------------------
>>> 
>>> Subject: Digest Footer
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>> 
>>> 
>>> ------------------------------
>>> 
>>> End of OvmsDev Digest, Vol 82, Issue 10
>>> ***************************************
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20181111/ae5927a0/attachment-0001.html>


More information about the OvmsDev mailing list