[Ovmsdev] Notifications concept draft

[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.