January 2021 - OvmsDev - Open Vehicles

Happy discovered: I3 seems to manage 12v battery charge by itself
by Steve Davies 24 Jan '21

24 Jan '21

Hi, Do other vehicle types also do this? My car was locked and parked since yesterday about 10:30 UTC. Not connected to the EVSE/charger. I was monitoring and I noticed that by itself it turned on the dc/dc and started a 12v battery charge The battery was 12.6V at the time and it charged it for an hour and then went back to sleep. Battery was bumped up to 13.2V. 2021-01-16T09:25:21+0000 ovms/CAA5060/event vehicle.awake 2021-01-16T09:25:24+0000 ovms/CAA5060/event vehicle.locked 2021-01-16T09:25:24+0000 ovms/CAA5060/event vehicle.charge.state 2021-01-16T09:25:24+0000 ovms/CAA5060/event vehicle.charge.12v.start ... 2021-01-16T09:26:42+0000 ovms/CAA5060/metric/v/b/12v/current -9.52 2021-01-16T09:26:42+0000 ovms/CAA5060/metric/v/b/12v/voltage 14.72 2021-01-16T09:26:42+0000 ovms/CAA5060/metric/v/e/charging12v yes ... 2021-01-16T09:40:20+0000 ovms/CAA5060/notify/alert/vehicle.idle Vehicle is idling / stopped turned on 2021-01-16T09:40:20+0000 ovms/CAA5060/event notify.alert.vehicle.idle ... 2021-01-16T10:25:33+0000 ovms/CAA5060/event vehicle.charge.12v.stop ... Chart in localtime (+0200): [image: image.png] I did wonder if this would trigger the car warning "Battery discharging while stopped" but it did not. So if the car manages the 12v battery I will adjust the warning in my docs about discharging the 12v battery by leaving the OVMS connected. Steve

6 14

Two trivial PRs - round v.b.consumption down to 0 when tiny; make v.b.voltage SM_STALE_HIGH
by Steve Davies 24 Jan '21

24 Jan '21

Hi, Michael please see PRs #515 and #516 two trivial tweaks that came out of the I3 work. Steve

3 9

Extended metrics persistence
by Michael Balzer 18 Jan '21

18 Jan '21

Everyone, I've managed to extend the persistent metrics storage structure to support 100 instead of the former 30 metrics with even a slight reduction in memory usage: OVMS# metrics persist version 3, serial 2, 820 bytes, and 77 of 100 slots used This is achieved by replacing the metric names as 24 byte keys by their 4 byte hash keys. There's a potential disadvantage from this to be noted: hash collisions may occur. I've tested a full persistent metrics set including the new TPMS arrays, no collisions with the current hash function. If a collision occurs, the metric won't get added to the persistent set (or will be removed, see below), and an error log message is generated. If you add new persistences for standard or custom metrics, check the log. A special case are vector metrics. These are implemented by allocating one slot to the vector size using the metric's base name, and one slot for each element using the base name extended by the index. If the vector grows, it will try to allocate new persistent slots as needed. If that fails, persistence is dropped for the whole vector. So if you add a new persistent vector, be sure to check for element hash collisions by setting it manually to a full expected element set at least once. You can do so easily by the "metrics set" command. If we run into hash collisions, there are some options, e.g. using another hash function. Extending the storage structure to support chained chunks of values is another option. Persistence is currently limited to values fitting into 4 bytes. OvmsMetricFloat, Int and Bool work, and vectors fitting that element size. String, Set, BitSet are todo. I've added persistence to a number of state and counter metrics formerly lacking persistence. The new set of persistent metrics is: OVMS# metrics list -p v.b.12v.voltage.ref 12.6V v.b.cac 160Ah v.b.coulomb.recd v.b.coulomb.recd.total v.b.coulomb.used v.b.coulomb.used.total v.b.energy.recd v.b.energy.recd.total v.b.energy.used v.b.energy.used.total v.b.range.est 160km v.b.range.ideal 200km v.b.soc 50% v.b.soh 100% v.b.temp 25°C v.c.12v.temp v.c.charging v.c.climit v.c.kwh v.c.kwh.grid v.c.kwh.grid.total v.c.limit.range v.c.limit.soc v.c.temp 22°C v.c.time 0Sec v.c.timermode v.c.timerstart v.d.cp v.e.aux12v v.e.awake v.e.cabintemp v.e.charging12v v.e.drivemode v.e.drivetime 0Sec v.e.locked v.e.on v.e.parktime 275Sec v.e.temp 22°C v.e.valet v.g.climit v.g.generating v.g.kwh v.g.kwh.grid v.g.kwh.grid.total v.g.limit.range v.g.limit.soc v.g.temp v.g.time v.g.timermode v.g.timerstart v.i.temp 22°C v.m.temp 30°C v.p.altitude 329.3m v.p.latitude 51.3024 v.p.longitude 7.38979 v.p.odometer 100000km v.p.trip v.t.alert 0,0,0,1 v.t.health 95,93,96,74% v.t.pressure 206.843,216.483,275.79,175.79kPa v.t.temp 33,33,34,38°C If you still miss something here, let me know. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 3

Hi from a new comer
by didier＠ernotte.com 18 Jan '21

18 Jan '21

Hi, I am new here, just received my OVMS device, and started to play with it.I have a couple of questions : 1) Is there anyone around that has started the integration with the Jaguar IPace ? or any JLR products ? 2) I can see that there is multiple CAN bus on the plug (can1, can2, can3). Does the car use the 3 of them, only one, or a mix and we have to listen to all of them ?3) Is there a detailed step-by-step process to start investigating the data on the bus ? I just plug the cable and expected to see "something" in the RE console, in "discover" mode, out of the box, without results. No a good start... :-( Didier

2 7

Generator / V2G metrics proposal
by Michael Balzer 18 Jan '21

18 Jan '21

Everyone, I'm planning to add a general (optional) charge / grid integration log and a general (optional) trip log. I'll describe my log record proposal in a separate mail. For the grid log, I'm going to add V2G / generator mode metrics now, so we can support this and define an already fully featured log format. As this is more or less a reverse charge, and can be combined with charging, my proposal is to a) basically duplicate the set of charge metrics with only slight changes for the "generating" view, and b) add grid side energy counters. We currently have these charge metrics: OvmsMetricFloat* ms_v_charge_voltage; // Momentary charger supply voltage [V] OvmsMetricFloat* ms_v_charge_power; // Momentary charger input power [kW] OvmsMetricFloat* ms_v_charge_efficiency; // Momentary charger efficiency [%] OvmsMetricFloat* ms_v_charge_current; // Momentary charger output current (→battery) [A] OvmsMetricFloat* ms_v_charge_climit; // Maximum charger output current [A] OvmsMetricInt* ms_v_charge_time; // Duration of running charge [sec] OvmsMetricFloat* ms_v_charge_kwh; // Energy charged into the battery in the running session [kWh] OvmsMetricString* ms_v_charge_mode; // standard, range, performance, storage OvmsMetricBool* ms_v_charge_timermode; // True if timer enabled OvmsMetricInt* ms_v_charge_timerstart; // Time timer is due to start OvmsMetricString* ms_v_charge_state; // charging, topoff, done, prepare, timerwait, heating, stopped OvmsMetricString* ms_v_charge_substate; // scheduledstop, scheduledstart, onrequest, timerwait, powerwait, stopped, interrupted OvmsMetricString* ms_v_charge_type; // Connection type: undefined, type1, type2, chademo, roadster, teslaus, supercharger, ccs OvmsMetricBool* ms_v_charge_pilot; // Pilot signal present OvmsMetricBool* ms_v_charge_inprogress; // True = currently charging OvmsMetricFloat* ms_v_charge_limit_range; // Sufficient range limit for current charge [km] OvmsMetricFloat* ms_v_charge_limit_soc; // Sufficient SOC limit for current charge [%] OvmsMetricInt* ms_v_charge_duration_full; // Estimated time remaining for full charge [min] OvmsMetricInt* ms_v_charge_duration_range; // … for sufficient range [min] OvmsMetricInt* ms_v_charge_duration_soc; // … for sufficient SOC [min] OvmsMetricFloat* ms_v_charge_temp; // Charger temperature [°C] …metrics (not in same order): v.c.charging v.c.climit v.c.current v.c.duration.full v.c.duration.range v.c.duration.soc v.c.efficiency v.c.kwh v.c.limit.range v.c.limit.soc v.c.mode v.c.pilot v.c.power v.c.state v.c.substate v.c.temp v.c.time v.c.timermode v.c.timerstart v.c.type v.c.voltage I would add now the following metrics for the generator mode: OvmsMetricFloat* ms_v_gen_voltage; // Momentary generator output voltage [V] OvmsMetricFloat* ms_v_gen_power; // Momentary generator output power [kW] OvmsMetricFloat* ms_v_gen_efficiency; // Momentary generator efficiency [%] OvmsMetricFloat* ms_v_gen_current; // Momentary generator input current (←battery) [A] OvmsMetricFloat* ms_v_gen_climit; // Maximum generator input current [A] OvmsMetricInt* ms_v_gen_time; // Duration of generator running [sec] OvmsMetricFloat* ms_v_gen_kwh; // Energy sum generated in the running session [kWh] OvmsMetricString* ms_v_gen_mode; // TBD OvmsMetricBool* ms_v_gen_timermode; // True if generator timer enabled OvmsMetricInt* ms_v_gen_timerstart; // Time generator is due to start OvmsMetricString* ms_v_gen_state; // TBD OvmsMetricString* ms_v_gen_substate; // TBD OvmsMetricString* ms_v_gen_type; // Connection type (chademo, ccs, …) OvmsMetricBool* ms_v_gen_pilot; // Pilot signal present OvmsMetricBool* ms_v_gen_inprogress; // True = currently delivering power OvmsMetricFloat* ms_v_gen_limit_range; // Minimum range limit for generator mode [km] OvmsMetricFloat* ms_v_gen_limit_soc; // Minimum SOC limit for generator mode [%] OvmsMetricInt* ms_v_gen_duration_empty; // Estimated time remaining for full discharge [min] OvmsMetricInt* ms_v_gen_duration_range; // … for range limit [min] OvmsMetricInt* ms_v_gen_duration_soc; // … for SOC limit [min] OvmsMetricFloat* ms_v_gen_temp; // Generator temperature [°C] …metrics (not in same order): v.g.generating v.g.climit v.g.current v.g.duration.empty v.g.duration.range v.g.duration.soc v.g.efficiency v.g.kwh v.g.limit.range v.g.limit.soc v.g.mode v.g.pilot v.g.power v.g.state v.g.substate v.g.temp v.g.time v.g.timermode v.g.timerstart v.g.type v.g.voltage In addition to these, I would add energy counters to cover the actual grid energy side (i.e. before/after conversion losses): OvmsMetricFloat* ms_v_charge_kwh_grid; // Energy drawn from grid during running session [kWh] OvmsMetricFloat* ms_v_charge_kwh_grid_total; // Energy drawn from grid total (life time) [kWh] OvmsMetricFloat* ms_v_gen_kwh_grid; // Energy sent to grid during running session [kWh] OvmsMetricFloat* ms_v_gen_kwh_grid_total; // Energy sent to grid total (life time) [kWh] v.c.kwh.grid v.c.kwh.grid.total v.g.kwh.grid v.g.kwh.grid.total And yes, "kwh" as a metric name isn't perfect, but we started this with "v.c.kwh", so we should now stick to it for consistency. Do I miss something? Any objections / suggestions? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 1

v.e.drivetime and v.e.parktime candidates for persistence
by Steve Davies 18 Jan '21

18 Jan '21

Hi Michael, I'd propose that v.e.drivetime and v.e.parktime should be persistent. Each time my OVMS reboots - whether deliberately or due to a crash - these timers are lost so its common that they are wrong. I know the space is limited but I think it would be much better if they survived a reboot. Steve

2 1

MyMetrics - create a metric but don't initialise a value and set modified
by Steve Davies 17 Jan '21

17 Jan '21

Hi, Is there an "official" way to Init my private metrics without setting a value and having them marked modified? The problem I am trying to solve is that if I do this, for instance: > mt_i3_range_ecoproplus = MyMetrics.InitInt ("xi3.v.b.range.ecoproplus", SM_STALE_HIGH, 0, Kilometers); Then "0" is officially published as the range. This is unlikely and messes up my charts. I'd rather not publish a value until I get one from the car. I see that the standard metrics are just created with: > ms_v_bat_range_full = new OvmsMetricFloat(MS_V_BAT_RANGE_FULL, SM_STALE_HIGH, Kilometers); where V_BAT_RANGE_FULL is "v.b.range.full" They have no value until they are explicitly set. So would it be acceptable to rather create my private metrics like that? I guess then it falls on me to check if the metric already exists - which is done as part of InitFloat. So I guess I'd write: > mt_i3_range_ecoproplus = (OvmsMetricInt*)MyMetrics.Find("xi3.v.b.range.ecoproplus"); > if (mt_i3_range_ecoproplus==NULL) mt_i3_range_ecoproplus = new OvmsMetricInt("xi3.v.b.range.ecoproplus", SM_STALE_HIGH, Kilometers, 0); Is this a reasonable approach or am I going about this the wrong way?

2 1

Module: Strange freeze & config loss
by jaunius＠gmx.com 16 Jan '21

16 Jan '21

Hi, Now for a second time I find module stuck with power on after the night. No reaction to anything. After restart the module no longer contains user config. Also some strange files appear in /store/ dir. See screenshot attached. I am on edge OTA, this happened today. Any ideas? Regards, Jaunius Sent using the GMX mail app

2 2

Generator / V2G metrics proposal
by Derek Caudwell 14 Jan '21

14 Jan '21

Hi Michael Despite mentioning it some time ago I haven't had time to progress anything around V2G, V2H. So good to see you are. IMO using v.gen could be confusing as it is not strictly operating as a generator, that is closer to motor regeneration back into the pack. How about v2x instead which covers both V2H and V2G applications? Is the voltage metric required as my understanding is this will be the pack DC voltage? Given there is the possibility of V2H, so not grid connected could you instead have v.v2x.kwh.output and .input? Cheers Derek

2 1

GPS quits?
by Steve Davies 12 Jan '21

12 Jan '21

Hi, I'm finding the OVMS GPS really unreliable. For instance, here are the current "v.p." values from my OVMS. I'm apparently going 88 km/h on the highway notwithstanding that my car is parked at my house: v.p.acceleration v.p.altitude 9.7m v.p.direction 347.5° v.p.gpshdop 1 v.p.gpslock yes v.p.gpsmode AN v.p.gpsspeed 88.3404km/h v.p.latitude -34.0584 v.p.location v.p.longitude 18.4477 v.p.odometer 15053km v.p.satcount 9 v.p.speed 0km/h v.p.trip 22km xi3.v.p.tripconsumption 125Wh/km xi3.v.p.wheel1_speed 0km/h xi3.v.p.wheel2_speed 0km/h xi3.v.p.wheel3_speed 0km/h xi3.v.p.wheel4_speed 0km/h xi3.v.p.wheel_speed 0km/h Earlier when I went out the GPS position got similarly stuck and only recovered when I power cycled the OVMS. simcom status: OVMS# simcom status Network Registration: RegisteredHome Provider: VodaCom-SA Signal: -99 dBm State: NetMode PPP: Connected on channel: #2 GPS: Connected on channel: #1 I turned the modem off with the gui and then turned it on. Result of doing that was it did not get a PPP connection after some minutes, and the GPS did not connect. I tried this twice with the same result. Position is still the old one as above, no 3G PPP connection and no GPS connection. My GPS antenna is currently on the dashboard - could it be overheating in the sun there? - it is probably pretty warm. (But my car is currently under shade since I got home) I now went and power cycled the OVMS and the SIMCOM connected successfully, GPS connected, and has the correct position: OVMS# metrics list v.p. v.p.acceleration v.p.altitude 5.2m v.p.direction 0° v.p.gpshdop 1 v.p.gpslock yes v.p.gpsmode AA v.p.gpsspeed 0km/h v.p.latitude -34.0XXX v.p.location Home v.p.longitude 18.4XXX v.p.odometer 15053km v.p.satcount 9 v.p.speed 0km/h v.p.trip 22km xi3.v.p.tripconsumption 125Wh/km xi3.v.p.wheel1_speed 0km/h xi3.v.p.wheel2_speed 0km/h xi3.v.p.wheel3_speed 0km/h xi3.v.p.wheel4_speed 0km/h xi3.v.p.wheel_speed 0km/h I'm running with the ABRP script - is it possible that this is impacting the reliability? Otherwise I'm looking for ideas... Thanks, Steve

2 2