Firstly, an apology for the continued delays with this. The IOT environment is changing so fast, and there are so many amazingly capable choices appearing in the market, that it is hard to select one and live with it for the coming years. That said, we now (finally) have a solution that I think will provide a fantastic platform for OVMS in the future, and meet most of our goals. So, here’s the design outline. MCU Platform I’ve obtained samples for, and tested, over a dozen MCU platforms over the past 9 months. None have been perfect, but one has come very very close. As many of you guessed, I feel that the ESP32 platform <https://espressif.com/en/products/hardware/esp32/overview> has pretty much everything we need and is the clear winner. a) Cost effective (MCU, bluetooth, wifi, plenty of RAM and FLASH; all in a single module the size of a postage stamp). b) Free-RTOS based operating system c) Over-the-air update support d) Open GNU based toolchain e) Great community support The main negative is that it only has a single on-board CAN bus, and that has zero documentation at the moment. But it has SPI and can interface to something like the MCP25625 to give us up to 3 CAN buses. The other issue is that this is so new that documentation is limited; although the manufacturers are working hard on this, and helping us where they can. So, from a platform point of view, that is what I am working on. A motherboard of our own containing buck converter style DC-DC conversion (high efficiency) from both 12V (vehicle) and 5V (usb), a WROOM-32 ESP32 FCC/CE certified module, SD-Card, USB port, OVMS ports, CAN circuitry, and two expansion slots. Expect 16MB RAM, giving us about 4-6MB maximum code size (based on the OTA scheme of one factory firmware image, one running firmware image, and one downloading firmware image). That base module will support bluetooth and wifi connectivity. Cellular will be provided by a plug-in module in an expansion slot, leaving one spare expansion slot free. Low power modes will be built in to the design, from the bottom up. I’m trying to get the cost of this right down. Base module cheaper than OVMS v2. With the cellular option, around the same price. A base OVMS v3 module could be used for CAN bus reverse engineering work, data logging, etc, at a very very competitive price. We’ve got prototypes for this running on breadboards already, and we are about to start the board and casing layout. I’ve also got a handful of ESP32 development boards available if anybody wants to help out with base platform code. Cellular Connectivity The base module will have an expansion connector for optional cellular connectivity. The idea is to make this modular, so we can swap out modems if necessary. The issue with OVMS v1 and v2 has been cellular connectivity plans. Everyone using a mix of prepaid SIMs, on a huge number of different networks, and all of us having to deal with topping-up and other hassles; the AT&T sunset of 2G being a good example. We tried GeoSIM, but it is just too expensive. A few years ago, I backed a kickstarter project called ‘konekt’. They were building a small cellular module, and IOT cloud, very early on. What they have produced has turned into two offerings: a) their cellular module with support for their cloud, and b) a MVNO (mobile virtual network operator) with very competitive data rates and worldwide coverage. You can find them now at www.hologram.io <http://www.hologram.io/>. I’ve been watching them grow, and testing their SIMs, and have been very impressed. It seems to be an amazing match for what OVMS needs. Specifically: a) Simple SIM that we can add to every OVMS module going out the door. b) Global activation (they use two zones, with most of the world where OVMS is in the cheapest zone 1). c) Zone 1 pricing of about US$0.40/month basic upkeep, plus US$0.60 - US$1.00 per MB of data. Zone 2 perhaps 20%+ more expensive. A 3MB zone 1 plan is around US$2/month all in (US$3/month in zone 2). d) Free inbound SMS. We can offer an option to put the cellular modem to low-power sleep, and be woken up by an SMS (from OVMS server) when an App connects. Free. Perfect for vehicles like the Twizy. e) Simple API based console so we automate the accounting side of things. f) Bi-directional SMS is available for normal SMS style rates (free inbound, with outbound at about US$0.19/message, plus US$1/month in USA if you want a fixed number). Hologram has partnerships with multiple carriers for each country. For example, in Hong Kong my car OVMS uses a family-plan style multi-sim approach. I get four SIMs and they all share the same data, call and sms plan. The one I use is from a carrier called CSL. It works well, except in front of my house or in my garage - where there is no coverage. I pulled out that SIM and put in a hologram sim (remembering to change the APN to “HOLOGRAM” before I did it, of course). The Hologram sim immediately connected to CSL and everything worked smoothly. Then I moved the car to the front of the garage. I saw the network disconnect from "Hong Kong CSL Limited” (carrier lost) and reconnect to "SmarTone Mobile Com Ltd”. Then I reversed into the garage, and saw the connection switch to "Hutchison Hong Kong”. On my drive to work I took a northerly route near china and got a switch to "China Mobile HongKong Comp Ltd”. The point is that I’m paying one data plan, but able to take advantage of 4 different networks. The plan is to put these SIMs in every OVMS module from the factory, and to offer a quick and simple provisioning system. Other SIMs could of course still be used, but this would be the default approach. Hologram SIMs are also available today to OVMS v2 users in USA (particularly those about to be stranded by AT&T). Hologram supports the T-mobile network in USA. This should give us some breathing room to give us time to get OVMS v3 out, without rushing things but getting things right as a base platform going forward. Protocol When OVMS v1 was designed, we rolled our own protocol out. This was far from ideal, but it was so early in the IOT world that there wasn’t anything else out there lightweight and mature enough to be used. Today, things have changed and there is a huge selection to choose from. That said, there is one clear winner of all these choices. The IOT world is varied, but the one clear solution that has appeared is MPPT (Message Queuing Telemetry Transport <https://en.wikipedia.org/wiki/MQTT>). The decision as to which hardware platform to choose has been incredibly hard. By comparison, the choice of protocol is a ‘no brainer’ - OVMS v3 will use MQTT. Specifically, MQTT v3.1.1 over SSL over TCP/IP. The protocol itself is very lightweight, very flexible, and offers a simple but powerful publish/subscribe model. The big advantage of this is that it is an open protocol with many clients and applications supporting it. Your house can subscribe to vehicle events just as easily as your cellphone app. Relatively easy to do “Hey siri set my car temperature to 20 celcius” style actions, as well as hook into home automation, etc. Server I really like the Amazon approach to MQTT, but consider that too proprietary and hard to integrate to others. We’ll probably end up just running our own Mosquitto MQTT server on the same machine as OVMS v2 currently runs on, but the protocol is open and easy to choose from the dozens of implementations out there. Apps Existing Apps should continue to work via a bridged OVMS v2 server. Longer-term, it will not be hard to change the Apps to switch to MQTT protocol (presumably over websockets). So, that is the plan. I hate to give timelines (especially when it depends so much on the ESP32 Expressif guys getting their documentation out, and WROOM-32 modules available in large quantities), so all I can say is it is happening ‘now’. I have the development environment in place, and am building the framework support for OVMS using the development boards I have. Also working with the guys in China to get the OVMS v3 hardware design finalised. I hope to be able to release what I have so far to github before the end of November. Regards, Mark.