March 2018 - OvmsDev - Open Vehicles

Wifi: Support APCLIENT mode (for Access-Point + Client)
by Mark Webb-Johnson 17 Mar '18

17 Mar '18

I’ve added support for a new wifi mode ‘apclient’. This takes AP and STA mode SSIDs, and sets up as both an access point and a client. Some caveats: There seems to be a problem coming out of the mode (wifi mode off, etc). The network interfaces are not torn down correctly every time. Symptom is the client comes up, wifi shows an IP address on it, but the address is not set correctly on the ’st’ network interface. Reproducibility is random (maybe interface order related?). Not sure if this is my fault, or a bug in the framework. A 'module reset’ works around the problem ;-) I updated Michael’s webserver, and the auto framework, to support this, but I’m not too familiar with that so might have got it wrong. Wifi sclient style mode (scanning for known SSIDs to join without knowing the _exact_ SSID) is not currently supported. I’m not sure if this can ever be supported properly. The apclient mode works by locking the channel for both the AP and STA to be the same - if we are locked like that, how can we scan across channels? I’m guessing that ‘wifi scan’ will be similarly restricted, when in ap or apclient modes. This is not a router. Setting the gateway on the ’st’ interface would be trivial, but I don’t think packets can travel AP -> STA. Doing that would require source-nat, plus packet routing, etc. Routing would be easy, SNAT very nasty. It does look pretty cool, and seems to work well: OVMS > network Interface#2: ap IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1 Interface#1: st IPv4: 10.x.x.x/255.255.255.0 gateway 10.x.x.x Interface#0: lo IPv4: 127.0.0.1/255.0.0.0 gateway 127.0.0.1 DNS: 8.8.8.8 8.8.4.4 OVMS > wifi WiFi Power: on Mode: Access-Point + Client mode STA SSID: MY-STA-SSID MAC: re:da:ct:ed:da:ta IP: 10.x.x.x/255.255.255.0 GW: 10.x.x.x AP SSID: MY-AP-SSID MAC: da:ta:re:da:ct:ed IP: 10.x.x.x AP Stations: 1 1: MAC: da:ta:re:da:ct:ed, IP: 192.168.4.2 Enjoy, Mark. > Begin forwarded message: > > Subject: [openvehicles/Open-Vehicle-Monitoring-System-3] ee023a: Wifi: Support APCLIENT mode (for Access-Point + Cl... > Date: 14 March 2018 at 11:09:21 AM HKT > > Branch: refs/heads/master > Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 > Commit: ee023a5c8383901da2b190e3a42e94ad49724b07 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/ee0… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-03-14 (Wed, 14 Mar 2018) > > Changed paths: > M vehicle/OVMS.V3/changes.txt > M vehicle/OVMS.V3/components/esp32wifi/src/esp32wifi.cpp > M vehicle/OVMS.V3/components/esp32wifi/src/esp32wifi.h > M vehicle/OVMS.V3/components/ovms_webserver/src/web_cfg.cpp > > Log Message: > ----------- > Wifi: Support APCLIENT mode (for Access-Point + Client) > >

3 4

Mongoose update & dev merge
by Michael Balzer 17 Mar '18

17 Mar '18

Mark, Steve, I'm about to update our mongoose submodule to the latest changes _including_ the latest additions to the "dev" branch. That's because I want to use the mg_broadcast() function, which doesn't work on the ESP32 until this fix from the dev branch: https://github.com/cesanta/mongoose/commit/780077d1187ff632bdcbf33d65207a08… Quickly found that in the mongoose issues once I knew what to look for… ;) My local checkout builds & runs. I've checked through the commits, there is no API change (except a minor one on HTTP header parsing). None of the commits looks like it could break something and there are some clear fixes included, so I think we can just merge the dev branch. I'll do some general tests before pushing the change, if you'd like me to wait with the update or do some specific tests, tell me. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

4 6

OVMS v3 DNS
by Mark Webb-Johnson 13 Mar '18

13 Mar '18

It seems that we have issues with DNS in OVMS v3. One problem I’ve found is that every time a network interface comes up, the DNS servers for that interface are defined. But when the interface goes down, the old DNS servers are not restored. This becomes an issue when we have both wifi and modem networking interfaces. I’ve committed support for: config network dns … I use: config set network dns "8.8.8.8 8.8.4.4" Along with a new event ‘network.interface.up’, network manager now sets those DNS servers, if defined. Regards, Mark.

1 0

Power consumption
by M B 13 Mar '18

13 Mar '18

Guys, What is the power consumption of ovms 3.1? Did we measure it? I know that some of the Leafs have issues with 12V battery, so would be good to know how much is being consumed by ovms. Thanks, Maciek

3 2

Fwd: [openvehicles/Open-Vehicle-Monitoring-System-3] 037bdd: OVMS event scripts are run in secure mode
by Mark Webb-Johnson 13 Mar '18

13 Mar '18

It seems that event scripts are run in insecure console mode. That doesn’t seem right. I thought we were protecting these so that only secure commands could create these scripts (vfs edit, append, cp, etc), but the scripts themselves ran secure? Otherwise, on a module with a password, how do you run scripts on startup? Putting ‘enable …’ in the script itself is inherently insecure. Anyway, I changed it to run these event scripts in secure mode. If that’s not right, let’s discuss it here… The other issue here is that these scripts may crash the system, so perhaps they should follow the ‘auto’ system as well? Only run event scripts if a corresponding ‘auto’ config is set (can default to true), and the auto system is not temporarily disabled due to too many crashes? Regards, Mark. > Begin forwarded message: > > From: GitHub <noreply(a)github.com> > Subject: [openvehicles/Open-Vehicle-Monitoring-System-3] 037bdd: OVMS event scripts are run in secure mode > Date: 11 March 2018 at 9:20:54 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: 037bddc3e6efa60c70c1fca36b0e0400c87bafe1 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/037… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-03-11 (Sun, 11 Mar 2018) > > Changed paths: > M vehicle/OVMS.V3/main/ovms_script.cpp > > Log Message: > ----------- > OVMS event scripts are run in secure mode > >

2 2

3.1 Production
by Mark Webb-Johnson 11 Mar '18

11 Mar '18

It is with great relief that I can announce I just wrote a very big cheque to produce the first batch of 120 OVMS v3.1 modules. That is on top of the last big cheque I wrote a couple of months ago for the injection moulding. The order is in, and production has started. Specifically, I’ve ordered: 120x OVMS v3.1 modules (cased in black injection moulded enclosures) 60x OVMS 3G modems with EU frequencies 60x OVMS 3G modems with US frequencies These include WROVER modules with dual processor cores, 16MB flash and 4MB SPI RAM. Also all the other OVMS v3 features such as Wifi, Bluetooth, 3x CAN buses, SD CARD, GPIOs, external 12V power control, pluggable modem modules, OTA firmware updates, etc. 100 (50x EU, 50x US) of these will go direct to FastTech for end users. 20 will come to me in Hong Kong for developers and special users. We have enough stock of the other cables, antennas, etc, already at FastTech. I’ll announce pricing in the next few days. There will be special pricing for everybody here (developers) as well as existing users who want to upgrade. This first batch are early production units, with beta firmware, intended for expert users only. To all those that have contributed to the project so far, we owe a huge debt of thanks. We’ve still got a long way to go with the firmware, but It feels good to finally get this out the door. I’m confident that we have a fantastic base on which to build great things in the coming years. Regards, Mark.

7 15

Valid Vehicle ID characters?
by Greg D. 10 Mar '18

10 Mar '18

Just noticed... The Webserver restricts the vehicle ID to "upper case letters and digits". I thought underscores and dashes are allowed (seems to work); my car's ID contains an underscore... Is this additional restriction new (server v3, perhaps)? Greg

4 7

3.0.991
by Mark Webb-Johnson 09 Mar '18

09 Mar '18

New version, tagged and in the repository now: 2018-03-05 MWJ 3.0.991 OTA release support OTA updates over HTTP - Update ovms_module to use new API for per-task heap info. - Commands "time status" and "time set" for access to real-time clock. - Time zone support in config vehicle/timezone See GNU LIBC documentation for details on format https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html - Auto start/init for wifi, modem, vehicle type, server v2 & v3 - Fix to SDCARD component to free SD_DATA1, SD_DATA2, and SD_DATA3 in 1-line mode (in particular so SD_DATA1/GPIO4 and SD_DATA3/GPIO13 can be used for UART to simcom modem for OVMS v3.1 hardware). https://www.esp32.com/viewtopic.php?f=13&t=4838 - Record statistics for CAN bus interrupts (per controller) and show in status. - Don't issue network.reconfigured event when network is down. - Auto start for ext12v & obd2ecu - Web config for timezone & distance units - Twizy web UI for features, battery properties & charge control - Support ESP IDF v3 style OTA updates over http This version is available via OTA (for both 3.0 and 3.1), but unfortunately you’ll need this version running to be able to do an http OTA ;-) If you want to try, then first flash it (as normal), then start wifi, then do ‘ota flash http’. Next version will be 3.0.992. Example: OVMS > ota flash http Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/firmware/ota/v3.1/main/ovms3.bin to ota_0 Expected file size is 1970944 Preparing flash partition... Downloading... (100208 bytes so far) Downloading... (200216 bytes so far) Downloading... (300324 bytes so far) Downloading... (400744 bytes so far) Downloading... (500752 bytes so far) Downloading... (600960 bytes so far) Downloading... (701068 bytes so far) Downloading... (801388 bytes so far) Downloading... (901396 bytes so far) Downloading... (1001604 bytes so far) Downloading... (1102024 bytes so far) Downloading... (1202132 bytes so far) Downloading... (1302140 bytes so far) Downloading... (1402248 bytes so far) Downloading... (1502668 bytes so far) Downloading... (1603088 bytes so far) Downloading... (1703296 bytes so far) Downloading... (1803304 bytes so far) Downloading... (1903724 bytes so far) Setting boot partition... OTA flash was successful Flashed 1970944 bytes from api.openvehicles.com/firmware/ota/v3.1/main/ovms3.bin Next boot will be from ‘ota_0' OVMS > ota status Firmware: 3.0.991-dirty/factory/main build (idf v3.1-dev-453-g0f978bcb) Mar 5 2018 13:34:10 Running partition: factory Boot partition: ota_0 OVMS > metrics list m.ve m.version 3.0.991-dirty/factory/main build (idf v3.1-dev-453-g0f978bcb) Mar 5 2018 13:34:10 This is using the ESP IDF v3.x way of doing OTA binary images. The last 32 bytes of the image contains a sha256 checksum of the image (up to but not including the last 32bytes). The ESP IDF bootloader checks that. Seems to work, but a little bit flaky. Sometimes I can’t get DNS resolution. Anyway, OTA updates are available now, and I’ll try to improve on it over the next few days. Longer term, we want this to happen automatically, so long as module is on wifi. Perhaps once a day. We can worry about that later; for the moment, connect to the web interface then run ‘ota flash http’ from the console there. Regards, Mark.

4 15

Fwd: [openvehicles/Open-Vehicle-Monitoring-System-3] 9a68e2: Tesla Model S basic vehicle support
by Mark Webb-Johnson 08 Mar '18

08 Mar '18

No, I don’t consider Tesla Model S to be a high priority car to support OVMS. However: It is the car I currently drive I am interested in seeing how usable OVMS v3 is as a CAN bus reverse engineering tool The Model S can bus is relatively high volume, so will stress the system I can put OVMS v3 into it, and monitor it on a daily basis to get the bugs out (particular modem stability, and modem/wifi switch) https://github.com/openvehicles/CAN-RE-Tool/blob/master/rules/teslamodels <https://github.com/openvehicles/CAN-RE-Tool/blob/master/rules/teslamodels> I’ve committed a stub at the moment. Just need to put it into my car, make sure the CAN bus parameters are fine, then I’ll flesh it out. Looks like the Tesla Roadster cable should work fine for this (I’ve got a ‘classic’ 2014 Model S). Regards, Mark. > Branch: refs/heads/master > Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 > Commit: 9a68e225969e45bafa0accc604305c6b17de4971 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9a6… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-03-06 (Tue, 06 Mar 2018) > > Changed paths: > M vehicle/OVMS.V3/changes.txt > A vehicle/OVMS.V3/components/vehicle_teslamodels/component.mk > A vehicle/OVMS.V3/components/vehicle_teslamodels/src/vehicle_teslamodels.cpp > A vehicle/OVMS.V3/components/vehicle_teslamodels/src/vehicle_teslamodels.h > M vehicle/OVMS.V3/main/Kconfig > > Log Message: > ----------- > Tesla Model S basic vehicle support

3 5

OVMS v3 Pre-Launch Announcement
by Mark Webb-Johnson 07 Mar '18

07 Mar '18

The first batch of production OVMS v3 modules and modems is being produced now. We estimate availability on Fasttech late this month (March 2018). Specifications and Pricing follow. OVMS v3.1 module: US$90 Black injection-moulded plastic enclosure ESP32 WROVER processor (16MB flash, 4MB SPI RAM, 520KB SRAM, dual core 160/240MHz Xtensa LX6 processor) WIFI 802.11 b/g/n Bluetooth v4.2 BR/EDR and BLE 3x CAN buses 1x Micro USB connector (for flash download and serial console) 1x Micro SD card slot 1x Internal expansion slot 8x EGPIO, 2x GPIO 1x GSM antenna connector 1x GPS antenna connector 1x DB9 vehicle connector 1x DB26 expansion connector OVMS v3.1 SIM5360E 3G modem module (either US or EU edition): US$60 Modem is an optional plug-in module, that can be changed in future (to allow for new technology) 3G (EV-DO/HSPA+) dual band modem Includes 2G (GSM/GPRS) and 2.5G (EDGE) quad band GPS/GNSS Nano (4FF) SIM slot HOLOGRAM.IO nano sim US edition is SIM5360A (Dual-Band UMTS/HSPA+ 850/1900MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz) EU edition is SIM5360J(E) (Dual-Band UMTS/HSPA+ 900/2100MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz) Bundle (OVMS v3.1 module + v3.1 modem): US$150 A time-limited special discount of US$20 off this bundle price will be provided for existing OVMS v2 owners (making this bundle offer US$130). This first production batch is intended for experienced OVMS v2 users and v3 developers. Please 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, Tesla Roadster The antenna and vehicle connectors for OVMS v3 are the same as for OVMS v2, and existing cables/antennas can generally be re-used for OVMS v3. Note, however, that the frequency ranges supported by individual 3G networks may be different than 2G, so may benefit from an antenna specifically designed for the 3G frequency ranges used.

1 1