January 2021 - OvmsDev - Open Vehicles

Netmanager priority issue solved
by Michael Balzer 05 Jul '23

05 Jul '23

TL;DR: you need to pull my latest esp-idf changes. I've finally found & solved the strange priority changes for our netmanager task (i.e. being raised suddenly from origin 5 to 18/22): the bug was in the esp-idf posix threads mutex implementation. I had suspected the mutex priority inheritance for a while, so added a way to retrieve the internal mutex hold count for our task list. Using this I noticed the hold count would always & only raise by 2 whenever any kind of mongoose connection was closed. That lead me to checking the thread concurrency protection for mongoose mbufs, because every mongoose connection has two mbufs associated (rx & tx), each having a posix mutex. The bug was: posix mutexes were deleted after locking (taking) them. FreeRTOS mutexes must not be deleted while being taken, that breaks the priority inheritance (more precisely the disinheritance), with the visible effect being the mutex hold count not returning to zero. As a side effect, this may also solve the strange event task starvations (hope so…). I was investigating this as I suspected some busy loop in the netmanager context. With the netman running at prio 22, that would effectively block almost all other processing including the timer service. I've found & fixed one potential busy loop trigger in the netman that would have been caused by the netman task still running while all interfaces had been lost -- not sure if that could happen, but it would explain the effects. So please watch your crash debug info & report if the issue still turns up. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

5 19

ESP32 CAN controller hardware bug / interrupt issue
by Michael Balzer 03 Apr '21

03 Apr '21

Second finding & commit: TL;DR: * ESP32 CAN controller is broken, delivers trashed & duplicated RX frames * we need to optimize interrupt latency Users have been reporting occasional false BMS readings on the Twizy for more than a year. The error always trashed the reading of voltage #10 and/or temperature #8, so I initially thought that must be a variant of the SPIRAM/cache bug. But the SPIRAM fix didn't help, and the bug still occured with all BMS data in internal RAM. The issue correlated with high load situations and the SIMCOM UART issue. On testing the latest changes by Marko, my car module began showing that issue regularly, so I could take a closer look. It turned out the wrong data came from the CAN bus. Checking with a CAN logger didn't show any wrong data on the bus. So I scanned our CAN driver for potential issues, found & solved some (even a serious race condition) but that didn't fix it. I then added debug dumps of all frames read, dug into the SJA1000 spec sheet and found this: The SJA1000 RX FIFO has a capacity of 64 bytes. It's supposed to work as a ring buffer, with frames wrapping around as necessary. If no space is left in the FIFO for a new frame coming in, that frame should be discarded completely, not counted, just the overflow indicator should be set & the according interrupt be generated. Reality differs. The frame causing the overflow is added to the FIFO partially. It's also counted both in the RMC register and indicated by RBS as a valid frame when retrieving the FIFO contents. The read buffer delivers the partial frame + some trashed bytes up to the nominal frame length. In the BMS frame sequence it would normally trash bytes 7 & 8 on the sixth frame of length 8 in a sequence. A standard frame needs a 3 byte header + the data bytes in the FIFO, so 6 frames would add up to 66 bytes => 64 + 2 trash. The first trash byte normally is "08", the second "84" or "2a" or sometimes "ab", possibly some internal SJA1000 data. Better yet, if you rely on the indicators of the SJA1000 when reading the FIFO, the SJA1000 will repeat the first frame within the FIFO after the invalid frame. Mostly once or twice, and sometimes 7 times or more: inv_msg: framecnt=13, invindex=6 inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 24 04 00 00 11 40 10 22 37 55 00 37 | 4..?........$....@."7U.7 inv_msg: 25 04 00 00 0a 1b 44 ff fe 4e 01 26 | 4..?........%.....D..N.& inv_msg: 54 05 00 00 37 37 37 37 37 37 37 00 | 4..?........T...7777777. inv_msg: 56 05 00 00 31 63 14 31 53 14 31 4a | 4..?........V...1c.1S.1J inv_msg: 57 05 00 00 31 43 14 31 53 15 *08 2a* | 4..?........W...1C.1S..* ^^^^^ trashed bytes … followed by 7 repetitions of the first frame: inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n If you had occasional strange false readings leading to strange effects, this may be the explanation. Note: the SJA1000 FIFO bug may need specific circumstance to occur in addition to the overflow, maybe the overflow happening on a specific byte position in the FIFO -- I haven't tried to determine that. I've tried clearing the overflow ASAP, looping on the IR indicator and looping on the RMC, the fault is always the same. The workaround I've now done is adding up the message lengths read during a FIFO run and discard all frames exceeding the 64 byte border. Not pretty, but functional. That keeps the trashed frames from being forwarded to the OVMS application level. As with the SIMCOM UART, these overflows wouldn't happen if the interrupt handler would react fast enough. It seems we've got a general interrupt latency issue. And just as with the SIMCOM I saw a reduction of overflows when allocating the CAN IRQ on core #0, another one with raising the IRQ level to 3, so that's also part of my commit. The esp-idf CAN driver apparently has the same issue even in the latest release, I'll contact the author about this or post another issue to Espressif. So our interrupt allocation is now: Task Run# Lvl ISR# Usage Source ---------------------------------------------------------------------------------------- - 0 1 0 RTC Core ETS_RTC_CORE_INTR_SOURCE esp_timer 0 1 0 RTOS esp_timer ETS_TIMER2_INTR_SOURCE ipc0 0 1 0 RTOS Scheduler Core0 ETS_FROM_CPU_INTR0_SOURCE ipc1 1 1 1 RTOS Scheduler Core1 ETS_FROM_CPU_INTR1_SOURCE main 0 1 0 RTOS Watchdog ETS_TG0_WDT_LEVEL_INTR_SOURCE OVMS Events 1 1 1 Peripherals (GPIO ISR) ETS_GPIO_INTR_SOURCE OVMS Events 1 1 1 MAX7317 (spi_nodma) ETS_SPI3_INTR_SOURCE *esp32can init 0 3 0 ESP32 CAN ETS_CAN_INTR_SOURCE** **OVMS SIMCOM 0 2 0 SIMCOM UART ETS_UART1_INTR_SOURCE* OVMS Events 1 1 1 USB console (UART) ETS_UART0_INTR_SOURCE OVMS Events 1 1 1 SD card ETS_SDIO_HOST_INTR_SOURCE ---------------------------------------------------------------------------------------- I think we need to find the source of the interrupt latency and/or find some better scheme to distribute the tasks & interrupts over the cores. I still don't know why core #1 already got an issue with just our 6 interrupts. This may be related to the SPIRAM fix adding overhead, but I've seen the FIFO overflows before applying the fix, and the CAN issue also has been present for over a year. My working hypothesis is some task/driver disabling interrupts for too often / too long, or non-IRAM ISRs getting delayed for too often / too long. And it seems this is an issue especially on core #1. Please verify & comment. Regards, Michael PS: a little side mystery: the netmanager task starts with priority 5, then gets raised to 22 (probably a mutex priority inheritance), but never gets lowered back to 5 afterwards. A FreeRTOS bug? -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 11

External Wifi antenna
by Michael Balzer 15 Mar '21

15 Mar '21

Some info for those in need of a better Wifi signal than achievable with the builtin ESP32-WROVER antenna: A friend of mine on the german Twizy forum had severe signal issues, using an external router antenna he saw an improvement of ~10 dB. Basics: - https://www.esp32.com/viewtopic.php?t=1635 …view on the OVMS module: Here's a video by him on the topic (in German, try automatic translation) – but sadly not showing the actual soldering process, more the afterworks: https://www.youtube.com/watch?v=4Uv71HiBPpg Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

4 22

Re: [Ovmsdev] Update WolfSSH/SSL
by Stephen Casner 31 Jan '21

31 Jan '21

Any objections to merging my update-wolfssh branch into master? -- Steve ---------- Forwarded message ---------- Date: Wed, 27 Jan 2021 18:03:42 -0800 (PST) From: Stephen Casner <casner(a)acm.org> Reply-To: OVMS Developers <ovmsdev(a)lists.openvehicles.com> To: OVMS Developers <ovmsdev(a)lists.openvehicles.com> Subject: Re: [Ovmsdev] Update WolfSSH/SSL On Sun, 24 Jan 2021, Michael Balzer wrote: > The higher base memory footprint due to the higher NetMan stack size + some > additional buffer it seems (some 512 bytes?) means this needs to be checked > with complex vehicle modules in live operation before merging, but I think > that won't be an issue. As suggested to me by WolfSSL support, there is a configuration parameter for wolfssl to use heap allocation rather than stack for some buffers and structures. With that change, I can restore the NetMan stack to 8K. Now the comparison of memory usage is as follows: - With the current master code the max NetMan stack depth on my OVMS was 5616 whereas after the update it is 5760. - With the current master code, the amount of memory added by NetMan when an ssh connection was established was 2557 D/IRAM and 6108 SPIRAM for 8665 total. With the update it was 1056 D/IRAM and 7532 SPIRAM for 8588 total. I think this change should clear the way for merging into master. -- Steve _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

1 0

Implementing advanced charge control
by Stephen Casner 29 Jan '21

29 Jan '21

I've been working intermittently over the past two years on functionality to replace the ACC (advanced charge control) feature of OVMS v2. As an example, ACC could be configured to begin a cooldown charge cycle upon plug-in at home. In OVMS v3 the geofencing aspect of the ACC feature was implemented in the "location" command to be usable more generally. Based on design discussions with Mark about how the charge control operations and other functions should be attached to geolocations I have extended the location command to allow a list of actions to be attached to a defined location upon entering or leaving. The initial set of actions is: - acc -- initiate a charging profile (only upon entering) - homelink -- transmit homelink code - notify -- send a notification text to the app While this activity has been in progress the OVMS scripting features have been enhanced significantly. It is possible to do much of what I describe using scripts that are triggered upon entering or leaving a location. However, creating and installing scripts requires some developer skills that are likely beyond the comfort zone of many OVMS users, so I think it is still worthwhile to implement these location actions. At this point the homelink and notify actions are already implemented for activation upon entering or leaving a location. Assignment of acc actions to locations is also implemented, but those actions have no effect at this point. This message describes what I propose for acc. ACC is based on named charging profiles that specify a charge type (on-demand, charge at time, charge by time, etc) and associated parameters controlling the charge. Mark suggested that at home he might want to do a: Type: Charge By Cooldown on plugin Charge limit: 90% SOC Charge mode: Standard Charge current: 32A Complete charge by 7am Another example: Type: Charge At Cooldown: no Charge limit: 200km Charge mode: Standard Charge current: 32A Start charge at 11pm Charge profiles could also be activated manually or by a script. For example, you might arrive at a restaurant and type "charge acc ontheroad" to select the profile ontheroad without having to set all the individual parameters. The "charge" command currently includes subcommands to set the current and mode but would need to be extended to control times and limits. The front-end changes would be to extended the command tree as follows: acc list <name> acc set <name> at <time> acc set <name> by <time> acc set <name> on-plugin acc set <name> soc <percent> acc set <name> range <distance> acc rm <name> acc rm <name> at <time> acc rm <name> by <time> acc rm <name> on-plugin acc rm <name> soc <percent> acc rm <name> range <distance> charge acc <name> charge at <time> charge by <time> charge on-plugin charge soc <percent> charge range <distance> The choices at, by and on-plugin are mutually exclusive, so the last one is effective. The soc and range limits will stop the charge when reached and if set together with a "by <time>" would cause charging to continue after the specified time if the limit has not been reached. Charge profiles would be stored in the config in a manner similar to the way locations are stored with the name as the instance and the list of charge parameters in the value. I have not worked out all the backend details yet, so this is where those of you who are more familiar with the vehicle code can provide some guidance. Mark's suggestion was to extend the general vehicle framework to support the core ACC functionality; some parts might be handled completely at the generic layer, while other parts would require vehicle-specific implementation. The goal is to bring a set of advanced charge control functionality to all vehicle types (even if the vehicle has limited support). So long as the vehicle can start / stop charging, we can provide things like timed charges (at or by) in OVMS firmware. So at a minimum the functionality we require is the vehicle ability to start a charge, stop a charge, and provide signaling when the pilot signal is detected. We also need to be able to monitor the SOC and range as they increase during charging, but I think those values are already implemented well enough in the metrics. Some cars might not be able to support the minimum functions, so we may need some sort of capabilities back from the vehicle module to know whether the acc functions can be implemented Something like 'HasChargeStop', 'HasChargeStart', 'HasTimer', etc. Since many cars will normally start charging as soon as the charge cable is plugged in, OVMS needs to see the pilot-signal-present notification and stop the car from charging until the ACC conditions dictate. This is the case for the Tesla Roadster unless the car is at a location where a scheduled charge time has been configured. But having a scheduled charge configured is not good because that may interfere with what OVMS is trying to control. The "charge by" operation requires using the charge time predictor to figure the start time, then is becomes the same as "charge at". I have some concern that the existing CTP may not be accurate for Roadsters with the 3.0 battery. I don't know whether the other vehicles have an accurate CTP. The "charge on-plugin" operation has an associated event, but all the other operations require use of a ticker to see if the start time has come or the stopping condition has been reached. Comments appreciated. -- Steve

3 7

Update WolfSSH/SSL
by Stephen Casner 28 Jan '21

28 Jan '21

After a pause of three years, I have finally gotten around to updating wolfssh and wolfssl to the current stable releases, 1.4.5 and 4.6.0 respectively. This includes the code to support SCP that I wrote and contributed back to them and was integrated into wolfssh 1.3.0. There were some API tweaks that I needed to work through, but the source files are now unmodified except for wolfcrypt/settings.h where I ran into a compilation conflict on the XREALLOC macro. As before, I need to supply my own malloc, free and realloc functions so we can control PSRAM usage and so we can emit a log message if memory allocation fails. For starters, this update removes the restriction to use cipher aes128-cbc. In addition, the WolfSSL code now includes integration with the hardware crypto acceleration capabilities of the ESP32. I'm not sure how much that will affect performance as we see it because I think the biggest performance factor is how we need to use the APIs given our task structure. The public key handshake for initial connection may be faster. I added the new code on a branch named update-wolfssh by copying in the source files as I did when creating the wolfssh and wolfssl components initially. I'm running the new code on OVMS in my car and have given it basic testing by connecting with the ssh client and transferring files with scp. I invite anyone else who is interested to test as well or to comment if there are any concerns about merging to the master branch. There are some memory considerations. I've added the complete wolfssl source tree even though we only use the wolfcrypt subset of wolfssl. The update added a bunch of files and increased the required disk space from 18M to 43M. Similarly, wolfssh added code for scp, sftp, ssh agent server code and also ssh clients that we are not using; that increased disk space from 2.0M to 2.6M. I added our scp code before they implemented theirs and I have not examined their scp and sftp code to see if there would be any advantage in trying to adapt it to fit our non-blocking architecture. I had to increase the size of the NetMan stack from 8K to 10K to avoid stack overflow. With current master code the max used on my OVMS was 5616 whereas after the update it is 9700. With the current master code, the amount of memory added by NetMan when an ssh connection was established was 2557 D/IRAM and 6108 SPIRAM for 8665 total. With the update it was 1240 D/IRAM and 8768 SPIRAM for 10008 total. -- Steve

3 4

Proposed new config option
by Stephen Casner 27 Jan '21

27 Jan '21

When I'm working with my bench OVMS unit attached with USB and frequently rebooting, I don't want to have to log in each time. To avoid this I have patched console_async.cpp to SetSecure(true) in the constructor. But I have to be careful to omit that patched file when committing my changes. I proposed to add a Kconfig developer option to control whether that SetSecure(true) statement is included. Then I can commit this functionality into the code base where it will normally be excluded but can be included for a developer build configuration. This is similar to OVMS_DEV_CONFIGVFS option that allows read access to the ovms_config file. My proposed change is attached. Any objections? -- Steve

3 3

Fwd: How does TPMS work now?
by Michael Balzer 27 Jan '21

27 Jan '21

It seems the list server still has issues: -------- Weitergeleitete Nachricht -------- Betreff: Re: [Ovmsdev] How does TPMS work now? Datum: Mon, 18 Jan 2021 07:54:31 +0100 Von: Michael Balzer <dexter(a)expeedo.de> An: ovmsdev(a)lists.openvehicles.com Craig, vector metrics can (as all metrics btw) be set by their string representation, i.e. metrics set v.t.pressure 210.29,210.29,210.29,210.29 …and all TPMS metrics (also the new ones) are persistent now, see my post "extended metrics persistence". Regarding the sensor sets, I haven't used them yet, and documentation is lacking, so you need to check the source. Regards, Michael Am 18.01.21 um 04:11 schrieb Craig Leres: > It used to be possible to manually set tire pressure with: > > metrics set v.tp.fl.p 210.29 > metrics set v.tp.fr.p 210.29 > metrics set v.tp.rl.p 210.29 > metrics set v.tp.rr.p 210.29 > > but after upgrading to the latest persistent metrics code I see these > are all gone. > > I looked at the tpms command but it seems to be designed to track > different sets of tpms sensor id numbers. > > Is it possible to set these from the command line? Are tpms tire > pressures (and temperatures) still persistent across warm reboots? Is > my problem that these are stored in vectors now and there is not yet a > way to manipulate them from the command line? > > Craig > _______________________________________________ > OvmsDev mailing list > OvmsDev(a)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 -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 5

Scan and discover process for 29bits PID
by didier＠ernotte.com 26 Jan '21

26 Jan '21

Hi, Thanks to all the help you provide me here, I was able to identify most of the 11bits ECU with broadcast request and SavvyCAN, and relative PID with the PID scanner.I am a bit confused how I can scan ECU/PID with the extended mode (29 bits). How can I do the same kind of investigation and scanning with the extended mode ? Didier

2 1

General trip & grid log proposal
by Michael Balzer 25 Jan '21

25 Jan '21

Everyone, followup to my previous mail, these are the record structures for the general trip & grid logs I would like to add. I'm going to implement this with configurable server hold times, with 0 = no server storage at all. As this has more potential for data privacy impact as the standard 24 hour storage of telemetry records, I wouldn't enable the logs by default, but leave this decision to the user. Please check & provide feedback. Regards, Michael ==================================================================================================== History type "*-LOG-Trip" Notification type "data", subtype "log.trip" OvmsMetricBool* ms_v_pos_gpslock; OvmsMetricFloat* ms_v_pos_latitude; OvmsMetricFloat* ms_v_pos_longitude; OvmsMetricFloat* ms_v_pos_altitude; OvmsMetricString* ms_v_pos_location; // Name of current location if defined OvmsMetricFloat* ms_v_pos_odometer; OvmsMetricFloat* ms_v_pos_trip; // Trip distance OvmsMetricInt* ms_v_env_drivetime; // Trip duration OvmsMetricInt* ms_v_env_drivemode; // Active drive profile number [1] OvmsMetricFloat* ms_v_bat_soc; // State of charge [%] OvmsMetricFloat* ms_v_bat_range_est; // Estimated range [km] OvmsMetricFloat* ms_v_bat_range_ideal; // Ideal range [km] OvmsMetricFloat* ms_v_bat_range_full; // Ideal range at 100% SOC & current conditions [km] OvmsMetricFloat* ms_v_bat_energy_used; // Main battery energy used on trip [kWh] OvmsMetricFloat* ms_v_bat_energy_recd; // Main battery energy recovered on trip [kWh] OvmsMetricFloat* ms_v_bat_coulomb_used; OvmsMetricFloat* ms_v_bat_coulomb_recd; OvmsMetricFloat* ms_v_bat_soh; // State of health [%] OvmsMetricString* ms_v_bat_health; // General textual description of battery health OvmsMetricFloat* ms_v_bat_cac; // Calculated capacity [Ah] OvmsMetricFloat* ms_v_bat_energy_used_total; // Battery energy used total (life time) [kWh] OvmsMetricFloat* ms_v_bat_energy_recd_total; // Battery energy recovered total (life time) [kWh] OvmsMetricFloat* ms_v_bat_coulomb_used_total; // Battery coulomb used total (life time) [Ah] OvmsMetricFloat* ms_v_bat_coulomb_recd_total; // Battery coulomb recovered total (life time) [Ah] OvmsMetricFloat* ms_v_env_temp; // Ambient temperature [°C] OvmsMetricFloat* ms_v_env_cabintemp; // Cabin temperature [°C] OvmsMetricFloat* ms_v_bat_temp; // Battery temperature [°C] OvmsMetricFloat* ms_v_inv_temp; // Inverter temperature [°C] OvmsMetricFloat* ms_v_mot_temp; // Motor temperature [°C] OvmsMetricFloat* ms_v_charge_12v_temp; // Temperature of DC/DC-converter [°C] OvmsMetricFloat* MAX(ms_v_tpms_temp); // Maximum tyre temperature OvmsMetricFloat* MIN(ms_v_tpms_pressure); // Minimum tyre pressure OvmsMetricFloat* MIN(ms_v_tpms_health); // Minimum tyre health ==================================================================================================== History type "*-LOG-Grid" Notification type "data", subtype "log.grid" OvmsMetricBool* ms_v_pos_gpslock; OvmsMetricFloat* ms_v_pos_latitude; OvmsMetricFloat* ms_v_pos_longitude; OvmsMetricFloat* ms_v_pos_altitude; OvmsMetricString* ms_v_pos_location; // Name of current location if defined OvmsMetricFloat* ms_v_pos_odometer; OvmsMetricString* ms_v_charge_type; // Grid connection type OvmsMetricString* ms_v_charge_state; // charging, topoff, done, prepare, … OvmsMetricString* ms_v_charge_substate; // scheduledstop, scheduledstart, … OvmsMetricString* ms_v_charge_mode; // standard, range, performance, storage OvmsMetricFloat* ms_v_charge_climit; // Maximum charger output current [A] 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 [%] OvmsMetricString* ms_v_gen_type; // Grid connection type OvmsMetricString* ms_v_gen_state; // TBD OvmsMetricString* ms_v_gen_substate; // TBD OvmsMetricString* ms_v_gen_mode; // TBD OvmsMetricFloat* ms_v_gen_climit; // Maximum battery output current [A] OvmsMetricFloat* ms_v_gen_limit_range; // Min range [km] OvmsMetricFloat* ms_v_gen_limit_soc; // Min SOC [%] OvmsMetricInt* ms_v_charge_time; // Duration of running charge session [sec] OvmsMetricFloat* ms_v_charge_kwh; // Energy charged into battery for running session [kWh] 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] OvmsMetricInt* ms_v_gen_time; // Duration of running generator session [sec] OvmsMetricFloat* ms_v_gen_kwh; // Energy taken from battery for running session [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] OvmsMetricFloat* ms_v_bat_soc; // State of charge [%] OvmsMetricFloat* ms_v_bat_range_est; // Estimated range [km] OvmsMetricFloat* ms_v_bat_range_ideal; // Ideal range [km] OvmsMetricFloat* ms_v_bat_range_full; // Ideal range at 100% SOC & current conditions [km] OvmsMetricFloat* ms_v_bat_voltage; // Main battery momentary voltage [V] OvmsMetricFloat* ms_v_bat_temp; // Battery temperature [°C] OvmsMetricFloat* ms_v_charge_temp; // Charger temperature [°C] OvmsMetricFloat* ms_v_charge_12v_temp; // Temperature of DC/DC-converter [°C] OvmsMetricFloat* ms_v_env_temp; // Ambient temperature [°C] OvmsMetricFloat* ms_v_env_cabintemp; // Cabin temperature [°C] OvmsMetricFloat* ms_v_bat_soh; // State of health [%] OvmsMetricString* ms_v_bat_health; // General textual description of battery health OvmsMetricFloat* ms_v_bat_cac; // Calculated capacity [Ah] OvmsMetricFloat* ms_v_bat_energy_used_total; // Battery energy used total (life time) [kWh] OvmsMetricFloat* ms_v_bat_energy_recd_total; // Battery energy recovered total (life time) [kWh] OvmsMetricFloat* ms_v_bat_coulomb_used_total; // Battery coulomb used total (life time) [Ah] OvmsMetricFloat* ms_v_bat_coulomb_recd_total; // Battery coulomb recovered total (life time) [Ah] -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

4 11