[Ovmsdev] Custom metrics
Tamás Kovács
kommykt at gmail.com
Thu Nov 15 14:41:03 HKT 2018
Now i implement new bms system to Mitsubishi iMiEV, but, now not working
the battery monitoring on web service Whats wrong?
[image: Screenshot 2018-11-15 at 7.33.27.png]
[image: Screenshot 2018-11-15 at 7.34.05.png]
Mark Webb-Johnson <mark at webb-johnson.net> ezt írta (időpont: 2018. nov.
11., V, 8:10):
> 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:
>
>
> 1. v.b.c.voltage
>
> Vector<float> metric type array of voltage measurements
>
> 2. v.b.c.temp
>
> Vector<float> metric type array of temperature measurements
>
> 3. 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?
>
> 4. 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);
>
> 5. 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)
>
> 6. 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
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
--
Üdvözlettel:
Kovács Tamás
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20181115/5d62ac28/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2018-11-15 at 7.33.27.png
Type: image/png
Size: 191484 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20181115/5d62ac28/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2018-11-15 at 7.34.05.png
Type: image/png
Size: 155130 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20181115/5d62ac28/attachment-0005.png>
More information about the OvmsDev
mailing list