[Ovmsdev] Notifications concept draft

Mark Webb-Johnson mark at webb-johnson.net
Tue Nov 7 07:48:24 HKT 2017


The issue is that to move to v3 in one giant leap, we would need to change the car firmware, server code, iPhone and Android apps. The user would also have to move everything over to v3 in one go (including ditching all his ovms v2 modules which will never be able to support a v3 server). This approach doesn’t seem a feasible.

So, the v3 architecture abstracts the vehicle model out into standardised metrics (v2 tried this, but didn’t take it far enough due to resource constraints and the limited Tesla Roadster focus of the original project). From there, we can have ovms_server_v2 and ovms_server_v3 components that support sending those same metrics to either v2 or v3 servers (or both). The vehicle support code itself doesn’t care (the protocol modules deal with any translation necessary). This gives us a gradual migration:

The ovms v3 modules support v2 protocol, so server and apps continue to work as before. This is where we are now (or are very close to).

We finalise the v3 server, and implement an ovms_server_v3 component to support that new protocol. (not too hard - mqtt, and metrics simply map to mqtt topics).

We make the apps support v3 protocol. (I’m interested in whether we can have a single unified app that runs on both Android and iOS).

We then still have the issue of support for ovms v2 modules. That can be addressed in one of two ways:
either have the new app(s) support both protocols
or change the ovms v2 server to act as a bridge to an ovms v3 server (producing metrics from the ovms v2 protocol messages). (this is my preferred option).

To do it this way only requires one more component (ovms_server_v2) in the ovms v3 firmware. It allows us to get something out much quicker than otherwise.

Thanks for the question - good to have the opportunity to clarify this roadmap.

Regards, Mark.

> On 7 Nov 2017, at 6:40 AM, Michael Balzer <dexter at expeedo.de> wrote:
> AFAIK the plan is to support v2 servers first, so existing servers and clients do not need to be changed to work with a v3 module.
> This is already quite usable: I can attach a v2 app via v2 server to my v3 module and see most of the standard infos.
> Having to build a whole new v3 infrastructure first would in fact be much more complicated and would need a lot more time until v3 becomes usable.
> v3 servers and clients will not need to support the v2 protocol, unless they want to be able to talk to v2 components.
> Regards,
> Michael
> Am 06.11.2017 um 22:23 schrieb HONDA S-2000:
>> Naive question here...
>> I see references to v2, v3, and v* - is the design plan to have clients and/or servers support multiple protocols at the same time?
>> That sounds way more complicated than just keeping v2 and v3 separate so that v3 clients and servers don’t have to support all of v2 if that turns out to be inconvenient. I realize that you’re probably just talking about reusing v2 protocols where prudent, even if v3 won’t be totally compatible, but I wanted to ask so that I’m on the same page.
>> Brian
>> On Nov 5, 2017, at 4:48 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>>> For send.info, I think it would be much better if the ovms_server_v* code could work out for itself what needs to be sent. Have a look at MetricModified() that I’ve just committed, as a starting point. (Sorry, I’d started work on that last night, but hadn’t committed yet. Done now.) Suggestion is to put the logic on ovms_server_v* MetricModified() rather than the individual vehicle modules. Things like if the car is turned on we should notify the apps, are universal.
>>> If there are cases where this is vehicle specific, then the send.info mechanism you suggest is ok; but I still think it better we don’t do this. Remember ovms_server_v3 is going to work differently (individual metrics, rather than groups). So, for vehicle specific cases (in particular for metrics not in metrics_standard.h) this approach is fine, but for standard metrics I suggest we use MetricModified() in ovms_server_v2.
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20171107/a2266554/attachment.htm>

More information about the OvmsDev mailing list