- OvmsDev - Open Vehicles

Request For Comments - Wireguard VPN
by Ludovic LANGE 05 May '23

05 May '23

Dear list, A few months ago I created https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752 to explore WireGuard VPN support ; which leaded me to add ESP-IDFv5 support to OVMS. Now that this ESP-IDFv5 support is added (in my branch, and it is in the progress of getting included in master - with the help and the testing of everybody here), I've resumed my exploration of adding support for WireGuard VPN to OVMS. It's now ready for comments, you can now check: * a new branch here https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/752-wiregua… * a DRAFT PR here https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/882 if you want to explore and test this VPN support for OVMS. My own use case for this feature is : * Security : I would like my module to be unreachable from the public Internet. This is a first step. * Practicality : I can reach my module with a single IP address / name that is part of my private network. SSH, Web, SCP, ... all work as if my module is local to my servers * Roaming : The idea is to have a single point of contact even if the module changes network, changes IP address, etc... Part of this feature set is already available with a combination of the OVMS Server (v2, v3) and the Hologram.io services, but I wanted to be independent of the mobile connexion provider, and also file transfer is important for my use case (SCP or other), as I'm often wanting to sync the content of the SD card over the network. If you can have a look and give feedback (either here, or on the PR), especially on: * The documentation : is it enough ? properly organized ? should it be split ? etc... * The command set * The configuration items : what's missing ? is the naming OK ? * Other features (should I introduced events ? metrics ?) Also if you have any feature request, please share. Limitations: * Currently limited to 1 tunnel, but should work with multiple - it's just a question of arranging the configuration to support multiple instances * Roaming not tested yet (will report) * Compatibility with mobile network not tested yet (will need help on this) * I'm not really happy with the way I set the configuration items. I'd like to "hide" (write-only) the important bits (private key, shared key), but fear that it would clutter the config namespace - especially if I introduce multiple tunnels. Maybe one solution would be to have a rich configuration per tunnel (like a JSON / YAML), which would be a nightmare to edit by hand and would need support in the web interface. * Tunnel always active as soon as the configuration is correct. May be will need to add an enabled/disabled flag to the configuration, and/or an auto-start flag. Current status: * Builds on GitHub actions (if you can to test, pre-compiled firmwares are available here for example: https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions/runs/478… - just download a Zip file (v5.0 or v5.0.1), and flash with a command-line like esptool.py --chip esp32 --port /dev/xxxx --baud 921600 write_flash --compress --flash_mode "dio" --flash_freq "40m" --flash_size detect 0x10000 ovms3.bin ) * Works on My Machine (tunnel is UP, SSH is working OK, HTTP is working OK, performances look OK. Ping time (ICMP) is comparable with or without tunnel) Thanks for your comments. Regards,

3 11

Re: [Ovmsdev] crash when calling 12 V history
by Michael Geddes 04 May '23

04 May '23

https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/892 This one is one me, and not sure how I missed it. //.ichael On Thu, 4 May 2023 at 15:45, Simon Ehlen <ovms(a)highteq.de> wrote: > Hello Michael, > > after Michael Balzer's hint that I should take a closer look at the JSON > string, I noticed that the error is in vehicle.cpp, which was changed in > November. > > When concatting the string some elements (yAxis, comma, closing) were > forgotten. > > You can see it if you compare for example the version of the Ioniq5 > against the one of the standard class. > > vehicle.cpp: > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/maste… > hyundai_ioniq5: > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/maste… > > I would be grateful if you could create a PR, because I am currently not > 100% sure whether in my vehicle.cpp not individual adjustments of me are > in there, with which I would not like to "pollute" the official repo. > > What I noticed is that the gauges sometimes show different values than the > label would lead you to believe. > > For example, instead of the engine temperature, the SOC is displayed. > > I am not familiar with the dashboard coding and would be grateful if you > could show me where the values are assigned to the various gauges. > > Cheers, > > Simon > > Am 03.05.2023 um 02:10 schrieb Michael Geddes: > > It's probably worth seeing if you can see the fresult that is being > returned causing the issue.. Being logged in the vfs-fat debug stream :/. > > Michael > > On Wed, 3 May 2023, 1:38 am Simon Ehlen, <ovms(a)highteq.de> wrote: > >> Hello, >> >> since a few days my OVMS crashes as soon as I call the 12 V history >> monitor from the webinterface. The crash happens right after the click in >> the menu even before the history web page is loaded. >> I have not made any changes to my firmware recently nor any changes to >> the 12 V history at all. >> Yesterday I compiled the current version as a test, but the error occurs >> there as well. >> >> Attached is the information from a2l with the backtrace. >> >> Cheers, >> Simon_______________________________________________ >> OvmsDev mailing list >> OvmsDev(a)lists.openvehicles.com >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >> > > _______________________________________________ > OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev > > >

1 1

crash when calling 12 V history
by Simon Ehlen 04 May '23

04 May '23

Hello, since a few days my OVMS crashes as soon as I call the 12 V history monitor from the webinterface. The crash happens right after the click in the menu even before the history web page is loaded. I have not made any changes to my firmware recently nor any changes to the 12 V history at all. Yesterday I compiled the current version as a test, but the error occurs there as well. Attached is the information from a2l with the backtrace. Cheers, Simon

3 6

Presentation and first questions
by Romuald Conty (Opus Codium) 29 Apr '23

29 Apr '23

Hi, I'm Romuald, a FLOSS enthusiast, and I'm working on a project where I'm going to use OVMS platform as a part of the vehicle hybridisation system. To reach my goals, I'll have to: - Read two CAN buses to grab and display values on a HUD - Make an expansion board with some IC which requires to talk using I²C - Publish events on a third CAN bus which exposes additional sensors values I have a lot of questions about the really exiting OVMS board and platform, to start here are my firsts: - Is there is any trap I should take care that is not described in users or developers documentation regarding my goals? - Is there is any place where I can find some prototype boards¹? - Could someone guide me to be able to periodically wrote values on CAN bus using the OVMS code architecture²? Thanks for this awesome project! [1] I bough my OVMS from OpenEnergyMonitor and unfortunately none are sold [2] It's about read some sensors, compute values and provide results at a traditional CAN frequency on the bus. -- Romuald Conty Opus Codium

3 3

SCP help and Cellular problem
by Tamás Kovács 25 Apr '23

25 Apr '23

My first problem is i want to download log files from sd card but i can't do it. 1.) i use the following command: scp -o HostkeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa -v admin@nnb635.local:/sd/cellular.20230422-232741 ~/ but no file downloaded Files on sd card from ovms [image: Screenshot 2023-04-23 at 14.43.07.png] I use MacOs Ventura 13.3.1 and 2) I create 2 simultaneous cellular command output: [image: IMG_0120.PNG] 1. works everything's fine 2. no cellular connection I use hologram sim card on Hungary. Any suggestion to resolve this issue? My OVMS Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM SIM7600 Hologram SIM Firmware: 1.0.16-1-g133c1144/ota_0/main (build idf v3.3.4-849-g6e214dc33-dirty Feb 19 2023 20:08:56) Same as OVMS main ait febr 19 -- Best regards: Tamás Kovács

2 2

P/R 859 - Moving polling to separate thread & More polling ideas
by Michael Geddes 08 Apr '23

08 Apr '23

Hi all, I was after some feedback on https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/859 which moves the ISOTP polling into what is currently the ISOTP response thread. This is part of a larger rework I have been doing to add flexibility to the loop and to move the poll-loop operations behind a clean interface. I'm interested in feedback on the mechanism in the p/r directly, but I'm also happy to provide the usage examples I have (which would be the follow-up commits for Ioniq 5). I'm also interested in other people's thoughts on where they see what improvements might be had to the poll-list mechanism. Already Done: * Clean up the blocking poll mechanism * Allow for multiple concurrent poll lists (still executed sequentially) * Add once-off non-blocking poll mechanism * Add a poll-list that allows repeating more-frequently than the primary poll Ideas: * Add a user-configurable poller that could possibly utilise the DBC framework (on top of the existing vehicle framework) to allow exploring/experimenting with both passive data as well as polled data. (Given that the DBC framework already does the heavy lifting of interpreting data - adding a poll request to that seems to be a nice way of going) * ??? Have a poll thread per bus ??? //.ichael

2 3

ECU / HUD and OBD Poller response redesign
by Michael Geddes 11 Mar '23

11 Mar '23

Hi all, I have a big change set coming for the OBD Poller that has really improved what I have been able to do with the responsiveness of the HUD and should provide a framework for consolidation of custom polling designs. The aim was to: - Have a single interface to the poll list that moves the one-shot blocking polling and the default list polling behind a single interface - Have the ability to have multiple poll-lists / responders active at once. - Be able to have responders that could use any spare polling time to continually update a value without impinging on moving to the 'next poll count'. (For example speed and rpm) - Be able to have a once-off responder that is non-blocking (for example a request for the VIN which is a once-off but requires the car to be 'on' for ioniq 5). All this I have implemented and am just finalising now - doing some stability testing and going through it to make sure it does what it needs to. The bulk of ISOTP and VWTP code has been left alone, with the exception of where it used to interface back to the poll queue / once-off blocking poll. I have a class that represents a poll responder, and a class that handles a list of responders. 'Blocking' handlers are treated specially. Implemented so far is: List Poller - to handle the standard list of entries Blocking Once-Off poller - to handle PollSingleRequest Data Buffer List Poller - handles a standard list but calls back with the complete data rather than frame-by-frame. Once-Off Poller - Handles a single request (with retries) but is non-blocking. On my TODO list is a special poll responder that allows us to add user entries that would grab/interpret particular ecu addresses on the fly and place them either in metrics or a special temporary metric area. This would enable better testing of values while driving (for example, I want to know which flag is for the brake being pressed, and which one is for the brake light, and I can use the ECU to display these on a HUD without recompiling). I would appreciate any thoughts on this. I might be pushing it up as a draft soon, but the usage of it in the I5 code does depend on the sub-tick p/r so I might wait for that. //.ichael

1 0

ESP-IDF v4 / v5 - baby steps
by Ludovic LANGE 06 Mar '23

06 Mar '23

Hi list, I am interested in upgrading our codebase to a latest ESP-IDF version (preferentially v5 which has just happened end of 2022 - Happy New Year ! :-)) - mostly to be able to use some components for which a backport seems difficult (for example : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752 ), and as a matter of balance between stability vs latest bugfixes, security fixes, new features etc... In the past it seems that some endeavours already set the basis to make this happen (https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/263, https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/360 ). I'm now trying to revive this effort, and after some work managed to have: * OVMS codebase building under v4.x using Makefile * OVMS codebase building under v4.x using cmake / idf.py (not 100% finished, multiple vehicle_* components are missing) (/*WARNING*: some important features of OVMS have been deactivated for the moment, see end of post)/ The produced binaries seem to "work on my machine board", as they end with a "OVMS#" prompt and a few (very) basic tests look OK (to be honest, unfortunately no real tests have been done except to check that the binary does not crash during boot and a few seconds of run, checking that WiFi / web Interface is OK, sdcard is OK - but very basic) You'll find the changes here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimenta… (In the README.md, there is a short notice at the top with a few useful informations) I'm now reaching out here mostly for : * gathering feedback both around the effort (is it worth pursuing this goal ?) and the implementation (do my CMakeLists.txt look weird ? yes they do.) * having volunteers using those builds on real-world workload (which I cannot do at the moment) and finding bugs * guidance and fixes regarding the CMakeLists.txt files My next steps could be (of course, subject to feedback) : 1. Have 100% of the cmake implementation finished (all the missing vehicle_* components) -> easy (only missing time) 2. Work on the warnings (currently disabled in the builds) and try to fix as much as possible 3. Iron out all the bugs, improve the dev documentation -> need help on finding them with real-world use 4. 1st goal is to propose this result as a merge request (either as a whole, or split depending on feedback - ideally I would like to have a first (big) MR accepted quickly so that people can play with it, and deliver incremental updates as expected) 5. then work on the v5 and do the same. (Please note that my cmake skills are inexistent - so be careful when opening those files to not hurt yourself.) # The guidelines I tried to follow: * Stay compatible with our 3.3.x branch which should still compile without any issue nor loss of functionality * Keep Makefiles running for 3.3.x (and 4.x if possible) * When possible, isolate differences (between 3.x, 4.x, 5.x) by testing the versions of ESP-IDF. * Focus on 5.x (if there are impossibilities, let's make it easier to build v5.x than v4.x) * https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-refer… * https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-guide… * https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guide… * https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guide… # Missing features: In the course of this work I had to make some decisions to speed up the work - that will need to be acted upon: * I disabled the crash handler (`xt_set_error_handler_callback` and `esp_task_wdt_get_trigger_tasknames`) for the moment, we need to decide whether we "fork" ESP-IDF again to port it ; or if the new APIs are enough to (partially ?) reimplement it * There is a crash in `OvmsConsole::Poll` which I did not analyse (yet) and which I worked around by declaring a variable static. * I decided to transform our local copies of `wolfssh` and `wolfssl` in submodules (and move them one level below in terms of directories) - mainly to be able to have a CMakeLists.txt different from the upstream one. In the process, I "lost" one of our patches : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/514… and we need to decide how to handle this. * A lot of dependencies are now explicitly (hard-)coded in the CMakeLists.txt - which may, or may not be a good thing. Let's discuss it. * I had to change a set of defines into a header generation (in ovms_webserver) because I was unable to implement those in a satisfying manner in cmake. If you manage to do it, it's a win ! * Build warnings were disabled to keep the output clean and focus on the build issues - but now they need to be re-activated. * etc... * Even if there is experimental support for cmake / idf.py in ESP-IDF 3.3.x, I did not make any effort to be compatible with it: o Our own fork does not seem to include this build system o It was experimental, the component API changed and I did not want to have edge case for something not used at the moment. Let me know your comments and questions. Best regards,

4 27

Re: [Ovmsdev] Hyundai Kona Electric devs?
by Christos Oscar Kambiselis 24 Feb '23

24 Feb '23

I have, for my 2019 Kona Electric, the maps of the whole CAN bus network, pinouts of connectors and schematics of the wiring on PDF, these can all be found at service.hyundai-motor (dot) com, when accessed from Europe, the access costs 15€ for 24h or 60€ for a whole week, it's all official service manual info and much more for independent repair shops. I also have a couple of contactless CAN bus readers plus the direct connection to D-CAN through the OBD. My car only has the 8inch Standard Navi without the mobile data connection, but from the info I have gathered the only CAN bus connected to the larger "conected" navi is the same M-CAN that the standard version has, so the remote AC control should be possible, through M-CAN. I was thinking to connect the contactless readers to my logic analyzer plus one channel to a button to act as a marker, and record a known sequence of events, marking each event start with the button for easier searching. I also have access to 100kW DC fast chargers and 22kW AC chargers, including their CAN data when I have my car charging. Oscar

3 4

Android Auto?
by Mark Webb-Johnson 24 Feb '23

24 Feb '23

It seems easier to get onto Android Auto now (although still not trivial and certain things must be locked down ‘while driving’). Is there any interest in this? https://developer.android.com/training/cars/distribute Regards, Mark.

3 2