[Ovmsdev] Happy discovered: I3 seems to manage 12v battery charge by itself
Michael Balzer
dexter at expeedo.de
Sat Jan 16 22:20:04 HKT 2021
Steve,
"awake" = vehicle has been switched on by the user
"on" = vehicle is in drive mode ("ignited")
The point is, "charging" is not "being awake". The idle alert checks if
the car is awake but not moving.
If you cannot tell if the user switched on the vehicle, assume it isn't
when you detect charge mode.
Another option is to implement your own idle alert handling, e.g. by
overriding OvmsVehicle::NotifyVehicleIdling().
The vehicle.charge.state event is bound to changes of the "v.c.state"
metric. Charge state is meant to only cover main battery charge states,
it's defined & assumed to be one of…
// charging, topoff, done, prepare, timerwait, heating, stopped
…or empty (unknown). There's currently no "idle" state, it's meant to
keep the last charge state.
Regards,
Michael
Am 16.01.21 um 14:52 schrieb Steve Davies:
> Hi Michael,
>
> On Sat, 16 Jan 2021 at 14:53, Michael Balzer <dexter at expeedo.de
> <mailto:dexter at expeedo.de>> wrote:
>
> To avoid the "idling" alert, don't set the awake state during
> charges. "Awake" represents the vehicle being switched on, not
> automatic activity.
>
>
> Help me understand "v.e.awake" vs "v.e.on"?
>
> I'm currently setting "awake" when I'm getting data from the OBD-II,
> ie the car is responsive ("awake"). I'm not sure how to tell if that
> happened by user action or automatically.
>
> I set "v.e.on" when the car is actually ready to drive (at the moment
> I detect that the power steering ECU is responsive since that only
> comes on when the car is "READY").
>
> If "awake" is supposed to mean ready to drive, what does "on" mean?
>
>
> Also, if distinguishable, you should only set "charging12v" in
> that case, as "charging" is meant for the main battery.
>
> As for the charge.state event - it should generally have a value like
> idle, charging etc. In this case though the value was empty - this is
> because OVMS rebooted at 01:25UTC and had not been able to talk to the
> car since then since the car was asleep.
>
> Here all the relevant events and metric changes:
>
> 2021-01-16T01:25:06+0000 ovms/CAA5060/metric/v/c/state
> # OVMS rebooted. v.c.state initialised empty.
> # and since we can't
> talk to the car we never know better
> 2021-01-16T09:25:24+0000 ovms/CAA5060/event vehicle.charge.state
> # Vehicle woke, for some reason mqtt code decided to send the
> charge.state at this point
> 2021-01-16T09:25:24+0000 ovms/CAA5060/event vehicle.charge.12v.start
> # 12v charging detected by current flow into 12v battery.
> 2021-01-16T09:26:42+0000 ovms/CAA5060/metric/v/c/state idle
> # Since car is now alive we get the "idle" charge state. BUT
> WHERE IS THE charge.state EVENT?
> 2021-01-16T10:25:33+0000 ovms/CAA5060/event vehicle.charge.12v.stop
> # Car decides to stop charging the 12v.
>
> I'm not clear why another "vehicle.charge.state" event was not sent
> with "idle".
>
> I did not implement GetNotifyChargeStateDelay in my vehicle module -
> so I wonder if it ended up suppressed.
>
> Alternatively - at 09:26:42 the module was sending all metrics to
> MQTT. This implies that it had lost and re-established MQTT session.
> I wonder if that interfered with the MetricChanged logic.
>
> Unfortunately my log doesn't have metrics trace enabled so I can't see
> exactly.
>
> Steve
>
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210116/9083eedf/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210116/9083eedf/attachment-0001.sig>
More information about the OvmsDev
mailing list