April 2018 - OvmsDev - Open Vehicles

Any activity/thoughts around a script to sign on to multi-prompting wifi networks?
by chip＠cangmag.com 20 Apr '18

20 Apr '18

If this is a naive question, please excuse my ignorance, but is their any activity/thoughts around implementing a script on the v3 module to allow for sign on to multi-prompting wifi networks--for example, a wifi network that prompts for a username and a password? Thanks. Chip C.

1 0

Initial OTA update
by Greg D. 20 Apr '18

20 Apr '18

5 16

Async events and config updates
by Michael Balzer 19 Apr '18

19 Apr '18

Frank Demes found an issue in the Twizy code that may affect other vehicles and commands as well, please check your code: I'm using the ConfigChanged() hook to process config changes, it's triggered by the "config.changed" and "config.mounted" events. In my command implementation I previously relied on this hook being called inline from MyConfig.SetParamValue…(), so my internal state would be updated immediately. Due to events now being processed asynchronously this is no longer valid. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

OVMS v3 v3.1.004 Over-the-Air firmware update
by Mark Webb-Johnson 17 Apr '18

17 Apr '18

FYI: Email sent to all purchasers of OVMS v3.1 modules Thank you for your support of the Open Vehicles project. OVMS kits have started arriving, and are being connected to cars. Approximately 1/3rd of the first batch of modules have already been installed and are connected to OVMS servers, with more coming online every day. The feedback you early users are providing is extremely helpful to the project, to smooth the way for future users, and is most appreciated. 1] Firmware Update Of those who have already installed their OVMS v3 modules, approximately half are still running the old factory firmware (now more than a month out of date). As this is early beta firmware, it is important that you keep the module up-to-date with the latest firmware (to take advantage of fixes and improvements as they are released, and avoid running into problems already fixed). Today, we are pleased to release v3.1.004: 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 <http://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 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. 2] FAQ Early production users have run into some common problems, which we summarise below in a mini-FAQ: The 'metric list m.net.mdm.iccid’ is not showing my modem, and my modem is not connecting. To minimise power consumption, OVMS v3 will by default keep all peripheral devices turned off unless you enable them. In the case of the modem, you can enable it at startup by the web interface ‘Autostart’ configuration clicking the “Start modem” option. You can also do this from the command line with ‘config auto modem yes’. I’ve messed things up, and need to reset the settings back to factory defaults. If you are running the latest v3.1.004 firmware, you can simply remove any SD CARD then press and hold the BOOT button for 10 seconds. Alternatively, make a file ‘factoryreset.txt’ on the root of the SD CARD and insert it. If you are running older firmware, you will need to connect a serial console (via USB) and use the ‘module factory reset’ command. Instructions are in the User Guide. It is not connecting. How do I find out what is going on? The following commands show useful status information: simcom status network status wifi status server v2 status What WiFi configuration is recommended? The most flexible seems to be “Scanning Client” mode. Enter SSIDs and passwords for all the WiFi networks you have access to (including your phone hotspot if you have it), and enable Scanning Client mode. The OVMS module will then connect to WiFi whenever it gets in range of any of those networks. That will then give the module cheap fast Internet (without cellular data charges), the ability to do OTA firmware updates over WiFi, and a simple way for any laptop/phone/tablet on the same WiFi network to connect to the module to configure/monitor. While Access Point mode is useful at times (especially for initial setup), it offers no Internet connectivity. Access Point + Client mode can only use one single SSID and is limited in that the channel for the SSID must be the same as the channel for the Access Point (only 1 radio in the module). In general, Scanning Client mode is much simpler and more useful for the majority of cases. 3] Help/Support links Unboxing Video: https://www.youtube.com/watch?v=HpyI1q4Y89I <https://www.youtube.com/watch?v=HpyI1q4Y89I> User Guide: https://docs.google.com/document/d/16JrXR7rybp-18DrEoeh1rg6GqQT_jVBvhaXh2oE… <https://docs.google.com/document/d/16JrXR7rybp-18DrEoeh1rg6GqQT_jVBvhaXh2oE…> User Forums: https://www.openvehicles.com/forum <https://www.openvehicles.com/forum> 4] Hologram To simplify getting started, a Hologram SIM has been included with the modem in every OVMS v3.1 kit. Hologram have also kindly provided a coupon code “OVMS” that can be used to get US$5 credit; this can be used for both existing as well as new Hologram customers. You can simply enter that coupon code at checkout (when purchasing data credits, etc). When activating your Hologram SIM, you’ll need to enter the ICCID written on the SIM itself. You can also get that electronically (without having to open up the package) from the web or terminal shells, so long as the modem is powered up, with the following command: OVMS# metric list m.net.mdm.iccid 5] Support Please remember that this first production batch is intended for experienced OVMS v2 users and v3 developers, and note: Firmware is not complete, and should be considered beta. Functionality is approximately equivalent to basic OVMS v2 firmware, but some advanced features (such as ACC, SMS control, etc) are not available yet. Firmware is far in advance of v2 in other aspects (such as built in web server, metrics, console, tcp/ip support, diagnostics, geofencing, scripting, etc). Firmware can be updated either Over The Air (OTA), by Micro SD card, or over USB interface. Vehicle support currently includes: Kia Soul EV, Nissan Leaf, Renault Twizy, and Tesla Roadster. If you do experience a problem, or need assistance, please start by talking to other OVMS v3.1 users/developers in your area. If you still can't solve the issue, then login to the www.openvehicles.com <http://www.openvehicles.com/> website and open a support ticket or forum topic. Software issues can be reported directly to the project GitHub issue tracker here: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues> Thank you for your support of the project. Open Vehicles

1 0

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