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

Mark Webb-Johnson mark at webb-johnson.net
Mon Jan 18 10:26:41 HKT 2021


Looking back at the old thread "Vehicle is idling": A new “Feature”, I don’t think we ever properly finished this. We did add the aux12v standard metric, and we have the charging12v one. But we never renames ‘awake’ to ‘accessory’ to avoid the confusion.

The alternative suggested would be one single enumerated metric to reflect all the possible states. Something like:

off
deepsleep
lightsleep
awake
accessory
starting
on

I’m ok either way. But really depends on how the other vehicle types fit into the model.

Regards, Mark.

> On 16 Jan 2021, at 10:20 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> Signed PGP part
> 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 <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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/20210118/48edf853/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210118/48edf853/attachment-0001.sig>


More information about the OvmsDev mailing list