May 2018 - OvmsDev - Open Vehicles

Network connection management
by Michael Balzer 21 May '18

21 May '18

Re: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/127 I've pushed my solution in commit d1f466d9a7fac6afbb4b768425164c9b367aca1a. Please check how this works for your setups. It normally doesn't need any manual control, the shell commands were a by-product, but may be useful. Example: OVMS# net list ID Flags Handler Local Remote 3f81ddf0 00000000 3f821380 192.168.2.101:80 192.168.2.107:48840 3f81ce3c 00000100 3f81b708 192.168.4.1:80 192.168.4.2:45516 3f81d1e8 00000100 3f81def8 192.168.2.101:80 192.168.2.107:48814 3f81b538 00000000 00000000 192.168.2.101:54799 188.138.75.229:6867 3f81b098 00000000 3f81bfb8 192.168.2.101:22 192.168.2.107:55362 OVMS# net close 3f81b098 Close signal sent to 1 connection(s) OVMS# net list ID Flags Handler Local Remote 3f81bb84 00000000 3f81e3ac 192.168.2.101:80 192.168.2.107:48844 3f81ce3c 00000100 3f81b708 192.168.4.1:80 192.168.4.2:45516 3f81d1e8 00000100 3f81def8 192.168.2.101:80 192.168.2.107:48814 3f81b538 00000000 00000000 192.168.2.101:54799 188.138.75.229:6867 Issuing "net close 0" closes all connections. An automatic cleanup log looks like this for an AP station disconnect: I (143741) wifi: station: 30:75:12:f5:71:c7 leave, AID = 1 I (143791) wifi: n:11 0, o:11 0, ap:11 2, sta:11 0, prof:11 I (143791) events: Signal(system.event) I (143881) events: Signal(system.wifi.ap.sta.disconnected) I (143931) netmanager: WIFI access point station disconnected D (143981) netmanager: send cmd 3 from 0x0 D (144041) netmanager: done cmd 3 from 0x0 I (144091) esp32wifi: AP station disconnected: id: 1, MAC: 30:75:12:f5:71:c7 D (144351) netmanager: MongooseTask: got cmd 3 from 0x0 D (144391) netmanager: CleanupConnections: conn 3f81e010 -> iface ap2 I (144441) netmanager: CleanupConnections: closing conn 3f81e010: AP peer disconnected D (144491) netmanager: CleanupConnections: conn 3f81bb2c -> iface ap2 I (144531) netmanager: CleanupConnections: closing conn 3f81bb2c: AP peer disconnected D (144591) netmanager: CleanupConnections: conn 3f81bd08 -> iface ap2 I (144641) netmanager: CleanupConnections: closing conn 3f81bd08: AP peer disconnected D (144681) netmanager: CleanupConnections: conn 3f81d1e8 -> iface st1 D (144731) netmanager: CleanupConnections: conn 3f81baa0 -> iface st1 D (144771) netmanager: CleanupConnections: conn 3f81b538 -> iface st1 D (144821) netmanager: CleanupConnections: conn 3f81b098 -> iface st1 D (144871) netmanager: MongooseTask: done cmd 3 from 0x0 D (145191) websocket: WebSocket connection 0x3f81ce3c closed; 1 clients active …and like this for a client network disconnect: I (535888) wifi: bcn_timout,ap_probe_send_start I (538398) wifi: ap_probe_send over, resett wifi status to disassoc I (538398) wifi: state: run -> init (1) I (538398) wifi: pm stop, total sleep time: 196172381 us / 249569092 us I (538398) wifi: n:11 0, o:11 2, ap:11 2, sta:11 2, prof:11 I (538408) netmanager: Interface priority is pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) I (538408) netmanager: Set DNS#0 212.9.0.135 I (538408) netmanager: Set DNS#1 212.9.0.136 I (538408) netmanager: Set DNS#2 0.0.0.0 I (538408) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority D (538408) netmanager: send cmd 3 from 0x0 D (538408) netmanager: done cmd 3 from 0x0 I (538408) esp32wifi: STA disconnected with reason 200 I (538408) time: Network was reconfigured: restarting SNTP client I (538418) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (538418) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (538558) ovms-server-v2: Status: Disconnected D (538558) netmanager: MongooseTask: got cmd 3 from 0x0 D (538558) netmanager: CleanupConnections: conn 3fff2854 -> no iface I (538568) netmanager: CleanupConnections: closing conn 3fff2854: interface/link down D (538578) netmanager: CleanupConnections: conn 3fff514c -> no iface I (538578) netmanager: CleanupConnections: closing conn 3fff514c: interface/link down D (538588) netmanager: CleanupConnections: conn 3fff5054 -> no iface I (538588) netmanager: CleanupConnections: closing conn 3fff5054: interface/link down D (538588) netmanager: MongooseTask: done cmd 3 from 0x0 D (538598) websocket: WebSocket[0x3fff2854] handler 0x3ffdff20 closed; 0 clients active Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

3.1-006
by Mark Webb-Johnson 21 May '18

21 May '18

Today, we are pleased to release v3.1.006. Over 125 bug fixes and enhancements have gone into this release since v3.1.005, and a summary of the major changes is here: Firmware: 3.1.006 (build idf v3.1-dev-455-gf4905cdf May 20 2018 20:08:31) OTA release providing minor improvements and fixes. - Web status: panel auto updates, reboot button, SD card and modem status and control - Twizy: sufficient charge notifications separated from charge state - Webserver: setup wizard - Notifications for charge and other standard events - Notifications for vehicle error fault codes - Notifications when new firmware is available / installed (autoflash) - Charge Time Predictor for Tesla Roadster 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 3.1.006 release also includes the new 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, you can enable this for future firmware releases with 'config ota auto yes'. Thank you for your support of the project. Open Vehicles

2 2

Modem fails to connect
by Greg D. 19 May '18

19 May '18

3 13

SD CARD speed vs cp2102
by Mark Webb-Johnson 17 May '18

17 May '18

Good grief. A year into this, and still writing about SD CARD issues with ESP32. If I could get into a room with the engineer who decided to share boot strapping pins with SDCARD pins, and to hard wire the SDIO controller to specific pins, I would literally try to slap some sense into him. The China guys and I have been struggling for the past couple of months trying to work out why we can’t get as much speed out of the SD CARD as we wanted. If we raise the speed to the normal 20MHz, we randomly get errors (timeouts, checksums, etc). It looked like interference on the bus lines, but scoping those we can’t find any. Dropping the speed to 16MHz works around the issue, but SD CARD accesses are slow. Then, we worked out it wasn’t random. It was based on whether we were powering from USB or external 12V. On the bench it works fine. In the car the problem appears. Simply put, if the USB was plugged in the ‘interference’ disappeared. If USB was unplugged, it came back. USB + external 12V combination also didn’t suffer from the issue, so the problem is not coming from the 12v side. The issue often appeared on only the second test of SD CARD, not the first. We didn’t see this problem on either the v3.0 developer modules, or v3.1 prototypes. We looked at the capacitors and pull-up resistors on that side of the circuit, without success. Whatever we did made little difference (or randomly changed things for the better/worse). We thought maybe ground-line interference, but nope. We spent some time looking at C20, C22, C23 to see if the manufacturers had messed up the component values - they hadn’t. Anyway, to cut a long story short, we finally found the culprit. The CP2102 chip itself. We’d already had to change the power supply design early on in the project to cope with a bug in CP2102 not correctly handling USB host disconnect and not properly going into suspend mode (to reduce power consumption of cp2101 circuit when usb was disconnected) - our current design completely powers down the cp2102 chip when the USB cable is disconnected. Michael Stegen had previously warned me about clones of this chip (see https://wiki.sha2017.org/w/Projects:Badge and what they went through), and we had added the extra resistor already to cope with that eventuality. But, from what we can tell this is not a clone part issue. Here is what we found: OVMS v3.0 and early v3.1 prototypes use CP2102 v1412+. For that chip, when the USB cable is disconnected, CSL-TXD is 3.3v. OVMS v3.1 first production batch use a newer CP2102 v1708+. For that chip, when the USB cable is disconnected, CSL-TXD is pulled down to 0.78v. We have replaced the cp2102 on a v3.1 first production module with v1412+, and SD CARD resumes normal operation (even with usb disconnected). The version number seems to be a date code. YYWW (year, week), I guess. We have absolutely no idea why this would be affecting the SD CARD performance or interference. Somehow, that CSL-TXD line is going through the ESP32 chip and affecting the SDIO controller (perhaps related to the bootstrapping pins dual use). The interference we see is inside the ESP32, not on the lines going from ESP32 to the SDCARD (which is why we couldn’t see it on the scope). I tried shutting down the pins on the ESP32 for CSL-TXD and CSL-RXD, to see if I could work around the problem in firmware, but couldn’t get it to work. There is no way of knowing whether the USB is connected, and even if we did know, setting CSL-TXD and CSL-RXD pins to output mode, or float, doesn’t seem to make any difference. The good news is that we’ve at least identified the problem. We are (a) checking the revision of cp2102 chip in the upcoming production batch, and (b) changing QC procedures to set SD CARD bus speed to default (20MHz) and randomly test modules twice on 12V power. Latest production batch is now using v1742+, and that has been tested as working. Going forward, we can resolve this. As for the first production batch units, they are what they are. For normal SD CARD operation (copying files, flashing firmware, etc), it makes little difference. I guess most users don’t even have an SD CARD inserted. The speed limitation really only becomes an issue if you are trying to log lots of data to SD CARD (such as CAN bus dumps). If the USB is connected, you can 'config set sdcard maxfreq.khz 20000’ and it will work faster. The CP2102 chip can be changed, and I’ll do that for anyone that needs it. I’m asking China to send me some from the latest production batch that we know works. Replacement is relatively straightforward, but involves micro-soldering (the cp2102 is a surface mount chip, very small footprint, with lots of other components near it on the board). Regards, Mark.

2 7

SPI RAM
by Mark Webb-Johnson 17 May '18

17 May '18

I’m doing some work on optimising RAM usage in OVMS v3.1. This is to try to make space for bluetooth, etc. First step is fixing the (broken) SPIMEM_AGGRESSIVE option to work better. Saving is worthwhile: Without aggressive: Free 8-bit 113116/281672, 32-bit 8020/24276, SPIRAM 4140964/4194252 With aggressive: Free 8-bit 137380/281640, 32-bit 8020/24276, SPIRAM 4108616/4194252 That is the first step only. We are still using far too much internal RAM, and almost the whole 4MB of external RAM is sitting idle. The reason for this eMail: Hopefully I didn’t break anything. If I did, let me know. Regards, Mark. > Begin forwarded message: > > From: GitHub <noreply(a)github.com> > Subject: [openvehicles/Open-Vehicle-Monitoring-System-3] 2816b9: Support minimal build (all components disabled) - ... > Date: 16 May 2018 at 10:13:49 AM HKT > To: mark(a)webb-johnson.net > Reply-To: GitHub <noreply(a)github.com> > > Commit: 23f307757abb6411f77500182b72b11417019317 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/23f… <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/23f…> > Author: Mark Webb-Johnson <mark(a)webb-johnson.net <mailto:mark@webb-johnson.net>> > Date: 2018-05-16 (Wed, 16 May 2018) > > Changed paths: > M vehicle/OVMS.V3/main/ovms.cpp > M vehicle/OVMS.V3/main/ovms.h > > Log Message: > ----------- > Correct implementation of CONFIG_OVMS_HW_SPIMEM_AGGRESSIVE.

2 1

Charge time prediction
by Michael Balzer 17 May '18

17 May '18

Mark, commit 9b841bfaaf5538da465e66da31c308c8c370f76f Vehicle: Clear the charge time predictor values, for all vehicles, when charge ends. That approach is not correct, I still (or especially) want to know the remaining charge time for the sufficient levels and the full charge if I stop the charge manually or automatically. I wouldn't see a problem in doing this based on the charge state "done", but is this necessary at all? Wouldn't the vehicle normally calculate the prediction continuously based on the SOC and charge config? The SOC changes independantly of charging and driving by self discharging and powering components, recharging the 12V battery etc.. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

3 5

Kilometers instead of miles
by Stephen Casner 16 May '18

16 May '18

Even though I have selected Miles in the Vehicle configuration in the web UI, the status and dashboard in the web UI report in km. Alerts that I receive through the app are also in km even though the app is displaying range in miles as it should. Do I need to select Miles somewhere else? Is this a consequence of not having gone through the setup wizard on this unit? (It it the v3.0 unit on which I've done all my development work.) -- Steve

3 2

Web configuration
by Stephen Casner 16 May '18

16 May '18

A couple of comments about the Wifi configuration via the web UI -- Not having run the setup wizard and having used only client mode previously, I had no AP configured. I configured an AP on the Wifi config page. As I expected, that had no immediate effect, so I rebooted the module to make that take effect. Then I saw the SSID OVMS appear. I needed to go to the autostart config page to select my new AP SSID as the one to be started, and then reboot again to start it. I can imagine situations where I want to temporarily switch Wifi modes and/or define a new AP or client SSID and switch right away, but not have those settings become my autostart settings. Shouldn't there be controls on the Wifi config page to set the Wifi mode like those on the autostart config page? Also, in the scenario above I was a bit surprised to see the OVMS SSID since the Wifi config page did not list it as an AP. Shouldn't it be included there? -- Steve

2 3

Fwd: [openvehicles/Open-Vehicle-Monitoring-System-3] 951f04: Support durations (default 1000ms) for homelink tr...
by Mark Webb-Johnson 15 May '18

15 May '18

Did some off-list work with Steve and Greg on homelink. Turns out that there is really a ‘duration’ associated with homelink transmissions. For Tesla Roadster: For single button presses, the duration is about 1,000ms. Any transmission longer than about 10,000ms - 14,000ms is cut-off and aborted after that time. If a button is held down, homelink continues to transmit (up to the maximum #2 above). Accordingly, I’ve updated the homelink command, and vehicle modules that use it. Haven’t bothered to change the OVMS protocol v2 (as that can just use the default of 1000ms). Regards, Mark > Begin forwarded message: > > From: GitHub <noreply(a)github.com> > Subject: [openvehicles/Open-Vehicle-Monitoring-System-3] 951f04: Support durations (default 1000ms) for homelink tr... > Date: 15 May 2018 at 9:23:39 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: 951f04587792c88682335ff938e83b6e071b5411 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/951… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-05-15 (Tue, 15 May 2018) > > Changed paths: > M vehicle/OVMS.V3/components/vehicle/vehicle.cpp > M vehicle/OVMS.V3/components/vehicle/vehicle.h > M vehicle/OVMS.V3/components/vehicle_demo/src/vehicle_demo.cpp > M vehicle/OVMS.V3/components/vehicle_demo/src/vehicle_demo.h > M vehicle/OVMS.V3/components/vehicle_nissanleaf/src/vehicle_nissanleaf.cpp > M vehicle/OVMS.V3/components/vehicle_nissanleaf/src/vehicle_nissanleaf.h > M vehicle/OVMS.V3/components/vehicle_teslaroadster/src/vehicle_teslaroadster.cpp > M vehicle/OVMS.V3/components/vehicle_teslaroadster/src/vehicle_teslaroadster.h > > Log Message: > ----------- > Support durations (default 1000ms) for homelink transmissions. > > > > **NOTE:** This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/ > > Functionality will be removed from GitHub.com on January 31st, 2019.

1 0

Notifications Framework (subtype and filtering)
by Mark Webb-Johnson 14 May '18

14 May '18

I’ve extended the notifications framework to include the concept of notification subtypes. This is in addition to the existing notification base types. This allows us to automatically filter notifications based on the granular subtypes. The filtering is done at the framework level, so all notification listeners need to do is turn it on (when they register). I have identified the following standard subtypes, and updated quite a few modules to use them: charge.stopped charge.state batt.alert batt.12v (seems similar to batt.alert, but not yet decided) homelink debug.crash xks.aux xrt.battmon xrt.power xrt.gps xrt.trip xrt.sevcon xrt.logs xrt.reset I would really rather have all the alert types standardised (including things like trip logs, gps tracking, etc) and working across all vehicle types. But this at least is a starting point. An example of it working is: OVMS# notify raise text info test hello Raise text notification for info/test as hello I (25618) ovms-server-v2: Send MP-0 PIhello OVMS# config set notify test none Parameter has been set. OVMS# notify raise text info test hello Raise text notification for info/test as hello OVMS# config set notify test ovmsv2 Parameter has been set. OVMS# notify raise text info test hello Raise text notification for info/test as hello I (71368) ovms-server-v2: Send MP-0 PIhello I am working on the vehicle module automated alerts we previously discussed, and this is a pre-requisite. New standardised subtypes will come with that (such as charge.start, charge.done, etc). Regards, Mark. > Begin forwarded message: > > From: GitHub <noreply(a)github.com> > Subject: [openvehicles/Open-Vehicle-Monitoring-System-3] 7516c9: test framework commands for testing can bus tx/rx > Date: 9 May 2018 at 9:18:53 AM 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: 7516c9681055ec7986a94ccb8cfb29bda5f1bce8 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/751… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-05-09 (Wed, 09 May 2018) > > Changed paths: > M vehicle/OVMS.V3/main/test_framework.cpp > > Log Message: > ----------- > test framework commands for testing can bus tx/rx > > > Commit: 183d26dc107bb21cd956776228d0a24030b115db > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/183… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-05-09 (Wed, 09 May 2018) > > Changed paths: > M vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp > M vehicle/OVMS.V3/components/ovms_server_v3/src/ovms_server_v3.cpp > M vehicle/OVMS.V3/components/vehicle/vehicle.cpp > M vehicle/OVMS.V3/components/vehicle_kiasoulev/src/vehicle_kiasoulev.cpp > M vehicle/OVMS.V3/components/vehicle_renaulttwizy/src/rt_battmon.cpp > M vehicle/OVMS.V3/components/vehicle_renaulttwizy/src/rt_notify.cpp > M vehicle/OVMS.V3/components/vehicle_renaulttwizy/src/rt_sevcon.cpp > M vehicle/OVMS.V3/components/vehicle_renaulttwizy/src/rt_sevcon_faults.cpp > M vehicle/OVMS.V3/components/vehicle_renaulttwizy/src/vehicle_renaulttwizy.cpp > M vehicle/OVMS.V3/main/ovms_boot.cpp > M vehicle/OVMS.V3/main/ovms_notify.cpp > M vehicle/OVMS.V3/main/ovms_notify.h > > Log Message: > ----------- > Notifications: Framework extensions to add support for subtypes on notifications, and automatic filtering by subtype and distribution mechanism > > > Compare: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/compare/57… > **NOTE:** This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/ > > Functionality will be removed from GitHub.com on January 31st, 2019.

4 20