November 2019 - OvmsDev - Open Vehicles

Android app updated, lost my car
by Greg D. 25 Nov '19

25 Nov '19

Last night the Android app updated on my phone. I'm still getting alerts from the car, but the only car shown on the app is the "Demonstration car", which of course, isn't active. I've added the car back, and it seems to be working. So, just FYI. Greg

9 15

Fwd: [openvehicles/Open-Vehicle-Monitoring-System-3] f84837: Server V2 & V3: fix registration for notifications...
by Mark Webb-Johnson 19 Nov '19

19 Nov '19

I don’t think this fix is correct. Seeking clarification of the thinking behind it. Currently, MyOvmsServerV2Reader is initialised to 0. Then, OvmsServerV2::OvmsServerV2 creates the reader (and sets MyOvmsServerV2Reader to it) if it is zero. Then OvmsServerV2::~OvmsServerV2 deregisters (clears) the reader, but does not set MyOvmsServerV2Reader to 0. The change is to OvmsServerV2::OvmsServerV2 to register the reader (without setting MyOvmsServerV2Reader) if MyOvmsServerV2Reader is 0. This seems to leak one reader every time the OvmsServerV2 is stopped/started, as without storing in MyOvmsServerV2Reader, the old reader will never be cleared upon deregistering. Or am I missing something? It seems that the better solution is to change OvmsServerV2::~OvmsServerV2 to set MyOvmsServerV2Reader=0 after deregistering (which is the original bug, imho)? Regards, Mark. > Begin forwarded message: > > From: Michael Balzer <noreply(a)github.com> > Subject: [openvehicles/Open-Vehicle-Monitoring-System-3] f84837: Server V2 & V3: fix registration for notifications... > Date: 17 November 2019 at 11:22:46 PM HKT > To: mark(a)webb-johnson.net > > Branch: refs/heads/master > Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 > Commit: f84837a2ce40d32769134d0bb5fe6dee09d842b3 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/f84… > Author: Michael Balzer <balzer(a)expeedo.de> > Date: 2019-11-17 (Sun, 17 Nov 2019) > > Changed paths: > M vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp > M vehicle/OVMS.V3/components/ovms_server_v3/src/ovms_server_v3.cpp > > Log Message: > ----------- > Server V2 & V3: fix registration for notifications on restart > >

2 2

EGPIO / MAX7317 input monitoring
by Michael Balzer 17 Nov '19

17 Nov '19

Everyone, to better support plugins using hardware extensions I've added input monitoring + events + metrics to the EGPIO / MAX7317 module, and some documentation on it: * https://docs.openvehicles.com/en/latest/userguide/egpio.html * https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/465… Please have a look and extend if something's missing there. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

Power Draw
by Fran Terry 12 Nov '19

12 Nov '19

Hello One and All. Sorry if this question has already been asked, how much current draw does one expect from V3? Thanks Fran

2 1

Re: [Ovmsdev] Nissan LEAF: HVAC Metrics
by Jaunius Kapkan 11 Nov '19

11 Nov '19

Hi, I agree with the suggestions. Remote cool/heat is when the climate control is activated from app. Not sure if other cars have a separate var for this. So the initial ones ar good enough. In regards to v.e.cabin it would be logical to add the cabin temperature there as well. Regards, Jaunius Kapkan [Sent from cellphone] > On 2019-11-11, at 07:52, Mark Webb-Johnson <mark(a)webb-johnson.net> wrote:

1 0

Time variable
by Tamás Kovács 08 Nov '19

08 Nov '19

I have a problem with utc time, the time is correct but the date is not valid. I use 3.2.005-99-g88cfeef9 version with modification of Mitsubishi i-MiEV. OVMS# me li utc m.time.utc 953756768Sec I (900675) housekeeping: 2000-03-22 21:27:06 CET (RAM: 8b=82812-86452 32b=27308) I (981115) webserver: HTTP POST /api/execute I (981115) webcommand: HttpCommandStream[0x3fa32958]: 1984428 bytes free, executing: time OVMS# time Time Zone: CET-1CEST,M3.5.0,M10.5.0/3 UTC Time: 2000-03-22 20:28:27 UTC Local Time: 2000-03-22 21:28:27 CET Provider: gsm-nmea PROVIDER STRATUM UPDATE TIME *gsm-nmea 2 0 Wed Mar 22 20:28:27 2000 -- Üdvözlettel: Kovács Tamás

3 12

Distinguishing between eNiro and Kona
by Peter Lord 05 Nov '19

05 Nov '19

Hi All, In trying to get my UK Kona Electric working I've realised that in the eNiro code we need to distinguish between : * Kia eNero and Hyundai Kona ( console odometer is different PID location ) * Country ( console odometer can be in Miles or Kilometres ) * Left hand drive and right hand drive ( door PID's are associated with driver position not fixed left/right ) I'm wondering whats the best way to do this. I believe the VIN number can tell us the first one - Hyundai is KMH and Kia KN, so the odometer code could look at the VIN number to choose where to extract the odometer info. However I'm not sure on the others. I can't tell if the VIN number gives this level of detail. My UK Kona ( right hand dive, uses miles ) VIN starts with KMHK581GUKU - but I've not found a definitive way to fully decode the VIN for eNiro and Kona Electric. I guess the other option is to add some car specific features. Any ideas ? Thanks, Pete

3 6

SIMCOM UART interrupt issue & optimization
by Michael Balzer 01 Nov '19

01 Nov '19

Everyone, I've pushed another optimization for the SIMCOM component that reduces the UART hardware FIFO overflows (https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/274) to nearly zero by changing core associations. TL;DR: * you also should apply the sdkconfig changes from the commit * we need to optimize interrupt latency Analyzing our current core usage I found we've been running nearly all interrupt handlers on core #1. That's because interrupts are bound to the core that allocates them, and after system init, the housekeeper created all peripheral components on core #1. This has been our interrupt allocation up to 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 OVMS Events 1 1 1 ESP32 CAN ETS_CAN_INTR_SOURCE OVMS Events 1 1 1 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 had some advances on the FIFO overflows by allocating a level 3 interrupt for the SIMCOM UART, but not much. I then tried moving the SIMCOM interrupt handler to core #0, and that immediately reduced the overflows drastically -- most of the time. I read through the Espressif forums and issues on interrupt latency optimization and found a precious hint here: https://www.esp32.com/viewtopic.php?t=11462#p46437 /"Finally, by default the LWIP task is allowed to run on either core, and will sometimes take a// //spinlock which requires disabling interrupts. Try pinning this task to CPU 0, only"/ I did so, and the FIFO overflows disappeared completely on my bench. In my car there still are some, but very few. I also tested pinning LWIP to core #1, that also worked and may be an alternative. I then searched for more config candidates affecting interrupt performance and also disabled the interrupt backtrace feature. That saves just 4 instructions on interrupt entry, so has little effect and can be re-enabled in case we need it. I've reduced the UART IRQ level to 2 again as a support for my second finding regarding the CAN controller, will describe that in the next post. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 2