May 2023 - OvmsDev - Open Vehicles

V3 Server
by Mark Webb-Johnson 17 May '23

17 May '23

I have committed some small changes today that address nagging problems I’ve seen on the api.openvehicles.com <http://api.openvehicles.com/> server. The most interesting of these shows in the logs as: 11:04:30.799832 +0800 info OVMS::Server::ApiV2: #497 - - new connection from <redacted>:<redacted> 11:04:30.800143 +0800 info OVMS::Server::Core: #497 - - ConnStart 11:04:32.147232 +0800 error OVMS::Server::ApiV2: #497 A <owner/vehicle> disconnected 11:04:32.149214 +0800 info OVMS::Server::Core: #497 A <owner/vehicle> AppDisconnect 11:04:32.149614 +0800 info OVMS::Server::Core: #497 - - ConnFinish 11:04:32.149924 +0800 info OVMS::Server::ApiV2: #497 A <owner/vehicle> got proto #/A login 11:04:32.150859 +0800 info OVMS::Server::Core: #497 - <owner/vehicle> AppConnect 11:04:45.071599 +0800 info OVMS::Server::ApiV2: #501 C <owner/vehicle> got proto #0/C login 11:04:45.072874 +0800 info OVMS::Server::Core: #501 C <owner/vehicle> CarConnect 11:04:45.073157 +0800 error OVMS::Server::Core: #497 <owner/vehicle> ClientsTransmit mismatch / So at 11:04:30.799832 we got a new connection from an App. Then at 11:04:32.147232 it disconnected. Then at 11:04:32.149924 we got the login. Huh? The rest is the car loging in and trying to inform the messed up app connection. I guess the login message was held in a push_read buffer within AnyEvent::Handle, but the disconnect error took priority and was delivered first. Fix I made for this is to shutdown reads when handling the disconnect, and another check to not login if the connection has been cleared half way through negotiation. Anyway, seems better now, but api.openvehicles.com <http://api.openvehicles.com/> is still experiencing heavy load (due to sheer number of concurrent users we have now, combined with a large number of HTTP API users and cpu-intensive SSL connections). It seems that one single HTTPS API user is equivalent to about 50 API v2 users. I think the only way of easily scaling this further now is a switch to MQTT, and have been wondering if the API v2 server could just be a simple bi-directional translator to/from MQTT (which would give us a nice migration path and better support IOT). Regards, Mark.

2 2

Discord
by Mark Webb-Johnson 17 May '23

17 May '23

I had a few requests for this a while back: https://discord.gg/eXp2FzYfJc It is a shell at the moment. If people find it useful, feel free to use it. I hang around on a few discord servers. For developer discussions, this mailing list should continue to be the main source of information. Regards, Mark.

1 0

Tesla Roadster Podcast - OVMS
by Pete Gruber 16 May '23

16 May '23

FYI: Upcoming podcast on some OVMS history and future plans. Tesla Roadster focussed. Regards, Mark. Tesla Roadster Podcast – Guest Speaker – Mark Webb-Johnson (Creator of OVMS) This Wednesday, at 10 AM MST, this special guest, Mark Webb-Johnson, who is the developer of the popular Open Vehicle Management System (OVMS) for the Tesla Roadster, will be joining us to discuss the evolution of this aftermarket add-on, which reconnects you to your Roadster with any Smartphone. As you may know, Roadsters were accessible to Tesla Service, until the 2G network went obsolete in the US eliminating the ability to monitor a variety of vehicle statistics via web interface. If your car is left unattended during a vacation, or storage, this handy link will keep you informed what is going on with your car. (HINT - Many Roadster brickings could be avoided with this add-on) In this question and answer session with Mark, the creator of the OVMS system, you can get up to speed on the advantages of restoring you or your service provider’s ability to connect to your car. See our E-Store for more details - https://grubermotors.com/product/ovms-unit/ If for some reason you are unable to join us for the live session Wednesday, our Podcasts as posted on our YouTube channel for later review. https://www.youtube.com/@grubermotorcompany/streams We look forward to seeing you Wednesday, Pete Pete Gruber | Gruber Industries | CEO Main 602-863-2655 x207 | Fax 623-879-7341 | Email gru(a)gruber.com <mailto:gru@gruber.com> Website Shop <https://www.grubermotors.com/> Youtube Subscribe <https://www.youtube.com/channel/UCjRHl8tpECei0UkoZfLE2hw/featured> Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.

1 0

unit repeatedly crashing / reverting to factory
by Derek Caudwell 15 May '23

15 May '23

Recently my 12V battery died, after replacing it the OVMS unit reverted to the factory reset state. Unfortunately it kept crashing in this state with the following: Last boot was 101 second(s) ago Time at boot: 1970-01-01 00:03:16 GMT This is reset #3 since last power cycle Detected boot reason: EarlyCrash (12/12) Reset reason: Exception/panic (4) Crash counters: 3 total, 3 early Last crash: LoadProhibited exception on core 1 Registers: PC : 0x4008c341 PS : 0x00060030 A0 : 0x8013cc48 A1 : 0x3ffe63d0 A2 : 0x00000000 A3 : 0xfffffffc A4 : 0x000000ff A5 : 0x0000ff00 A6 : 0x00ff0000 A7 : 0xff000000 A8 : 0x00000000 A9 : 0x00000008 A10 : 0x3ffeba1d A11 : 0x3f417d87 A12 : 0x3ffeba25 A13 : 0x3ffe684c A14 : 0x47006c6c A15 : 0x47006c6c SAR : 0x00000010 EXCCAUSE: 0x0000001c EXCVADDR: 0x00000000 LBEG : 0x4008c341 LEND : 0x4008c351 LCOUNT : 0xffffffff Current task on core 0: wifi, 1176 stack bytes free Current task on core 1: OVMS NetMan, 6420 stack bytes free Backtrace: 0x4008c341 0x4013cc45 0x4013ffbe 0x4013fff5 0x4011439b 0x40184ee2 0x4018526b 0x40185ac8 0x40189829 0x401311ed 0x40132221 0x401311ed 0x40131597 0x4013168a 0x40132ff1 0x40133272 0x4012f432 0x4012330f 0x401233bd Version: 3.3.003-423-g68d9aee8/ota_0/main (build idf v3.3.4-849-g6e214dc33 Apr 19 2023 00:11:25) Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/1 ------------------------------ Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/1 Firmware: 3.3.003-423-g68d9aee8/ota_0/main (build idf v3.3.4-849-g6e214dc33 Apr 19 2023 00:11:25) Running partition: ota_0 Boot partition: ota_0 Factory image: 3.2.002 OTA_O image: 3.3.003-423-g68d9aee8 OTA_1 image: 3.3.003-419-gfbbf3c0d Removing the SD card and trying a S2 reset made no difference, so I proceeded to run the following commands to factory reset and boot from the factory firmware: esptool.py --chip esp32 --port COM3 --baud 921600 erase_region 0xC10000 0x100000 esptool.py --chip esp32 --port COM3 --baud 921600 erase_region 0xd000 0x2000 Both ran successfully however the unit is now no longer providing the factory wifi access point. What should I try next to restore it? Cheers Derek

2 2

Re: [Ovmsdev] Can't compile due to wolfssh
by Chris van der Meijden 14 May '23

14 May '23

:-)) Nothing strange in "git status". "git log" shows e7f41bd8d9aabc0cecba369dc1b7e3641e748d17 and also 7b1c932eab4e00d6a20ba1cc8f30d7dbf6db7e2d and beaada5aaa6c76da2d83612d263a1f3eb17e240c Am Samstag, dem 13.05.2023 um 13:03 -0700 schrieb Craig Leres: > On 5/13/23 12:39, Chris van der Meijden wrote: > > Still "dirty" but it compiles. > > I think "git status" will tell you what's modified. > > I also find it useful to occasionally check my sdkconfig against the > default: > > diff sdkconfig support/sdkconfig.default.hw31 | fgrep -v > CONFIG_OVMS_VEHICLE_ > > > Sorry for my words on "experimenting". Sometimes the complexity of > it > > all is a bit frustrating. > > Dude, in my view I don't think any explanation is necessary past, > "because git." (Don't get me wrong, git is really useful, just seems > like sometimes it wants to pick a fight with me.) > > Craig

1 0

Can't compile due to wolfssh
by Chris van der Meijden 14 May '23

14 May '23

Today I pulled the newest version. During the pull my Wolfssh directory was deleted. I then renewed all the submodules and I got the newest Wolfssh. But now the verion 3.3.003-467-ge7f41bd8-dirty won't compile (why is it "dirty" anyways, I didn't change the code ...). First I get CXX build/console_ssh/src/console_ssh.o /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp: In function 'void wolfssh_logger(wolfSSH_LogLevel, const char*)': /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp:1176:10: error: enumeration value 'WS_LOG_CERTMAN' not handled in switch [- Werror=switch] switch (level) ^ Then I add case WS_LOG_CERTMAN: on line 1178: static void wolfssh_logger(enum wolfSSH_LogLevel level, const char* const msg) { switch (level) { case WS_LOG_CERTMAN: ... But the I run into this error: /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c: In function 'IdentifyKey': /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:883:9: warning: unused variable 'dynType' [-Wunused-variable] int dynType = isPrivate ? DYNTYPE_PRIVKEY : DYNTYPE_PUBKEY; ^ /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c: In function 'DoKexDhReply': /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:3947:17: error: implicit declaration of function 'PRIVATE_KEY_UNLOCK' [- Werror=implicit-function-declaration] PRIVATE_KEY_UNLOCK(); ^ /home/chris/OVMS/Open-Vehicle-Monitoring-System- 3/vehicle/OVMS.V3/components/wolfssh/wolfssh/src/internal.c:3952:17: error: implicit declaration of function 'PRIVATE_KEY_LOCK' [- Werror=implicit-function-declaration] PRIVATE_KEY_LOCK(); ^ Any ideas? Regards Chris

2 7

No GSM connection
by Chris van der Meijden 13 May '23

13 May '23

For the second time within a month I have no GSM connection and I'm not able to reestablish the connection. The SIM card is "Congstar" Prepaid (with enough money on the card). The Network is 2G and connections are normally without any problems here. What I can see, is that I have a signal around -70 dBm, but can't get a network registration: Cellular Modem MODEM Status Model: SIM5360 Network Registration: Searching Provider: Signal: -69 dBm Mode: State: NetWait Mux: Status up PPP: Not running GPS: Not running I can't get an ICCID Cellular modem configuration SIM ICCID: (power cellular modem on to read) Power mode of cellular is now on This is the log output log level debug cellular D (455339) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ D (455349) cellular: mux-rx-line #3: AT+CREG?;+CCLK?;+CSQ D (455359) cellular: mux-rx-line #3: +CREG: 0,2 D (455359) cellular: mux-rx-line #3: +CCLK: "80/01/06,00:07:36+08" D (455359) cellular: mux-rx-line #3: +CSQ: 22,99 D (455359) cellular: mux-rx-line #3: OK D (456339) cellular: mux-tx #3: AT+CPSI? D (456349) cellular: mux-rx-line #3: AT+CPSI? D (456349) cellular: mux-rx-line #3: +CPSI: NO SERVICE,Online D (456349) cellular: mux-rx-line #3: OK D (457339) cellular: mux-tx #3: AT+COPS? D (457349) cellular: mux-rx-line #3: AT+COPS? D (457349) cellular: mux-rx-line #3: ERROR and this is the Info output on the console I (1444379) gsm-mux: Start MUX I (1444449) gsm-mux: Channel #0 is open I (1444459) gsm-mux: Channel #1 is open I (1444459) gsm-mux: Channel #2 is open I (1444469) gsm-mux: Channel #3 is open I (1444479) gsm-mux: Channel #4 is open I (1444789) webserver: HTTP POST /api/execute I (1444799) webcommand: HttpCommandStream[0x3f8ba0b4]: 3478800 bytes free, executing: cellular status I (1445339) cellular: State: Enter NetWait state I (1445599) webserver: HTTP POST /api/execute I (1445599) webcommand: HttpCommandStream[0x3f8ba0b4]: 3478584 bytes free, executing: cellular status I (1455359) cellular: Network Registration status: Searching I (1455359) cellular: Signal Quality is: 22 (-69 dBm) I (1461919) webserver: HTTP GET /shell I (1475359) cellular: Signal Quality is: 18 (-77 dBm) I (1485359) cellular: Signal Quality is: 21 (-71 dBm) The live events show this Live Events [08:02:08]system.modem.poweringon [08:02:08]egpio.output.0.high [08:02:10]egpio.output.0.low [08:02:15]system.modem.installed [08:02:15]system.modem.poweredon [08:02:35]system.modem.muxstart [08:02:36]system.modem.netwait And this is my module information Module Last boot was 1719 second(s) ago Time at boot: 2023-04-13 07:35:21 CEST This is reset #0 since last power cycle Detected boot reason: PowerOn (16/14) Reset reason: Unknown/unset (0) Crash counters: 0 total, 0 early Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/1; MODEM SIM5360 Firmware: 3.3.003-413-ge0a8e914/ota_0/main (build idf v3.3.4-849- g6e214dc33 Apr 12 2023 20:20:24) Last time this happened I was able to get the connection back by performing some esotheric button pressing on "Start Modem", "Stop Modem" and "Power cellular Modem on" in the WebUI, but now it does not help. I compiled the newest version yesterday and I did some reboots of the module and I even pulled the fuse to completely power off my OVMS in the car, but no success. Is there anything I can do to do some more troubleshooting? Any thoughts on possible causes? Thanx Regards Chris

2 3

Review request
by Ludovic LANGE 12 May '23

12 May '23

Hi List, If someone has the time, I'd like a peer-review of the following PRs: * https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/896 It's very straightforward - documentation issues fixed. * https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/887 lots of changes, as it is wolfssh conversion to a submodule. However everything should be fine. Automatic build are here: o equivalent(*) to this branch `convert-wolfssl-submodule` : https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions/runs/495… (*) "equivalent" because, as we don't (yet ?) have automatic builds on our repo, these builds are done on mine, and a few patches are added to master to enable those builds. Thanks in advance. Regards,

1 0

Another readthedocs dependency issue
by Mark Webb-Johnson 05 May '23

05 May '23

We’ve hit another readthedocs dependency issue causing CI/CD builds to fail. This is getting frustrating. This time the error is: https://readthedocs.org/projects/ovms/builds/20391654/ ImportError: urllib3 v2.0 only supports OpenSSL 1.1.1+, currently the 'ssl' module is compiled with OpenSSL 1.0.2n 7 Dec 2017. See: https://github.com/urllib3/urllib3/issues/2168 The urllib3 package is dragged in by the ‘requests’ package, and it seems their v2.29.0 broke compatibility with recent urllib3 versions. https://github.com/psf/requests/issues/6432 I added "requests<2.29.0” to the docs/source/requirements.txt to work around it, and readthedocs CI/CD builds now seem ok. Regards, Mark.

1 0

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