[Ovmsdev] OVMS Power Drain?

Fri Sep 30 17:39:41 HKT 2022

Thankyou all!

I have not been idle - I've not quite moved away from the polling for
receiving information.. but at least now I can clamp right down on it being
used while the car is off by looking at the 12v power!

The only code in the original  using tester present is the commands, which
I am yet to try.

I will have a look at the upmiigo code. I'm not seeing multiple high
levels.. But once it spikes I can poll for a bit.

There is a crash that happens periodically.   It's not in my code I don't
think as I have put a debug on all functions in the directory that logs if
it isn't 'disarmed'.  Not for production, but useful.

I guess once I have a GPS aerial I can use that to make sure the polling is
activated on movement! I'm guessing it has to be significant to avoid
inaccuracies of GPS triggering it.

Michael

On Wed, 28 Sept 2022 at 14:21, Michael Balzer <dexter at expeedo.de> wrote:

> Cars now often do not provide live process data frames on the OBD port's
> primary CAN. You may have an auxiliary CAN bus there, e.g. for infotainment
> communication, that may provide live frames. But you may not be able to
> detect a charge session from these.
>
> A very simple approach is to monitor the 12V level. For example on the
> UpMiiGo, if it rises to around 13V the car is recharging the 12V battery,
> if it goes to 14V or higher, it's fully awake for a drive or charge
> session. We used that approach until I found PIDs we can poll without
> keeping the car awake.
>
> If you didn't do so yet, try polling without a tester presence or diag
> session.
>
> Also try polling low priority / auxiliary PIDs instead of the actual
> status PIDs, i.e. PIDs that do not carry crucial system state data.
>
> You may also need to keep the polling frequency below some threshold to
> avoid the keep-alive trigger.
>
> Regards,
> Michael
>
>
> Am 28.09.22 um 06:15 schrieb Timo Penttilä:
>
> Hi Michael.
>
> Back when I had a Kia Niro I did some measurements on power draw.
>
> It’s not the poll itself that causes the power drain, it prevents the car
> from going to deep sleep. So I don’t think polling less frequently will
> have much effect. I didn’t find any way on the Kia to detect if it’s on
> without additional hardware involved, e.g. to check if there was power on
> the radio fuse.
>
> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/275
>
>
>
> *Best Regards*
>
>
>
> *TIMO PENTTILÄ*
>
>
>
>
>
> *From:* OvmsDev <ovmsdev-bounces at lists.openvehicles.com>
> <ovmsdev-bounces at lists.openvehicles.com> *On Behalf Of *Michael Geddes
> *Sent:* den 28 september 2022 04:31
> *To:* OVMS Developers <ovmsdev at lists.openvehicles.com>
> <ovmsdev at lists.openvehicles.com>
> *Subject:* Re: [Ovmsdev] OVMS Power Drain?
>
>
>
> Yeah, I'm beginning to see that continuous polls are Bad(tm).
>
>
>
> With my latest changes, the 2 polls that are always done are for detecting
> On and Unlock which are on different module addresses. Setting the Car Type
> to NONE (and rebooting) certainly confirms that the battery drain goes
> away. Crap.
>
>
>
> Is there a better way of detecting 'On', 'unlock' and possibly 'alarm'?
> Anything else could be checked much less frequently anyway.
>
>
>
>  Maybe I could use internal battery test changes to trigger checks... A
> bit dodgy though.
>
>
>
> Should I expect to see _any_ messages floating around on the bus without
> being requested? I'm not seeing any..  Presumably if I send 'Tester
> Present' it will keep the module powered (and back to square 1), or is
> there some kind of bus switch that is not letting me see messages? I'm
> coming into Can messages as a complete noon.
>
>
> Maybe Peter could help me on this, and we could put some of my changes
> back to kia/Kona or the common class when I'm done.
>
>
>
> I'll certainly look at using the wakeup.
>
>
>
> BTW for  updating images I have set a SSH pubkey and am using
>
> scp <<image>> admin at ovms.lan:/sd && ssh admin at ovms.lan "module reset"
>
>
>
> Which works like a charm!
>
>
>
> Michael
>
>
>
> On Tue, 27 Sept 2022, 3:55 pm Michael Balzer, <dexter at expeedo.de> wrote:
>
> Michael,
>
> it's generally a bad idea to have polls running just based on the client
> connection status. Clients may be connected all the time, e.g. if users
> attach some API pollers or set the App to persistent background operation
> (which is necessary for widgets or tasker scripting for example).
>
> You should only enable polling when actually necessary to perform some
> user requested action, or to monitor a drive / charge session of course.
>
> We've got an explicit "wakeup" command users can call to tell the module
> to wake up the car. That needs to implement some timeout to put the car
> back to sleep if it doesn't do so by itself.
>
> Regards,
> Michael
>
> Am 27.09.22 um 09:41 schrieb Michael Geddes:
>
> Thanks Michael,
>
>
>
> I rang the Hyundai service centre, and apparently, my BMS should not need
> any updates (build date 2021 vs 2020 cars with the problem apparently), but
> I'm putting it in for a checkup of the battery.  Apparently, the BMS update
> was the subject of a recall for those cars affected. I'm going to take it
> in anyway in case.
>
>
>
> It seems, according to the OVMS, that the 12V is going from 13v down to
> 12v over about 3hours before (generally) being recharged.  Looking at that
> link you shared with me (and related
> https://www.youtube.com/watch?v=lr3Z_z1C0Uk&t=965s), it should be more
> like 24 hours.   It still should be triggering a charge cycle - and
> obviously in this case it seems to miss one and then it just goes downhill
> from there - so maybe the BMS still has a bug; not helped by being forced
> to trigger about 4x more frequently than normal!
>
>
>
> Assuming nothing is wrong with the car (which unless I install some kind
> of external battery monitor like that youtube clip), I can only assume that
> the 3hr drain is because my Ioniq 5 module is polling too much (which,
> seeing I copied the vehicle_kianiroev/src/ as my base, would mean THAT
> polls too much as well).  I still have the  PollSetPidList() called with
> the same data (albeit a copy) as the Kia.
>
>
>
> So in drafting this email I think I've hit on the problem, which is when
> the car is off, but a V2 or V3 client is connected (like the android app in
> 'background' mode), then it uses the 'Charging' pollstate element.
>
>
>
> It has {OFF, Charging, ON} at the moment, which means there's space for a
> 4th which I will assign to 'off, not-charging and clients connected'.  I'll
> see what I can do to drop that right down in polling frequency and the
> number of modules being addressed.
>
>
>
> At some point soon it might be worth me pushing up to a fork in case
> anybody else wants to jump in!  For example, the Lock module that the kia
> has is not present in the Australian version, but I suspect US ones with
> key-card ability might have it.
>
>
>
> //.ichael
>
>
>
> On Fri, 23 Sept 2022 at 17:03, Michael Balzer <dexter at expeedo.de> wrote:
>
> Michael,
>
> while the OVMS draws some power, unless you actually keep the car alive
> by polling, that's normally no issue. The 12V battery will be recharged
> automatically from the main battery by the car.
>
> The Ioniq 5 though has a history of issues with the 12V battery.
> According to Andrew Till, a BMS update has fixed his issues:
> https://www.youtube.com/watch?v=YmfkvL_O1IA
>
> Also see his previous posts on that topic.
>
> Regards,
> Michael
>
>
> Am 23.09.22 um 09:55 schrieb Michael Geddes:
> > Hi All,
> >
> > I have just had a bit of a painful experience with my 12V being
> > drained (twice).  I'm guessing it's related to OVMS, but also
> > something seems to have happened as it was running file for a week!
> >
> > For some reason, the 12V battery graphs aren't working in the
> > (android) App.. which means I'm not quite sure of the timelines,
> > however it was most likely overnight.  This morning my 12V was
> > severely depleted (like 6v!). (Oh, it could be because I don't have
> > the app running in the background).
> >
> > I'm assuming it's likely not to be the direct drain of the device
> > itself, but maybe something it is querying on the CAN busses or
> > something that is then causing a consequential power drain?
> >
> > I got road-side assist out and they got me going, but then 20mins
> > later it was flat again! (I did see an alert in the APP and so was
> > quick to go out, but was unsuccessful in getting the car going before
> > it died!).
> >
> > I'm going to unplug it and see if that stops the card from dying.
> > Also, I might leave the car on for a bit longer.. but still I have
> > concerns!
> >
> > Also I haven't started using 'write' commands yet. Any ideas?
> >
> > //.ichael
> >
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
>
> OvmsDev mailing list
>
> OvmsDev at lists.openvehicles.com
>
> http://lists.openvehicles.com/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.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/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.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20220930/07524766/attachment-0001.htm>