[Ovmsdev] Custom metrics

Thu Nov 8 06:49:53 HKT 2018

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:
>
>  1. 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)?
>
>  2. 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).
>
>  3. 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.
>
>  4. 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 tunnelled through (with authentication at the
>     server level using the normal web server user account). Similarly for SSH access. These are both simple tcp/ip connections, so presumably could be
>     injected into mongoose as fake connections. One possible approach would be SOCKS, and there is some reference code for LWIP
>     <https://github.com/russdill/lwip/commit/dfeba616>. Another is TUN/TAP, again with reference code for LWIP
>     <https://github.com/russdill/lwip/commit/47ca42f8>. And then there is the standard PPP (although that would technically then be PPP within tcp/ip over PPP
>     within async within GSM, which is a bit freaky).
>
>
> Regards, Mark.
>
>> On 7 Nov 2018, at 4:52 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>
>> Mark, Tamás,
>>
>> I've prepared a more or less generalized array version of my Twizy battery chart (OvmsVehicleRenaultTwizy::WebBattMon) for you. Easier to collect the data
>> from actual arrays than separate metrics.
>>
>> This ZIP…
>>
>> https://dexters-web.de/f/ovms-dev/ovms.zip
>>
>> …contains my local ovms web test/development folder. Unzip it into some local web server (needs to be run via http for javascript), then open the folder from
>> a browser. You should see an OVMS web UI lookalike.
>>
>> Config → CellChart loads "cellchart.htm". The blue button generates and injects test data. Should look like this:
>>
>> <eoibkbnkbpofdlab.png>
>>
>> Assuming you'll add some min/max records as well I left that code including the reset button in there. If you can't provide that yet, you can simply set min
>> & max = act in the get_xxx_data functions. Other than that you should basically just need to change the metrics names.
>>
>> To generate C/C++ syntax from the file, use the script bin/mksrc: "bin/mksrc cellchart.htm >cellchart.cpp". The chart init URL needs to be changed for the
>> production environment (see comment), and the test data generator can be removed. See OvmsVehicleRenaultTwizy::WebBattMon for reference.
>>
>> Maybe I should add that stuff to the repository as well…
>>
>> Regards,
>> Michael
>>
>>
>> Am 06.11.18 um 15:56 schrieb Mark Webb-Johnson:
>>> Nice. I just implemented this for Model S using your new metric type.
>>>
>>> 96 individual brick voltages for each of the bricks, plus two temperatures for each of the 16 modules.
>>>
>>> Works well.
>>>
>>>
>>>
>>>
>>> On 1 Nov 2018, at 5:58 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>>
>>>> Tamás,
>>>>
>>>> I've been creating separate metrics for all cell values on the Twizy, but that only has 14 cells.
>>>>
>>>> We discussed this before, a better approach is introducing a new metric class for arrays. I have just done that for you, please pull.
>>>>
>>>> Usage example:
>>>>
>>>>     OvmsMetricVector<float>* vf = new OvmsMetricVector<float>("test.volts", SM_STALE_MIN, Volts);
>>>>     vf->SetElemValue(3, 1.23);
>>>>     vf->SetElemValue(17, 2.34);
>>>>     float myvals[3] = { 5.5, 6.6, 7.7 };
>>>>     vf->SetElemValues(10, 3, myvals);
>>>>
>>>> With this data set, you get:
>>>>
>>>>     OVMS# met lis test
>>>>     test.volts                               0,0,0,1.23,0,0,0,0,0,0,5.5,6.6,7.7,0,0,0,0,2.34V
>>>>
>>>> …and in the web framework:
>>>>
>>>>     metrics["test.volts"]
>>>>     (18) [0, 0, 0, 1.23, 0, 0, 0, 0, 0, 0, 5.5, 6.6, 7.7, 0, 0, 0, 0, 2.34]
>>>>     metrics["test.volts"][11]
>>>>     6.6
>>>>
>>>> See template definition in ovms_metrics.h for more.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>> Am 31.10.18 um 20:08 schrieb Tamás Kovács:
>>>>> I have a Peugeot iOn, and i wan't to create own metrics for battery temp (66 piece) and voltage (88 (old) or 80(new) piece) for all cell (and show on web
>>>>> interface), and i don't understand how can i create it. Now my data in array-s from can messages 6E1-6E4.
>>>>> My git fork: https://github.com/KommyKT/Open-Vehicle-Monitoring-System-3/tree/peugeot
>>>>> vehicle_mitsubishi
>>>>>
>>>>
>>>> -- 
>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20181107/f0d14a0b/attachment.htm>