December 2016 - OvmsDev - Open Vehicles

OVMS logo
by Mark Webb-Johnson 06 Jun '17

06 Jun '17

We need to change the OVMS logo, to better reflect the vehicle independence. The existing logo is too much Tesla. Felix has kindly prepared a couple of options for us, attached below. My preference is for the one with the car outline (even though it retains a hint of Tesla), as it emphasizes the vehicle comms aspect. This is quite urgent, as the Teslive people are pushing for artwork. What do you guys/gals think? Regards, Mark

8 14

OVMS v3
by Mastro Gippo 20 May '17

20 May '17

Hi all, I'd like to resurrect an old conversation. As we know, the current PIC is quickly running out of resources and maybe it's time to switch to a better platform. Two CAN buses are now desirable too. A microSD slot and direct USB connectivity wouldn't hurt either. I will probably have to design a similar hardware for myself, so I'd like to contribute to the OVMS by sharing the HW platform if you want; no strings attached of course, if you decide that there's no need for the upgrade, I'll keep on working on my project by myself! :) That said, I'd like to throw a few ideas to the table. - MCU: I'd like to use an STM32 micro. They seem to be emerging as the standard choice for diy ARM projects, and this offers a few interesting opportunities: -Programming it in c/c++ with the manufacturer CMSIS standard libraries (boring) -Programming it with the mbed.org SDK. Unfortunately no dev boards are available with dual CAN bus, but it will be easy to move to the correct micro of the same series once most of the software is ironed out on a dev board like the https://mbed.org/platforms/ST-Nucleo-F302R8/ -Programming it with an RTOS. NuttX would be my choice, as it's the one used in the Ardupilot Pixhawk platform, and I'd like to learn it. This would mean a steeper starting curve, but a lot of flexibility later as a lot of stuff is handled on the OS level (network stacks, SD card & filesystems, multitasking...). FreeRTOS is a nice option too. I'd like to use the STM32F405RG as it's the most similar to the one found on the Pixhawk, but of course I'm biased because of that, and that micro is quite overkill for the task. We can of course use a lower specced part and lose some RTOS fuctionality as long as it has 2 CAN buses. - MODEM: I have no experience in this field; is the SIM908 still a good choice or does anyone think that we should try new platforms? I like this, but I don't know if the price puts it out of budget: http://www.telit.com/telit/Pulsar/en_US.Store.display.1001./ge864-gps On the bright side, it can be programmed in python, so we can offload some of the work to the modem. This *could* allow us to free some space on the PIC, and keep that platform without changing MCU.. - Enclosure: I think that, even with the new MCU, we can still fit the old enclosure. Is that ok, or should we think about a more automotive-friendly one? Maybe waterproof for the twizy? And that's it. I think that the core SW developers should voice their opinion, as there is a lot of work to be done on that front. A huge problem will be keeping backwards compatibility to add features for the v2 users, so we should discuss about this too. Regards MG

18 70

Nissan Leaf Climate Control
by Tom Parker 25 Dec '16

25 Dec '16

I sent a pull request with Nissan Leaf remote climate control support. I also wrote up a quick blog post with a photo of my gen 1 wakeup circuit: https://carrott.org/blog/archives/158-OVMS-Nissan-Leaf-Remote-Climate-Contr… I'll post a schematic of the circuit. Gen 2 doesn't require any hardware modifications. I added #define CMD_ClimateControl 43 // (ON or OFF) with argument 'on' and 'off'. I'm using temporary hack to enable climate control via the homelink buttons. If CMD_ClimateControl is suitable, could we add support in the Apps for a better button to toggle it on and off? I see there is a car_doors5bits.HVAC to signal that climate control is on, but I don't think that is exposed in the android interface. This would be a good candidate to provide feedback that the climate control is on.

3 5

Fwd: Please pass onto your software developer friends
by Mark Webb-Johnson 23 Dec '16

23 Dec '16

Robert has asked me to distribute this, as it may be of interest and relevant to members here. Regards, Mark P.S. I’ve cc’d Robert to this eMail, so you can reply directly. Hi, I am a start-up looking for a developer to come on board as a co-founder and would very much appreciate it if you could share the following with your developer contacts. Want to help save the planet? We believe that technology can do that and we are committed to making it happen. Every year vehicles dump nearly 3 billion-tonnes of CO2 into the atmosphere. Electric vehicles represent a clean alternative and we're focussed on maximising their take-up by making them easy to use. Our software overcomes the problems associated with highly variable range and charging times, by providing sat navs with the data to support electric vehicles quickly & easily. With over one million people worldwide already driving electric vehicles and with more and more manufacturers entering the market place, electric vehicles are becoming a reality. We are a start-up business in Basingstoke looking for a talented and effective senior developer to join as a co-founder. We currently have a prototype system that we want to develop into a commercial product. As well as product implementation this is an ideal opportunity to lead the company's technical development with the potential to progress to a CTO role. The ideal person will be experienced in the following areas Fluent in at least 3 programming languages (including one object orientated language) JavaScript SQL databases HTML/CSS UI/UX design scalable server management So if you want to help save the planet this is the opportunity for you. For more information or an informal chat please feel free to contact me Regards, Robert Sharpe (Managing Director) 07711 252971 Your Plugged-in Partner Evergreen Consulting is the trading name of Sharpe Consultants Ltd

1 0

Re: [Ovmsdev] OVMS update
by Julien Banchet 15 Dec '16

15 Dec '16

Hi Mark, Many Thanks for the update, I honestly can't wait as every single point of features are great! Just a couple of questions: - Do you forsee a data envelope to have on the mobile provider ? (payload * rythme might go up) I suppose most of the things can(/will) be configurable on the backend/provisionning side ("discard this"/"limit these to once an hour"...) - Will the backend be rewritten? I suppose it will have to, as this is nothing alike before... What language will it be based on? Honestly, I have loved Perl in the past, and even though I'm far from being Python fluent, the latter might be a better pick in terms of adoption. Again, Thanks ! JaXX./. On Wed, Dec 14, 2016 at 2:00 AM, Mark Webb-Johnson <mark(a)openvehicles.com> wrote: > A short update on OVMS. > > We are working hard on OVMS v3. The development environment for the > microcontroller we chose for v3 has finally stabilised to a point where we > can rely on it. There will be a new revision of hardware silicon around the > end of 2017Q1 and we'll most likely try to time the first production > releases of OVMS v3 to use that as soon as it is available. But, the good > news is that we have the production development environments available now, > and the CAN driver (although early beta) is working well. All the > components are finally in place and usable. This has caused us delays in > our plans, but we are confident that our choice of microcontroller was the > right one. This will give us a great platform for the future and most > importantly allow us to keep costs down without being constrained by > RAM/Flash memory storage (as was the case for the v2 PIC18 platform). > Bluetooth and Wifi support are a bonus. Work on the firmware for OVMS v3 is > ongoing, and we're hoping to release this to the open source team any day > now. Some highlights of the coming features for OVMS v3 include: > > > - Use of the industry standard MQTT protocol, for easier third party > integration (in particular to IOT and home automation systems) > - Event driven model for scripting events in the car (such as > geofencing, homelink, charge settings, etc) > - 3G > - Wifi > - Bluetooth > - SD-CARD support > - Reduced power consumption, and low-power sleep modes > - Dramatically more RAM and FLASH memory, to overcome limits of PIC18 > architecture used by OVMS v2 > - Firmware updates via SD-CARD and USB, without any special > programming tools > - Over-The-Air (OTA) firmware updates via wifi and/or 3G > - Expansion slot and port for extra functionality > > > In the meantime, we continue to support OVMS v2. The hardware is still > available on fasttech site, but we are over half way through what we think > will be the very last batch. > > In other news, we have partnered with hologram.io to provide a cellular > network for OVMS users (both v2 and v3). Early feedback from our users has > been fantastic, and this is now running in a bunch of OVMS cars. Use of > this is entirely optional, and the cost-effectiveness will depend on where > you are in the world and what other cellular options you have. We're not > forcing you to use Hologram; just making it easy for you to choose them if > you want. OVMS v3 will come with hologram.io SIMs included as standard > (but easily replaced if you choose not to use it). For OVMS v2 users in > USA, with the imminent shutdown of the AT&T 2G network, we recommend > Hologram.IO now. You can get SIMs from Hologram directly at > https://hologram.io/store/, and Tom has penned an excellent write-up of > how to switch to Hologram at https://www.idleloop.com/ > tesla/ovms/hologram.php. > > Regards, Mark. > >

3 3

Tom's Hologram instructions
by Mark Webb-Johnson 14 Dec '16

14 Dec '16

Tom’s instructions for Hologram are here: https://www.idleloop.com/tesla/ovms/hologram.php <https://www.idleloop.com/tesla/ovms/hologram.php> Regards, Mark.

2 3

OVMS v2 Memory/Settings Corruption
by Julien Banchet 12 Dec '16

12 Dec '16

Hi all, Thanks to Michaels last message to remind me to ask a question here: Since a few months, maybe a bit more because it happens only once in a while, I have noticed I wasn't receiving the SMS alerts (feature on SMSIP mode) , and sending a "Stats?" only gave me the nasty access denied answer. It turns out, using the application, I noticed that the phone number was getting corrupted (afaik, it's the only setting affected) Normally: "+33651886877" it became "+336k1886877" or "+33651886Z77" etc... like a solar flare bit flip ! It seems it happens only upon reconnection of the ovms module the the OBD plug (Twizy) as, well, the 12V battery, though brand new, can't last a weekend (car parked underground, I suppose the GSM needs to force a bit too much) So question: Has any one suffered from such an issue ? And, otherwise, Michael might be able to tell: Would having the feature on SMS only (without IP) consume less energy ? If so, would it possible to imagine a Hybrid mode, IP active only if vehicle on charge or keyon ? Thanks, JaXX, PS: Despite winter, thinking of building a solar panel + thin plexi sandwich for the rooftop, just because of the 12V battery :-) Only recent twizys can charge the 12V from the traction battery when resting.

5 21

Android App release 3.12.1
by Michael Balzer 10 Dec '16

10 Dec '16

https://dexters-web.de/openvehicleapp-release-3.12.1-text_80.en.htm OVMS Android App V3.12.1 APK: http://dexters-web.de/f/tw/OpenVehicleApp-release-3.12.1.apk Source: https://github.com/openvehicles/Open-Vehicle-Android Wiki: https://github.com/openvehicles/Open-Vehicle-Android/wiki V3.12.1 (2016-12-09): - Fixed OCM updater - Incremental OCM updates (using modifiedsince) - Added clear cache button to map settings - Fixed OCM clustering settings - Map remembers last zoom level - Map shows home button if autotrack mode is off - Added car capabilities to CarData + ApiService - Added Nissan Leaf images by Chris van der Meijden (chris(a)arachnon.de) - Added DNS parameter label - Added Twizy charge power feature label - Added climate control (command 26) & status support - Added Twizy charge power control to charge alert dialog - Added message timestamp to duplicate notification check - Support for Twizy V3.8.2 charge stop mode control - New option: background API service (this needs RECEIVE_BOOT_COMPLETED rights) - New option: broadcast API car status updates (for Automagic/Tasker/...) - New option: car command intent API (for Automagic/Tasker/...) - Handling for new framework car model variables & message fields - Replacing CR in system notifications for readability - Options menus optimizations - Code cleanups & fixes -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

Twizy release 3.8.2
by Michael Balzer 10 Dec '16

10 Dec '16

https://dexters-web.de/ovms-twizy-3.8.2-text_79.en.htm OVMS Twizy Firmware V3.8.2 Firmware: http://dexters-web.de/f/tw/OVMS-Twizy-3.8.2.zip Framework V2.9.2: - Keep volatile features over reset - Added speed & trip length to location update (msg L) - Added b4 + substate to JSON API - Fixed spelling of 'charge_etr_range' in JSON API Twizy 3.8.2: - Fill framework car_chargelimit from feature #7 - Added charge power to MSG CMDs #203,204 (Query/Set ChargeAlerts) - Skip feature init on CPU reset - Inhibit CPU reset during charging with charge power override - New: charge auto stop control (feature #6 / car_chargemode) - Added charge control to commands CA & #203,204 - Tightened SDO bus timing - Minor code size optimizations Charge stop mode is controlled via feature 6 or combined with limits and power level using the reworked "CA" & #203,204 commands. For example, to enable automatic charge stop on reaching a sufficient charge limit, issue: FEATURE 6 1 or CA S To set charge to stop at 80% SOC and use power level 3 = 1 kW, issue: CA 80% S L3 The Android App charge limit UI has been updated accordingly in V3.12.1. See documentation for more details. Source: https://github.com/openvehicles/Open-Vehicle-Monitoring-System/ -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

Twizy tuning disabled by Renault
by Michael Balzer 08 Dec '16

08 Dec '16

Hi everyone, sorry, this is no direct OVMS issue, but as many Twizy users seem to read here, this may be the fastest way to spread this news. Renault have disabled tuning on new Twizys. This applies to Twizys manufactured after June 30 2016, variants T45 & T80 have been confirmed, Cargo most probably as well. To check your SEVCON firmware, do these reads: CFG READS 1008 0 CFG READS 1009 0 CFG READS 100A 0 CFG READ 1018 3 The new SEVCON firmware version is: Product name: Gen4 (Renault Twizy)Thu Jun 30 18:21:36 Hardware version: T45: 0x00070104 T80: 0x00000103 Software version: 0712.0003 CANopen (Object Dictionary) revision: 0x00010021 The effect is, that any write access to some tuning register will result in a CANopen general abort code 0x08000000. Write access has been blocked selectively to just the driving profile registers. Login level still is 4 and other writes succeed, DCF download works. The blocked registers have not been changed in the object dictionary, so this is a hard coded handling. I currently don't see any way around this other than reflashing the controller with a previous firmware (which has not leaked up to now and cannot be read from the controller). Of course this not only affects OVMS tuning, but all Twizy tuning boxes. Only SEVCON tuning (CFG command) is affected, all other OVMS functions will still work. Please spread this info to your local Twizy communities. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 1