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

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 <mailto: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

It used to be possible to manually set tire pressure with: metrics set v.tp.fl.p 210.29 metrics set v.tp.fr.p 210.29 metrics set v.tp.rl.p 210.29 metrics set v.tp.rr.p 210.29 but after upgrading to the latest persistent metrics code I see these are all gone. I looked at the tpms command but it seems to be designed to track different sets of tpms sensor id numbers. Is it possible to set these from the command line? Are tpms tire pressures (and temperatures) still persistent across warm reboots? Is my problem that these are stored in vectors now and there is not yet a way to manipulate them from the command line? Craig

Stephen Casner wrote:

On Wed, 20 Jan 2021, Greg D. wrote:

...

"On" is the keyswitch position 2, where the car can be driven (contactor is in). Pushing the keyswitch to the momentary position 3 (ICE "Start") toggles the Performance driving mode setting. A handy place to put that, I guess. It is necessary to depress the brake and momentarily turn to position 3 to initiate the start-up sequence and put the car into driving mode. I was specifically referring to the Roadster (2.x if that matters) for this use of switch position 3. I expect that's another Roadster-unique behavior. The alternative suggested would be one single enumerated metric to reflect all the possible states. Something like:

* off * deepsleep * lightsleep * awake * accessory * starting * on The condition that occurs when opening the door could be deepsleep or lightsleep rather than awake. Is there an overall description of the various states? What describes the difference between the different sleeps and awake? -- Steve

---

OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

Stephen Casner wrote:

On Wed, 20 Jan 2021, Greg D. wrote:

...

Stephen Casner wrote:

...

It is necessary to depress the brake and momentarily turn to position 3 to initiate the start-up sequence and put the car into driving mode. I was specifically referring to the Roadster (2.x if that matters) for this use of switch position 3. I expect that's another Roadster-unique behavior.

I was also referring to the Roadster. My point was that postition 3 is not just for toggling to Performance mode. Interesting.

I didn't know the 1.5's behaved that way. On a 2.x, simply turning the key to position 2 and pushing the "D" button gets you going. Foot on brake likely required, too. Never tried without doing that, for safety reasons. I guess they figured the "start" action was kind of silly in an EV, and repurposed the 3rd switch position for something else. But to the question of vehicle states, is a single metric going to be sufficient, or do we need separate status metrics for the various functions as it is today? I'm not sure. The more of these exceptions we run into, the more the separate metrics make sense to me. Greg

Hi Steve, Chimes and such occur at 2, along with the brake vacuum pump. But, to show you how much I pay attention to these things, it turns out that there is actually a key position between 1 and 2. The first notch ("Accessory") turns on the dash lights, radio, and such, then there's a very short throw to another notch that doesn't have any obvious function, then a bigger throw to the "On" position. Then the spring-return to position 3, aka Start / Performance. The user guide is silent on that intermediate 1-B position, and unless we can determine what it does, it's probably safe to ignore. The reverse direction brings out another Roadster quirk, where going from Accessory to Off doesn't do anything until you actually remove the key. The dash stays active, radio on, etc. until the key is removed. The user guide does describe this behavior. So, what state is the car in, when the key is at Off, but the dash is still active? Greg Stephen Casner wrote:

On Thu, 21 Jan 2021, Greg D. wrote:

...

I didn't know the 1.5's behaved that way. On a 2.x, simply turning the key to position 2 and pushing the "D" button gets you going. Do the startup sounds occur at the first step or the second?

...

But to the question of vehicle states, is a single metric going to be sufficient, or do we need separate status metrics for the various functions as it is today? I'm not sure. The more of these exceptions we run into, the more the separate metrics make sense to me. If the states for all vehicles are strictly ordered, then it should be possible to define a mapping to a single metric so long as the number of values is sufficient.

-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev