I'd like to add a boolean metric for gas vehicles as a prelude to the phone apps having this info. Would this be ok? #define MS_V_MOT_GAS "v.m.gas" ms_v_mot_gas = new OvmsMetricBool(MS_V_MOT_GAS); The default to false. The other way would be via OvmsMetricInt and an enum (or defines): typedef enum : uint8_t { Battery = 0, Gasoline = 1, } metric_vehicle_t; #define MS_V_MOT_TYPE "v.m.type" ms_v_mot_type = new OvmsMetricInt(MS_V_MOT_TYPE); which would allow for more than two types. Craig
Hi Craig, I think this question could be thin ice :-) We could start a highly political and emotional discussion on this. Question is, do we want to support fossil fuel burning technology, or do we want to make the statement, that the burning stuff aera is over and if you want to use cool technology like OVMS, then come into the future and buy an electric vehicle? Now I'm definitly aware that there will be various different points of view on this topic and that it is a hot topic. It is easy to drift into arguing about how political or not OVMS should or could be and political discussions in a large community mostly leed to emotional discussions. I would like to go the way Robert Llewellyn (Youtube channel Fullycharged) went, when he started to disagree with Johnny Smith on wether to test hybrids on the channel or not. Robert decided not to do so, because that would be the wrong signal to the viewers. But that decission went to the point that Johnny left the show. So, as I said, these discussions can be thin ice :-) I'm interested to see where we will be going on this. Greetinx Chris Am Freitag, den 12.06.2020, 16:09 -0700 schrieb Craig Leres:
I'd like to add a boolean metric for gas vehicles as a prelude to the phone apps having this info. Would this be ok?
#define MS_V_MOT_GAS "v.m.gas"
ms_v_mot_gas = new OvmsMetricBool(MS_V_MOT_GAS);
The default to false. The other way would be via OvmsMetricInt and an enum (or defines):
typedef enum : uint8_t { Battery = 0, Gasoline = 1, } metric_vehicle_t;
#define MS_V_MOT_TYPE "v.m.type"
ms_v_mot_type = new OvmsMetricInt(MS_V_MOT_TYPE);
which would allow for more than two types.
Craig _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
My 2 cents: We shouldn't generally exclude alternative propulsion technologies. Battery based electric propulsion will cover the majority of future transportation and mobility, but it won't fit every use case and every kind of vehicle. We should keep the core support to be for (battery) electric propulsion, and add support for alternative technologies on a strict add-on base. If for example a vehicle has a hydrogen based range extender, that should be signaled by the vehicle adapter, and the system should only then add the set of standard metrics for this particular technology. A metric "v.m.gas" would be confusing (what kind of gas? what kind of energy conversion?), would favorize a specific technology by it's name, and would not be sufficient to describe arbitrary combinations of technologies (e.g. a BEV with rocket thrusters…). 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. Regards, Michael 13.06.20 um 07:57 schrieb Chris van der Meijden:
Hi Craig,
I think this question could be thin ice :-)
We could start a highly political and emotional discussion on this. Question is, do we want to support fossil fuel burning technology, or do we want to make the statement, that the burning stuff aera is over and if you want to use cool technology like OVMS, then come into the future and buy an electric vehicle?
Now I'm definitly aware that there will be various different points of view on this topic and that it is a hot topic. It is easy to drift into arguing about how political or not OVMS should or could be and political discussions in a large community mostly leed to emotional discussions.
I would like to go the way Robert Llewellyn (Youtube channel Fullycharged) went, when he started to disagree with Johnny Smith on wether to test hybrids on the channel or not. Robert decided not to do so, because that would be the wrong signal to the viewers. But that decission went to the point that Johnny left the show. So, as I said, these discussions can be thin ice :-)
I'm interested to see where we will be going on this.
Greetinx
Chris
Am Freitag, den 12.06.2020, 16:09 -0700 schrieb Craig Leres:
I'd like to add a boolean metric for gas vehicles as a prelude to the phone apps having this info. Would this be ok?
#define MS_V_MOT_GAS "v.m.gas"
ms_v_mot_gas = new OvmsMetricBool(MS_V_MOT_GAS);
The default to false. The other way would be via OvmsMetricInt and an enum (or defines):
typedef enum : uint8_t { Battery = 0, Gasoline = 1, } metric_vehicle_t;
#define MS_V_MOT_TYPE "v.m.type"
ms_v_mot_type = new OvmsMetricInt(MS_V_MOT_TYPE);
which would allow for more than two types.
Craig _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
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
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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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@lists.openvehicles.com <mailto:OvmsDev@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
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): Value Description 0 Not available 1 Gasoline 2 Methanol 3 Ethanol 4 Diesel 5 LPG <https://en.wikipedia.org/wiki/Liquefied_petroleum_gas> 6 CNG <https://en.wikipedia.org/wiki/Compressed_natural_gas> 7 Propane 8 Electric 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. Regards, Mark.
On 15 Jun 2020, at 2:46 AM, Michael Balzer <dexter@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@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
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@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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@arachnon.de> 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):
Value Description 0 Not available 1 Gasoline 2 Methanol 3 Ethanol 4 Diesel 5 LPG <https://en.wikipedia.org/wiki/Liquefied_petroleum_gas> 6 CNG <https://en.wikipedia.org/wiki/Compressed_natural_gas> 7 Propane 8 Electric 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.
Regards, Mark.
On 15 Jun 2020, at 2:46 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@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 <http://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 <http://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 <http://v.tech/> with "battery" and "other" as the initial two possible values?
Craig _______________________________________________ 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
_______________________________________________ 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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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@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@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Hey, I appreciate the wisdom in Mark’s approach and his and others’ work on this project and, in this matter, his opinion. No solution is ever used just for what it was intended. Even if he wanted to, the project could easily be forked and massed produced in countries with few IP laws. It’s already “out there”. Secondly, purists and absolutists rarely serve projects’s benefit very long as their growing impatience with the world’s imperfections tend to kill their motivation sooner rather than later. Indeed, if perfect environmental requirements were necessary, then no one in NL, for example, would be allowed to drive at all, EV or ICE, as well over 90% of NL’s energy production isn’t from renewables. Life is more complex than what we can easily see. I own an Ampera and am glad for the functionality that has been developed in OVMS and hope to be able to contribute some day soon. The car is a utilitarian compromise from its day in 2013, and it gets me through the year with 90% of my travel on battery. It’s not perfect, but it’s much better than nothing, and that is where most of us (and the world) need to start. The old saying is “Perfection is the enemy of progress” (or as Voltaire phrased it, “the best is the enemy of the good”), fits rather aptly here. Cheers, Shaun (via the iPad thingamajigg)
On 15 Jun 2020, at 10:39, Chris van der Meijden <chris@arachnon.de> wrote:
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@arachnon.de> 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):
Value Description 0 Not available 1 Gasoline 2 Methanol 3 Ethanol 4 Diesel 5 LPG 6 CNG 7 Propane 8 Electric 9 Bifuel 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.
Regards, Mark.
On 15 Jun 2020, at 2:46 AM, Michael Balzer <dexter@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@lists.openvehicles.com > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (5)
-
Chris van der Meijden -
Craig Leres -
Mark Webb-Johnson -
Michael Balzer -
Shaun Jurrens