- OvmsDev - Open Vehicles

Android App release 3.19.1
by Michael Balzer 24 Dec '21

24 Dec '21

I've just released version 3.19.1 of the Android App on the Google Play Store. *Version 3.19.1 (2021-12-24)* * Add Renault Kangoo * Add Maxus eDeliver 3 * Add BMW i3 * Nissan Leaf image improvements * Add charge speed to battery info page * Twizy: hide charge power input & loss (unavailable) Thanks to all contributors! You can also download the APK file from: https://github.com/openvehicles/Open-Vehicle-Android/tree/master/release Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

3.2.018 release
by Mark Webb-Johnson 16 Dec '21

16 Dec '21

We need to get the v3.3 release ready for release now, as the new v3.3 hardware is about to enter production and the factory needs the firmware. Accordingly, I suggest: I have already updated the for-v3.3 branch with all the recent changes from v3.2. We now (today/tomorrow) release the current v3.2 branch as tag 3.2.018, OTA release. This would be the (hopefully) last v3.2 release. After release of that, we branch off master to a v3.2 branch, for historical purposes (and if we need it for anything). We then merge back for-v3.3 into the master branch and start working through the usual daily builds for that to get it ready for production. I think there is still some work to do on pouring the plugins, but the core code (and in particular new modem support) should be ok now. I think we will need to investigate an approach for dual builds for v3.3-or-later and pre-v3.3 hardware, to take advantage of the new ESP32 rev3 chips. I think those will require a different sdkconfig. We can do that automatically in the OTA system, by building the URL based on the ESP32 platform revision. Should we do that with the v3.3 release (even if the builds are for the moment the same), or at a later date? Regards, Mark.

3 25

Another readthedocs dependency issue
by Mark Webb-Johnson 12 Dec '21

12 Dec '21

Got another readthedocs dependency issue. Seems the mistune package has been updated from 0.8.4 to 2.0.0, and we now have compatibility issues with readthedocs. The error is: AttributeError: module 'mistune' has no attribute ‘BlockGrammar' ovms build #15510497 <https://readthedocs.org/projects/ovms/builds/15510497/> Similar to the docutils<0.18, I have added a requirements.txt to mistune <2.0.0 to workaround the issue. These python developers really need to learn to follow Linus’s mantra of ’never break user space’. Regards, Mark.

1 0

for-v3.3: ota flash http crashes
by Michael Balzer 23 Nov '21

23 Nov '21

There is another fatal issue with OvmsSyncHttpClient besides the issue with running in the mongoose context: OTA updates are no longer possible. When flashing via HTTP, the OvmsSyncHttpClient tries to allocate memory for a full firmware image, which of course fails: OVMS# ota flash http Current running partition is: factory Target partition is: ota_0 Download firmware from ovms.dexters-web.de/firmware/ota/v3.1/edge/ovms3.bin to ota_0 Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled. Core 1 register dump: PC : 0x4022438b PS : 0x00060a30 A0 : 0x802245cd A1 : 0x3ffe9c70 A2 : 0x00000000 A3 : 0x3ffe6f5c A4 : 0x00000001 A5 : 0xffffffff A6 : 0x3fabad7c A7 : 0xff000000 A8 : 0x00000000 A9 : 0x3ffe9c50 A10 : 0x00000000 A11 : 0x3ffe6f5c A12 : 0x00000001 A13 : 0x0000000a A14 : 0x00000037 A15 : 0x00000057 SAR : 0x00000018 EXCCAUSE: 0x0000001d EXCVADDR: 0x00000000 LBEG : 0x4008b179 LEND : 0x4008b19b LCOUNT : 0xffffffff ELF file SHA256: 94a8e191baae33a5 Backtrace: 0x4022438b:0x3ffe9c70 0x402245ca:0x3ffe9c90 0x40132f93:0x3ffe9cc0 0x40132e51:0x3ffe9d10 0x40133609:0x3ffe9d40 0x402e7472:0x3ffe9d70 0x4010e229:0x3ffe9d90 0x4010fbd5:0x3ffe9dd0 0x40110015:0x3ffe9e00 0x401102de:0x3ffe9e70 0x4010c51a:0x3ffe9ed0 0x400f5a4f:0x3ffe9ef0 0x400f5afd:0x3ffe9f40 Rebooting... 0x4022438b is in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_copy(char*, char const*, unsigned int) (/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/esp32-psram/libstdc++-v3/include/bits/char_traits.h:243). 0x402245ca is in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::reserve(unsigned int) (/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/esp32-psram/libstdc++-v3/include/bits/basic_string.tcc:298). 0x40132f93 is in OvmsSyncHttpClient::ConnectionHeaders(mg_connection*) (/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_http/src/ovms_http.cpp:381). 376 else 377 { 378 if (header.compare(0,15,"Content-Length:") == 0) 379 { 380 m_bodysize = atoi(header.substr(15).c_str()); *381 m_body.reserve(m_bodysize+1);* 382 } 383 else if (header.compare(0,5,"HTTP/") == 0) 384 { 385 size_t space = header.find(' '); 0x40132e51 is in OvmsSyncHttpClient::ConnectionData(mg_connection*, unsigned char*, unsigned int) (/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_http/src/ovms_http.cpp:316). 311 data += len; 312 consumed += len; 313 len = 0; 314 } 315 316 ConnectionHeaders(nc); 317 } 318 319 if (! m_inheaders) 320 { 0x40133609 is in OvmsSyncHttpClient::MongooseCallback(mg_connection*, int, void*) (/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_http/src/ovms_http.cpp:124). 119 m_mgconn = NULL; 120 } 121 break; 122 123 case MG_EV_RECV: 124 mbuf_remove(&nc->recv_mbuf, ConnectionData(nc,(uint8_t*)nc->recv_mbuf.buf, nc->recv_mbuf.len)); 125 break; 126 127 default: 128 break; Can we switch back to using the old async client? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 6

Readthedocs broken
by Mark Webb-Johnson 15 Nov '21

15 Nov '21

The readthedocs service we use appears to be broken at the moment. Issue reported here (and in a dozen or more other places): https://github.com/readthedocs/readthedocs.org/issues/8616#issuecomment-955… <https://github.com/readthedocs/readthedocs.org/issues/8616#issuecomment-955…> There is a workaround, to pin the docutils<0.18 version, but I think better to just wait for readthedocs to fix the issue as it is affecting so many builds. If they haven’t fixed it in the next few days then I’ll try to apply the workaround. Regards, Mark.

3 3

OVMS v3.3 Certified
by Mark Webb-Johnson 09 Nov '21

09 Nov '21

Guys, I am overjoyed to be able to report that we sailed through certification, with no changes required to our design. CE, and FCC. Bluetooth, wifi, GPS, 2G, 3G, 4G, ROHS, and EMC. It will take another couple of weeks to get the paperwork through, but the hurdle seems over and hardware design is finalised. We can now move on to production (which is helpful, as almost everywhere is running very low on OVMS stock). The pressure is now on finalising the v3.3 firmware to match. Regards, Mark.

2 2

Update from master
by Shane ＠ Kilve Engineering 02 Nov '21

02 Nov '21

Hi all I ve just done an update from ovms master and gone to do a build and got given lots of options to select? Now my builds won’t connect to v2 server Regards Shane shane@Shanes-MacBook-Pro OVMS.V3 % make Toolchain path: /Users/shane/.espressif/tools/xtensa-esp32-elf/1.22.0-97-gc752ad5-5.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc Toolchain version: crosstool-ng-1.22.0-97-gc752ad5 Compiler version: 5.2.0 GENCONFIG * * Restart config... * * * System Options * Stack size for command execution (OVMS_SYS_COMMAND_STACK_SIZE) [6144] 6144 Task priority for command execution (OVMS_SYS_COMMAND_PRIORITY) [5] (NEW) Queue size for file logging (OVMS_LOGFILE_QUEUE_SIZE) [100] 100 Task priority for file logging (OVMS_LOGFILE_TASK_PRIORITY) [2] 2 * * Include the GPL licensed MONGOOSE networking library (web server, etc) * Include the GPL licensed MONGOOSE networking library (web server, etc) (OVMS_SC_GPL_MONGOOSE) [Y/n/?] y Enable MONGOOSE filesystem support (MG_ENABLE_FILESYSTEM) [Y/n/?] y Enable MONGOOSE directory listing support (MG_ENABLE_DIRECTORY_LISTING) [Y/n/?] y Enable MONGOOSE SSL/TLS support (MG_ENABLE_SSL) [Y/n/?] y Select the MONGOOSE SSL/TLS library to use > 1. mbedTLS (MG_SSL_IF_MBEDTLS) (NEW) 2. WolfSSL (MG_SSL_IF_WOLFSSL) (NEW) choice[1-2?]: 2 Enable MONGOOSE debug logging (MG_ENABLE_DEBUG) [N/y/?] n * * Library Support * Select the OVMS javascript library to use 1. No javascript support (OVMS_SC_JAVASCRIPT_NONE) > 2. Use the MIT licensed DUKTAPE library (OVMS_SC_JAVASCRIPT_DUKTAPE) choice[1-2?]: 2 Include the GPL licensed WOLFSSH and WOLFSSL libraries (ssh server) (OVMS_SC_GPL_WOLF) [Y/n/?] y Include ZIP archive support (OVMS_SC_ZIP) [Y/n/?] y JavaScript (DukTape) task stack size (OVMS_SC_JAVASCRIPT_DUKTAPE_STACK) [12288] 12288 JavaScript (DukTape) task queue size (OVMS_SC_JAVASCRIPT_DUKTAPE_QUEUE_SIZE) [40] 40 JavaScript (DukTape) task priority (OVMS_SC_JAVASCRIPT_DUKTAPE_PRIORITY) [3] 3 Enable Javascript (Duktape) dedicated heap memory management (OVMS_SC_JAVASCRIPT_DUKTAPE_HEAP_UMM) [Y/n/?] (NEW) Javascript/Duktape default size of dedicated memory chunk (KB) (OVMS_SC_JAVASCRIPT_DUKTAPE_HEAP_UMM_DEFAULTSIZE) [512] (NEW) Javascript/Duktape size of a memory block (bytes) (OVMS_SC_JAVASCRIPT_DUKTAPE_HEAP_UMM_BLOCKSIZE) [32] (NEW) # # configuration written to /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/sdkconfig # App "ovms3" version: 3.2.014-1137-g8bc1c599-dirty Python requirements from /Users/shane/esp-idf/requirements.txt are satisfied. Building partitions from /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/partitions.csv... CC build/bootloader/bootloader_support/src/bootloader_clock.o CC build/bootloader/bootloader_support/src/bootloader_common.o CC build/bootloader/bootloader_support/src/bootloader_flash.o CC build/bootloader/bootloader_support/src/bootloader_flash_config.o CC build/bootloader/bootloader_support/src/bootloader_init.o

2 1

UDS write by identifier help
by Shane ＠ Kilve Engineering 25 Oct '21

25 Oct '21

Hi all, Can anyone give me some help trying to write data to the TPMS ecu? I can read for example FL tyre using can can1 tx standard 735 03 22 e0 10 00 00 00 00 (FL id e010 FR e020 etc.) And get back 07 62 e0 10 80 2d b9 d4 I have confirmed that the tyre id is "80 2d b9 d4” with a tmps reader wireless at the wheel I have then done a session control with can can1 tx standard 735 02 10 03 00 00 00 00 00 And get back 06 50 03 00 32 01 f4 00 So that looks ok ? So I then try can can1 tx standard 735 07 2e e0 10 40 ea 85 ce (the new id) And get back 03 7f 2e 7f So ive tried issuing can can1 tx standard 735 02 27 01 00 00 00 00 00 But get no response?? any pointers? p.s. do I also need to be sending tester present to the ecu? Or does the fact im doing a session control take care of this? Regards Shane

2 3

Newbie Git question
by Michael Iimura 24 Oct '21

24 Oct '21

Since my OVMS module automatically updated to 3.2.017, I want to rebuild my RAV4 EV vehicle module based on this version. I have pushed the button in my branch on GitHub to bring it up to that version, but I don't know how to get it down into the Mingw32 environment on my PC so I can recompile it and upload it to my OVMS device. What command line git commands will do this? Thanks, - Mike

5 4

Urgent TLS root certificate issue (Let's Encrypt)
by Michael Balzer 12 Oct '21

12 Oct '21

Everyone, the DST root certificate we include (DST Root CA X3) expires on September 30, i.e. in two days. OVMS# tls trust list DST Root CA X3 length 1200 bytes 1200 byte certificate: DST Root CA X3 cert. version : 3 serial number : 44:AF:B0:80:D6:A3:27:BA:89:30:39:86:2E:F8:40:6B issuer name : O=Digital Signature Trust Co., CN=DST Root CA X3 subject name : O=Digital Signature Trust Co., CN=DST Root CA X3 issued on : 2000-09-30 21:12:19 * expires on : 2021-09-30 14:01:15* signed using : RSA with SHA1 RSA key size : 2048 bits basic constraints : CA=true key usage : Key Cert Sign, CRL Sign AFAICT, this root certificate is currently used by the OVMS to validate Let's Encrypt certificates. * https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ * https://letsencrypt.org/docs/certificate-compatibility/ Unfortunately, we missed adding the followup LE root certificate "ISRG Root X1" in time. I've just added that certificate to our builtin certificate repository, but it's too late now to roll out a "main" update in time (isn't it?). So, to prevent losing TLS connectivity with LE servers, users need to manually add the ISRG Root X1 certificate to their TLS repositories. I've added a section on this to our user manual: * https://docs.openvehicles.com/en/latest/userguide/ssltls.html If users contact you, point them to that page. We probably should also remove the expired DST root certificate after September 30. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

6 38