Rivian ABRP integration working (if you're motivated ?)

[bueller]

I have a feeling they are not really maintaining this rest api.

My calibrated reference consumption number has gone too high so I filed a bug report: https://abrp.upvoty.com/b/report-a-...nsumption-w-confidence-0-except-for-low-speed

Sponsored

 

[bueller]

I've got a lead. Last night I updated my code to provide an occasional power parameter to the API and also erased all the prior calibration data, and now today I have calibration reference consumption confidence in the 20s and 30s for all 3 speed ranges. The actual consumption number it has so far is also much more reasonable.

So I think ABRP itself is working as designed, as it did say in the API docs that power reports were necessary. The issue is the accuracy of the power estimate I am providing. Basically I have a template sensor that converts the SoC into a pack energy value, and then I created a derivative "power" sensor off that energy sensor. Then am feeding that value to the ABRP API, but only when SoC changes. If it calls the ABRP API for any other reason, I am not passing the power parameter to the API.

The proof will be in the accuracy of the consumption estimate. The new code is definitely more complicated, not expecting to post unless there is interest.

 

[shap]

Thank you - makes a lot of sense. Will be glad to see how you calculate power based on SoC.

But in general - it is very sad that Rivian can not make a simple integration for us...

 

[bueller]

Will be glad to see how you calculate power based on SoC.

I moved my code into a gist forked off that original one from earlier in this thread. Basically I have a "R1S Pack Energy template" sensor that multiplies SoC by large pack useful capacity, also multiplied by my wild guess of SoH, plus a wild guess of how much is left if SoC were to reach 0. From that sensor, I setup "R1S Power" as a derivative sensor.

The calibrated estimate it is producing seems low by 15-20%. Not sure exactly why but obviously SoC is only roughly proportional to energy. And SoC updates aren't coming in as fast as ABRP would want to consume power readings. However it hasn't been long either so I'll probably just leave it as is and see how it ends up predicting real road trips over the next few months.

 

[kylerw]

I moved my code into a gist forked off that original one from earlier in this thread. Basically I have a "R1S Pack Energy template" sensor that multiplies SoC by large pack useful capacity, also multiplied by my wild guess of SoH, plus a wild guess of how much is left if SoC were to reach 0. From that sensor, I setup "R1S Power" as a derivative sensor.

The calibrated estimate it is producing seems low by 15-20%. Not sure exactly why but obviously SoC is only roughly proportional to energy. And SoC updates aren't coming in as fast as ABRP would want to consume power readings. However it hasn't been long either so I'll probably just leave it as is and see how it ends up predicting real road trips over the next few months.

Been following along and taking advantage of your work. What do you have your timers set to - as they are not included in the gist from what I can find.

 

[bueller]

What do you have your timers set to - as they are not included in the gist from what I can find.

Sorry I forgot the timers, I just pushed a new commit with them.

 

[shap]

Just got a reply from ABRP:



Overall I would say that as we do not have Power available (and yes, you can try to calculate it in some way, but far from precise one), I feel that all this exercise is basically useless ...

 

[mindstormsguy]

Back in the old days ABRP used to just have a little + and - button to allow you to manually update the SoC as you drove. It still was able to build an accurate vehicle model that way over time. A live and automated version of that (this integration) is certainly a lot better. Mine seems to learn quite well. I don't use it much anymore because of how good the built in nav is. BUT, I do like having ABRP still for a) when I want to plan a route on my PC, and b) when I want to plan a route with a trailer, while not in the vehicle.

I've trained a "configuration" of my R1T in ABRP for 21" wheels, ATs, and with my big trailer. It's quite handy.

 

[bueller]

all this exercise is basically useless

The live data enables features that are useful to me even if the calibrated reference computation isn't reliable.

Still, while I'm not spending a lot of time on it at the moment, I'm not giving up on the derivative power approach. The power estimates mine generates seem too noisy/spiky given the low resolution and update interval, so my next thought is to run it through some kind of low-pass filter.

 

[Michal]

This is great. Could you post your NodeRed code

 

[mindstormsguy]

This is great. Could you post your NodeRed code

https://www.rivianforums.com/forum/...orking-if-youre-motivated-🙂.11731/post-271904

 

[Michal]

@mindstormsguy Thank you again for your JSON conde and assistance. I had to adjust the entity names, but it all worked out.

 

[djsider2]

For those that have completed integration, what reference consumption @65 did you get? How does it compare to the default ones ABRP has setup for Rivian? ABRP seems to include tire size in vehicle selection now.

 

[mindstormsguy]

For those that have completed integration, what reference consumption @65 did you get? How does it compare to the default ones ABRP has setup for Rivian? ABRP seems to include tire size in vehicle selection now.

I have 2.25 for my truck with 21s

 

[bueller]

Rejoice! https://www.rivianforums.com/forum/...ve-integration-posted-on-riviantracker.29373/

Sponsored