[Ovmsdev] Gas vs. battery metric?
mark at webb-johnson.net
Mon Jun 15 10:27:52 HKT 2020
I think the core principle of the “Open” in “Open Vehicle Monitoring System” is that we should not restrict any uses, no matter our personal opinions.
Regarding the metrics themselves, I agree with Michael. The v.b namespace is intended for vehicle battery metrics. Perhaps we can simply add another namespace “v.ice” for internal combustion engine fuels?
Note that OBDII defines standard fuel type codings (service 01 PID 51):
0 Not available
5 LPG <https://en.wikipedia.org/wiki/Liquefied_petroleum_gas>
6 CNG <https://en.wikipedia.org/wiki/Compressed_natural_gas>
9 Bifuel <https://en.wikipedia.org/wiki/Bi-fuel_vehicle> running Gasoline
10 Bifuel running Methanol
11 Bifuel running Ethanol
12 Bifuel running LPG
13 Bifuel running CNG
14 Bifuel running Propane
15 Bifuel running Electricity
16 Bifuel running electric and combustion engine
17 Hybrid gasoline
18 Hybrid Ethanol
19 Hybrid Diesel
20 Hybrid Electric
21 Hybrid running electric and combustion engine
22 Hybrid Regenerative
23 Bifuel running diesel
A ‘v.fueltype’ metric makes sense for this. Perhaps just use the full OBDII list (which supports hybrids). For ICE vehicles, keeping to standard OBDII PIDs is probably the simplest and most standardised approach. So, “v.ice.tank.level”, or something like that (OBDII PID 0x2f).
Regarding the Apps support for this (and other things), that is something I am working on and trying to prototype. I will eMail separately regarding this.
> On 15 Jun 2020, at 2:46 AM, Michael Balzer <dexter at expeedo.de> wrote:
> I strictly vote against re-interpretation of the SOC metric. Where metrics have clear semantics we should not make them dependent on some context.
> A battery is not a fuel tank, and vehicles may have both. "v.b." is the namespace "vehicle battery" and shall not be populated with non-battery metrics.
> That's what I meant by adding technology specific metrics: if the vehicle has a fuel tank, additional standard metrics describing that fuel tank shall be present.
> Fuel tank specific metrics might e.g. get the namespace "v.ft.", ICE engine specific metrics might get "v.ice.", fuel cell metrics "v.fc.", rocket thruster metrics "v.rt." … you get the idea.
> Make a proposition for the metrics sets you need. Try to define them as generalized as possible.
> That will probably include duplicates of some metrics, like the ranges & consumption. That's necessary to be able to describe a hybrid, and some units among those will also need to be different (e.g. consumption in litres / m³ per km).
> Am 14.06.20 um 18:59 schrieb Chris van der Meijden:
>> Thank you for considering my thoughts.
>> I believe it is a good idea to use a v.tech variable and not using gas or gazoline. That gives OVMS enough flexibility and is also a (little) statement.
>> I'm also looking forward to rocket propulsion add ons :-))
>> Am Sonntag, den 14.06.2020, 08:21 -0700 schrieb Craig Leres:
>>> On 2020-06-13 08:31, Michael Balzer wrote:
>>>> How about adding an array or set metric like "v.ext" or "v.tech", for
>>>> defined technology codes. A tag present in the metric means the
>>>> additional metrics, commands & configs for that technology are available.
>>> My goal is to make it possible for the app to depict soc with something
>>> other than a battery graphic when the energy source is not a battery.
>>> How about v.tech with "battery" and "other" as the initial two possible
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OvmsDev