[Ovmsdev] Gas vs. battery metric?
Chris van der Meijden
chris at arachnon.de
Mon Jun 15 16:38:18 HKT 2020
Hey Mark
I think it is a difference telling someone what to do or actively
enabling what someone can do. If you enable something for someone you
are ethicaly responsible for that something.
All in all, we are all on the same side of the river. Driving EV's
brought a deeper understanding for the climate issues to me and I'm
sure to most of us. Good to read that you are active in a charity in
HK. Working together for a cleaner future. Just like the development of
OVMS :-)
Regards
Chris
Am Montag, den 15.06.2020, 15:56 +0800 schrieb Mark Webb-Johnson:
> Hmmm...
> It is hard to decouple ‘open’ from ‘free’, particularly given the
> roots of the open source movement. But at it’s core is the concept of
> openness and freedom in that I (or we) should not be telling anyone
> what they can or cannot do with this project. The user is free to do
> with it what they will, and our license explicitly states that.
>
> So, given that we cannot control what is done with the project, or
> what type of vehicle it is used in, the decision is whether we allow
> the ‘v.b’ battery namespace to be ’trampled on’ with ICE metrics? I
> think that the suggested v.ice namespace is a reasonable compromise.
>
> Regards, Mark.
>
> P.S. My personal opinion is that I drive electric cars, prefer them,
> and advocate for them every day. I even co-founded a charity here in
> HK to support and promote them.
>
> > On 15 Jun 2020, at 3:13 PM, Chris van der Meijden <chris at arachnon.d
> > e> wrote:
> >
> > 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
> > > available1Gasoline2Methanol3Ethanol4Diesel5LPG6CNG7Propane8Electr
> > > ic9Bifuel 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
> > _______________________________________________
> > 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/2ae9f262/attachment-0001.html>
More information about the OvmsDev
mailing list