- OvmsDev - Open Vehicles

CAN bus hacking
by Mark Webb-Johnson 26 Jul '18

26 Jul '18

For those of us working on vehicle support, I am concentrating on the last pieces for Tesla Roadster, ongoing work on Tesla Model S, and helping out Chris (in AU) to try to get Volt/Ampera ported (he has the car, I don’t). We have a lot of users waiting for Volt/Ampera support. For all of this, I’m trying to extend the RE tools and CAN frameworks to allow for OVMS to be used for CAN bus analysis and simulation. It is really coming together nicely, and it looks like the system is powerful enough to handle this admirably. I’m trying hard not to plug a USB-CAN adaptor into my car, or use any other desktop tools. This should bring the barrier to entry right down for new vehicle support. A few examples… Using ‘can rx’ to simulate an incoming CAN bus message and see what happens to metrics: OVMS# metrics trace on Metric tracing is now on OVMS# vehicle module VA I (26522) v-voltampera: Volt/Ampera vehicle module I (26522) metrics: Modified metric v.type: VA I (26582) metrics: Modified metric v.e.parktime: 26Sec I (27582) metrics: Modified metric v.e.parktime: 27Sec I (28582) metrics: Modified metric v.e.parktime: 28Sec OVMS# can can1 rx standard 135 01 I (49462) metrics: Modified metric v.e.on: yes I (49462) metrics: Modified metric v.e.awake: yes I (49462) metrics: Modified metric v.e.handbrake: no I (49582) metrics: Modified metric v.e.parktime: 0Sec OVMS# can can1 rx standard 4e1 42 55 31 30 32 36 38 39 OVMS# can can1 rx standard 514 47 31 52 44 36 45 34 36 I (94402) metrics: Modified metric v.vin: 1G1RD6E46BU102689 OVMS# can can1 rx standard 135 00 I (103342) metrics: Modified metric v.e.on: no I (103342) metrics: Modified metric v.e.awake: no I (103342) metrics: Modified metric v.e.handbrake: yes I (103582) metrics: Modified metric v.e.parktime: 1Sec I (104582) metrics: Modified metric v.e.parktime: 2Sec I (105582) metrics: Modified metric v.e.parktime: 3Sec I (106582) metrics: Modified metric v.e.parktime: 4Sec I (107582) metrics: Modified metric v.e.parktime: 5Sec I (108582) metrics: Modified metric v.e.parktime: 6Sec I (109582) metrics: Modified metric v.e.parktime: 7Sec I (110582) metrics: Modified metric v.e.parktime: 8Sec Showing CAN message changes, and discovering new messages (or bytes within that were not previously changing but now are): OVMS# re start OVMS# re mode analyse Now running in analyse mode OVMS# can can1 rx standard 100 01 02 03 04 OVMS# can can1 rx standard 101 01 02 03 04 OVMS# can can1 rx standard 102 01 02 03 04 OVMS# re discover list changed key records ms last can1/100 1 8000 01 02 03 04 | .... can1/101 1 8000 01 02 03 04 | .... can1/102 1 8000 01 02 03 04 | .... OVMS# re discover clear changed Cleared all change flags OVMS# can can1 rx standard 102 01 02 13 04 OVMS# re discover list changed key records ms last can1/102 2 15500 01 02 13 04 | .... OVMS# re mode discover Now running in discover mode OVMS# can can1 rx standard 102 01 02 13 04 OVMS# re discover list discovered key records ms last OVMS# can can1 rx standard 102 01 12 13 04 OVMS# re discover list discovered key records ms last can1/102 4 14500 01 12 13 04 | .... OVMS# can can1 rx standard 110 01 02 03 04 OVMS# re discover list discovered key records ms last can1/102 4 17500 01 12 13 04 | .... can1/110 1 70000 01 02 03 04 | .... A CRTD format can bus dump: I (372613) re: Log service connection from 10.8.8.83 OVMS# can can1 rx standard 120 01 02 03 04 OVMS# can can1 rx standard 121 01 02 03 04 OVMS# can can1 rx standard 121 DE AD BE AT I (466333) re: Log service disconnection from 10.8.8.83 $ telnet devbench.local 3000 Connected to devbench.local. 1524105901.244120 1R11 120 01 02 03 04 1524105905.794094 1R11 121 01 02 03 04 1524105915.194145 1R11 121 de ad be at The TODO list for this is huge, so it will progress as I have time to work on it (and as I hit a requirement for each unfinished part). For example, simulating CAN bus traffic (replaying) would be nice (something like ‘$ cat mylogfile.crtd | nc devbench.local 3000’) - and that is something I need now, so will probably come next (and is pretty trivial - just pickup on data coming in the tcp/3000, decode it, and either simulate reception or transmit it on the actual car bus). The whole decoding/encoding thing (where we use DBC or whatever to say key X byte Y is converted to v.bat.soc using this formula) is of course the holy grain of this; and is built upon all the foundation I’m laying now. The end goal remains for vehicle modules with just a DBC (or whatever) and no actual code. It is all command line at the moment, but this could be very very cool using Michael’s web framework (particularly with real-time websocket updates). Regards, Mark.

2 6

nmc_list and ListConnections
by Mark Webb-Johnson 26 Jul '18

26 Jul '18

I am seeing quite a few crashes from my modules, like this: # xtensa-esp32-elf-addr2line -pfiaC -e 3.1.008-76-ga33b30e.ovms3.elf 0x4008fac5 0x40090355 0x4008f23f 0x400914a1 0x40083e6a 0x4020c6b3 0x400f514d 0x400f69cb 0x400f6d95 0x400f705f 0x400f3cba 0x400eafe6 0x400eb035 0x4008fac5: uxPortCompareSet at /home/openvehicles/build/esp-idf/components/freertos/tasks.c:3564 (inlined by) vPortCPUAcquireMutexIntsDisabledInternal at /home/openvehicles/build/esp-idf/components/freertos/portmux_impl.inc.h:86 (inlined by) vPortCPUAcquireMutexIntsDisabled at /home/openvehicles/build/esp-idf/components/freertos/portmux_impl.h:98 (inlined by) vTaskEnterCritical at /home/openvehicles/build/esp-idf/components/freertos/tasks.c:4267 0x40090355: xTaskIncrementTick at /home/openvehicles/build/esp-idf/components/freertos/tasks.c:3564 0x4008f23f: xPortSysTickHandler at /home/openvehicles/build/esp-idf/components/freertos/port.c:406 0x400914a1: _frxt_timer_int at /home/openvehicles/build/esp-idf/components/freertos/portasm.S:303 0x40083e6a: _xt_lowint1 at /home/openvehicles/build/esp-idf/components/freertos/xtensa_vectors.S:1105 0x4020c6b3: esp_vApplicationWaitiHook at /home/openvehicles/build/esp-idf/components/esp32/freertos_hooks.c:66 0x400f514d: mg_sock_addr_to_str at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f69cb: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f6d95: mg_mgr_handle_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f705f: mg_socket_if_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f3cba: mg_add_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400eafe6: OvmsNetManager::ListConnections(int, OvmsWriter*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:685 0x400eb035: OvmsNetManager::CloseConnection(unsigned int) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:702 [root@markhk8 edge]# xtensa-esp32-elf-addr2line -pfiaC -e 3.1.008-76-ga33b30e.ovms3.elf 0x400f6893 0x400f7edc 0x4011e623 0x4011e729 0x4011e9e2 0x400f8306 0x400f514d 0x400f69cb 0x400f6d95 0x400f705f 0x400f3cba 0x400eafe6 0x400eb035 0x400f6893: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f7edc: mg_send_mqtt_handshake_opt at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x4011e623: OvmsServerV3::Ticker1(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_server_v3/src/ovms_server_v3.cpp:841 0x4011e729: OvmsServerV3::IncomingPubRec(int) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_server_v3/src/ovms_server_v3.cpp:488 0x4011e9e2: OvmsServerV3MongooseCallback(mg_connection*, int, void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_server_v3/src/ovms_server_v3.cpp:66 0x400f8306: parse_mqtt at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 (inlined by) mqtt_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:10606 0x400f514d: mg_sock_addr_to_str at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f69cb: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f6d95: mg_mgr_handle_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f705f: mg_socket_if_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f3cba: mg_add_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400eafe6: OvmsNetManager::ListConnections(int, OvmsWriter*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:685 0x400eb035: OvmsNetManager::CloseConnection(unsigned int) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:702 Apart from the massive stack, it seems very strange that we would be calling OvmsNetManager::ListConnections() and CloseConnection(). I guess the stack is messed up, or this is some other remnant of a previous call? Any ideas? Mark

2 1

Linker error: uxTaskGetSystemState
by Geir Øyvind Vælidalo 25 Jul '18

25 Jul '18

Hi guys! I got the latest from master and also did pull the latest from esp-idf, but when I run make I get this linker error: ylfest:OVMS.V3 goev$ make LD build/ovms3.elf /Users/goev/git/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/main/libmain.a(ovms_utils.o):(.literal._Z13TaskGetHandlePKc+0x4): undefined reference to `uxTaskGetSystemState' /Users/goev/git/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/main/libmain.a(ovms_utils.o): In function `TaskGetHandle(char const*)': /Users/goev/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:159: undefined reference to `uxTaskGetSystemState' collect2: error: ld returned 1 exit status make: *** [/Users/goev/git/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf] Error 1 Any ideas? Best regards, Geir

2 1

CAN throughput & latency optimization
by Michael Balzer 23 Jul '18

23 Jul '18

I've pushed my latest changes to optimize CAN throughput & latency, which had problems before and have become worse with aggressive SPIRAM usage. There especially were too many RX overflows and TX delays now. The Twizy module needs to respond to some frames as fast as possible, and the delays added up to over 120 ms in some circumstances. I first moved the esp32can ISR and instance into internal RAM, then applied that change to all peripheral objects. To allocate objects of some class in internal RAM, simply add the super class InternalRamAllocated to it (counterpart to ExternalRamAllocated), i.e. class SevconClient : public InternalRamAllocated This eliminated RX overflows (except some on init when starting the module/bus with running transmissions on the bus -- don't know yet if we can avoid them), and helped a bit with TX delays. Moving the vehicle instance into internal RAM also helped a bit with TX latency, but together only reduced it by about 10%. So I also added a synchronous callback mechanism to the CAN system to be able to run a CAN responder directly within the CAN rxtask context. See the Twizy CanResponder() in module rt_can for an example: void OvmsVehicleRenaultTwizy::CanResponder(const CAN_frame_t* p_frame); MyCan.RegisterCallback(TAG, std::bind(&OvmsVehicleRenaultTwizy::CanResponder, this, _1)); This reduced TX delays to zero most of the time. From time to time some delays still occurred, not continously but in chunks and only every few minutes. I think they were caused by the Wifi stack, because they seem to have disappeared after rearranging the CAN rxtask to be running at priority 23 and reducing the Wifi task priority to 22, but I need to collect some more data on this. The new build is in my "edge" directory. Placing the peripherals in internal RAM potentially solves other issues as well -- it's certainly not good if a peripheral component has to wait for an SPIRAM page-in operation. But I've had no reproducable issues before I could test now. We need to test this in the field. Regarding the issues with can2 & can3: I don't think they are related to this, but it's worth a try. The mcp2515 instances are in internal RAM now as well. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 1

UDS/ISO-TP Query
by Fran Terry 19 Jul '18

19 Jul '18

Hello One & All, I am in the process of getting the smart ED (451) working on v3, have not had an issue getting data out via normal PID requests. However I am having issues with talking to the BMS & Charger, it might me being a noob, but I can't work out the best way to do UDS/ISO-TP. For instance I need to send the following packet to: 0x7E7 03 22 02 08 FF FF FF FF I need to then pick up the following from 0x7EF: 11 93 62 02 08 0E A7 0E I also need to send flow control frames, basically speak ISO-TP. I can see in the TR code how to send a frame via CAN, however not sure how to pick up the response and talk ISO-TP Hope that makes sense, Thanks Fran

2 1

Module passwords shorter than 8 characters
by Nikolay Shishkov 12 Jul '18

12 Jul '18

Hi all, I have managed to install 2 V.3 boxes on two Think City A306 and the basic functionality works great - I am able to see the SOC, position, battery temperature. I will be measuring power consumption and look at logging and adding more parameters in near future. I had a few wows that came from me not reading documentation and one that I could not find in the documentation. The undocumented one was that I was able to set password to "test" - it was just for testing on the bench, and I was no longer able to find the access point... when I connected via usb cable and terminal I could see that the process for the AC was complaining that the module password was too short and aborted startup. I haven't tested this in the latest update, but wanted to put it out there in case any of you run in to it. Nikolay On Thursday, July 12, 2018, 11:40:49 AM GMT+2, Mark Webb-Johnson <mark(a)webb-johnson.net> wrote: Just seems wasteful to have a dozen metrics for this. Expensive in ram, bandwidth, and mqtt. Every vehicle module would have to set the unused ones to ‘no’ (due to the way mqtt retained topics work). If we add a new capability, all the vehicle modules would have to be changed to set it to ’no'. Your suggestion is cleaner, but more expensive. Regards, Mark. > On 12 Jul 2018, at 5:34 PM, Robin O'Leary <ovmsdev(a)caederus.org> wrote: > > On Thu, Jul 12, 2018 at 08:56:25AM +0800, Mark Webb-Johnson wrote: >> I think the capabilities are useful, but need to be done in a better, more future-proof, way. Relying on protocol v2 commands is limited. > ... >> My suggestion is: >> >> Create a standard metric ‘v.capabilities’. >> Have the vehicle modules set that metric with their capabilities, as a comma-separated list of the commands supported: > > Mapping things to strings seems rather roundabout. > Would it not be better to have individual boolean capabilities? > > v.capability.chargemode = yes/no > ... > v.capability.climate = yes/no > _______________________________________________ > OvmsDev mailing list > OvmsDev(a)lists.openvehicles.com > http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

2 2

Nissan Leaf Support Request
by Mark Webb-Johnson 12 Jul '18

12 Jul '18

A user has a raised a ticket: https://www.openvehicles.com/node/2053 <https://www.openvehicles.com/node/2053> I would like to be able to turn my A/C on and off remotely as discussed http://www.arachnon.de/wb/pages/en/nissan-leaf/ovms.php <http://www.arachnon.de/wb/pages/en/nissan-leaf/ovms.php> here. When I use their version of the OVMS app it just crashes repeatedly after I input my car's settings so I can't use it. However when I use the play market version of the app, there is no A/C button but it runs solidly and I can see my car's information (it works). Is there a way to turn the A/C on and off with this version of the app? Also, I'm assuming (perhaps incorrectly) that the latest hardware already has the features built in and no flashing is necessary. Bonus questions: In the app it seems there's an ability to unlock my car and to put it in valet mode but those features need a pin. Where does this pin come from and do the features really work? What is valet mode anyway? What is the 'Features' section of the app for? I see that I need to set my #15 CAN Write to 1 before I can expect the A/C control to work which I've done but is there any info on what the rest of it does? Server: 2.1.1-20121216 Car: 3.1.006 App: 3.12.4 (20180428 Update: The remote A/C worked with homelink 1 and 2 when I got home to charge. I don't have a model with navigation or car wings so I don't think I have the option mentioned about when to allow remote A/C with respect to SOC level. Is it possible that there's a way to set this option with the OVMS? Can a Nissan Leaf developer/expert help out with this? Regards, Mark

3 7

Missing submodule init in Development Guide.
by Jakob Löw 11 Jul '18

11 Jul '18

Hey, the development guide states: Git clone the OVMS v3 repository and init the build configuration: $ git clone https://github.com/openvehicles/Open-Vehicle-Monitoring-Sys tem-3.git $ cd Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3 $ cp support/sdkconfig.default.hw31 sdkconfig $ make menuconfig This does not initialize the mongoose submodule and thus does not work. Either a --recursive has to be added to the git clone or git submodule update --init has to be run. Unfortunately I do not have access to the Google Doc, so I can't change it. See this issue on github: https://github.com/openvehicles/Open-Vehicle- Monitoring-System-3/issues/140 - Jakob

2 1

GPS / NMEA integration
by Michael Balzer 11 Jul '18

11 Jul '18

I'm currently working on the NMEA module. The MUX channel is working, but I don't get a GPS fix. I've tried all GPS commands and now suspect my SIMCOM module having a hardware issue. I'm doing this: OVMS > level debug OVMS > power simcom on …wait for the MUX to be ready, then issue… OVMS > simcom muxtx 4 AT+CGPSNMEA=1 OVMS > simcom muxtx 4 AT+CGPS=1,1 …now the SIMCOM begins sending NMEA $GPGGA lines once per second looking like this: D (2937174) SIMCOM rx: f9 05 ff 35 24 47 50 47 47 41 2c 2c 2c 2c 2c 2c ...5*$GPGGA,,,,,,* D (2937174) SIMCOM rx: 30 2c 2c 2c 2c 2c 2c 2c 2c 2a 36 36 0d 0a 60 f9 *0,,,,,,,,*66*..`. Normally the modem should get a GPS fix within about 1-2 minutes and begin filling data in the $GPGGA record. But my modem won't, it just keeps sending empty fields. Can someone please try this with his/her module? To disable the GPS receiver, issue: OVMS > simcom muxtx 4 AT+CGPS=0 Thanks & regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

7 30

Re: [Ovmsdev] Leaf
by Dean MacGregor 10 Jul '18

10 Jul '18

I'm using the play store version 3.12.4 and I don't have the AC button. It's not that big of a deal except that I can't see whether or not the AC is on from the app. Also it seems like since the recent OTA update my app always says my doors are unlocked even when they are locked. On Thu, Jul 5, 2018 at 5:42 AM, ovmsdev-request(a)lists.openvehicles.com<ovmsdev-request(a)lists.openvehicles.com> wrote: Send OvmsDev mailing list submissions to ovmsdev(a)lists.openvehicles.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.openvehicles.com/mailman/listinfo/ovmsdev or, via email, send a message with subject or body 'help' to ovmsdev-request(a)lists.openvehicles.com You can reach the person managing the list at ovmsdev-owner(a)lists.openvehicles.com When replying, please edit your Subject line so it is more specific than "Re: Contents of OvmsDev digest..." Today's Topics: 1. Re: Can buses stop after some time (Stein Arne Sordal) 2. Re: Can buses stop after some time (Tom Parker) 3. Re: Nissan Leaf Support Request (Tom Parker) 4. Re: MQTT and Ovms Server v3 (Jakob L?w) ---------------------------------------------------------------------- Message: 1 Date: Thu, 5 Jul 2018 08:34:17 +0200 From: Stein Arne Sordal <ovms(a)topphemmelig.no> To: OVMS Developers <ovmsdev(a)lists.openvehicles.com> Subject: Re: [Ovmsdev] Can buses stop after some time Message-ID: <B62B646E-7129-4A61-B928-467E83EC32B1(a)topphemmelig.no> Content-Type: text/plain; charset=utf-8 Did anyone figure out what happens here? Now the OVMS thinks my car is stolen since it?s moving (GPS) and CAN2 is dead. Reboot of module brings CAN2 back to life for a period of time. -Stein Arne Sordal- > On 11 May 2018, at 12:29, Stein Arne Sordal <ovms(a)topphemmelig.no> wrote: > > Hi Tom > > I have seen this with my Leaf. > I?ve been on vacation, so I haven?t got time to test a lot, but it looks like one of the can buses stops. Started testing again today. > > -Stein Arne Sordal- > > > >> On 11 May 2018, at 12:22, Tom Parker <tom(a)carrott.org> wrote: >> >> Hi all, >> >> I synced up with master about a week ago and since then I've seen both can busses stop working. I still see the 12v battery metric changing, but everything that comes from the car stops. Rebooting the module with "module reset" does not seem to fix it, while make app-flash monitor does fix it. I haven't tried make monitor on it's own. >> >> Is anyone else seeing behavior like this? >> >> Sorry for the vague bug report. I'll spend some time later this weekend to try to gather more information. >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev(a)lists.openvehicles.com >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev > > _______________________________________________ > OvmsDev mailing list > OvmsDev(a)lists.openvehicles.com > http://lists.openvehicles.com/mailman/listinfo/ovmsdev ------------------------------ Message: 2 Date: Thu, 5 Jul 2018 19:55:05 +1200 From: Tom Parker <tom(a)carrott.org> To: ovmsdev(a)lists.openvehicles.com Subject: Re: [Ovmsdev] Can buses stop after some time Message-ID: <8e2964d0-047e-7f27-9eaa-daf9cd14f6a0(a)carrott.org> Content-Type: text/plain; charset=utf-8; format=flowed I haven't had a chance to try to work out what is going on. I can say that the second can interface doesn't work for very long before stopping. This manifests most obviously on my Leaf as a stopped odometer in the OVMS app. If you look at the metrics in the console then everything that comes from the Car CAN bus (ie the second CAN bus) has frozen. The first CAN interface seems much more reliable, with SOC information from the EV bus being fairly reliably reported. I haven't done the modification to make my 3.0 unit's GPS work so I haven't experienced the stolen detection. On 05/07/18 18:34, Stein Arne Sordal wrote: > Did anyone figure out what happens here? > Now the OVMS thinks my car is stolen since it?s moving (GPS) and CAN2 is dead. > Reboot of module brings CAN2 back to life for a period of time. > > -Stein Arne Sordal- > > > >> On 11 May 2018, at 12:29, Stein Arne Sordal <ovms(a)topphemmelig.no> wrote: >> >> Hi Tom >> >> I have seen this with my Leaf. >> I?ve been on vacation, so I haven?t got time to test a lot, but it looks like one of the can buses stops. Started testing again today. >> >> -Stein Arne Sordal- >> >> >> >>> On 11 May 2018, at 12:22, Tom Parker <tom(a)carrott.org> wrote: >>> >>> Hi all, >>> >>> I synced up with master about a week ago and since then I've seen both can busses stop working. I still see the 12v battery metric changing, but everything that comes from the car stops. Rebooting the module with "module reset" does not seem to fix it, while make app-flash monitor does fix it. I haven't tried make monitor on it's own. >>> >>> Is anyone else seeing behavior like this? >>> >>> Sorry for the vague bug report. I'll spend some time later this weekend to try to gather more information. >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev(a)lists.openvehicles.com >>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev(a)lists.openvehicles.com >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev > _______________________________________________ > OvmsDev mailing list > OvmsDev(a)lists.openvehicles.com > http://lists.openvehicles.com/mailman/listinfo/ovmsdev ------------------------------ Message: 3 Date: Thu, 5 Jul 2018 20:34:34 +1200 From: Tom Parker <tom(a)carrott.org> To: ovmsdev(a)lists.openvehicles.com Subject: Re: [Ovmsdev] Nissan Leaf Support Request Message-ID: <85109d8f-31ba-245e-40bf-50b0351f13fc(a)carrott.org> Content-Type: text/plain; charset="windows-1252"; Format="flowed" On 01/07/18 21:23, Mark Webb-Johnson wrote: > A user has a raised a ticket: > > https://www.openvehicles.com/node/2053 > I can't see this link > > I would like to be able to turn my A/C on and off remotely as > discussed > http://www.arachnon.de/wb/pages/en/nissan-leaf/ovms.php?here. When > I use their version of the OVMS app it just crashes repeatedly > after I input my car's settings so I can't use it. However when I > use the play market version of the app, there is no A/C button but > it runs solidly and I can see my car's information (it works). Is > there a way to turn the A/C on and off with this version of the > app? Also, I'm assuming (perhaps incorrectly) that the latest > hardware already has the features built in and no flashing is > necessary. > You want to use the play store version. I'm running 3.12.4 from the Play store and when connected to a Leaf, I see the AC button. > Bonus questions: > In the app it seems there's an ability to unlock my car and to put > it in valet mode but those features need a pin. Where does this > pin come from and do the features really work? What is valet mode > anyway? > Not all cars support lock and unlock or valet mode. We have some code that works for lock/unlock on the Leaf but it's not yet finished. There are no plans to support valet mode. > What is the 'Features' section of the app for? I see that I need > to set my #15 CAN Write to 1 before I can expect the A/C control > to work which I've done but is there any info on what the rest of > it does? > You don't need this for OVMS v3. > Server: 2.1.1-20121216 > Car: 3.1.006 > App: 3.12.4 (20180428 > Update: The remote A/C worked with homelink 1 and 2 when I got > home to charge. I don't have a model with navigation or car wings > so I don't think I have the option mentioned about when to allow > remote A/C with respect to SOC level. Is it possible that there's > a way to set this option with the OVMS? > We still support climate control with homelink 1 & 2 for old apps. This at least lets use separate your climate control button problem questions about how the AC works. Which model year Leaf do you have? Older than 2013 may require extra hardware to enable climate control when the car is asleep. 2013 through 2015 use a different remote climate control to that of 2016 & 2017. You have to set the module year configuration option to tell the OVMS which car you have. 2018 Leafs are not yet supported. We made a change to how the climate control is switched off recently and this is probably in the latest firmware (which you don't have on your OVMS). We don't have a way way to configure the remote climate control -- the OVMS simply sends the enable command to the car and the car does it's thing.

2 1