February 2019 - OvmsDev - Open Vehicles

Nissan Leaf - Stop Charge
by Lance Tjessem 19 Feb '19

19 Feb '19

You'd think there would be a way to stop charging - if you have the vehicle plugged in but not charging and start climate control it will activate charging, then stop charging when you turn CC off. Also, lock/unlock don't seem to work on my 2015 S, is it only for specific models?

2 1

Nissan Leaf - Stop Charge
by Mark Webb-Johnson 18 Feb '19

18 Feb '19

Interesting question on a support ticket: Why is ‘stop charge’ not implemented on Nissan Leaf? We have vehicle codes for door lock/unlock and start charge, but not stop? Regards, mark.

2 1

OTA download incremental progress no longer happens
by Craig Leres 17 Feb '19

17 Feb '19

When doing an OTA download the download progress used to incrementally display, e.g. it would start with: Processing… (do not interrupt, may take some minutes) and then slowly spit out a bunch of lines like this: Downloading... (100029 bytes so far) And then finish with a form offering to reboot or whatever. This has been broken for a few versions now. Basically when you start the OTA download you get the initial dialog and then nothing happens until the download completes and then you see the rest of the output at once. I normally use firefox but the behavior is the same with chorme. Craig

3 3

Collecting information on the Fiat 500e
by Jason Perkins 15 Feb '19

15 Feb '19

OVMS team, As an owner of a Fiat 500e I was very interested when I stumbled across this project on the TMC forums. The Fiat factory telematics system deactivates 3 years from the original vehicle sale and is non renewable. I think FCA wants to kill the whole system at this point (it's been replaced with the corporate UConnect system) so another solution would be ideal. I have a 2013 500e with deactivated telematics, and our roommate has a 2014 with working telematics. If any data could be captured from the car with working telematics (branded as Fiat Access) to assist integrating OVMS I'd love to help. The Fiat Access telematics provides vehicle location, battery level, tire pressure, setting the charge schedules, locking / unlocking the car, and starting the climate control. I believe the actual control unit was adapted from some kind of remote-disablement system used in europe (the Fiat literature calls this the Vehicle Tracking Module). The Fiat has a normal J1962 plug, but does not have OBDII protocol support. Like the Kia Soul the powertrain CAN on pin 6 / 14 and the body CAN on 1 / 9. There's no telling how long the telematics will keep working on our roommates '14, so doing a capture sooner than later would be good. I'm open to any suggestions on how best to do this. The car related diag tools I have on hand are: ELM327 Bluetooth, Ross-Tech VCDS (For VW / Audi Products), and AlfaOBD (which can talk to most of the modules in the 500e - but not the VTM :( ), and an adapter to swap the CAN wires so a standard interface can get to the Body CAN. Thanks! -J

5 28

DBC and Endian-ness
by Mark Webb-Johnson 12 Feb '19

12 Feb '19

I’ve been going round and round in circles on this, most of the weekend, but not getting anywhere. I’ve rewritten the Decoder code four times so far, but just can’t get it to work. So calling for help here. I attach the DBC specification. You can also find an extensive python library here: https://github.com/eerimoq/cantools.git (for anyone playing with DBC, that seems an excellent library and set of command line tools) The seemingly simple problem that I am trying to solve is: Given a CAN frame, we need to decode a particular signal. We want the integer value (signed or unsigned) out of it. The signal species the start bit, size (number of bits), endian-ness (big or little), and value type (signed or unsigned). The DBC specification says: The start_bit value specifies the position of the signal within the data field of the frame. For signals with byte order Intel (little endian) the position of the least-significant bit is given. For signals with byte order Motorola (big endian) the position of the most significant bit is given. The bits are counted in a saw-tooth manner. byte_order = '0' | '1' (* 0=little endian, 1=big endian *) The byte_format is 0 if the signal's byte order is Intel (little endian) or 1 if the byte order is Motorola (big endian). There are also factor and offset values for signals, but that is irrelevant for the moment (trivial to apply once we have the actual integer raw signal value extracted) and can be ignored for the moment. Wikipedia explains endian-ness: In big-endian format, whenever addressing memory or sending/storing words bytewise, the most significant byte—the byte containing the most significant bit—is stored first (has the lowest address) or sent first, then the following bytes are stored or sent in decreasing significance order, with the least significant byte—the one containing the least significant bit—stored last (having the highest address) or sent last. Little-endian format reverses this order: the sequence addresses/sends/stores the least significant byte first (lowest address) and the most significant byte last (highest address). So, we have two strange things in the DBC specification: (1) the start bit is not always the first bit in the stream, and (2) this ’saw-tooth manner’ comment. So, I create a very simple DBC, and run it through the cantools dump to visualise it: $ cat mark.dbc BU_: WS200 MCN_Powertrain BO_ 1 LittleEnd: 8 WS200 SG_ OneByte : 7|8@0+ (1,0) [0|0] "" Vector__XXX SG_ TwoByte : 15|16@0+ (1,0) [0|0] "" Vector__XXX SG_ TwelveBit : 39|12@0+ (1,0) [0|0] "" Vector__XXX $ cantools dump mark.dbc ================================= Messages ================================= ------------------------------------------------------------------------ Name: LittleEnd Id: 0x1 Length: 8 bytes Cycle time: - ms Senders: WS200 Layout: Bit 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ 0 |<-----------------------------x| +---+---+---+---+---+---+---+---+ +-- OneByte +---+---+---+---+---+---+---+---+ 1 |<------------------------------| +---+---+---+---+---+---+---+---+ 2 |------------------------------x| +---+---+---+---+---+---+---+---+ B +-- TwoByte y +---+---+---+---+---+---+---+---+ t 3 | | | | | | | | | e +---+---+---+---+---+---+---+---+ 4 |<------------------------------| +---+---+---+---+---+---+---+---+ 5 |--------------x| | | | | +---+---+---+---+---+---+---+---+ +-- TwelveBit +---+---+---+---+---+---+---+---+ 6 | | | | | | | | | +---+---+---+---+---+---+---+---+ 7 | | | | | | | | | +---+---+---+---+---+---+---+---+ Signal tree: -- {root} +-- OneByte +-- TwoByte +-- TwelveBit ------------------------------------------------------------------------ I also used 'cantools generate_c_source mark.dbc’ to generate a C decoder for this, and this is what it looks like: int mark_little_end_unpack( struct mark_little_end_t *dst_p, const uint8_t *src_p, size_t size) { if (size < 8u) { return (-EINVAL); } memset(dst_p, 0, sizeof(*dst_p)); dst_p->one_byte |= unpack_right_shift_u8(src_p[0], 0u, 0xffu); dst_p->two_byte |= unpack_left_shift_u16(src_p[1], 8u, 0xffu); dst_p->two_byte |= unpack_right_shift_u16(src_p[2], 0u, 0xffu); dst_p->twelve_bit |= unpack_left_shift_u16(src_p[4], 4u, 0xffu); dst_p->twelve_bit |= unpack_right_shift_u16(src_p[5], 4u, 0xf0u); return (0); } Let’s look at that TwoByte value. This is little endian, so the least significant byte should come first in p[1] followed by the most significant in p[2]. So, why does the generator produce: dst_p->two_byte |= unpack_left_shift_u16(src_p[1], 8u, 0xffu); dst_p->two_byte |= unpack_right_shift_u16(src_p[2], 0u, 0xffu); From what I can see, that means take p[1] and shift it left 8, then add on p[2]. That seems big endian, not little endian? Let’s try a big endian example: BO_ 3 BigEnd2: 8 WS200 SG_ EightBit2 : 5|8@1+ (1,0) [0|0] "" Vector__XXX SG_ OneByte2 : 16|8@1+ (1,0) [0|0] "" Vector__XXX SG_ TwelveBit2 : 48|11@1+ (1,0) [0|0] "” Vector__XXX Bit 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ 0 |----------x| | | | | | +---+---+---+---+---+---+---+---+ 1 | | | |<------------------| +---+---+---+---+---+---+---+---+ +-- EightBit2 +---+---+---+---+---+---+---+---+ 2 |<-----------------------------x| +---+---+---+---+---+---+---+---+ B +-- OneByte2 y +---+---+---+---+---+---+---+---+ t 3 | | | | | | | | | e +---+---+---+---+---+---+---+---+ 4 | | | | | | | | | +---+---+---+---+---+---+---+---+ 5 | | | | | | | | | +---+---+---+---+---+---+---+---+ 6 |------------------------------x| +---+---+---+---+---+---+---+---+ 7 | | | | | |<----------| +---+---+---+---+---+---+---+---+ +-- TwelveBit2 Notice the weird alignment of EightBit2 and TwelveBit2? I presume that is the ’saw-tooth’ pattern talked about in the DBC specification. A Tesla Model S encodes values like the battery temperature in CAN ID 0x102, and we decode this in C like this: StandardMetrics.ms_v_bat_temp->SetValue((float)((((int)d[7]&0x07)<<8)+d[6])/10); So that is little endian (d[7] is shifted right, followed by d[6] normally - so d[7] is the MSB and d[6] the LSB). But how to represent that in DBC? BO_ 1 LittleEnd2: 8 WS200 SG_ TwoByte : 47|11@0+ (1,0) [0|0] "” Vector__XXX Bit 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ 0 | | | | | | | | | +---+---+---+---+---+---+---+---+ 1 | | | | | | | | | +---+---+---+---+---+---+---+---+ 2 | | | | | | | | | +---+---+---+---+---+---+---+---+ B 3 | | | | | | | | | y +---+---+---+---+---+---+---+---+ t 4 | | | | | | | | | e +---+---+---+---+---+---+---+---+ 5 |<------------------------------| +---+---+---+---+---+---+---+---+ 6 |----------x| | | | | | +---+---+---+---+---+---+---+---+ +-- TwoByte +---+---+---+---+---+---+---+---+ 7 | | | | | | | | | +---+---+---+---+---+---+---+—+ dst_p->two_byte |= unpack_left_shift_u16(src_p[5], 3u, 0xffu); dst_p->two_byte |= unpack_right_shift_u16(src_p[6], 5u, 0xe0u); That doesn’t work. How about big endian? BO_ 1 BigEnd2: 8 WS200 SG_ TwoByte : 48|11@1+ (1,0) [0|0] "” Vector__XXX Bit 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ 0 | | | | | | | | | +---+---+---+---+---+---+---+---+ 1 | | | | | | | | | +---+---+---+---+---+---+---+---+ 2 | | | | | | | | | +---+---+---+---+---+---+---+---+ B 3 | | | | | | | | | y +---+---+---+---+---+---+---+---+ t 4 | | | | | | | | | e +---+---+---+---+---+---+---+---+ 5 | | | | | | | | | +---+---+---+---+---+---+---+---+ 6 |------------------------------x| +---+---+---+---+---+---+---+---+ 7 | | | | | |<----------| +---+---+---+---+---+---+---+---+ +— TwoByte dst_p->two_byte |= unpack_right_shift_u16(src_p[6], 0u, 0xffu); dst_p->two_byte |= unpack_left_shift_u16(src_p[7], 8u, 0x07u); That seems correct. Looking in the source for cantools dbc (cantools/cantools/database/can/formats/dbc.py), I see: byte_order=(0 if signal.byte_order == 'big_endian' else 1), This code also says the same thing (0 = big endian): https://github.com/julietkilo/CANBabel/blob/master/src/main/java/com/github… boolean isBigEndian = "0".equals(splitted[2]); WTF? There is this (from googling), which makes things clear as mud: https://github.com/ebroecker/canmatrix/wiki/signal-Byteorder https://se.mathworks.com/help/vnt/ug/canpack.html https://github.com/ebroecker/SocketCandecodeSignals/blob/master/datenbasis.… https://github.com/julietkilo/CANBabel/blob/master/src/main/java/com/github… My conclusions are that: The DBC specification is incorrect, in that 0 is big endian, and 1 is little endian in the public code we see. and/or The DBC specification is incorrect, in that all CAN bus byte ordering is little endian, and the byte_order setting only affects the interpretation of the bit_ordering, and saw-tooth decode/encode. But that really makes no sense to me. This is supposed to be the defacto standard for automotive CAN bus signal definition - how can it be such a mess? Help? Mark

2 2

Smart ED
by Mark Webb-Johnson 11 Feb '19

11 Feb '19

Can someone working on Smart ED help to update this forum post with current status: https://www.openvehicles.com/node/2097 Thanks, Mark

1 0

User guide update for Nissan Leaf
by Anko Hanse 06 Feb '19

06 Feb '19

With the inclusion of fix #170, "Fix for 0% SOH on 30KWh models with Nissan BMS update" in the new 3.2.001 firmware, the user guide needs updating. I do not seem to have the right to do that, so can someone do it for me? It concerns the "OVMS v3 Advanced User Guide", Chapter "NL Nissan Leaf", section "Configuration": - The former [2016] section title should be updated to [2016-2017] - The section about the 30 kwh models should be taken out of the [2016-2017] section and into its own section (there are 2015 30 kwh models, I own one...) - The new section about the 30kwh models needs an extra command to also update the "newCarAh" setting to 79 (from 66) Full new text: [2011-2015 models] To enable remote commands, either Unplug any CARWINGS, Nissan Connection or TCU units or on Generation 1 Cars, wire the RC3 to TCU pin 11 (see MyNissanLeaf post) [2016-2017 models] Set the model year as follows config set xnl modelyear 2016 or config set xnl modelyear 2017 [30 kwh models] For models with a 30 kwh battery pack, set the capacity manually as follows config set xnl maxGids 356 config set xnl newCarAh 79

4 5

Mitsubishi i-MiEV and clones
by Tamás Kovács 06 Feb '19

06 Feb '19

I want to add support for 80 cell cars , the i-Miev has 88 cell all model year, but the clones are 80 cell from 2013 model year. What's the good implement for this. 1) Create a config, and user can set it 2) Automatically get from VIN number and set it. And a nother question, where set the BmsSetCellArrangementVoltage() and BmsSetCellArrangementTemperature(); Now set in OvmsVehicleMitsubishi::OvmsVehicleMitsubishi() I now created the first for testing. I added BmsSetCellArrangementVoltage(80,8) BmsSetCellArrangementTemperature(60, 6) in: void OvmsVehicleMitsubishi::ConfigChanged(OvmsConfigParam* param) if checkbox checked, but in dasboard show all the 88 cell data if set to 80 cell. This is because the vestor has 88 values, or because 80/88 cell cars delivers 88 cell values? I don't understand why send 80 cell cars 88 cell data (8 fake?) If i add "MyConfig.GetParamValueBool("vehicle", "bms.alerts.enabled", false);" to OvmsVehicleMitsubishi::OvmsVehicleMitsubishi() i can disable bms alerts for default?

2 1

Leaf SOH
by Dean MacGregor 06 Feb '19

06 Feb '19

The SOH did come back the next time I started the car. Thanks. On Tue, Feb 5, 2019 at 12:23 PM, 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. LEAF SOH (was: OvmsDev Digest, Vol 85, Issue 5) (Robin O'Leary) 2. Re: LEAF SOH (Robin O'Leary) 3. Re: Collecting information on the Fiat 500e (Guenther Huck) 4. Re: Collecting information on the Fiat 500e (Guenther Huck) ---------------------------------------------------------------------- Message: 1 Date: Tue, 5 Feb 2019 10:29:04 +0000 From: Robin O'Leary <ovmsdev(a)caederus.org> To: OVMS Developers <ovmsdev(a)lists.openvehicles.com> Subject: [Ovmsdev] LEAF SOH (was: OvmsDev Digest, Vol 85, Issue 5) Message-ID: <20190205102904.GB19577(a)mail.ro.nu> Content-Type: text/plain; charset=iso-8859-1 On Tue, Feb 05, 2019 at 02:46:40AM +0000, Dean MacGregor wrote: > With the new firmware version the SOH reading doesn't work but it used > to.? That's in both the 'Vehicle Info' and 'metrics list' command. > I have a 2015 Nissan Leaf.? Is this with the car switched off? Can you check with the the car ready to drive? Most other values we display are passively read whenever the can bus is active, but to get more detailed values from the battery (v.b.soh, xnl.v.b.hx, v.b.cac), we need to send an active poll request. We don't want to do this when the car is asleep, since it causes modules to wake up and consume power. We did previously get v.b.soh from a passive message 0x5b3, which is a 7-bit value (0--100%) available whenever the car is awake. The active poll to 0x7bb.6101 gives better resolution (~11 bits). We had a similar situation with the SOC, where I think we have a better solution. We now report both low- and high-resolution values as separate LEAF-specific metrics: the simple percentage in xnl.v.b.soc.instrument and the high-resolution value scaled as a proportion of the "new car" value as xnl.v.b.soc.newcar. By default, the standard metric v.b.soc reports the value from xnl.v.b.soc.instrument; there is a config option if you want it to report xnl.v.b.soc.newcar instead. I think it would be better if we followed the same pattern with SOH. ------------------------------ Message: 2 Date: Tue, 5 Feb 2019 13:16:47 +0000 From: Robin O'Leary <ovmsdev(a)caederus.org> To: OVMS Developers <ovmsdev(a)lists.openvehicles.com> Subject: Re: [Ovmsdev] LEAF SOH Message-ID: <20190205131647.GD19577(a)mail.ro.nu> Content-Type: text/plain; charset=us-ascii On Tue, Feb 05, 2019 at 10:29:04AM +0000, Robin O'Leary wrote: > ... > We did previously get v.b.soh from a passive message 0x5b3, which is a > 7-bit value (0--100%) available whenever the car is awake. The active > poll to 0x7bb.6101 gives better resolution (~11 bits). > > We had a similar situation with the SOC, where I think we have a better > solution. We now report both low- and high-resolution values as separate > LEAF-specific metrics: the simple percentage in xnl.v.b.soc.instrument > and the high-resolution value scaled as a proportion of the "new car" > value as xnl.v.b.soc.newcar. By default, the standard metric v.b.soc > reports the value from xnl.v.b.soc.instrument; there is a config option > if you want it to report xnl.v.b.soc.newcar instead. > > I think it would be better if we followed the same pattern with SOH. This is implemented in: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/200 Report SOH from passive 0x5b3 in private metric "xnl.v.b.soh.instrument". Report SOH from active 0x7bb.6101 in private metric "xnl.v.b.soh.newcar". Standard metric "v.b.soh" copies from "xnl.v.b.soh.instrument" by default, or from "xnl.v.b.soh.newcar" if config option "xnl.soh.newcar" is set to "true". ------------------------------ Message: 3 Date: Tue, 5 Feb 2019 18:06:40 +0100 From: "Guenther Huck" <privat(a)guentherhuck.at> To: "OVMS Developers" <ovmsdev(a)lists.openvehicles.com> Subject: Re: [Ovmsdev] Collecting information on the Fiat 500e Message-ID: <3DF31B4F6313452380B2A0C536D4CC8B@GuentherPCHP> Content-Type: text/plain; charset="utf-8" Hello Mark I have a Fiat 500e and asked if there is anybody who is firm with the CAN Id?s. In the meantime I have some CAN informations for Fiat 500e and can give to you or somebody who is familiar to programm the OVMS for this car. I don?t have enough experiance to programm this. Sorry! What informations to you need to insert this car to your project ? Guenther From: Mark Webb-Johnson Sent: Saturday, June 30, 2018 3:52 PM To: OVMS Developers Subject: Re: [Ovmsdev] Collecting information on the Fiat 500e I?ve had a user in Australia contact me about this recently. It seems there is some activity on Fiat forums, with people discussing this? I am told the factory app is non-renewable after 3 years, and many cars are being exported out of USA. This user is a Fiat and Alfa technician, so has quite some knowledge of the cars. Regards, Mark. On 30 Jun 2018, at 6:21 AM, Jason Perkins <perkins.jason(a)gmail.com> wrote: I had trouble with the Arduinos I'd gotten, they seemed to garble the 2nd CAN whenever the baud rate was set correctly. I only got a single day to play with it before the telematics was cut off on our roomates 2014 :( Another local friend just got a 2015, don't know if his telematics work or not though. -J On Fri, Jun 29, 2018 at 3:36 PM, Guenther Huck <privat(a)guentherhuck.at> wrote: Is here anybody working on Fiat 500e can bus sniffing? (Maybe perkins.jason) I have also some sniffing done and send you file for arduino. This works for SOC. Maybe we can share information? greetings Guenther _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev -- Jason Perkins 313 355 0085 _______________________________________________ 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

1 0

Re: [Ovmsdev] OvmsDev Digest, Vol 85, Issue 5
by Dean MacGregor 05 Feb '19

05 Feb '19

With the new firmware version the SOH reading doesn't work but it used to. That's in both the 'Vehicle Info' and 'metrics list' command. I have a 2015 Nissan Leaf. On Mon, Feb 4, 2019 at 5:29 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: OVMS v3 v3.2.001 Over-the-Air firmware update (Mark Webb-Johnson) 2. Re: OVMS v3 v3.2.001 Over-the-Air firmware update (ovms) ---------------------------------------------------------------------- Message: 1 Date: Mon, 4 Feb 2019 18:17:35 +0800 From: Mark Webb-Johnson <mark(a)webb-johnson.net> To: OVMS Developers <ovmsdev(a)lists.openvehicles.com> Subject: Re: [Ovmsdev] OVMS v3 v3.2.001 Over-the-Air firmware update Message-ID: <5EB9E54C-7BBA-4424-8890-17806B2E7D03(a)webb-johnson.net> Content-Type: text/plain; charset="utf-8" Can you give details on what you are compiling custom, and where you are getting the code from? I checked the current driver and there doesn?t seem to be any door lock code. Also checked github pull requests, but nothing related to that. Of it this is your extension, can you email it in? Regards, Mark > On 4 Feb 2019, at 4:39 PM, ovms <ovms(a)topphemmelig.no> wrote: > > Any chance someone can include door lock/unlock for Leaf? Then I don?t have to compile the code every time to get the function, and can use the auto-update function. > I have no idea how to commit anything to git. > > Kind regards, > Stein Arne Sordal > > > > On 2019-02-04 06:11, Mark Webb-Johnson <mark(a)webb-johnson.net> wrote: > I?ve just moved this 3.2.001 to ?main? release level. > > If anybody wants to include something, please commit. Hoping to build 3.2.002 for EAP later this week. > > Regards, Mark. > > On 19 Jan 2019, at 5:00 PM, Mark Webb-Johnson <mark(a)webb-johnson.net> wrote: > > > https://www.openvehicles.com/node/2123 > > Today, we are pleased to release v3.2.0-1 to Early Access Program (EAP) participants. This is the first public v3.2 version, and introduces an entirely new scripting framework based on an embedded javascript engine. Now, custom javascript modules and functions can be written to respond to system events. In addition, a host of other UI changes enhancements have been made. > A summary of the major changes is here: > 2019-01-19 MWJ 3.2.001 OTA release > - v3.2 first public release > - New JavaScript modular framework allowing for dynamic scripting and object model > - New vehicle: Smart ED (adaption by Martin Graml ) > - Mitsubishi i-MiEV re-write for OVMS v3 > - Web UI: text / script editor > - Web UI: user plugin support (pages & hooks) > - Web UI: night mode by URI parameter, e.g. "?/#/dashboard?nm=1" > - Web UI: dashboard accessible w/o login > - Web UI: added config backup & restore tool > - Web UI: file selector added for firmware flashing from SD > - Web UI: text notifications (info/error/alert) displayed as dialogs > - Twizy web UI: drivemode buttons secured & added to dashboard > - Twizy web UI: added file dialog for virtual dyno recording > - Twizy: SEVCON monitoring & recording > New commands: > xrt mon start [] > xrt mon stop > xrt mon reset > New metrics: > xrt.i.* = operational inverter data > xrt.s.* = power & torque by speed (virtual dyno) > - Twizy: experimental powermap calculation including region 3 / breakdown torque > New config: > xrt [motor_trq_breakdown] = 0 Breakdown torque in Nm, e.g. 210.375 > xrt [motor_rpm_rated] = 0 Rated speed in rpm, e.g. 2100 > See docs/Renault-Twizy/Twizy-Powermap-Calculator-Tbrk.ods for details. > - Add inactivity watchdog timers to CAN buses > - NissanLeaf: Fix for 0% SOH on 30KWh models with Nissan BMS update > - Introduction of support for DBC CAN bus configuration files > For full detail on all changes, check the GitHub revision history. > The v3 modules can be updated over the air (wifi), via SD CARD, or over USB - all without requiring special hardware programmers like the PICKIT used for v2. The simplest way to update the module firmware is to connect it as a client to your wifi network (or phone hotspot), and then use the web interface Config / Firmware / Flash-from-Web; that will show you the version you are running, as well as the latest version available for update. One click on 'Flash now' and the update will be downloaded and installed. Alternatively, you can download the firmware update to a file named ovms3.bin in the root directory of a FAT formatted SD CARD and insert the card into the module's slot - the new firmware will be updated automatically and the file renamed ovms3.done to signify completion. > This firmware also includes the feature to check for and automatically update to newly available firmware, every night (so long as the vehicle is connected to WiFi). After updating to 3.1.005 or later, you can enable this for future firmware releases with 'config ota auto yes'. You can choose the release level by setting 'config ota tag edge|eap|main', as one of: > > > edge: Bleeding edge developer nightly-builds > eap: Early Access Program (full releases, but with little public testing) > main: Publicly tested full releases (the most stable) > > > We expect to release the 3.2.001 firmware to 'main' (all users) after EAP testing (most likely within a week or so). > Thank you to all the open source developers who have contributed to this, and previous, releases, and thank you for your support of the project. > Open Vehicles > _______________________________________________ > 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

2 2