May 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

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

Subaru Solterra
by Solterra 11 Jun '23

11 Jun '23

Any interest in adding support for Subaru Solterra?

4 9

Minimally viable vehicle module
by Solterra 30 May '23

30 May '23

Hello, I'm trying to determine what the minimally viable vehicle module is? I'm implemented a handful of polling PIDs (SoC, Voltage, Current, Speed, Temperature, Odometer, etc.), and am starting to consider vehicle states and transitions. I'm wondering what I should target as a set good enough for a pull request to the main. Thank you

2 1

PR review requests + Mongoose 7 progress update
by Ludovic LANGE 30 May '23

30 May '23

Dear all, I have a few PRs pending, that are low-risk I believe, but are building block for the ESP-IDF4+ upgrade saga: * ESP-IDFv4+: fix cmake build of ovms_webserver #907 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/907> specific to ESP-IDF4+ builds (for the ovms_webserver component): o It reverts a previous PR on the component.mk / ESP-IDF3 build system of this component - which had a temporary workaround o It fixes the ESP-IDF4+ build system of this component with an approach better aligned to the ESP-IDF3 approach. * mongoose: identify dependencies, and generate a version header #909 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/909> o In order to help upgrade mongoose from 6.11 to 7.10, it introduces a new header with ability to compare mongoose version. It impacts both ESP3 and ESP4+ builds but should be low-impact Also pending: * fix documentation of arguments of tcpserver #900 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/900> straightforward update of the documentation * fix a few issues appearing when disabling/enabling components #910 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/910> o (specific to ESP-IDF4+) : make |ovms_plugins| compilable with or without |duktape| o |vehicle_hyundai_ioniq5| had issue when disabling webserver component o |vehicle_maxus_euniq56| had missing header when disabling webserver component If some of you can review any or all of these it'll help. Thank you ! Finally, progress is being made on the Mongoose v7.10 upgrade. You can have a look at the `upgrade-mongoose-7` branch <https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/upgrade-mon…>, or this (artificial) PR <https://github.com/llange/Open-Vehicle-Monitoring-System-3/pull/5/files> to show the diff. At the moment, SSH console is crashing. Not happy with that, and will happily read your comments about it. Regards,

1 0

Use of ovms_netlib component ?
by Ludovic LANGE 29 May '23

29 May '23

Dear all, While doing network-related things (/mainly trying to upgrade our Mongoose from 6.11 to 7.10 - more on that in a later mail/) I've seen this module (components/ovms_netlib). I can't easily figure how, and where it is used. Can someone please enlighten me ? Thanks in advance. Brest regards,

3 3

Review request
by Ludovic LANGE 19 May '23

19 May '23

Hi List, If possible, I'd like a peer-review / discussion of the following PRs: * ESP-IDF v4+: we do not have uxMutexesHeld any more #901 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/901> > > In ESP-IDF 3.3.x builds of OVMS, we're using a fork of ESP-IDF. In > this fork, FreeRTOS has been patched with > openvehicles/esp-idf@95e43fc > <https://github.com/openvehicles/esp-idf/commit/95e43fc2c4360f8126a0985bf037…> > to add a |uxMutexesHeld| field in |TaskStatus_t|. > > However, in the ESP-IDF >= 4 build we're using mainstream ESP-IDF > (for the moment), which does not include this field. > > So we adapt the display to handle both cases. > * ESP-IDF4+ : crash handler and boot status #902 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/902> > o error handling rework (|xt_set_error_handler_callback| is only > available in our ESP-IDF 3.3.4 fork.) > o |esp_task_wdt_get_trigger_tasknames()| not available (*feature > removed* from ESP-IDF4+ builds) TODO > o first steps to support other archs than XTensa in > |boot_data.crash_data| These are the *last 2 PRs* before being able to build with any of these ESP-IDF versions : 3.3.4-ovms, 4.4.4, 5.0, 5.0.1, branch-v5.0, branch-v5.1, latest - the last mile ! (One workaround PR <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/903> is pending to be able to *run* one of these new versions, preventing a crash at boot - but it needs a proper analysis first) Also, with these 2 PRs, we will be able to enable automatic builds on all these versions on master (using GitHub "Actions") - you can have a preview of what I mean here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions As we're slowly entering a period of transition between ESP-IDF 3.3.4-ovms and a more recent one (5.0.1 ?), we will need a way to ensure that the PRs / commits are OK across all these versions. Automatic builds can be configured to build on all targeted ESP-IDF versions, and can report their result back in the PRs, so that we can trap potential compilation errors before merging. (Especially as in the newer ESP-IDF versions, more and more warnings are treated as compilation errors) I also prepared a check for documentation errors using the same mechanism. Thanks in advance. Regards,

3 4

HTTP API Quotas on api.openvehicles.com
by Mark Webb-Johnson 18 May '23

18 May '23

Looking through the server logs, it is clear that (probably unintended) abuse of the HTTP/HTTPS API is a primary cause of overloading issues with the api.openvehicles.com <http://api.openvehicles.com/> server. Some users are issuing the same HTTP API request every 5 or 10 seconds (each time doing a complete expensive SSL negotiation). Accordingly, I’ve committed some simple code to try to limit the impact of this. This is configured on the api.openvehicles.com <http://api.openvehicles.com/> server as: On the first connection, each source IP is given an initial quota allowance of 12 requests. Every minute, the quota is topped up with another 3 requests (subject to a maximum quota of 24). Every HTTP/HTTPS API call reduces the quota by 1. Should the quota hit zero, a 20 second delayed 429 (too many requests) response will be sent. If no requests are seen for 5 minutes, the quota is cleared. This allows reasonable use of the API, while fairly sharing the limited resources of this free service. I am only seeing six users currently rate limited by these new quotas, while the CPU utilisation has gone from 100% of one core (pre-quota) to ~50% now (with quota). This implies that just those six users were consuming almost half the server resources. Anecdotally, things feel much more snappier now for API v2 users, with server connections completing in under a second. Regards, Mark

1 0