https://www.openvehicles.com/node/2123 <https://www.openvehicles.com/node/2123>
Today, we are pleased to release v3.2.0-1 to Early Access Program (EAP) participants. This is the first public v3.2 version, and introduces an entirely new scripting framework based on an embedded javascript engine. Now, custom javascript modules and functions can be written to respond to system events. In addition, a host of other UI changes enhancements have been made.
A summary of the major changes is here:
2019-01-19 MWJ 3.2.001 OTA release
- v3.2 first public release
- New JavaScript modular framework allowing for dynamic scripting and object model
- New vehicle: Smart ED (adaption by Martin Graml )
- Mitsubishi i-MiEV re-write for OVMS v3
- Web UI: text / script editor
- Web UI: user plugin support (pages & hooks)
- Web UI: night mode by URI parameter, e.g. "…/#/dashboard?nm=1"
- Web UI: dashboard accessible w/o login
- Web UI: added config backup & restore tool
- Web UI: file selector added for firmware flashing from SD
- Web UI: text notifications (info/error/alert) displayed as dialogs
- Twizy web UI: drivemode buttons secured & added to dashboard
- Twizy web UI: added file dialog for virtual dyno recording
- Twizy: SEVCON monitoring & recording
New commands:
xrt mon start []
xrt mon stop
xrt mon reset
New metrics:
xrt.i.* = operational inverter data
xrt.s.* = power & torque by speed (virtual dyno)
- Twizy: experimental powermap calculation including region 3 / breakdown torque
New config:
xrt [motor_trq_breakdown] = 0 Breakdown torque in Nm, e.g. 210.375
xrt [motor_rpm_rated] = 0 Rated speed in rpm, e.g. 2100
See docs/Renault-Twizy/Twizy-Powermap-Calculator-Tbrk.ods for details.
- Add inactivity watchdog timers to CAN buses
- NissanLeaf: Fix for 0% SOH on 30KWh models with Nissan BMS update
- Introduction of support for DBC CAN bus configuration files
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 also includes the 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 or later, you can enable this for future firmware releases with 'config ota auto yes'. You can choose the release level by setting 'config ota tag edge|eap|main', as one of:
edge: Bleeding edge developer nightly-builds
eap: Early Access Program (full releases, but with little public testing)
main: Publicly tested full releases (the most stable)
We expect to release the 3.2.001 firmware to 'main' (all users) after EAP testing (most likely within a week or so).
Thank you to all the open source developers who have contributed to this, and previous, releases, and thank you for your support of the project.
Open Vehicles
Everyone please have a look at…
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/189…
Please try to reproduce the bug on your modules.
I'm open for explanations.
I thought this might be some copy-on-write bug with std::string, but the gcc 5.x libstdc++ does no longer use that implementation (wouldn't be C++11 compliant
as well). I also tried moving all strings to temporary buffers, but modes 5 & 6 eliminated this explanation as well.
My remaining theories:
* A task writing out of bounds (but only 0-bytes?)
* A hardware issue only affecting some modules
A hardware issue only affecting some percentage of ESP32 could explain this as well as the strange heap corruptions that seem to affect some modules especially
often.
Regards,
Michael
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
