[Ovmsdev] Happy discovered: I3 seems to manage 12v battery charge by itself

[Steve Davies]

Hi Michael,

On Sat, 16 Jan 2021 at 14:53, Michael Balzer <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210116/89bb0346/attachment-0002.htm>