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@lists.openvehicles.com<ovmsdev-request@lists.openvehicles.com> wrote: Send OvmsDev mailing list submissions to ovmsdev@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@lists.openvehicles.com You can reach the person managing the list at ovmsdev-owner@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@webb-johnson.net> To: OVMS Developers <ovmsdev@lists.openvehicles.com> Subject: Re: [Ovmsdev] OVMS v3 v3.2.001 Over-the-Air firmware update Message-ID: <5EB9E54C-7BBA-4424-8890-17806B2E7D03@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@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@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@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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.
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".
participants (2)
-
Dean MacGregor -
Robin O'Leary