- OvmsDev - Open Vehicles

Alert notification history
by Mark Webb-Johnson 13 Dec '19

13 Dec '19

To try to address Greg’s concern about DMC (debug only) alerts, as well as other requests, we have: https://github.com/openvehicles/Open-Vehicle-Server/issues/1 <https://github.com/openvehicles/Open-Vehicle-Server/issues/1> I have today implemented this on api.openvehicles.com <http://api.openvehicles.com/> and set the data retention to 30 days. From now onwards, if the vehicle raises a push notification, it will be stored in the historical data table under type *-Log-Notification. This history can be retrieved either with the protocol v2 api, or http api. Perhaps @Michael can deploy this to his server as well? Regards, Mark.

2 1

ESP-WROVER-B
by Mark Webb-Johnson 12 Dec '19

12 Dec '19

Our latest wifi-only modules are coming with ESP-WROVER-B module, and that includes 8MB PSRAM/SPIRAM (not 4MB, our standard so far). I have had one report from the field that factory firmware 3.2.002 works fine, but 3.2.005 crashes on boot with an error: (824) psram: This chip is ESP32-D0WD[[0m (824) spiram: Expected 4096KiB chip but found 8192KiB chip. Bailing out.. I see we have this in our sdkconfig: Type of SPI RAM chip in use ( ) Auto-detect (X) ESP-PSRAM32 or IS25WP032 ( ) ESP-PSRAM64 or LY68L6400 Not sure when that appeared, but I guess between 3.2.002 and 3.2.005. The user experiencing this problem is knowledgeable (he managed to recover back to factory), so I am trying a 3.2.007 build with him, with that setting set to auto-detect. Regards, Mark.

2 3

3.2.006 Release to Early Access Program
by Mark Webb-Johnson 09 Dec '19

09 Dec '19

https://www.openvehicles.com/node/2346 <https://www.openvehicles.com/node/2346> Today, we are pleased to release v3.2.006 to Early Access Program. A summary of the major changes is here: 2019-11-30 MWJ 3.2.006 OTA release - Web UI: Calibration and configuration aid for 12v monitor - Log monitoring via web shell - EGPIO/MAX7317: Port input monitoring, metrics, events, documentation - Powermgmt: New automatic power management module - Scripting: OvmsMetrics.AsJSON(), OvmsEvents, and OvmsNotify added - Logging: file logging moved to dedicated task (improved performance) - SWCAN: Support for add-on SWCAN module (see https://github.com/mjuhanne/OVMS-SWCAN) - Pushover: New Pushover notification framework support - SIMCOM: Allow user to set custom SIM PIN code - Metrics: 'metric list -s' shows metric age and staleness - Others: Factory reset from web/remote shell by "module factory reset -noconfirm" - Renault Zoe: Basic Metrics and charging status added, trip notify, web config for battery capacity - Volt/Ampera: Major update (including web config, SWCAN support, etc) - Twizy: Send custom OBD2 requests, output response as hex dump - Immediate tuning metrics updates (was delegated to ticker before) 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) 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.

2 5

Time for 3.2.006?
by Michael Balzer 09 Dec '19

09 Dec '19

Looking at the git log and changes.txt I'd say it's time to head for the next main release. The current build with the latest changes and tiT on core 1 is working very smoothly here. No crashes, CAN RX overflows are down to 0.25 per mille and SIMCOM overflows around 0.3 per mille. Espressif have announced they're incorporating the PSRAM fix into the official toolchain now, but there is no schedule for the release. Are there any open issues that need to be fixed for 3.2.006? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 4

Locations and scripts
by ovms 03 Dec '19

03 Dec '19

Hi I would like to run scripts based on location. The scripts work fine, but the location service stops working. I guess the location service requires CAN1 to be working? Since CAN1 stops receiving after a short period of time, the location service also stops. Is there a way to bypass this so the location service does not depend on CAN1 working? Kind regards, Stein Arne Sordal

7 61

OpenChargeMap API https
by Michael Balzer 02 Dec '19

02 Dec '19

Mark, the OpenChargeMap API has just changed to force redirecting to the https version -- basically a good idea. That broke the Android App OCM implementation: the standard Android InputStream class conveniently opens streams from URLs, but does not follow redirects. I've changed all API URLs to https, should have done so before when https became available for OCM. Maybe the iOS reader is smarter here, but maybe you should check that. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 2

Help
by Tamás Kovács 30 Nov '19

30 Nov '19

Can anybody compile my fork and send it to me, the ovms3.bin? I would like to test, because this code works well if i compiled my old computer ( i sell it), but now always crash with the new one. My fork address: https://github.com/KommyKT/Open-Vehicle-Monitoring-System-3

1 0

Android app updated, lost my car
by Greg D. 25 Nov '19

25 Nov '19

Last night the Android app updated on my phone. I'm still getting alerts from the car, but the only car shown on the app is the "Demonstration car", which of course, isn't active. I've added the car back, and it seems to be working. So, just FYI. Greg

9 15

Fwd: [openvehicles/Open-Vehicle-Monitoring-System-3] f84837: Server V2 & V3: fix registration for notifications...
by Mark Webb-Johnson 19 Nov '19

19 Nov '19

I don’t think this fix is correct. Seeking clarification of the thinking behind it. Currently, MyOvmsServerV2Reader is initialised to 0. Then, OvmsServerV2::OvmsServerV2 creates the reader (and sets MyOvmsServerV2Reader to it) if it is zero. Then OvmsServerV2::~OvmsServerV2 deregisters (clears) the reader, but does not set MyOvmsServerV2Reader to 0. The change is to OvmsServerV2::OvmsServerV2 to register the reader (without setting MyOvmsServerV2Reader) if MyOvmsServerV2Reader is 0. This seems to leak one reader every time the OvmsServerV2 is stopped/started, as without storing in MyOvmsServerV2Reader, the old reader will never be cleared upon deregistering. Or am I missing something? It seems that the better solution is to change OvmsServerV2::~OvmsServerV2 to set MyOvmsServerV2Reader=0 after deregistering (which is the original bug, imho)? Regards, Mark. > Begin forwarded message: > > From: Michael Balzer <noreply(a)github.com> > Subject: [openvehicles/Open-Vehicle-Monitoring-System-3] f84837: Server V2 & V3: fix registration for notifications... > Date: 17 November 2019 at 11:22:46 PM HKT > To: mark(a)webb-johnson.net > > Branch: refs/heads/master > Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 > Commit: f84837a2ce40d32769134d0bb5fe6dee09d842b3 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/f84… > Author: Michael Balzer <balzer(a)expeedo.de> > Date: 2019-11-17 (Sun, 17 Nov 2019) > > 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 > > Log Message: > ----------- > Server V2 & V3: fix registration for notifications on restart > >

2 2

EGPIO / MAX7317 input monitoring
by Michael Balzer 17 Nov '19

17 Nov '19

Everyone, to better support plugins using hardware extensions I've added input monitoring + events + metrics to the EGPIO / MAX7317 module, and some documentation on it: * https://docs.openvehicles.com/en/latest/userguide/egpio.html * https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/465… Please have a look and extend if something's missing there. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0