[Ovmsdev] leaf odometer

Thu Apr 12 00:29:51 HKT 2018

I don't know if this helps since it's not OVMS databut I have US Leaf with miles on instrument panel but leaf spy shows odometer in km

  On Wed, Apr 11, 2018 at 12:14 PM, ovmsdev-request at lists.openvehicles.com<ovmsdev-request at lists.openvehicles.com> wrote:   Send OvmsDev mailing list submissions to
    ovmsdev at 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 at lists.openvehicles.com

You can reach the person managing the list at
    ovmsdev-owner at 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 Odometer Units (Tom Parker)
  2. Re: changes.txt (Michael Balzer)

----------------------------------------------------------------------

Message: 1
Date: Wed, 11 Apr 2018 21:55:14 +1200
From: Tom Parker <tom at carrott.org>
To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
Subject: [Ovmsdev] Leaf Odometer Units
Message-ID: <6496e407-cef0-ef76-96d2-86c174107291 at carrott.org>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi,

I'm parsing the Leaf odometer out of the car can bus messages (something 
that wasn't possible on the ovms v2). The leaf apparently sends the 
odometer in km or miles, depending on the dashboard units. I'm detecting 
the units and setting them on the ovms metric, but I can only test on a 
car that records km. If it doesn't understand the units it does not 
populate the odometer value at all.

When someone gets an OVMS on Leaf which shows it's odometer in miles can 
you please let me know if your odometer metric remains zero, is reported 
with the correct units, or reported with the wrong units.

Thanks.

------------------------------

Message: 2
Date: Wed, 11 Apr 2018 18:13:41 +0200
From: Michael Balzer <dexter at expeedo.de>
To: ovmsdev at lists.openvehicles.com
Subject: Re: [Ovmsdev] changes.txt
Message-ID: <5777c152-653e-5af7-ba9f-98ed48f2c3ac at expeedo.de>
Content-Type: text/plain; charset="utf-8"

Mark,

I would reduce this much further to:

????-??-?? ???? ???????? OTA release
- Tesla Model S: Support v.bat.soc, v.pos.speed and park/drive status metrics

This is IMO the only change from the current log a normal user needs to know about.

The SD card configuration is on the edge, I would remove that entry from the user info as well, as a normal user will (should) not need to touch these configs:

- SD CARD: Provide configurable sdcard parameters:
??? sdcard [maxfreq.khz] = 16000???????? Maximum frequency (in kHz) of SD CARD bus
??? sdcard [automount] = yes???????????? Automatically mount SD CARD on insertion

The DebugCrash records info is also on the edge, I would now also remove that from the changes file as no normal user can make use of that info:

- Boot: store & send crash debug info (*-OVM-DebugCrash records)

The remaining changes are bug fixes or internal stuff no user needs to know, only developers:

- Wifi: Increase scan responsiveness (60 seconds -> 10, on first scan)
- Server v2: Introduce a 50ms delay between setting charge mode and current in same command
- Core: Changes to housekeeping and events tasks to move event delivery and housekeeping actions
? to the event task (removing housekeeping task)
- Core: Enable watchdogs for production builds
- SD CARD: Reliability improvements to SD CARD auto-mounting on insertion
- Core: Introduce protection for thread safety while logging, to workaround ESP IDF bug
? https://github.com/espressif/esp-idf/issues/1837

All this can be reduced to a single line "lots of bug fixes and optimizations".

Am I too radical on this?

Regards,
Michael

Am 11.04.2018 um 02:06 schrieb Mark Webb-Johnson:
>
> Yes, that is the intention. For v2, I generally did this for each firmware release by doing a ?git lola? (like your 'git log --oneline --no-merges?), going
> through the changelog, and updating the changes.txt with non technical translations of core functionality changes. Trivial changes were not recorded in
> changes.txt.
>
> I just reviewed the latest, and this is what I came up with:
>
>    $ git log --oneline --no-merges 3.1.003 master
>    aeb7728 (HEAD -> master) Tesla Model S: Refinements for v.e.handbrake and Mph/Kph support
>    52e8214 (origin/master, origin/HEAD) Web shell: touch keyboard optimization
>    2eab5d3 Provide configurable parameters for sdcard: sdcard [maxfreq.khz] = 16000 sdcard [automount] = yes
>    a2804b8 Add ovms_utils.h for FormatHexDump.
>    343ad45 Reimplement setting console prompt for secure mode
>    09f6f6b Tesla Model S: Use 32bit arithmetic for data decoding
>    ed4d700 Tesla Model S: Use 32bit arithmetic for data decoding
>    6f732b2 Improve hexdump of 're list' to show ascii printable characters.
>    82cccc7 Tesla Model S: Gear selector - on/awake
>    3e0d5b1 TeslaModelS: v.bat.soc and v.pos.speed metrics
>    e898c1b TeslaModelS: Fix for metric v.bat.soc
>    c5bc34a TeslaModelS: Fix for metric v.pos.speed
>    ad46fb2 Clone data passed to SignalEvent
>    ed32467 Default production config support for ESP IDF panic stub
>    b38b0ef Mutex protect fsync function call, on logging, to workaround ESP IDF bug https://github.com/espressif/esp-idf/issues/1837
>    37c5f4b Boot: store & send crash debug info (*-OVM-DebugCrash records) Note: needs esp-idf update (daef4b5c11a646b7149bf3534e338f3070ae3abf)
>    1bcbef9 Clone data passed to SignalEvent
>    d9931cb Changelog update
>    be39917 Run SD CARD automount in Events task context, not Timer.
>    f0969a3 Refactor housekeeping/events tasks to use Events task for signal dispatch and housekeeping.
>    97775cf OVMS task naming cleanup
>    90c00b8 Enable watchdog reset for production builds
>    fde6d8d OVMS task naming cleanup
>    f6a8de5 changes.txt update
>    7ea18b4 Server v2: Delay 50ms on cmd #16 (between setting mode and current)
>    21e4110 Increase wifi scan responsiveness
>
>
> Becomes:
>
>    ????-??-?? ??? ???????? ?OTA release
>    ? ? ? ? ? ? ? ? ? ? ? ? ?- Wifi: Increase scan responsiveness (60 seconds -> 10, on first scan)
>    ? ? ? ? ? ? ? ? ? ? ? ? ?- Server v2: Introduce a 50ms delay between setting charge mode and current in same command
>    ? ? ? ? ? ? ? ? ? ? ? ? ?- Core: Changes to housekeeping and events tasks to move event delivery and housekeeping actions
>    ? ? ? ? ? ? ? ? ? ? ? ? ? ?to the event task (removing housekeeping task)
>    ? ? ? ? ? ? ? ? ? ? ? ? ?- Core: Enable watchdogs for production builds
>    ? ? ? ? ? ? ? ? ? ? ? ? ?- SD CARD: Reliability improvements to SD CARD auto-mounting on insertion
>    ? ? ? ? ? ? ? ? ? ? ? ? ?- SD CARD: Provide configurable sdcard parameters:
>    ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?sdcard [maxfreq.khz] = 16000 ? ? ? ? Maximum frequency (in kHz) of SD CARD bus
>    ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?sdcard [automount] = yes ? ? ? ? ? ? Automatically mount SD CARD on insertion
>    ? ? ? ? ? ? ? ? ? ? ? ? ?- Boot: store & send crash debug info (*-OVM-DebugCrash records)
>    ? ? ? ? ? ? ? ? ? ? ? ? ?- Core: Introduce protection for thread safety while logging, to workaround ESP IDF bug
>    ? ? ? ? ? ? ? ? ? ? ? ? ? ?https://github.com/espressif/esp-idf/issues/1837
>    ? ? ? ? ? ? ? ? ? ? ? ? ?- Tesla Model S: Support v.bat.soc, v.pos.speed and park/drive status metrics
>
>
> This process is helped if people can include full information in their commit messages - in particular for changes that impact features, usage, provide new
> options, etc - anything that is going to affect or be visible to the user.
>
> Currently, the firmware download server has a file (http://api.openvehicles.com/firmware/ota/[v3.0|v3.1]/<tag>/ovms3.ver
> <http://api.openvehicles.com/firmware/ota/%5Bv3.0%7Cv3.1%5D/%3Ctag%3E/ovms3.ver>) that stores a one-line ?current version?. I plan to change that to include
> the last few releases for changes.txt (as well as the version). That way, ?ota status? can show the changes in the latest version as well as the version
> number itself).
>
> Regards, Mark.
>
>> On 11 Apr 2018, at 5:31 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>
>> A suggestion for the changes.txt:
>>
>> I thought and now suggest this file is intended as an extract of high level changes, i.e. changes that extend or change the user interface and/or features of
>> the system, but not bug fixes or internal reworks.
>>
>> A log of all changes can be created automatically from the git log, no need to do that manually.
>>
>> git log --oneline --no-merges 3.1.000..
>>
>> If we add all commits, users will stop reading this file. If we reduce it to high level entries, it becomes a valuable info for users.
>>
>> Regards,
>> Michael
>>
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180411/d11bb176/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
OvmsDev mailing list
OvmsDev at lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev

------------------------------

End of OvmsDev Digest, Vol 75, Issue 39
***************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180411/cd0c93f6/attachment-0001.html>