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@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.
- 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”…)
We are hoping to be able to control reporting with better granularity. Data usage will probably have to go up (MQQT is not as efficient as our proprietary protocol), but we can offset that by smarter usage of the cellular network as well as use of wifi where available.
- 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.
We are planning on using a standard MQTT backend. Currently working with mosquito. There are some ancillary scripts, but not too many. Regards, Mark
On 14 Dec 2016, at 4:47 PM, Julien Banchet <jaxx@jaxx.org> wrote:
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@openvehicles.com <mailto:mark@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 <http://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 <http://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/ <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 <https://www.idleloop.com/tesla/ovms/hologram.php>.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On Wed, Dec 14, 2016 at 1:38 PM, Mark Webb-Johnson <mark@openvehicles.com> wrote:
We are planning on using a standard MQTT backend. Currently working with mosquito. There are some ancillary scripts, but not too many.
Sorry, wasn't asking about the messaging protocol and broker (I 360% would opt for MQTT as well (reminds me a have open mosquitto's around for my home automation and geo tracking, gotta lock some stuff down :-) )) But it cannot do much alone, I was wondering what the rest would be implemented in, provisioning tools & website, the cmd.pl remplacement, and what choices (plural) have been made about data storage? JaXX./.
Julian, I really haven’t thought about it. I haven’t done much with those tools. I’m going to implement the push notification and database plugins myself, and probably use perl/python for those (but not yet decided). I really like mosquito, but it has no message plugin architecture. Seems to require an external service process to read and response. Not too bad anyway, but just more services to fail. Regards, Mark.
On 14 Dec 2016, at 10:07 PM, Julien Banchet <jaxx@jaxx.org> wrote:
On Wed, Dec 14, 2016 at 1:38 PM, Mark Webb-Johnson <mark@openvehicles.com <mailto:mark@openvehicles.com>> wrote: We are planning on using a standard MQTT backend. Currently working with mosquito. There are some ancillary scripts, but not too many.
Sorry, wasn't asking about the messaging protocol and broker (I 360% would opt for MQTT as well (reminds me a have open mosquitto's around for my home automation and geo tracking, gotta lock some stuff down :-) )) But it cannot do much alone, I was wondering what the rest would be implemented in, provisioning tools & website, the cmd.pl <http://cmd.pl/> remplacement, and what choices (plural) have been made about data storage?
JaXX./.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (3)
-
Julien Banchet -
Mark Webb-Johnson -
Mark Webb-Johnson