- OvmsDev - Open Vehicles

Zoe
by Mark Webb-Johnson 02 Feb '20

02 Feb '20

Anyone know the status of Renault Zoe support now? It seems our code is feature rich in comments, but most of the functionality is commented out. I am getting quite a lot of enquires regarding this. Regards, Mark

2 2

Ready for 3.2.009
by Mark Webb-Johnson 02 Feb '20

02 Feb '20

Seems we are ready for another release. I made a number of fixes yesterday, and maybe able to make a few more today, then I am done and ready to release 3.2.009. Anything else to put in this? Regards, Mark

4 9

Double updates - Normal?
by Greg D. 31 Jan '20

31 Jan '20

Hi folks, I moved my car's OVMSv3 to the Edge firmware a bit ago, and notice that every update seems to be doubled. Besides being a bit annoying, it ends up without a previous version to fall back to since both partitions end up being the same. Is this behavior normal? Can it be prevented? I'm only on Edge because of the bug in obd2ecu, and will probably move to EAP after we get an EAP build with the fix in it. Is the behavior the same there? I used to be on Main, and all seemed fine there. Thanks, Greg

5 14

Stock
by Mark Webb-Johnson 21 Jan '20

21 Jan '20

FYI: Kits and Cables are back in stock. It was tight, but the factory came through and got these done before the Chinese New Year holiday shut everything down. Fasttech have them already, and managed to fulfil outstanding orders over the weekend. They are now closed for the Chinese New Year holidays, and will resume shipping around 31st January. Shipment to OpenEnergyMonitor is on the way. They should have the stock thursday/friday this week. Regards, Mark.

1 0

xTimerCreate <10ms
by Mark Webb-Johnson 21 Jan '20

21 Jan '20

I’ve received a bug report that the Tesla Roadster vehicle module is crashing when the digital speedo option is used (with latest 3.2.008 firmware): #324 Tesla Roadster digital speedo crashing on latest firmware <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/324> Backtrace is: 0x4008b72f is in invoke_abort (esp-idf/components/esp32/panic.c:156). 0x4008b9c9 is in abort (esp-idf/components/esp32/panic.c:171). 0x40097765 is in xTimerCreate (esp-idf/components/freertos/timers.c:385). 0x4018ccaa is in OvmsVehicleTeslaRoadster::IncomingFrameCan1(CAN_frame_t*) (components/vehicle_teslaroadster/src/vehicle_teslaroadster.cpp:375). 0x4015ba95 is in OvmsVehicle::RxTask() (components/vehicle/vehicle.cpp:1138). 0x4027fee2 is in OvmsVehicleRxTask(void*) (components/vehicle/vehicle.cpp:940). and the abort is called by an assert: configASSERT( ( xTimerPeriodInTicks > 0 ) ); In our default sdkconfig configurations, we have: CONFIG_FREERTOS_HZ=100 so I think that means there are 0.1 ticks per millisecond, and setting any timer <10ms will trigger the assertion crash. I have no idea why it wasn’t a problem when this was written (a few years ago), but the crash is definitely caused by this. Maybe at some time ago we disabled abort on assertions? Anyway, reviewing the code there are a few places we use xTimerCreate and this can happen. Most are hard-coded times greater than 10ms. The remaining ones are: ovms_events.cpp in the SignalRaise function vehicle_teslaroadster.cpp in two places I changed both of these to avoid the issue (enforce ticks to be >= 1). Just beware that we can’t have timers less than 10ms with our current configuration. Regards, Mark.

1 0

Fasttech kit status "discontinued"
by Michael Balzer 15 Jan '20

15 Jan '20

Mark, Fasttech now have tagged both kits as "discontinued", and tell users this: https://www.openvehicles.com/comment/6167#comment-6167 /> "We are really sorry to write here that the item 9642829 had been discontinued and we can't find the other supplier, so it may not be in our stock again. Sorry for the inconvenience."/ Do you have any info on this? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 1

Scripting - missing integrations
by Mark Webb-Johnson 10 Jan '20

10 Jan '20

Michael’s work has brought up an issue that we seem to be missing some javascript integrations. We have: OvmsCommand OvmsLocation OvmsMetrics OvmsVehicle PubSub (to ovms events) Obvious ones missing are: OvmsConfig OvmsWebServer I can do OvmsConfig, but one question: Do we allow scripts access to protected config values? I think not (as that would void the entire protection system with a ’script eval JSON.print(…)', but is a limitation). Comments? It would be interesting to see scripts extend the OvmsWebServer, so urls could be mapped to scripts - but not sure of the practical use of that vs plugins. Regards, Mark.

2 3

iOS App v1.8.2
by Mark Webb-Johnson 07 Jan '20

07 Jan '20

iOS App v1.8.2 has now been approved by Apple for TestFlight beta testing. Public link is here: https://testflight.apple.com/join/05tfPlqR <https://testflight.apple.com/join/05tfPlqR> This addresses the compatibility issue with iOS 13 and APNS push notification registration. Regards, Mark.

2 4

Scripting: Duktape update to version 2.5.0
by Craig Leres 03 Jan '20

03 Jan '20

Hum... I haven't tried to build for a week or so and am now getting a error from the new duktape: ice 840 % gmake Toolchain path: /home/ice/u0/leres/bin/xtensa-esp32-elf-gcc Toolchain version: crosstool-ng-1.22.0-80-g6c4433a5 Compiler version: 5.2.0 Python requirements from /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/requirements.txt are satisfied. App "ovms3" version: 3.2.008-34-gd1a0e982-dirty CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/duktape/src/duktape.o duk_js_call.c: In function 'duk__handle_call_raw': duk_js_call.c:2268:32: error: 'func' may be used uninitialized in this function [-Werror=maybe-uninitialized] cc1: some warnings being treated as errors gmake[1]: *** [/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/make/component_wrapper.mk:290: src/duktape.o] Error 1 gmake: *** [/home/ice/u0/leres/esp/esp-idf/make/project.mk:552: component-duktape-build] Error 2 I looked at the code and don't see the problem: /* XXX: native funcptr could come out of call setup. */ if (func) { rc = ((duk_hnatfunc *) func)->func(thr); // 2268 } else { duk_tval *tv_func; My guess is my toolchain is too old? I'm using 1.22.0-80-g6c4433a5. Looking here: https://github.com/espressif/crosstool-NG Should I switch to the esp-1.23.x branch? Or am I just SOL because you're all using a binary release toolchain and espressif hasn't released the source to the crosstool-NG they're using to build it? Craig

2 7

Crash
by Tamás Kovács 02 Jan '20

02 Jan '20

Hi, I have a problem, some time my OVMS crash with the fw version 3.2.008-33-g0b7d4a9c-dirty. I use the Mitsubishi(trio) vehicle (Peugeot iOn) The crash log from (dexters-web.de) attached, and a2l result is attached.

2 1