- OvmsDev - Open Vehicles

Re: [Ovmsdev] Time for release 3.2.016?
by sharkcow 11 Mar '21

11 Mar '21

Hi all, > Twice in the last few weeks I've gotten the "possible theft/flatbed" alert just as I was backing out of the garage. I have never received that alert before. I hadn't posted anything yet because I was waiting to drive the other car and see if has the same problem. I get this too every once in a while with my e-Up. Mostly shortly after parking, I think (and tragically, the one time I'd have needed it because I actually _did_ get towed, I had crashed OVMS into a boot loop just before :-/). sharkcow

6 26

Wifi AP bandwidth
by Derek Caudwell 09 Mar '21

09 Mar '21

Hi all, I've noticed the default wifi AP is using a 40mhz width. This is not ideal at 2.4ghz as it can be less stable and create interference see https://learntomato.flashrouters.com/wifi-frequency-wifi-channel-width-wire… . Does anyone mind if I submit a PR to default it to 20mhz instead? Cheers Derek

2 1

ESP32 S3
by Mark Webb-Johnson 07 Mar '21

07 Mar '21

Not available for a while, but the specs look incrementally better. Mark

2 4

Re: [Ovmsdev] Angelo, ipace forum
by didier＠ernotte.com 27 Feb '21

27 Feb '21

Here is a screenshot of my session with "obdii" command. Don't hesitate to post here :ovmsdev@lists.openvehicles.com You will get a quick answer from the core developement team of OVMS. Didier Le vendredi 26 février 2021 13 h 01 min 39 s UTC−5, Angelo Russo <ing.angelorusso(a)icloud.com> a écrit : No way !!! Maybe I will start over all OVMS initialing procedure. It’s a very strange issue. Can you please confirm you can use odbii command without typing ECU? ————————— This e-mail is strictly confidential. It is intended for the sole use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. You are hereby notified that any dissemination, distribution or duplication of this message by someone else than the intended addressee or its designed agent is strictly prohibited and may breach art. 616 and ff. of the criminal code. Should you receive this e-mail by mistake please notify this firm immediately and delete the message from all locations in your computer. > Il giorno 26 feb 2021, alle ore 13:55, didier(a)ernotte.com ha scritto: > > re obdii tester start 1 7e4 5

1 0

Shell syntax to write a value
by didier＠ernotte.com 25 Feb '21

25 Feb '21

Hi, I can easily read a PID value using the shell syntax in the web browser : "obdii can1 request device 7e4 7ec 22ddd00" for example. I understand that "0x22" is used to read data by identifier, and I read that "0x2E" would be used to write data by identifier but what would be the correct syntax to write a value to a PID in the shell ? or it is not possible yet ? Didier

2 1

Time for release 3.2.016?
by Michael Balzer 24 Feb '21

24 Feb '21

Everyone, we're 624 commits away from 3.2.015, and we've got a bunch of new features & vehicle support. We've had some changes recently, but apparently no issues with these (at least none reported). I'd say it's time for 3.2.016. Objections? Anything in the works that should be included? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

5 27

Using the BMW Connecteddrive API from OVMS
by Steve Davies 19 Feb '21

19 Feb '21

Hi, One way to "command" the BMW/Mini cars is with the BMW ConnectedDrive app. This talks to REST APIs on BMW servers around the place. This API has been sniffed by others and seems simple to use. The actual delivery of the command to the car is deathly slow - at least here in South Africa. I think it actually sends the car an SMS to kick things off. And it doesn't always work. Still, it does allow things like unlock / lock / climatise and what have you. I expect I can come up with some sort of "noop" operation that boils down to "wake up the car" which would be helpful to get fresh state from the car from time to time. Would you be OK with taking a PR for the bmwi3 vehicle module that uses this? Are there any available frameworks for calling HTTP/JSON/REST APIs from the C++ code? Thanks, Steve -- https://www.telviva.co.za/legal/email-disclaimer <https://www.telviva.co.za/legal/email-disclaimer>

3 6

Re: [Ovmsdev] GPS theft alert (fwd)
by Stephen Casner 13 Feb '21

13 Feb '21

Delivery of the message below to ovmsdev(a)lists.openvehicles.com failed: "554 command rejected for policy reasons". Is that because of a .pl attachment? Fortunately I addressed it directly to Craig as well. -- Steve ---------- Forwarded message ---------- Date: Fri, 12 Feb 2021 12:30:13 -0800 (PST) From: Stephen Casner <casner(a)acm.org> To: Craig Leres <leres(a)xse.com> Cc: OVMS Developers <ovmsdev(a)lists.openvehicles.com> Subject: Re: [Ovmsdev] GPS theft alert On Fri, 12 Feb 2021, Craig Leres wrote: > I also got a theft alert last night. Considering that I had never seen this > alert until a few weeks ago it feels like something has changed. This includes > the vehicle_cadillac_c2_cts which until a few days ago was not updating > StandardMetrics.ms_v_env_on->SetValue() (which I believe maps to v.e.on?) And > looking at OvmsLocations::CheckTheft() it's not even clear to me that a > vehicle module that never sets ms_v_env_on can even trigger an alert?!?! > > void OvmsLocations::CheckTheft() > { > if ((m_park_latitude == 0) && (m_park_longitude == 0)) return; > if (StandardMetrics.ms_v_env_on->AsBool()) return; > [...] Right. That was why I asked you if v.e.on was set in your cars. > I browsed changes to ovms_location.cpp over the last months and if anything I > would think it was less likely to get a theft alert. That has been the intent. > It's difficult for me to see how upgrading my esp32 hardware could be causing > this especially since the gps hardware is in the simcom. Agreed. > On 2/12/21 1:35 AM, Michael Balzer wrote: > > Please check your "L" log at the time of the alert: what did your GPS > > data look like just before the alert? > > Do I need to turn on logging to the sdcard to see this? As far as I know I'm > not doing any logging right now. No, this is referring to the records stored on the v2 server. They are only kept for a limited time (48 hours?). I have attached a perl script given to me by Tom Saxton to fetch those records. I have it run daily on my laptop. Note that you need to put your credentials in variables near the top, and you'll probably have to adjust some paths and libraries for your system. -- Steve

1 0

Changed log file timestamps
by Stephen Casner 11 Feb '21

11 Feb '21

While investigating the delay in ssh connection establishment I observed that the wallclock timestamps added to the log file don't match the deltas in the kernel-supplied uptime timestamps: 2021-02-10 09:55:35 PST I (305470) wolfssh: Entering wolfSSH_accept() 2021-02-10 09:55:35 PST I (305480) wolfssh: Entering DoKexInit() 2021-02-10 09:55:35 PST I (305480) wolfssh: Leaving DoKexInit(), ret = 0 2021-02-10 09:55:35 PST I (305490) wolfssh: Entering wolfSSH_accept() 2021-02-10 09:55:35 PST I (305490) wolfssh: Entering SendKexDhReply() 2021-02-10 09:55:35 PST I (310800) wolfssh: Signing hash with RSA. 2021-02-10 09:55:35 PST I (312640) wolfssh: Entering SendNewKeys() 2021-02-10 09:55:35 PST I (312640) wolfssh: Entering wolfSSH_SendPacket() 2021-02-10 09:55:35 PST I (312640) wolfssh: Leaving SendNewKeys(), ret = 0 2021-02-10 09:55:35 PST I (312640) wolfssh: Leaving SendKexDhReply(), ret = 0 That's because the wallclock timestamps are obtained when the log is written, not when the message occurred and may have been queued. I have improved this by basing the timestamps on the kernel-supplied uptime timestamp added to a calculated system boot time. I also extended the wallclock timestamp with milliseconds: 2021-02-10 23:59:16.410 PST I (99560) wolfssh: Entering wolfSSH_accept() 2021-02-10 23:59:16.410 PST I (99560) wolfssh: Entering DoKexInit() 2021-02-10 23:59:16.410 PST I (99560) wolfssh: Leaving DoKexInit(), ret = 0 2021-02-10 23:59:16.420 PST I (99570) wolfssh: Entering wolfSSH_accept() 2021-02-10 23:59:16.420 PST I (99570) wolfssh: Entering SendKexDhReply() 2021-02-10 23:59:16.430 PST I (99580) wolfssl: wolfSSL Entering wc_ecc_make_key_ex2 2021-02-10 23:59:18.730 PST I (101880) wolfssl: wolfSSL Leaving wc_ecc_make_key_ex2, return 0 2021-02-10 23:59:18.730 PST I (101880) wolfssl: wolfSSL Entering wc_ecc_shared_secret 2021-02-10 23:59:21.070 PST I (104220) wolfssl: wolfSSL Leaving wc_ecc_shared_secret, return 0 2021-02-10 23:59:21.070 PST I (104220) wolfssh: Signing hash with RSA. 2021-02-10 23:59:21.070 PST I (104220) wolfssl: wolfSSL Entering RsaPublicEncryptEx 2021-02-10 23:59:22.980 PST I (106130) wolfssl: wolfSSL Leaving RsaPublicEncryptEx, return 256 2021-02-10 23:59:22.980 PST I (106130) wolfssh: Entering SendNewKeys() 2021-02-10 23:59:22.980 PST I (106130) wolfssh: Entering wolfSSH_SendPacket() 2021-02-10 23:59:22.980 PST I (106130) wolfssh: Leaving SendNewKeys(), ret = 0 2021-02-10 23:59:22.990 PST I (106140) wolfssh: Leaving SendKexDhReply(), ret = 0 If the extra milliseconds field is going to cause breakage in some scripts or something I can remove it. -- Steve

1 0

Android App release 3.18.1
by Michael Balzer 10 Feb '21

10 Feb '21

I've just released version 3.18.1 of the Android App on the Google Play Store. *Version 3.18.1 (2021-02-10)* * Show charge input power & loss if available * Support new TPMS 'Y' record, adding health & alert states * Add car_auxiliary_12v state data & broadcast * Fix UpMiiGo images * Fix service info You can also download the APK file from: https://github.com/openvehicles/Open-Vehicle-Android/tree/master/release Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0