RFC / Roadmap: ovms-link 3.0 - Migrate to OVMS plugin

[kezarjg]

I'd like to lay out a 3.0 for ovms-link and get your input. The goal: turn the hand-installed script into a proper, installable OVMS plugin which is easier to install and update, friendlier to set up, and aware of your ABRP plan. Several open issues fold directly into this; I've tagged them per feature.

This whole direction was kicked off by @stumbaumr in #38 ("Use OVMS plugin infrastructure to deploy abrp.js to OVMS module"). Thank you for the suggestion.

Proposed 3.0 features

1. One-command install & updates - Package as an OVMS plugin (plugin install / plugin update) served from a hosted repo, so there's no hand-copying files into the editor. → addresses Use OVMS plugin infrastructure to deploy abrp.js to OVMS module #38
2. Cert reliability - Proactively install the specific CA roots OVMS's firmware doesn't ship at first run, so the recurring "SSL Error" reports are pre-empted rather than hit-and-recovered. → addresses SSL Error (Code 3.3.005-3-g4f3f7688) even after adding amazon.pem #39, Again SSL Error? #35
3. Bandwidth: per-point delta encoding. - Omit unchanged fields to cut cellular data usage. → addresses Enhancement: can unchanged fields be omitted from bulk telemetry points to save cellular data? #41
4. Web UI - A config page (enter your ABRP token via a form instead of config set, with a "Connected as … — your vehicle" confirmation), a live status/plan dashboard (queue depth, last send, current telemetry).
5. Plan awareness - Use ABRP's plan to fire an OVMS notification when you've reached your charging target, so you know it's time to unplug and go without watching the app. Plan info (next-charge target, etc.) would also be surfaced on the dashboard.

Feedback wanted

• Which of these matters most to you? What would you install 3.0 for?
• Dashboard must-haves. What would you want to see at a glance?
• Help wanted: testers on different vehicles (Leaf, Kia, MG, etc.). The metric mapping is per-vehicle.

Comment below. Thanks!

[stumbaumr]

The user interface when driving for me is clearly ABRP on the smartphone/car play/android auto and not the OVMS dashboard!
For reliability I still would prefer Bluetooth LE communication from OVMS to SmartPhone ABRP App - but that is not about to happen soon as I understand.

I want 1. and 2.
I like 3. and 4. for convenience.
Don't need 5.

I can test for a Smart EQ ForFour.

[kezarjg]

@stumbaumr — thanks, this is exactly the kind of feedback I was after.

Quick clarification on the dashboard (#4): I should've been clearer. It's not meant to be a driving display. Fully agree with you that the driving UI is ABRP on the phone / CarPlay / Android Auto. The web page is for setup and diagnostics: entering your ABRP token in a form instead of config set, confirming "Connected as … your vehicle", and a status view (queue depth, last send, current telemetry) for when something looks off. Not something you'd ever glance at while driving.

On Bluetooth LE, what you're describing (OVMS feeding the phone's ABRP app over BLE so it rides the phone's connection instead of the module's link and the cloud round-trip) is a separate project: it'd mean making the OVMS module act like a standard Bluetooth OBD-II dongle, the kind ABRP already reads from natively. That's a different codebase and problem from ovms-link, which works entirely through the Iternio Telemetry API (the cloud path). Worth someone tackling, but out of scope here.

What 3.0 can do for reliability on the API path: a drop-safe send queue with retry, a keep-alive heartbeat so the ABRP session doesn't go stale, and the delta encoding (#3) to cut how much has to get through on a marginal connection.

One more clarification on plan awareness (#5), since you flagged it as a skip: the main use I have in mind is a concrete, hands-off one; firing an OVMS notification when you've hit your ABRP charging target, so you know it's time to unplug and go without watching the app. If that reframes it for you, let me know; either way it's good to know it's low priority for your use.

So I've got you down as: 1 & 2 must-have, 3 & 4 welcome, 5 not needed. That's really useful for prioritizing.

And yes please on testing, that'd be a big help when there's a build to try. I'll ping you here.

[DragonEndeavour]

Hi there, for me features 1 through 4 are cool, same as @stumbaumr feature 5 isn't necessarily important for my usual journeys as I usually don't charge outside my house. Maybe only thing to add would be in feature 4 allow for more configuration options like calibration speed or the thresholds for the time elapsed to send info, so it's easier to adjust for individual reasons.

Also can test on smart forfour ED4 and fortwo ED3.

Best regards, Nick.

[egoetz-zz]

1 & 2 Wanted!
3 & 4 would be nice
Don't need 5.
Thanks for the initiative!
Would be happy to test for my VW e-up.

[stumbaumr]

My daughter was just recently on a trip where she had to charge on the way. OVMS -> ABRP communication had problems, because the OVMS uplink with that specific SIM is not reliable on some routes(Germany - mobile network here is the worst!). At some point she almost missed to charge, because there was no update and the ABRP still reported 22% SoC while the car showed 8%...

I would rather invest time now into OVMS -> BLE -> Smartphone -> ABRP App than fixing this...

[Jetiman]

My daughter was just recently on a trip where she had to charge on the way. OVMS -> ABRP communication had problems, because the OVMS uplink with that specific SIM is not reliable on some routes(Germany - mobile network here is the worst!). At some point she almost missed to charge, because there was no update and the ABRP still reported 22% SoC while the car showed 8%...

I would rather invest time now into OVMS -> BLE -> Smartphone -> ABRP App than fixing this...

For Germany, go with the provider "Simbase." It costs around €10 a year with heavy usage. It connects to whichever network is currently the best.

[kezarjg]

My daughter was just recently on a trip where she had to charge on the way. OVMS -> ABRP communication had problems, because the OVMS uplink with that specific SIM is not reliable on some routes(Germany - mobile network here is the worst!). At some point she almost missed to charge, because there was no update and the ABRP still reported 22% SoC while the car showed 8%...

I would rather invest time now into OVMS -> BLE -> Smartphone -> ABRP App than fixing this...

Is there a reason you don't connect OVMS to the Smartphone via wi-fi hotspot instead of relying on the OVMS SIM? That's what I typically do while driving...

[stumbaumr]

Is there a reason you don't connect OVMS to the Smartphone via wi-fi hotspot instead of relying on the OVMS SIM?

To complicated to explain to all the other users of the car...
Would need to maintain all mobile phones of the family on the OVMS and they would have to enable the HotSpot when driving off. Not gonna happen...