[Ovmsdev] OVMS 3.1 Production

Mark Webb-Johnson mark at webb-johnson.net
Wed Mar 21 10:21:13 HKT 2018


Both the 3.0 box in my car, and 3.1 on my desk, are running fine with the firmware I built and tagged this morning as 3.1.000. That version is now available on api.openvehicles.com <http://api.openvehicles.com/> as an OTA update. I’ve sent that to the factory, along with the QC instructions we have. It is not perfect, but it is good enough for a factory starting point. I’ve also sent the factory the production/qc/production_notes.txt for production/QC steps.

Pressure is off a bit now. We have some time to work on documentation, stability and fine-tuning (which is what I will be concentrating on for the next few weeks). The OTA update system works well (I had a chance to play with Michael’s web based firmware update, and that went well), and should be usable for people to do OTA updates when they get the modules.

Feature wise, a web server OTA using file upload would be good. I’m finding Access Point mode very useful to get into the box from an iPad and play with it. Still have to work out how to get the module to connect to my iPhone hotspot (which may be a better way of doing things).

A single page QuickStart on the webserver would also be good to have; something people go to and enter password, vehicle type, vehicle ID, server, etc - all on one page. I started the user documentation, and there are quite a lot of steps to go through, on a bunch of different screens, to setup the box.

To set user expectations, there is a knownissues.txt file where I would like to keep a TODO list of stuff people want, as well as a list of what we can’t do that v2 could. That currently contains:

Open Vehicle Monitor System v3 - Known issues

* Wifi APCLIENT mode is to be considered experimental.

* SSH, TELNET, and WEBSERVER all register listeners for incoming calls. There
  is a possible security issue here as those calls may come over cellular
  networks (not just wifi). There is no firewalling of these calls. It seems
  that the correct approach to this is to validate the destination IP to
  make sure it is a wifi interface IP address; but this is not currently
  done.

* Bluetooth is not currently supported.

* Vehicle: Tesla Roadster limitations (vs 2.x):
  * Cooldown not currently supported.
  * Charge timer not currently supported.
  * Charge time predictor not currently supported.
  * VDS vehicle errors not currently supported.
  * Digital speedometer feature not currently supported.
  * CAC request not currently supported.

* Vehicle: Kyburz not currently implemented in 3.x.

* Vehicle: Mitdubishi iMiev not currently implemented in 3.x.

* Vehicle: NissanLeaf:
  * Remote telemetry wake-up for pre-2016 vehicles not currently supported
    (as required hardware wakeup circuit).

* Vehicle: Tazzari not currently implemented in 3.x.

* Vehicle: Think City not currently implemented in 3.x.

* Vehicle: Volt/Ampera not currently implemented in 3.x.

* Vehicle: Renault Zoe not currently implemented in 3.x.

* Advanced Charge control not currently implemented in 3.x.
  Note that scripting can go someway towards providing equivalent functionality.

I’d appreciate it if people could update that as necessary with things they want or that v2 did.

Thanks to everyone involved for getting to where we are. I’m expecting hardware to be coming out of the factory (and in my hands) early next week.

Regards, Mark.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20180321/2ae5022f/attachment.html>


More information about the OvmsDev mailing list