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@lists.openvehicles.com:
Send OvmsDev mailing list submissions to ovmsdev@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@lists.openvehicles.com
You can reach the person managing the list at ovmsdev-owner@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@webb-johnson.net> To: OVMS Developers <ovmsdev@lists.openvehicles.com> Subject: Re: [Ovmsdev] Custom metrics Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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@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@lists.openvehicles.com:
Send OvmsDev mailing list submissions to ovmsdev@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@lists.openvehicles.com
You can reach the person managing the list at ovmsdev-owner@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@webb-johnson.net> To: OVMS Developers <ovmsdev@lists.openvehicles.com> Subject: Re: [Ovmsdev] Custom metrics Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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@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@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@lists.openvehicles.com:
Send OvmsDev mailing list submissions to ovmsdev@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@lists.openvehicles.com
You can reach the person managing the list at ovmsdev-owner@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@webb-johnson.net> To: OVMS Developers <ovmsdev@lists.openvehicles.com> Subject: Re: [Ovmsdev] Custom metrics Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> > > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Mark, yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as… * OvmsVehicle::ResetCellStats(); * Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level? On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the vehicle / user. There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion bitset, i.e. * OvmsVehicle::RestartCellVoltages(); * OvmsVehicle::RestartCellTemperatures(); …as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation. Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these thresholds are currently fixed to… // Battery cell/cmod deviation alert thresholds: #define BATT_DEV_TEMP_ALERT 3 // = 3 °C #define BATT_DEV_VOLT_ALERT 6 // = 30 mV // ...thresholds for overall stddev: #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV …these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. So these should be configurable, i.e. * vehicle bms.dev.temp.alert [°C] * vehicle bms.dev.voltage.alert [V] * vehicle bms.stddev.temp.watch [°C] * vehicle bms.stddev.temp.alert [°C] * vehicle bms.stddev.voltage.watch [V] * vehicle bms.stddev.voltage.alert [V] I can generalize the Twizy code for all of this. The Twizy battery monitoring command set is: OVMS# xrt batt ? data-cell Output cell record data-pack Output pack record reset Reset alerts & watches status Status report tdev Show temperature deviations temp Show temperatures vdev Show voltage deviations volt Show voltages The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the output within the SMS msg size limit. "status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and "tdev" show all cells. The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set. The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on the Twizy, sending a vector metric to the server is just a matter of… std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; msg.append(m_mon.m_mot_torque_drv->AsString()); MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str()); Neat. The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a lot of additional data volume on large packs. The Twizy layout may be either… * 14 cell groups in the pack * 2 cell groups in each module * 7 modules in the pack * Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) * Each module has 1 temperature measurements (so, 7 individual temperature measurements) * That means: o OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) o OvmsVehicle::SetCellArrangementTemperature(7, 1, 7) …for the original battery, or for an LFP type replacement… * 16 cell groups in the pack * 16 cell groups in each module * 1 module in the pack * Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) * Each module has 3 temperature measurements (so, 3 individual temperature measurements) * That means: o OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) o OvmsVehicle::SetCellArrangementTemperature(3, 3, 3) Regards, Michael Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson:
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: o OvmsVehicle::SetCellArrangementVoltage(96, 6, 3) o 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: o OvmsVehicle::SetCellArrangementVoltage(99, 9, 9) o 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: o OvmsVehicle::SetCellArrangementVoltage(N, Y, Z) o 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@webb-johnson.net <mailto:mark@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@spjeldager.dk <mailto:henrik.scheel@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@lists.openvehicles.com:
Send OvmsDev mailing list submissions to ovmsdev@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@lists.openvehicles.com
You can reach the person managing the list at ovmsdev-owner@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@webb-johnson.net> To: OVMS Developers <ovmsdev@lists.openvehicles.com> Subject: Re: [Ovmsdev] Custom metrics Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >> >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to use it, and support came down to just a few simple lines of code. For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational. c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with using std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way of doing that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of data ready to commit to metrics, so will need to think about this some more. I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall aggregates, etc). There is a very basic ‘bms status’ command implemented. Let me know what you think of it. Regards, Mark
On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as… OvmsVehicle::ResetCellStats(); Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level? On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the vehicle / user.
There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion bitset, i.e. OvmsVehicle::RestartCellVoltages(); OvmsVehicle::RestartCellTemperatures(); …as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation.
Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these thresholds are currently fixed to… // Battery cell/cmod deviation alert thresholds: #define BATT_DEV_TEMP_ALERT 3 // = 3 °C #define BATT_DEV_VOLT_ALERT 6 // = 30 mV
// ...thresholds for overall stddev: #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV …these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. So these should be configurable, i.e. vehicle bms.dev.temp.alert [°C] vehicle bms.dev.voltage.alert [V] vehicle bms.stddev.temp.watch [°C] vehicle bms.stddev.temp.alert [°C] vehicle bms.stddev.voltage.watch [V] vehicle bms.stddev.voltage.alert [V] I can generalize the Twizy code for all of this.
The Twizy battery monitoring command set is: OVMS# xrt batt ? data-cell Output cell record data-pack Output pack record reset Reset alerts & watches status Status report tdev Show temperature deviations temp Show temperatures vdev Show voltage deviations volt Show voltages The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the output within the SMS msg size limit.
"status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and "tdev" show all cells.
The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set.
The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on the Twizy, sending a vector metric to the server is just a matter of… std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; msg.append(m_mon.m_mot_torque_drv->AsString()); MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str()); Neat.
The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a lot of additional data volume on large packs.
The Twizy layout may be either… 14 cell groups in the pack 2 cell groups in each module 7 modules in the pack Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) Each module has 1 temperature measurements (so, 7 individual temperature measurements) That means: OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) OvmsVehicle::SetCellArrangementTemperature(7, 1, 7) …for the original battery, or for an LFP type replacement…
16 cell groups in the pack 16 cell groups in each module 1 module in the pack Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) Each module has 3 temperature measurements (so, 3 individual temperature measurements) That means: OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) OvmsVehicle::SetCellArrangementTemperature(3, 3, 3)
Regards, Michael
Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson:
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@webb-johnson.net <mailto:mark@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@spjeldager.dk <mailto:henrik.scheel@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/ <http://www.spjeldager.dk/>
Den 10. nov. 2018 kl. 15.34 skrev ovmsdev-request@lists.openvehicles.com <mailto:ovmsdev-request@lists.openvehicles.com>:
Send OvmsDev mailing list submissions to ovmsdev@lists.openvehicles.com <mailto:ovmsdev@lists.openvehicles.com>
To subscribe or unsubscribe via the World Wide Web, visit http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> or, via email, send a message with subject or body 'help' to ovmsdev-request@lists.openvehicles.com <mailto:ovmsdev-request@lists.openvehicles.com>
You can reach the person managing the list at ovmsdev-owner@lists.openvehicles.com <mailto:ovmsdev-owner@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@webb-johnson.net> <mailto:mark@webb-johnson.net> To: OVMS Developers <ovmsdev@lists.openvehicles.com> <mailto:ovmsdev@lists.openvehicles.com> Subject: Re: [Ovmsdev] Custom metrics Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@webb-johnson.net> <mailto:1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@expeedo.de> <mailto:dexter@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 likehttps://api.openvehicles.com:8080/VEHICLEID <https://api.openvehicles.com:8080/VEHICLEID> <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> <https://github.com/russdill/lwip/commit/dfeba616>. Another is TUN/TAP, again with reference code for LWIP <https://github.com/russdill/lwip/commit/47ca42f8> <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@expeedo.de <mailto:dexter@expeedo.de> <mailto:dexter@expeedo.de> <mailto:dexter@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> <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@expeedo.de <mailto:dexter@expeedo.de> <mailto:dexter@expeedo.de> <mailto:dexter@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> <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>> >>> >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> > > > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
Mark, Tamás, I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI. Please see git log for details and send some screenshots. Regards, Michael Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson:
OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to use it, and support came down to just a few simple lines of code.
For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational.
c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with using std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way of doing that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of data ready to commit to metrics, so will need to think about this some more.
I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall aggregates, etc). There is a very basic ‘bms status’ command implemented.
Let me know what you think of it.
Regards, Mark
On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as…
* OvmsVehicle::ResetCellStats(); * Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level?
On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the vehicle / user.
There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion bitset, i.e.
* OvmsVehicle::RestartCellVoltages(); * OvmsVehicle::RestartCellTemperatures();
…as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation.
Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these thresholds are currently fixed to…
// Battery cell/cmod deviation alert thresholds: #define BATT_DEV_TEMP_ALERT 3 // = 3 °C #define BATT_DEV_VOLT_ALERT 6 // = 30 mV
// ...thresholds for overall stddev: #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV
…these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. So these should be configurable, i.e.
* vehicle bms.dev.temp.alert [°C] * vehicle bms.dev.voltage.alert [V] * vehicle bms.stddev.temp.watch [°C] * vehicle bms.stddev.temp.alert [°C] * vehicle bms.stddev.voltage.watch [V] * vehicle bms.stddev.voltage.alert [V]
I can generalize the Twizy code for all of this.
The Twizy battery monitoring command set is:
OVMS# xrt batt ? data-cell Output cell record data-pack Output pack record reset Reset alerts & watches status Status report tdev Show temperature deviations temp Show temperatures vdev Show voltage deviations volt Show voltages
The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the output within the SMS msg size limit.
"status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and "tdev" show all cells.
The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set.
The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on the Twizy, sending a vector metric to the server is just a matter of…
std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; msg.append(m_mon.m_mot_torque_drv->AsString()); MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str());
Neat.
The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a lot of additional data volume on large packs.
The Twizy layout may be either…
* 14 cell groups in the pack * 2 cell groups in each module * 7 modules in the pack * Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) * Each module has 1 temperature measurements (so, 7 individual temperature measurements) * That means: o OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) o OvmsVehicle::SetCellArrangementTemperature(7, 1, 7)
…for the original battery, or for an LFP type replacement…
* 16 cell groups in the pack * 16 cell groups in each module * 1 module in the pack * Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) * Each module has 3 temperature measurements (so, 3 individual temperature measurements) * That means: o OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) o OvmsVehicle::SetCellArrangementTemperature(3, 3, 3)
Regards, Michael
Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson:
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: o OvmsVehicle::SetCellArrangementVoltage(96, 6, 3) o 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: o OvmsVehicle::SetCellArrangementVoltage(99, 9, 9) o 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: o OvmsVehicle::SetCellArrangementVoltage(N, Y, Z) o 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@webb-johnson.net <mailto:mark@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@spjeldager.dk <mailto:henrik.scheel@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@lists.openvehicles.com:
Send OvmsDev mailing list submissions to ovmsdev@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@lists.openvehicles.com
You can reach the person managing the list at ovmsdev-owner@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@webb-johnson.net> To: OVMS Developers <ovmsdev@lists.openvehicles.com> Subject: Re: [Ovmsdev] Custom metrics Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>> >>>> >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >> >> >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Now i found the problem, i used this ( https://dexters-web.de/f/ovms-dev/ovms.zip) to create web interface for battery monitor, and has one failure , this rows: if (update["v.b.c.temp"] || update["v.b.c.temp.min"] || update["v.b.c.temp.max"]) it modified you in git to : "if (update[\"v.b.c.voltage\"] != null\n" "|| update[\"v.b.c.voltage.min\"] != null\n" "|| update[\"v.b.c.voltage.max\"] != null)\n" now i moved my code same as Tesla Model S Michael Balzer <dexter@expeedo.de> ezt írta (időpont: 2018. nov. 17., Szo, 0:36):
Mark, Tamás,
I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI.
Please see git log for details and send some screenshots.
Regards, Michael
Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson:
OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to use it, and support came down to just a few simple lines of code.
For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational.
c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with using std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way of doing that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of data ready to commit to metrics, so will need to think about this some more.
I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall aggregates, etc). There is a very basic ‘bms status’ command implemented.
Let me know what you think of it.
Regards, Mark
On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as…
- OvmsVehicle::ResetCellStats(); - Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level?
On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the vehicle / user.
There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion bitset, i.e.
- OvmsVehicle::RestartCellVoltages(); - OvmsVehicle::RestartCellTemperatures();
…as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation.
Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these thresholds are currently fixed to…
// Battery cell/cmod deviation alert thresholds: #define BATT_DEV_TEMP_ALERT 3 // = 3 °C #define BATT_DEV_VOLT_ALERT 6 // = 30 mV
// ...thresholds for overall stddev: #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV
…these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. So these should be configurable, i.e.
- vehicle bms.dev.temp.alert [°C] - vehicle bms.dev.voltage.alert [V] - vehicle bms.stddev.temp.watch [°C] - vehicle bms.stddev.temp.alert [°C] - vehicle bms.stddev.voltage.watch [V] - vehicle bms.stddev.voltage.alert [V]
I can generalize the Twizy code for all of this.
The Twizy battery monitoring command set is:
OVMS# xrt batt ? data-cell Output cell record data-pack Output pack record reset Reset alerts & watches status Status report tdev Show temperature deviations temp Show temperatures vdev Show voltage deviations volt Show voltages
The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the output within the SMS msg size limit.
"status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and "tdev" show all cells.
The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set.
The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on the Twizy, sending a vector metric to the server is just a matter of…
std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; msg.append(m_mon.m_mot_torque_drv->AsString()); MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str());
Neat.
The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a lot of additional data volume on large packs.
The Twizy layout may be either…
- 14 cell groups in the pack - 2 cell groups in each module - 7 modules in the pack - Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) - Each module has 1 temperature measurements (so, 7 individual temperature measurements) - That means: - OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) - OvmsVehicle::SetCellArrangementTemperature(7, 1, 7)
…for the original battery, or for an LFP type replacement…
- 16 cell groups in the pack - 16 cell groups in each module - 1 module in the pack - Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) - Each module has 3 temperature measurements (so, 3 individual temperature measurements) - That means: - OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) - OvmsVehicle::SetCellArrangementTemperature(3, 3, 3)
Regards, Michael
Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson:
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@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@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@lists.openvehicles.com:
Send OvmsDev mailing list submissions to ovmsdev@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@lists.openvehicles.com
You can reach the person managing the list at ovmsdev-owner@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@webb-johnson.net> <mark@webb-johnson.net> To: OVMS Developers <ovmsdev@lists.openvehicles.com> <ovmsdev@lists.openvehicles.com> Subject: Re: [Ovmsdev] Custom metrics Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@webb-johnson.net> <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@expeedo.de> <dexter@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> <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> <https://github.com/russdill/lwip/commit/dfeba616>. Another is TUN/TAP, again with reference code for LWIP <https://github.com/russdill/lwip/commit/47ca42f8> <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@expeedo.de <mailto:dexter@expeedo.de> <dexter@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> <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@expeedo.de <mailto:dexter@expeedo.de> <dexter@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> <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Michael, Looks good. It seems that you did everything necessary for the Model S already in your commit 2a84d861403f48142d6adcc16ad7a20cd458e427: #include “ovms_webserver.h" OvmsVehicleTeslaModelS::OvmsVehicleTeslaModelS() MyWebServer.RegisterPage("/bms/cellmon", "BMS cell monitor", OvmsWebServer::HandleBmsCellMonitor, PageMenu_Vehicle, PageAuth_Cookie); OvmsVehicleTeslaModelS::~OvmsVehicleTeslaModelS() MyWebServer.DeregisterPage("/bms/cellmon"); From my devbench, replaying a CAN CRTD log file, I get this output: The animation is very nice. I am, however, getting crashes, as follows: # xtensa-esp32-elf-addr2line -pfiaC -e 3.1.011-25-g2a84d86.ovms3.elf 0x400935d3 0x4009372b 0x400db90c 0x4012c0f7 0x4012d0e1 0x4012d1e0 0x4012ebc1 0x4012ecbd 0x400f8b65 0x400f912d 0x400fa27c 0x400fa29a 0x400f8b65 0x400fa3e3 0x400fa7ad 0x400faa77 0x400f767e 0x400ee40a 0x400ee459 0x400935d3: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 0x4009372b: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 0x400db90c: __cxx_fatal_exception_message at /home/openvehicles/build/esp-idf/components/cxx/cxx_exception_stubs.cpp:19 0x4012c0f7: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:216 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, char const*, std::__false_type) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457 0x4012d0e1: OvmsWebServer::CreateMenu[abi:cxx11](PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:393 0x4012d1e0: OvmsWebServer::HandleRoot(PageEntry&, PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:510 0x4012ebc1: PageEntry::Serve(PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 0x4012ecbd: OvmsWebServer::EventHandler(mg_connection*, int, void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f912d: mg_http_call_endpoint_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa27c: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa29a: mg_http_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa3e3: mg_recv_common at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa7ad: mg_if_recv_tcp_cb at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 (inlined by) mg_handle_tcp_read at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3723 (inlined by) mg_mgr_handle_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3844 0x400faa77: mg_socket_if_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f767e: mg_mgr_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400ee40a: OvmsNetManager::MongooseTask() at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:560 0x400ee459: MongooseRawTask(void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:545 On my development bench module I get this crash 1 in 4 times or so. On my real car, 100% of the time. That code path leads into MyVehicleFactory.ActiveVehicleShortName(). Those should all be ‘const char*’, but it is possible for NULL to be returned. I will look into it in more detail. Regards, Mark.
On 17 Nov 2018, at 7:35 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark, Tamás,
I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI.
Please see git log for details and send some screenshots.
Regards, Michael
Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson:
OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to use it, and support came down to just a few simple lines of code.
For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational.
c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with using std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way of doing that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of data ready to commit to metrics, so will need to think about this some more.
I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall aggregates, etc). There is a very basic ‘bms status’ command implemented.
Let me know what you think of it.
Regards, Mark
On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as… OvmsVehicle::ResetCellStats(); Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level? On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the vehicle / user.
There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion bitset, i.e. OvmsVehicle::RestartCellVoltages(); OvmsVehicle::RestartCellTemperatures(); …as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation.
Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these thresholds are currently fixed to… // Battery cell/cmod deviation alert thresholds: #define BATT_DEV_TEMP_ALERT 3 // = 3 °C #define BATT_DEV_VOLT_ALERT 6 // = 30 mV
// ...thresholds for overall stddev: #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV …these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. So these should be configurable, i.e. vehicle bms.dev.temp.alert [°C] vehicle bms.dev.voltage.alert [V] vehicle bms.stddev.temp.watch [°C] vehicle bms.stddev.temp.alert [°C] vehicle bms.stddev.voltage.watch [V] vehicle bms.stddev.voltage.alert [V] I can generalize the Twizy code for all of this.
The Twizy battery monitoring command set is: OVMS# xrt batt ? data-cell Output cell record data-pack Output pack record reset Reset alerts & watches status Status report tdev Show temperature deviations temp Show temperatures vdev Show voltage deviations volt Show voltages The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the output within the SMS msg size limit.
"status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and "tdev" show all cells.
The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set.
The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on the Twizy, sending a vector metric to the server is just a matter of… std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; msg.append(m_mon.m_mot_torque_drv->AsString()); MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str()); Neat.
The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a lot of additional data volume on large packs.
The Twizy layout may be either… 14 cell groups in the pack 2 cell groups in each module 7 modules in the pack Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) Each module has 1 temperature measurements (so, 7 individual temperature measurements) That means: OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) OvmsVehicle::SetCellArrangementTemperature(7, 1, 7) …for the original battery, or for an LFP type replacement…
16 cell groups in the pack 16 cell groups in each module 1 module in the pack Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) Each module has 3 temperature measurements (so, 3 individual temperature measurements) That means: OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) OvmsVehicle::SetCellArrangementTemperature(3, 3, 3)
Regards, Michael
Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson:
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@webb-johnson.net <mailto:mark@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@spjeldager.dk <mailto:henrik.scheel@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/ <http://www.spjeldager.dk/>
> Den 10. nov. 2018 kl. 15.34 skrev ovmsdev-request@lists.openvehicles.com <mailto:ovmsdev-request@lists.openvehicles.com>: > > Send OvmsDev mailing list submissions to > ovmsdev@lists.openvehicles.com <mailto:ovmsdev@lists.openvehicles.com> > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> > or, via email, send a message with subject or body 'help' to > ovmsdev-request@lists.openvehicles.com <mailto:ovmsdev-request@lists.openvehicles.com> > > You can reach the person managing the list at > ovmsdev-owner@lists.openvehicles.com <mailto:ovmsdev-owner@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@webb-johnson.net> <mailto:mark@webb-johnson.net> > To: OVMS Developers <ovmsdev@lists.openvehicles.com> <mailto:ovmsdev@lists.openvehicles.com> > Subject: Re: [Ovmsdev] Custom metrics > Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@webb-johnson.net> <mailto:1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@expeedo.de> <mailto:dexter@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> <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> <https://github.com/russdill/lwip/commit/dfeba616>. Another is TUN/TAP, again with reference code for LWIP <https://github.com/russdill/lwip/commit/47ca42f8> <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@expeedo.de <mailto:dexter@expeedo.de> <mailto:dexter@expeedo.de> <mailto:dexter@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> <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@expeedo.de <mailto:dexter@expeedo.de> <mailto:dexter@expeedo.de> <mailto:dexter@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><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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OvmsDev mailing list >>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>> >>> >>> >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> > >
Two issues: OvmsWebServer::CreateMenu is not handling the possibility that MyVehicleFactory.ActiveVehicleShortName() returns NULL (for no short name found). MyVehicleFactory.ActiveVehicleShortName() calls VehicleShortName(), which uses the metric v.type to lookup the registered vehicle and associated short name. However, if the v.type metric has been modified, that lookup will fail and NULL returned. For example, Tesla Model S is initially registered as TS, but after getting CAN bus data may change that to describe the vehicle better (such as TSHK). I think it is probably onerous to expect every user of MyVehicleFactory.ActiveVehicleShortName() to handle NULL. Better to just return “” as the “not found” value. That stops the crash. Then, fix VehicleShortName() to use the originally registered vehicle code (TS) to do the lookup, not the v.type metric. Committed just now. Real car now showing this: Looks good. Regards, Mark.
On 17 Nov 2018, at 5:08 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Michael,
Looks good. It seems that you did everything necessary for the Model S already in your commit 2a84d861403f48142d6adcc16ad7a20cd458e427:
#include “ovms_webserver.h"
OvmsVehicleTeslaModelS::OvmsVehicleTeslaModelS() MyWebServer.RegisterPage("/bms/cellmon", "BMS cell monitor", OvmsWebServer::HandleBmsCellMonitor, PageMenu_Vehicle, PageAuth_Cookie);
OvmsVehicleTeslaModelS::~OvmsVehicleTeslaModelS() MyWebServer.DeregisterPage("/bms/cellmon");
From my devbench, replaying a CAN CRTD log file, I get this output:
<PastedGraphic-2.png>
The animation is very nice.
I am, however, getting crashes, as follows:
# xtensa-esp32-elf-addr2line -pfiaC -e 3.1.011-25-g2a84d86.ovms3.elf 0x400935d3 0x4009372b 0x400db90c 0x4012c0f7 0x4012d0e1 0x4012d1e0 0x4012ebc1 0x4012ecbd 0x400f8b65 0x400f912d 0x400fa27c 0x400fa29a 0x400f8b65 0x400fa3e3 0x400fa7ad 0x400faa77 0x400f767e 0x400ee40a 0x400ee459 0x400935d3: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 0x4009372b: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 0x400db90c: __cxx_fatal_exception_message at /home/openvehicles/build/esp-idf/components/cxx/cxx_exception_stubs.cpp:19 0x4012c0f7: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:216 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, char const*, std::__false_type) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457 0x4012d0e1: OvmsWebServer::CreateMenu[abi:cxx11](PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:393 0x4012d1e0: OvmsWebServer::HandleRoot(PageEntry&, PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:510 0x4012ebc1: PageEntry::Serve(PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 0x4012ecbd: OvmsWebServer::EventHandler(mg_connection*, int, void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f912d: mg_http_call_endpoint_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa27c: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa29a: mg_http_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa3e3: mg_recv_common at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa7ad: mg_if_recv_tcp_cb at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 (inlined by) mg_handle_tcp_read at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3723 (inlined by) mg_mgr_handle_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3844 0x400faa77: mg_socket_if_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f767e: mg_mgr_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400ee40a: OvmsNetManager::MongooseTask() at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:560 0x400ee459: MongooseRawTask(void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:545
On my development bench module I get this crash 1 in 4 times or so. On my real car, 100% of the time.
That code path leads into MyVehicleFactory.ActiveVehicleShortName(). Those should all be ‘const char*’, but it is possible for NULL to be returned. I will look into it in more detail.
Regards, Mark.
On 17 Nov 2018, at 7:35 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark, Tamás,
I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI.
Please see git log for details and send some screenshots.
Regards, Michael
Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson:
OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to use it, and support came down to just a few simple lines of code.
For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational.
c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with using std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way of doing that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of data ready to commit to metrics, so will need to think about this some more.
I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall aggregates, etc). There is a very basic ‘bms status’ command implemented.
Let me know what you think of it.
Regards, Mark
On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as… OvmsVehicle::ResetCellStats(); Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level? On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the vehicle / user.
There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion bitset, i.e. OvmsVehicle::RestartCellVoltages(); OvmsVehicle::RestartCellTemperatures(); …as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation.
Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these thresholds are currently fixed to… // Battery cell/cmod deviation alert thresholds: #define BATT_DEV_TEMP_ALERT 3 // = 3 °C #define BATT_DEV_VOLT_ALERT 6 // = 30 mV
// ...thresholds for overall stddev: #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV …these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. So these should be configurable, i.e. vehicle bms.dev.temp.alert [°C] vehicle bms.dev.voltage.alert [V] vehicle bms.stddev.temp.watch [°C] vehicle bms.stddev.temp.alert [°C] vehicle bms.stddev.voltage.watch [V] vehicle bms.stddev.voltage.alert [V] I can generalize the Twizy code for all of this.
The Twizy battery monitoring command set is: OVMS# xrt batt ? data-cell Output cell record data-pack Output pack record reset Reset alerts & watches status Status report tdev Show temperature deviations temp Show temperatures vdev Show voltage deviations volt Show voltages The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the output within the SMS msg size limit.
"status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and "tdev" show all cells.
The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set.
The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on the Twizy, sending a vector metric to the server is just a matter of… std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; msg.append(m_mon.m_mot_torque_drv->AsString()); MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str()); Neat.
The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a lot of additional data volume on large packs.
The Twizy layout may be either… 14 cell groups in the pack 2 cell groups in each module 7 modules in the pack Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) Each module has 1 temperature measurements (so, 7 individual temperature measurements) That means: OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) OvmsVehicle::SetCellArrangementTemperature(7, 1, 7) …for the original battery, or for an LFP type replacement…
16 cell groups in the pack 16 cell groups in each module 1 module in the pack Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) Each module has 3 temperature measurements (so, 3 individual temperature measurements) That means: OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) OvmsVehicle::SetCellArrangementTemperature(3, 3, 3)
Regards, Michael
Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson:
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@webb-johnson.net <mailto:mark@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@spjeldager.dk <mailto:henrik.scheel@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/ <http://www.spjeldager.dk/> > >> Den 10. nov. 2018 kl. 15.34 skrev ovmsdev-request@lists.openvehicles.com <mailto:ovmsdev-request@lists.openvehicles.com>: >> >> Send OvmsDev mailing list submissions to >> ovmsdev@lists.openvehicles.com <mailto:ovmsdev@lists.openvehicles.com> >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >> or, via email, send a message with subject or body 'help' to >> ovmsdev-request@lists.openvehicles.com <mailto:ovmsdev-request@lists.openvehicles.com> >> >> You can reach the person managing the list at >> ovmsdev-owner@lists.openvehicles.com <mailto:ovmsdev-owner@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@webb-johnson.net> <mailto:mark@webb-johnson.net> >> To: OVMS Developers <ovmsdev@lists.openvehicles.com> <mailto:ovmsdev@lists.openvehicles.com> >> Subject: Re: [Ovmsdev] Custom metrics >> Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@webb-johnson.net> <mailto:1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@expeedo.de> <mailto:dexter@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> <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> <https://github.com/russdill/lwip/commit/dfeba616>. Another is TUN/TAP, again with reference code for LWIP <https://github.com/russdill/lwip/commit/47ca42f8> <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@expeedo.de <mailto:dexter@expeedo.de> <mailto:dexter@expeedo.de> <mailto:dexter@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> <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@expeedo.de <mailto:dexter@expeedo.de> <mailto:dexter@expeedo.de> <mailto:dexter@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><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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OvmsDev mailing list >>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >> >>
Mark, nice, thanks. The short name is used for the menu label. It's meant to fall back to the long name (and seems to do so in your screenshot), so should not be null. But I admit I haven't tested it on a vehicle without a short name. Btw, I'm currently working on the deviations and alerts. Regards, Michael Am 17.11.18 um 10:08 schrieb Mark Webb-Johnson:
Michael,
Looks good. It seems that you did everything necessary for the Model S already in your commit 2a84d861403f48142d6adcc16ad7a20cd458e427:
#include “ovms_webserver.h"
OvmsVehicleTeslaModelS::OvmsVehicleTeslaModelS() MyWebServer.RegisterPage("/bms/cellmon", "BMS cell monitor", OvmsWebServer::HandleBmsCellMonitor, PageMenu_Vehicle, PageAuth_Cookie);
OvmsVehicleTeslaModelS::~OvmsVehicleTeslaModelS() MyWebServer.DeregisterPage("/bms/cellmon");
From my devbench, replaying a CAN CRTD log file, I get this output:
The animation is very nice.
I am, however, getting crashes, as follows:
# xtensa-esp32-elf-addr2line -pfiaC -e 3.1.011-25-g2a84d86.ovms3.elf 0x400935d3 0x4009372b 0x400db90c 0x4012c0f7 0x4012d0e1 0x4012d1e0 0x4012ebc1 0x4012ecbd 0x400f8b65 0x400f912d 0x400fa27c 0x400fa29a 0x400f8b65 0x400fa3e3 0x400fa7ad 0x400faa77 0x400f767e 0x400ee40a 0x400ee459 0x400935d3: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 0x4009372b: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 0x400db90c: __cxx_fatal_exception_message at /home/openvehicles/build/esp-idf/components/cxx/cxx_exception_stubs.cpp:19 0x4012c0f7: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:216 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, char const*, std::__false_type) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457 0x4012d0e1: OvmsWebServer::CreateMenu[abi:cxx11](PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:393 0x4012d1e0: OvmsWebServer::HandleRoot(PageEntry&, PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:510 0x4012ebc1: PageEntry::Serve(PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 0x4012ecbd: OvmsWebServer::EventHandler(mg_connection*, int, void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f912d: mg_http_call_endpoint_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa27c: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa29a: mg_http_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa3e3: mg_recv_common at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa7ad: mg_if_recv_tcp_cb at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 (inlined by) mg_handle_tcp_read at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3723 (inlined by) mg_mgr_handle_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3844 0x400faa77: mg_socket_if_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f767e: mg_mgr_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400ee40a: OvmsNetManager::MongooseTask() at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:560 0x400ee459: MongooseRawTask(void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:545
On my development bench module I get this crash 1 in 4 times or so. On my real car, 100% of the time.
That code path leads into MyVehicleFactory.ActiveVehicleShortName(). Those should all be ‘const char*’, but it is possible for NULL to be returned. I will look into it in more detail.
Regards, Mark.
On 17 Nov 2018, at 7:35 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark, Tamás,
I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI.
Please see git log for details and send some screenshots.
Regards, Michael
Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson:
OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to use it, and support came down to just a few simple lines of code.
For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational.
c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with using std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way of doing that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of data ready to commit to metrics, so will need to think about this some more.
I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall aggregates, etc). There is a very basic ‘bms status’ command implemented.
Let me know what you think of it.
Regards, Mark
On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as…
* OvmsVehicle::ResetCellStats(); * Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level?
On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the vehicle / user.
There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion bitset, i.e.
* OvmsVehicle::RestartCellVoltages(); * OvmsVehicle::RestartCellTemperatures();
…as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation.
Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these thresholds are currently fixed to…
// Battery cell/cmod deviation alert thresholds: #define BATT_DEV_TEMP_ALERT 3 // = 3 °C #define BATT_DEV_VOLT_ALERT 6 // = 30 mV
// ...thresholds for overall stddev: #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV
…these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. So these should be configurable, i.e.
* vehicle bms.dev.temp.alert [°C] * vehicle bms.dev.voltage.alert [V] * vehicle bms.stddev.temp.watch [°C] * vehicle bms.stddev.temp.alert [°C] * vehicle bms.stddev.voltage.watch [V] * vehicle bms.stddev.voltage.alert [V]
I can generalize the Twizy code for all of this.
The Twizy battery monitoring command set is:
OVMS# xrt batt ? data-cell Output cell record data-pack Output pack record reset Reset alerts & watches status Status report tdev Show temperature deviations temp Show temperatures vdev Show voltage deviations volt Show voltages
The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the output within the SMS msg size limit.
"status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and "tdev" show all cells.
The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set.
The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on the Twizy, sending a vector metric to the server is just a matter of…
std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; msg.append(m_mon.m_mot_torque_drv->AsString()); MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str());
Neat.
The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a lot of additional data volume on large packs.
The Twizy layout may be either…
* 14 cell groups in the pack * 2 cell groups in each module * 7 modules in the pack * Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) * Each module has 1 temperature measurements (so, 7 individual temperature measurements) * That means: o OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) o OvmsVehicle::SetCellArrangementTemperature(7, 1, 7)
…for the original battery, or for an LFP type replacement…
* 16 cell groups in the pack * 16 cell groups in each module * 1 module in the pack * Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) * Each module has 3 temperature measurements (so, 3 individual temperature measurements) * That means: o OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) o OvmsVehicle::SetCellArrangementTemperature(3, 3, 3)
Regards, Michael
Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson:
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: o OvmsVehicle::SetCellArrangementVoltage(96, 6, 3) o 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: o OvmsVehicle::SetCellArrangementVoltage(99, 9, 9) o 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: o OvmsVehicle::SetCellArrangementVoltage(N, Y, Z) o 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@webb-johnson.net <mailto:mark@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@spjeldager.dk <mailto:henrik.scheel@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@lists.openvehicles.com: >> >> Send OvmsDev mailing list submissions to >> ovmsdev@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@lists.openvehicles.com >> >> You can reach the person managing the list at >> ovmsdev-owner@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@webb-johnson.net> >> To: OVMS Developers <ovmsdev@lists.openvehicles.com> >> Subject: Re: [Ovmsdev] Custom metrics >> Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OvmsDev mailing list >>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com >>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >> >>
Twizy code overrides the virtual short name function, so won’t suffer the issue. I think it is a bug in vehicle factory (as modifying the vehicle type is reasonable), so fixed it there. Returning NULL is problematic. It would be so much easier for everything to return std::string, but concern is memory consumption and overhead. I’d like to start converting RE TOOLS to just use the web server. First step is to work out how to add a menu onto the web server. It seems that the PageMenu_t is a fixed enum list (and similarly hard-coded in the web_framework. Do I just add a ‘CAN bus’ menu there, by adding it to PageMenu_t, and supporting it where the other top level menus are? Or do you have any other suggestions/plans for this? I don’t want to step on anything you are working on here. The second stage will be to add displays under that, but I think that is fairly straight forward. I will mostly be displaying tables, and sending those over the web socket would be good. Regards, Mark
On 17 Nov 2018, at 5:37 PM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
nice, thanks.
The short name is used for the menu label. It's meant to fall back to the long name (and seems to do so in your screenshot), so should not be null. But I admit I haven't tested it on a vehicle without a short name.
Btw, I'm currently working on the deviations and alerts.
Regards, Michael
Am 17.11.18 um 10:08 schrieb Mark Webb-Johnson:
Michael,
Looks good. It seems that you did everything necessary for the Model S already in your commit 2a84d861403f48142d6adcc16ad7a20cd458e427:
#include “ovms_webserver.h"
OvmsVehicleTeslaModelS::OvmsVehicleTeslaModelS() MyWebServer.RegisterPage("/bms/cellmon", "BMS cell monitor", OvmsWebServer::HandleBmsCellMonitor, PageMenu_Vehicle, PageAuth_Cookie);
OvmsVehicleTeslaModelS::~OvmsVehicleTeslaModelS() MyWebServer.DeregisterPage("/bms/cellmon");
From my devbench, replaying a CAN CRTD log file, I get this output:
<PastedGraphic-2.png>
The animation is very nice.
I am, however, getting crashes, as follows:
# xtensa-esp32-elf-addr2line -pfiaC -e 3.1.011-25-g2a84d86.ovms3.elf 0x400935d3 0x4009372b 0x400db90c 0x4012c0f7 0x4012d0e1 0x4012d1e0 0x4012ebc1 0x4012ecbd 0x400f8b65 0x400f912d 0x400fa27c 0x400fa29a 0x400f8b65 0x400fa3e3 0x400fa7ad 0x400faa77 0x400f767e 0x400ee40a 0x400ee459 0x400935d3: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 0x4009372b: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 0x400db90c: __cxx_fatal_exception_message at /home/openvehicles/build/esp-idf/components/cxx/cxx_exception_stubs.cpp:19 0x4012c0f7: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:216 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, char const*, std::__false_type) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457 0x4012d0e1: OvmsWebServer::CreateMenu[abi:cxx11](PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:393 0x4012d1e0: OvmsWebServer::HandleRoot(PageEntry&, PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:510 0x4012ebc1: PageEntry::Serve(PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 0x4012ecbd: OvmsWebServer::EventHandler(mg_connection*, int, void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f912d: mg_http_call_endpoint_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa27c: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa29a: mg_http_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa3e3: mg_recv_common at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa7ad: mg_if_recv_tcp_cb at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 (inlined by) mg_handle_tcp_read at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3723 (inlined by) mg_mgr_handle_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3844 0x400faa77: mg_socket_if_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f767e: mg_mgr_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400ee40a: OvmsNetManager::MongooseTask() at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:560 0x400ee459: MongooseRawTask(void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:545
On my development bench module I get this crash 1 in 4 times or so. On my real car, 100% of the time.
That code path leads into MyVehicleFactory.ActiveVehicleShortName(). Those should all be ‘const char*’, but it is possible for NULL to be returned. I will look into it in more detail.
Regards, Mark.
On 17 Nov 2018, at 7:35 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark, Tamás,
I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI.
Please see git log for details and send some screenshots.
Regards, Michael
Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson:
OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to use it, and support came down to just a few simple lines of code.
For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational.
c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with using std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way of doing that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of data ready to commit to metrics, so will need to think about this some more.
I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall aggregates, etc). There is a very basic ‘bms status’ command implemented.
Let me know what you think of it.
Regards, Mark
On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as… OvmsVehicle::ResetCellStats(); Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level? On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the vehicle / user.
There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion bitset, i.e. OvmsVehicle::RestartCellVoltages(); OvmsVehicle::RestartCellTemperatures(); …as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation.
Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these thresholds are currently fixed to… // Battery cell/cmod deviation alert thresholds: #define BATT_DEV_TEMP_ALERT 3 // = 3 °C #define BATT_DEV_VOLT_ALERT 6 // = 30 mV
// ...thresholds for overall stddev: #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV …these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. So these should be configurable, i.e. vehicle bms.dev.temp.alert [°C] vehicle bms.dev.voltage.alert [V] vehicle bms.stddev.temp.watch [°C] vehicle bms.stddev.temp.alert [°C] vehicle bms.stddev.voltage.watch [V] vehicle bms.stddev.voltage.alert [V] I can generalize the Twizy code for all of this.
The Twizy battery monitoring command set is: OVMS# xrt batt ? data-cell Output cell record data-pack Output pack record reset Reset alerts & watches status Status report tdev Show temperature deviations temp Show temperatures vdev Show voltage deviations volt Show voltages The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the output within the SMS msg size limit.
"status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and "tdev" show all cells.
The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set.
The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on the Twizy, sending a vector metric to the server is just a matter of… std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; msg.append(m_mon.m_mot_torque_drv->AsString()); MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str()); Neat.
The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a lot of additional data volume on large packs.
The Twizy layout may be either… 14 cell groups in the pack 2 cell groups in each module 7 modules in the pack Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) Each module has 1 temperature measurements (so, 7 individual temperature measurements) That means: OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) OvmsVehicle::SetCellArrangementTemperature(7, 1, 7) …for the original battery, or for an LFP type replacement…
16 cell groups in the pack 16 cell groups in each module 1 module in the pack Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) Each module has 3 temperature measurements (so, 3 individual temperature measurements) That means: OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) OvmsVehicle::SetCellArrangementTemperature(3, 3, 3)
Regards, Michael
Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson:
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@webb-johnson.net <mailto:mark@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@spjeldager.dk <mailto:henrik.scheel@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/ <http://www.spjeldager.dk/> >> >>> Den 10. nov. 2018 kl. 15.34 skrev ovmsdev-request@lists.openvehicles.com <mailto:ovmsdev-request@lists.openvehicles.com>: >>> >>> Send OvmsDev mailing list submissions to >>> ovmsdev@lists.openvehicles.com <mailto:ovmsdev@lists.openvehicles.com> >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>> or, via email, send a message with subject or body 'help' to >>> ovmsdev-request@lists.openvehicles.com <mailto:ovmsdev-request@lists.openvehicles.com> >>> >>> You can reach the person managing the list at >>> ovmsdev-owner@lists.openvehicles.com <mailto:ovmsdev-owner@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@webb-johnson.net> <mailto:mark@webb-johnson.net> >>> To: OVMS Developers <ovmsdev@lists.openvehicles.com> <mailto:ovmsdev@lists.openvehicles.com> >>> Subject: Re: [Ovmsdev] Custom metrics >>> Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@webb-johnson.net> <mailto:1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@expeedo.de> <mailto:dexter@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 likehttps://api.openvehicles.com:8080/VEHICLEID <https://api.openvehicles.com:8080/VEHICLEID> <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> <https://github.com/russdill/lwip/commit/dfeba616>. Another is TUN/TAP, again with reference code for LWIP <https://github.com/russdill/lwip/commit/47ca42f8> <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@expeedo.de <mailto:dexter@expeedo.de> <mailto:dexter@expeedo.de> <mailto:dexter@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> <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@expeedo.de <mailto:dexter@expeedo.de> <mailto:dexter@expeedo.de> <mailto:dexter@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><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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OvmsDev mailing list >>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OvmsDev mailing list >>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>> >>>
Yes, you can add a new menu to PageMenu_t like that. I suggest introducing a general tools menu instead of a specific one, i.e. "PageMenu_Tools". To still fit the menu on one line in tablet mode (width down to 768 px) I suggest moving the Shell into the tools menu then. Go ahead, I'm not working on the web framework at the moment. Regards, Michael Am 17.11.18 um 10:48 schrieb Mark Webb-Johnson:
Twizy code overrides the virtual short name function, so won’t suffer the issue.
I think it is a bug in vehicle factory (as modifying the vehicle type is reasonable), so fixed it there. Returning NULL is problematic. It would be so much easier for everything to return std::string, but concern is memory consumption and overhead.
I’d like to start converting RE TOOLS to just use the web server. First step is to work out how to add a menu onto the web server. It seems that the PageMenu_t is a fixed enum list (and similarly hard-coded in the web_framework.
Do I just add a ‘CAN bus’ menu there, by adding it to PageMenu_t, and supporting it where the other top level menus are? Or do you have any other suggestions/plans for this?
I don’t want to step on anything you are working on here.
The second stage will be to add displays under that, but I think that is fairly straight forward. I will mostly be displaying tables, and sending those over the web socket would be good.
Regards, Mark
On 17 Nov 2018, at 5:37 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
nice, thanks.
The short name is used for the menu label. It's meant to fall back to the long name (and seems to do so in your screenshot), so should not be null. But I admit I haven't tested it on a vehicle without a short name.
Btw, I'm currently working on the deviations and alerts.
Regards, Michael
Am 17.11.18 um 10:08 schrieb Mark Webb-Johnson:
Michael,
Looks good. It seems that you did everything necessary for the Model S already in your commit 2a84d861403f48142d6adcc16ad7a20cd458e427:
#include “ovms_webserver.h"
OvmsVehicleTeslaModelS::OvmsVehicleTeslaModelS() MyWebServer.RegisterPage("/bms/cellmon", "BMS cell monitor", OvmsWebServer::HandleBmsCellMonitor, PageMenu_Vehicle, PageAuth_Cookie);
OvmsVehicleTeslaModelS::~OvmsVehicleTeslaModelS() MyWebServer.DeregisterPage("/bms/cellmon");
From my devbench, replaying a CAN CRTD log file, I get this output:
<PastedGraphic-2.png>
The animation is very nice.
I am, however, getting crashes, as follows:
# xtensa-esp32-elf-addr2line -pfiaC -e 3.1.011-25-g2a84d86.ovms3.elf 0x400935d3 0x4009372b 0x400db90c 0x4012c0f7 0x4012d0e1 0x4012d1e0 0x4012ebc1 0x4012ecbd 0x400f8b65 0x400f912d 0x400fa27c 0x400fa29a 0x400f8b65 0x400fa3e3 0x400fa7ad 0x400faa77 0x400f767e 0x400ee40a 0x400ee459 0x400935d3: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 0x4009372b: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 0x400db90c: __cxx_fatal_exception_message at /home/openvehicles/build/esp-idf/components/cxx/cxx_exception_stubs.cpp:19 0x4012c0f7: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:216 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, char const*, std::__false_type) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457 0x4012d0e1: OvmsWebServer::CreateMenu[abi:cxx11](PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:393 0x4012d1e0: OvmsWebServer::HandleRoot(PageEntry&, PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:510 0x4012ebc1: PageEntry::Serve(PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 0x4012ecbd: OvmsWebServer::EventHandler(mg_connection*, int, void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f912d: mg_http_call_endpoint_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa27c: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa29a: mg_http_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa3e3: mg_recv_common at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa7ad: mg_if_recv_tcp_cb at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 (inlined by) mg_handle_tcp_read at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3723 (inlined by) mg_mgr_handle_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3844 0x400faa77: mg_socket_if_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f767e: mg_mgr_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400ee40a: OvmsNetManager::MongooseTask() at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:560 0x400ee459: MongooseRawTask(void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:545
On my development bench module I get this crash 1 in 4 times or so. On my real car, 100% of the time.
That code path leads into MyVehicleFactory.ActiveVehicleShortName(). Those should all be ‘const char*’, but it is possible for NULL to be returned. I will look into it in more detail.
Regards, Mark.
On 17 Nov 2018, at 7:35 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark, Tamás,
I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI.
Please see git log for details and send some screenshots.
Regards, Michael
Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson:
OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to use it, and support came down to just a few simple lines of code.
For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational.
c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with using std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way of doing that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of data ready to commit to metrics, so will need to think about this some more.
I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall aggregates, etc). There is a very basic ‘bms status’ command implemented.
Let me know what you think of it.
Regards, Mark
On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as…
* OvmsVehicle::ResetCellStats(); * Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level?
On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the vehicle / user.
There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion bitset, i.e.
* OvmsVehicle::RestartCellVoltages(); * OvmsVehicle::RestartCellTemperatures();
…as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation.
Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these thresholds are currently fixed to…
// Battery cell/cmod deviation alert thresholds: #define BATT_DEV_TEMP_ALERT 3 // = 3 °C #define BATT_DEV_VOLT_ALERT 6 // = 30 mV
// ...thresholds for overall stddev: #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV
…these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. So these should be configurable, i.e.
* vehicle bms.dev.temp.alert [°C] * vehicle bms.dev.voltage.alert [V] * vehicle bms.stddev.temp.watch [°C] * vehicle bms.stddev.temp.alert [°C] * vehicle bms.stddev.voltage.watch [V] * vehicle bms.stddev.voltage.alert [V]
I can generalize the Twizy code for all of this.
The Twizy battery monitoring command set is:
OVMS# xrt batt ? data-cell Output cell record data-pack Output pack record reset Reset alerts & watches status Status report tdev Show temperature deviations temp Show temperatures vdev Show voltage deviations volt Show voltages
The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the output within the SMS msg size limit.
"status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and "tdev" show all cells.
The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set.
The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on the Twizy, sending a vector metric to the server is just a matter of…
std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; msg.append(m_mon.m_mot_torque_drv->AsString()); MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str());
Neat.
The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a lot of additional data volume on large packs.
The Twizy layout may be either…
* 14 cell groups in the pack * 2 cell groups in each module * 7 modules in the pack * Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) * Each module has 1 temperature measurements (so, 7 individual temperature measurements) * That means: o OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) o OvmsVehicle::SetCellArrangementTemperature(7, 1, 7)
…for the original battery, or for an LFP type replacement…
* 16 cell groups in the pack * 16 cell groups in each module * 1 module in the pack * Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) * Each module has 3 temperature measurements (so, 3 individual temperature measurements) * That means: o OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) o OvmsVehicle::SetCellArrangementTemperature(3, 3, 3)
Regards, Michael
Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson: > 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: > o OvmsVehicle::SetCellArrangementVoltage(96, 6, 3) > o 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: > o OvmsVehicle::SetCellArrangementVoltage(99, 9, 9) > o 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: > o OvmsVehicle::SetCellArrangementVoltage(N, Y, Z) > o 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@webb-johnson.net <mailto:mark@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@spjeldager.dk <mailto:henrik.scheel@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@lists.openvehicles.com: >>>> >>>> Send OvmsDev mailing list submissions to >>>> ovmsdev@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@lists.openvehicles.com >>>> >>>> You can reach the person managing the list at >>>> ovmsdev-owner@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@webb-johnson.net> >>>> To: OVMS Developers <ovmsdev@lists.openvehicles.com> >>>> Subject: Re: [Ovmsdev] Custom metrics >>>> Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OvmsDev mailing list >>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OvmsDev mailing list >>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com >>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>>> >>>>
Ok. Will do. Now you remind me, bms looks good on iPhone:
On 17 Nov 2018, at 6:08 PM, Michael Balzer <dexter@expeedo.de> wrote:
Yes, you can add a new menu to PageMenu_t like that. I suggest introducing a general tools menu instead of a specific one, i.e. "PageMenu_Tools".
To still fit the menu on one line in tablet mode (width down to 768 px) I suggest moving the Shell into the tools menu then.
Go ahead, I'm not working on the web framework at the moment.
Regards, Michael
Am 17.11.18 um 10:48 schrieb Mark Webb-Johnson: Twizy code overrides the virtual short name function, so won’t suffer the issue.
I think it is a bug in vehicle factory (as modifying the vehicle type is reasonable), so fixed it there. Returning NULL is problematic. It would be so much easier for everything to return std::string, but concern is memory consumption and overhead.
I’d like to start converting RE TOOLS to just use the web server. First step is to work out how to add a menu onto the web server. It seems that the PageMenu_t is a fixed enum list (and similarly hard-coded in the web_framework.
Do I just add a ‘CAN bus’ menu there, by adding it to PageMenu_t, and supporting it where the other top level menus are? Or do you have any other suggestions/plans for this?
I don’t want to step on anything you are working on here.
The second stage will be to add displays under that, but I think that is fairly straight forward. I will mostly be displaying tables, and sending those over the web socket would be good.
Regards, Mark
On 17 Nov 2018, at 5:37 PM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
nice, thanks.
The short name is used for the menu label. It's meant to fall back to the long name (and seems to do so in your screenshot), so should not be null. But I admit I haven't tested it on a vehicle without a short name.
Btw, I'm currently working on the deviations and alerts.
Regards, Michael
Am 17.11.18 um 10:08 schrieb Mark Webb-Johnson: Michael,
Looks good. It seems that you did everything necessary for the Model S already in your commit 2a84d861403f48142d6adcc16ad7a20cd458e427:
#include “ovms_webserver.h"
OvmsVehicleTeslaModelS::OvmsVehicleTeslaModelS() MyWebServer.RegisterPage("/bms/cellmon", "BMS cell monitor", OvmsWebServer::HandleBmsCellMonitor, PageMenu_Vehicle, PageAuth_Cookie);
OvmsVehicleTeslaModelS::~OvmsVehicleTeslaModelS() MyWebServer.DeregisterPage("/bms/cellmon");
From my devbench, replaying a CAN CRTD log file, I get this output:
<PastedGraphic-2.png>
The animation is very nice.
I am, however, getting crashes, as follows:
# xtensa-esp32-elf-addr2line -pfiaC -e 3.1.011-25-g2a84d86.ovms3.elf 0x400935d3 0x4009372b 0x400db90c 0x4012c0f7 0x4012d0e1 0x4012d1e0 0x4012ebc1 0x4012ecbd 0x400f8b65 0x400f912d 0x400fa27c 0x400fa29a 0x400f8b65 0x400fa3e3 0x400fa7ad 0x400faa77 0x400f767e 0x400ee40a 0x400ee459 0x400935d3: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 0x4009372b: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 0x400db90c: __cxx_fatal_exception_message at /home/openvehicles/build/esp-idf/components/cxx/cxx_exception_stubs.cpp:19 0x4012c0f7: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:216 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, char const*, std::__false_type) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457 0x4012d0e1: OvmsWebServer::CreateMenu[abi:cxx11](PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:393 0x4012d1e0: OvmsWebServer::HandleRoot(PageEntry&, PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:510 0x4012ebc1: PageEntry::Serve(PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 0x4012ecbd: OvmsWebServer::EventHandler(mg_connection*, int, void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f912d: mg_http_call_endpoint_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa27c: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa29a: mg_http_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa3e3: mg_recv_common at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa7ad: mg_if_recv_tcp_cb at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 (inlined by) mg_handle_tcp_read at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3723 (inlined by) mg_mgr_handle_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3844 0x400faa77: mg_socket_if_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f767e: mg_mgr_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400ee40a: OvmsNetManager::MongooseTask() at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:560 0x400ee459: MongooseRawTask(void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:545
On my development bench module I get this crash 1 in 4 times or so. On my real car, 100% of the time.
That code path leads into MyVehicleFactory.ActiveVehicleShortName(). Those should all be ‘const char*’, but it is possible for NULL to be returned. I will look into it in more detail.
Regards, Mark.
On 17 Nov 2018, at 7:35 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark, Tamás,
I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI.
Please see git log for details and send some screenshots.
Regards, Michael
Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson: OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to use it, and support came down to just a few simple lines of code.
For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational.
c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with using std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way of doing that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of data ready to commit to metrics, so will need to think about this some more.
I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall aggregates, etc). There is a very basic ‘bms status’ command implemented.
Let me know what you think of it.
Regards, Mark
> On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de> wrote: > > Mark, > > yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as… > OvmsVehicle::ResetCellStats(); > Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level? > On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the vehicle / user. > > > There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion bitset, i.e. > OvmsVehicle::RestartCellVoltages(); > OvmsVehicle::RestartCellTemperatures(); > …as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation. > > > Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these thresholds are currently fixed to… > // Battery cell/cmod deviation alert thresholds: > #define BATT_DEV_TEMP_ALERT 3 // = 3 °C > #define BATT_DEV_VOLT_ALERT 6 // = 30 mV > > // ...thresholds for overall stddev: > #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C > #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C > #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV > #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV > …these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. So these should be configurable, i.e. > vehicle bms.dev.temp.alert [°C] > vehicle bms.dev.voltage.alert [V] > vehicle bms.stddev.temp.watch [°C] > vehicle bms.stddev.temp.alert [°C] > vehicle bms.stddev.voltage.watch [V] > vehicle bms.stddev.voltage.alert [V] > I can generalize the Twizy code for all of this. > > > The Twizy battery monitoring command set is: > OVMS# xrt batt ? > data-cell Output cell record > data-pack Output pack record > reset Reset alerts & watches > status Status report > tdev Show temperature deviations > temp Show temperatures > vdev Show voltage deviations > volt Show voltages > The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the output within the SMS msg size limit. > > "status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and "tdev" show all cells. > > The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set. > > > The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on the Twizy, sending a vector metric to the server is just a matter of… > std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; > msg.append(m_mon.m_mot_torque_drv->AsString()); > MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str()); > Neat. > > The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a lot of additional data volume on large packs. > > > The Twizy layout may be either… > 14 cell groups in the pack > 2 cell groups in each module > 7 modules in the pack > Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) > Each module has 1 temperature measurements (so, 7 individual temperature measurements) > That means: > OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) > OvmsVehicle::SetCellArrangementTemperature(7, 1, 7) > …for the original battery, or for an LFP type replacement… > > 16 cell groups in the pack > 16 cell groups in each module > 1 module in the pack > Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) > Each module has 3 temperature measurements (so, 3 individual temperature measurements) > That means: > OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) > OvmsVehicle::SetCellArrangementTemperature(3, 3, 3) > > Regards, > Michael > > >> Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson: >> 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@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@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@lists.openvehicles.com: >>>>> >>>>> Send OvmsDev mailing list submissions to >>>>> ovmsdev@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@lists.openvehicles.com >>>>> >>>>> You can reach the person managing the list at >>>>> ovmsdev-owner@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@webb-johnson.net> >>>>> To: OVMS Developers <ovmsdev@lists.openvehicles.com> >>>>> Subject: Re: [Ovmsdev] Custom metrics >>>>> Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OvmsDev mailing list >>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OvmsDev mailing list >>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com >>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>>>> >>>>>
Short video showing Model S charging; https://youtu.be/Q4vMPSwBFAo
On 17 Nov 2018, at 6:13 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Ok. Will do.
Now you remind me, bms looks good on iPhone:
<image1.jpeg>
On 17 Nov 2018, at 6:08 PM, Michael Balzer <dexter@expeedo.de> wrote:
Yes, you can add a new menu to PageMenu_t like that. I suggest introducing a general tools menu instead of a specific one, i.e. "PageMenu_Tools".
To still fit the menu on one line in tablet mode (width down to 768 px) I suggest moving the Shell into the tools menu then.
Go ahead, I'm not working on the web framework at the moment.
Regards, Michael
Am 17.11.18 um 10:48 schrieb Mark Webb-Johnson: Twizy code overrides the virtual short name function, so won’t suffer the issue.
I think it is a bug in vehicle factory (as modifying the vehicle type is reasonable), so fixed it there. Returning NULL is problematic. It would be so much easier for everything to return std::string, but concern is memory consumption and overhead.
I’d like to start converting RE TOOLS to just use the web server. First step is to work out how to add a menu onto the web server. It seems that the PageMenu_t is a fixed enum list (and similarly hard-coded in the web_framework.
Do I just add a ‘CAN bus’ menu there, by adding it to PageMenu_t, and supporting it where the other top level menus are? Or do you have any other suggestions/plans for this?
I don’t want to step on anything you are working on here.
The second stage will be to add displays under that, but I think that is fairly straight forward. I will mostly be displaying tables, and sending those over the web socket would be good.
Regards, Mark
On 17 Nov 2018, at 5:37 PM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
nice, thanks.
The short name is used for the menu label. It's meant to fall back to the long name (and seems to do so in your screenshot), so should not be null. But I admit I haven't tested it on a vehicle without a short name.
Btw, I'm currently working on the deviations and alerts.
Regards, Michael
Am 17.11.18 um 10:08 schrieb Mark Webb-Johnson: Michael,
Looks good. It seems that you did everything necessary for the Model S already in your commit 2a84d861403f48142d6adcc16ad7a20cd458e427:
#include “ovms_webserver.h"
OvmsVehicleTeslaModelS::OvmsVehicleTeslaModelS() MyWebServer.RegisterPage("/bms/cellmon", "BMS cell monitor", OvmsWebServer::HandleBmsCellMonitor, PageMenu_Vehicle, PageAuth_Cookie);
OvmsVehicleTeslaModelS::~OvmsVehicleTeslaModelS() MyWebServer.DeregisterPage("/bms/cellmon");
From my devbench, replaying a CAN CRTD log file, I get this output:
<PastedGraphic-2.png>
The animation is very nice.
I am, however, getting crashes, as follows:
# xtensa-esp32-elf-addr2line -pfiaC -e 3.1.011-25-g2a84d86.ovms3.elf 0x400935d3 0x4009372b 0x400db90c 0x4012c0f7 0x4012d0e1 0x4012d1e0 0x4012ebc1 0x4012ecbd 0x400f8b65 0x400f912d 0x400fa27c 0x400fa29a 0x400f8b65 0x400fa3e3 0x400fa7ad 0x400faa77 0x400f767e 0x400ee40a 0x400ee459 0x400935d3: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 0x4009372b: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 0x400db90c: __cxx_fatal_exception_message at /home/openvehicles/build/esp-idf/components/cxx/cxx_exception_stubs.cpp:19 0x4012c0f7: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:216 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, char const*, std::__false_type) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457 0x4012d0e1: OvmsWebServer::CreateMenu[abi:cxx11](PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:393 0x4012d1e0: OvmsWebServer::HandleRoot(PageEntry&, PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:510 0x4012ebc1: PageEntry::Serve(PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 0x4012ecbd: OvmsWebServer::EventHandler(mg_connection*, int, void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f912d: mg_http_call_endpoint_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa27c: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa29a: mg_http_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa3e3: mg_recv_common at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa7ad: mg_if_recv_tcp_cb at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 (inlined by) mg_handle_tcp_read at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3723 (inlined by) mg_mgr_handle_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3844 0x400faa77: mg_socket_if_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f767e: mg_mgr_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400ee40a: OvmsNetManager::MongooseTask() at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:560 0x400ee459: MongooseRawTask(void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:545
On my development bench module I get this crash 1 in 4 times or so. On my real car, 100% of the time.
That code path leads into MyVehicleFactory.ActiveVehicleShortName(). Those should all be ‘const char*’, but it is possible for NULL to be returned. I will look into it in more detail.
Regards, Mark.
On 17 Nov 2018, at 7:35 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark, Tamás,
I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI.
Please see git log for details and send some screenshots.
Regards, Michael
> Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson: > OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to use it, and support came down to just a few simple lines of code. > > For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational. > > c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with using std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way of doing that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of data ready to commit to metrics, so will need to think about this some more. > > I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall aggregates, etc). There is a very basic ‘bms status’ command implemented. > > Let me know what you think of it. > > Regards, Mark > >> On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de> wrote: >> >> Mark, >> >> yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as… >> OvmsVehicle::ResetCellStats(); >> Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level? >> On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the vehicle / user. >> >> >> There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion bitset, i.e. >> OvmsVehicle::RestartCellVoltages(); >> OvmsVehicle::RestartCellTemperatures(); >> …as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation. >> >> >> Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these thresholds are currently fixed to… >> // Battery cell/cmod deviation alert thresholds: >> #define BATT_DEV_TEMP_ALERT 3 // = 3 °C >> #define BATT_DEV_VOLT_ALERT 6 // = 30 mV >> >> // ...thresholds for overall stddev: >> #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C >> #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C >> #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV >> #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV >> …these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. So these should be configurable, i.e. >> vehicle bms.dev.temp.alert [°C] >> vehicle bms.dev.voltage.alert [V] >> vehicle bms.stddev.temp.watch [°C] >> vehicle bms.stddev.temp.alert [°C] >> vehicle bms.stddev.voltage.watch [V] >> vehicle bms.stddev.voltage.alert [V] >> I can generalize the Twizy code for all of this. >> >> >> The Twizy battery monitoring command set is: >> OVMS# xrt batt ? >> data-cell Output cell record >> data-pack Output pack record >> reset Reset alerts & watches >> status Status report >> tdev Show temperature deviations >> temp Show temperatures >> vdev Show voltage deviations >> volt Show voltages >> The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the output within the SMS msg size limit. >> >> "status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and "tdev" show all cells. >> >> The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set. >> >> >> The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on the Twizy, sending a vector metric to the server is just a matter of… >> std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; >> msg.append(m_mon.m_mot_torque_drv->AsString()); >> MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str()); >> Neat. >> >> The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a lot of additional data volume on large packs. >> >> >> The Twizy layout may be either… >> 14 cell groups in the pack >> 2 cell groups in each module >> 7 modules in the pack >> Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) >> Each module has 1 temperature measurements (so, 7 individual temperature measurements) >> That means: >> OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) >> OvmsVehicle::SetCellArrangementTemperature(7, 1, 7) >> …for the original battery, or for an LFP type replacement… >> >> 16 cell groups in the pack >> 16 cell groups in each module >> 1 module in the pack >> Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) >> Each module has 3 temperature measurements (so, 3 individual temperature measurements) >> That means: >> OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) >> OvmsVehicle::SetCellArrangementTemperature(3, 3, 3) >> >> Regards, >> Michael >> >> >>> Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson: >>> 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@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@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@lists.openvehicles.com: >>>>>> >>>>>> Send OvmsDev mailing list submissions to >>>>>> ovmsdev@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@lists.openvehicles.com >>>>>> >>>>>> You can reach the person managing the list at >>>>>> ovmsdev-owner@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@webb-johnson.net> >>>>>> To: OVMS Developers <ovmsdev@lists.openvehicles.com> >>>>>> Subject: Re: [Ovmsdev] Custom metrics >>>>>> Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OvmsDev mailing list >>>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OvmsDev mailing list >>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com >>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>>>>> >>>>>>
First implementation of general cell deviation checking and alerts is pushed. Vehicle BMS: cell deviations & alerts Renamed metrics: - v.b.c.level.* → v.b.p.level.* (for consistency) New metrics: - v.b.c.(voltage,temp).(dev.max,alert) - v.b.p.(voltage,temp).(min,max,avg,stddev,stddev.max) New configs: - vehicle [bms.dev.voltage.warn] -- threshold [V] - vehicle [bms.dev.voltage.alert] -- threshold [V] - vehicle [bms.dev.temp.warn] -- threshold [°C] - vehicle [bms.dev.temp.alert] -- threshold [°C] …all optional, default: warn at 120% stddev, alert at 200% stddev New commands: - bms alerts → show cells with warn/alert levels I changed the config scheme hoping a manual configuration normally isn't necessary with this automatic adaption to the standard deviation. Please check and report if that idea works. If it doesn't, please report the deviations and necessary threshold levels on your batteries. I also omitted the overall stddev alerts for now, I don't think those really are necessary, haven't had a single trigger on the Twizy for this. Integration into the web chart page and historical data updates are still todo. Migration for the Twizy battery monitor to the generalized scheme is in progress. Regards, Michael Am 17.11.18 um 11:53 schrieb Mark Webb-Johnson:
Short video showing Model S charging;
On 17 Nov 2018, at 6:13 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
Ok. Will do.
Now you remind me, bms looks good on iPhone:
<image1.jpeg>
On 17 Nov 2018, at 6:08 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Yes, you can add a new menu to PageMenu_t like that. I suggest introducing a general tools menu instead of a specific one, i.e. "PageMenu_Tools".
To still fit the menu on one line in tablet mode (width down to 768 px) I suggest moving the Shell into the tools menu then.
Go ahead, I'm not working on the web framework at the moment.
Regards, Michael
Am 17.11.18 um 10:48 schrieb Mark Webb-Johnson:
Twizy code overrides the virtual short name function, so won’t suffer the issue.
I think it is a bug in vehicle factory (as modifying the vehicle type is reasonable), so fixed it there. Returning NULL is problematic. It would be so much easier for everything to return std::string, but concern is memory consumption and overhead.
I’d like to start converting RE TOOLS to just use the web server. First step is to work out how to add a menu onto the web server. It seems that the PageMenu_t is a fixed enum list (and similarly hard-coded in the web_framework.
Do I just add a ‘CAN bus’ menu there, by adding it to PageMenu_t, and supporting it where the other top level menus are? Or do you have any other suggestions/plans for this?
I don’t want to step on anything you are working on here.
The second stage will be to add displays under that, but I think that is fairly straight forward. I will mostly be displaying tables, and sending those over the web socket would be good.
Regards, Mark
On 17 Nov 2018, at 5:37 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
nice, thanks.
The short name is used for the menu label. It's meant to fall back to the long name (and seems to do so in your screenshot), so should not be null. But I admit I haven't tested it on a vehicle without a short name.
Btw, I'm currently working on the deviations and alerts.
Regards, Michael
Am 17.11.18 um 10:08 schrieb Mark Webb-Johnson:
Michael,
Looks good. It seems that you did everything necessary for the Model S already in your commit 2a84d861403f48142d6adcc16ad7a20cd458e427:
#include “ovms_webserver.h"
OvmsVehicleTeslaModelS::OvmsVehicleTeslaModelS() MyWebServer.RegisterPage("/bms/cellmon", "BMS cell monitor", OvmsWebServer::HandleBmsCellMonitor, PageMenu_Vehicle, PageAuth_Cookie);
OvmsVehicleTeslaModelS::~OvmsVehicleTeslaModelS() MyWebServer.DeregisterPage("/bms/cellmon");
From my devbench, replaying a CAN CRTD log file, I get this output:
<PastedGraphic-2.png>
The animation is very nice.
I am, however, getting crashes, as follows:
# xtensa-esp32-elf-addr2line -pfiaC -e 3.1.011-25-g2a84d86.ovms3.elf 0x400935d3 0x4009372b 0x400db90c 0x4012c0f7 0x4012d0e1 0x4012d1e0 0x4012ebc1 0x4012ecbd 0x400f8b65 0x400f912d 0x400fa27c 0x400fa29a 0x400f8b65 0x400fa3e3 0x400fa7ad 0x400faa77 0x400f767e 0x400ee40a 0x400ee459 0x400935d3: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 0x4009372b: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 0x400db90c: __cxx_fatal_exception_message at /home/openvehicles/build/esp-idf/components/cxx/cxx_exception_stubs.cpp:19 0x4012c0f7: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:216 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, char const*, std::__false_type) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457 0x4012d0e1: OvmsWebServer::CreateMenu[abi:cxx11](PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:393 0x4012d1e0: OvmsWebServer::HandleRoot(PageEntry&, PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:510 0x4012ebc1: PageEntry::Serve(PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 0x4012ecbd: OvmsWebServer::EventHandler(mg_connection*, int, void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f912d: mg_http_call_endpoint_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa27c: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa29a: mg_http_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa3e3: mg_recv_common at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa7ad: mg_if_recv_tcp_cb at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 (inlined by) mg_handle_tcp_read at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3723 (inlined by) mg_mgr_handle_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3844 0x400faa77: mg_socket_if_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f767e: mg_mgr_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400ee40a: OvmsNetManager::MongooseTask() at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:560 0x400ee459: MongooseRawTask(void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:545
On my development bench module I get this crash 1 in 4 times or so. On my real car, 100% of the time.
That code path leads into MyVehicleFactory.ActiveVehicleShortName(). Those should all be ‘const char*’, but it is possible for NULL to be returned. I will look into it in more detail.
Regards, Mark.
> On 17 Nov 2018, at 7:35 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: > > Mark, Tamás, > > I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI. > > Please see git log for details and send some screenshots. > > Regards, > Michael > > > Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson: >> OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to use >> it, and support came down to just a few simple lines of code. >> >> For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational. >> >> c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with using >> std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way of doing >> that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of data ready to >> commit to metrics, so will need to think about this some more. >> >> I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall >> aggregates, etc). There is a very basic ‘bms status’ command implemented. >> >> Let me know what you think of it. >> >> Regards, Mark >> >>> On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>> >>> Mark, >>> >>> yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as… >>> >>> * OvmsVehicle::ResetCellStats(); >>> * Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level? >>> >>> On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the >>> vehicle / user. >>> >>> >>> There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated by >>> the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion bitset, i.e. >>> >>> * OvmsVehicle::RestartCellVoltages(); >>> * OvmsVehicle::RestartCellTemperatures(); >>> >>> …as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation. >>> >>> >>> Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation thresholds, >>> and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for normal stddev and >>> one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these thresholds are >>> currently fixed to… >>> >>> // Battery cell/cmod deviation alert thresholds: >>> #define BATT_DEV_TEMP_ALERT 3 // = 3 °C >>> #define BATT_DEV_VOLT_ALERT 6 // = 30 mV >>> >>> // ...thresholds for overall stddev: >>> #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C >>> #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C >>> #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV >>> #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV >>> >>> …these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. So >>> these should be configurable, i.e. >>> >>> * vehicle bms.dev.temp.alert [°C] >>> * vehicle bms.dev.voltage.alert [V] >>> * vehicle bms.stddev.temp.watch [°C] >>> * vehicle bms.stddev.temp.alert [°C] >>> * vehicle bms.stddev.voltage.watch [V] >>> * vehicle bms.stddev.voltage.alert [V] >>> >>> I can generalize the Twizy code for all of this. >>> >>> >>> The Twizy battery monitoring command set is: >>> >>> OVMS# xrt batt ? >>> data-cell Output cell record >>> data-pack Output pack record >>> reset Reset alerts & watches >>> status Status report >>> tdev Show temperature deviations >>> temp Show temperatures >>> vdev Show voltage deviations >>> volt Show voltages >>> >>> The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the output >>> within the SMS msg size limit. >>> >>> "status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and "tdev" >>> show all cells. >>> >>> The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set. >>> >>> >>> The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on the >>> Twizy, sending a vector metric to the server is just a matter of… >>> >>> std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; >>> msg.append(m_mon.m_mot_torque_drv->AsString()); >>> MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str()); >>> >>> Neat. >>> >>> The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a lot >>> of additional data volume on large packs. >>> >>> >>> The Twizy layout may be either… >>> >>> * 14 cell groups in the pack >>> * 2 cell groups in each module >>> * 7 modules in the pack >>> * Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) >>> * Each module has 1 temperature measurements (so, 7 individual temperature measurements) >>> * That means: >>> o OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) >>> o OvmsVehicle::SetCellArrangementTemperature(7, 1, 7) >>> >>> …for the original battery, or for an LFP type replacement… >>> >>> * 16 cell groups in the pack >>> * 16 cell groups in each module >>> * 1 module in the pack >>> * Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) >>> * Each module has 3 temperature measurements (so, 3 individual temperature measurements) >>> * That means: >>> o OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) >>> o OvmsVehicle::SetCellArrangementTemperature(3, 3, 3) >>> >>> >>> Regards, >>> Michael >>> >>> >>> Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson: >>>> 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: >>>> o OvmsVehicle::SetCellArrangementVoltage(96, 6, 3) >>>> o 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: >>>> o OvmsVehicle::SetCellArrangementVoltage(99, 9, 9) >>>> o 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: >>>> o OvmsVehicle::SetCellArrangementVoltage(N, Y, Z) >>>> o 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@webb-johnson.net <mailto:mark@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@spjeldager.dk <mailto:henrik.scheel@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@lists.openvehicles.com: >>>>>>> >>>>>>> Send OvmsDev mailing list submissions to >>>>>>> ovmsdev@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@lists.openvehicles.com >>>>>>> >>>>>>> You can reach the person managing the list at >>>>>>> ovmsdev-owner@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@webb-johnson.net> >>>>>>> To: OVMS Developers <ovmsdev@lists.openvehicles.com> >>>>>>> Subject: Re: [Ovmsdev] Custom metrics >>>>>>> Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OvmsDev mailing list >>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com >>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>>>>>> >>>>>>>
Not really sure how to interpret this. I get: OVMS# bms alerts Voltage: SD=7mV !1:-7mV !2:-4mV !3:-4mV !4:-5mV !5:-5mV !6:-6mV !7:-1mV !8:+2mV !9:+0mV !10:+0mV !11:+0mV !12:-2mV ?13:+0mV !14:+4mV !15:+2mV !16:+2mV !17:+0mV !18:+0mV !19:-3mV !20:+0mV !21:-1mV ?22:+0mV !23:-2mV !24:-2mV !26:+2mV !27:+1mV !28:+2mV ?29:+0mV !30:+0mV !31:-2mV ?33:+0mV !35:-1mV !36:-2mV ?37:-5mV !38:-3mV !39:-2mV !40:-2mV !41:-4mV !42:-6mV !43:-3mV !44:+0mV !45:-1mV !46:-1mV !47:-1mV !48:-1mV !49:+6mV !50:+7mV !51:+6mV !52:+8mV !53:+7mV !54:+6mV !55:+1mV !56:+4mV !57:+1mV !58:+4mV !59:+0mV !60:+0mV !61:+3mV !62:+5mV !63:+4mV !64:+4mV !65:+2mV !66:+3mV !67:-1mV !68:+2mV !69:+1mV !70:+1mV !71:-1mV !72:-1mV !74:+2mV !76:+1mV ?77:+0mV !78:-1mV !79:+1mV !80:+3mV !81:+1mV !82:+2mV !83:+2mV !84:+1mV !85:-3mV !86:+2mV !87:-1mV !88:-1mV !89:-3mV !90:-2mV !91:-2mV !92:-1mV !93:-2mV !94:-2mV !95:-3mV !96:-4mV Temperature: SD=0.6C ?1:+0.5C ?2:+1.0C ?3:+0.3C ?4:+0.3C ?5:-0.2C ?7:-0.3C ?9:-0.2C !10:-0.2C ?12:-0.4C ?13:-0.3C ?14:-0.4C ?15:-0.5C ?16:-0.3C ?17:+0.8C !18:-0.3C ?19:-0.1C ?20:-0.3C ?21:-0.1C !22:-0.4C !24:-0.5C ?25:-0.3C ?26:-0.4C ?28:-0.3C ?29:+0.7C ?30:+0.3C ?31:+0.9C ?32:+0.5C OVMS# metrics list v.b.c v.b.c.temp 28.8652,29.4386,28.6334,28.6822,28.1942,28.5114,28.1454,28.4626,28.182,28.3406,28.3894,28.121,28.1088,28.1454,28.0112,28.182,28.9262,28.243,28.2674,28.2186,28.2918,28.0844,28.3528,28.0356,28.1454,28.1088,28.4626,28.2186,28.975,28.7554,29.0604,28.9384°C v.b.c.temp.alert 1,2,1,1,1,1,1,0,1,2,0,1,1,1,1,1,2,2,1,1,1,1,1,1,1,1,0,1,2,1,1,2 v.b.c.temp.dev.max 0.52,1.03,0.31,0.26,-0.23,0.1,-0.29,-0.07,-0.25,-0.18,0.04,-0.44,-0.31,-0.39,-0.46,-0.34,0.76,-0.27,-0.15,-0.3,-0.13,-0.45,-0.08,-0.49,-0.28,-0.41,0.09,-0.28,0.73,0.34,0.92,0.52°C v.b.c.temp.max 28.8774,29.4386,28.6578,28.6822,28.1942,28.5236,28.1454,28.4626,28.182,28.3406,28.3894,28.121,28.1088,28.1454,28.0112,28.182,29.1092,28.243,28.2674,28.2186,28.2918,28.0844,28.3528,28.0356,28.1576,28.1088,28.4626,28.2186,29.0848,28.7554,29.2678,28.9384°C v.b.c.temp.min 28.853,29.3654,28.6212,28.5724,28.1332,28.3894,28.1088,28.2796,28.1332,28.1698,28.3894,27.9136,28.0966,27.9624,27.9014,28.0112,28.9262,28.0844,28.2674,28.0478,28.2796,27.9014,28.3406,27.8648,28.121,27.938,28.426,28.0722,28.975,28.609,29.0604,28.8042°C v.b.c.voltage 4.13794,4.14099,4.14099,4.14099,4.14007,4.13915,4.14465,4.1477,4.14586,4.14556,4.14465,4.14373,4.14556,4.14922,4.14739,4.14709,4.14586,4.14586,4.14251,4.14556,4.14434,4.14495,4.14373,4.14342,4.14586,4.148,4.14586,4.14709,4.14526,4.14526,4.14342,4.14556,4.14526,4.14556,4.14434,4.14342,4.14038,4.14251,4.14282,4.14312,4.14099,4.13946,4.14251,4.14586,4.14434,4.14465,4.14465,4.14434,4.15197,4.15318,4.15166,4.1541,4.15318,4.15166,4.14709,4.14922,4.14709,4.14861,4.14617,4.14586,4.148,4.15074,4.14983,4.15044,4.1477,4.148,4.14465,4.148,4.14678,4.14647,4.14403,4.14403,4.14556,4.148,4.14586,4.14647,4.14465,4.14526,4.14617,4.148,4.14617,4.14647,4.14739,4.14678,4.14251,4.14709,4.14373,4.14434,4.14282,4.14373,4.14312,4.14465,4.14282,4.14312,4.14282,4.1419V v.b.c.voltage.alert 2,1,1,1,1,1,2,1,2,2,2,2,1,1,1,2,2,2,1,2,2,1,1,1,0,1,2,2,1,2,1,0,1,0,2,2,1,1,1,1,1,1,1,2,2,2,2,2,1,2,1,2,2,1,2,1,2,1,2,2,1,1,1,1,1,1,2,1,2,2,2,2,0,1,0,2,1,2,2,1,2,2,2,2,1,2,2,2,1,1,1,2,1,1,1,1 v.b.c.voltage.dev.max -0.0082,-0.00487,-0.00498,-0.00508,-0.00583,-0.00674,-0.00139,0.00257,0.00096,0.00086,-0.00096,-0.00221,-0.00061,0.004,0.00275,0.00217,0.00096,0.00077,-0.0034,0.00081,-0.0017,-0.00091,-0.00234,-0.00304,0.00068,0.00288,0.00124,0.0022,-0.00052,-0.00078,-0.0024,0.00095,-0.00103,-0.00061,-0.00179,-0.00224,-0.00546,-0.00335,-0.0032,-0.00271,-0.00506,-0.00644,-0.0036,0.00087,-0.00129,-0.00168,-0.00139,-0.00132,0.00648,0.00824,0.00648,0.00883,0.0081,0.00641,0.00161,0.00443,0.00222,0.00401,0.00096,0.00095,0.00342,0.00597,0.00469,0.00505,0.00318,0.00315,-0.00127,0.00291,0.00132,0.00197,-0.0024,-0.00168,-0.00072,0.00275,0.00069,0.00184,-0.00096,-0.0012,0.00125,0.0032,0.00166,0.00203,0.00291,0.00153,-0.00355,0.00214,-0.00225,-0.00171,-0.003,-0.00249,-0.00292,-0.00152,-0.00295,-0.00296,-0.00311,-0.00432V v.b.c.voltage.max 4.13794,4.14129,4.14099,4.14099,4.14007,4.13915,4.14465,4.1477,4.14586,4.14586,4.14556,4.14403,4.14556,4.14922,4.1477,4.14709,4.14586,4.14586,4.14251,4.14586,4.14434,4.14495,4.14373,4.14342,4.14586,4.148,4.14617,4.14709,4.14556,4.14526,4.14342,4.14586,4.14526,4.14556,4.14434,4.14373,4.14099,4.14282,4.14282,4.14312,4.14099,4.13946,4.14282,4.14617,4.14465,4.14465,4.14465,4.14434,4.15197,4.15349,4.15197,4.1541,4.15318,4.15166,4.14709,4.14922,4.14709,4.14861,4.14617,4.14647,4.14861,4.15105,4.15014,4.15044,4.1483,4.1483,4.14465,4.148,4.14678,4.14709,4.14403,4.14403,4.14556,4.148,4.14586,4.14709,4.14526,4.14526,4.14647,4.148,4.14709,4.14739,4.1483,4.14678,4.14282,4.14709,4.14403,4.14434,4.14312,4.14373,4.14312,4.14465,4.14312,4.14312,4.14312,4.1419V v.b.c.voltage.min 4.13123,4.13427,4.13397,4.13397,4.13336,4.13214,4.13732,4.14038,4.13915,4.13885,4.13794,4.13641,4.13824,4.14159,4.14068,4.14007,4.13855,4.13824,4.1355,4.13885,4.13702,4.13794,4.13611,4.1358,4.13855,4.14099,4.13915,4.14007,4.13794,4.13794,4.13641,4.13855,4.13794,4.13824,4.13702,4.13641,4.13367,4.1358,4.1355,4.1358,4.13397,4.13275,4.13488,4.13855,4.13702,4.13702,4.13702,4.13732,4.14342,4.14586,4.14403,4.14617,4.14526,4.14403,4.13824,4.14159,4.13946,4.14038,4.13824,4.13824,4.14099,4.14342,4.14251,4.14251,4.14068,4.14038,4.13732,4.14099,4.13946,4.13976,4.13671,4.13671,4.13794,4.14038,4.13824,4.13946,4.13763,4.13763,4.13885,4.14038,4.13915,4.13946,4.14068,4.13885,4.1355,4.14007,4.13671,4.13732,4.13611,4.13641,4.13641,4.13732,4.13611,4.13641,4.13611,4.13458V v.b.cac v.b.consumption 0Wh/km v.b.coulomb.recd v.b.coulomb.used v.b.current OVMS# metrics list v.b.p v.b.p.level.avg v.b.p.level.max v.b.p.level.min v.b.p.level.stddev v.b.p.temp.avg 28.43°C v.b.p.temp.max 29.4508°C v.b.p.temp.min 28.0234°C v.b.p.temp.stddev 0.36°C v.b.p.temp.stddev.max 0.65°C v.b.p.voltage.avg 4.14669V v.b.p.voltage.max 4.15532V v.b.p.voltage.min 4.13855V v.b.p.voltage.stddev 0.00669V v.b.p.voltage.stddev.max 0.00717V v.b.power And a bunch of push notifications every time I connect the App, like this: Regards, Mark
On 17 Nov 2018, at 10:51 PM, Michael Balzer <dexter@expeedo.de> wrote:
First implementation of general cell deviation checking and alerts is pushed.
Vehicle BMS: cell deviations & alerts
Renamed metrics: - v.b.c.level.* → v.b.p.level.* (for consistency)
New metrics: - v.b.c.(voltage,temp).(dev.max,alert) - v.b.p.(voltage,temp).(min,max,avg,stddev,stddev.max)
New configs: - vehicle [bms.dev.voltage.warn] -- threshold [V] - vehicle [bms.dev.voltage.alert] -- threshold [V] - vehicle [bms.dev.temp.warn] -- threshold [°C] - vehicle [bms.dev.temp.alert] -- threshold [°C] …all optional, default: warn at 120% stddev, alert at 200% stddev
New commands: - bms alerts → show cells with warn/alert levels
I changed the config scheme hoping a manual configuration normally isn't necessary with this automatic adaption to the standard deviation.
Please check and report if that idea works. If it doesn't, please report the deviations and necessary threshold levels on your batteries.
I also omitted the overall stddev alerts for now, I don't think those really are necessary, haven't had a single trigger on the Twizy for this.
Integration into the web chart page and historical data updates are still todo.
Migration for the Twizy battery monitor to the generalized scheme is in progress.
Regards, Michael
Am 17.11.18 um 11:53 schrieb Mark Webb-Johnson:
Short video showing Model S charging;
https://youtu.be/Q4vMPSwBFAo <https://youtu.be/Q4vMPSwBFAo>
On 17 Nov 2018, at 6:13 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
Ok. Will do.
Now you remind me, bms looks good on iPhone:
<image1.jpeg>
On 17 Nov 2018, at 6:08 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Yes, you can add a new menu to PageMenu_t like that. I suggest introducing a general tools menu instead of a specific one, i.e. "PageMenu_Tools".
To still fit the menu on one line in tablet mode (width down to 768 px) I suggest moving the Shell into the tools menu then.
Go ahead, I'm not working on the web framework at the moment.
Regards, Michael
Am 17.11.18 um 10:48 schrieb Mark Webb-Johnson:
Twizy code overrides the virtual short name function, so won’t suffer the issue.
I think it is a bug in vehicle factory (as modifying the vehicle type is reasonable), so fixed it there. Returning NULL is problematic. It would be so much easier for everything to return std::string, but concern is memory consumption and overhead.
I’d like to start converting RE TOOLS to just use the web server. First step is to work out how to add a menu onto the web server. It seems that the PageMenu_t is a fixed enum list (and similarly hard-coded in the web_framework.
Do I just add a ‘CAN bus’ menu there, by adding it to PageMenu_t, and supporting it where the other top level menus are? Or do you have any other suggestions/plans for this?
I don’t want to step on anything you are working on here.
The second stage will be to add displays under that, but I think that is fairly straight forward. I will mostly be displaying tables, and sending those over the web socket would be good.
Regards, Mark
On 17 Nov 2018, at 5:37 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
nice, thanks.
The short name is used for the menu label. It's meant to fall back to the long name (and seems to do so in your screenshot), so should not be null. But I admit I haven't tested it on a vehicle without a short name.
Btw, I'm currently working on the deviations and alerts.
Regards, Michael
Am 17.11.18 um 10:08 schrieb Mark Webb-Johnson: > Michael, > > Looks good. It seems that you did everything necessary for the Model S already in your commit 2a84d861403f48142d6adcc16ad7a20cd458e427: > > #include “ovms_webserver.h" > > OvmsVehicleTeslaModelS::OvmsVehicleTeslaModelS() > MyWebServer.RegisterPage("/bms/cellmon", "BMS cell monitor", OvmsWebServer::HandleBmsCellMonitor, PageMenu_Vehicle, PageAuth_Cookie); > > OvmsVehicleTeslaModelS::~OvmsVehicleTeslaModelS() > MyWebServer.DeregisterPage("/bms/cellmon"); > > From my devbench, replaying a CAN CRTD log file, I get this output: > > <PastedGraphic-2.png> > > The animation is very nice. > > I am, however, getting crashes, as follows: > > # xtensa-esp32-elf-addr2line -pfiaC -e 3.1.011-25-g2a84d86.ovms3.elf 0x400935d3 0x4009372b 0x400db90c 0x4012c0f7 0x4012d0e1 0x4012d1e0 0x4012ebc1 0x4012ecbd 0x400f8b65 0x400f912d 0x400fa27c 0x400fa29a 0x400f8b65 0x400fa3e3 0x400fa7ad 0x400faa77 0x400f767e 0x400ee40a 0x400ee459 > 0x400935d3: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 > 0x4009372b: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 > 0x400db90c: __cxx_fatal_exception_message at /home/openvehicles/build/esp-idf/components/cxx/cxx_exception_stubs.cpp:19 > 0x4012c0f7: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:216 > (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, char const*, std::__false_type) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195 > (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214 > (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457 > 0x4012d0e1: OvmsWebServer::CreateMenu[abi:cxx11](PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:393 > 0x4012d1e0: OvmsWebServer::HandleRoot(PageEntry&, PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:510 > 0x4012ebc1: PageEntry::Serve(PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 > 0x4012ecbd: OvmsWebServer::EventHandler(mg_connection*, int, void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 > 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 > 0x400f912d: mg_http_call_endpoint_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 > 0x400fa27c: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 > 0x400fa29a: mg_http_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 > 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 > 0x400fa3e3: mg_recv_common at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 > 0x400fa7ad: mg_if_recv_tcp_cb at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 > (inlined by) mg_handle_tcp_read at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3723 > (inlined by) mg_mgr_handle_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3844 > 0x400faa77: mg_socket_if_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 > 0x400f767e: mg_mgr_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 > 0x400ee40a: OvmsNetManager::MongooseTask() at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:560 > 0x400ee459: MongooseRawTask(void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:545 > > On my development bench module I get this crash 1 in 4 times or so. On my real car, 100% of the time. > > That code path leads into MyVehicleFactory.ActiveVehicleShortName(). Those should all be ‘const char*’, but it is possible for NULL to be returned. I will look into it in more detail. > > Regards, Mark. > >> On 17 Nov 2018, at 7:35 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >> >> Mark, Tamás, >> >> I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI. >> >> Please see git log for details and send some screenshots. >> >> Regards, >> Michael >> >> >> Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson: >>> OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to use it, and support came down to just a few simple lines of code. >>> >>> For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational. >>> >>> c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with using std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way of doing that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of data ready to commit to metrics, so will need to think about this some more. >>> >>> I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall aggregates, etc). There is a very basic ‘bms status’ command implemented. >>> >>> Let me know what you think of it. >>> >>> Regards, Mark >>> >>>> On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>> >>>> Mark, >>>> >>>> yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as… >>>> OvmsVehicle::ResetCellStats(); >>>> Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level? >>>> On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the vehicle / user. >>>> >>>> >>>> There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion bitset, i.e. >>>> OvmsVehicle::RestartCellVoltages(); >>>> OvmsVehicle::RestartCellTemperatures(); >>>> …as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation. >>>> >>>> >>>> Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these thresholds are currently fixed to… >>>> // Battery cell/cmod deviation alert thresholds: >>>> #define BATT_DEV_TEMP_ALERT 3 // = 3 °C >>>> #define BATT_DEV_VOLT_ALERT 6 // = 30 mV >>>> >>>> // ...thresholds for overall stddev: >>>> #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C >>>> #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C >>>> #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV >>>> #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV >>>> …these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. So these should be configurable, i.e. >>>> vehicle bms.dev.temp.alert [°C] >>>> vehicle bms.dev.voltage.alert [V] >>>> vehicle bms.stddev.temp.watch [°C] >>>> vehicle bms.stddev.temp.alert [°C] >>>> vehicle bms.stddev.voltage.watch [V] >>>> vehicle bms.stddev.voltage.alert [V] >>>> I can generalize the Twizy code for all of this. >>>> >>>> >>>> The Twizy battery monitoring command set is: >>>> OVMS# xrt batt ? >>>> data-cell Output cell record >>>> data-pack Output pack record >>>> reset Reset alerts & watches >>>> status Status report >>>> tdev Show temperature deviations >>>> temp Show temperatures >>>> vdev Show voltage deviations >>>> volt Show voltages >>>> The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the output within the SMS msg size limit. >>>> >>>> "status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and "tdev" show all cells. >>>> >>>> The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set. >>>> >>>> >>>> The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on the Twizy, sending a vector metric to the server is just a matter of… >>>> std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; >>>> msg.append(m_mon.m_mot_torque_drv->AsString()); >>>> MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str()); >>>> Neat. >>>> >>>> The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a lot of additional data volume on large packs. >>>> >>>> >>>> The Twizy layout may be either… >>>> 14 cell groups in the pack >>>> 2 cell groups in each module >>>> 7 modules in the pack >>>> Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) >>>> Each module has 1 temperature measurements (so, 7 individual temperature measurements) >>>> That means: >>>> OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) >>>> OvmsVehicle::SetCellArrangementTemperature(7, 1, 7) >>>> …for the original battery, or for an LFP type replacement… >>>> >>>> 16 cell groups in the pack >>>> 16 cell groups in each module >>>> 1 module in the pack >>>> Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) >>>> Each module has 3 temperature measurements (so, 3 individual temperature measurements) >>>> That means: >>>> OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) >>>> OvmsVehicle::SetCellArrangementTemperature(3, 3, 3) >>>> >>>> Regards, >>>> Michael >>>> >>>> >>>> Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson: >>>>> 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@webb-johnson.net <mailto:mark@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@spjeldager.dk <mailto:henrik.scheel@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/ <http://www.spjeldager.dk/> >>>>>>> >>>>>>>> Den 10. nov. 2018 kl. 15.34 skrev ovmsdev-request@lists.openvehicles.com <mailto:ovmsdev-request@lists.openvehicles.com>: >>>>>>>> >>>>>>>> Send OvmsDev mailing list submissions to >>>>>>>> ovmsdev@lists.openvehicles.com <mailto:ovmsdev@lists.openvehicles.com> >>>>>>>> >>>>>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>> or, via email, send a message with subject or body 'help' to >>>>>>>> ovmsdev-request@lists.openvehicles.com <mailto:ovmsdev-request@lists.openvehicles.com> >>>>>>>> >>>>>>>> You can reach the person managing the list at >>>>>>>> ovmsdev-owner@lists.openvehicles.com <mailto:ovmsdev-owner@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@webb-johnson.net> <mailto:mark@webb-johnson.net> >>>>>>>> To: OVMS Developers <ovmsdev@lists.openvehicles.com> <mailto:ovmsdev@lists.openvehicles.com> >>>>>>>> Subject: Re: [Ovmsdev] Custom metrics >>>>>>>> Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@webb-johnson.net> <mailto:1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@expeedo.de> <mailto:dexter@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 likehttps://api.openvehicles.com:8080/VEHICLEID <https://api.openvehicles.com:8080/VEHICLEID> <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> <https://github.com/russdill/lwip/commit/dfeba616>. Another is TUN/TAP, again with reference code for LWIP<https://github.com/russdill/lwip/commit/47ca42f8> <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@expeedo.de <mailto:dexter@expeedo.de> <mailto:dexter@expeedo.de> <mailto:dexter@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> <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@expeedo.de <mailto:dexter@expeedo.de> <mailto:dexter@expeedo.de> <mailto:dexter@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><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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OvmsDev mailing list >>>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>> >>>>>>>>
Obviously not working for you. Cells that exceeded the alert threshold deviation from average get marked with "!", and "?" = warn threshold exceeded. So at some point, many cells exceeded 200% stddev -- obviously not in the established overall situation. Is there maybe some init phase with unstable / incomplete readings that needs to be skipped on the Model S? If so, a "bms reset" should clean the alerts up. Can you try that? Regards, Michael Am 17.11.18 um 16:01 schrieb Mark Webb-Johnson:
Not really sure how to interpret this. I get:
OVMS# bms alerts Voltage: SD=7mV !1:-7mV !2:-4mV !3:-4mV !4:-5mV !5:-5mV !6:-6mV !7:-1mV !8:+2mV !9:+0mV !10:+0mV !11:+0mV !12:-2mV ?13:+0mV !14:+4mV !15:+2mV !16:+2mV !17:+0mV !18:+0mV !19:-3mV !20:+0mV !21:-1mV ?22:+0mV !23:-2mV !24:-2mV !26:+2mV !27:+1mV !28:+2mV ?29:+0mV !30:+0mV !31:-2mV ?33:+0mV !35:-1mV !36:-2mV ?37:-5mV !38:-3mV !39:-2mV !40:-2mV !41:-4mV !42:-6mV !43:-3mV !44:+0mV !45:-1mV !46:-1mV !47:-1mV !48:-1mV !49:+6mV !50:+7mV !51:+6mV !52:+8mV !53:+7mV !54:+6mV !55:+1mV !56:+4mV !57:+1mV !58:+4mV !59:+0mV !60:+0mV !61:+3mV !62:+5mV !63:+4mV !64:+4mV !65:+2mV !66:+3mV !67:-1mV !68:+2mV !69:+1mV !70:+1mV !71:-1mV !72:-1mV !74:+2mV !76:+1mV ?77:+0mV !78:-1mV !79:+1mV !80:+3mV !81:+1mV !82:+2mV !83:+2mV !84:+1mV !85:-3mV !86:+2mV !87:-1mV !88:-1mV !89:-3mV !90:-2mV !91:-2mV !92:-1mV !93:-2mV !94:-2mV !95:-3mV !96:-4mV Temperature: SD=0.6C ?1:+0.5C ?2:+1.0C ?3:+0.3C ?4:+0.3C ?5:-0.2C ?7:-0.3C ?9:-0.2C !10:-0.2C ?12:-0.4C ?13:-0.3C ?14:-0.4C ?15:-0.5C ?16:-0.3C ?17:+0.8C !18:-0.3C ?19:-0.1C ?20:-0.3C ?21:-0.1C !22:-0.4C !24:-0.5C ?25:-0.3C ?26:-0.4C ?28:-0.3C ?29:+0.7C ?30:+0.3C ?31:+0.9C ?32:+0.5C
OVMS# metrics list v.b.c v.b.c.temp 28.8652,29.4386,28.6334,28.6822,28.1942,28.5114,28.1454,28.4626,28.182,28.3406,28.3894,28.121,28.1088,28.1454,28.0112,28.182,28.9262,28.243,28.2674,28.2186,28.2918,28.0844,28.3528,28.0356,28.1454,28.1088,28.4626,28.2186,28.975,28.7554,29.0604,28.9384°C v.b.c.temp.alert 1,2,1,1,1,1,1,0,1,2,0,1,1,1,1,1,2,2,1,1,1,1,1,1,1,1,0,1,2,1,1,2 v.b.c.temp.dev.max 0.52,1.03,0.31,0.26,-0.23,0.1,-0.29,-0.07,-0.25,-0.18,0.04,-0.44,-0.31,-0.39,-0.46,-0.34,0.76,-0.27,-0.15,-0.3,-0.13,-0.45,-0.08,-0.49,-0.28,-0.41,0.09,-0.28,0.73,0.34,0.92,0.52°C v.b.c.temp.max 28.8774,29.4386,28.6578,28.6822,28.1942,28.5236,28.1454,28.4626,28.182,28.3406,28.3894,28.121,28.1088,28.1454,28.0112,28.182,29.1092,28.243,28.2674,28.2186,28.2918,28.0844,28.3528,28.0356,28.1576,28.1088,28.4626,28.2186,29.0848,28.7554,29.2678,28.9384°C v.b.c.temp.min 28.853,29.3654,28.6212,28.5724,28.1332,28.3894,28.1088,28.2796,28.1332,28.1698,28.3894,27.9136,28.0966,27.9624,27.9014,28.0112,28.9262,28.0844,28.2674,28.0478,28.2796,27.9014,28.3406,27.8648,28.121,27.938,28.426,28.0722,28.975,28.609,29.0604,28.8042°C v.b.c.voltage 4.13794,4.14099,4.14099,4.14099,4.14007,4.13915,4.14465,4.1477,4.14586,4.14556,4.14465,4.14373,4.14556,4.14922,4.14739,4.14709,4.14586,4.14586,4.14251,4.14556,4.14434,4.14495,4.14373,4.14342,4.14586,4.148,4.14586,4.14709,4.14526,4.14526,4.14342,4.14556,4.14526,4.14556,4.14434,4.14342,4.14038,4.14251,4.14282,4.14312,4.14099,4.13946,4.14251,4.14586,4.14434,4.14465,4.14465,4.14434,4.15197,4.15318,4.15166,4.1541,4.15318,4.15166,4.14709,4.14922,4.14709,4.14861,4.14617,4.14586,4.148,4.15074,4.14983,4.15044,4.1477,4.148,4.14465,4.148,4.14678,4.14647,4.14403,4.14403,4.14556,4.148,4.14586,4.14647,4.14465,4.14526,4.14617,4.148,4.14617,4.14647,4.14739,4.14678,4.14251,4.14709,4.14373,4.14434,4.14282,4.14373,4.14312,4.14465,4.14282,4.14312,4.14282,4.1419V v.b.c.voltage.alert 2,1,1,1,1,1,2,1,2,2,2,2,1,1,1,2,2,2,1,2,2,1,1,1,0,1,2,2,1,2,1,0,1,0,2,2,1,1,1,1,1,1,1,2,2,2,2,2,1,2,1,2,2,1,2,1,2,1,2,2,1,1,1,1,1,1,2,1,2,2,2,2,0,1,0,2,1,2,2,1,2,2,2,2,1,2,2,2,1,1,1,2,1,1,1,1 v.b.c.voltage.dev.max -0.0082,-0.00487,-0.00498,-0.00508,-0.00583,-0.00674,-0.00139,0.00257,0.00096,0.00086,-0.00096,-0.00221,-0.00061,0.004,0.00275,0.00217,0.00096,0.00077,-0.0034,0.00081,-0.0017,-0.00091,-0.00234,-0.00304,0.00068,0.00288,0.00124,0.0022,-0.00052,-0.00078,-0.0024,0.00095,-0.00103,-0.00061,-0.00179,-0.00224,-0.00546,-0.00335,-0.0032,-0.00271,-0.00506,-0.00644,-0.0036,0.00087,-0.00129,-0.00168,-0.00139,-0.00132,0.00648,0.00824,0.00648,0.00883,0.0081,0.00641,0.00161,0.00443,0.00222,0.00401,0.00096,0.00095,0.00342,0.00597,0.00469,0.00505,0.00318,0.00315,-0.00127,0.00291,0.00132,0.00197,-0.0024,-0.00168,-0.00072,0.00275,0.00069,0.00184,-0.00096,-0.0012,0.00125,0.0032,0.00166,0.00203,0.00291,0.00153,-0.00355,0.00214,-0.00225,-0.00171,-0.003,-0.00249,-0.00292,-0.00152,-0.00295,-0.00296,-0.00311,-0.00432V v.b.c.voltage.max 4.13794,4.14129,4.14099,4.14099,4.14007,4.13915,4.14465,4.1477,4.14586,4.14586,4.14556,4.14403,4.14556,4.14922,4.1477,4.14709,4.14586,4.14586,4.14251,4.14586,4.14434,4.14495,4.14373,4.14342,4.14586,4.148,4.14617,4.14709,4.14556,4.14526,4.14342,4.14586,4.14526,4.14556,4.14434,4.14373,4.14099,4.14282,4.14282,4.14312,4.14099,4.13946,4.14282,4.14617,4.14465,4.14465,4.14465,4.14434,4.15197,4.15349,4.15197,4.1541,4.15318,4.15166,4.14709,4.14922,4.14709,4.14861,4.14617,4.14647,4.14861,4.15105,4.15014,4.15044,4.1483,4.1483,4.14465,4.148,4.14678,4.14709,4.14403,4.14403,4.14556,4.148,4.14586,4.14709,4.14526,4.14526,4.14647,4.148,4.14709,4.14739,4.1483,4.14678,4.14282,4.14709,4.14403,4.14434,4.14312,4.14373,4.14312,4.14465,4.14312,4.14312,4.14312,4.1419V v.b.c.voltage.min 4.13123,4.13427,4.13397,4.13397,4.13336,4.13214,4.13732,4.14038,4.13915,4.13885,4.13794,4.13641,4.13824,4.14159,4.14068,4.14007,4.13855,4.13824,4.1355,4.13885,4.13702,4.13794,4.13611,4.1358,4.13855,4.14099,4.13915,4.14007,4.13794,4.13794,4.13641,4.13855,4.13794,4.13824,4.13702,4.13641,4.13367,4.1358,4.1355,4.1358,4.13397,4.13275,4.13488,4.13855,4.13702,4.13702,4.13702,4.13732,4.14342,4.14586,4.14403,4.14617,4.14526,4.14403,4.13824,4.14159,4.13946,4.14038,4.13824,4.13824,4.14099,4.14342,4.14251,4.14251,4.14068,4.14038,4.13732,4.14099,4.13946,4.13976,4.13671,4.13671,4.13794,4.14038,4.13824,4.13946,4.13763,4.13763,4.13885,4.14038,4.13915,4.13946,4.14068,4.13885,4.1355,4.14007,4.13671,4.13732,4.13611,4.13641,4.13641,4.13732,4.13611,4.13641,4.13611,4.13458V v.b.cac v.b.consumption 0Wh/km v.b.coulomb.recd v.b.coulomb.used v.b.current
OVMS# metrics list v.b.p v.b.p.level.avg v.b.p.level.max v.b.p.level.min v.b.p.level.stddev v.b.p.temp.avg 28.43°C v.b.p.temp.max 29.4508°C v.b.p.temp.min 28.0234°C v.b.p.temp.stddev 0.36°C v.b.p.temp.stddev.max 0.65°C v.b.p.voltage.avg 4.14669V v.b.p.voltage.max 4.15532V v.b.p.voltage.min 4.13855V v.b.p.voltage.stddev 0.00669V v.b.p.voltage.stddev.max 0.00717V v.b.power
And a bunch of push notifications every time I connect the App, like this:
Regards, Mark
On 17 Nov 2018, at 10:51 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
First implementation of general cell deviation checking and alerts is pushed.
Vehicle BMS: cell deviations & alerts Renamed metrics: - v.b.c.level.* → v.b.p.level.* (for consistency) New metrics: - v.b.c.(voltage,temp).(dev.max,alert) - v.b.p.(voltage,temp).(min,max,avg,stddev,stddev.max) New configs: - vehicle [bms.dev.voltage.warn] -- threshold [V] - vehicle [bms.dev.voltage.alert] -- threshold [V] - vehicle [bms.dev.temp.warn] -- threshold [°C] - vehicle [bms.dev.temp.alert] -- threshold [°C] …all optional, default: warn at 120% stddev, alert at 200% stddev New commands: - bms alerts → show cells with warn/alert levels
I changed the config scheme hoping a manual configuration normally isn't necessary with this automatic adaption to the standard deviation.
Please check and report if that idea works. If it doesn't, please report the deviations and necessary threshold levels on your batteries.
I also omitted the overall stddev alerts for now, I don't think those really are necessary, haven't had a single trigger on the Twizy for this.
Integration into the web chart page and historical data updates are still todo.
Migration for the Twizy battery monitor to the generalized scheme is in progress.
Regards, Michael
Am 17.11.18 um 11:53 schrieb Mark Webb-Johnson:
Short video showing Model S charging;
On 17 Nov 2018, at 6:13 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
Ok. Will do.
Now you remind me, bms looks good on iPhone:
<image1.jpeg>
On 17 Nov 2018, at 6:08 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Yes, you can add a new menu to PageMenu_t like that. I suggest introducing a general tools menu instead of a specific one, i.e. "PageMenu_Tools".
To still fit the menu on one line in tablet mode (width down to 768 px) I suggest moving the Shell into the tools menu then.
Go ahead, I'm not working on the web framework at the moment.
Regards, Michael
Am 17.11.18 um 10:48 schrieb Mark Webb-Johnson:
Twizy code overrides the virtual short name function, so won’t suffer the issue.
I think it is a bug in vehicle factory (as modifying the vehicle type is reasonable), so fixed it there. Returning NULL is problematic. It would be so much easier for everything to return std::string, but concern is memory consumption and overhead.
I’d like to start converting RE TOOLS to just use the web server. First step is to work out how to add a menu onto the web server. It seems that the PageMenu_t is a fixed enum list (and similarly hard-coded in the web_framework.
Do I just add a ‘CAN bus’ menu there, by adding it to PageMenu_t, and supporting it where the other top level menus are? Or do you have any other suggestions/plans for this?
I don’t want to step on anything you are working on here.
The second stage will be to add displays under that, but I think that is fairly straight forward. I will mostly be displaying tables, and sending those over the web socket would be good.
Regards, Mark
> On 17 Nov 2018, at 5:37 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: > > Mark, > > nice, thanks. > > The short name is used for the menu label. It's meant to fall back to the long name (and seems to do so in your screenshot), so should not be null. But > I admit I haven't tested it on a vehicle without a short name. > > Btw, I'm currently working on the deviations and alerts. > > Regards, > Michael > > > Am 17.11.18 um 10:08 schrieb Mark Webb-Johnson: >> Michael, >> >> Looks good. It seems that you did everything necessary for the Model S already in your commit 2a84d861403f48142d6adcc16ad7a20cd458e427: >> >> #include “ovms_webserver.h" >> >> OvmsVehicleTeslaModelS::OvmsVehicleTeslaModelS() >> MyWebServer.RegisterPage("/bms/cellmon", "BMS cell monitor", OvmsWebServer::HandleBmsCellMonitor, PageMenu_Vehicle, PageAuth_Cookie); >> >> OvmsVehicleTeslaModelS::~OvmsVehicleTeslaModelS() >> MyWebServer.DeregisterPage("/bms/cellmon"); >> >> >> From my devbench, replaying a CAN CRTD log file, I get this output: >> >> <PastedGraphic-2.png> >> >> The animation is very nice. >> >> I am, however, getting crashes, as follows: >> >> # xtensa-esp32-elf-addr2line -pfiaC -e 3.1.011-25-g2a84d86.ovms3.elf 0x400935d3 0x4009372b 0x400db90c 0x4012c0f7 0x4012d0e1 0x4012d1e0 0x4012ebc1 >> 0x4012ecbd 0x400f8b65 0x400f912d 0x400fa27c 0x400fa29a 0x400f8b65 0x400fa3e3 0x400fa7ad 0x400faa77 0x400f767e 0x400ee40a 0x400ee459 >> 0x400935d3: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 >> 0x4009372b: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 >> 0x400db90c: __cxx_fatal_exception_message at /home/openvehicles/build/esp-idf/components/cxx/cxx_exception_stubs.cpp:19 >> 0x4012c0f7: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char >> const*, std::forward_iterator_tag) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:216 >> (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, char >> const*, std::__false_type) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195 >> (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char >> const*) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214 >> (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> >> const&) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457 >> 0x4012d0e1: OvmsWebServer::CreateMenu[abi:cxx11](PageContext&) at >> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:393 >> 0x4012d1e0: OvmsWebServer::HandleRoot(PageEntry&, PageContext&) at >> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:510 >> 0x4012ebc1: PageEntry::Serve(PageContext&) at >> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 >> 0x4012ecbd: OvmsWebServer::EventHandler(mg_connection*, int, void*) at >> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 >> 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >> 0x400f912d: mg_http_call_endpoint_handler at >> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >> 0x400fa27c: mg_http_handler2 at >> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >> 0x400fa29a: mg_http_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >> 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >> 0x400fa3e3: mg_recv_common at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >> 0x400fa7ad: mg_if_recv_tcp_cb at >> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >> (inlined by) mg_handle_tcp_read at >> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3723 >> (inlined by) mg_mgr_handle_conn at >> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3844 >> 0x400faa77: mg_socket_if_poll at >> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >> 0x400f767e: mg_mgr_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >> 0x400ee40a: OvmsNetManager::MongooseTask() at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:560 >> 0x400ee459: MongooseRawTask(void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:545 >> >> >> On my development bench module I get this crash 1 in 4 times or so. On my real car, 100% of the time. >> >> That code path leads into MyVehicleFactory.ActiveVehicleShortName(). Those should all be ‘const char*’, but it is possible for NULL to be returned. I >> will look into it in more detail. >> >> Regards, Mark. >> >>> On 17 Nov 2018, at 7:35 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>> >>> Mark, Tamás, >>> >>> I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI. >>> >>> Please see git log for details and send some screenshots. >>> >>> Regards, >>> Michael >>> >>> >>> Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson: >>>> OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to >>>> use it, and support came down to just a few simple lines of code. >>>> >>>> For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational. >>>> >>>> c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with using >>>> std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way of >>>> doing that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of data >>>> ready to commit to metrics, so will need to think about this some more. >>>> >>>> I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall >>>> aggregates, etc). There is a very basic ‘bms status’ command implemented. >>>> >>>> Let me know what you think of it. >>>> >>>> Regards, Mark >>>> >>>>> On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>> >>>>> Mark, >>>>> >>>>> yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as… >>>>> >>>>> * OvmsVehicle::ResetCellStats(); >>>>> * Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level? >>>>> >>>>> On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the >>>>> vehicle / user. >>>>> >>>>> >>>>> There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated >>>>> by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion bitset, >>>>> i.e. >>>>> >>>>> * OvmsVehicle::RestartCellVoltages(); >>>>> * OvmsVehicle::RestartCellTemperatures(); >>>>> >>>>> …as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation. >>>>> >>>>> >>>>> Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation >>>>> thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for >>>>> normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these >>>>> thresholds are currently fixed to… >>>>> >>>>> // Battery cell/cmod deviation alert thresholds: >>>>> #define BATT_DEV_TEMP_ALERT 3 // = 3 °C >>>>> #define BATT_DEV_VOLT_ALERT 6 // = 30 mV >>>>> >>>>> // ...thresholds for overall stddev: >>>>> #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C >>>>> #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C >>>>> #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV >>>>> #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV >>>>> >>>>> …these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. So >>>>> these should be configurable, i.e. >>>>> >>>>> * vehicle bms.dev.temp.alert [°C] >>>>> * vehicle bms.dev.voltage.alert [V] >>>>> * vehicle bms.stddev.temp.watch [°C] >>>>> * vehicle bms.stddev.temp.alert [°C] >>>>> * vehicle bms.stddev.voltage.watch [V] >>>>> * vehicle bms.stddev.voltage.alert [V] >>>>> >>>>> I can generalize the Twizy code for all of this. >>>>> >>>>> >>>>> The Twizy battery monitoring command set is: >>>>> >>>>> OVMS# xrt batt ? >>>>> data-cell Output cell record >>>>> data-pack Output pack record >>>>> reset Reset alerts & watches >>>>> status Status report >>>>> tdev Show temperature deviations >>>>> temp Show temperatures >>>>> vdev Show voltage deviations >>>>> volt Show voltages >>>>> >>>>> The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the output >>>>> within the SMS msg size limit. >>>>> >>>>> "status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and >>>>> "tdev" show all cells. >>>>> >>>>> The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set. >>>>> >>>>> >>>>> The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on >>>>> the Twizy, sending a vector metric to the server is just a matter of… >>>>> >>>>> std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; >>>>> msg.append(m_mon.m_mot_torque_drv->AsString()); >>>>> MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str()); >>>>> >>>>> Neat. >>>>> >>>>> The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a >>>>> lot of additional data volume on large packs. >>>>> >>>>> >>>>> The Twizy layout may be either… >>>>> >>>>> * 14 cell groups in the pack >>>>> * 2 cell groups in each module >>>>> * 7 modules in the pack >>>>> * Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) >>>>> * Each module has 1 temperature measurements (so, 7 individual temperature measurements) >>>>> * That means: >>>>> o OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) >>>>> o OvmsVehicle::SetCellArrangementTemperature(7, 1, 7) >>>>> >>>>> …for the original battery, or for an LFP type replacement… >>>>> >>>>> * 16 cell groups in the pack >>>>> * 16 cell groups in each module >>>>> * 1 module in the pack >>>>> * Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) >>>>> * Each module has 3 temperature measurements (so, 3 individual temperature measurements) >>>>> * That means: >>>>> o OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) >>>>> o OvmsVehicle::SetCellArrangementTemperature(3, 3, 3) >>>>> >>>>> >>>>> Regards, >>>>> Michael >>>>> >>>>> >>>>> Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson: >>>>>> 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: >>>>>> o OvmsVehicle::SetCellArrangementVoltage(96, 6, 3) >>>>>> o 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: >>>>>> o OvmsVehicle::SetCellArrangementVoltage(99, 9, 9) >>>>>> o 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: >>>>>> o OvmsVehicle::SetCellArrangementVoltage(N, Y, Z) >>>>>> o 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@webb-johnson.net <mailto:mark@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@spjeldager.dk <mailto:henrik.scheel@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@lists.openvehicles.com: >>>>>>>>> >>>>>>>>> Send OvmsDev mailing list submissions to >>>>>>>>> ovmsdev@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@lists.openvehicles.com >>>>>>>>> >>>>>>>>> You can reach the person managing the list at >>>>>>>>> ovmsdev-owner@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@webb-johnson.net> >>>>>>>>> To: OVMS Developers <ovmsdev@lists.openvehicles.com> >>>>>>>>> Subject: Re: [Ovmsdev] Custom metrics >>>>>>>>> Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com >>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>>>>>>>> >>>>>>>>>
i tested on Peuogeot iOn: Welcome to the Open Vehicle Monitoring System (OVMS) - SSH Console Firmware: 3.1.011-52-gbe9798f6/ota_0/main Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/1 OVMS# bms alerts Voltage: SD=6mV ?1:+3mV !2:-4mV !3:-4mV !4:+3mV ?5:+4mV !6:+4mV ?7:+4mV !8:+4mV ?9:+4mV ?10:+3mV ?11:+4mV ?12:+4mV ?13:+4mV ?14:+3mV ?15:+4mV !16:+4mV !17:-5mV !18:-5mV ?19:+3mV !20:+3mV !21:+4mV ?22:-4mV !23:-5mV !24:-4mV !25:+3mV ?26:-4mV ?27:+3mV ?28:-3mV !29:+4mV !30:+4mV !31:+4mV !32:+4mV ?33:-3mV ?34:-3mV !35:+4mV ?36:+4mV !37:-3mV ?38:-3mV !39:+4mV ?40:+4mV !41:-5mV !42:-3mV !43:+3mV !44:+4mV !45:-5mV ?46:-3mV !47:+4mV !48:+4mV ?49:+4mV ?50:+4mV !51:+4mV !52:+4mV !53:+4mV !54:+8mV !55:+4mV ?56:+4mV ?57:+4mV ?58:+4mV !59:+4mV !60:+4mV ?61:+4mV !62:+4mV !63:-3mV !64:-3mV !65:+4mV ?66:+4mV !67:-4mV !68:+4mV !69:+4mV !70:+4mV !71:+4mV ?72:+4mV ?73:+8mV !74:+8mV !75:+5mV !76:+4mV !77:+4mV !78:+4mV ?79:+4mV ?80:+4mV ?81:+4mV !82:+4mV ?83:-4mV !84:-3mV !85:+4mV ?86:+4mV !87:+4mV ?88:+4mV Temperature: SD=1.7C ?3:+1.8C ?4:+2.8C ?5:+1.9C ?6:+3.7C !8:+3.8C ?10:+1.9C ?16:+2.8C ?18:+2.7C ?20:+2.7C ?22:+1.8C ?23:+3.8C ?27:+1.9C ?29:+2.8C ?31:+2.8C ?39:+1.9C ?41:+1.9C ?43:+1.8C ?55:-2.3C ?56:-2.3C ?57:-2.3C ?58:-2.3C ?66:-2.3C OVMS# metrics list v.b.c v.b.c.temp 13,14,15,16,15,16,14,17,12,15,13,13,13,14,14,15,14,15,14,15,12,14,17,13,14,12,15,13,16,13,16,13,14,12,12,12,13,12,15,13,14,13,14,12,14,12,12,12,13,12,13,12,12,12,11,11,11,11,12,12,13,13,12,12,12,11°C v.b.c.temp.alert 0,0,1,1,1,1,0,1,0,1,0,0,0,0,0,1,0,1,0,1,0,1,2,0,0,0,1,0,1,0,1,0,0,0,0,0,0,0,1,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,0,1 v.b.c.temp.dev.max -0.35,1.65,1.8,2.85,1.85,3.7,0.85,3.8,-1.35,1.85,-0.35,-0.35,-0.35,1.73,0.85,2.76,0.85,2.67,0.83,2.7,-1.35,1.76,3.85,-0.35,0.8,-1.35,1.85,-0.35,2.82,-0.35,2.79,-0.35,0.85,-1.35,-1.35,-1.35,0.77,-1.35,1.85,-0.35,1.85,-1.35,1.79,-1.35,0.82,-1.35,-1.35,-1.35,-0.35,-1.35,-0.35,-1.35,-1.35,-1.35,-2.35,-2.35,-2.35,-2.35,-1.35,-1.35,-0.35,-1.35,-1.35,-1.35,-1.35,-2.35°C v.b.c.temp.max 13,15,15,16,15,17,14,17,13,15,13,13,13,15,14,16,14,16,14,16,12,15,17,13,14,12,15,13,16,13,16,13,14,12,12,12,14,12,15,13,15,13,15,12,14,12,12,12,13,12,13,12,12,12,11,11,12,11,12,12,13,13,13,12,12,11°C v.b.c.temp.min 13,14,14,16,15,16,14,16,12,15,13,13,13,14,14,15,14,15,13,15,12,14,17,13,13,12,15,13,15,13,15,13,14,12,12,12,13,12,15,13,14,12,14,12,13,12,12,12,13,12,13,12,12,12,11,11,11,11,12,12,13,12,12,12,12,11°C v.b.c.voltage 4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02V v.b.c.voltage.alert 2,1,1,1,2,1,2,1,2,2,2,2,2,2,2,1,1,1,2,1,1,2,1,1,1,2,2,2,1,1,1,1,2,2,1,2,1,2,1,2,1,1,1,1,1,2,1,1,2,2,1,1,1,1,1,2,2,2,1,1,2,1,1,1,1,2,1,1,1,1,1,2,2,1,1,1,1,1,2,2,2,1,2,1,1,2,1,2 v.b.c.voltage.dev.max 0.00352,-0.00472,-0.00494,0.00375,0.0046,0.00489,0.00494,0.00494,0.00432,0.00347,0.00455,0.0046,0.00415,0.00375,0.00415,0.00449,-0.005,-0.005,0.00347,0.00375,0.0046,-0.00494,-0.0054,-0.00455,0.00375,-0.00455,0.00398,-0.00335,0.00477,0.00494,0.00494,0.00494,-0.00335,-0.00335,0.00494,0.00483,-0.00392,-0.00369,0.00415,0.00455,-0.005,-0.00392,0.00375,0.00449,-0.00506,-0.00369,0.00483,0.00489,0.00426,0.00455,0.00477,0.0046,0.00483,0.00886,0.00489,0.00494,0.0046,0.00466,0.0046,0.0046,0.00483,0.00472,-0.00392,-0.00392,0.0046,0.00426,-0.00455,0.00415,0.00477,0.00472,0.00489,0.0046,0.00886,0.00886,0.00511,0.00494,0.00483,0.00477,0.0046,0.00472,0.00477,0.00489,-0.00455,-0.00392,0.00466,0.00432,0.00466,0.00449V v.b.c.voltage.max 4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.035,4.04,4.04,4.04,4.04,4.04,4.035,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04V v.b.c.voltage.min 4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02V v.b.cac 1Ah v.b.consumption 0Wh/km v.b.coulomb.recd v.b.coulomb.used v.b.current -0.88A OVMS# metrics list v.b.p v.b.p.level.avg v.b.p.level.max v.b.p.level.min v.b.p.level.stddev v.b.p.temp.avg 13.23°C v.b.p.temp.max 17°C v.b.p.temp.min 11°C v.b.p.temp.stddev 1.43°C v.b.p.temp.stddev.max 1.74°C v.b.p.voltage.avg 4.01903V v.b.p.voltage.max 4.02V v.b.p.voltage.min 4.015V v.b.p.voltage.stddev 0.00599V v.b.p.voltage.stddev.max 0.00691V v.b.power 0.311256kW OVMS# bms reset BMS cell statistics have been reset. OVMS# bms alerts Voltage: SD=6mV ?1:+0mV ?2:+0mV ?3:+0mV ?4:+0mV ?5:+0mV ?6:+0mV ?7:+0mV ?8:+0mV ?9:+0mV ?10:+0mV ?11:+0mV ?12:+0mV ?13:+0mV ?14:+0mV ?15:+0mV ?16:+0mV ?17:+0mV ?18:+0mV ?19:+0mV ?20:+0mV ?21:+0mV ?22:+0mV ?23:+0mV ?24:+0mV ?25:+0mV ?26:+0mV ?27:+0mV ?28:+0mV ?29:+0mV ?30:+0mV ?31:+0mV ?32:+0mV ?33:+0mV ?34:+0mV ?35:+0mV ?36:+0mV ?37:+0mV ?38:+0mV ?39:+0mV ?40:+0mV ?41:+0mV ?42:+0mV ?43:+0mV ?44:+0mV ?45:+0mV ?46:+0mV ?47:+0mV ?48:+0mV ?49:+0mV ?50:+0mV ?51:+0mV ?52:+0mV ?53:+0mV ?54:+0mV ?55:+0mV ?56:+0mV ?57:+0mV ?58:+0mV ?59:+0mV ?60:+0mV ?61:+0mV ?62:+0mV ?63:+0mV ?64:+0mV ?65:+0mV ?66:+0mV ?67:+0mV ?68:+0mV ?69:+0mV ?70:+0mV ?71:+0mV ?72:+0mV ?73:+0mV ?74:+0mV ?75:+0mV ?76:+0mV ?77:+0mV ?78:+0mV ?79:+0mV ?80:+0mV ?81:+0mV ?82:+0mV ?83:+0mV ?84:+0mV ?85:+0mV ?86:+0mV ?87:+0mV ?88:+0mV Temperature: SD=1.7C ?3:+1.8C ?4:+2.8C ?5:+1.8C ?6:+2.8C ?8:+2.8C ?16:+1.8C ?18:+1.8C ?20:+1.8C ?23:+3.8C ?27:+1.8C ?29:+1.8C ?31:+1.8C ?39:+1.8C ?55:-2.2C ?56:-2.2C ?57:-2.2C ?58:-2.2C ?66:-2.2C OVMS# metrics list v.b.c v.b.c.temp 13,14,15,15,15,16,14,16,12,14,13,12,13,14,14,15,14,15,14,15,12,14,17,13,13,12,15,13,15,13,15,13,14,12,12,12,13,12,15,13,14,13,14,12,13,12,12,12,13,12,13,12,12,12,11,11,11,11,12,12,13,13,12,12,12,11°C v.b.c.temp.alert 0,0,1,1,1,2,0,2,0,0,0,0,0,0,0,1,0,1,0,1,0,0,2,0,0,0,1,0,1,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,0,1 v.b.c.temp.dev.max -0.2,0.85,1.85,2.82,1.85,2.85,0.85,2.85,-1.18,0.85,-0.2,-1.15,-0.2,0.85,0.85,1.85,0.85,1.85,0.85,1.85,-1.2,0.85,3.85,-0.2,-0.2,-1.2,1.85,-0.2,1.85,-0.2,1.85,-0.2,0.85,-1.2,-1.2,-1.2,-0.2,-1.2,1.85,-0.2,0.85,-0.2,0.85,-1.2,-0.2,-1.2,-1.2,-1.2,-0.2,-1.2,-0.2,-1.2,-1.2,-1.2,-2.2,-2.2,-2.2,-2.2,-1.2,-1.2,-0.2,-0.2,-1.2,-1.2,-1.2,-2.2°C v.b.c.temp.max 13,14,15,16,15,16,14,16,13,14,13,13,13,14,14,15,14,15,14,15,12,14,17,13,13,12,15,13,15,13,15,13,14,12,12,12,13,12,15,13,14,13,14,12,13,12,12,12,13,12,13,12,12,12,11,11,11,11,12,12,13,13,13,12,12,11°C v.b.c.temp.min 13,14,15,15,15,16,14,16,12,14,13,12,13,14,14,15,14,15,14,15,12,14,17,13,13,12,15,13,15,13,15,13,14,12,12,12,13,12,15,13,14,13,14,12,13,12,12,12,13,12,13,12,12,12,11,11,11,11,12,12,13,13,12,12,12,11°C v.b.c.voltage 4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.01,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015V v.b.c.voltage.alert 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 v.b.c.voltage.dev.max 6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,-0.00494,-0.00494,6e-05,-0.00494,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,-0.00494,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05V v.b.c.voltage.max 4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015V v.b.c.voltage.min 4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.01,4.01,4.015,4.01,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.01,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015V v.b.cac 1Ah v.b.consumption 0Wh/km v.b.coulomb.recd v.b.coulomb.used v.b.current -1.04A OVMS# metrics list v.b.p v.b.p.level.avg v.b.p.level.max v.b.p.level.min v.b.p.level.stddev v.b.p.temp.avg 13.15°C v.b.p.temp.max 17°C v.b.p.temp.min 11°C v.b.p.temp.stddev 1.39°C v.b.p.temp.stddev.max 1.74°C v.b.p.voltage.avg 4.0146V v.b.p.voltage.max 4.015V v.b.p.voltage.min 4.01V v.b.p.voltage.stddev 0.00451V v.b.p.voltage.stddev.max 0.00691V v.b.power 0.374498kW OVMS# Michael Balzer <dexter@expeedo.de> ezt írta (időpont: 2018. nov. 17., Szo, 16:43):
Obviously not working for you. Cells that exceeded the alert threshold deviation from average get marked with "!", and "?" = warn threshold exceeded.
So at some point, many cells exceeded 200% stddev -- obviously not in the established overall situation. Is there maybe some init phase with unstable / incomplete readings that needs to be skipped on the Model S?
If so, a "bms reset" should clean the alerts up. Can you try that?
Regards, Michael
Am 17.11.18 um 16:01 schrieb Mark Webb-Johnson:
Not really sure how to interpret this. I get:
OVMS# bms alerts Voltage: SD=7mV !1:-7mV !2:-4mV !3:-4mV !4:-5mV !5:-5mV !6:-6mV !7:-1mV !8:+2mV !9:+0mV !10:+0mV !11:+0mV !12:-2mV ?13:+0mV !14:+4mV !15:+2mV !16:+2mV !17:+0mV !18:+0mV !19:-3mV !20:+0mV !21:-1mV ?22:+0mV !23:-2mV !24:-2mV !26:+2mV !27:+1mV !28:+2mV ?29:+0mV !30:+0mV !31:-2mV ?33:+0mV !35:-1mV !36:-2mV ?37:-5mV !38:-3mV !39:-2mV !40:-2mV !41:-4mV !42:-6mV !43:-3mV !44:+0mV !45:-1mV !46:-1mV !47:-1mV !48:-1mV !49:+6mV !50:+7mV !51:+6mV !52:+8mV !53:+7mV !54:+6mV !55:+1mV !56:+4mV !57:+1mV !58:+4mV !59:+0mV !60:+0mV !61:+3mV !62:+5mV !63:+4mV !64:+4mV !65:+2mV !66:+3mV !67:-1mV !68:+2mV !69:+1mV !70:+1mV !71:-1mV !72:-1mV !74:+2mV !76:+1mV ?77:+0mV !78:-1mV !79:+1mV !80:+3mV !81:+1mV !82:+2mV !83:+2mV !84:+1mV !85:-3mV !86:+2mV !87:-1mV !88:-1mV !89:-3mV !90:-2mV !91:-2mV !92:-1mV !93:-2mV !94:-2mV !95:-3mV !96:-4mV Temperature: SD=0.6C ?1:+0.5C ?2:+1.0C ?3:+0.3C ?4:+0.3C ?5:-0.2C ?7:-0.3C ?9:-0.2C !10:-0.2C ?12:-0.4C ?13:-0.3C ?14:-0.4C ?15:-0.5C ?16:-0.3C ?17:+0.8C !18:-0.3C ?19:-0.1C ?20:-0.3C ?21:-0.1C !22:-0.4C !24:-0.5C ?25:-0.3C ?26:-0.4C ?28:-0.3C ?29:+0.7C ?30:+0.3C ?31:+0.9C ?32:+0.5C
OVMS# metrics list v.b.c v.b.c.temp 28.8652,29.4386,28.6334,28.6822,28.1942,28.5114,28.1454,28.4626,28.182,28.3406,28.3894,28.121,28.1088,28.1454,28.0112,28.182,28.9262,28.243,28.2674,28.2186,28.2918,28.0844,28.3528,28.0356,28.1454,28.1088,28.4626,28.2186,28.975,28.7554,29.0604,28.9384°C v.b.c.temp.alert 1,2,1,1,1,1,1,0,1,2,0,1,1,1,1,1,2,2,1,1,1,1,1,1,1,1,0,1,2,1,1,2 v.b.c.temp.dev.max 0.52,1.03,0.31,0.26,-0.23,0.1,-0.29,-0.07,-0.25,-0.18,0.04,-0.44,-0.31,-0.39,-0.46,-0.34,0.76,-0.27,-0.15,-0.3,-0.13,-0.45,-0.08,-0.49,-0.28,-0.41,0.09,-0.28,0.73,0.34,0.92,0.52°C v.b.c.temp.max 28.8774,29.4386,28.6578,28.6822,28.1942,28.5236,28.1454,28.4626,28.182,28.3406,28.3894,28.121,28.1088,28.1454,28.0112,28.182,29.1092,28.243,28.2674,28.2186,28.2918,28.0844,28.3528,28.0356,28.1576,28.1088,28.4626,28.2186,29.0848,28.7554,29.2678,28.9384°C v.b.c.temp.min 28.853,29.3654,28.6212,28.5724,28.1332,28.3894,28.1088,28.2796,28.1332,28.1698,28.3894,27.9136,28.0966,27.9624,27.9014,28.0112,28.9262,28.0844,28.2674,28.0478,28.2796,27.9014,28.3406,27.8648,28.121,27.938,28.426,28.0722,28.975,28.609,29.0604,28.8042°C v.b.c.voltage 4.13794,4.14099,4.14099,4.14099,4.14007,4.13915,4.14465,4.1477,4.14586,4.14556,4.14465,4.14373,4.14556,4.14922,4.14739,4.14709,4.14586,4.14586,4.14251,4.14556,4.14434,4.14495,4.14373,4.14342,4.14586,4.148,4.14586,4.14709,4.14526,4.14526,4.14342,4.14556,4.14526,4.14556,4.14434,4.14342,4.14038,4.14251,4.14282,4.14312,4.14099,4.13946,4.14251,4.14586,4.14434,4.14465,4.14465,4.14434,4.15197,4.15318,4.15166,4.1541,4.15318,4.15166,4.14709,4.14922,4.14709,4.14861,4.14617,4.14586,4.148,4.15074,4.14983,4.15044,4.1477,4.148,4.14465,4.148,4.14678,4.14647,4.14403,4.14403,4.14556,4.148,4.14586,4.14647,4.14465,4.14526,4.14617,4.148,4.14617,4.14647,4.14739,4.14678,4.14251,4.14709,4.14373,4.14434,4.14282,4.14373,4.14312,4.14465,4.14282,4.14312,4.14282,4.1419V v.b.c.voltage.alert 2,1,1,1,1,1,2,1,2,2,2,2,1,1,1,2,2,2,1,2,2,1,1,1,0,1,2,2,1,2,1,0,1,0,2,2,1,1,1,1,1,1,1,2,2,2,2,2,1,2,1,2,2,1,2,1,2,1,2,2,1,1,1,1,1,1,2,1,2,2,2,2,0,1,0,2,1,2,2,1,2,2,2,2,1,2,2,2,1,1,1,2,1,1,1,1 v.b.c.voltage.dev.max -0.0082,-0.00487,-0.00498,-0.00508,-0.00583,-0.00674,-0.00139,0.00257,0.00096,0.00086,-0.00096,-0.00221,-0.00061,0.004,0.00275,0.00217,0.00096,0.00077,-0.0034,0.00081,-0.0017,-0.00091,-0.00234,-0.00304,0.00068,0.00288,0.00124,0.0022,-0.00052,-0.00078,-0.0024,0.00095,-0.00103,-0.00061,-0.00179,-0.00224,-0.00546,-0.00335,-0.0032,-0.00271,-0.00506,-0.00644,-0.0036,0.00087,-0.00129,-0.00168,-0.00139,-0.00132,0.00648,0.00824,0.00648,0.00883,0.0081,0.00641,0.00161,0.00443,0.00222,0.00401,0.00096,0.00095,0.00342,0.00597,0.00469,0.00505,0.00318,0.00315,-0.00127,0.00291,0.00132,0.00197,-0.0024,-0.00168,-0.00072,0.00275,0.00069,0.00184,-0.00096,-0.0012,0.00125,0.0032,0.00166,0.00203,0.00291,0.00153,-0.00355,0.00214,-0.00225,-0.00171,-0.003,-0.00249,-0.00292,-0.00152,-0.00295,-0.00296,-0.00311,-0.00432V v.b.c.voltage.max 4.13794,4.14129,4.14099,4.14099,4.14007,4.13915,4.14465,4.1477,4.14586,4.14586,4.14556,4.14403,4.14556,4.14922,4.1477,4.14709,4.14586,4.14586,4.14251,4.14586,4.14434,4.14495,4.14373,4.14342,4.14586,4.148,4.14617,4.14709,4.14556,4.14526,4.14342,4.14586,4.14526,4.14556,4.14434,4.14373,4.14099,4.14282,4.14282,4.14312,4.14099,4.13946,4.14282,4.14617,4.14465,4.14465,4.14465,4.14434,4.15197,4.15349,4.15197,4.1541,4.15318,4.15166,4.14709,4.14922,4.14709,4.14861,4.14617,4.14647,4.14861,4.15105,4.15014,4.15044,4.1483,4.1483,4.14465,4.148,4.14678,4.14709,4.14403,4.14403,4.14556,4.148,4.14586,4.14709,4.14526,4.14526,4.14647,4.148,4.14709,4.14739,4.1483,4.14678,4.14282,4.14709,4.14403,4.14434,4.14312,4.14373,4.14312,4.14465,4.14312,4.14312,4.14312,4.1419V v.b.c.voltage.min 4.13123,4.13427,4.13397,4.13397,4.13336,4.13214,4.13732,4.14038,4.13915,4.13885,4.13794,4.13641,4.13824,4.14159,4.14068,4.14007,4.13855,4.13824,4.1355,4.13885,4.13702,4.13794,4.13611,4.1358,4.13855,4.14099,4.13915,4.14007,4.13794,4.13794,4.13641,4.13855,4.13794,4.13824,4.13702,4.13641,4.13367,4.1358,4.1355,4.1358,4.13397,4.13275,4.13488,4.13855,4.13702,4.13702,4.13702,4.13732,4.14342,4.14586,4.14403,4.14617,4.14526,4.14403,4.13824,4.14159,4.13946,4.14038,4.13824,4.13824,4.14099,4.14342,4.14251,4.14251,4.14068,4.14038,4.13732,4.14099,4.13946,4.13976,4.13671,4.13671,4.13794,4.14038,4.13824,4.13946,4.13763,4.13763,4.13885,4.14038,4.13915,4.13946,4.14068,4.13885,4.1355,4.14007,4.13671,4.13732,4.13611,4.13641,4.13641,4.13732,4.13611,4.13641,4.13611,4.13458V v.b.cac v.b.consumption 0Wh/km v.b.coulomb.recd v.b.coulomb.used v.b.current
OVMS# metrics list v.b.p v.b.p.level.avg v.b.p.level.max v.b.p.level.min v.b.p.level.stddev v.b.p.temp.avg 28.43°C v.b.p.temp.max 29.4508°C v.b.p.temp.min 28.0234°C v.b.p.temp.stddev 0.36°C v.b.p.temp.stddev.max 0.65°C v.b.p.voltage.avg 4.14669V v.b.p.voltage.max 4.15532V v.b.p.voltage.min 4.13855V v.b.p.voltage.stddev 0.00669V v.b.p.voltage.stddev.max 0.00717V v.b.power
And a bunch of push notifications every time I connect the App, like this:
Regards, Mark
On 17 Nov 2018, at 10:51 PM, Michael Balzer <dexter@expeedo.de> wrote:
First implementation of general cell deviation checking and alerts is pushed.
Vehicle BMS: cell deviations & alerts
Renamed metrics: - v.b.c.level.* → v.b.p.level.* (for consistency)
New metrics: - v.b.c.(voltage,temp).(dev.max,alert) - v.b.p.(voltage,temp).(min,max,avg,stddev,stddev.max)
New configs: - vehicle [bms.dev.voltage.warn] -- threshold [V] - vehicle [bms.dev.voltage.alert] -- threshold [V] - vehicle [bms.dev.temp.warn] -- threshold [°C] - vehicle [bms.dev.temp.alert] -- threshold [°C] …all optional, default: warn at 120% stddev, alert at 200% stddev
New commands: - bms alerts → show cells with warn/alert levels
I changed the config scheme hoping a manual configuration normally isn't necessary with this automatic adaption to the standard deviation.
Please check and report if that idea works. If it doesn't, please report the deviations and necessary threshold levels on your batteries.
I also omitted the overall stddev alerts for now, I don't think those really are necessary, haven't had a single trigger on the Twizy for this.
Integration into the web chart page and historical data updates are still todo.
Migration for the Twizy battery monitor to the generalized scheme is in progress.
Regards, Michael
Am 17.11.18 um 11:53 schrieb Mark Webb-Johnson:
Short video showing Model S charging;
On 17 Nov 2018, at 6:13 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Ok. Will do.
Now you remind me, bms looks good on iPhone:
<image1.jpeg>
On 17 Nov 2018, at 6:08 PM, Michael Balzer <dexter@expeedo.de> wrote:
Yes, you can add a new menu to PageMenu_t like that. I suggest introducing a general tools menu instead of a specific one, i.e. "PageMenu_Tools".
To still fit the menu on one line in tablet mode (width down to 768 px) I suggest moving the Shell into the tools menu then.
Go ahead, I'm not working on the web framework at the moment.
Regards, Michael
Am 17.11.18 um 10:48 schrieb Mark Webb-Johnson:
Twizy code overrides the virtual short name function, so won’t suffer the issue.
I think it is a bug in vehicle factory (as modifying the vehicle type is reasonable), so fixed it there. Returning NULL is problematic. It would be so much easier for everything to return std::string, but concern is memory consumption and overhead.
I’d like to start converting RE TOOLS to just use the web server. First step is to work out how to add a menu onto the web server. It seems that the PageMenu_t is a fixed enum list (and similarly hard-coded in the web_framework.
Do I just add a ‘CAN bus’ menu there, by adding it to PageMenu_t, and supporting it where the other top level menus are? Or do you have any other suggestions/plans for this?
I don’t want to step on anything you are working on here.
The second stage will be to add displays under that, but I think that is fairly straight forward. I will mostly be displaying tables, and sending those over the web socket would be good.
Regards, Mark
On 17 Nov 2018, at 5:37 PM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
nice, thanks.
The short name is used for the menu label. It's meant to fall back to the long name (and seems to do so in your screenshot), so should not be null. But I admit I haven't tested it on a vehicle without a short name.
Btw, I'm currently working on the deviations and alerts.
Regards, Michael
Am 17.11.18 um 10:08 schrieb Mark Webb-Johnson:
Michael,
Looks good. It seems that you did everything necessary for the Model S already in your commit 2a84d861403f48142d6adcc16ad7a20cd458e427:
#include “ovms_webserver.h"
OvmsVehicleTeslaModelS::OvmsVehicleTeslaModelS() MyWebServer.RegisterPage("/bms/cellmon", "BMS cell monitor", OvmsWebServer::HandleBmsCellMonitor, PageMenu_Vehicle, PageAuth_Cookie);
OvmsVehicleTeslaModelS::~OvmsVehicleTeslaModelS() MyWebServer.DeregisterPage("/bms/cellmon");
From my devbench, replaying a CAN CRTD log file, I get this output:
<PastedGraphic-2.png>
The animation is very nice.
I am, however, getting crashes, as follows:
# xtensa-esp32-elf-addr2line -pfiaC -e 3.1.011-25-g2a84d86.ovms3.elf 0x400935d3 0x4009372b 0x400db90c 0x4012c0f7 0x4012d0e1 0x4012d1e0 0x4012ebc1 0x4012ecbd 0x400f8b65 0x400f912d 0x400fa27c 0x400fa29a 0x400f8b65 0x400fa3e3 0x400fa7ad 0x400faa77 0x400f767e 0x400ee40a 0x400ee459 0x400935d3: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 0x4009372b: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 0x400db90c: __cxx_fatal_exception_message at /home/openvehicles/build/esp-idf/components/cxx/cxx_exception_stubs.cpp:19 0x4012c0f7: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:216 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, char const*, std::__false_type) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457 0x4012d0e1: OvmsWebServer::CreateMenu[abi:cxx11](PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:393 0x4012d1e0: OvmsWebServer::HandleRoot(PageEntry&, PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:510 0x4012ebc1: PageEntry::Serve(PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 0x4012ecbd: OvmsWebServer::EventHandler(mg_connection*, int, void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f912d: mg_http_call_endpoint_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa27c: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa29a: mg_http_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa3e3: mg_recv_common at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400fa7ad: mg_if_recv_tcp_cb at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 (inlined by) mg_handle_tcp_read at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3723 (inlined by) mg_mgr_handle_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3844 0x400faa77: mg_socket_if_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f767e: mg_mgr_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400ee40a: OvmsNetManager::MongooseTask() at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:560 0x400ee459: MongooseRawTask(void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:545
On my development bench module I get this crash 1 in 4 times or so. On my real car, 100% of the time.
That code path leads into MyVehicleFactory.ActiveVehicleShortName(). Those should all be ‘const char*’, but it is possible for NULL to be returned. I will look into it in more detail.
Regards, Mark.
On 17 Nov 2018, at 7:35 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark, Tamás,
I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI.
Please see git log for details and send some screenshots.
Regards, Michael
Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson:
OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to use it, and support came down to just a few simple lines of code.
For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational.
c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with using std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way of doing that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of data ready to commit to metrics, so will need to think about this some more.
I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall aggregates, etc). There is a very basic ‘bms status’ command implemented.
Let me know what you think of it.
Regards, Mark
On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as…
- OvmsVehicle::ResetCellStats(); - Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level?
On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the vehicle / user.
There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion bitset, i.e.
- OvmsVehicle::RestartCellVoltages(); - OvmsVehicle::RestartCellTemperatures();
…as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation.
Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these thresholds are currently fixed to…
// Battery cell/cmod deviation alert thresholds: #define BATT_DEV_TEMP_ALERT 3 // = 3 °C #define BATT_DEV_VOLT_ALERT 6 // = 30 mV
// ...thresholds for overall stddev: #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV
…these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. So these should be configurable, i.e.
- vehicle bms.dev.temp.alert [°C] - vehicle bms.dev.voltage.alert [V] - vehicle bms.stddev.temp.watch [°C] - vehicle bms.stddev.temp.alert [°C] - vehicle bms.stddev.voltage.watch [V] - vehicle bms.stddev.voltage.alert [V]
I can generalize the Twizy code for all of this.
The Twizy battery monitoring command set is:
OVMS# xrt batt ? data-cell Output cell record data-pack Output pack record reset Reset alerts & watches status Status report tdev Show temperature deviations temp Show temperatures vdev Show voltage deviations volt Show voltages
The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the output within the SMS msg size limit.
"status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and "tdev" show all cells.
The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set.
The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on the Twizy, sending a vector metric to the server is just a matter of…
std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; msg.append(m_mon.m_mot_torque_drv->AsString()); MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str());
Neat.
The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a lot of additional data volume on large packs.
The Twizy layout may be either…
- 14 cell groups in the pack - 2 cell groups in each module - 7 modules in the pack - Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) - Each module has 1 temperature measurements (so, 7 individual temperature measurements) - That means: - OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) - OvmsVehicle::SetCellArrangementTemperature(7, 1, 7)
…for the original battery, or for an LFP type replacement…
- 16 cell groups in the pack - 16 cell groups in each module - 1 module in the pack - Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) - Each module has 3 temperature measurements (so, 3 individual temperature measurements) - That means: - OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) - OvmsVehicle::SetCellArrangementTemperature(3, 3, 3)
Regards, Michael
Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson:
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@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@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@lists.openvehicles.com:
Send OvmsDev mailing list submissions to ovmsdev@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@lists.openvehicles.com
You can reach the person managing the list at ovmsdev-owner@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@webb-johnson.net> <mark@webb-johnson.net> To: OVMS Developers <ovmsdev@lists.openvehicles.com> <ovmsdev@lists.openvehicles.com> Subject: Re: [Ovmsdev] Custom metrics Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@webb-johnson.net> <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@expeedo.de> <dexter@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> <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> <https://github.com/russdill/lwip/commit/dfeba616>. Another is TUN/TAP, again with reference code for LWIP <https://github.com/russdill/lwip/commit/47ca42f8> <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@expeedo.de <mailto:dexter@expeedo.de> <dexter@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> <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@expeedo.de <mailto:dexter@expeedo.de> <dexter@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> <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
The voltages from your metrics dump have a std dev of just 3 mV, while the v.b.p. dump shows 6.7 mV and a max of 7.2 mV: v.b.p.voltage.stddev 0.00669V v.b.p.voltage.stddev.max 0.00717V …so either that's a strange bug or the battery pack has a lot of fluctuations on the cell readings leading to sudden jumps. Tamás, your readings look more consistent, but also show some very large deviations. Mark & Tamás, please try manual thresholds: config set vehicle bms.dev.voltage.warn 0.02 config set vehicle bms.dev.voltage.alert 0.03 config set vehicle bms.dev.temp.warn 2 config set vehicle bms.dev.temp.alert 3 …if that still produces alerts, try raising them further. Regards, Michael Am 17.11.18 um 16:41 schrieb Michael Balzer:
Obviously not working for you. Cells that exceeded the alert threshold deviation from average get marked with "!", and "?" = warn threshold exceeded.
So at some point, many cells exceeded 200% stddev -- obviously not in the established overall situation. Is there maybe some init phase with unstable / incomplete readings that needs to be skipped on the Model S?
If so, a "bms reset" should clean the alerts up. Can you try that?
Regards, Michael
Am 17.11.18 um 16:01 schrieb Mark Webb-Johnson:
Not really sure how to interpret this. I get:
OVMS# bms alerts Voltage: SD=7mV !1:-7mV !2:-4mV !3:-4mV !4:-5mV !5:-5mV !6:-6mV !7:-1mV !8:+2mV !9:+0mV !10:+0mV !11:+0mV !12:-2mV ?13:+0mV !14:+4mV !15:+2mV !16:+2mV !17:+0mV !18:+0mV !19:-3mV !20:+0mV !21:-1mV ?22:+0mV !23:-2mV !24:-2mV !26:+2mV !27:+1mV !28:+2mV ?29:+0mV !30:+0mV !31:-2mV ?33:+0mV !35:-1mV !36:-2mV ?37:-5mV !38:-3mV !39:-2mV !40:-2mV !41:-4mV !42:-6mV !43:-3mV !44:+0mV !45:-1mV !46:-1mV !47:-1mV !48:-1mV !49:+6mV !50:+7mV !51:+6mV !52:+8mV !53:+7mV !54:+6mV !55:+1mV !56:+4mV !57:+1mV !58:+4mV !59:+0mV !60:+0mV !61:+3mV !62:+5mV !63:+4mV !64:+4mV !65:+2mV !66:+3mV !67:-1mV !68:+2mV !69:+1mV !70:+1mV !71:-1mV !72:-1mV !74:+2mV !76:+1mV ?77:+0mV !78:-1mV !79:+1mV !80:+3mV !81:+1mV !82:+2mV !83:+2mV !84:+1mV !85:-3mV !86:+2mV !87:-1mV !88:-1mV !89:-3mV !90:-2mV !91:-2mV !92:-1mV !93:-2mV !94:-2mV !95:-3mV !96:-4mV Temperature: SD=0.6C ?1:+0.5C ?2:+1.0C ?3:+0.3C ?4:+0.3C ?5:-0.2C ?7:-0.3C ?9:-0.2C !10:-0.2C ?12:-0.4C ?13:-0.3C ?14:-0.4C ?15:-0.5C ?16:-0.3C ?17:+0.8C !18:-0.3C ?19:-0.1C ?20:-0.3C ?21:-0.1C !22:-0.4C !24:-0.5C ?25:-0.3C ?26:-0.4C ?28:-0.3C ?29:+0.7C ?30:+0.3C ?31:+0.9C ?32:+0.5C
OVMS# metrics list v.b.c v.b.c.temp 28.8652,29.4386,28.6334,28.6822,28.1942,28.5114,28.1454,28.4626,28.182,28.3406,28.3894,28.121,28.1088,28.1454,28.0112,28.182,28.9262,28.243,28.2674,28.2186,28.2918,28.0844,28.3528,28.0356,28.1454,28.1088,28.4626,28.2186,28.975,28.7554,29.0604,28.9384°C v.b.c.temp.alert 1,2,1,1,1,1,1,0,1,2,0,1,1,1,1,1,2,2,1,1,1,1,1,1,1,1,0,1,2,1,1,2 v.b.c.temp.dev.max 0.52,1.03,0.31,0.26,-0.23,0.1,-0.29,-0.07,-0.25,-0.18,0.04,-0.44,-0.31,-0.39,-0.46,-0.34,0.76,-0.27,-0.15,-0.3,-0.13,-0.45,-0.08,-0.49,-0.28,-0.41,0.09,-0.28,0.73,0.34,0.92,0.52°C v.b.c.temp.max 28.8774,29.4386,28.6578,28.6822,28.1942,28.5236,28.1454,28.4626,28.182,28.3406,28.3894,28.121,28.1088,28.1454,28.0112,28.182,29.1092,28.243,28.2674,28.2186,28.2918,28.0844,28.3528,28.0356,28.1576,28.1088,28.4626,28.2186,29.0848,28.7554,29.2678,28.9384°C v.b.c.temp.min 28.853,29.3654,28.6212,28.5724,28.1332,28.3894,28.1088,28.2796,28.1332,28.1698,28.3894,27.9136,28.0966,27.9624,27.9014,28.0112,28.9262,28.0844,28.2674,28.0478,28.2796,27.9014,28.3406,27.8648,28.121,27.938,28.426,28.0722,28.975,28.609,29.0604,28.8042°C v.b.c.voltage 4.13794,4.14099,4.14099,4.14099,4.14007,4.13915,4.14465,4.1477,4.14586,4.14556,4.14465,4.14373,4.14556,4.14922,4.14739,4.14709,4.14586,4.14586,4.14251,4.14556,4.14434,4.14495,4.14373,4.14342,4.14586,4.148,4.14586,4.14709,4.14526,4.14526,4.14342,4.14556,4.14526,4.14556,4.14434,4.14342,4.14038,4.14251,4.14282,4.14312,4.14099,4.13946,4.14251,4.14586,4.14434,4.14465,4.14465,4.14434,4.15197,4.15318,4.15166,4.1541,4.15318,4.15166,4.14709,4.14922,4.14709,4.14861,4.14617,4.14586,4.148,4.15074,4.14983,4.15044,4.1477,4.148,4.14465,4.148,4.14678,4.14647,4.14403,4.14403,4.14556,4.148,4.14586,4.14647,4.14465,4.14526,4.14617,4.148,4.14617,4.14647,4.14739,4.14678,4.14251,4.14709,4.14373,4.14434,4.14282,4.14373,4.14312,4.14465,4.14282,4.14312,4.14282,4.1419V v.b.c.voltage.alert 2,1,1,1,1,1,2,1,2,2,2,2,1,1,1,2,2,2,1,2,2,1,1,1,0,1,2,2,1,2,1,0,1,0,2,2,1,1,1,1,1,1,1,2,2,2,2,2,1,2,1,2,2,1,2,1,2,1,2,2,1,1,1,1,1,1,2,1,2,2,2,2,0,1,0,2,1,2,2,1,2,2,2,2,1,2,2,2,1,1,1,2,1,1,1,1 v.b.c.voltage.dev.max -0.0082,-0.00487,-0.00498,-0.00508,-0.00583,-0.00674,-0.00139,0.00257,0.00096,0.00086,-0.00096,-0.00221,-0.00061,0.004,0.00275,0.00217,0.00096,0.00077,-0.0034,0.00081,-0.0017,-0.00091,-0.00234,-0.00304,0.00068,0.00288,0.00124,0.0022,-0.00052,-0.00078,-0.0024,0.00095,-0.00103,-0.00061,-0.00179,-0.00224,-0.00546,-0.00335,-0.0032,-0.00271,-0.00506,-0.00644,-0.0036,0.00087,-0.00129,-0.00168,-0.00139,-0.00132,0.00648,0.00824,0.00648,0.00883,0.0081,0.00641,0.00161,0.00443,0.00222,0.00401,0.00096,0.00095,0.00342,0.00597,0.00469,0.00505,0.00318,0.00315,-0.00127,0.00291,0.00132,0.00197,-0.0024,-0.00168,-0.00072,0.00275,0.00069,0.00184,-0.00096,-0.0012,0.00125,0.0032,0.00166,0.00203,0.00291,0.00153,-0.00355,0.00214,-0.00225,-0.00171,-0.003,-0.00249,-0.00292,-0.00152,-0.00295,-0.00296,-0.00311,-0.00432V v.b.c.voltage.max 4.13794,4.14129,4.14099,4.14099,4.14007,4.13915,4.14465,4.1477,4.14586,4.14586,4.14556,4.14403,4.14556,4.14922,4.1477,4.14709,4.14586,4.14586,4.14251,4.14586,4.14434,4.14495,4.14373,4.14342,4.14586,4.148,4.14617,4.14709,4.14556,4.14526,4.14342,4.14586,4.14526,4.14556,4.14434,4.14373,4.14099,4.14282,4.14282,4.14312,4.14099,4.13946,4.14282,4.14617,4.14465,4.14465,4.14465,4.14434,4.15197,4.15349,4.15197,4.1541,4.15318,4.15166,4.14709,4.14922,4.14709,4.14861,4.14617,4.14647,4.14861,4.15105,4.15014,4.15044,4.1483,4.1483,4.14465,4.148,4.14678,4.14709,4.14403,4.14403,4.14556,4.148,4.14586,4.14709,4.14526,4.14526,4.14647,4.148,4.14709,4.14739,4.1483,4.14678,4.14282,4.14709,4.14403,4.14434,4.14312,4.14373,4.14312,4.14465,4.14312,4.14312,4.14312,4.1419V v.b.c.voltage.min 4.13123,4.13427,4.13397,4.13397,4.13336,4.13214,4.13732,4.14038,4.13915,4.13885,4.13794,4.13641,4.13824,4.14159,4.14068,4.14007,4.13855,4.13824,4.1355,4.13885,4.13702,4.13794,4.13611,4.1358,4.13855,4.14099,4.13915,4.14007,4.13794,4.13794,4.13641,4.13855,4.13794,4.13824,4.13702,4.13641,4.13367,4.1358,4.1355,4.1358,4.13397,4.13275,4.13488,4.13855,4.13702,4.13702,4.13702,4.13732,4.14342,4.14586,4.14403,4.14617,4.14526,4.14403,4.13824,4.14159,4.13946,4.14038,4.13824,4.13824,4.14099,4.14342,4.14251,4.14251,4.14068,4.14038,4.13732,4.14099,4.13946,4.13976,4.13671,4.13671,4.13794,4.14038,4.13824,4.13946,4.13763,4.13763,4.13885,4.14038,4.13915,4.13946,4.14068,4.13885,4.1355,4.14007,4.13671,4.13732,4.13611,4.13641,4.13641,4.13732,4.13611,4.13641,4.13611,4.13458V v.b.cac v.b.consumption 0Wh/km v.b.coulomb.recd v.b.coulomb.used v.b.current
OVMS# metrics list v.b.p v.b.p.level.avg v.b.p.level.max v.b.p.level.min v.b.p.level.stddev v.b.p.temp.avg 28.43°C v.b.p.temp.max 29.4508°C v.b.p.temp.min 28.0234°C v.b.p.temp.stddev 0.36°C v.b.p.temp.stddev.max 0.65°C v.b.p.voltage.avg 4.14669V v.b.p.voltage.max 4.15532V v.b.p.voltage.min 4.13855V v.b.p.voltage.stddev 0.00669V v.b.p.voltage.stddev.max 0.00717V v.b.power
And a bunch of push notifications every time I connect the App, like this:
Regards, Mark
On 17 Nov 2018, at 10:51 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
First implementation of general cell deviation checking and alerts is pushed.
Vehicle BMS: cell deviations & alerts Renamed metrics: - v.b.c.level.* → v.b.p.level.* (for consistency) New metrics: - v.b.c.(voltage,temp).(dev.max,alert) - v.b.p.(voltage,temp).(min,max,avg,stddev,stddev.max) New configs: - vehicle [bms.dev.voltage.warn] -- threshold [V] - vehicle [bms.dev.voltage.alert] -- threshold [V] - vehicle [bms.dev.temp.warn] -- threshold [°C] - vehicle [bms.dev.temp.alert] -- threshold [°C] …all optional, default: warn at 120% stddev, alert at 200% stddev New commands: - bms alerts → show cells with warn/alert levels
I changed the config scheme hoping a manual configuration normally isn't necessary with this automatic adaption to the standard deviation.
Please check and report if that idea works. If it doesn't, please report the deviations and necessary threshold levels on your batteries.
I also omitted the overall stddev alerts for now, I don't think those really are necessary, haven't had a single trigger on the Twizy for this.
Integration into the web chart page and historical data updates are still todo.
Migration for the Twizy battery monitor to the generalized scheme is in progress.
Regards, Michael
Am 17.11.18 um 11:53 schrieb Mark Webb-Johnson:
Short video showing Model S charging;
On 17 Nov 2018, at 6:13 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
Ok. Will do.
Now you remind me, bms looks good on iPhone:
<image1.jpeg>
On 17 Nov 2018, at 6:08 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Yes, you can add a new menu to PageMenu_t like that. I suggest introducing a general tools menu instead of a specific one, i.e. "PageMenu_Tools".
To still fit the menu on one line in tablet mode (width down to 768 px) I suggest moving the Shell into the tools menu then.
Go ahead, I'm not working on the web framework at the moment.
Regards, Michael
Am 17.11.18 um 10:48 schrieb Mark Webb-Johnson: > Twizy code overrides the virtual short name function, so won’t suffer the issue. > > I think it is a bug in vehicle factory (as modifying the vehicle type is reasonable), so fixed it there. Returning NULL is problematic. It would be so > much easier for everything to return std::string, but concern is memory consumption and overhead. > > I’d like to start converting RE TOOLS to just use the web server. First step is to work out how to add a menu onto the web server. It seems that > the PageMenu_t is a fixed enum list (and similarly hard-coded in the web_framework. > > Do I just add a ‘CAN bus’ menu there, by adding it to PageMenu_t, and supporting it where the other top level menus are? Or do you have any other > suggestions/plans for this? > > I don’t want to step on anything you are working on here. > > > The second stage will be to add displays under that, but I think that is fairly straight forward. I will mostly be displaying tables, and sending those > over the web socket would be good. > > Regards, Mark > >> On 17 Nov 2018, at 5:37 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >> >> Mark, >> >> nice, thanks. >> >> The short name is used for the menu label. It's meant to fall back to the long name (and seems to do so in your screenshot), so should not be null. But >> I admit I haven't tested it on a vehicle without a short name. >> >> Btw, I'm currently working on the deviations and alerts. >> >> Regards, >> Michael >> >> >> Am 17.11.18 um 10:08 schrieb Mark Webb-Johnson: >>> Michael, >>> >>> Looks good. It seems that you did everything necessary for the Model S already in your commit 2a84d861403f48142d6adcc16ad7a20cd458e427: >>> >>> #include “ovms_webserver.h" >>> >>> OvmsVehicleTeslaModelS::OvmsVehicleTeslaModelS() >>> MyWebServer.RegisterPage("/bms/cellmon", "BMS cell monitor", OvmsWebServer::HandleBmsCellMonitor, PageMenu_Vehicle, PageAuth_Cookie); >>> >>> OvmsVehicleTeslaModelS::~OvmsVehicleTeslaModelS() >>> MyWebServer.DeregisterPage("/bms/cellmon"); >>> >>> >>> From my devbench, replaying a CAN CRTD log file, I get this output: >>> >>> <PastedGraphic-2.png> >>> >>> The animation is very nice. >>> >>> I am, however, getting crashes, as follows: >>> >>> # xtensa-esp32-elf-addr2line -pfiaC -e 3.1.011-25-g2a84d86.ovms3.elf 0x400935d3 0x4009372b 0x400db90c 0x4012c0f7 0x4012d0e1 0x4012d1e0 0x4012ebc1 >>> 0x4012ecbd 0x400f8b65 0x400f912d 0x400fa27c 0x400fa29a 0x400f8b65 0x400fa3e3 0x400fa7ad 0x400faa77 0x400f767e 0x400ee40a 0x400ee459 >>> 0x400935d3: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 >>> 0x4009372b: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 >>> 0x400db90c: __cxx_fatal_exception_message at /home/openvehicles/build/esp-idf/components/cxx/cxx_exception_stubs.cpp:19 >>> 0x4012c0f7: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char >>> const*, std::forward_iterator_tag) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:216 >>> (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, >>> char const*, std::__false_type) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195 >>> (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char >>> const*) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214 >>> (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> >>> const&) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457 >>> 0x4012d0e1: OvmsWebServer::CreateMenu[abi:cxx11](PageContext&) at >>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:393 >>> 0x4012d1e0: OvmsWebServer::HandleRoot(PageEntry&, PageContext&) at >>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:510 >>> 0x4012ebc1: PageEntry::Serve(PageContext&) at >>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 >>> 0x4012ecbd: OvmsWebServer::EventHandler(mg_connection*, int, void*) at >>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 >>> 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>> 0x400f912d: mg_http_call_endpoint_handler at >>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>> 0x400fa27c: mg_http_handler2 at >>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>> 0x400fa29a: mg_http_handler at >>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>> 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>> 0x400fa3e3: mg_recv_common at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>> 0x400fa7ad: mg_if_recv_tcp_cb at >>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>> (inlined by) mg_handle_tcp_read at >>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3723 >>> (inlined by) mg_mgr_handle_conn at >>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3844 >>> 0x400faa77: mg_socket_if_poll at >>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>> 0x400f767e: mg_mgr_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>> 0x400ee40a: OvmsNetManager::MongooseTask() at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:560 >>> 0x400ee459: MongooseRawTask(void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:545 >>> >>> >>> On my development bench module I get this crash 1 in 4 times or so. On my real car, 100% of the time. >>> >>> That code path leads into MyVehicleFactory.ActiveVehicleShortName(). Those should all be ‘const char*’, but it is possible for NULL to be returned. I >>> will look into it in more detail. >>> >>> Regards, Mark. >>> >>>> On 17 Nov 2018, at 7:35 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>> >>>> Mark, Tamás, >>>> >>>> I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI. >>>> >>>> Please see git log for details and send some screenshots. >>>> >>>> Regards, >>>> Michael >>>> >>>> >>>> Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson: >>>>> OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to >>>>> use it, and support came down to just a few simple lines of code. >>>>> >>>>> For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational. >>>>> >>>>> c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with using >>>>> std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way of >>>>> doing that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of data >>>>> ready to commit to metrics, so will need to think about this some more. >>>>> >>>>> I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall >>>>> aggregates, etc). There is a very basic ‘bms status’ command implemented. >>>>> >>>>> Let me know what you think of it. >>>>> >>>>> Regards, Mark >>>>> >>>>>> On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>> >>>>>> Mark, >>>>>> >>>>>> yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as… >>>>>> >>>>>> * OvmsVehicle::ResetCellStats(); >>>>>> * Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level? >>>>>> >>>>>> On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the >>>>>> vehicle / user. >>>>>> >>>>>> >>>>>> There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated >>>>>> by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion >>>>>> bitset, i.e. >>>>>> >>>>>> * OvmsVehicle::RestartCellVoltages(); >>>>>> * OvmsVehicle::RestartCellTemperatures(); >>>>>> >>>>>> …as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation. >>>>>> >>>>>> >>>>>> Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation >>>>>> thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for >>>>>> normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these >>>>>> thresholds are currently fixed to… >>>>>> >>>>>> // Battery cell/cmod deviation alert thresholds: >>>>>> #define BATT_DEV_TEMP_ALERT 3 // = 3 °C >>>>>> #define BATT_DEV_VOLT_ALERT 6 // = 30 mV >>>>>> >>>>>> // ...thresholds for overall stddev: >>>>>> #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C >>>>>> #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C >>>>>> #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV >>>>>> #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV >>>>>> >>>>>> …these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. >>>>>> So these should be configurable, i.e. >>>>>> >>>>>> * vehicle bms.dev.temp.alert [°C] >>>>>> * vehicle bms.dev.voltage.alert [V] >>>>>> * vehicle bms.stddev.temp.watch [°C] >>>>>> * vehicle bms.stddev.temp.alert [°C] >>>>>> * vehicle bms.stddev.voltage.watch [V] >>>>>> * vehicle bms.stddev.voltage.alert [V] >>>>>> >>>>>> I can generalize the Twizy code for all of this. >>>>>> >>>>>> >>>>>> The Twizy battery monitoring command set is: >>>>>> >>>>>> OVMS# xrt batt ? >>>>>> data-cell Output cell record >>>>>> data-pack Output pack record >>>>>> reset Reset alerts & watches >>>>>> status Status report >>>>>> tdev Show temperature deviations >>>>>> temp Show temperatures >>>>>> vdev Show voltage deviations >>>>>> volt Show voltages >>>>>> >>>>>> The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the >>>>>> output within the SMS msg size limit. >>>>>> >>>>>> "status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and >>>>>> "tdev" show all cells. >>>>>> >>>>>> The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set. >>>>>> >>>>>> >>>>>> The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on >>>>>> the Twizy, sending a vector metric to the server is just a matter of… >>>>>> >>>>>> std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; >>>>>> msg.append(m_mon.m_mot_torque_drv->AsString()); >>>>>> MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str()); >>>>>> >>>>>> Neat. >>>>>> >>>>>> The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a >>>>>> lot of additional data volume on large packs. >>>>>> >>>>>> >>>>>> The Twizy layout may be either… >>>>>> >>>>>> * 14 cell groups in the pack >>>>>> * 2 cell groups in each module >>>>>> * 7 modules in the pack >>>>>> * Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) >>>>>> * Each module has 1 temperature measurements (so, 7 individual temperature measurements) >>>>>> * That means: >>>>>> o OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) >>>>>> o OvmsVehicle::SetCellArrangementTemperature(7, 1, 7) >>>>>> >>>>>> …for the original battery, or for an LFP type replacement… >>>>>> >>>>>> * 16 cell groups in the pack >>>>>> * 16 cell groups in each module >>>>>> * 1 module in the pack >>>>>> * Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) >>>>>> * Each module has 3 temperature measurements (so, 3 individual temperature measurements) >>>>>> * That means: >>>>>> o OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) >>>>>> o OvmsVehicle::SetCellArrangementTemperature(3, 3, 3) >>>>>> >>>>>> >>>>>> Regards, >>>>>> Michael >>>>>> >>>>>> >>>>>> Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson: >>>>>>> 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: >>>>>>> o OvmsVehicle::SetCellArrangementVoltage(96, 6, 3) >>>>>>> o 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: >>>>>>> o OvmsVehicle::SetCellArrangementVoltage(99, 9, 9) >>>>>>> o 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: >>>>>>> o OvmsVehicle::SetCellArrangementVoltage(N, Y, Z) >>>>>>> o 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@webb-johnson.net <mailto:mark@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@spjeldager.dk <mailto:henrik.scheel@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@lists.openvehicles.com: >>>>>>>>>> >>>>>>>>>> Send OvmsDev mailing list submissions to >>>>>>>>>> ovmsdev@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@lists.openvehicles.com >>>>>>>>>> >>>>>>>>>> You can reach the person managing the list at >>>>>>>>>> ovmsdev-owner@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@webb-johnson.net> >>>>>>>>>> To: OVMS Developers <ovmsdev@lists.openvehicles.com> >>>>>>>>>> Subject: Re: [Ovmsdev] Custom metrics >>>>>>>>>> Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com >>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>>>>>>>>> >>>>>>>>>>
There are some strange high and low values (-100C for temperatures, and +5V for voltages) - seemingly when the car wakes up or goes to sleep. I have added some functions in vehicle.{h, cpp} to provide automatic sanity checking (based on limits provided by the vehicle). On the Model S, that is now better, but still giving issues: OVMS# bms alerts Voltage: SD=5mV !77:+16mV !78:-59mV !80:+19mV Temperature: SD=0.7C ?1:+0.6C ?2:+1.2C ?3:+0.3C !4:+0.5C ?6:+0.2C !7:-0.5C ?9:-0.5C ?11:-0.4C ?13:-0.8C ?14:-0.4C !15:-0.5C !19:-0.5C ?20:-0.3C ?21:-0.3C ?22:-0.3C ?23:-0.2C ?24:-0.4C ?25:-0.3C ?29:+0.7C ?30:+0.6C ?31:+0.8C ?32:+0.9C I think the temperature variances are correct and normal. I see some big differences in voltage min/max on some cells that look like spurious readings. Not sure how to address that - it is going to be hard to discard these readings. For example, see attached. Regards, Mark
On 17 Nov 2018, at 11:41 PM, Michael Balzer <dexter@expeedo.de> wrote:
Obviously not working for you. Cells that exceeded the alert threshold deviation from average get marked with "!", and "?" = warn threshold exceeded.
So at some point, many cells exceeded 200% stddev -- obviously not in the established overall situation. Is there maybe some init phase with unstable / incomplete readings that needs to be skipped on the Model S?
If so, a "bms reset" should clean the alerts up. Can you try that?
Regards, Michael
Am 17.11.18 um 16:01 schrieb Mark Webb-Johnson:
Not really sure how to interpret this. I get:
OVMS# bms alerts Voltage: SD=7mV !1:-7mV !2:-4mV !3:-4mV !4:-5mV !5:-5mV !6:-6mV !7:-1mV !8:+2mV !9:+0mV !10:+0mV !11:+0mV !12:-2mV ?13:+0mV !14:+4mV !15:+2mV !16:+2mV !17:+0mV !18:+0mV !19:-3mV !20:+0mV !21:-1mV ?22:+0mV !23:-2mV !24:-2mV !26:+2mV !27:+1mV !28:+2mV ?29:+0mV !30:+0mV !31:-2mV ?33:+0mV !35:-1mV !36:-2mV ?37:-5mV !38:-3mV !39:-2mV !40:-2mV !41:-4mV !42:-6mV !43:-3mV !44:+0mV !45:-1mV !46:-1mV !47:-1mV !48:-1mV !49:+6mV !50:+7mV !51:+6mV !52:+8mV !53:+7mV !54:+6mV !55:+1mV !56:+4mV !57:+1mV !58:+4mV !59:+0mV !60:+0mV !61:+3mV !62:+5mV !63:+4mV !64:+4mV !65:+2mV !66:+3mV !67:-1mV !68:+2mV !69:+1mV !70:+1mV !71:-1mV !72:-1mV !74:+2mV !76:+1mV ?77:+0mV !78:-1mV !79:+1mV !80:+3mV !81:+1mV !82:+2mV !83:+2mV !84:+1mV !85:-3mV !86:+2mV !87:-1mV !88:-1mV !89:-3mV !90:-2mV !91:-2mV !92:-1mV !93:-2mV !94:-2mV !95:-3mV !96:-4mV Temperature: SD=0.6C ?1:+0.5C ?2:+1.0C ?3:+0.3C ?4:+0.3C ?5:-0.2C ?7:-0.3C ?9:-0.2C !10:-0.2C ?12:-0.4C ?13:-0.3C ?14:-0.4C ?15:-0.5C ?16:-0.3C ?17:+0.8C !18:-0.3C ?19:-0.1C ?20:-0.3C ?21:-0.1C !22:-0.4C !24:-0.5C ?25:-0.3C ?26:-0.4C ?28:-0.3C ?29:+0.7C ?30:+0.3C ?31:+0.9C ?32:+0.5C
OVMS# metrics list v.b.c v.b.c.temp 28.8652,29.4386,28.6334,28.6822,28.1942,28.5114,28.1454,28.4626,28.182,28.3406,28.3894,28.121,28.1088,28.1454,28.0112,28.182,28.9262,28.243,28.2674,28.2186,28.2918,28.0844,28.3528,28.0356,28.1454,28.1088,28.4626,28.2186,28.975,28.7554,29.0604,28.9384°C v.b.c.temp.alert 1,2,1,1,1,1,1,0,1,2,0,1,1,1,1,1,2,2,1,1,1,1,1,1,1,1,0,1,2,1,1,2 v.b.c.temp.dev.max 0.52,1.03,0.31,0.26,-0.23,0.1,-0.29,-0.07,-0.25,-0.18,0.04,-0.44,-0.31,-0.39,-0.46,-0.34,0.76,-0.27,-0.15,-0.3,-0.13,-0.45,-0.08,-0.49,-0.28,-0.41,0.09,-0.28,0.73,0.34,0.92,0.52°C v.b.c.temp.max 28.8774,29.4386,28.6578,28.6822,28.1942,28.5236,28.1454,28.4626,28.182,28.3406,28.3894,28.121,28.1088,28.1454,28.0112,28.182,29.1092,28.243,28.2674,28.2186,28.2918,28.0844,28.3528,28.0356,28.1576,28.1088,28.4626,28.2186,29.0848,28.7554,29.2678,28.9384°C v.b.c.temp.min 28.853,29.3654,28.6212,28.5724,28.1332,28.3894,28.1088,28.2796,28.1332,28.1698,28.3894,27.9136,28.0966,27.9624,27.9014,28.0112,28.9262,28.0844,28.2674,28.0478,28.2796,27.9014,28.3406,27.8648,28.121,27.938,28.426,28.0722,28.975,28.609,29.0604,28.8042°C v.b.c.voltage 4.13794,4.14099,4.14099,4.14099,4.14007,4.13915,4.14465,4.1477,4.14586,4.14556,4.14465,4.14373,4.14556,4.14922,4.14739,4.14709,4.14586,4.14586,4.14251,4.14556,4.14434,4.14495,4.14373,4.14342,4.14586,4.148,4.14586,4.14709,4.14526,4.14526,4.14342,4.14556,4.14526,4.14556,4.14434,4.14342,4.14038,4.14251,4.14282,4.14312,4.14099,4.13946,4.14251,4.14586,4.14434,4.14465,4.14465,4.14434,4.15197,4.15318,4.15166,4.1541,4.15318,4.15166,4.14709,4.14922,4.14709,4.14861,4.14617,4.14586,4.148,4.15074,4.14983,4.15044,4.1477,4.148,4.14465,4.148,4.14678,4.14647,4.14403,4.14403,4.14556,4.148,4.14586,4.14647,4.14465,4.14526,4.14617,4.148,4.14617,4.14647,4.14739,4.14678,4.14251,4.14709,4.14373,4.14434,4.14282,4.14373,4.14312,4.14465,4.14282,4.14312,4.14282,4.1419V v.b.c.voltage.alert 2,1,1,1,1,1,2,1,2,2,2,2,1,1,1,2,2,2,1,2,2,1,1,1,0,1,2,2,1,2,1,0,1,0,2,2,1,1,1,1,1,1,1,2,2,2,2,2,1,2,1,2,2,1,2,1,2,1,2,2,1,1,1,1,1,1,2,1,2,2,2,2,0,1,0,2,1,2,2,1,2,2,2,2,1,2,2,2,1,1,1,2,1,1,1,1 v.b.c.voltage.dev.max -0.0082,-0.00487,-0.00498,-0.00508,-0.00583,-0.00674,-0.00139,0.00257,0.00096,0.00086,-0.00096,-0.00221,-0.00061,0.004,0.00275,0.00217,0.00096,0.00077,-0.0034,0.00081,-0.0017,-0.00091,-0.00234,-0.00304,0.00068,0.00288,0.00124,0.0022,-0.00052,-0.00078,-0.0024,0.00095,-0.00103,-0.00061,-0.00179,-0.00224,-0.00546,-0.00335,-0.0032,-0.00271,-0.00506,-0.00644,-0.0036,0.00087,-0.00129,-0.00168,-0.00139,-0.00132,0.00648,0.00824,0.00648,0.00883,0.0081,0.00641,0.00161,0.00443,0.00222,0.00401,0.00096,0.00095,0.00342,0.00597,0.00469,0.00505,0.00318,0.00315,-0.00127,0.00291,0.00132,0.00197,-0.0024,-0.00168,-0.00072,0.00275,0.00069,0.00184,-0.00096,-0.0012,0.00125,0.0032,0.00166,0.00203,0.00291,0.00153,-0.00355,0.00214,-0.00225,-0.00171,-0.003,-0.00249,-0.00292,-0.00152,-0.00295,-0.00296,-0.00311,-0.00432V v.b.c.voltage.max 4.13794,4.14129,4.14099,4.14099,4.14007,4.13915,4.14465,4.1477,4.14586,4.14586,4.14556,4.14403,4.14556,4.14922,4.1477,4.14709,4.14586,4.14586,4.14251,4.14586,4.14434,4.14495,4.14373,4.14342,4.14586,4.148,4.14617,4.14709,4.14556,4.14526,4.14342,4.14586,4.14526,4.14556,4.14434,4.14373,4.14099,4.14282,4.14282,4.14312,4.14099,4.13946,4.14282,4.14617,4.14465,4.14465,4.14465,4.14434,4.15197,4.15349,4.15197,4.1541,4.15318,4.15166,4.14709,4.14922,4.14709,4.14861,4.14617,4.14647,4.14861,4.15105,4.15014,4.15044,4.1483,4.1483,4.14465,4.148,4.14678,4.14709,4.14403,4.14403,4.14556,4.148,4.14586,4.14709,4.14526,4.14526,4.14647,4.148,4.14709,4.14739,4.1483,4.14678,4.14282,4.14709,4.14403,4.14434,4.14312,4.14373,4.14312,4.14465,4.14312,4.14312,4.14312,4.1419V v.b.c.voltage.min 4.13123,4.13427,4.13397,4.13397,4.13336,4.13214,4.13732,4.14038,4.13915,4.13885,4.13794,4.13641,4.13824,4.14159,4.14068,4.14007,4.13855,4.13824,4.1355,4.13885,4.13702,4.13794,4.13611,4.1358,4.13855,4.14099,4.13915,4.14007,4.13794,4.13794,4.13641,4.13855,4.13794,4.13824,4.13702,4.13641,4.13367,4.1358,4.1355,4.1358,4.13397,4.13275,4.13488,4.13855,4.13702,4.13702,4.13702,4.13732,4.14342,4.14586,4.14403,4.14617,4.14526,4.14403,4.13824,4.14159,4.13946,4.14038,4.13824,4.13824,4.14099,4.14342,4.14251,4.14251,4.14068,4.14038,4.13732,4.14099,4.13946,4.13976,4.13671,4.13671,4.13794,4.14038,4.13824,4.13946,4.13763,4.13763,4.13885,4.14038,4.13915,4.13946,4.14068,4.13885,4.1355,4.14007,4.13671,4.13732,4.13611,4.13641,4.13641,4.13732,4.13611,4.13641,4.13611,4.13458V v.b.cac v.b.consumption 0Wh/km v.b.coulomb.recd v.b.coulomb.used v.b.current
OVMS# metrics list v.b.p v.b.p.level.avg v.b.p.level.max v.b.p.level.min v.b.p.level.stddev v.b.p.temp.avg 28.43°C v.b.p.temp.max 29.4508°C v.b.p.temp.min 28.0234°C v.b.p.temp.stddev 0.36°C v.b.p.temp.stddev.max 0.65°C v.b.p.voltage.avg 4.14669V v.b.p.voltage.max 4.15532V v.b.p.voltage.min 4.13855V v.b.p.voltage.stddev 0.00669V v.b.p.voltage.stddev.max 0.00717V v.b.power
And a bunch of push notifications every time I connect the App, like this:
Regards, Mark
On 17 Nov 2018, at 10:51 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
First implementation of general cell deviation checking and alerts is pushed.
Vehicle BMS: cell deviations & alerts
Renamed metrics: - v.b.c.level.* → v.b.p.level.* (for consistency)
New metrics: - v.b.c.(voltage,temp).(dev.max,alert) - v.b.p.(voltage,temp).(min,max,avg,stddev,stddev.max)
New configs: - vehicle [bms.dev.voltage.warn] -- threshold [V] - vehicle [bms.dev.voltage.alert] -- threshold [V] - vehicle [bms.dev.temp.warn] -- threshold [°C] - vehicle [bms.dev.temp.alert] -- threshold [°C] …all optional, default: warn at 120% stddev, alert at 200% stddev
New commands: - bms alerts → show cells with warn/alert levels
I changed the config scheme hoping a manual configuration normally isn't necessary with this automatic adaption to the standard deviation.
Please check and report if that idea works. If it doesn't, please report the deviations and necessary threshold levels on your batteries.
I also omitted the overall stddev alerts for now, I don't think those really are necessary, haven't had a single trigger on the Twizy for this.
Integration into the web chart page and historical data updates are still todo.
Migration for the Twizy battery monitor to the generalized scheme is in progress.
Regards, Michael
Am 17.11.18 um 11:53 schrieb Mark Webb-Johnson:
Short video showing Model S charging;
https://youtu.be/Q4vMPSwBFAo <https://youtu.be/Q4vMPSwBFAo>
On 17 Nov 2018, at 6:13 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
Ok. Will do.
Now you remind me, bms looks good on iPhone:
<image1.jpeg>
On 17 Nov 2018, at 6:08 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Yes, you can add a new menu to PageMenu_t like that. I suggest introducing a general tools menu instead of a specific one, i.e. "PageMenu_Tools".
To still fit the menu on one line in tablet mode (width down to 768 px) I suggest moving the Shell into the tools menu then.
Go ahead, I'm not working on the web framework at the moment.
Regards, Michael
Am 17.11.18 um 10:48 schrieb Mark Webb-Johnson: > Twizy code overrides the virtual short name function, so won’t suffer the issue. > > I think it is a bug in vehicle factory (as modifying the vehicle type is reasonable), so fixed it there. Returning NULL is problematic. It would be so much easier for everything to return std::string, but concern is memory consumption and overhead. > > I’d like to start converting RE TOOLS to just use the web server. First step is to work out how to add a menu onto the web server. It seems that the PageMenu_t is a fixed enum list (and similarly hard-coded in the web_framework. > > Do I just add a ‘CAN bus’ menu there, by adding it to PageMenu_t, and supporting it where the other top level menus are? Or do you have any other suggestions/plans for this? > > I don’t want to step on anything you are working on here. > > The second stage will be to add displays under that, but I think that is fairly straight forward. I will mostly be displaying tables, and sending those over the web socket would be good. > > Regards, Mark > >> On 17 Nov 2018, at 5:37 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >> >> Mark, >> >> nice, thanks. >> >> The short name is used for the menu label. It's meant to fall back to the long name (and seems to do so in your screenshot), so should not be null. But I admit I haven't tested it on a vehicle without a short name. >> >> Btw, I'm currently working on the deviations and alerts. >> >> Regards, >> Michael >> >> >> Am 17.11.18 um 10:08 schrieb Mark Webb-Johnson: >>> Michael, >>> >>> Looks good. It seems that you did everything necessary for the Model S already in your commit 2a84d861403f48142d6adcc16ad7a20cd458e427: >>> >>> #include “ovms_webserver.h" >>> >>> OvmsVehicleTeslaModelS::OvmsVehicleTeslaModelS() >>> MyWebServer.RegisterPage("/bms/cellmon", "BMS cell monitor", OvmsWebServer::HandleBmsCellMonitor, PageMenu_Vehicle, PageAuth_Cookie); >>> >>> OvmsVehicleTeslaModelS::~OvmsVehicleTeslaModelS() >>> MyWebServer.DeregisterPage("/bms/cellmon"); >>> >>> From my devbench, replaying a CAN CRTD log file, I get this output: >>> >>> <PastedGraphic-2.png> >>> >>> The animation is very nice. >>> >>> I am, however, getting crashes, as follows: >>> >>> # xtensa-esp32-elf-addr2line -pfiaC -e 3.1.011-25-g2a84d86.ovms3.elf 0x400935d3 0x4009372b 0x400db90c 0x4012c0f7 0x4012d0e1 0x4012d1e0 0x4012ebc1 0x4012ecbd 0x400f8b65 0x400f912d 0x400fa27c 0x400fa29a 0x400f8b65 0x400fa3e3 0x400fa7ad 0x400faa77 0x400f767e 0x400ee40a 0x400ee459 >>> 0x400935d3: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 >>> 0x4009372b: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 >>> 0x400db90c: __cxx_fatal_exception_message at /home/openvehicles/build/esp-idf/components/cxx/cxx_exception_stubs.cpp:19 >>> 0x4012c0f7: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:216 >>> (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, char const*, std::__false_type) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195 >>> (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214 >>> (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457 >>> 0x4012d0e1: OvmsWebServer::CreateMenu[abi:cxx11](PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:393 >>> 0x4012d1e0: OvmsWebServer::HandleRoot(PageEntry&, PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:510 >>> 0x4012ebc1: PageEntry::Serve(PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 >>> 0x4012ecbd: OvmsWebServer::EventHandler(mg_connection*, int, void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 >>> 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>> 0x400f912d: mg_http_call_endpoint_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>> 0x400fa27c: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>> 0x400fa29a: mg_http_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>> 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>> 0x400fa3e3: mg_recv_common at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>> 0x400fa7ad: mg_if_recv_tcp_cb at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>> (inlined by) mg_handle_tcp_read at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3723 >>> (inlined by) mg_mgr_handle_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3844 >>> 0x400faa77: mg_socket_if_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>> 0x400f767e: mg_mgr_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>> 0x400ee40a: OvmsNetManager::MongooseTask() at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:560 >>> 0x400ee459: MongooseRawTask(void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:545 >>> >>> On my development bench module I get this crash 1 in 4 times or so. On my real car, 100% of the time. >>> >>> That code path leads into MyVehicleFactory.ActiveVehicleShortName(). Those should all be ‘const char*’, but it is possible for NULL to be returned. I will look into it in more detail. >>> >>> Regards, Mark. >>> >>>> On 17 Nov 2018, at 7:35 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>> >>>> Mark, Tamás, >>>> >>>> I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI. >>>> >>>> Please see git log for details and send some screenshots. >>>> >>>> Regards, >>>> Michael >>>> >>>> >>>> Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson: >>>>> OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to use it, and support came down to just a few simple lines of code. >>>>> >>>>> For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational. >>>>> >>>>> c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with using std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way of doing that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of data ready to commit to metrics, so will need to think about this some more. >>>>> >>>>> I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall aggregates, etc). There is a very basic ‘bms status’ command implemented. >>>>> >>>>> Let me know what you think of it. >>>>> >>>>> Regards, Mark >>>>> >>>>>> On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>> >>>>>> Mark, >>>>>> >>>>>> yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as… >>>>>> OvmsVehicle::ResetCellStats(); >>>>>> Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level? >>>>>> On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the vehicle / user. >>>>>> >>>>>> >>>>>> There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion bitset, i.e. >>>>>> OvmsVehicle::RestartCellVoltages(); >>>>>> OvmsVehicle::RestartCellTemperatures(); >>>>>> …as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation. >>>>>> >>>>>> >>>>>> Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these thresholds are currently fixed to… >>>>>> // Battery cell/cmod deviation alert thresholds: >>>>>> #define BATT_DEV_TEMP_ALERT 3 // = 3 °C >>>>>> #define BATT_DEV_VOLT_ALERT 6 // = 30 mV >>>>>> >>>>>> // ...thresholds for overall stddev: >>>>>> #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C >>>>>> #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C >>>>>> #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV >>>>>> #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV >>>>>> …these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. So these should be configurable, i.e. >>>>>> vehicle bms.dev.temp.alert [°C] >>>>>> vehicle bms.dev.voltage.alert [V] >>>>>> vehicle bms.stddev.temp.watch [°C] >>>>>> vehicle bms.stddev.temp.alert [°C] >>>>>> vehicle bms.stddev.voltage.watch [V] >>>>>> vehicle bms.stddev.voltage.alert [V] >>>>>> I can generalize the Twizy code for all of this. >>>>>> >>>>>> >>>>>> The Twizy battery monitoring command set is: >>>>>> OVMS# xrt batt ? >>>>>> data-cell Output cell record >>>>>> data-pack Output pack record >>>>>> reset Reset alerts & watches >>>>>> status Status report >>>>>> tdev Show temperature deviations >>>>>> temp Show temperatures >>>>>> vdev Show voltage deviations >>>>>> volt Show voltages >>>>>> The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the output within the SMS msg size limit. >>>>>> >>>>>> "status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and "tdev" show all cells. >>>>>> >>>>>> The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set. >>>>>> >>>>>> >>>>>> The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on the Twizy, sending a vector metric to the server is just a matter of… >>>>>> std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; >>>>>> msg.append(m_mon.m_mot_torque_drv->AsString()); >>>>>> MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str()); >>>>>> Neat. >>>>>> >>>>>> The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a lot of additional data volume on large packs. >>>>>> >>>>>> >>>>>> The Twizy layout may be either… >>>>>> 14 cell groups in the pack >>>>>> 2 cell groups in each module >>>>>> 7 modules in the pack >>>>>> Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) >>>>>> Each module has 1 temperature measurements (so, 7 individual temperature measurements) >>>>>> That means: >>>>>> OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) >>>>>> OvmsVehicle::SetCellArrangementTemperature(7, 1, 7) >>>>>> …for the original battery, or for an LFP type replacement… >>>>>> >>>>>> 16 cell groups in the pack >>>>>> 16 cell groups in each module >>>>>> 1 module in the pack >>>>>> Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) >>>>>> Each module has 3 temperature measurements (so, 3 individual temperature measurements) >>>>>> That means: >>>>>> OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) >>>>>> OvmsVehicle::SetCellArrangementTemperature(3, 3, 3) >>>>>> >>>>>> Regards, >>>>>> Michael >>>>>> >>>>>> >>>>>> Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson: >>>>>>> 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@webb-johnson.net <mailto:mark@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@spjeldager.dk <mailto:henrik.scheel@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/ <http://www.spjeldager.dk/> >>>>>>>>> >>>>>>>>>> Den 10. nov. 2018 kl. 15.34 skrev ovmsdev-request@lists.openvehicles.com <mailto:ovmsdev-request@lists.openvehicles.com>: >>>>>>>>>> >>>>>>>>>> Send OvmsDev mailing list submissions to >>>>>>>>>> ovmsdev@lists.openvehicles.com <mailto:ovmsdev@lists.openvehicles.com> >>>>>>>>>> >>>>>>>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>> or, via email, send a message with subject or body 'help' to >>>>>>>>>> ovmsdev-request@lists.openvehicles.com <mailto:ovmsdev-request@lists.openvehicles.com> >>>>>>>>>> >>>>>>>>>> You can reach the person managing the list at >>>>>>>>>> ovmsdev-owner@lists.openvehicles.com <mailto:ovmsdev-owner@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@webb-johnson.net> <mailto:mark@webb-johnson.net> >>>>>>>>>> To: OVMS Developers <ovmsdev@lists.openvehicles.com> <mailto:ovmsdev@lists.openvehicles.com> >>>>>>>>>> Subject: Re: [Ovmsdev] Custom metrics >>>>>>>>>> Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@webb-johnson.net> <mailto:1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@expeedo.de> <mailto:dexter@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 likehttps://api.openvehicles.com:8080/VEHICLEID <https://api.openvehicles.com:8080/VEHICLEID> <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> <https://github.com/russdill/lwip/commit/dfeba616>. Another is TUN/TAP, again with reference code for LWIP<https://github.com/russdill/lwip/commit/47ca42f8> <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@expeedo.de <mailto:dexter@expeedo.de> <mailto:dexter@expeedo.de> <mailto:dexter@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> <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@expeedo.de <mailto:dexter@expeedo.de> <mailto:dexter@expeedo.de> <mailto:dexter@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><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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev><http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>> >>>>>>>>>>
Mark, filtering single readings or brick groups that way will not work, you need to discard the complete current series of readings and do a restart. If you don't, the omitted cell will complete the series on the next run, leading to an inconsistent series. That may be the source of those spurious big differences…? Regards, Michael Am 17.11.18 um 18:03 schrieb Mark Webb-Johnson:
There are some strange high and low values (-100C for temperatures, and +5V for voltages) - seemingly when the car wakes up or goes to sleep.
I have added some functions in vehicle.{h, cpp} to provide automatic sanity checking (based on limits provided by the vehicle).
On the Model S, that is now better, but still giving issues:
OVMS# bms alerts Voltage: SD=5mV !77:+16mV !78:-59mV !80:+19mV Temperature: SD=0.7C ?1:+0.6C ?2:+1.2C ?3:+0.3C !4:+0.5C ?6:+0.2C !7:-0.5C ?9:-0.5C ?11:-0.4C ?13:-0.8C ?14:-0.4C !15:-0.5C !19:-0.5C ?20:-0.3C ?21:-0.3C ?22:-0.3C ?23:-0.2C ?24:-0.4C ?25:-0.3C ?29:+0.7C ?30:+0.6C ?31:+0.8C ?32:+0.9C
I think the temperature variances are correct and normal. I see some big differences in voltage min/max on some cells that look like spurious readings. Not sure how to address that - it is going to be hard to discard these readings. For example, see attached.
Regards, Mark
On 17 Nov 2018, at 11:41 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Obviously not working for you. Cells that exceeded the alert threshold deviation from average get marked with "!", and "?" = warn threshold exceeded.
So at some point, many cells exceeded 200% stddev -- obviously not in the established overall situation. Is there maybe some init phase with unstable / incomplete readings that needs to be skipped on the Model S?
If so, a "bms reset" should clean the alerts up. Can you try that?
Regards, Michael
Am 17.11.18 um 16:01 schrieb Mark Webb-Johnson:
Not really sure how to interpret this. I get:
OVMS# bms alerts Voltage: SD=7mV !1:-7mV !2:-4mV !3:-4mV !4:-5mV !5:-5mV !6:-6mV !7:-1mV !8:+2mV !9:+0mV !10:+0mV !11:+0mV !12:-2mV ?13:+0mV !14:+4mV !15:+2mV !16:+2mV !17:+0mV !18:+0mV !19:-3mV !20:+0mV !21:-1mV ?22:+0mV !23:-2mV !24:-2mV !26:+2mV !27:+1mV !28:+2mV ?29:+0mV !30:+0mV !31:-2mV ?33:+0mV !35:-1mV !36:-2mV ?37:-5mV !38:-3mV !39:-2mV !40:-2mV !41:-4mV !42:-6mV !43:-3mV !44:+0mV !45:-1mV !46:-1mV !47:-1mV !48:-1mV !49:+6mV !50:+7mV !51:+6mV !52:+8mV !53:+7mV !54:+6mV !55:+1mV !56:+4mV !57:+1mV !58:+4mV !59:+0mV !60:+0mV !61:+3mV !62:+5mV !63:+4mV !64:+4mV !65:+2mV !66:+3mV !67:-1mV !68:+2mV !69:+1mV !70:+1mV !71:-1mV !72:-1mV !74:+2mV !76:+1mV ?77:+0mV !78:-1mV !79:+1mV !80:+3mV !81:+1mV !82:+2mV !83:+2mV !84:+1mV !85:-3mV !86:+2mV !87:-1mV !88:-1mV !89:-3mV !90:-2mV !91:-2mV !92:-1mV !93:-2mV !94:-2mV !95:-3mV !96:-4mV Temperature: SD=0.6C ?1:+0.5C ?2:+1.0C ?3:+0.3C ?4:+0.3C ?5:-0.2C ?7:-0.3C ?9:-0.2C !10:-0.2C ?12:-0.4C ?13:-0.3C ?14:-0.4C ?15:-0.5C ?16:-0.3C ?17:+0.8C !18:-0.3C ?19:-0.1C ?20:-0.3C ?21:-0.1C !22:-0.4C !24:-0.5C ?25:-0.3C ?26:-0.4C ?28:-0.3C ?29:+0.7C ?30:+0.3C ?31:+0.9C ?32:+0.5C
OVMS# metrics list v.b.c v.b.c.temp 28.8652,29.4386,28.6334,28.6822,28.1942,28.5114,28.1454,28.4626,28.182,28.3406,28.3894,28.121,28.1088,28.1454,28.0112,28.182,28.9262,28.243,28.2674,28.2186,28.2918,28.0844,28.3528,28.0356,28.1454,28.1088,28.4626,28.2186,28.975,28.7554,29.0604,28.9384°C v.b.c.temp.alert 1,2,1,1,1,1,1,0,1,2,0,1,1,1,1,1,2,2,1,1,1,1,1,1,1,1,0,1,2,1,1,2 v.b.c.temp.dev.max 0.52,1.03,0.31,0.26,-0.23,0.1,-0.29,-0.07,-0.25,-0.18,0.04,-0.44,-0.31,-0.39,-0.46,-0.34,0.76,-0.27,-0.15,-0.3,-0.13,-0.45,-0.08,-0.49,-0.28,-0.41,0.09,-0.28,0.73,0.34,0.92,0.52°C v.b.c.temp.max 28.8774,29.4386,28.6578,28.6822,28.1942,28.5236,28.1454,28.4626,28.182,28.3406,28.3894,28.121,28.1088,28.1454,28.0112,28.182,29.1092,28.243,28.2674,28.2186,28.2918,28.0844,28.3528,28.0356,28.1576,28.1088,28.4626,28.2186,29.0848,28.7554,29.2678,28.9384°C v.b.c.temp.min 28.853,29.3654,28.6212,28.5724,28.1332,28.3894,28.1088,28.2796,28.1332,28.1698,28.3894,27.9136,28.0966,27.9624,27.9014,28.0112,28.9262,28.0844,28.2674,28.0478,28.2796,27.9014,28.3406,27.8648,28.121,27.938,28.426,28.0722,28.975,28.609,29.0604,28.8042°C v.b.c.voltage 4.13794,4.14099,4.14099,4.14099,4.14007,4.13915,4.14465,4.1477,4.14586,4.14556,4.14465,4.14373,4.14556,4.14922,4.14739,4.14709,4.14586,4.14586,4.14251,4.14556,4.14434,4.14495,4.14373,4.14342,4.14586,4.148,4.14586,4.14709,4.14526,4.14526,4.14342,4.14556,4.14526,4.14556,4.14434,4.14342,4.14038,4.14251,4.14282,4.14312,4.14099,4.13946,4.14251,4.14586,4.14434,4.14465,4.14465,4.14434,4.15197,4.15318,4.15166,4.1541,4.15318,4.15166,4.14709,4.14922,4.14709,4.14861,4.14617,4.14586,4.148,4.15074,4.14983,4.15044,4.1477,4.148,4.14465,4.148,4.14678,4.14647,4.14403,4.14403,4.14556,4.148,4.14586,4.14647,4.14465,4.14526,4.14617,4.148,4.14617,4.14647,4.14739,4.14678,4.14251,4.14709,4.14373,4.14434,4.14282,4.14373,4.14312,4.14465,4.14282,4.14312,4.14282,4.1419V v.b.c.voltage.alert 2,1,1,1,1,1,2,1,2,2,2,2,1,1,1,2,2,2,1,2,2,1,1,1,0,1,2,2,1,2,1,0,1,0,2,2,1,1,1,1,1,1,1,2,2,2,2,2,1,2,1,2,2,1,2,1,2,1,2,2,1,1,1,1,1,1,2,1,2,2,2,2,0,1,0,2,1,2,2,1,2,2,2,2,1,2,2,2,1,1,1,2,1,1,1,1 v.b.c.voltage.dev.max -0.0082,-0.00487,-0.00498,-0.00508,-0.00583,-0.00674,-0.00139,0.00257,0.00096,0.00086,-0.00096,-0.00221,-0.00061,0.004,0.00275,0.00217,0.00096,0.00077,-0.0034,0.00081,-0.0017,-0.00091,-0.00234,-0.00304,0.00068,0.00288,0.00124,0.0022,-0.00052,-0.00078,-0.0024,0.00095,-0.00103,-0.00061,-0.00179,-0.00224,-0.00546,-0.00335,-0.0032,-0.00271,-0.00506,-0.00644,-0.0036,0.00087,-0.00129,-0.00168,-0.00139,-0.00132,0.00648,0.00824,0.00648,0.00883,0.0081,0.00641,0.00161,0.00443,0.00222,0.00401,0.00096,0.00095,0.00342,0.00597,0.00469,0.00505,0.00318,0.00315,-0.00127,0.00291,0.00132,0.00197,-0.0024,-0.00168,-0.00072,0.00275,0.00069,0.00184,-0.00096,-0.0012,0.00125,0.0032,0.00166,0.00203,0.00291,0.00153,-0.00355,0.00214,-0.00225,-0.00171,-0.003,-0.00249,-0.00292,-0.00152,-0.00295,-0.00296,-0.00311,-0.00432V v.b.c.voltage.max 4.13794,4.14129,4.14099,4.14099,4.14007,4.13915,4.14465,4.1477,4.14586,4.14586,4.14556,4.14403,4.14556,4.14922,4.1477,4.14709,4.14586,4.14586,4.14251,4.14586,4.14434,4.14495,4.14373,4.14342,4.14586,4.148,4.14617,4.14709,4.14556,4.14526,4.14342,4.14586,4.14526,4.14556,4.14434,4.14373,4.14099,4.14282,4.14282,4.14312,4.14099,4.13946,4.14282,4.14617,4.14465,4.14465,4.14465,4.14434,4.15197,4.15349,4.15197,4.1541,4.15318,4.15166,4.14709,4.14922,4.14709,4.14861,4.14617,4.14647,4.14861,4.15105,4.15014,4.15044,4.1483,4.1483,4.14465,4.148,4.14678,4.14709,4.14403,4.14403,4.14556,4.148,4.14586,4.14709,4.14526,4.14526,4.14647,4.148,4.14709,4.14739,4.1483,4.14678,4.14282,4.14709,4.14403,4.14434,4.14312,4.14373,4.14312,4.14465,4.14312,4.14312,4.14312,4.1419V v.b.c.voltage.min 4.13123,4.13427,4.13397,4.13397,4.13336,4.13214,4.13732,4.14038,4.13915,4.13885,4.13794,4.13641,4.13824,4.14159,4.14068,4.14007,4.13855,4.13824,4.1355,4.13885,4.13702,4.13794,4.13611,4.1358,4.13855,4.14099,4.13915,4.14007,4.13794,4.13794,4.13641,4.13855,4.13794,4.13824,4.13702,4.13641,4.13367,4.1358,4.1355,4.1358,4.13397,4.13275,4.13488,4.13855,4.13702,4.13702,4.13702,4.13732,4.14342,4.14586,4.14403,4.14617,4.14526,4.14403,4.13824,4.14159,4.13946,4.14038,4.13824,4.13824,4.14099,4.14342,4.14251,4.14251,4.14068,4.14038,4.13732,4.14099,4.13946,4.13976,4.13671,4.13671,4.13794,4.14038,4.13824,4.13946,4.13763,4.13763,4.13885,4.14038,4.13915,4.13946,4.14068,4.13885,4.1355,4.14007,4.13671,4.13732,4.13611,4.13641,4.13641,4.13732,4.13611,4.13641,4.13611,4.13458V v.b.cac v.b.consumption 0Wh/km v.b.coulomb.recd v.b.coulomb.used v.b.current
OVMS# metrics list v.b.p v.b.p.level.avg v.b.p.level.max v.b.p.level.min v.b.p.level.stddev v.b.p.temp.avg 28.43°C v.b.p.temp.max 29.4508°C v.b.p.temp.min 28.0234°C v.b.p.temp.stddev 0.36°C v.b.p.temp.stddev.max 0.65°C v.b.p.voltage.avg 4.14669V v.b.p.voltage.max 4.15532V v.b.p.voltage.min 4.13855V v.b.p.voltage.stddev 0.00669V v.b.p.voltage.stddev.max 0.00717V v.b.power
And a bunch of push notifications every time I connect the App, like this:
Regards, Mark
On 17 Nov 2018, at 10:51 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
First implementation of general cell deviation checking and alerts is pushed.
Vehicle BMS: cell deviations & alerts Renamed metrics: - v.b.c.level.* → v.b.p.level.* (for consistency) New metrics: - v.b.c.(voltage,temp).(dev.max,alert) - v.b.p.(voltage,temp).(min,max,avg,stddev,stddev.max) New configs: - vehicle [bms.dev.voltage.warn] -- threshold [V] - vehicle [bms.dev.voltage.alert] -- threshold [V] - vehicle [bms.dev.temp.warn] -- threshold [°C] - vehicle [bms.dev.temp.alert] -- threshold [°C] …all optional, default: warn at 120% stddev, alert at 200% stddev New commands: - bms alerts → show cells with warn/alert levels
I changed the config scheme hoping a manual configuration normally isn't necessary with this automatic adaption to the standard deviation.
Please check and report if that idea works. If it doesn't, please report the deviations and necessary threshold levels on your batteries.
I also omitted the overall stddev alerts for now, I don't think those really are necessary, haven't had a single trigger on the Twizy for this.
Integration into the web chart page and historical data updates are still todo.
Migration for the Twizy battery monitor to the generalized scheme is in progress.
Regards, Michael
Am 17.11.18 um 11:53 schrieb Mark Webb-Johnson:
Short video showing Model S charging;
On 17 Nov 2018, at 6:13 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
Ok. Will do.
Now you remind me, bms looks good on iPhone:
<image1.jpeg>
On 17 Nov 2018, at 6:08 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
> Yes, you can add a new menu to PageMenu_t like that. I suggest introducing a general tools menu instead of a specific one, i.e. "PageMenu_Tools". > > To still fit the menu on one line in tablet mode (width down to 768 px) I suggest moving the Shell into the tools menu then. > > Go ahead, I'm not working on the web framework at the moment. > > Regards, > Michael > > > Am 17.11.18 um 10:48 schrieb Mark Webb-Johnson: >> Twizy code overrides the virtual short name function, so won’t suffer the issue. >> >> I think it is a bug in vehicle factory (as modifying the vehicle type is reasonable), so fixed it there. Returning NULL is problematic. It would be so >> much easier for everything to return std::string, but concern is memory consumption and overhead. >> >> I’d like to start converting RE TOOLS to just use the web server. First step is to work out how to add a menu onto the web server. It seems that >> the PageMenu_t is a fixed enum list (and similarly hard-coded in the web_framework. >> >> Do I just add a ‘CAN bus’ menu there, by adding it to PageMenu_t, and supporting it where the other top level menus are? Or do you have any other >> suggestions/plans for this? >> >> I don’t want to step on anything you are working on here. >> >> >> The second stage will be to add displays under that, but I think that is fairly straight forward. I will mostly be displaying tables, and sending those >> over the web socket would be good. >> >> Regards, Mark >> >>> On 17 Nov 2018, at 5:37 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>> >>> Mark, >>> >>> nice, thanks. >>> >>> The short name is used for the menu label. It's meant to fall back to the long name (and seems to do so in your screenshot), so should not be null. >>> But I admit I haven't tested it on a vehicle without a short name. >>> >>> Btw, I'm currently working on the deviations and alerts. >>> >>> Regards, >>> Michael >>> >>> >>> Am 17.11.18 um 10:08 schrieb Mark Webb-Johnson: >>>> Michael, >>>> >>>> Looks good. It seems that you did everything necessary for the Model S already in your commit 2a84d861403f48142d6adcc16ad7a20cd458e427: >>>> >>>> #include “ovms_webserver.h" >>>> >>>> OvmsVehicleTeslaModelS::OvmsVehicleTeslaModelS() >>>> MyWebServer.RegisterPage("/bms/cellmon", "BMS cell monitor", OvmsWebServer::HandleBmsCellMonitor, PageMenu_Vehicle, PageAuth_Cookie); >>>> >>>> OvmsVehicleTeslaModelS::~OvmsVehicleTeslaModelS() >>>> MyWebServer.DeregisterPage("/bms/cellmon"); >>>> >>>> >>>> From my devbench, replaying a CAN CRTD log file, I get this output: >>>> >>>> <PastedGraphic-2.png> >>>> >>>> The animation is very nice. >>>> >>>> I am, however, getting crashes, as follows: >>>> >>>> # xtensa-esp32-elf-addr2line -pfiaC -e 3.1.011-25-g2a84d86.ovms3.elf 0x400935d3 0x4009372b 0x400db90c 0x4012c0f7 0x4012d0e1 0x4012d1e0 0x4012ebc1 >>>> 0x4012ecbd 0x400f8b65 0x400f912d 0x400fa27c 0x400fa29a 0x400f8b65 0x400fa3e3 0x400fa7ad 0x400faa77 0x400f767e 0x400ee40a 0x400ee459 >>>> 0x400935d3: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 >>>> 0x4009372b: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 >>>> 0x400db90c: __cxx_fatal_exception_message at /home/openvehicles/build/esp-idf/components/cxx/cxx_exception_stubs.cpp:19 >>>> 0x4012c0f7: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char >>>> const*, std::forward_iterator_tag) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:216 >>>> (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, >>>> char const*, std::__false_type) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195 >>>> (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char >>>> const*) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214 >>>> (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> >>>> const&) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457 >>>> 0x4012d0e1: OvmsWebServer::CreateMenu[abi:cxx11](PageContext&) at >>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:393 >>>> 0x4012d1e0: OvmsWebServer::HandleRoot(PageEntry&, PageContext&) at >>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:510 >>>> 0x4012ebc1: PageEntry::Serve(PageContext&) at >>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 >>>> 0x4012ecbd: OvmsWebServer::EventHandler(mg_connection*, int, void*) at >>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 >>>> 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>> 0x400f912d: mg_http_call_endpoint_handler at >>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>> 0x400fa27c: mg_http_handler2 at >>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>> 0x400fa29a: mg_http_handler at >>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>> 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>> 0x400fa3e3: mg_recv_common at >>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>> 0x400fa7ad: mg_if_recv_tcp_cb at >>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>> (inlined by) mg_handle_tcp_read at >>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3723 >>>> (inlined by) mg_mgr_handle_conn at >>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3844 >>>> 0x400faa77: mg_socket_if_poll at >>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>> 0x400f767e: mg_mgr_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>> 0x400ee40a: OvmsNetManager::MongooseTask() at >>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:560 >>>> 0x400ee459: MongooseRawTask(void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:545 >>>> >>>> >>>> On my development bench module I get this crash 1 in 4 times or so. On my real car, 100% of the time. >>>> >>>> That code path leads into MyVehicleFactory.ActiveVehicleShortName(). Those should all be ‘const char*’, but it is possible for NULL to be returned. I >>>> will look into it in more detail. >>>> >>>> Regards, Mark. >>>> >>>>> On 17 Nov 2018, at 7:35 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>> >>>>> Mark, Tamás, >>>>> >>>>> I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI. >>>>> >>>>> Please see git log for details and send some screenshots. >>>>> >>>>> Regards, >>>>> Michael >>>>> >>>>> >>>>> Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson: >>>>>> OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to >>>>>> use it, and support came down to just a few simple lines of code. >>>>>> >>>>>> For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational. >>>>>> >>>>>> c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with >>>>>> using std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way >>>>>> of doing that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of >>>>>> data ready to commit to metrics, so will need to think about this some more. >>>>>> >>>>>> I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall >>>>>> aggregates, etc). There is a very basic ‘bms status’ command implemented. >>>>>> >>>>>> Let me know what you think of it. >>>>>> >>>>>> Regards, Mark >>>>>> >>>>>>> On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>> >>>>>>> Mark, >>>>>>> >>>>>>> yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as… >>>>>>> >>>>>>> * OvmsVehicle::ResetCellStats(); >>>>>>> * Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level? >>>>>>> >>>>>>> On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the >>>>>>> vehicle / user. >>>>>>> >>>>>>> >>>>>>> There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated >>>>>>> by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion >>>>>>> bitset, i.e. >>>>>>> >>>>>>> * OvmsVehicle::RestartCellVoltages(); >>>>>>> * OvmsVehicle::RestartCellTemperatures(); >>>>>>> >>>>>>> …as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation. >>>>>>> >>>>>>> >>>>>>> Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation >>>>>>> thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for >>>>>>> normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these >>>>>>> thresholds are currently fixed to… >>>>>>> >>>>>>> // Battery cell/cmod deviation alert thresholds: >>>>>>> #define BATT_DEV_TEMP_ALERT 3 // = 3 °C >>>>>>> #define BATT_DEV_VOLT_ALERT 6 // = 30 mV >>>>>>> >>>>>>> // ...thresholds for overall stddev: >>>>>>> #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C >>>>>>> #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C >>>>>>> #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV >>>>>>> #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV >>>>>>> >>>>>>> …these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. >>>>>>> So these should be configurable, i.e. >>>>>>> >>>>>>> * vehicle bms.dev.temp.alert [°C] >>>>>>> * vehicle bms.dev.voltage.alert [V] >>>>>>> * vehicle bms.stddev.temp.watch [°C] >>>>>>> * vehicle bms.stddev.temp.alert [°C] >>>>>>> * vehicle bms.stddev.voltage.watch [V] >>>>>>> * vehicle bms.stddev.voltage.alert [V] >>>>>>> >>>>>>> I can generalize the Twizy code for all of this. >>>>>>> >>>>>>> >>>>>>> The Twizy battery monitoring command set is: >>>>>>> >>>>>>> OVMS# xrt batt ? >>>>>>> data-cell Output cell record >>>>>>> data-pack Output pack record >>>>>>> reset Reset alerts & watches >>>>>>> status Status report >>>>>>> tdev Show temperature deviations >>>>>>> temp Show temperatures >>>>>>> vdev Show voltage deviations >>>>>>> volt Show voltages >>>>>>> >>>>>>> The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the >>>>>>> output within the SMS msg size limit. >>>>>>> >>>>>>> "status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and >>>>>>> "tdev" show all cells. >>>>>>> >>>>>>> The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set. >>>>>>> >>>>>>> >>>>>>> The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on >>>>>>> the Twizy, sending a vector metric to the server is just a matter of… >>>>>>> >>>>>>> std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; >>>>>>> msg.append(m_mon.m_mot_torque_drv->AsString()); >>>>>>> MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str()); >>>>>>> >>>>>>> Neat. >>>>>>> >>>>>>> The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a >>>>>>> lot of additional data volume on large packs. >>>>>>> >>>>>>> >>>>>>> The Twizy layout may be either… >>>>>>> >>>>>>> * 14 cell groups in the pack >>>>>>> * 2 cell groups in each module >>>>>>> * 7 modules in the pack >>>>>>> * Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) >>>>>>> * Each module has 1 temperature measurements (so, 7 individual temperature measurements) >>>>>>> * That means: >>>>>>> o OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) >>>>>>> o OvmsVehicle::SetCellArrangementTemperature(7, 1, 7) >>>>>>> >>>>>>> …for the original battery, or for an LFP type replacement… >>>>>>> >>>>>>> * 16 cell groups in the pack >>>>>>> * 16 cell groups in each module >>>>>>> * 1 module in the pack >>>>>>> * Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) >>>>>>> * Each module has 3 temperature measurements (so, 3 individual temperature measurements) >>>>>>> * That means: >>>>>>> o OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) >>>>>>> o OvmsVehicle::SetCellArrangementTemperature(3, 3, 3) >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Michael >>>>>>> >>>>>>> >>>>>>> Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson: >>>>>>>> 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: >>>>>>>> o OvmsVehicle::SetCellArrangementVoltage(96, 6, 3) >>>>>>>> o 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: >>>>>>>> o OvmsVehicle::SetCellArrangementVoltage(99, 9, 9) >>>>>>>> o 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: >>>>>>>> o OvmsVehicle::SetCellArrangementVoltage(N, Y, Z) >>>>>>>> o 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@webb-johnson.net <mailto:mark@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@spjeldager.dk <mailto:henrik.scheel@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@lists.openvehicles.com: >>>>>>>>>>> >>>>>>>>>>> Send OvmsDev mailing list submissions to >>>>>>>>>>> ovmsdev@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@lists.openvehicles.com >>>>>>>>>>> >>>>>>>>>>> You can reach the person managing the list at >>>>>>>>>>> ovmsdev-owner@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@webb-johnson.net> >>>>>>>>>>> To: OVMS Developers <ovmsdev@lists.openvehicles.com> >>>>>>>>>>> Subject: Re: [Ovmsdev] Custom metrics >>>>>>>>>>> Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com >>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>>>>>>>>>> >>>>>>>>>>>
Unlike a standard indexed message (such as VIN, for example) where the messages come in #1, #2, #3, etc, these BMS messages come in seemingly at random. For example, here is a capture from cold wakeup: 1542472541.536441 1R11 6F2 0e ff ff ff ff ff ff ff 1542472541.636967 1R11 6F2 0f ff ff ff ff ff ff ff 1542472541.837607 1R11 6F2 11 ff ff ff ff ff ff ff 1542472542.136658 1R11 6F2 14 ff ff ff ff ff ff ff 1542472542.236201 1R11 6F2 15 ff ff ff ff ff ff ff 1542472542.537060 1R11 6F2 18 e7 c8 45 c2 8c 7c 23 1542472543.274424 1R11 6F2 1f f0 08 3a 92 8f f0 23 1542472543.472967 1R11 6F2 01 90 34 24 4d 49 53 d2 1542472543.973617 1R11 6F2 06 93 f4 24 4d 49 4f d2 1542472544.173053 1R11 6F2 08 91 b4 24 1d 49 43 d2 1542472544.671201 1R11 6F2 0d 97 b4 25 dd 48 3f d2 1542472545.173202 1R11 6F2 12 93 34 25 4d 49 4f d2 1542472545.685309 1R11 6F2 17 94 b4 24 2d 49 53 d2 1542472545.973614 1R11 6F2 1a 99 48 2e e2 89 c0 22 … 1542472606.575697 1R11 6F2 18 f0 08 48 42 8d a4 23 1542472607.075726 1R11 6F2 1d a7 48 2a d2 8a 90 22 1542472607.284635 1R11 6F2 1f f7 c8 3b 02 90 0c 24 1542472607.374752 1R11 6F2 00 8d f4 23 fd 48 3b d2 1542472608.078353 1R11 6F2 07 93 74 25 1d 49 3f d2 1542472608.373934 1R11 6F2 0a 92 34 24 2d 49 53 d2 1542472608.875669 1R11 6F2 0f 93 f4 24 4d 49 4f d2 1542472609.375819 1R11 6F2 14 96 b4 25 7d 49 57 d2 1542472609.875780 1R11 6F2 19 b0 c8 35 92 89 1c 23 1542472610.175548 1R11 6F2 1c d5 c8 33 72 89 9c 22 1542472610.375530 1R11 6F2 1e a4 48 2c c2 8c 00 23 1542472649.542261 1R11 6F2 1a 00 20 00 08 00 02 80 1542472649.648029 1R11 6F2 1b 00 20 00 08 00 02 80 1542472649.850761 1R11 6F2 1d 00 20 00 08 00 02 80 1542472650.141807 1R11 6F2 00 ff ff ff ff ff ff ff 1542472650.441905 1R11 6F2 03 ff ff ff ff ff ff ff 1542472650.642106 1R11 6F2 05 bd 33 4b cd 4c 1b cf 1542472651.178823 1R11 6F2 0a 92 74 24 3d 49 5b d2 1542472651.386026 1R11 6F2 0c 97 f4 25 7d 49 5f d2 1542472651.885083 1R11 6F2 11 96 b4 25 3d 49 57 d2 1542472652.178292 1R11 6F2 14 97 b4 25 6d 49 5b d2 1542472652.386909 1R11 6F2 16 95 b4 25 6d 49 4f d2 1542472652.678470 1R11 6F2 19 ab 88 34 42 89 08 23 1542472652.977144 1R11 6F2 1c cf 08 32 22 89 88 22 You can see the time difference between the first set of ‘ff ff ff’ and second set is quite large. 109 seconds. Looking at just a couple of specific messages: 1542472545.973614 1R11 6F2 1a 99 48 2e e2 89 c0 22 1542472549.173160 1R11 6F2 1a 9a 88 2e f2 89 c4 22 1542472561.979447 1R11 6F2 1a 9c 08 2f 12 8a c8 22 1542472571.576261 1R11 6F2 1a 9b c8 2e 12 8a cc 22 1542472574.775537 1R11 6F2 1a 9c 08 2f 02 8a c8 22 1542472593.975024 1R11 6F2 1a 9c 48 2f 02 8a cc 22 1542472600.375601 1R11 6F2 1a 9c 08 2f 02 8a cc 22 1542472649.542261 1R11 6F2 1a 00 20 00 08 00 02 80 1542472542.136658 1R11 6F2 14 ff ff ff ff ff ff ff 1542472561.373928 1R11 6F2 14 97 f4 25 7d 49 5b d2 1542472564.573971 1R11 6F2 14 97 f4 25 8d 49 67 d2 1542472583.774481 1R11 6F2 14 94 b4 25 7d 49 5f d2 1542472586.973971 1R11 6F2 14 96 b4 25 7d 49 5f d2 1542472609.375819 1R11 6F2 14 96 b4 25 7d 49 57 d2 1542472652.178292 1R11 6F2 14 97 b4 25 6d 49 5b d2 1542472661.785441 1R11 6F2 14 96 b4 25 6d 49 5f d2 It seems that voltage temperature readings (such as 1a) go negative-maximum as the module goes to sleep, and voltage readings go maximum as the module wakes up. But in some case, completely random: 1542472568.973842 1R11 6F2 00 8e f4 23 1d 49 3f d2 1542472604.182418 1R11 6F2 00 8e b4 23 fd 48 3b d2 1542472607.374752 1R11 6F2 00 8d f4 23 fd 48 3b d2 1542472650.141807 1R11 6F2 00 ff ff ff ff ff ff ff 1542472656.594506 1R11 6F2 00 8d f4 23 ed 48 3f d2 1542472666.183604 1R11 6F2 00 8e b4 23 ed 48 3b d2 Similarly for the spurious readings. It seems that the individual BMS modules are reporting these values directly onto the bus, with no centralised control. But given the arrangement of 4x14bit readings per message, that doesn’t really make sense (particularly for voltage, with 6 readings per module). It is quite simple to remove these out of range readings, and I could also simply discard all others in the same group. But, I suspect identifying the slightly out of range readings will be harder. I’ll try the group disable first, and see if that improves it… Regards, Mark.
On 18 Nov 2018, at 1:38 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
filtering single readings or brick groups that way will not work, you need to discard the complete current series of readings and do a restart.
If you don't, the omitted cell will complete the series on the next run, leading to an inconsistent series.
That may be the source of those spurious big differences…?
Regards, Michael
Am 17.11.18 um 18:03 schrieb Mark Webb-Johnson:
There are some strange high and low values (-100C for temperatures, and +5V for voltages) - seemingly when the car wakes up or goes to sleep.
I have added some functions in vehicle.{h, cpp} to provide automatic sanity checking (based on limits provided by the vehicle).
On the Model S, that is now better, but still giving issues:
OVMS# bms alerts Voltage: SD=5mV !77:+16mV !78:-59mV !80:+19mV Temperature: SD=0.7C ?1:+0.6C ?2:+1.2C ?3:+0.3C !4:+0.5C ?6:+0.2C !7:-0.5C ?9:-0.5C ?11:-0.4C ?13:-0.8C ?14:-0.4C !15:-0.5C !19:-0.5C ?20:-0.3C ?21:-0.3C ?22:-0.3C ?23:-0.2C ?24:-0.4C ?25:-0.3C ?29:+0.7C ?30:+0.6C ?31:+0.8C ?32:+0.9C
I think the temperature variances are correct and normal. I see some big differences in voltage min/max on some cells that look like spurious readings. Not sure how to address that - it is going to be hard to discard these readings. For example, see attached.
Regards, Mark
<PastedGraphic-5.png>
On 17 Nov 2018, at 11:41 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Obviously not working for you. Cells that exceeded the alert threshold deviation from average get marked with "!", and "?" = warn threshold exceeded.
So at some point, many cells exceeded 200% stddev -- obviously not in the established overall situation. Is there maybe some init phase with unstable / incomplete readings that needs to be skipped on the Model S?
If so, a "bms reset" should clean the alerts up. Can you try that?
Regards, Michael
Am 17.11.18 um 16:01 schrieb Mark Webb-Johnson:
Not really sure how to interpret this. I get:
OVMS# bms alerts Voltage: SD=7mV !1:-7mV !2:-4mV !3:-4mV !4:-5mV !5:-5mV !6:-6mV !7:-1mV !8:+2mV !9:+0mV !10:+0mV !11:+0mV !12:-2mV ?13:+0mV !14:+4mV !15:+2mV !16:+2mV !17:+0mV !18:+0mV !19:-3mV !20:+0mV !21:-1mV ?22:+0mV !23:-2mV !24:-2mV !26:+2mV !27:+1mV !28:+2mV ?29:+0mV !30:+0mV !31:-2mV ?33:+0mV !35:-1mV !36:-2mV ?37:-5mV !38:-3mV !39:-2mV !40:-2mV !41:-4mV !42:-6mV !43:-3mV !44:+0mV !45:-1mV !46:-1mV !47:-1mV !48:-1mV !49:+6mV !50:+7mV !51:+6mV !52:+8mV !53:+7mV !54:+6mV !55:+1mV !56:+4mV !57:+1mV !58:+4mV !59:+0mV !60:+0mV !61:+3mV !62:+5mV !63:+4mV !64:+4mV !65:+2mV !66:+3mV !67:-1mV !68:+2mV !69:+1mV !70:+1mV !71:-1mV !72:-1mV !74:+2mV !76:+1mV ?77:+0mV !78:-1mV !79:+1mV !80:+3mV !81:+1mV !82:+2mV !83:+2mV !84:+1mV !85:-3mV !86:+2mV !87:-1mV !88:-1mV !89:-3mV !90:-2mV !91:-2mV !92:-1mV !93:-2mV !94:-2mV !95:-3mV !96:-4mV Temperature: SD=0.6C ?1:+0.5C ?2:+1.0C ?3:+0.3C ?4:+0.3C ?5:-0.2C ?7:-0.3C ?9:-0.2C !10:-0.2C ?12:-0.4C ?13:-0.3C ?14:-0.4C ?15:-0.5C ?16:-0.3C ?17:+0.8C !18:-0.3C ?19:-0.1C ?20:-0.3C ?21:-0.1C !22:-0.4C !24:-0.5C ?25:-0.3C ?26:-0.4C ?28:-0.3C ?29:+0.7C ?30:+0.3C ?31:+0.9C ?32:+0.5C
OVMS# metrics list v.b.c v.b.c.temp 28.8652,29.4386,28.6334,28.6822,28.1942,28.5114,28.1454,28.4626,28.182,28.3406,28.3894,28.121,28.1088,28.1454,28.0112,28.182,28.9262,28.243,28.2674,28.2186,28.2918,28.0844,28.3528,28.0356,28.1454,28.1088,28.4626,28.2186,28.975,28.7554,29.0604,28.9384°C v.b.c.temp.alert 1,2,1,1,1,1,1,0,1,2,0,1,1,1,1,1,2,2,1,1,1,1,1,1,1,1,0,1,2,1,1,2 v.b.c.temp.dev.max 0.52,1.03,0.31,0.26,-0.23,0.1,-0.29,-0.07,-0.25,-0.18,0.04,-0.44,-0.31,-0.39,-0.46,-0.34,0.76,-0.27,-0.15,-0.3,-0.13,-0.45,-0.08,-0.49,-0.28,-0.41,0.09,-0.28,0.73,0.34,0.92,0.52°C v.b.c.temp.max 28.8774,29.4386,28.6578,28.6822,28.1942,28.5236,28.1454,28.4626,28.182,28.3406,28.3894,28.121,28.1088,28.1454,28.0112,28.182,29.1092,28.243,28.2674,28.2186,28.2918,28.0844,28.3528,28.0356,28.1576,28.1088,28.4626,28.2186,29.0848,28.7554,29.2678,28.9384°C v.b.c.temp.min 28.853,29.3654,28.6212,28.5724,28.1332,28.3894,28.1088,28.2796,28.1332,28.1698,28.3894,27.9136,28.0966,27.9624,27.9014,28.0112,28.9262,28.0844,28.2674,28.0478,28.2796,27.9014,28.3406,27.8648,28.121,27.938,28.426,28.0722,28.975,28.609,29.0604,28.8042°C v.b.c.voltage 4.13794,4.14099,4.14099,4.14099,4.14007,4.13915,4.14465,4.1477,4.14586,4.14556,4.14465,4.14373,4.14556,4.14922,4.14739,4.14709,4.14586,4.14586,4.14251,4.14556,4.14434,4.14495,4.14373,4.14342,4.14586,4.148,4.14586,4.14709,4.14526,4.14526,4.14342,4.14556,4.14526,4.14556,4.14434,4.14342,4.14038,4.14251,4.14282,4.14312,4.14099,4.13946,4.14251,4.14586,4.14434,4.14465,4.14465,4.14434,4.15197,4.15318,4.15166,4.1541,4.15318,4.15166,4.14709,4.14922,4.14709,4.14861,4.14617,4.14586,4.148,4.15074,4.14983,4.15044,4.1477,4.148,4.14465,4.148,4.14678,4.14647,4.14403,4.14403,4.14556,4.148,4.14586,4.14647,4.14465,4.14526,4.14617,4.148,4.14617,4.14647,4.14739,4.14678,4.14251,4.14709,4.14373,4.14434,4.14282,4.14373,4.14312,4.14465,4.14282,4.14312,4.14282,4.1419V v.b.c.voltage.alert 2,1,1,1,1,1,2,1,2,2,2,2,1,1,1,2,2,2,1,2,2,1,1,1,0,1,2,2,1,2,1,0,1,0,2,2,1,1,1,1,1,1,1,2,2,2,2,2,1,2,1,2,2,1,2,1,2,1,2,2,1,1,1,1,1,1,2,1,2,2,2,2,0,1,0,2,1,2,2,1,2,2,2,2,1,2,2,2,1,1,1,2,1,1,1,1 v.b.c.voltage.dev.max -0.0082,-0.00487,-0.00498,-0.00508,-0.00583,-0.00674,-0.00139,0.00257,0.00096,0.00086,-0.00096,-0.00221,-0.00061,0.004,0.00275,0.00217,0.00096,0.00077,-0.0034,0.00081,-0.0017,-0.00091,-0.00234,-0.00304,0.00068,0.00288,0.00124,0.0022,-0.00052,-0.00078,-0.0024,0.00095,-0.00103,-0.00061,-0.00179,-0.00224,-0.00546,-0.00335,-0.0032,-0.00271,-0.00506,-0.00644,-0.0036,0.00087,-0.00129,-0.00168,-0.00139,-0.00132,0.00648,0.00824,0.00648,0.00883,0.0081,0.00641,0.00161,0.00443,0.00222,0.00401,0.00096,0.00095,0.00342,0.00597,0.00469,0.00505,0.00318,0.00315,-0.00127,0.00291,0.00132,0.00197,-0.0024,-0.00168,-0.00072,0.00275,0.00069,0.00184,-0.00096,-0.0012,0.00125,0.0032,0.00166,0.00203,0.00291,0.00153,-0.00355,0.00214,-0.00225,-0.00171,-0.003,-0.00249,-0.00292,-0.00152,-0.00295,-0.00296,-0.00311,-0.00432V v.b.c.voltage.max 4.13794,4.14129,4.14099,4.14099,4.14007,4.13915,4.14465,4.1477,4.14586,4.14586,4.14556,4.14403,4.14556,4.14922,4.1477,4.14709,4.14586,4.14586,4.14251,4.14586,4.14434,4.14495,4.14373,4.14342,4.14586,4.148,4.14617,4.14709,4.14556,4.14526,4.14342,4.14586,4.14526,4.14556,4.14434,4.14373,4.14099,4.14282,4.14282,4.14312,4.14099,4.13946,4.14282,4.14617,4.14465,4.14465,4.14465,4.14434,4.15197,4.15349,4.15197,4.1541,4.15318,4.15166,4.14709,4.14922,4.14709,4.14861,4.14617,4.14647,4.14861,4.15105,4.15014,4.15044,4.1483,4.1483,4.14465,4.148,4.14678,4.14709,4.14403,4.14403,4.14556,4.148,4.14586,4.14709,4.14526,4.14526,4.14647,4.148,4.14709,4.14739,4.1483,4.14678,4.14282,4.14709,4.14403,4.14434,4.14312,4.14373,4.14312,4.14465,4.14312,4.14312,4.14312,4.1419V v.b.c.voltage.min 4.13123,4.13427,4.13397,4.13397,4.13336,4.13214,4.13732,4.14038,4.13915,4.13885,4.13794,4.13641,4.13824,4.14159,4.14068,4.14007,4.13855,4.13824,4.1355,4.13885,4.13702,4.13794,4.13611,4.1358,4.13855,4.14099,4.13915,4.14007,4.13794,4.13794,4.13641,4.13855,4.13794,4.13824,4.13702,4.13641,4.13367,4.1358,4.1355,4.1358,4.13397,4.13275,4.13488,4.13855,4.13702,4.13702,4.13702,4.13732,4.14342,4.14586,4.14403,4.14617,4.14526,4.14403,4.13824,4.14159,4.13946,4.14038,4.13824,4.13824,4.14099,4.14342,4.14251,4.14251,4.14068,4.14038,4.13732,4.14099,4.13946,4.13976,4.13671,4.13671,4.13794,4.14038,4.13824,4.13946,4.13763,4.13763,4.13885,4.14038,4.13915,4.13946,4.14068,4.13885,4.1355,4.14007,4.13671,4.13732,4.13611,4.13641,4.13641,4.13732,4.13611,4.13641,4.13611,4.13458V v.b.cac v.b.consumption 0Wh/km v.b.coulomb.recd v.b.coulomb.used v.b.current
OVMS# metrics list v.b.p v.b.p.level.avg v.b.p.level.max v.b.p.level.min v.b.p.level.stddev v.b.p.temp.avg 28.43°C v.b.p.temp.max 29.4508°C v.b.p.temp.min 28.0234°C v.b.p.temp.stddev 0.36°C v.b.p.temp.stddev.max 0.65°C v.b.p.voltage.avg 4.14669V v.b.p.voltage.max 4.15532V v.b.p.voltage.min 4.13855V v.b.p.voltage.stddev 0.00669V v.b.p.voltage.stddev.max 0.00717V v.b.power
And a bunch of push notifications every time I connect the App, like this:
Regards, Mark
On 17 Nov 2018, at 10:51 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
First implementation of general cell deviation checking and alerts is pushed.
Vehicle BMS: cell deviations & alerts
Renamed metrics: - v.b.c.level.* → v.b.p.level.* (for consistency)
New metrics: - v.b.c.(voltage,temp).(dev.max,alert) - v.b.p.(voltage,temp).(min,max,avg,stddev,stddev.max)
New configs: - vehicle [bms.dev.voltage.warn] -- threshold [V] - vehicle [bms.dev.voltage.alert] -- threshold [V] - vehicle [bms.dev.temp.warn] -- threshold [°C] - vehicle [bms.dev.temp.alert] -- threshold [°C] …all optional, default: warn at 120% stddev, alert at 200% stddev
New commands: - bms alerts → show cells with warn/alert levels
I changed the config scheme hoping a manual configuration normally isn't necessary with this automatic adaption to the standard deviation.
Please check and report if that idea works. If it doesn't, please report the deviations and necessary threshold levels on your batteries.
I also omitted the overall stddev alerts for now, I don't think those really are necessary, haven't had a single trigger on the Twizy for this.
Integration into the web chart page and historical data updates are still todo.
Migration for the Twizy battery monitor to the generalized scheme is in progress.
Regards, Michael
Am 17.11.18 um 11:53 schrieb Mark Webb-Johnson:
Short video showing Model S charging;
https://youtu.be/Q4vMPSwBFAo <https://youtu.be/Q4vMPSwBFAo>
On 17 Nov 2018, at 6:13 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
> Ok. Will do. > > Now you remind me, bms looks good on iPhone: > > <image1.jpeg> > > On 17 Nov 2018, at 6:08 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: > >> Yes, you can add a new menu to PageMenu_t like that. I suggest introducing a general tools menu instead of a specific one, i.e. "PageMenu_Tools". >> >> To still fit the menu on one line in tablet mode (width down to 768 px) I suggest moving the Shell into the tools menu then. >> >> Go ahead, I'm not working on the web framework at the moment. >> >> Regards, >> Michael >> >> >> Am 17.11.18 um 10:48 schrieb Mark Webb-Johnson: >>> Twizy code overrides the virtual short name function, so won’t suffer the issue. >>> >>> I think it is a bug in vehicle factory (as modifying the vehicle type is reasonable), so fixed it there. Returning NULL is problematic. It would be so much easier for everything to return std::string, but concern is memory consumption and overhead. >>> >>> I’d like to start converting RE TOOLS to just use the web server. First step is to work out how to add a menu onto the web server. It seems that the PageMenu_t is a fixed enum list (and similarly hard-coded in the web_framework. >>> >>> Do I just add a ‘CAN bus’ menu there, by adding it to PageMenu_t, and supporting it where the other top level menus are? Or do you have any other suggestions/plans for this? >>> >>> I don’t want to step on anything you are working on here. >>> >>> The second stage will be to add displays under that, but I think that is fairly straight forward. I will mostly be displaying tables, and sending those over the web socket would be good. >>> >>> Regards, Mark >>> >>>> On 17 Nov 2018, at 5:37 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>> >>>> Mark, >>>> >>>> nice, thanks. >>>> >>>> The short name is used for the menu label. It's meant to fall back to the long name (and seems to do so in your screenshot), so should not be null. But I admit I haven't tested it on a vehicle without a short name. >>>> >>>> Btw, I'm currently working on the deviations and alerts. >>>> >>>> Regards, >>>> Michael >>>> >>>> >>>> Am 17.11.18 um 10:08 schrieb Mark Webb-Johnson: >>>>> Michael, >>>>> >>>>> Looks good. It seems that you did everything necessary for the Model S already in your commit 2a84d861403f48142d6adcc16ad7a20cd458e427: >>>>> >>>>> #include “ovms_webserver.h" >>>>> >>>>> OvmsVehicleTeslaModelS::OvmsVehicleTeslaModelS() >>>>> MyWebServer.RegisterPage("/bms/cellmon", "BMS cell monitor", OvmsWebServer::HandleBmsCellMonitor, PageMenu_Vehicle, PageAuth_Cookie); >>>>> >>>>> OvmsVehicleTeslaModelS::~OvmsVehicleTeslaModelS() >>>>> MyWebServer.DeregisterPage("/bms/cellmon"); >>>>> >>>>> From my devbench, replaying a CAN CRTD log file, I get this output: >>>>> >>>>> <PastedGraphic-2.png> >>>>> >>>>> The animation is very nice. >>>>> >>>>> I am, however, getting crashes, as follows: >>>>> >>>>> # xtensa-esp32-elf-addr2line -pfiaC -e 3.1.011-25-g2a84d86.ovms3.elf 0x400935d3 0x4009372b 0x400db90c 0x4012c0f7 0x4012d0e1 0x4012d1e0 0x4012ebc1 0x4012ecbd 0x400f8b65 0x400f912d 0x400fa27c 0x400fa29a 0x400f8b65 0x400fa3e3 0x400fa7ad 0x400faa77 0x400f767e 0x400ee40a 0x400ee459 >>>>> 0x400935d3: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 >>>>> 0x4009372b: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 >>>>> 0x400db90c: __cxx_fatal_exception_message at /home/openvehicles/build/esp-idf/components/cxx/cxx_exception_stubs.cpp:19 >>>>> 0x4012c0f7: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:216 >>>>> (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, char const*, std::__false_type) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195 >>>>> (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214 >>>>> (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457 >>>>> 0x4012d0e1: OvmsWebServer::CreateMenu[abi:cxx11](PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:393 >>>>> 0x4012d1e0: OvmsWebServer::HandleRoot(PageEntry&, PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:510 >>>>> 0x4012ebc1: PageEntry::Serve(PageContext&) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 >>>>> 0x4012ecbd: OvmsWebServer::EventHandler(mg_connection*, int, void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 >>>>> 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>>> 0x400f912d: mg_http_call_endpoint_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>>> 0x400fa27c: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>>> 0x400fa29a: mg_http_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>>> 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>>> 0x400fa3e3: mg_recv_common at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>>> 0x400fa7ad: mg_if_recv_tcp_cb at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>>> (inlined by) mg_handle_tcp_read at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3723 >>>>> (inlined by) mg_mgr_handle_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3844 >>>>> 0x400faa77: mg_socket_if_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>>> 0x400f767e: mg_mgr_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>>> 0x400ee40a: OvmsNetManager::MongooseTask() at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:560 >>>>> 0x400ee459: MongooseRawTask(void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:545 >>>>> >>>>> On my development bench module I get this crash 1 in 4 times or so. On my real car, 100% of the time. >>>>> >>>>> That code path leads into MyVehicleFactory.ActiveVehicleShortName(). Those should all be ‘const char*’, but it is possible for NULL to be returned. I will look into it in more detail. >>>>> >>>>> Regards, Mark. >>>>> >>>>>> On 17 Nov 2018, at 7:35 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>> >>>>>> Mark, Tamás, >>>>>> >>>>>> I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI. >>>>>> >>>>>> Please see git log for details and send some screenshots. >>>>>> >>>>>> Regards, >>>>>> Michael >>>>>> >>>>>> >>>>>> Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson: >>>>>>> OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to use it, and support came down to just a few simple lines of code. >>>>>>> >>>>>>> For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational. >>>>>>> >>>>>>> c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with using std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way of doing that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of data ready to commit to metrics, so will need to think about this some more. >>>>>>> >>>>>>> I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall aggregates, etc). There is a very basic ‘bms status’ command implemented. >>>>>>> >>>>>>> Let me know what you think of it. >>>>>>> >>>>>>> Regards, Mark >>>>>>> >>>>>>>> On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>>> >>>>>>>> Mark, >>>>>>>> >>>>>>>> yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as… >>>>>>>> OvmsVehicle::ResetCellStats(); >>>>>>>> Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level? >>>>>>>> On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the vehicle / user. >>>>>>>> >>>>>>>> >>>>>>>> There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion bitset, i.e. >>>>>>>> OvmsVehicle::RestartCellVoltages(); >>>>>>>> OvmsVehicle::RestartCellTemperatures(); >>>>>>>> …as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation. >>>>>>>> >>>>>>>> >>>>>>>> Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these thresholds are currently fixed to… >>>>>>>> // Battery cell/cmod deviation alert thresholds: >>>>>>>> #define BATT_DEV_TEMP_ALERT 3 // = 3 °C >>>>>>>> #define BATT_DEV_VOLT_ALERT 6 // = 30 mV >>>>>>>> >>>>>>>> // ...thresholds for overall stddev: >>>>>>>> #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C >>>>>>>> #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C >>>>>>>> #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV >>>>>>>> #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV >>>>>>>> …these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. So these should be configurable, i.e. >>>>>>>> vehicle bms.dev.temp.alert [°C] >>>>>>>> vehicle bms.dev.voltage.alert [V] >>>>>>>> vehicle bms.stddev.temp.watch [°C] >>>>>>>> vehicle bms.stddev.temp.alert [°C] >>>>>>>> vehicle bms.stddev.voltage.watch [V] >>>>>>>> vehicle bms.stddev.voltage.alert [V] >>>>>>>> I can generalize the Twizy code for all of this. >>>>>>>> >>>>>>>> >>>>>>>> The Twizy battery monitoring command set is: >>>>>>>> OVMS# xrt batt ? >>>>>>>> data-cell Output cell record >>>>>>>> data-pack Output pack record >>>>>>>> reset Reset alerts & watches >>>>>>>> status Status report >>>>>>>> tdev Show temperature deviations >>>>>>>> temp Show temperatures >>>>>>>> vdev Show voltage deviations >>>>>>>> volt Show voltages >>>>>>>> The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the output within the SMS msg size limit. >>>>>>>> >>>>>>>> "status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and "tdev" show all cells. >>>>>>>> >>>>>>>> The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set. >>>>>>>> >>>>>>>> >>>>>>>> The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on the Twizy, sending a vector metric to the server is just a matter of… >>>>>>>> std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; >>>>>>>> msg.append(m_mon.m_mot_torque_drv->AsString()); >>>>>>>> MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str()); >>>>>>>> Neat. >>>>>>>> >>>>>>>> The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a lot of additional data volume on large packs. >>>>>>>> >>>>>>>> >>>>>>>> The Twizy layout may be either… >>>>>>>> 14 cell groups in the pack >>>>>>>> 2 cell groups in each module >>>>>>>> 7 modules in the pack >>>>>>>> Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) >>>>>>>> Each module has 1 temperature measurements (so, 7 individual temperature measurements) >>>>>>>> That means: >>>>>>>> OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) >>>>>>>> OvmsVehicle::SetCellArrangementTemperature(7, 1, 7) >>>>>>>> …for the original battery, or for an LFP type replacement… >>>>>>>> >>>>>>>> 16 cell groups in the pack >>>>>>>> 16 cell groups in each module >>>>>>>> 1 module in the pack >>>>>>>> Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) >>>>>>>> Each module has 3 temperature measurements (so, 3 individual temperature measurements) >>>>>>>> That means: >>>>>>>> OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) >>>>>>>> OvmsVehicle::SetCellArrangementTemperature(3, 3, 3) >>>>>>>> >>>>>>>> Regards, >>>>>>>> Michael >>>>>>>> >>>>>>>> >>>>>>>> Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson: >>>>>>>>> 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@webb-johnson.net <mailto:mark@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@spjeldager.dk <mailto:henrik.scheel@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/ <http://www.spjeldager.dk/> >>>>>>>>>>> >>>>>>>>>>>> Den 10. nov. 2018 kl. 15.34 skrev ovmsdev-request@lists.openvehicles.com <mailto:ovmsdev-request@lists.openvehicles.com>: >>>>>>>>>>>> >>>>>>>>>>>> Send OvmsDev mailing list submissions to >>>>>>>>>>>> ovmsdev@lists.openvehicles.com <mailto:ovmsdev@lists.openvehicles.com> >>>>>>>>>>>> >>>>>>>>>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>> or, via email, send a message with subject or body 'help' to >>>>>>>>>>>> ovmsdev-request@lists.openvehicles.com <mailto:ovmsdev-request@lists.openvehicles.com> >>>>>>>>>>>> >>>>>>>>>>>> You can reach the person managing the list at >>>>>>>>>>>> ovmsdev-owner@lists.openvehicles.com <mailto:ovmsdev-owner@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@webb-johnson.net> <mailto:mark@webb-johnson.net> >>>>>>>>>>>> To: OVMS Developers <ovmsdev@lists.openvehicles.com> <mailto:ovmsdev@lists.openvehicles.com> >>>>>>>>>>>> Subject: Re: [Ovmsdev] Custom metrics >>>>>>>>>>>> Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@webb-johnson.net> <mailto:1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@expeedo.de> <mailto:dexter@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 likehttps://api.openvehicles.com:8080/VEHICLEID <https://api.openvehicles.com:8080/VEHICLEID> <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> <https://github.com/russdill/lwip/commit/dfeba616>. Another is TUN/TAP, again with reference code for LWIP<https://github.com/russdill/lwip/commit/47ca42f8> <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@expeedo.de <mailto:dexter@expeedo.de> <mailto:dexter@expeedo.de> <mailto:dexter@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> <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@expeedo.de <mailto:dexter@expeedo.de> <mailto:dexter@expeedo.de> <mailto:dexter@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><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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev><http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev><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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev><http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>> >>>>>>>>>>>>
With time offsets that large you may also need to discard a series that is stretched too far in time… or more generally, that stretches over different load situations. But that would mean the data is useless while driving, and I can't imagine someone at Tesla doing nonsense like that, rendering real time data useless. Is it possible the readings are sent differentially (no change = no tx)? Then you should get a complete set only when flooring the pedal or starting/stopping a high power charge. Regards, Michael Am 18.11.18 um 02:43 schrieb Mark Webb-Johnson:
Unlike a standard indexed message (such as VIN, for example) where the messages come in #1, #2, #3, etc, these BMS messages come in seemingly at random. For example, here is a capture from cold wakeup:
1542472541.536441 1R11 6F2 0e ff ff ff ff ff ff ff 1542472541.636967 1R11 6F2 0f ff ff ff ff ff ff ff 1542472541.837607 1R11 6F2 11 ff ff ff ff ff ff ff 1542472542.136658 1R11 6F2 14 ff ff ff ff ff ff ff 1542472542.236201 1R11 6F2 15 ff ff ff ff ff ff ff 1542472542.537060 1R11 6F2 18 e7 c8 45 c2 8c 7c 23 1542472543.274424 1R11 6F2 1f f0 08 3a 92 8f f0 23 1542472543.472967 1R11 6F2 01 90 34 24 4d 49 53 d2 1542472543.973617 1R11 6F2 06 93 f4 24 4d 49 4f d2 1542472544.173053 1R11 6F2 08 91 b4 24 1d 49 43 d2 1542472544.671201 1R11 6F2 0d 97 b4 25 dd 48 3f d2 1542472545.173202 1R11 6F2 12 93 34 25 4d 49 4f d2 1542472545.685309 1R11 6F2 17 94 b4 24 2d 49 53 d2 1542472545.973614 1R11 6F2 1a 99 48 2e e2 89 c0 22 … 1542472606.575697 1R11 6F2 18 f0 08 48 42 8d a4 23 1542472607.075726 1R11 6F2 1d a7 48 2a d2 8a 90 22 1542472607.284635 1R11 6F2 1f f7 c8 3b 02 90 0c 24 1542472607.374752 1R11 6F2 00 8d f4 23 fd 48 3b d2 1542472608.078353 1R11 6F2 07 93 74 25 1d 49 3f d2 1542472608.373934 1R11 6F2 0a 92 34 24 2d 49 53 d2 1542472608.875669 1R11 6F2 0f 93 f4 24 4d 49 4f d2 1542472609.375819 1R11 6F2 14 96 b4 25 7d 49 57 d2 1542472609.875780 1R11 6F2 19 b0 c8 35 92 89 1c 23 1542472610.175548 1R11 6F2 1c d5 c8 33 72 89 9c 22 1542472610.375530 1R11 6F2 1e a4 48 2c c2 8c 00 23 1542472649.542261 1R11 6F2 1a 00 20 00 08 00 02 80 1542472649.648029 1R11 6F2 1b 00 20 00 08 00 02 80 1542472649.850761 1R11 6F2 1d 00 20 00 08 00 02 80 1542472650.141807 1R11 6F2 00 ff ff ff ff ff ff ff 1542472650.441905 1R11 6F2 03 ff ff ff ff ff ff ff 1542472650.642106 1R11 6F2 05 bd 33 4b cd 4c 1b cf 1542472651.178823 1R11 6F2 0a 92 74 24 3d 49 5b d2 1542472651.386026 1R11 6F2 0c 97 f4 25 7d 49 5f d2 1542472651.885083 1R11 6F2 11 96 b4 25 3d 49 57 d2 1542472652.178292 1R11 6F2 14 97 b4 25 6d 49 5b d2 1542472652.386909 1R11 6F2 16 95 b4 25 6d 49 4f d2 1542472652.678470 1R11 6F2 19 ab 88 34 42 89 08 23 1542472652.977144 1R11 6F2 1c cf 08 32 22 89 88 22
You can see the time difference between the first set of ‘ff ff ff’ and second set is quite large. 109 seconds.
Looking at just a couple of specific messages:
1542472545.973614 1R11 6F2 1a 99 48 2e e2 89 c0 22 1542472549.173160 1R11 6F2 1a 9a 88 2e f2 89 c4 22 1542472561.979447 1R11 6F2 1a 9c 08 2f 12 8a c8 22 1542472571.576261 1R11 6F2 1a 9b c8 2e 12 8a cc 22 1542472574.775537 1R11 6F2 1a 9c 08 2f 02 8a c8 22 1542472593.975024 1R11 6F2 1a 9c 48 2f 02 8a cc 22 1542472600.375601 1R11 6F2 1a 9c 08 2f 02 8a cc 22 1542472649.542261 1R11 6F2 1a 00 20 00 08 00 02 80
1542472542.136658 1R11 6F2 14 ff ff ff ff ff ff ff 1542472561.373928 1R11 6F2 14 97 f4 25 7d 49 5b d2 1542472564.573971 1R11 6F2 14 97 f4 25 8d 49 67 d2 1542472583.774481 1R11 6F2 14 94 b4 25 7d 49 5f d2 1542472586.973971 1R11 6F2 14 96 b4 25 7d 49 5f d2 1542472609.375819 1R11 6F2 14 96 b4 25 7d 49 57 d2 1542472652.178292 1R11 6F2 14 97 b4 25 6d 49 5b d2 1542472661.785441 1R11 6F2 14 96 b4 25 6d 49 5f d2
It seems that voltage temperature readings (such as 1a) go negative-maximum as the module goes to sleep, and voltage readings go maximum as the module wakes up.
But in some case, completely random:
1542472568.973842 1R11 6F2 00 8e f4 23 1d 49 3f d2 1542472604.182418 1R11 6F2 00 8e b4 23 fd 48 3b d2 1542472607.374752 1R11 6F2 00 8d f4 23 fd 48 3b d2 1542472650.141807 1R11 6F2 00 ff ff ff ff ff ff ff 1542472656.594506 1R11 6F2 00 8d f4 23 ed 48 3f d2 1542472666.183604 1R11 6F2 00 8e b4 23 ed 48 3b d2
Similarly for the spurious readings.
It seems that the individual BMS modules are reporting these values directly onto the bus, with no centralised control. But given the arrangement of 4x14bit readings per message, that doesn’t really make sense (particularly for voltage, with 6 readings per module).
It is quite simple to remove these out of range readings, and I could also simply discard all others in the same group. But, I suspect identifying the slightly out of range readings will be harder. I’ll try the group disable first, and see if that improves it…
Regards, Mark.
On 18 Nov 2018, at 1:38 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
filtering single readings or brick groups that way will not work, you need to discard the complete current series of readings and do a restart.
If you don't, the omitted cell will complete the series on the next run, leading to an inconsistent series.
That may be the source of those spurious big differences…?
Regards, Michael
Am 17.11.18 um 18:03 schrieb Mark Webb-Johnson:
There are some strange high and low values (-100C for temperatures, and +5V for voltages) - seemingly when the car wakes up or goes to sleep.
I have added some functions in vehicle.{h, cpp} to provide automatic sanity checking (based on limits provided by the vehicle).
On the Model S, that is now better, but still giving issues:
OVMS# bms alerts Voltage: SD=5mV !77:+16mV !78:-59mV !80:+19mV Temperature: SD=0.7C ?1:+0.6C ?2:+1.2C ?3:+0.3C !4:+0.5C ?6:+0.2C !7:-0.5C ?9:-0.5C ?11:-0.4C ?13:-0.8C ?14:-0.4C !15:-0.5C !19:-0.5C ?20:-0.3C ?21:-0.3C ?22:-0.3C ?23:-0.2C ?24:-0.4C ?25:-0.3C ?29:+0.7C ?30:+0.6C ?31:+0.8C ?32:+0.9C
I think the temperature variances are correct and normal. I see some big differences in voltage min/max on some cells that look like spurious readings. Not sure how to address that - it is going to be hard to discard these readings. For example, see attached.
Regards, Mark
<PastedGraphic-5.png>
On 17 Nov 2018, at 11:41 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Obviously not working for you. Cells that exceeded the alert threshold deviation from average get marked with "!", and "?" = warn threshold exceeded.
So at some point, many cells exceeded 200% stddev -- obviously not in the established overall situation. Is there maybe some init phase with unstable / incomplete readings that needs to be skipped on the Model S?
If so, a "bms reset" should clean the alerts up. Can you try that?
Regards, Michael
Am 17.11.18 um 16:01 schrieb Mark Webb-Johnson:
Not really sure how to interpret this. I get:
OVMS# bms alerts Voltage: SD=7mV !1:-7mV !2:-4mV !3:-4mV !4:-5mV !5:-5mV !6:-6mV !7:-1mV !8:+2mV !9:+0mV !10:+0mV !11:+0mV !12:-2mV ?13:+0mV !14:+4mV !15:+2mV !16:+2mV !17:+0mV !18:+0mV !19:-3mV !20:+0mV !21:-1mV ?22:+0mV !23:-2mV !24:-2mV !26:+2mV !27:+1mV !28:+2mV ?29:+0mV !30:+0mV !31:-2mV ?33:+0mV !35:-1mV !36:-2mV ?37:-5mV !38:-3mV !39:-2mV !40:-2mV !41:-4mV !42:-6mV !43:-3mV !44:+0mV !45:-1mV !46:-1mV !47:-1mV !48:-1mV !49:+6mV !50:+7mV !51:+6mV !52:+8mV !53:+7mV !54:+6mV !55:+1mV !56:+4mV !57:+1mV !58:+4mV !59:+0mV !60:+0mV !61:+3mV !62:+5mV !63:+4mV !64:+4mV !65:+2mV !66:+3mV !67:-1mV !68:+2mV !69:+1mV !70:+1mV !71:-1mV !72:-1mV !74:+2mV !76:+1mV ?77:+0mV !78:-1mV !79:+1mV !80:+3mV !81:+1mV !82:+2mV !83:+2mV !84:+1mV !85:-3mV !86:+2mV !87:-1mV !88:-1mV !89:-3mV !90:-2mV !91:-2mV !92:-1mV !93:-2mV !94:-2mV !95:-3mV !96:-4mV Temperature: SD=0.6C ?1:+0.5C ?2:+1.0C ?3:+0.3C ?4:+0.3C ?5:-0.2C ?7:-0.3C ?9:-0.2C !10:-0.2C ?12:-0.4C ?13:-0.3C ?14:-0.4C ?15:-0.5C ?16:-0.3C ?17:+0.8C !18:-0.3C ?19:-0.1C ?20:-0.3C ?21:-0.1C !22:-0.4C !24:-0.5C ?25:-0.3C ?26:-0.4C ?28:-0.3C ?29:+0.7C ?30:+0.3C ?31:+0.9C ?32:+0.5C
OVMS# metrics list v.b.c v.b.c.temp 28.8652,29.4386,28.6334,28.6822,28.1942,28.5114,28.1454,28.4626,28.182,28.3406,28.3894,28.121,28.1088,28.1454,28.0112,28.182,28.9262,28.243,28.2674,28.2186,28.2918,28.0844,28.3528,28.0356,28.1454,28.1088,28.4626,28.2186,28.975,28.7554,29.0604,28.9384°C v.b.c.temp.alert 1,2,1,1,1,1,1,0,1,2,0,1,1,1,1,1,2,2,1,1,1,1,1,1,1,1,0,1,2,1,1,2 v.b.c.temp.dev.max 0.52,1.03,0.31,0.26,-0.23,0.1,-0.29,-0.07,-0.25,-0.18,0.04,-0.44,-0.31,-0.39,-0.46,-0.34,0.76,-0.27,-0.15,-0.3,-0.13,-0.45,-0.08,-0.49,-0.28,-0.41,0.09,-0.28,0.73,0.34,0.92,0.52°C v.b.c.temp.max 28.8774,29.4386,28.6578,28.6822,28.1942,28.5236,28.1454,28.4626,28.182,28.3406,28.3894,28.121,28.1088,28.1454,28.0112,28.182,29.1092,28.243,28.2674,28.2186,28.2918,28.0844,28.3528,28.0356,28.1576,28.1088,28.4626,28.2186,29.0848,28.7554,29.2678,28.9384°C v.b.c.temp.min 28.853,29.3654,28.6212,28.5724,28.1332,28.3894,28.1088,28.2796,28.1332,28.1698,28.3894,27.9136,28.0966,27.9624,27.9014,28.0112,28.9262,28.0844,28.2674,28.0478,28.2796,27.9014,28.3406,27.8648,28.121,27.938,28.426,28.0722,28.975,28.609,29.0604,28.8042°C v.b.c.voltage 4.13794,4.14099,4.14099,4.14099,4.14007,4.13915,4.14465,4.1477,4.14586,4.14556,4.14465,4.14373,4.14556,4.14922,4.14739,4.14709,4.14586,4.14586,4.14251,4.14556,4.14434,4.14495,4.14373,4.14342,4.14586,4.148,4.14586,4.14709,4.14526,4.14526,4.14342,4.14556,4.14526,4.14556,4.14434,4.14342,4.14038,4.14251,4.14282,4.14312,4.14099,4.13946,4.14251,4.14586,4.14434,4.14465,4.14465,4.14434,4.15197,4.15318,4.15166,4.1541,4.15318,4.15166,4.14709,4.14922,4.14709,4.14861,4.14617,4.14586,4.148,4.15074,4.14983,4.15044,4.1477,4.148,4.14465,4.148,4.14678,4.14647,4.14403,4.14403,4.14556,4.148,4.14586,4.14647,4.14465,4.14526,4.14617,4.148,4.14617,4.14647,4.14739,4.14678,4.14251,4.14709,4.14373,4.14434,4.14282,4.14373,4.14312,4.14465,4.14282,4.14312,4.14282,4.1419V v.b.c.voltage.alert 2,1,1,1,1,1,2,1,2,2,2,2,1,1,1,2,2,2,1,2,2,1,1,1,0,1,2,2,1,2,1,0,1,0,2,2,1,1,1,1,1,1,1,2,2,2,2,2,1,2,1,2,2,1,2,1,2,1,2,2,1,1,1,1,1,1,2,1,2,2,2,2,0,1,0,2,1,2,2,1,2,2,2,2,1,2,2,2,1,1,1,2,1,1,1,1 v.b.c.voltage.dev.max -0.0082,-0.00487,-0.00498,-0.00508,-0.00583,-0.00674,-0.00139,0.00257,0.00096,0.00086,-0.00096,-0.00221,-0.00061,0.004,0.00275,0.00217,0.00096,0.00077,-0.0034,0.00081,-0.0017,-0.00091,-0.00234,-0.00304,0.00068,0.00288,0.00124,0.0022,-0.00052,-0.00078,-0.0024,0.00095,-0.00103,-0.00061,-0.00179,-0.00224,-0.00546,-0.00335,-0.0032,-0.00271,-0.00506,-0.00644,-0.0036,0.00087,-0.00129,-0.00168,-0.00139,-0.00132,0.00648,0.00824,0.00648,0.00883,0.0081,0.00641,0.00161,0.00443,0.00222,0.00401,0.00096,0.00095,0.00342,0.00597,0.00469,0.00505,0.00318,0.00315,-0.00127,0.00291,0.00132,0.00197,-0.0024,-0.00168,-0.00072,0.00275,0.00069,0.00184,-0.00096,-0.0012,0.00125,0.0032,0.00166,0.00203,0.00291,0.00153,-0.00355,0.00214,-0.00225,-0.00171,-0.003,-0.00249,-0.00292,-0.00152,-0.00295,-0.00296,-0.00311,-0.00432V v.b.c.voltage.max 4.13794,4.14129,4.14099,4.14099,4.14007,4.13915,4.14465,4.1477,4.14586,4.14586,4.14556,4.14403,4.14556,4.14922,4.1477,4.14709,4.14586,4.14586,4.14251,4.14586,4.14434,4.14495,4.14373,4.14342,4.14586,4.148,4.14617,4.14709,4.14556,4.14526,4.14342,4.14586,4.14526,4.14556,4.14434,4.14373,4.14099,4.14282,4.14282,4.14312,4.14099,4.13946,4.14282,4.14617,4.14465,4.14465,4.14465,4.14434,4.15197,4.15349,4.15197,4.1541,4.15318,4.15166,4.14709,4.14922,4.14709,4.14861,4.14617,4.14647,4.14861,4.15105,4.15014,4.15044,4.1483,4.1483,4.14465,4.148,4.14678,4.14709,4.14403,4.14403,4.14556,4.148,4.14586,4.14709,4.14526,4.14526,4.14647,4.148,4.14709,4.14739,4.1483,4.14678,4.14282,4.14709,4.14403,4.14434,4.14312,4.14373,4.14312,4.14465,4.14312,4.14312,4.14312,4.1419V v.b.c.voltage.min 4.13123,4.13427,4.13397,4.13397,4.13336,4.13214,4.13732,4.14038,4.13915,4.13885,4.13794,4.13641,4.13824,4.14159,4.14068,4.14007,4.13855,4.13824,4.1355,4.13885,4.13702,4.13794,4.13611,4.1358,4.13855,4.14099,4.13915,4.14007,4.13794,4.13794,4.13641,4.13855,4.13794,4.13824,4.13702,4.13641,4.13367,4.1358,4.1355,4.1358,4.13397,4.13275,4.13488,4.13855,4.13702,4.13702,4.13702,4.13732,4.14342,4.14586,4.14403,4.14617,4.14526,4.14403,4.13824,4.14159,4.13946,4.14038,4.13824,4.13824,4.14099,4.14342,4.14251,4.14251,4.14068,4.14038,4.13732,4.14099,4.13946,4.13976,4.13671,4.13671,4.13794,4.14038,4.13824,4.13946,4.13763,4.13763,4.13885,4.14038,4.13915,4.13946,4.14068,4.13885,4.1355,4.14007,4.13671,4.13732,4.13611,4.13641,4.13641,4.13732,4.13611,4.13641,4.13611,4.13458V v.b.cac v.b.consumption 0Wh/km v.b.coulomb.recd v.b.coulomb.used v.b.current
OVMS# metrics list v.b.p v.b.p.level.avg v.b.p.level.max v.b.p.level.min v.b.p.level.stddev v.b.p.temp.avg 28.43°C v.b.p.temp.max 29.4508°C v.b.p.temp.min 28.0234°C v.b.p.temp.stddev 0.36°C v.b.p.temp.stddev.max 0.65°C v.b.p.voltage.avg 4.14669V v.b.p.voltage.max 4.15532V v.b.p.voltage.min 4.13855V v.b.p.voltage.stddev 0.00669V v.b.p.voltage.stddev.max 0.00717V v.b.power
And a bunch of push notifications every time I connect the App, like this:
Regards, Mark
On 17 Nov 2018, at 10:51 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
First implementation of general cell deviation checking and alerts is pushed.
Vehicle BMS: cell deviations & alerts Renamed metrics: - v.b.c.level.* → v.b.p.level.* (for consistency) New metrics: - v.b.c.(voltage,temp).(dev.max,alert) - v.b.p.(voltage,temp).(min,max,avg,stddev,stddev.max) New configs: - vehicle [bms.dev.voltage.warn] -- threshold [V] - vehicle [bms.dev.voltage.alert] -- threshold [V] - vehicle [bms.dev.temp.warn] -- threshold [°C] - vehicle [bms.dev.temp.alert] -- threshold [°C] …all optional, default: warn at 120% stddev, alert at 200% stddev New commands: - bms alerts → show cells with warn/alert levels
I changed the config scheme hoping a manual configuration normally isn't necessary with this automatic adaption to the standard deviation.
Please check and report if that idea works. If it doesn't, please report the deviations and necessary threshold levels on your batteries.
I also omitted the overall stddev alerts for now, I don't think those really are necessary, haven't had a single trigger on the Twizy for this.
Integration into the web chart page and historical data updates are still todo.
Migration for the Twizy battery monitor to the generalized scheme is in progress.
Regards, Michael
Am 17.11.18 um 11:53 schrieb Mark Webb-Johnson: > Short video showing Model S charging; > > https://youtu.be/Q4vMPSwBFAo > > On 17 Nov 2018, at 6:13 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote: > >> Ok. Will do. >> >> Now you remind me, bms looks good on iPhone: >> >> <image1.jpeg> >> >> On 17 Nov 2018, at 6:08 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >> >>> Yes, you can add a new menu to PageMenu_t like that. I suggest introducing a general tools menu instead of a specific one, i.e. "PageMenu_Tools". >>> >>> To still fit the menu on one line in tablet mode (width down to 768 px) I suggest moving the Shell into the tools menu then. >>> >>> Go ahead, I'm not working on the web framework at the moment. >>> >>> Regards, >>> Michael >>> >>> >>> Am 17.11.18 um 10:48 schrieb Mark Webb-Johnson: >>>> Twizy code overrides the virtual short name function, so won’t suffer the issue. >>>> >>>> I think it is a bug in vehicle factory (as modifying the vehicle type is reasonable), so fixed it there. Returning NULL is problematic. It would be >>>> so much easier for everything to return std::string, but concern is memory consumption and overhead. >>>> >>>> I’d like to start converting RE TOOLS to just use the web server. First step is to work out how to add a menu onto the web server. It seems that >>>> the PageMenu_t is a fixed enum list (and similarly hard-coded in the web_framework. >>>> >>>> Do I just add a ‘CAN bus’ menu there, by adding it to PageMenu_t, and supporting it where the other top level menus are? Or do you have any other >>>> suggestions/plans for this? >>>> >>>> I don’t want to step on anything you are working on here. >>>> >>>> >>>> The second stage will be to add displays under that, but I think that is fairly straight forward. I will mostly be displaying tables, and sending >>>> those over the web socket would be good. >>>> >>>> Regards, Mark >>>> >>>>> On 17 Nov 2018, at 5:37 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>> >>>>> Mark, >>>>> >>>>> nice, thanks. >>>>> >>>>> The short name is used for the menu label. It's meant to fall back to the long name (and seems to do so in your screenshot), so should not be null. >>>>> But I admit I haven't tested it on a vehicle without a short name. >>>>> >>>>> Btw, I'm currently working on the deviations and alerts. >>>>> >>>>> Regards, >>>>> Michael >>>>> >>>>> >>>>> Am 17.11.18 um 10:08 schrieb Mark Webb-Johnson: >>>>>> Michael, >>>>>> >>>>>> Looks good. It seems that you did everything necessary for the Model S already in your commit 2a84d861403f48142d6adcc16ad7a20cd458e427: >>>>>> >>>>>> #include “ovms_webserver.h" >>>>>> >>>>>> OvmsVehicleTeslaModelS::OvmsVehicleTeslaModelS() >>>>>> MyWebServer.RegisterPage("/bms/cellmon", "BMS cell monitor", OvmsWebServer::HandleBmsCellMonitor, PageMenu_Vehicle, PageAuth_Cookie); >>>>>> >>>>>> OvmsVehicleTeslaModelS::~OvmsVehicleTeslaModelS() >>>>>> MyWebServer.DeregisterPage("/bms/cellmon"); >>>>>> >>>>>> >>>>>> From my devbench, replaying a CAN CRTD log file, I get this output: >>>>>> >>>>>> <PastedGraphic-2.png> >>>>>> >>>>>> The animation is very nice. >>>>>> >>>>>> I am, however, getting crashes, as follows: >>>>>> >>>>>> # xtensa-esp32-elf-addr2line -pfiaC -e 3.1.011-25-g2a84d86.ovms3.elf 0x400935d3 0x4009372b 0x400db90c 0x4012c0f7 0x4012d0e1 0x4012d1e0 >>>>>> 0x4012ebc1 0x4012ecbd 0x400f8b65 0x400f912d 0x400fa27c 0x400fa29a 0x400f8b65 0x400fa3e3 0x400fa7ad 0x400faa77 0x400f767e 0x400ee40a 0x400ee459 >>>>>> 0x400935d3: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 >>>>>> 0x4009372b: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 >>>>>> 0x400db90c: __cxx_fatal_exception_message at /home/openvehicles/build/esp-idf/components/cxx/cxx_exception_stubs.cpp:19 >>>>>> 0x4012c0f7: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char >>>>>> const*, std::forward_iterator_tag) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:216 >>>>>> (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, >>>>>> char const*, std::__false_type) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195 >>>>>> (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char >>>>>> const*) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214 >>>>>> (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> >>>>>> const&) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457 >>>>>> 0x4012d0e1: OvmsWebServer::CreateMenu[abi:cxx11](PageContext&) at >>>>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:393 >>>>>> 0x4012d1e0: OvmsWebServer::HandleRoot(PageEntry&, PageContext&) at >>>>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:510 >>>>>> 0x4012ebc1: PageEntry::Serve(PageContext&) at >>>>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 >>>>>> 0x4012ecbd: OvmsWebServer::EventHandler(mg_connection*, int, void*) at >>>>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 >>>>>> 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>>>> 0x400f912d: mg_http_call_endpoint_handler at >>>>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>>>> 0x400fa27c: mg_http_handler2 at >>>>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>>>> 0x400fa29a: mg_http_handler at >>>>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>>>> 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>>>> 0x400fa3e3: mg_recv_common at >>>>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>>>> 0x400fa7ad: mg_if_recv_tcp_cb at >>>>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>>>> (inlined by) mg_handle_tcp_read at >>>>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3723 >>>>>> (inlined by) mg_mgr_handle_conn at >>>>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3844 >>>>>> 0x400faa77: mg_socket_if_poll at >>>>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>>>> 0x400f767e: mg_mgr_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 >>>>>> 0x400ee40a: OvmsNetManager::MongooseTask() at >>>>>> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:560 >>>>>> 0x400ee459: MongooseRawTask(void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:545 >>>>>> >>>>>> >>>>>> On my development bench module I get this crash 1 in 4 times or so. On my real car, 100% of the time. >>>>>> >>>>>> That code path leads into MyVehicleFactory.ActiveVehicleShortName(). Those should all be ‘const char*’, but it is possible for NULL to be returned. >>>>>> I will look into it in more detail. >>>>>> >>>>>> Regards, Mark. >>>>>> >>>>>>> On 17 Nov 2018, at 7:35 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>> >>>>>>> Mark, Tamás, >>>>>>> >>>>>>> I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI. >>>>>>> >>>>>>> Please see git log for details and send some screenshots. >>>>>>> >>>>>>> Regards, >>>>>>> Michael >>>>>>> >>>>>>> >>>>>>> Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson: >>>>>>>> OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code >>>>>>>> to use it, and support came down to just a few simple lines of code. >>>>>>>> >>>>>>>> For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational. >>>>>>>> >>>>>>>> c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with >>>>>>>> using std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better >>>>>>>> way of doing that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set >>>>>>>> of data ready to commit to metrics, so will need to think about this some more. >>>>>>>> >>>>>>>> I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall >>>>>>>> aggregates, etc). There is a very basic ‘bms status’ command implemented. >>>>>>>> >>>>>>>> Let me know what you think of it. >>>>>>>> >>>>>>>> Regards, Mark >>>>>>>> >>>>>>>>> On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>>>> >>>>>>>>> Mark, >>>>>>>>> >>>>>>>>> yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as… >>>>>>>>> >>>>>>>>> * OvmsVehicle::ResetCellStats(); >>>>>>>>> * Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level? >>>>>>>>> >>>>>>>>> On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by >>>>>>>>> the vehicle / user. >>>>>>>>> >>>>>>>>> >>>>>>>>> There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be >>>>>>>>> calculated by the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings >>>>>>>>> completion bitset, i.e. >>>>>>>>> >>>>>>>>> * OvmsVehicle::RestartCellVoltages(); >>>>>>>>> * OvmsVehicle::RestartCellTemperatures(); >>>>>>>>> >>>>>>>>> …as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation. >>>>>>>>> >>>>>>>>> >>>>>>>>> Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation >>>>>>>>> thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for >>>>>>>>> normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these >>>>>>>>> thresholds are currently fixed to… >>>>>>>>> >>>>>>>>> // Battery cell/cmod deviation alert thresholds: >>>>>>>>> #define BATT_DEV_TEMP_ALERT 3 // = 3 °C >>>>>>>>> #define BATT_DEV_VOLT_ALERT 6 // = 30 mV >>>>>>>>> >>>>>>>>> // ...thresholds for overall stddev: >>>>>>>>> #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C >>>>>>>>> #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C >>>>>>>>> #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV >>>>>>>>> #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV >>>>>>>>> >>>>>>>>> …these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type >>>>>>>>> cells. So these should be configurable, i.e. >>>>>>>>> >>>>>>>>> * vehicle bms.dev.temp.alert [°C] >>>>>>>>> * vehicle bms.dev.voltage.alert [V] >>>>>>>>> * vehicle bms.stddev.temp.watch [°C] >>>>>>>>> * vehicle bms.stddev.temp.alert [°C] >>>>>>>>> * vehicle bms.stddev.voltage.watch [V] >>>>>>>>> * vehicle bms.stddev.voltage.alert [V] >>>>>>>>> >>>>>>>>> I can generalize the Twizy code for all of this. >>>>>>>>> >>>>>>>>> >>>>>>>>> The Twizy battery monitoring command set is: >>>>>>>>> >>>>>>>>> OVMS# xrt batt ? >>>>>>>>> data-cell Output cell record >>>>>>>>> data-pack Output pack record >>>>>>>>> reset Reset alerts & watches >>>>>>>>> status Status report >>>>>>>>> tdev Show temperature deviations >>>>>>>>> temp Show temperatures >>>>>>>>> vdev Show voltage deviations >>>>>>>>> volt Show voltages >>>>>>>>> >>>>>>>>> The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the >>>>>>>>> output within the SMS msg size limit. >>>>>>>>> >>>>>>>>> "status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and >>>>>>>>> "tdev" show all cells. >>>>>>>>> >>>>>>>>> The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set. >>>>>>>>> >>>>>>>>> >>>>>>>>> The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer >>>>>>>>> on the Twizy, sending a vector metric to the server is just a matter of… >>>>>>>>> >>>>>>>>> std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; >>>>>>>>> msg.append(m_mon.m_mot_torque_drv->AsString()); >>>>>>>>> MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str()); >>>>>>>>> >>>>>>>>> Neat. >>>>>>>>> >>>>>>>>> The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be >>>>>>>>> a lot of additional data volume on large packs. >>>>>>>>> >>>>>>>>> >>>>>>>>> The Twizy layout may be either… >>>>>>>>> >>>>>>>>> * 14 cell groups in the pack >>>>>>>>> * 2 cell groups in each module >>>>>>>>> * 7 modules in the pack >>>>>>>>> * Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) >>>>>>>>> * Each module has 1 temperature measurements (so, 7 individual temperature measurements) >>>>>>>>> * That means: >>>>>>>>> o OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) >>>>>>>>> o OvmsVehicle::SetCellArrangementTemperature(7, 1, 7) >>>>>>>>> >>>>>>>>> …for the original battery, or for an LFP type replacement… >>>>>>>>> >>>>>>>>> * 16 cell groups in the pack >>>>>>>>> * 16 cell groups in each module >>>>>>>>> * 1 module in the pack >>>>>>>>> * Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) >>>>>>>>> * Each module has 3 temperature measurements (so, 3 individual temperature measurements) >>>>>>>>> * That means: >>>>>>>>> o OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) >>>>>>>>> o OvmsVehicle::SetCellArrangementTemperature(3, 3, 3) >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Michael >>>>>>>>> >>>>>>>>> >>>>>>>>> Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson: >>>>>>>>>> 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: >>>>>>>>>> o OvmsVehicle::SetCellArrangementVoltage(96, 6, 3) >>>>>>>>>> o 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: >>>>>>>>>> o OvmsVehicle::SetCellArrangementVoltage(99, 9, 9) >>>>>>>>>> o 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: >>>>>>>>>> o OvmsVehicle::SetCellArrangementVoltage(N, Y, Z) >>>>>>>>>> o 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@webb-johnson.net <mailto:mark@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@spjeldager.dk <mailto:henrik.scheel@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@lists.openvehicles.com: >>>>>>>>>>>>> >>>>>>>>>>>>> Send OvmsDev mailing list submissions to >>>>>>>>>>>>> ovmsdev@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@lists.openvehicles.com >>>>>>>>>>>>> >>>>>>>>>>>>> You can reach the person managing the list at >>>>>>>>>>>>> ovmsdev-owner@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@webb-johnson.net> >>>>>>>>>>>>> To: OVMS Developers <ovmsdev@lists.openvehicles.com> >>>>>>>>>>>>> Subject: Re: [Ovmsdev] Custom metrics >>>>>>>>>>>>> Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com >>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>>>>>>>>>>>> >>>>>>>>>>>>>
I just pushed an update fixing some minor issues and adding deviations, alerts and a configuration dialog to the web UI. As usual, you can hover/click the series names in the legend to focus/disable. I also replaced the attempt to determine warn/alert by a stddev factor by simple thresholds. Especially on a small sensor set with limited resolution, even few outsiders can change the std dev drastically. Default thresholds are: // BMS default deviation thresholds: #define BMS_DEFTHR_VWARN 0.020 // [V] #define BMS_DEFTHR_VALERT 0.030 // [V] #define BMS_DEFTHR_TWARN 2.00 // [°C] #define BMS_DEFTHR_TALERT 3.00 // [°C] API to install vehicle specific default thresholds: BmsSetCellDefaultThresholdsVoltage(warn, alert); BmsSetCellDefaultThresholdsTemperature(warn, alert); The defaults can be overridden by the user. Regards, Michael Am 17.11.18 um 15:51 schrieb Michael Balzer:
First implementation of general cell deviation checking and alerts is pushed.
Vehicle BMS: cell deviations & alerts Renamed metrics: - v.b.c.level.* → v.b.p.level.* (for consistency) New metrics: - v.b.c.(voltage,temp).(dev.max,alert) - v.b.p.(voltage,temp).(min,max,avg,stddev,stddev.max) New configs: - vehicle [bms.dev.voltage.warn] -- threshold [V] - vehicle [bms.dev.voltage.alert] -- threshold [V] - vehicle [bms.dev.temp.warn] -- threshold [°C] - vehicle [bms.dev.temp.alert] -- threshold [°C] …all optional, default: warn at 120% stddev, alert at 200% stddev New commands: - bms alerts → show cells with warn/alert levels
I changed the config scheme hoping a manual configuration normally isn't necessary with this automatic adaption to the standard deviation.
Please check and report if that idea works. If it doesn't, please report the deviations and necessary threshold levels on your batteries.
I also omitted the overall stddev alerts for now, I don't think those really are necessary, haven't had a single trigger on the Twizy for this.
Integration into the web chart page and historical data updates are still todo.
Migration for the Twizy battery monitor to the generalized scheme is in progress.
Regards, Michael
Am 17.11.18 um 11:53 schrieb Mark Webb-Johnson:
Short video showing Model S charging;
On 17 Nov 2018, at 6:13 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
Ok. Will do.
Now you remind me, bms looks good on iPhone:
<image1.jpeg>
On 17 Nov 2018, at 6:08 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Yes, you can add a new menu to PageMenu_t like that. I suggest introducing a general tools menu instead of a specific one, i.e. "PageMenu_Tools".
To still fit the menu on one line in tablet mode (width down to 768 px) I suggest moving the Shell into the tools menu then.
Go ahead, I'm not working on the web framework at the moment.
Regards, Michael
Am 17.11.18 um 10:48 schrieb Mark Webb-Johnson:
Twizy code overrides the virtual short name function, so won’t suffer the issue.
I think it is a bug in vehicle factory (as modifying the vehicle type is reasonable), so fixed it there. Returning NULL is problematic. It would be so much easier for everything to return std::string, but concern is memory consumption and overhead.
I’d like to start converting RE TOOLS to just use the web server. First step is to work out how to add a menu onto the web server. It seems that the PageMenu_t is a fixed enum list (and similarly hard-coded in the web_framework.
Do I just add a ‘CAN bus’ menu there, by adding it to PageMenu_t, and supporting it where the other top level menus are? Or do you have any other suggestions/plans for this?
I don’t want to step on anything you are working on here.
The second stage will be to add displays under that, but I think that is fairly straight forward. I will mostly be displaying tables, and sending those over the web socket would be good.
Regards, Mark
On 17 Nov 2018, at 5:37 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
nice, thanks.
The short name is used for the menu label. It's meant to fall back to the long name (and seems to do so in your screenshot), so should not be null. But I admit I haven't tested it on a vehicle without a short name.
Btw, I'm currently working on the deviations and alerts.
Regards, Michael
Am 17.11.18 um 10:08 schrieb Mark Webb-Johnson: > Michael, > > Looks good. It seems that you did everything necessary for the Model S already in your commit 2a84d861403f48142d6adcc16ad7a20cd458e427: > > #include “ovms_webserver.h" > > OvmsVehicleTeslaModelS::OvmsVehicleTeslaModelS() > MyWebServer.RegisterPage("/bms/cellmon", "BMS cell monitor", OvmsWebServer::HandleBmsCellMonitor, PageMenu_Vehicle, PageAuth_Cookie); > > OvmsVehicleTeslaModelS::~OvmsVehicleTeslaModelS() > MyWebServer.DeregisterPage("/bms/cellmon"); > > > From my devbench, replaying a CAN CRTD log file, I get this output: > > <PastedGraphic-2.png> > > The animation is very nice. > > I am, however, getting crashes, as follows: > > # xtensa-esp32-elf-addr2line -pfiaC -e 3.1.011-25-g2a84d86.ovms3.elf 0x400935d3 0x4009372b 0x400db90c 0x4012c0f7 0x4012d0e1 0x4012d1e0 0x4012ebc1 > 0x4012ecbd 0x400f8b65 0x400f912d 0x400fa27c 0x400fa29a 0x400f8b65 0x400fa3e3 0x400fa7ad 0x400faa77 0x400f767e 0x400ee40a 0x400ee459 > 0x400935d3: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 > 0x4009372b: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:670 > 0x400db90c: __cxx_fatal_exception_message at /home/openvehicles/build/esp-idf/components/cxx/cxx_exception_stubs.cpp:19 > 0x4012c0f7: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char > const*, std::forward_iterator_tag) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:216 > (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, char > const*, std::__false_type) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195 > (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char > const*) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214 > (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> > const&) at /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457 > 0x4012d0e1: OvmsWebServer::CreateMenu[abi:cxx11](PageContext&) at > /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:393 > 0x4012d1e0: OvmsWebServer::HandleRoot(PageEntry&, PageContext&) at > /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:510 > 0x4012ebc1: PageEntry::Serve(PageContext&) at > /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 > 0x4012ecbd: OvmsWebServer::EventHandler(mg_connection*, int, void*) at > /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558 > 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 > 0x400f912d: mg_http_call_endpoint_handler at > /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 > 0x400fa27c: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 > 0x400fa29a: mg_http_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 > 0x400f8b65: mg_call at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 > 0x400fa3e3: mg_recv_common at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 > 0x400fa7ad: mg_if_recv_tcp_cb at > /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 > (inlined by) mg_handle_tcp_read at > /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3723 > (inlined by) mg_mgr_handle_conn at > /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3844 > 0x400faa77: mg_socket_if_poll at > /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 > 0x400f767e: mg_mgr_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 > 0x400ee40a: OvmsNetManager::MongooseTask() at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:560 > 0x400ee459: MongooseRawTask(void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:545 > > > On my development bench module I get this crash 1 in 4 times or so. On my real car, 100% of the time. > > That code path leads into MyVehicleFactory.ActiveVehicleShortName(). Those should all be ‘const char*’, but it is possible for NULL to be returned. I > will look into it in more detail. > > Regards, Mark. > >> On 17 Nov 2018, at 7:35 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >> >> Mark, Tamás, >> >> I haven't had the time yet to take care of the stddev port, but I've just added the generalized web UI. >> >> Please see git log for details and send some screenshots. >> >> Regards, >> Michael >> >> >> Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson: >>> OK. I spent some time on this today, and sent in a first draft (as a bunch of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to >>> use it, and support came down to just a few simple lines of code. >>> >>> For the moment, I dropped the idea of ‘readingsperrow’, as I think that is Tesla Model S specific, and not really necessary. Purely presentational. >>> >>> c++ std::bitset is fixed size, so that doesn’t work for us. The std::vector<bool> seems a workable alternative, but I am not really happy with using >>> std::find as a way of looking to see if we have everything. It works as it is, but is not very optimal. It seems there should be a better way of doing >>> that. I think it is a pretty key feature, given the broadcast nature of the buses, to help the vehicle module know when it has a set of data ready to >>> commit to metrics, so will need to think about this some more. >>> >>> I also implemented min and max, for voltages and temperatures. They went in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall >>> aggregates, etc). There is a very basic ‘bms status’ command implemented. >>> >>> Let me know what you think of it. >>> >>> Regards, Mark >>> >>>> On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>> >>>> Mark, >>>> >>>> yes, .min & .max are the minimum and maximum readings seen since last battery monitor reset. The reset should be available as… >>>> >>>> * OvmsVehicle::ResetCellStats(); >>>> * Command: "vehicle bms reset" …or just "bms reset" as we also have other vehicle commands on the root level? >>>> >>>> On the Twizy I do an auto reset each time the vehicle is turned on and each time a charge starts, but that behaviour should be controllable by the >>>> vehicle / user. >>>> >>>> >>>> There's additionally the overall { .stddev, .avg } on voltages and temperatures of the pack. These and the cell level statistics can be calculated by >>>> the framework, so the vehicle simply needs to provide the readings. The framework needs to provide a way to reset the readings completion bitset, i.e. >>>> >>>> * OvmsVehicle::RestartCellVoltages(); >>>> * OvmsVehicle::RestartCellTemperatures(); >>>> >>>> …as sometimes readings get lost, and adding new to the previous readings may lead to an inconsistent view leading to wrong standard deviation. >>>> >>>> >>>> Speaking of standard deviation, the framework should also provide warnings and alerts flags. On the Twizy it does so by checking deviation >>>> thresholds, and there's a general stddev warn & alert threshold to detect overall condition and two alert thresholds on the cell level, one for >>>> normal stddev and one for stddev alert mode. Warning flags on the cell level are set when the cell deviation is above stddev. On the Twizy these >>>> thresholds are currently fixed to… >>>> >>>> // Battery cell/cmod deviation alert thresholds: >>>> #define BATT_DEV_TEMP_ALERT 3 // = 3 °C >>>> #define BATT_DEV_VOLT_ALERT 6 // = 30 mV >>>> >>>> // ...thresholds for overall stddev: >>>> #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C >>>> #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C >>>> #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV >>>> #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV >>>> >>>> …these are good defaults for the Twizy 43 Ah pouch cells, but may be too low for an 18650 pack, and will especially not fit cheap LFP type cells. So >>>> these should be configurable, i.e. >>>> >>>> * vehicle bms.dev.temp.alert [°C] >>>> * vehicle bms.dev.voltage.alert [V] >>>> * vehicle bms.stddev.temp.watch [°C] >>>> * vehicle bms.stddev.temp.alert [°C] >>>> * vehicle bms.stddev.voltage.watch [V] >>>> * vehicle bms.stddev.voltage.alert [V] >>>> >>>> I can generalize the Twizy code for all of this. >>>> >>>> >>>> The Twizy battery monitoring command set is: >>>> >>>> OVMS# xrt batt ? >>>> data-cell Output cell record >>>> data-pack Output pack record >>>> reset Reset alerts & watches >>>> status Status report >>>> tdev Show temperature deviations >>>> temp Show temperatures >>>> vdev Show voltage deviations >>>> volt Show voltages >>>> >>>> The "data" commands provide the server historical records output. The other commands originate from the V2 and have been designed to keep the output >>>> within the SMS msg size limit. >>>> >>>> "status" gives an operative overview of the standard and max deviation levels of cells with warning or alert status. "volt", "vdev", "temp" and >>>> "tdev" show all cells. >>>> >>>> The Twizy generates a battery alert notification from the "status" output whenever some cell alert flag is set. >>>> >>>> >>>> The Twizy server records also originate from the V2 limits, and can now better be changed to vectors. I've just finished a virtual dynamometer on the >>>> Twizy, sending a vector metric to the server is just a matter of… >>>> >>>> std::string msg = "RT-ENG-MotTrqDrv,0,86400,"; >>>> msg.append(m_mon.m_mot_torque_drv->AsString()); >>>> MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str()); >>>> >>>> Neat. >>>> >>>> The Twizy sends server records once per minute during drive/charge. The server update frequency should become tunable as well, as that would be a lot >>>> of additional data volume on large packs. >>>> >>>> >>>> The Twizy layout may be either… >>>> >>>> * 14 cell groups in the pack >>>> * 2 cell groups in each module >>>> * 7 modules in the pack >>>> * Each cell group has 1 voltage measurement (so, 14 individual voltage measurements) >>>> * Each module has 1 temperature measurements (so, 7 individual temperature measurements) >>>> * That means: >>>> o OvmsVehicle::SetCellArrangementVoltage(14, 2, 7) >>>> o OvmsVehicle::SetCellArrangementTemperature(7, 1, 7) >>>> >>>> …for the original battery, or for an LFP type replacement… >>>> >>>> * 16 cell groups in the pack >>>> * 16 cell groups in each module >>>> * 1 module in the pack >>>> * Each cell group has 1 voltage measurement (so, 16 individual voltage measurements) >>>> * Each module has 3 temperature measurements (so, 3 individual temperature measurements) >>>> * That means: >>>> o OvmsVehicle::SetCellArrangementVoltage(16, 16, 8) >>>> o OvmsVehicle::SetCellArrangementTemperature(3, 3, 3) >>>> >>>> >>>> Regards, >>>> Michael >>>> >>>> >>>> Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson: >>>>> 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: >>>>> o OvmsVehicle::SetCellArrangementVoltage(96, 6, 3) >>>>> o 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: >>>>> o OvmsVehicle::SetCellArrangementVoltage(99, 9, 9) >>>>> o 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: >>>>> o OvmsVehicle::SetCellArrangementVoltage(N, Y, Z) >>>>> o 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@webb-johnson.net <mailto:mark@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@spjeldager.dk <mailto:henrik.scheel@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@lists.openvehicles.com: >>>>>>>> >>>>>>>> Send OvmsDev mailing list submissions to >>>>>>>> ovmsdev@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@lists.openvehicles.com >>>>>>>> >>>>>>>> You can reach the person managing the list at >>>>>>>> ovmsdev-owner@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@webb-johnson.net> >>>>>>>> To: OVMS Developers <ovmsdev@lists.openvehicles.com> >>>>>>>> Subject: Re: [Ovmsdev] Custom metrics >>>>>>>> Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OvmsDev mailing list >>>>>>>>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com >>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>>>>>>> >>>>>>>>
I have used this to add support for the Leaf. Very cool! I also added a new way to process incoming poll replies: void OvmsVehicle::IncomingPollComplete(canbus* bus, uint16_t moduleid, uint16_t type, uint16_t pid, uint8_t* data, uint8_t length) Instead of implementing IncomingPollReply() and handling each frame as it arrives, vehicles can instead implement IncomingPollComplete(), which gets called once after all the frames are concatenated into data[length]. Robin.
Robin, I am looking at your IncomingPollComplete, pull request, but it seems very confusing to me. The current design is that OvmsVehicle::PollerReceive calls IncomingPollReply() in several places, to pass the result up to the vehicle code for decoding. It pretty much just passes the data part of the frame (after decoding the first part containing PID, result code, etc). Now, you have IncomingPollComplete(). You have changed OvmsVehicleIncomingPollReply from pure virtual to now have code? You have a ’static uint8_t *buf’ defined in your new IncomingPollReply, but I can’t see where that get freed. Also there only seems to be one, so what happens when multiple ‘ml’ style polls are defined? I’m really not sure if this should be a static - perhaps a vehicle object member variable would make more sense (Iike the other m_poll member variables, as this IncomingPollComplete is concerning m_poll_ml)? I am really not sure what is required/solved here? The vehicle.{h,cpp} change is mixed in with changes to the nissan leaf vehicle code, in the same commits, which makes things harder to see. In future, could you make one commit to the base code, and one to the vehicle module - if they are related/dependent, they can be in the same pull request, but mixing everything together with commits changing commits, makes it hard to see what is going on (or the impact that the changes to base code could have on other vehicle modules). Regards, Mark.
On 22 Nov 2018, at 11:32 PM, Robin O'Leary <ovmsdev@caederus.org> wrote:
I have used this to add support for the Leaf. Very cool!
I also added a new way to process incoming poll replies:
void OvmsVehicle::IncomingPollComplete(canbus* bus, uint16_t moduleid, uint16_t type, uint16_t pid, uint8_t* data, uint8_t length)
Instead of implementing IncomingPollReply() and handling each frame as it arrives, vehicles can instead implement IncomingPollComplete(), which gets called once after all the frames are concatenated into data[length].
Robin. _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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@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@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@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@lists.openvehicles.com:
Send OvmsDev mailing list submissions to ovmsdev@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@lists.openvehicles.com
You can reach the person managing the list at ovmsdev-owner@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@webb-johnson.net> To: OVMS Developers <ovmsdev@lists.openvehicles.com> Subject: Re: [Ovmsdev] Custom metrics Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11@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@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@expeedo.de <mailto: dexter@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@expeedo.de <mailto: dexter@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev < http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev < http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (5)
-
Henrik Scheel -
Mark Webb-Johnson -
Michael Balzer -
Robin O'Leary -
Tamás Kovács