On 16 Jan 2021, at 10:20 PM, Michael Balzer <dexter@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@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@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