[Ovmsdev] Gas vs. battery metric?

[Chris van der Meijden]

Sorry, I disagree.
I think "Open" stands for open source and open source should also mean
being open to discussions. And discussions involve personal opinions.
IMHO supporting internal combustion engines in OVMS is a bad idea in
times of climate change. It is the wrong signal if we do so. 
I do not  want to "over discuss" this, but it is important enough for
me suggest not to implement support for ICE engines.
Greetinx
Chris

Am Montag, den 15.06.2020, 10:27 +0800 schrieb Mark Webb-Johnson:
> 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):
> 
> ValueDescription0Not
> available1Gasoline2Methanol3Ethanol4Diesel5LPG6CNG7Propane8Electric9B
> ifuel running Gasoline10Bifuel running Methanol11Bifuel running
> Ethanol12Bifuel running LPG13Bifuel running CNG14Bifuel running
> Propane15Bifuel running Electricity16Bifuel running electric and
> combustion engine17Hybrid gasoline18Hybrid Ethanol19Hybrid
> Diesel20Hybrid Electric21Hybrid running electric and combustion
> engine22Hybrid Regenerative23Bifuel 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.
> 
> Regards, Mark.
> 
> > On 15 Jun 2020, at 2:46 AM, Michael Balzer <dexter at expeedo.de>
> > wrote:
> > 
> > 
> >   
> >     
> >   
> >   
> >     Craig,
> > 
> >     
> > 
> >     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).
> > 
> >     
> > 
> >     Regards,
> > 
> >     Michael
> > 
> >     
> > 
> >     
> > 
> >     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 :-))
> > >       
> > > 
> > >       
> > >       Greetinx
> > >       
> > > 
> > >       
> > >       Chris
> > >       
> > > 
> > >       
> > >       
> > > 
> > >       
> > >       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
> > > > values?
> > > > 
> > > > 		Craig
> > > > _______________________________________________
> > > > OvmsDev mailing list
> > > > OvmsDev at lists.openvehicles.com
> > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > 
> > > >       
> > > 
> > >     
> > 
> >     
> > 
> >     
> >   
> > 
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200615/7026aa77/attachment.htm>