I understand some drain makes sense, my 3 year old Telsa was at about 4kW per week during the heights of the pandemic lock downs where it didn't move much. So about 4kw per day seems a bit high but maybe I just need to reset expectations.
If you want minute by minute data on the state of the vehicle logged then the logging program has to query the vehicle frequently which, when it is asleep, means waking it up, assembling the data, and, if in a remote location, forwarding it via the cellular network. That takes a fair amount of energy to do. Some people really value that data. Some are totally indifferent.
BS. Teslas have never swallowed as much juice (kwh) as these Rivians are. You would need to have Sentry on and Cabin temp protection on in the sun on a sweltering summer day to come anywhere close. Rivian needs to fix it. Stop making excuses for them.
This, I have never noticed vampire drain on my Model Y. Not saying it hasn't happened, but when it has it's been an unnoticeable percentage of my battery.
Right. This would equate to about 15-25 miles lost in your Y in a day. You would notice for sure.
Rivian couldn't just wait until their car was mature and matched Tesla. Besides vampire drain they are missing the easy and obvious battery preconditioning before charging feature. Everyone is rushing their cars to market, it's unrealistic or naive to expect a high quality bar. It would be desirable but that's not the world we live in.
Posts like this again reinforce my conclusion that many people do not understand what phantom drain is nor, therefore, what causes it nor how to mitigate it.
Stop making a fool of yourself. When people have real data it's hard to argue that it's wrong. You clearly don't understand what causes this and therefore don't understand that to "fix" it Rivian has to curtail functionality which people want.
In my particular case I run 2 programs which poll the car and my phantom drain is 4 kWh/day so I'd guess each is pulling close to 2 kWh/da but that would assume that all of it comes from those 2 programs when, in reality, there is lots of other stuff going on too. So perhaps around 1 kWh/da for each.
Actually they are quite efficient. Unfortunatey Rivian uses the term "efficiency" when they should be using "energy consumption". Others have commented on this here before.
This is real efficiency IOW if 100W is delivered by the mains only 90 - 95 W gets to the battery.
That's consumption. E.G. if the rolling resistance is 100 W/mi with the standard wheels it goes up to 110 - 115 W/mi with the non standard.
This is neither an efficiency nor consumption cost as it does not contribute to traction. It is an overhead cost for maintaining the vehicle is a "ready to go" state at all times. It can be stirred into an overal energy cost to operate calculation. Clearly it can increase overall consumption by a factor of 2 or more if the truck is not driven much or can be insignificant if it is.
I'd be really surprised if Rivian completely abandoned traditional automotive low power CAN bus architecture to control ECU sleep and standby communications/vehicle control/data logging functions - there's no excuse using 1 kWh or more per day just to poll the car and pass network traffic, if that's what's causing this, when ICE cars with similar remote access and networked status monitoring manage to keep 12V standby consumption for these features under 300 ÎĽA, around 1 Wh per day.
