- OvmsDev - Open Vehicles

Recommen
by Solterra 20 Jun '23

20 Jun '23

Hello, I have a couple of questions on the CAN poll TX framework. Is there a recommended method for adding a one-time CAN poll to the queue with the response to be processed by IncomingPollReply? What is the recommended method for adding or modifying obdii_polls after initialization? Thank you

3 5

Using the override keyword
by Michael Geddes 17 Jun '23

17 Jun '23

Hi all, So at my work, the main language I use is Delphi (so Object Pascal), and one of the things about Delphi is that you are forced to always be explicit about overriding virtual methods. (Missing out on 'override' directive indicates that you are Hiding (a warning) rather than overriding the virtual method). Since C++ now allows use of the override keyword now to explicitly say a method is overriding a virtual function, I have been adding that in all the code I use (or at least trying to). Firstly, it is a visual indicator that the method is, in fact, overriding a virtual function (which is not always obvious), but it also means that if a virtual method changes its signature in any way, you will get an error if an 'override' marked method no longer matches! I'm not sure what I'm after except just to bring it to people's attention in case they might have missed it, and find out how people view this. My latest pull-request has changed the signature of OvmsVehicle methods and I have added 'override' to all the places where this is overridden in derived Vehicle classes. //.ichael

1 0

Error: can: can1 watchdog inactivity timeout - resetting bus
by Solterra 12 Jun '23

12 Jun '23

Hello, I'm getting this error. However, I don't think I'm using can1... My vehicle uses can2. I don't think I've initialized can1. Any clues to help me debug? Do I need to do something to actively disable can1 during vehicle initialization? Thank you

1 1

Subaru Solterra
by Solterra 11 Jun '23

11 Jun '23

Any interest in adding support for Subaru Solterra?

4 9

CI ?
by Ludovic LANGE 08 Jun '23

08 Jun '23

Dear list, I've been playing a little with GitHub's automatic builds / CI for a few months, and I'm thinking about having it in master. The advantages I can think of would be: * Ability to "catch" early on any incompatibility we could introduce in a PR. Still in a transition period between ESP-IDFv3.3 - the official builds, and ESP-IDFv5.x (the future, I hope, once all the issues are ironed out) ; it can add some value in trying to build the firmware for different combinations, and thus with different compiler versions / libraries versions. * It could also be a backup build system for the nightly / releases firmwares. Hosting, compiling there is free of charge for public GitHub projects Possible concerns: * Very tied to GitHub's hosting and API - vendor lock-in However a) it's completely isolated in its own directory, and b) some of GitHub's competitors have a similar mechanism (GitLab, ...) In my tests, I'm using it to: * Ensure that the documentation always compile without any warning. Sometime, we have very small issues that can impact the visual rendering of the HTML, and this step can trigger when the compiler emits a warning (or error) * Ensure that the changes I'm doing are building without error for a "matrix" of different environments: o target: ESP32 (but could also be other processor of the Espressif portfolio, as supported by the build chains: -S2, -S3, -C2, -C3, -C6, -H2 ...) o ESP-IDF version : v3.3.4 (our current), v4.4 branch, v5.0, v5.0, v5.0.1, v5.0.2, v5.0 branch (could also use v5.1 branch and latest, but compile errors from time to time) o Mongoose version: 7.9, 7.10, 6.11 (our current) If you want to have a look, please check: * Some of the automated builds here https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions * A set of corresponding build recipes here https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/build-maste… * The output of a random build: o The log of commands: https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions/runs/519… o The build artefacts: https://github.com/llange/Open-Vehicle-Monitoring-System-3/suites/134194909… (NB: Do not flash ! Just an example :-)) I'd be happy to have some feedback about the interest (or not) to have this in master. For that the next plans would be: * Step1 : a PR (to be written) including all these config files in <root>/.github/workflows * Step2 : a configuration of our GitHub repo to : o activate the CI actions o After some time, mark some of these actions as "required" in PRs (Can be overriden of course, but will show the creator of the PR how to improve the PR and have it work across all the combinations of environments we aim to support) Thanks for your time. Regards,

2 1

Proposed changes to IncomingPollReply and IncomingPollError - before making a pull request
by Michael Geddes 02 Jun '23

02 Jun '23

Hi all, So I have some changes coming that depend heavily on this function signature change. What it is doing is taking the members of OvmsVehicle that are specific to the ISOTP (and VWTP) protocols and making the parameters to both IncomingPollReply and IncomingPollError. This way of doing it makes all the bits explicit parameters, which means a bunch more parameters passed on the stack. *Original*: - virtual void IncomingPollReply(canbus* bus, uint16_t type, uint16_t pid, const uint8_t* data, uint8_t length, uint16_t mlremain); - virtual void IncomingPollError(canbus* bus, uint16_t type, uint16_t pid, uint16_t code); *New:* virtual void IncomingPollReply(canbus* bus, uint32_t moduleidsent, uint32_t moduleid, uint16_t type, uint16_t pid, const uint8_t* data, uint16_t mloffset, uint8_t length, uint16_t mlremain, uint16_t mlframe, const OvmsPoller::poll_pid_t &pollentry); virtual void IncomingPollError(canbus* bus, uint32_t moduleidsent, uint32_t moduleid, uint16_t type, uint16_t pid, uint16_t code, const OvmsPoller::poll_pid_t &pollentry); The other way of achieving the same result would be to create a struct that contains these elements, and then to pass that as a const reference. Thoughts? If I need to make modifications to the signatures, I'd prefer to do it before I make the pull request. //.ichael

2 2

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