- OvmsDev - Open Vehicles

App notification help
by Derek Caudwell 05 Aug '20

05 Aug '20

Any help appreciated to understand why App alerts are being sent with different information to that in the MP-0 message. I assume it is being triggered earlier and then delayed for some reason? 2020-08-05 18:25:08 NZST I (325841) ovms-server-v3: Tx event vehicle.charge.start 2020-08-05 18:25:08 NZST I (325861) ovms-server-v3: Tx event vehicle.charge.state 2020-08-05 18:25:08 NZST I (325891) ovms-server-v3: Tx event vehicle.charge.mode 2020-08-05 18:25:08 NZST I (326031) webserver: HTTP POST /api/execute 2020-08-05 18:25:08 NZST I (326051) webserver: HTTP POST /api/execute 2020-08-05 18:25:08 NZST I (326071) webserver: HTTP POST /api/execute 2020-08-05 18:25:08 NZST I (326091) webcommand: HttpCommandStream[0x3f89a4bc]: 3601112 bytes free, executing: stat*2020-08-05 18:25:08 NZST I (326101) ovms-server-v2: Send MP-0 S62.0,K,371,0,charging,standard,132,101,16,1,0,0,3,1,0,0,0,0,65.44,0,0,0,80,-1,0,0,0,0,0,164,0,-0.51,511.50,82* 2020-08-05 18:25:08 NZST I (326131) ovms-server-v2: Send MP-0 D80,8,4,12.5,0,16,0,447560,0,325,12.5,1,1,1,12.17,0,12.5,0,0,0,16 2020-08-05 18:25:08 NZST I (326091) webcommand: HttpCommandStream[0x3f895bf4]: 3598540 bytes free, executing: stat 2020-08-05 18:25:08 NZST I (326091) webcommand: HttpCommandStream[0x3f89a3f4]: 3600896 bytes free, executing: stat*2020-08-05 18:25:10 NZST I (328121) ovms-server-v2: Send MP-0 PINot charging|SOC: 62.0%|Ideal range: 132km|Est. range: 102km|ODO: 44756.0km|CAC: 65.4Ah|SOH: 82%* 2020-08-05 18:25:10 NZST I (328131) ovms-server-v3: Tx notify ovms/nismo/notify/info/charge.started=Not charging|SOC: 62.0%|Ideal range: 132km|Est. range: 102km|ODO: 44756.0km|CAC: 65.4Ah|SOH: 82% 2020-08-05 18:25:10 NZST I (328191) ovms-server-v3: Tx event notify.info.charge.started 2020-08-05 18:25:11 NZST I (328301) ovms-server-v3: Message publishing acknowledged (msg_id: 216) 2020-08-05 18:25:11 NZST I (329151) ovms-server-v3: Tx event vehicle.charge.pilot.on 2020-08-05 18:25:11 NZST I (329171) ovms-server-v3: Tx event vehicle.charge.prepare

2 1

Persistent metrics
by Derek Caudwell 02 Aug '20

02 Aug '20

Hi all, Is it possible to set persistence on metrics such as v.e.awake and v.e.locked? I tried setting in the vehicle module but they did not show in persist list, other vehicle specific ones that I set did however.

1 0

Re: [Ovmsdev] Vehicle Idle Notification
by Derek Caudwell 01 Aug '20

01 Aug '20

Hi Michael Thanks for clarifying that, it may be worth removing reference to bus activity in the metric description. I see some vehicles have used can bus activity to set awake metric, which I then used for the Leaf before noticing its implications. I will send through pull request for Leaf to align it with the awake definition. Cheers Derek

1 0

Vehicle Idle Notification
by Derek Caudwell 31 Jul '20

31 Jul '20

Hi all, In Vehicle.cpp the NotifyVehicleIdling() routine is essentially called when StdMetrics.ms_v_env_awake is true and the idle ticker has expired. My understanding from the standard metrics documentation is that the awake metric is to indicate activity on the can bus eg when charging or prior to the vehicle being turned on. Hence I was only expecting an idle notification if the vehicle has been accidentally left in the on state indicated by StandardMetrics.ms_v_env_on. Or have I misunderstood how the two metrics and idle function are intended to work or mean? Cheers Derek

2 1

App for Garmin Watches
by Sébastien Darveau 30 Jul '20

30 Jul '20

Hi Mark, I’m working on a widget to see my SOC on my Garmin watch and I’d like to request permission to go further and publish on the Garmin store (https://apps.garmin.com/en-US/) with “OVMS" as name. Once in the store, user will be able to enter vehicle_id, username and password/token to access own car information. Application uses a proxy on AWS Lambda to access the REST Api. I have taken the resources from the iOS app and reduced the size a bit. Please note that I also use the OVMS logo on the loading screen. Here is the code: https://github.com/sdarveau/Open-Vehicle-Garmin. Feel free to move it under the openvehicles workspace. I’m planning to improve it but I'll keep it simple. Thanks, Sebastien

2 4

Reading config in OvmsVehicleXXXInit
by Soko 26 Jul '20

26 Jul '20

Hey guys, I'd like to keep the sources for the T26A and OBD version for the VW e-up separated. With my little understanding of the OVMS framework I've created one (abstract) class for the vehicle with the web-interface stuff. Then two derived classes, one for OBD one for T26A. Now I try to register those two different classes depending on the settings: OvmsVehicleVWeUpInit::OvmsVehicleVWeUpInit() { int how_connected = MyConfig.GetParamValueInt("vwup", "how_connected", CONN_OBD); ESP_LOGI(TAG, "Registering Vehicle: VW e-Up (9000). how_connected=%d", how_connected); if (how_connected == CONN_T26A) { MyVehicleFactory.RegisterVehicle<VWeUpT26a>("VWUP", "VW e-Up"); } else { MyVehicleFactory.RegisterVehicle<VWeUpObd>("VWUP", "VW e-Up"); } } I know already that this only gets called during reboot as the log-message doesn't show up when I change the vehicle. But it seems that MyConfig isn't really the correct/same instance (?) as I'm getting inside my classes. Because the web-interface shows how_connected=CONN_T26A, but here it is always CONN_OBD (default value). How do I do this properly? Or is it even a better idea to do two separate vehicles?? thx Soko

2 2

Re: [Ovmsdev] debugging CAN bus error flags
by Derek Caudwell 18 Jul '20

18 Jul '20

Thanks Michael, That explains why I was struggling to decode the error flag. Having been through the MCP2515 docs and decoded the logged error flags can2 is receiving they all relate to overflow of RXB0 but not RXB1. Hence this does not really pose or indicate a problem for the can bus / MCP2515 chip, correct? So if I have understood the chip operation is there any reason for line 489 in mcp2515.cpp which causes these to be logged? 489: LogStatus(CAN_LogStatus_Error); As if RXB1 does overflow and cause a packet loss then line 467: ESP_LOGW(TAG, "CAN Bus 2/3 receive overflow; Frame lost."); deals with that? Cheers Derek

3 2

Debugging the task watchdog triggers
by Michael Balzer 18 Jul '20

18 Jul '20

Everyone, the remaining crashes I have seen in quite a while were all due to the task watchdog triggering. I have now added capturing the names of the tasks that failed feeding the dog and capturing the event that was processed at the time of the crash/wdt to the RTC boot data. If set, it's shown by the "boot" command and transmitted to a v2 server via the "*-OVM-DebugCrash" records. Example: OVMS# boot status Last boot was 10 second(s) ago Time at boot: 2020-07-18 11:53:07 CEST This is reset #1 since last power cycle Detected boot reason: Crash (12/12) Reset reason: *Task watchdog* (6) Crash counters: 1 total, 0 early Last crash: abort() was called on core 0 Backtrace: 0x4008e627 0x4008e8c1 0x400e6100 0x40083f6a * Event: ticker.1@module 64 secs** ** WDT tasks: OVMS Events* Version: 3.2.013-303-gfc79b92f/factory/edge (build idf v3.3.2-879-g0137aef47 Jul 18 2020 11:29:45) This was a test trigger by "module trigger twdt". DebugCrash record structure is now: // H type "*-OVM-DebugCrash" // ,<firmware_version> // ,<bootcount>,<bootreason_name>,<bootreason_cpu0>,<bootreason_cpu1> // ,<crashcnt>,<earlycrashcnt>,<crashtype>,<crashcore>,<registers>,<backtrace> // ,<resetreason>,<resetreason_name> // ,<curr_event_name>,<curr_event_handler>,<curr_event_runtime> // ,<wdt_tasknames> Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

PSRAM fix in esp-idf release v3.3
by Michael Balzer 16 Jul '20

16 Jul '20

Mark, it seems the fix has finally arrived in the official release 3.3 branch: https://github.com/espressif/esp-idf/issues/2892#issuecomment-658327913 https://github.com/espressif/esp-idf/commit/f4333c8e3a554e8bb4210d825cbdf4b… Btw: > In the v3 silicon, the issue has been fixed, and the workaround is no > longer required. > I guess that means from some manufacturing point on we should provide two builds, one for the older hardware and one for the modules with v3 chips, as the fix definitely has a performance impact. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

4 8

debugging CAN bus error flags
by Derek Caudwell 16 Jul '20

16 Jul '20

On my Nissan Leaf I am getting the following error irqs repeating on CAN bus 2. The error flags appear to be set in esp32can.cpp but I could use some pointers on how to interpret their meaning and hence how to handle the interrupts (assuming they are not real errors): 1970-01-01 13:01:41 NZDT E (89501) can: can2: intr=93510 rxpkt=127559 txpkt=14 errflags=0x23000001 rxerr=0 txerr=0 rxovr=0 txovr=0 txdelay=0 wdgreset=0 errreset=0 1970-01-01 13:01:41 NZDT E (89511) can: can2: intr=93511 rxpkt=127564 txpkt=14 errflags=0x23400401 rxerr=0 txerr=0 rxovr=0 txovr=0 txdelay=0 wdgreset=0 errreset=0 1970-01-01 13:01:41 NZDT E (89531) can: can2: intr=93525 rxpkt=127592 txpkt=14 errflags=0x22400402 rxerr=0 txerr=0 rxovr=0 txovr=0 txdelay=0 wdgreset=0 errreset=0

2 1