- OvmsDev - Open Vehicles

3.1.004 OTA
by Mark Webb-Johnson 17 Apr '18

17 Apr '18

This has been released to ‘main’ ota tag: Firmware: 3.1.004/ota_0/main (build idf v3.1-dev-454-gdaef4b5c Apr 17 2018 08:35:59) OTA release providing minor improvements and fixes. - Tesla Model S: Add support for v.bat.soc, v.pos.speed and park/drive status metrics - Tesla Roadster: Fixes for charge/drive mode on v1.x and v2.x cars - 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) - OTA: Support for configurable release tag and server URL ota [tag] = main ota [server] = api.openvehicles.com/firmware/ota - Wifi: Increase scan responsiveness (60 seconds -> 10, on first scan) - Factory reset by SD file "factoryreset.txt" or pushing SW2 for 10 seconds Note: SW2 method needs removing any SD card inserted. - Wifi: fallback to AP mode net "OVMS" password "OVMSinit" after factory reset - Miscellaneous bug fixes and enhancements It is functionality equivalent to ‘edge’ 3.1.003-52-g8cde1a4. Regards, Mark.

1 0

Re: [Ovmsdev] Turned off commenting on the OVMS v3 User Guide
by Tom Parker 17 Apr '18

17 Apr '18

3.1.001-19-g02ae9c4 is me, I haven't updated recently. I might also have a couple of accounts that I used a while ago during development (I have a few but I can't remember if I used them with v3). On Apr 17, 2018 2:34 AM, Michael Balzer <dexter(a)expeedo.de> wrote: > > > Am 16.04.2018 um 14:59 schrieb Mark Webb-Johnson: >> >> My server is now showing 14 v3.x modules connected (2 of which are mine): >> 6 running 3.1.001/factory/main >> 4 running 3.1.003/ota_0/main >> 1 running 3.1.003-38-g435f516/factory/main >> 1 running 3.1.003-41-gc299c84-dirty/ota_0/ro1 >> 2 running 3.1.003-48-g7cfbc35/ota_1/edge >> We had about 6 people ask for help, and 14 got connected in the end. I think all but one that asked for help got connected ok. For experienced users, that support call ratio is way too high - mostly lack of documentation and issues with wifi settings being incorrectly set then unable to get back in. >> >> Presumably you also have some connected to your server? I’m just looking for ‘build idf’ in the version string in ‘rx msg F’. How many did you get? > > > This is the current status over here: > > SELECT LEFT(m_msg, INSTR(m_msg,'/')-1) AS version, COUNT(*) FROM ovms_carmessages WHERE m_code='F' AND m_msg LIKE '%build idf%' GROUP BY version WITH ROLLUP > > > version > count(*) > 3.1.001 > 1 > 3.1.001-19-g02ae9c4 > 1 > 3.1.003 > 4 > 3.1.003-14-gad46fb2 > 1 > 3.1.003-23-ga2804b8 > 1 > 3.1.003-38-g435f516 > 1 > 3.1.003-41-gc299c84 > 1 > 3.1.003-44-g627d21e-dirty > 1 > 3.1.003-45-g9fabbea > 3 > > 14 > > > Two of those are mine, and I think some more are Toms (?). > >> >> The 3.1.003/ota_0/main is the latest main firmware. But the 6x running 3.1.001/factory/main haven’t updated firmware. That is not good. >> >> I think we should be able to release 3.1.004 ota tomorrow. I’ll then send out an eMail to all purchasers reminding them to (a) update, (b) use the help support system, and (c) some reminders (a faq based on what we’ve seen the past few days). Anything else to put in that eMail? > > > A reminder to include more detail in bug reports / support requests. The request for qualified help on the user guide. Maybe my EU firmware mirror, but I'd like to make the directory structure fit to the new ota config options first -- I'll tell you. > > > Regards, > Michael > > >> >> Regards, Mark >> >>> On 16 Apr 2018, at 6:48 PM, Michael Balzer <dexter(a)expeedo.de> wrote: >>> >>> >>> Am 16.04.2018 um 04:15 schrieb Mark Webb-Johnson: >>>> >>>> I’ve had to turn off commenting on the OVMS v3 user guide. Too many people with just no idea what they are doing messing around. >>> >>> >>> Indeed. Thanks. I'll ask for qualified help on the forum. >>> >>> On the positive side: we can already see now how the system performs for normal users. >>> >>> Regards, >>> Michael >>> >>> -- >>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>> >>> >>> _______________________________________________ >>> 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 >> > > -- > > Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal > > Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >

1 0

Some warning/error messages
by Stephen Casner 17 Apr '18

17 Apr '18

Item 1: When running "make flash" I see the following warning: Running make flash... /Users/casner/src/github/esp-idf/components/partition_table/Makefile.projbuild:16: warning: undefined variable `MD5_OPT' Flashing binaries to serial port /dev/cu.SLAB_USBtoUART (app at offset 0x10000)... A grep for MD5_OPT in the esp-idf source tree only finds the two instances in Makefile.projbuild, so it looks like is not defined anywhere if CONFIG_PARTITION_TABLE_MD5=y. Do others see this warning? If not, I must need to update something. Item 2: I don't have an SD card installed, but I see the following errors at boot time (with current Master sources): I (2492) sdcard: SD CARD has been inserted E (2532) sdmmc_req: handle_idle_state_events unhandled: 00000004 00000000 E (2532) sdmmc_cmd: sdmmc_card_init: send_op_cond (1) returned 0x107 -- Steve

2 4

Moving to a production cycle
by Mark Webb-Johnson 16 Apr '18

16 Apr '18

My v3.1 test board seems stable, and we are ready for hardware production. I’m ordering the components with relatively long lead times (weeks) now, and the production order will go in as soon as China comes back from holiday (next week). First hardware batch will be available during March. I know lots of people are waiting for this, but I have to balance that against risk (should some hardware issue be found during wider real-world testing). I currently plan to order 120 modules (including 60 USA 3G modems, and 60 EU 3G modems) for the first batch. 100 will go to FastTech (for general ordering), and 20 to me (for special cases). As with OVMS v1, we’ll clearly say these are early units for ‘technically capable’ people, and the firmware still has a way to go. On the firmware side, we need to move to a production style release cycle, and I will need to provide the first ‘factory’ firmware around the second week of March. Accordingly, I’m setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it available for OTA download). I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they merge/commit changes to the project. The top of the file will contain an entry for the ‘next’ version, so the change text just needs to be added below that. When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use tags for OTA versions - or just don’t tag at all for the moment and let me maintain this. The last list of things I have for this build are: OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I’ve still got to make the changes to HTTP firmware updates to use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file. We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features. SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware). Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?). End-User Documentation. Real-world stability (in cars). My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply update the firmware to keep pace with the fast release cycle we expect (at least in the coming months). Anything I’ve missed? Regards, Mark.

6 73

Wifi autostart user problems
by Michael Balzer 15 Apr '18

15 Apr '18

We've got some reports of users losing wifi after configuration. The cause is a missing check and fallback for apclient + scan mode. I have added fallbacks to the autostart code so the system starts whatever mode can be run, and a validation of the wifi setup to the autostart config page. I have also added a warning to the user guide along with instructions on how to get wifi working again. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

Console output batched up while command is run #32
by Mark Webb-Johnson 14 Apr '18

14 Apr '18

Another one for Steve: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/32 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/32> When running commands in ssh console (maybe others), the output is batched up and only output when the command has finished running. An example is: test sd But also: ota flash http It would be better if it could be output as the command is run. The issue is that we get no output when the command is run, then 30 seconds later (when command finishes) everything comes in one big batch output. The progress messages issued while the command runs are batched up. I don’t know how easy this is (I fear it is fundamental), but please have a look. Thanks, Mark.

3 6

Fwd: [openvehicles/Open-Vehicle-Monitoring-System-3] 7aa91a: SD card: fix insertion/removal detection
by Mark Webb-Johnson 14 Apr '18

14 Apr '18

Thanks for this, @Michael. My bad. Regards, Mark. > Begin forwarded message: > > From: GitHub <noreply(a)github.com> > Subject: [openvehicles/Open-Vehicle-Monitoring-System-3] 7aa91a: SD card: fix insertion/removal detection > Date: 14 April 2018 at 5:46:35 PM HKT > To: mark(a)webb-johnson.net > Reply-To: GitHub <noreply(a)github.com> > > Branch: refs/heads/master > Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 > Commit: 7aa91acd0b1554fa5918c68b4484e72fc97c33b9 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/7aa… > Author: Michael Balzer <balzer(a)expeedo.de> > Date: 2018-04-14 (Sat, 14 Apr 2018) > > Changed paths: > M vehicle/OVMS.V3/components/sdcard/src/sdcard.cpp > M vehicle/OVMS.V3/components/sdcard/src/sdcard.h > > Log Message: > ----------- > SD card: fix insertion/removal detection > >

1 0

changes.txt
by Michael Balzer 13 Apr '18

13 Apr '18

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

4 8

Support Help
by Mark Webb-Johnson 12 Apr '18

12 Apr '18

The 3.1 boxes have started arriving, and requests for support start coming in. So far, mostly just things due to lack of documentation (things like baud rate for USB serial connection not being documented anywhere). The users seem to be reasonable technically competent so far (which was the original plan). We have a new support ticket system now running at www.openvehicles.com. If anyone can volunteer to help support users, that would be most appreciated. Just take on the cases you can, or answer those that you have particular expertise with. It would be helpful if those responsible for individual vehicles / functionality could sign up anyway and just take on the cases (or be assigned them) when someone asks about those specific area of expertise. Another way to help out is to have a periodic review of the support tickets, and take common requests and provided answers, to update the User Guide with the information. If you can volunteer some support time, just let me have your login ID or eMail address you use on www.openvehicles.com, and I will upgrade your permissions to let you view and/or help with support tickets. The tickets themselves are relatively easy to handle. Once you have permissions set on your account, you’ll see a “Support tickets” link appear in the navigation side bar. Users raise tickets, and they are assigned to support volunteers. The tickets can be answered, and everyone involved on that particular ticket is automatically emailed the response. I’m trying to get the eMail integration working, but for the moment the tickets need to be updated from the web site interface. No specific time commitment necessary. Just help out whenever you can. Thanks, Mark.

2 3

Re: [Ovmsdev] leaf odometer
by Dean MacGregor 12 Apr '18

12 Apr '18

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(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 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(a)carrott.org> To: OVMS Developers <ovmsdev(a)lists.teslaclub.hk> Subject: [Ovmsdev] Leaf Odometer Units Message-ID: <6496e407-cef0-ef76-96d2-86c174107291(a)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(a)expeedo.de> To: ovmsdev(a)lists.openvehicles.com Subject: Re: [Ovmsdev] changes.txt Message-ID: <5777c152-653e-5af7-ba9f-98ed48f2c3ac(a)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.…>) 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(a)expeedo.de <mailto:dexter@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(a)lists.openvehicles.com <mailto:OvmsDev@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 -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0