June 2018 - OvmsDev - Open Vehicles

Fwd: [openvehicles/Open-Vehicle-Monitoring-System-3] 29e333: Issue #36: Add support for ota/tag in config
by Mark Webb-Johnson 30 Jun '18

30 Jun '18

A few changes to OTA this morning: The ‘ota status’ command used to check available server version only if a WIFI network was up. It now does that if ANY network is up (including modem). I’ve added a config instance ‘tag’ to parameter ‘ota’. This can be used to override the ota tag (default: main) at run-time. I’ve added a config instance ‘server’ to parameter ‘ota’. This can be used to override the ota server URL (default: api.openvehicles.com/firmware/ota <http://api.openvehicles.com/firmware/ota>). From now on, I’m going to be maintaining two tags for the production ota server api.openvehicles.com <http://api.openvehicles.com/>. These are: main: for stable releases edge: for bleeding edge developer releases You can, for example, now set your module to bleeding-edge by ‘config set ota tag edge’. Regards, Mark. > Begin forwarded message: > > From: GitHub <noreply(a)github.com> > Subject: [openvehicles/Open-Vehicle-Monitoring-System-3] 29e333: Issue #36: Add support for ota/tag in config > Date: 16 April 2018 at 8:37:46 AM HKT > To: mark(a)webb-johnson.net > Reply-To: GitHub <noreply(a)github.com> > > Branch: refs/heads/master > Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 > Commit: 29e33348f6dff949fd22567083de1d9db04b05e3 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/29e… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-04-16 (Mon, 16 Apr 2018) > > Changed paths: > M vehicle/OVMS.V3/components/ovms_ota/src/ovms_ota.cpp > M vehicle/OVMS.V3/main/ovms_version.cpp > > Log Message: > ----------- > Issue #36: Add support for ota/tag in config > Issue #37: Add support for ota/server in config > Issue #38: ota status should show available server version for modem as > well as wifi > >

4 9

A Car Hacking Experiment: When Connectivity Meets Vulnerability
by Mark Webb-Johnson 29 Jun '18

29 Jun '18

FYI: https://www.researchgate.net/publication/286931560_A_Car_Hacking_Experiment… <https://www.researchgate.net/publication/286931560_A_Car_Hacking_Experiment…> Interconnected vehicles are a growing commodity providing remote access to on-board sys- tems for monitoring and controlling the state of the ve- hicle. Such features are built to facilitate and strengthen the owner’s knowledge about its car but at the same time they impact its safety and security. Vehicles are not ready to be fully connected as various attacks are currently possible against their control systems. In this paper, we analyse possible attack scenarios on a recently released all-electric car and investigate their impact on real life driving scenarios. We leverage our findings to change the behaviour of safety critical com- ponents of the vehicle in order to achieve autonomous driving using an Open Vehicle Monitoring System. Furthermore, to demonstrate the potential of our setup, we developed a novel mobile application able to control such vehicle systems remotely through the Internet. We challenge the current state-of-the-art technology in today’s vehicles and provide a vulnerability analysis on modern embedded systems.

3 5

Vehicle Info in User Guides
by Mark Webb-Johnson 29 Jun '18

29 Jun '18

We’ve got quite a few (hundreds, as we are about half way sold through the second batch) using OVMS v3 now, and I’m getting questions about specific functionality in specific vehicles. We need better documentation on this. As an example, I’ve updated the User Guide, Tesla Roadster section. I’ve covered: A short introduction about level of vehicle support. Should describe exactly what model years and variants are supported, and overall how good the support is. Hardware requirements. A list of components (on fasttech, or elsewhere) for what is required (most importantly cables, antennas, etc). Module installation in the vehicle. Where we recommend putting it. Antenna installation. Where we recommend placing the antenna(s). Vehicle-specific configuration options. Vehicle-specific commands. Notes. Concentrate on limitations, or vehicle-specific stuff. Thanks. A space to thank the developers (yourself) and anybody else who has contributed to that vehicle module support. It would be good if the other vehicles followed the same format (or something similar). I see that Kia Soul is pretty complete, but Nissan Leaf and Renault Twizy need some work (I guess the RT document is somewhere else?). It would be good to get this all in one place, so we can simply refer questions to that. Could you guys fill in / copy over the text, and I’ll help with proof-reading and formatting? Thanks, Mark.

1 0

Compiler warning
by Mark Webb-Johnson 28 Jun '18

28 Jun '18

I’m seeing this: CXX build/ovms_webserver/src/ovms_webserver.o /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp: In member function 'user_session* OvmsWebServer::CreateSession(const http_message*)': /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:665:32: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] s->id = *((uint64_t *) digest); ^ Michael: Can you have a look? Thanks, Mark.

2 2

Feedback regarding web dashboard
by Mark Webb-Johnson 28 Jun '18

28 Jun '18

I received the following feedback regarding the web dashboard: Can you please revert the two ranges in the OVMS dashboard so that they appear in the same order as in the app (see pictures above: 297 - 307 v. 307 - 298)? This would make reading the numbers much easier for us! Can we make this change? Regards, Mark.

2 1

Default values and fields...
by Greg D. 27 Jun '18

27 Jun '18

Hi folks, One thing I've noticed in setting up the OVMS module is that my experience with the term "default" is a bit different than what we have implemented. In the past, I have come to expect "default" to mean "if you don't do anything, you will get this". Instead, we seem to be using it to mean "unless you need to use something else, use this value". In the former case, one properly leaves the entry empty or otherwise unchanged. In the later case, we show the value, but it is up to the user to actually configure it. Leaving the entry in its default state is not correct. Where this most recently affected things was the automatic update to version .006, which did not occur on time. Investigating, there were a couple of fields labeled with the default phrasing (e.g. the server address) that were, as I thought instructed, left blank. Filling them in with the default contents and pressing save worked. Next morning, I awoke to .006 running on the module. Yea! Oh, almost... My timezone was also wrong. It was set to -7 like I do everywhere else, instead of PST8PDT. Where did that come from? My only clue to this was that the new boot status display of time at last boot said GMT instead of PDT. Is this just my own weird view of the world? Is it worth changing either the on-screen instructions to clarify what action needs to be taken, or should we actually implement (pre-configure) the defaults so that no further action needs to be taken by the user? My recollection is that this is not just with the webserver UI; the command line setup is equally in need of active management, for example to get the v2 server to connect. There are lots of defaults all over the place, but none of them are implemented by default. At least we are consistent... Greg

6 24

Fwd: OVMS 3.1.007
by Mark Webb-Johnson 26 Jun '18

26 Jun '18

FYI: I’ve put v3.1.008 up on edge, but not live yet. Users of the problematic v3.1.007 can download and update from there. I plan to release v3.1.008 to all edge users this weekend. Regards, Mark. > Begin forwarded message: > > From: Mark Webb-Johnson <mark(a)openvehicles.com> > Subject: OVMS 3.1.007 > Date: 26 June 2018 at 10:21:16 PM HKT > To: undisclosed-recipients:; > > > You vehicle connected to the api.openvehicles.com <http://api.openvehicles.com/> is running firmware v3.1.007. That version of firmware was released to ‘edge’ a week or so ago, but was not released to ‘main’ as we’ve seen issues with that firmware sometimes being unable to update over Wifi OTA (depending on flash image size and speed of flash access). > > As we are about to release v3.1.008 (to address this issue, as well as a few other small enhancements), it would be helpful if you could manually update to that new firmware first (as the automatic OTA update from v3.1.007 to v3.1.008 will most likely fail for you). You can do that with: > > Firstly, go back to factory firmware: > > ota boot factory > module reset > > After reset, connect to wifi and do a manual ota update: > > ota flash http api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008.ovms3.bin <http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008.ovms3.bin> > module reset > > After that is done, check the version with: > > ota status > > (You should be running 3.1.008 from an ota partition) > > Alternatively, you can download 3.1.008 from http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008.ovms3.bin <http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008.ovms3.bin> directly and put as ovms3.bin on SD CARD to update from that. > > We will release v3.1.008 to edge this weekend, and we suggest you do this manual upgrade before then. > > Apologies for the inconvenience. > Regards, Mark.

1 0

Nissan Leaf 2018 cable
by Mark Webb-Johnson 25 Jun '18

25 Jun '18

I got this enquiry regarding the cable for the 2018 Nissan Leaf. It seems that the OBDII pinout has changed? Anyone know anything about this? Regards, Mark. > Begin forwarded message: > ...But if this is correct, it will probably not work on the 2018 Nissan Leaf, because ODB2-Pins 12 and 13 are not assigned (see the image from the service manual attached - page 17) and when I take a look at the connector I can clearly see, that 12 and 13 have no metal clip - no electrical connection possible. > Do I have to - somehow - connect the OVMS to the CAN Bus the TCU is connected to? > > Or do I have to select something special in the web-interface of the OVMS module, like the model-year?

2 1

What causes factory reset?
by Stephen Casner 21 Jun '18

21 Jun '18

This evening I connected my new OVMS v3.1 to my laptop and went through the setup wizard. That seemed to go smoothly. I copied over my ssh key and things seemed to be working fine. I installed an SD card so I could do logging if needed, and then unplugged the module to install it in the car. But it didn't come up! After I brought it back to the desk and connected to the laptop again, I see a message on the console that it has factory reset itself. What are the ways to trigger a factory reset? I must have unintentionally hit one. -- Steve

3 6

Network stuck?
by Stephen Casner 21 Jun '18

21 Jun '18

My OVMS v3.1 has been installed in the car for some hours and now the network operations are stuck in some way. I detected this when I found that the app had no status for two hours. When I connect to the USB console, I see the reason: I (28236429) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (28236429) ovms-server-v2: Status: Connecting... W (28254039) ovms-server-v2: Connection failed E (28254039) ovms-server-v2: Status: Error: Connection failed I (28254239) ovms-server-v2: Status: Disconnected I (28273429) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (28273429) ovms-server-v2: Status: Connecting... W (28290959) ovms-server-v2: Connection failed E (28290959) ovms-server-v2: Status: Error: Connection failed I (28291159) ovms-server-v2: Status: Disconnected And now, as I look, a variation: I (28527429) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (28527429) ovms-server-v2: Status: Connecting... E (28533869) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (28533869) ovms-server-v2: Status: Error: Connection failed I (28547429) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (28547429) ovms-server-v2: Status: Connecting... E (28553979) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (28553979) ovms-server-v2: Status: Error: Connection failed OVMS# network status Interface#3: pp3 (ifup=1 linkup=1) IPv4: 10.170.41.247/255.255.255.255 gateway 10.64.64.64 Interface#2: ap2 (ifup=1 linkup=1) IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1 Interface#1: st1 (ifup=1 linkup=1) IPv4: 192.168.1.82/255.255.255.0 gateway 192.168.1.254 DNS: 192.168.1.254 Default Interface: st1 (192.168.1.82/255.255.255.0 gateway 192.168.1.254) OVMS# wifi status Power: on Mode: Access-Point + Client mode STA SSID: Revelstoke MAC: 30:ae:a4:43:9c:28 IP: 192.168.1.82/255.255.255.0 GW: 192.168.1.254 AP SSID: US33 MAC: 30:ae:a4:43:9c:29 IP: 192.168.4.1 AP Stations: 0 Anything else to look at before I reset? The module does respond to ping, but not to the web browser nor ssh on the STA wifi. -- Steve

2 4