- OvmsDev - Open Vehicles

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

OVMS v3.1 installed and working — with Bonjour
by Stuart Cheshire 20 Jun '18

20 Jun '18

I just got some positive feedback that I thought would be useful to share. It contains some useful tips (particularly for MAC users). Regards, Mark. > Hi Mark, > > Just wanted to let you know I received my OVMS v3.1 module, and it is installed and working. > > And I discovered something that made me very happy — it has Bonjour (aka DNS-SD/mDNS Service Discovery). > > In the manual you talk about connecting using “ssh <vehicleid>.local” > > This is fantastic — certainly better than having to type some unknown IP address, but the user still needs to know the right <vehicleid> to enter. > > Here’s something you may not know — on a Mac, in Terminal, press Cmd-Shift-K (New Remote Connection). It will display a Bonjour browser window showing available devices, and then, instead of having to know what <vehicleid> to enter, you just have to click on it in the list. > > Sadly the “-c aes128-cbc” thing is still an issue. The workaround for now is that if you enter the username as “-c aes128-cbc ovms” then it will end up generating the right command. > > If you were to add a TXT record key to the Bonjour-advertised service on the OVMS module saying “u=-c aes128-cbc ovms”, then I believe the Bonjour browser window in Terminal would auto-fill the right thing. > > And I see the embedded web server is also advertised using Bonjour. This is wonderful.

1 0

Strange DNS lookup issue with current build
by Michael Balzer 16 Jun '18

16 Jun '18

…manifesting in "ota status" and web firmware page not being able to show the latest version & info. It seems the error always comes on the web page. On "ota status" it normally only comes once, then successive "ota status" calls work. Loading the web page seems to restart the cycle. I (695311) webserver: HTTP GET /cfg/firmware W (695361) net: DNS lookup on ovms.dexters-web.de failed err=200 D (695471) webserver: Serve /cfg/firmware: 9940 bytes used, 4171640 free OVMS# ota status Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.006-44-gd3fcb8b-dirty/ota_1/edge (build idf ovms-3.1.006-2-g1a1a544a Jun 13 2018 23:28:20) W (698871) net: DNS lookup on ovms.dexters-web.de failed err=200 OVMS# ota status Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.006-44-gd3fcb8b-dirty/ota_1/edge (build idf ovms-3.1.006-2-g1a1a544a Jun 13 2018 23:28:20) Server Available: 3.1.006-45-gd8220ef (is newer) OTA bleeding edge developer build Wed Jun 13 23:54:42 CEST 2018 See ovms3.log for details d8220ef - Web UI: simplified time zone region selection (vehicle config) d3fcb8b esp32can: Try draining rx fifo in main ESP32CAN_rxframe function This is brand new, has been working flawlessly before. Mark, can this be caused by the aggressive SPIMEM rework? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 3

Time, Apps, 3.1.007, and others
by Mark Webb-Johnson 15 Jun '18

15 Jun '18

Status update. In recent weeks, I've been working on a big EV conference that we were co-organising here in HK, so haven’t done as much for OVMS as I would have wanted. That is now over, so I have more time for the project. The HK EV community has been pretty demoralised recently, by government policy changes. Getting everybody together for a conference was a good opportunity to try to revitalise things and reignite the community. I have been working on the iOS App. I brought in all the recent changes, and tried to update it to the latest iOS SDK. So much has changed in iOS, and a lot is now broken. It is going to be a hell of a job to get that properly working, let alone add the ‘messages’ tab I wanted to add to bring it on-par with the Android App. I have something like 200+ warning messages at build time, and core things like the async tcp/ip socket library we use is no longer reliable/usable. I’ve also been looking at cross platform frameworks, as a possibly better solution. So many are a mess, or commercially dubious, but I narrowed it down to Xamarin and Ionic (both meeting our criteria of ‘free’ to developers, as ‘free’ as possible, cross-platform, and viable for a project like OVMS. Xamarin looks very appealing, but I just hate that proprietary Microsoft thing hanging over it’s head. I know it is free (of charge, at least) now, but that could change at the whim of the people in Redmond. The cross platform design is fantastic; one IDE can see both platforms and it is very simple to build a single virtual class with platform-dependent implementations. Simulators are great. Integration (to github, sdks, etc) is great. Documentation examples are limited, which makes it a steep learning curve. Ionic (and other PhoneGap style frameworks) look good, but are much harder to get to the raw operating system. Even things like maps (web not native) are going to be troublesome given google’s recent pricing change. Getting a raw tcp/ip socket is not possible without platform dependent plugins (so we’d probably have to mess with adding websocket support to the OVMS v2 server). Overall, not nearly as polished as Xamarin. My current plan is to try to build a proof-of-concept with Xamarin. Just the very basics, to see what is possible. Open to offers / suggestions here. It really seems to me that having one cross-platform app would be better for the project long-term. On the vehicle side, I have some time (finally) this weekend to work on it. I’ll be making some changes I’ve had on my list, and then intend to build a 3.1.007 on Monday (my time). If there is anything people want to get into 3.1.007, please commit it before the Sunday day end. Hardware is in stock at Fasttech, and going well. Lots of people receiving their v3.1 kits now, so I expect support calls to increase over the coming week. Please help out with support tickets on www.openvehicles.com <http://www.openvehicles.com/>, or providing local support directly, where you can. We should be able to start the CE and FCC certification process soon, but I still need to sort out exactly who is responsible for what with the certification labs - getting the tests passed is one thing, but it seems that getting labels on the product is something else entirely. I’ve also been working with China on an optional display for OVMS. We sourced a pretty nice 3.5” LCD (based on ILI9488 chipset, driven by SPI bus, and supporting 320*480 resolution with 16 million colours). 4 push button switches (up, down, back, enter - or tasked differently depending on context). SD card, and USB. Enclosure size is about 78mm x 122mm x 26mm. It works with the Loboris ESP32 TFT library: https://github.com/loboris/ESP32_TFT_library <https://github.com/loboris/ESP32_TFT_library> The original idea was for a companion display to work alongside OVMS (perhaps using bluetooth GATT to talk to OVMS v3.1 modules). But using the same firmware framework seems sensible, and it ends up being pretty similar to a full OVMS v3.1. It seems wrong to remove features, but GPIOs are limited. Still playing with what is possible, cost vs functionality, but it seems feasible. Still playing around with whether this is a full OVMS v3.1 with a display, or just a very cut down display to connect to an OVMS v3.1. I’ve attached some pictures, below, to give you some ideas. Thanks, and Best Regards, Mark.

2 5

Roadster info missing?
by Greg D. 14 Jun '18

14 Jun '18

Hi folks (probably Mark...), My Roadster is in the shop for some work on the HVAC system (I think they over-filled it last time), and watched remotely as they took the car for a test drive. One thing I noticed is that the PEM, Motor, and Battery temps aren't being updated. Position, speed (yikes!), tire pressure, and battery SoC are live, so the OVMS is still connected and working normally. I'm guessing they had the car in some sort of service / debug mode. Would that prevent the CAN messages from being reported on the diagnostic connector? Thanks, Greg

2 4

Getting CONFIG_OVMS_HW_SPIMEM_AGGRESSIVE to work properly
by Mark Webb-Johnson 10 Jun '18

10 Jun '18

I finally got CONFIG_OVMS_HW_SPIMEM_AGGRESSIVE working properly. It seems we need to include sdkconfig.h to access these CONFIG_* variables (if we don’t include other esp libraries that do that already). Other than that change, the rest was easy. For my running config (a car, a v2 server connected, and wifi), I originally had this: OVMS# module memory Free 8-bit 87484/230708, 32-bit 7296/11532, SPIRAM 4079552/4194252 Now, with CONFIG_OVMS_HW_SPIMEM_AGGRESSIVE working properly, I get this: OVMS# module memory Free 8-bit 104640/230700, 32-bit 7296/11532, SPIRAM 4062400/4194252 OVMS# test spiram Metrics (0x3f802024) are in SPI RAM With that config option enabled, all the C++ allocations are by default in SPI RAM, and we gain about 17KB of conventional RAM. A quick ‘fgrep -r alloc main components’ shows about 1,000 uses of calloc/malloc in our system. I’ve got a large number of them now done, but probably a few more still to do. For example, changing wolf ssh/ssl to use it means most of the incremental allocations are from SPI RAM. Duktape would be a good win (but non-trivial, I think). Even with bluetooth compiled in, and running, I now have: OVMS# module memory Free 8-bit 76476/230696, 32-bit 7296/11532, SPIRAM 4033960/4194252 OVMS# module tasks Number of Tasks = 21 Stack: Now Max Total Heap 32-bit SPIRAM 3FFCFF98 1 Blk esp_timer 388 628 4096 23928 644 44632 3FFD1C38 2 Blk eventTask 436 1876 4608 0 0 0 3FFD4158 3 Blk OVMS Events 436 3124 8192 73960 0 22128 3FFD56C0 4 Blk OVMS CanRx 428 476 1024 0 0 0 3FFBC3D4 5 Blk ipc0 400 480 1024 7776 0 0 3FFBC9D4 6 Blk ipc1 400 496 1024 12 0 0 3FFBD5E8 9 Rdy IDLE 372 548 1024 0 0 0 3FFBD768 10 Rdy IDLE 372 548 1024 0 0 0 3FFBD8E8 11 Blk Tmr Svc 344 888 3072 88 0 0 3FFBCCAC 16 Blk tiT 496 1504 3072 696 0 884 3FFB7A2C 17 Blk OVMS SIMCOM 464 512 4096 0 0 0 3FFB7D58 18 Blk wifi 432 2384 4096 360 0 1576 3FFDAD44 19 Blk OVMS Vehicle 460 508 6144 0 0 0 3FFDF718 20 Rdy OVMS Console 740 2612 6144 9072 3488 24044 3FFDFBC0 21 Blk mdns 456 1384 4096 108 0 4 3FFE37BC 22 Blk OVMS NetMan 728 2552 8192 104 0 1136 3FFE79B0 23 Blk btController 444 1980 4096 88 0 0 3FFE8CA0 24 Blk Btc_task 412 2572 3584 14924 0 1688 3FFE9EEC 25 Blk hciHostT 408 744 2560 0 0 0 3FFEAFF0 26 Blk hciH4T 412 604 2560 0 0 0 3FFEC854 27 Blk btuT 416 2016 4608 2760 0 23996 That seems very workable. Regards, Mark > Begin forwarded message: > > From: GitHub <noreply(a)github.com> > Subject: [openvehicles/Open-Vehicle-Monitoring-System-3] c2d3f7: Add a test spiram command to show whether SPI RAM ... > Date: 11 June 2018 at 12:51:21 PM HKT > > Branch: refs/heads/master > Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 > Commit: c2d3f7f7ae8655d9d2809e15ad6f989a3459c8df > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/c2d… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-06-11 (Mon, 11 Jun 2018) > > Changed paths: > M vehicle/OVMS.V3/main/test_framework.cpp > > Log Message: > ----------- > Add a test spiram command to show whether SPI RAM is being globally used or not > > > Commit: c1f96e71dd51c44f9aeff9cf5940982b939a8b24 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/c1f… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-06-11 (Mon, 11 Jun 2018) > > Changed paths: > M vehicle/OVMS.V3/main/ovms.cpp > M vehicle/OVMS.V3/main/ovms.h > > Log Message: > ----------- > Fix CONFIG_OVMS_HW_SPIMEM_AGGRESSIVE

1 0

OVMS v3.1 Production Batch #2
by Mark Webb-Johnson 06 Jun '18

06 Jun '18

Production batch #2 is done, and should be up on fasttech within the next day or so. A] 50x US kits (module + US modem) B] 145x EU kits (module + EU modem) C] 20x modules only (board + case, but no modem so wifi/bluetooth only) D] 5x extra optional EU modems E] 5x extra optional US modems All factory loaded with 3.1.006 firmware. Items [C], [D], and [E] will end up as new SKUs. These modules include the cp2102 to address the 12v power sd card issue, and now come in a nice padded foam cardboard box. Other than that, identical to batch #1. I’m arranging a one-off coupon code for the US$20 discount for existing OVMS v2 owners to upgrade, valid until the end of this month (June 2018). I’ll let you all know what that is, as soon as I get it. Beyond then, everyone pays full price. There are 200+ modules in this batch, so hopefully enough. If we run out too quickly, I’ll re-think this, but the project needs money to get the FCC+CE certifications, and that needs to come from somewhere. Regards, Mark.

4 7

It's Here!
by Greg D. 03 Jun '18

03 Jun '18

Hi Mark, The 3.1 module arrived in today's mail. I haven't plugged it in yet, but two "unboxing" observations... The unit looks really nice, though it seems that the top shell is a tad too wide and overlaps the bottom piece by nearly a mm on one corner. And, not evenly, at that; it's like the corner by the Vehicle connector got stretched a bit outward (or the other half pushed inward). The other two sides are all pretty evenly matched. The 3.0 proto unit was not like this. {shrug} Also, the two SMA dust caps seemed to have had some reaction with the adhesive on the flap of the padded envelope. They were stuck to the flap, pulled away from the connectors (so, not much dust protection), and the adhesive on the flap seemed to be very gooey in that area. The caps seemed to have been more or less unaffected, so it's more of a cosmetic issue. Perhaps they could point the module in the other direction (SMA end first), to prevent this in the future? My intent is to play "customer" with this unit, only using officially released code, updated through typical methods (i.e. not via the developer's kit) unless I need to do otherwise. I've got some short-term distractions through the weekend, but will take it out for a spin next week. Greg

6 15