[Ovmsdev] "Vehicle is idling": A new "Feature"?
Michael Balzer
dexter at expeedo.de
Sun Feb 9 17:50:06 HKT 2020
Yes, sounds good to me.
Regards,
Michael
Am 09.02.20 um 09:53 schrieb Mark Webb-Johnson:
> The Tesla Roadster transmits it’s sleep/awake status:
>
> ID 0x100 B1=0x96
>
> B4=doors3
>
> bit1 = awake/asleep (awake=1 / asleep=0)
>
>
> In the v2 code, we simply sent this as doors3 value (in the ‘D’ protocol message).
>
> The v3 code has this as:
>
> case 0x96: // Doors / Charging yes/no
> {
> m_awake = d[3] & 0x01;
>
>
> Which was wrong (bit #0). I fixed it in recent commit 39cdb7e19e5a3b88ab7217a9adb0cb6008278ab1 to 'm_awake = d[3] & 0x02’ (bit #1), and that now correctly
> tracks the vehicle state. This was to address bug 'Tesla Roadster: Vehicle AWAKE metric not correct #328’.
>
> Over the years, it seems that the meaning of doors3 has changed. It originally just specified bit #1, but now the protocol specifies:
>
> *
>
> Door state #3
>
> bit0 = Car awake (turned on=1 / off=0)
> bit1 = Cooling pump (on=1/off=0)
> bit6 = 1=Logged into motor controller
> bit7 = 1=Motor controller in configuration mode
>
> The Tesla Roadster code in v2 never adhered to that, and just set doors3 to whatever it saw on the bus. However, I’ve never seen values other than 0x00 or
> 0x02 on that byte. Certainly, no known value for bit#0 (car turned on). I guess this is where the confusion from the conversion v2 -> v3 came from (the
> protocol document saying ‘awake’ in bit#0, vs cooling pump in bit #1). Tesla Roadster users know the cooling pump as ‘awake/sleep’.
>
> So, where are we now? A general car can be defined as at least these states:
>
> 1. Ignition off, asleep, consuming as little power as possible
> 2. Ignition off, awake, with some systems using power
> 3. Ignition on to the first stop (just some systems on, but car not started)
> 4. Ignition on all the way (engine running or starting)
> 5. Ignition past on all the way (turning the engine starter motor)
>
>
> We can ignore #5 for electric cars.
>
> In v3, we have these metrics:
>
> * v.e.awake
> * v.e.on
> * v.e.charging12v
>
>
> I assumed that v.e.awake corresponds to state #2, and v.e.on to states #3 and/or #4.
>
> The v.e.charging12v doesn’t really work for the Roadster. The cooling pump is not related to the little 12v battery charging system.
>
> I guess I could add a standard metric ‘v.e.aux12v’ to indicate the auxiliary 12v system is on (and then set v.e.awake and v.e.ok corresponding to the ignition
> switch). Is that acceptable?
>
> Regards, Mark.
>
>> On 8 Feb 2020, at 5:46 AM, Greg D. <gregd2350 at gmail.com <mailto:gregd2350 at gmail.com>> wrote:
>>
>> Hi Michael, Mark,
>>
>> Ok, very interesting that this is an old feature. I only just started seeing the message very recently. What changed?
>>
>> As to "Awake" vs "On" vs "Ignited", they are definitely different. I am seeing the correct state reflected in v.e.awake and v.e.on. Simply opening the car
>> door when the car is asleep will wake it up (v.e.awake turns to yes), and inserting the key and moving it to the "Accessory" position (first notch) moves the
>> state to "On" (both metrics are "yes"). Note that the car is not On (drivable) until the key is moved one notch farther; I'm presuming that's "Ignited" in
>> your terminology.
>>
>> But something has changed. I have an event script tied to vehicle.on which activates ext12v power to enable a HUD or similar (*). Simply awakening the car
>> triggers the script, a behavior I believe is new, and incorrect. The script should get activated only when the key is moved to Accessory (your "On" state).
>> When the car goes directly back to sleep after a few minutes, the vehicle.off script correctly does not trigger. Turning the car to Accessory, then Off
>> (removing the key), does correctly trigger the vehicle.off script, even though the car is still Awake at the time.
>>
>> So what I think is happening with the "Vehicle is idling" message is that it's a side effect of some logic change to what "on" is, that it's being sensed and
>> triggered by "Awake" instead of "On". The car is definitely Awake during charging, but it is not On. And not being On, the Idle message shouldn't be
>> triggered, nor should my HUD be turned on.
>>
>> What changed?
>>
>> Greg
>>
>> (*) Actually, the script does a bit more, to work around the CAN3 bus hangs:
>>
>> power ext12v off
>> obdii ecu stop
>> obdii ecu start can3
>> power ext12v on
>>
>>
>>
>> Michael Balzer wrote:
>>> Greg, Mark,
>>>
>>> that's actually a very old feature originating from V2. It's meant to alert about a car left turned on, which is both a potential security issue (key is
>>> plugged) and a potential fire/explosion threat on vehicles that may overcharge the 12V battery from the DC/DC converter. It's also main battery drainage.
>>>
>>> This also needs to trigger during charging, but of course not if the vehicle wakes itself for some internal checks or OTA updates / whatever.
>>>
>>> This was/is using the definition of "awake" as "turned on", and "on" as "ignited". It seems all cars except the roadster follow this scheme now, so maybe we
>>> should separate the "maintenance awake" state?
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> Am 07.02.20 um 08:43 schrieb Mark Webb-Johnson:
>>>> Greg,
>>>>
>>>> That would be the system thinking the vehicle is asleep, but speed > 0.
>>>>
>>>> I did fix the roadster awake/sleep flag (which was not being set correctly before), so most likely this is something new.
>>>>
>>>> The logic is in VehicleTicker1() in vehicle.cpp. It is:
>>>>
>>>> // Idle alert:
>>>> if (!StdMetrics.ms_v_env_awake->AsBool() || StdMetrics.ms_v_pos_speed->AsFloat() > 0)
>>>> {
>>>> m_idle_ticker = 15 * 60; // first alert after 15 minutes
>>>> }
>>>> else if (m_idle_ticker > 0 && --m_idle_ticker == 0)
>>>> {
>>>> NotifyVehicleIdling();
>>>> m_idle_ticker = 60 * 60; // successive alerts every 60 minutes
>>>> }
>>>>
>>>>
>>>> So, that resets the fifteen minute timer whenever the vehicle is either asleep OR speed>0 (driving). Otherwise the timer counts down, and after 15 minutes
>>>> the alert is raised (and every 60 minutes thereafter until either the vehicle goes to sleep or speed>0).
>>>>
>>>> For roadster, that work work. The car can ‘awake’ itself for charging,etc.
>>>>
>>>> I am not really sure why we are using ms_v_env_awake in the first place here. Why do we care if the vehicle is awake or not? Surely we should be looking
>>>> at ms_v_env_on (ie; vehicle switched on)? But for JDEMO users that would cause a problem (as for they have to leave the vehicle ignition on while charging).
>>>>
>>>> Maybe simplest to disable this alert for Roadster, unless someone else has any better ideas. In any case, we need to think about using ms_v_env_awake vs
>>>> ms_v_env_on.
>>>>
>>>> Regards, Mark.
>>>>
>>>>> On 7 Feb 2020, at 2:22 AM, Greg D. <gregd2350 at gmail.com <mailto:gregd2350 at gmail.com>> wrote:
>>>>>
>>>>> Hi folks,
>>>>>
>>>>> I'm starting to get an alert "Vehicle is idling / stopped turned on"
>>>>> when my Roadster is charging. Seems to occur every hour.
>>>>>
>>>>> Is this something new with OVMSv3, or did something change / break on my
>>>>> car?
>>>>>
>>>>> Greg
>>>>>
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> 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/20200209/d250b217/attachment.htm>
More information about the OvmsDev
mailing list