June 2023 - OvmsDev - Open Vehicles

Warning in Duktape
by Michael Geddes 09 Aug '24

09 Aug '24

There's an unused variable 'dcc' warning in the below code. It seems that the 'Perform the callback' is not being 'performed! Is this deliberate? //.ichael void DukOvmsCommandRegisterRun(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv) { ESP_LOGD(TAG, "DukOvmsCommandRegisterRun(%s)",cmd->GetName()); auto it = MyDuktape.m_cmdmap.find(cmd); if (it == MyDuktape.m_cmdmap.end()) { ESP_LOGE(TAG, "Command '%s' cannot be found in registry",cmd->GetName ()); return; } else { DuktapeConsoleCommand* dcc = it->second; // Perform the callback } }

3 6

wolfssl has been converted to a git submodule
by Ludovic LANGE 19 Feb '24

19 Feb '24

Dear all, The PR https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/887 which converts wolfssl to a git submodule has been merged to master. For those that build / sync their trees manually, please ensure that you do `git submodule update --init --recursive` after the git pull, so that you can properly retrieve the submodule. You can confirm that everything is OK by doing: $ git submodule status 7b953e7ebb440ce9461ee469159c3759450e7c98 components/mongoose/mongoose (6.2-882-g7b953e7) c05f6c7530a8670e3d0ffdf04ee4cecb2d3b0496 components/wolfssh/wolfssh (v1.4.10-stable) 2d5a0ccae50a2ea32fc933d707b465520cc90011 components/wolfssl/wolfssl (v4.7.0-stable-5-g2d5a0ccae) 7c3878f8302c0e84578a67473e49e60bc6b3ada7 components/zip/libzip (rel-1-5-1-60-g7c3878f) d6bcf4ca4d02479f058fff44cfd171f928148179 components/zip/zlib (v1.2.11-65-gd6bcf4c) It should print (3rd line) a version of v4.7.0-stable-5-g2d5a0ccae. If instead you see: $ git submodule status 7b953e7ebb440ce9461ee469159c3759450e7c98 components/mongoose/mongoose (6.2-882-g7b953e7) c05f6c7530a8670e3d0ffdf04ee4cecb2d3b0496 components/wolfssh/wolfssh (v1.4.10-stable) -2d5a0ccae50a2ea32fc933d707b465520cc90011 components/wolfssl/wolfssl 7c3878f8302c0e84578a67473e49e60bc6b3ada7 components/zip/libzip (rel-1-5-1-60-g7c3878f) d6bcf4ca4d02479f058fff44cfd171f928148179 components/zip/zlib (v1.2.11-65-gd6bcf4c) then you need to use `git submodule update --init --recursive` Let me know if it's not working according to the plan. Regards,

3 3

Fwd: [Action Required] Update your apps to the latest Firebase Cloud Messaging APIs and SDKs
by Michael Balzer 09 Jan '24

09 Jan '24

Time for another Google API deprecation. It seems we'll need to update the Android App & possibly the server now to the FCM API for push notifications, the old GCM API will stop working in June 2024. Anyone volunteering to take care of this? Regards, Michael -------- Weitergeleitete Nachricht -------- Betreff: [Action Required] Update your apps to the latest Firebase Cloud Messaging APIs and SDKs Datum: Tue, 20 Jun 2023 13:26:22 -0700 Von: Firebase <firebase-noreply(a)google.com> Antwort an: Firebase <firebase-noreply(a)google.com> An: dexter(a)expeedo.de Mandatory Service Announcement from Firebase Take action before June 20, 2024 to continue receiving support. Firebase Console <https://notifications.google.com/g/p/ACUgQrEqj5I8-oiq75nsyLmVgMI_2P_O30pr9Z…> Hi Michael, We’re writing to let you know that starting *June 20, 2024* the legacy Firebase Cloud Messaging (FCM) APIs will be discontinued. What do you need to know? On *June 20, 2024,* we’re reducing the number of Firebase Cloud Messaging (FCM) legacy register APIs and legacy send APIs that provide similar functionality. This step will allow us to provide you with a more consistent experience and align with Google security standards to improve security, reliability and performance. Because of these API decommissions, some already-deprecated SDKs and features will stop working after *June 20, 2024.* Please consult the tables below to find which Firebase Cloud Messaging (FCM) APIs and corresponding services/SDKs/features will be discontinued and replaced with new alternatives. *Discontinued Send API* *Decommissioned service* *New alternative* *Legacy HTTP Protocol* Sending messages via the Legacy HTTP API. Send messages via the HTTP v1 API. *XMPP Protocol* Sending upstream and downstream messages via the XMPP API. Send downstream messages via the HTTP v1 API. Send upstream messages via HTTP/gRPC <https://notifications.google.com/g/p/ACUgQrFKp0BdXKuz3_mUi3W9wdl6DV3Ib_q0Hn…> directly from the App to your server. *Batch send API* Including multiple send requests in a single HTTP request to FCM known as Batch Send. Send messages via the HTTP v1 API, which has been optimized for fanout performance *Discontinued Register API* *Decommissioned SDK* *New alternative* *GCM register API* Google Cloud Messaging(GCM) SDKs (deprecated in 2018). Latest FCM Android SDK. *Legacy Web register API* FCM JS SDK version<7.0.0 (deprecated in 2019) Latest FCM JS SDK. *Instance ID Server API for Web* No SDK related to this API. Latest FCM JS SDK. *Discontinued Feature* *Decommissioned service* *New alternative* *Server keys* Authenticating requests with server keys. Authenticate requests with access tokens generated from authorized service accounts <https://notifications.google.com/g/p/ACUgQrE8LxWKrfZvL3R5hoSruQL4An9Vg5kFcD…> *iOS Direct Channel* Sending messages via FCM’s direct channel to iOS devices while they are running in the foreground. All iOS messages will be sent via APNS channel. What do you need to do? Take the following actions before *June 20, 2024*, to ensure that you have access to the latest supported features and to reduce the risk of future decommissions affecting your usage: * *Follow the instructions described in *Firebase FAQ <https://notifications.google.com/g/p/ACUgQrF1q42xLDBDWvEr5RHaOfbnfKhv0UdWXB…> to migrate your individual APIs. * *Update to the latest versions of Firebase SDKs*. *Platform* *Recommended FCM SDK version* Android >= 23.1.2 iOS >= 10.10.0 Web (Javascript) >= 9.22.1 Your Firebase project(s) that use Firebase Cloud Messaging APIs are listed below: * MyOvmsServer (1043773844049) <https://notifications.google.com/g/p/ACUgQrEotRQKxV6LgEoXckEV9bLkUuhj9b1dUE…> o /Your recent usage of impacted APIs/features: Server Keys/ o /Your recent usage of impacted APIs/features: Legacy HTTP protocol/ We’re here to help If you have any questions, please review the Firebase FAQs <https://notifications.google.com/g/p/ACUgQrF1q42xLDBDWvEr5RHaOfbnfKhv0UdWXB…>. Thanks, Todd on behalf of the Firebase team *Was this information helpful?* Yes <https://notifications.google.com/g/p/ACUgQrG_D9izaxqaPAZL66peR0D-yHGGWiULfq…> Neutral <https://notifications.google.com/g/p/ACUgQrFnFdXuJ_VF6ChjiUeTeV5elzVrPymaFM…> No <https://notifications.google.com/g/p/ACUgQrFb7NDlSkpL4nuGR0g71bgiRuj39SdywV…> You have received this mandatory service announcement to update you about important changes to Firebase or your account. © 2023 Google LLC 1600 Amphitheatre Parkway Mountain View, CA 94043 USA <#> -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

3 4

Strange issues with Car GPS accuracy.
by Michael Geddes 14 Jul '23

14 Jul '23

Hi all, I'm having a bunch of weird things going on which seem correlated to having the OVMS running. I'm not convinced of causation yet. My car's Nav system is drifting out majorly (like by >100m) and then seems to stay out. This causes major distractions as the nav system keeps giving me warnings about going down one-way roads and it makes the navigation 'interesting' to use. I also noticed that Android Auto location was frozen in one place, so I assumed this was coming from the car - or meant to be anyway. I reduced the polling rate (new work I'm doing) slightly and this freezing no longer happens. (To 3 speed queries per second). But the drifting out on the Navigation still happens... but then not on AA!? Very very weird. If I unplug the OVMS from the OBD port (as I'm driving) it seems to (but not immediately - after a minute or so) correct itself. It's hard to confirm this is directly resulting .. but it seems to be? I turned off my ECU2OBD which should mean that it is resorting to 1 per second POLL with a low throttle value. I'll run with some logs to make sure this is what is happening.. but it still seems that this hasn't stopped this issue from happening. I've tried turning the GSM power off. No result. Another note: I seem to have stopped getting anything near regular updates from the OVMS GPS. Every now and again it gets a successful change come through. Still working on diagnosing that.. maybe it's related? Any thoughts / help would be useful. //.ichael

4 9

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

Attempting to ssh in too soon after a reboot causes an abort() from esp_sha_read_digest_state()
by Craig Leres 26 Jun '23

26 Jun '23

[third attempt, apparently my opendkim sendmail milter was borked and needed to be restarted...] I updated to 3.3.003-518-gb6c10a59 a few days ago and noticed if I'm too impatient trying to ssh into the module after rebooting, it crashes. I suspect this is easy to reproduce. Craig =============================================================== OVMS# boot Last boot was 501 second(s) ago Time at boot: 2023-06-21 19:49:18 PDT This is reset #8 since last power cycle Detected boot reason: EarlyCrash (12/12) Reset reason: Exception/panic (4) Crash counters: 1 total, 1 early Last crash: abort() was called on core 1 Current task on core 0: IDLE0, 524 stack bytes free Current task on core 1: OVMS NetMan, 1208 stack bytes free Backtrace: 0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389 Version: 3.3.003-518-gb6c10a59-dirty/ota_1/main (build idf v3.3.4-849-g6e214dc33 Jun 20 2023 21:30:05) Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM SIM7600 =============================================================== ice 104 % git describe 3.3.003-518-gb6c10a59 ice 105 % cat backtrace.sh #!/bin/sh PATH=/usr/local/xtensa-esp32-elf/bin:${PATH} export PATH cd ${HOME}/src/OVMS.V3 || exit 1 dn=`/bin/pwd` (set -x ; xtensa-esp32-elf-addr2line -e build/ovms3.elf $*) | sed -e s,^${dn}/,, ice 106 % !./ ./backtrace.sh 0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389 + xtensa-esp32-elf-addr2line -e build/ovms3.elf 0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/hwcrypto/sha.c:272 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/port/esp_sha256.c:349 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_cli.c:3894 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 main/ovms_netmanager.cpp:1198 main/ovms_netmanager.cpp:1198

3 2

CAN message throughput
by Solterra 25 Jun '23

25 Jun '23

Do we have an idea what the polling throughput is? I haven't really dug into the poller code yet, but I suspect I might be overloading the poller. Responses aren't coming in when I expect them. Is there any notification when a Ticker takes more than one second? Is it possible for a ticker to be missed. For example, if ticker#9 takes more than one second, does it move on to ticker #11, possibly skipping ticker#10? Thank you

2 2

Looking for a twizy battery rebuild
by Jérôme Nicolle 24 Jun '23

24 Jun '23

Hi ! I hope it's OK to post this here. Sorry for the inconvenience if it is not. I'm looking for updated informations regarding modified batteries for the Twizy. Mine is down to about 4.5kWh (fully owned) after 8 years in service. What capacity could we reasonably reach with newer cells ? With plumetting prices for the cells, would there be anyone (preferably close to France) from whom I could buy all the required modules (including Twizy Virtual BMS), ready to fit in the battery case, or with a new case ? Thanks ! -- Jérôme Nicolle +33 6 19 31 27 14

2 1

Attempting to ssh in too soon after a reboot causes an abort() from esp_sha_read_digest_state()
by Craig Leres 23 Jun '23

23 Jun '23

[second attempt, my first message never propagated...] I updated to 3.3.003-518-gb6c10a59 today and noticed if I'm too impatient trying to ssh into the module after rebooting, it crashes. I suspect this will be easy to reproduce. Craig =============================================================== OVMS# boot Last boot was 501 second(s) ago Time at boot: 2023-06-21 19:49:18 PDT This is reset #8 since last power cycle Detected boot reason: EarlyCrash (12/12) Reset reason: Exception/panic (4) Crash counters: 1 total, 1 early Last crash: abort() was called on core 1 Current task on core 0: IDLE0, 524 stack bytes free Current task on core 1: OVMS NetMan, 1208 stack bytes free Backtrace: 0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389 Version: 3.3.003-518-gb6c10a59-dirty/ota_1/main (build idf v3.3.4-849-g6e214dc33 Jun 20 2023 21:30:05) Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM SIM7600 =============================================================== ice 104 % git describe 3.3.003-518-gb6c10a59 ice 105 % cat backtrace.sh #!/bin/sh PATH=/usr/local/xtensa-esp32-elf/bin:${PATH} export PATH cd ${HOME}/src/OVMS.V3 || exit 1 dn=`/bin/pwd` (set -x ; xtensa-esp32-elf-addr2line -e build/ovms3.elf $*) | sed -e s,^${dn}/,, ice 106 % !./ ./backtrace.sh 0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389 + xtensa-esp32-elf-addr2line -e build/ovms3.elf 0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/hwcrypto/sha.c:272 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/port/esp_sha256.c:349 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_cli.c:3894 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 main/ovms_netmanager.cpp:1198 main/ovms_netmanager.cpp:1198

1 0

Attempting to ssh in too soon after a reboot causes an abort() from esp_sha_read_digest_state()
by Craig Leres 22 Jun '23

22 Jun '23

I updated to 3.3.003-518-gb6c10a59 today and noticed if I'm too impatient trying to ssh into the module after rebooting, it crashes. I suspect this will be easy to reproduce. Craig =============================================================== OVMS# boot Last boot was 501 second(s) ago Time at boot: 2023-06-21 19:49:18 PDT This is reset #8 since last power cycle Detected boot reason: EarlyCrash (12/12) Reset reason: Exception/panic (4) Crash counters: 1 total, 1 early Last crash: abort() was called on core 1 Current task on core 0: IDLE0, 524 stack bytes free Current task on core 1: OVMS NetMan, 1208 stack bytes free Backtrace: 0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389 Version: 3.3.003-518-gb6c10a59-dirty/ota_1/main (build idf v3.3.4-849-g6e214dc33 Jun 20 2023 21:30:05) Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM SIM7600 =============================================================== ice 104 % git describe 3.3.003-518-gb6c10a59 ice 105 % cat backtrace.sh #!/bin/sh PATH=/usr/local/xtensa-esp32-elf/bin:${PATH} export PATH cd ${HOME}/src/OVMS.V3 || exit 1 dn=`/bin/pwd` (set -x ; xtensa-esp32-elf-addr2line -e build/ovms3.elf $*) | sed -e s,^${dn}/,, ice 106 % !./ ./backtrace.sh 0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389 + xtensa-esp32-elf-addr2line -e build/ovms3.elf 0x400891b7 0x40089451 0x40268a11 0x40244aea 0x4023e892 0x40240287 0x4024f6bb 0x40240556 0x40240581 0x4012aaa0 0x4012c150 0x4012d89d 0x4012ddc3 0x4012a2aa 0x4011e2eb 0x4011e389 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/hwcrypto/sha.c:272 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/port/esp_sha256.c:349 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_cli.c:3894 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 main/ovms_netmanager.cpp:1198 main/ovms_netmanager.cpp:1198

1 0