<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Mark,<br>
<br>
Ok, getting closer. I understand that this is potentially a
wide-ranging thing to clean up, and we do have higher priority
things to address, but I do want to set the right direction.<br>
<br>
------------------<br>
TL; DR summary: (Should have this in my earlier email)<br>
<br>
v.e.awake<br>
- No means car is in a power saving state; busses are inactive,
dash lights and interfaces are off. Any metrics are stale.<br>
- Yes means the busses are active, and metrics derived from them
are valid. Car is awake, but user interfaces (dash buttons, lights,
radio, etc.) are not active. The transition between No and Yes is
controlled by the car, indirectly from some user action (e.g.
opening a door) or by time (going to sleep after no activity).
Success of the OVMS application's "Wake up car" command should be
reflected in this metric when the car wakes up.<br>
<br>
v.e.accessory<br>
- Yes means that the car dash user interfaces, radio, etc. are
active, but the car is not drivable. Historically this corresponds
to the key being turned to the first (Accessory) position.<br>
<br>
v.e.on<br>
- Yes means that the car is fully on (contactor engaged), and
drivable (can be put into drive or reverse). Historically this
corresponds to the key being turned to the second position.<br>
<br>
-------------------<br>
<br>
<br>
To clarify, when I was referring to a car that kept the 12v
accessory plug on, it wasn't the Roadster. It was some old thing I
had, I think in college, or maybe it was a friend's or a family car
from earlier. Back then, the outlet was for the cigarette lighter.
Gotta have those things powered, just in case you need a smoke...<br>
<br>
And, no, I guess I wasn't clear. Roadster owners define Awake as
when the car first "wakes up" after being asleep, for example when
you open a door. As you earlier noted, this is when the APS turns
on. The first key position is still Accessory, both in common usage
and in the Tesla Roadster user manual, page 40. The 12v accessory
outlet power is related to being awake, not the key position, but
that is effectively accidental in terms of the metrics. The
"original" code (going back some months) was in my definition
correct, in that the Awake metric was set when you opened the door
and the car woke up. The problem I reported was that it was
triggering vehicle.on events. The fix to make Awake not be set when
the car woke up kind of made things better, but also more
inconsistent. A new v.e.accessory metric should be associated with
the key, not the APS. Today that Accessory key position on the
Roadster triggers the On metric to be set, which is also wrong. If
you want to rename On to Accessory, that might work. It should
trigger events under /store/events/vehicle.accessory then.<br>
<br>
So, for what the code does today in setting v.e.awake, renaming that
target to v.e.accessory would be correct. Or equivalently, create
the v.e.accessory metric and aim the code that sees the key go to
position 1 (or whatever it is on other cars) to that new metric.<br>
<br>
Renaming v.e.aux12v to Awake is ok, I guess. At least, that aligns
with the Roadster's behavior. I would caution that the traditional
use of the 12v outlet being tied to the Accessory key position might
complicate any existing code that was changed when that metric was
created. We really need to ignore that the Roadster turns on the
12v outlet when it wakes up. That's an accident of the car's
design, and I don't think it's important. Awake really needs to be
tied to the change resulting from the Wake up the car command. Send
the command, car wakes up, see the metric change. Open a door, car
wakes up, metric changes. Let the car sit, car goes to sleep,
metric turns false. Metric is false, other metrics are stale. That
should be the binding and scope of the Awake metric. <br>
<br>
I haven't updated my build environment since finishing the obd2ecu
code, so it will take some effort (and time) to help make the
changes. Let me know if this is worth my time to do so.<br>
<br>
Hope this helps,<br>
<br>
Greg<br>
<br>
<br>
<div class="moz-cite-prefix">Mark Webb-Johnson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:9B04E9F0-4295-4AA5-804D-B4FA6830CC3D@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class=""><br class="">
</div>
Re-reading this, perhaps I was not clear… I think the proposal is:<br
class="">
<div><br class="">
</div>
<div>
<ul class="MailOutline">
<li class="">Rename ‘v.e.awake’ to be ‘v.e.accessory’, and
change all code in our firmware to reflect that (both
definition and uses).</li>
<li class="">Rename ‘v.e.aux12v’ to be ‘v.e.awake’, and
change <span style="caret-color: rgb(0, 0, 0); color: rgb(0,
0, 0);" class="">all code in our firmware to reflect that
(both definition and uses).</span></li>
<li class=""><font class="" color="#000000">The implementation
of the ‘awake’ command is still vehicle dependent.</font></li>
</ul>
</div>
<div><br class="">
</div>
<div>Is that correct? If so, I have no objections, and really
don’t mind either way.</div>
<div><br class="">
</div>
<div>Regards, Mark.</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 18 Feb 2020, at 9:34 AM, Mark Webb-Johnson
<<a href="mailto:mark@webb-johnson.net" class=""
moz-do-not-send="true">mark@webb-johnson.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
line-break: after-white-space;" class=""><br class="">
<div class="">Greg,</div>
<div class=""><br class="">
</div>
<div class="">Your three points understanding seems
correct. However, I am not aware of any roadsters where
the 12v accessory port is always on - it should not be.</div>
<div class=""><br class="">
</div>
<div class="">I would disagree that most roadster owners
define ‘awake’ as ‘accessory’ (the first key position).
The power to 12v accessories in roadster is not related
to the key at all.</div>
<div class=""><br class="">
</div>
<div class="">I also agree that the v.e.awake metric, as
used by other cars, would probably be better named
v.e.accessory - as that seems to be what it is tracking
(the accessory key switch). However, I’m not overly
concerned about it. We have much bigger issues to deal
with. I’m happy either way. It just seemed easier to add
a metric for aux12v, and not have to change everything
else.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div class="">On 18 Feb 2020, at 8:43 AM, Greg D. <<a
href="mailto:gregd2350@gmail.com" class=""
moz-do-not-send="true">gregd2350@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""> Hi
Mark,<br class="">
<br class="">
Forgive me, but I'm not quite ready to let this
one go. Please help me untangle some of this in
my mind. <br class="">
<br class="">
The issue comes down to what we want to do with
Awake and On, and how and when the metrics get
updated. So this is not just a car thing, but a
car and phone app thing.<br class="">
<br class="">
<b class="">Foundational concepts.</b><br class="">
<b class="">1. </b>One source of my confusion is
certainly that there are a lot of ways EVs do the
whole "ignition" thing. But I think we can break
the population into two camps. Those with
physical keys, and those without. The key
difference (pardon the pun) is that the state of
physical key cannot be changed without moving the
physical key, i.e. it cannot be changed remotely.
To fake this, I expect, would open up a bunch of
inconsistency issues depending on how the car is
wired, potentially confusing the car itself. That
could be bad. Cars without physical keys might
have similar issues linking back to
unauthenticated access, but I presume that the
OVMSv3 could be considered a proxy once given the
proper credentials. This would be similar to the
Tesla phone app having the ability to control the
car once paired and authenticated with it.<br
class="">
<br class="">
<b class="">2. </b>The Roadster has a physical
key. In common usage (what Roadster owners as a
community call them), the car is in one of 4
states. Asleep, awake, Accessory, and On. Asleep
and awake are controlled by the car, Accessory and
On by the driver via the physical key. The car,
when Awake, is running the little pump, and is
generally conscious from a CAN bus perspective,
but the dashboard lights, cabin fan, radio, and
such are unpowered. Similar to a traditional ICE,
the Accessory key position turns on the dash
lights, fan, heat, seat warmers, radio, etc., and
the car can be driven when the key is moved to
On. Unlike most traditional ICEs, the Roadster's
12v accessory port is powered when the car becomes
Awake, while most cars only power it when in
Accessory or On. I say "most" because I vaguely
recall a car some years ago where the 12v port was
always powered. I forget what the car was, but
the point is that it's perhaps rare, but not
impossible. <br class="">
<br class="">
<b class="">3. </b>Metrics. The car needs to be
conscious in order for its state to be read and
understood by the OVMSv3 module. In common
Roadster terms, that means the car has to be
awake, but not necessarily On. Some metrics, TPMS
for example, don't go live until the car is
driven, but those are exceptions. The OVMS phone
app can display the metrics, but as expected, it
needs the car to be awake to do so. So, there is
a command that the OVMS app can send to the OVMS
module to "Wake up the car". This takes the car
out of its slumber, turning on the internal power
systems that run the various components, including
the little pump on the Roadster. Metrics go live,
captured by the OVMSv3 module, sent to the server,
and on to the phone app for display. It does not
(can not) move the physical key to Accessory, so
cannot turn on the dash lights, fan, radio, etc.
<br class="">
<br class="">
I believe all of the 1, 2, & 3 above is
correct. Yes?<br class="">
<br class="">
<b class="">What I don't know</b><br class="">
I do not have OVMS experience with any EV other
than the Roadster. We (some historic "we") have
defined OVMS "Awake" as what is commonly called
"Accessory" on traditional cars. It's the first
key position. This is where my brain says "Huh?",
and I need some help. When you call up the App
and issue its "wake up the car" command, do we
expect that an EV will generally turn on the dash
lights, cabin fan, and radio? <i class="">Do any
of the EVs respond in this way?</i> If not,
then we have not correctly defined what Awake is.<br
class="">
<br class="">
<b class="">Proposal</b><br class="">
I should probably stop this missive here, and
await clarification on what I don't know, but will
discuss where I think it will go next. The
following is a draft... <br class="">
<br class="">
Assuming that "Wake up the car" does not turn on
the dash, fan, and radio in most EVs, we need to
change some definitions. If so, I think the
Roadster's four commonly accepted definitions are,
in fact, the correct ones. The Wake up the car
command should set the Awake metric and put the
car in a state where live metrics can be
obtained. Turning the key to Accessory (or the
equivalent with a non-key vehicle where the dash
comes on) should set an Accessory metric (new),
instead of On, and turning the key to On (or the
equivalent where the car can be driven) should set
the On metric. <br class="">
<br class="">
The charging of the 12v battery appears to be
important, but will depend on the car's
architecture. It does not necessarily map to one
of the 4 states. My Roadster's 12v battery, for
example, appears to be float-charged continuously
(I've measured it). Using the existing high and
low voltage alerts may be more important than
simply knowing the battery is being charged, but I
will leave that for owners of those cars to
determine.<br class="">
<br class="">
If a car doesn't have a state where the dash,
radio, etc. are on, but the car is not drivable,
then the Accessory state may not be used
independently. For those cars, Accessory and On
would be linked.<br class="">
<br class="">
If for some reason the Wake up the car action does
turn on the dash lights, fan, radio, etc., then
those cars should link Awake and Accessory. Going
further, if Wake up the car actually allows it to
be driven (yikes!), then all three metrics (awake,
accessory, on) should be set.<br class="">
<br class="">
So, thoughts? The bottom line is that we
currently do not have a consistent set of
definitions and common usage, particularly with
the Roadster which oddly was one of (if not the)
first cars supported.<br class="">
<br class="">
Thanks,<br class="">
<br class="">
Greg<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Mark Webb-Johnson
wrote:<br class="">
</div>
<blockquote type="cite"
cite="mid:113C975A-517A-400F-9C33-C8834CECD6C5@webb-johnson.net"
class="">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8" class="">
Greg,
<div class=""><br class="">
</div>
<div class="">The problem is that your and my
understanding of what ‘awake’ means is not the
same as the OVMS definition of v.e.awake.
Looking at <a
href="https://docs.openvehicles.com/en/latest/userguide/metrics.html"
class="" moz-do-not-send="true">https://docs.openvehicles.com/en/latest/userguide/metrics.html</a> we
can see:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">v.e.awake<br class="">
yes = Vehicle/bus awake (switched on)<br
class="">
ie; my state #3 (Ignition on to the first
stop)<br class="">
<br class="">
</li>
<li class="">v.e.on<br class="">
yes = “Ignition” state (drivable)<br
class="">
ie; my state #4 (Ignition on all the way)<br
class="">
<br class="">
</li>
<li class="">and the new v.e.aux12v<br
class="">
yes = Auxiliary 12v system is on</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">While we can say that ‘awake’
means the coolant pump is running, and a side
effect is the 12v auxiliary power in the cabin
is on; in reality it is the other way round -
this thing we think of as ‘awake’ is really
the state of the auxiliary 12v power which the
coolant pump runs off. Note that neither
‘awake’ not ‘aux12v’ metrics are shown on the
Apps - they are purely an internal
representation.</div>
<div class=""><br class="">
</div>
<div class="">The only thing that matters to the
App (ie; user) is the temperatures. Those
sensors seem powered by the same auxiliary 12v
system, so when that is off those go stale.
That seems currently to be implemented
correctly (in latest edge firmware). If the
car is sleeping (aux12v is off), the
temperature sensors are not updated, go stale,
and appear as gray in the App. If you tap on
‘wakeup’ in the App, the aux12v comes on,
temperature sensors get power, and the App
shows the temperatures in real time (white,
not gray) immediately.</div>
<div class=""><br class="">
</div>
<div class="">The choices we had were:</div>
<div class=""><br class="">
</div>
<div class="">
<ol class="MailOutline">
<li class="">Change the definition of
‘v.e.awake’ (which has been there for
years) to mean aux12v power, introduce a
new sensor for state #3 (to mean ignition
on, but car not started), and then change
all the other vehicle modules +
notification code to conform to this.<br
class="">
<br class="">
or<br class="">
<br class="">
</li>
<li class="">Add a new metric ‘v.e.aux12v’
to properly track the 12v auxiliary power.</li>
</ol>
</div>
<div class=""><br class="">
</div>
<div class="">We chose #2 as it just seems
easier and better tracks what is actually
happening in the car. The only issue in the
Tesla Roadster is we don’t know how to tell
the difference between states #3 and #4, so we
just set v.e.awake and v.e.on at the same time
now (to track the ignition on). Perhaps we can
go looking to try to find that on the CAN bus,
but I don’t think of it as that important
(also difficult for me because I don’t have
the car any more). If somebody can get three
CRTD can bus dumps from a roadster for a) with
the ignition off, b) with ignition to the
first stop, and c) with ignition fully on, I
can look at it to see what I can find.</div>
<div class=""><br class="">
</div>
<div class="">Bottom line is that the states for
Roadster are now:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">Car asleep. v.e.awake=off,
v.e.on=off, v.e.aux12v=off.</li>
<li class="">The charge port or door handle
is opened (or vehicle woken up from the
app). v.e.awake=off, v.e.on=off,
v.e.aux12v=on.</li>
<li class="">The ignition is turned on.
v.e.awake=on, v.e.on=on, v.e.aux12v=on.</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">I think that will also work for
the Tesla Model S, X and 3 (which have the
same power states). Note that modern Tesla
cars don’t have ignition switches, and don’t
have any difference between states #3 and #4.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 10 Feb 2020, at 2:08 AM,
Greg D. <<a
href="mailto:gregd2350@gmail.com"
class="" moz-do-not-send="true">gregd2350@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8"
class="">
<div text="#000000" bgcolor="#FFFFFF"
class=""> Hi Mark, Michael,<br
class="">
<br class="">
Mmmm, not sure this is right. The
states you outline are exactly what I
would expect, and what I am seeing
with my car: Awake corresponds to the
car running the little pump, lighting
the charge ring if the door is open,
etc. The On state properly
corresponds to the turning of the
key. All that is fine as is. That it
also powers the 12v Accessory port on
the dash is a bit odd, but I think we
can ignore that for these purposes.
It's just one of this magical little
car's quirks. <br class="">
<br class="">
So, all was fine. I can't test the
Idling message without going for a
long drive, but the triggering of
vehicle.on events does work (follows
the key), so I guess that's progress.
Cosmetically, we have addressed the
issues, but the collateral damage? I
did the update, and the change sort of
breaks the app Wake up the car.
Waking it doesn't change the state of
Awake, though the car does wake up (in
the old definition) as before. I
don't think we're really at root
cause, so the fixes are unraveling
other things.<br class="">
<br class="">
What I was thinking explains both of
my issues - the Idling message, and
the triggering of vehicle.on events -
is that both of those appear to be
qualified by Awake instead of On.
That, I think, is the root cause.
That the vehicle.on event follows the
key (as it should) is because we've
changed the definition on Awake, not
the use of On as the trigger for
vehicle.on. I am using vehicle.on,
not vehicle.awake, for a reason.
Vehicle.awake should follow the little
pump and its friends, not the key.
Vehicle.on and vehicle.off should
follow the key. vehicle.off is (and
has been) fine. Vehicle.on isn't tied
to On as it should.<br class="">
<br class="">
Having the Aux12v metric is fine by
itself, I suppose, and may be useful
for other cars that have their own
quirks. But the common definition of
Awake for the Roadster was properly
implemented before this change. That
the Roadster powers the Aux12v outlet
when the car is Awake instead of
following the key to On isn't relevant
to the definition of Awake.<br
class="">
<br class="">
Greg<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Mark
Webb-Johnson wrote:<br class="">
</div>
<blockquote type="cite"
cite="mid:02E4D449-32CA-418E-A8A4-BCB01B4CBBF6@webb-johnson.net"
class="">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8"
class="">
OK. This is in 3.2.010-6-gac7c26d.
<div class=""><br class="">
</div>
<div class="">@Greg can you try this
one (OTA) and let me know if you
see any more of these alerts.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.<br
class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 9 Feb 2020,
at 5:50 PM, Michael Balzer
<<a
href="mailto:dexter@expeedo.de"
class=""
moz-do-not-send="true">dexter@expeedo.de</a>>
wrote:</div>
<br
class="Apple-interchange-newline">
<div class="">
<meta
http-equiv="Content-Type"
content="text/html;
charset=UTF-8" class="">
<div class=""> Yes, sounds
good to me.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div
class="moz-cite-prefix">Am
09.02.20 um 09:53
schrieb Mark
Webb-Johnson:<br
class="">
</div>
<blockquote type="cite"
cite="mid:0C5F9CD4-AC22-4373-96EC-6C64787DE17F@webb-johnson.net"
class="">
<meta
http-equiv="Content-Type"
content="text/html;
charset=UTF-8"
class="">
<div class="">The Tesla
Roadster transmits
it’s sleep/awake
status:</div>
<div class=""><br
class="">
</div>
<blockquote
style="margin: 0 0 0
40px; border: none;
padding: 0px;"
class="">
<div class="">ID 0x100
B1=0x96</div>
</blockquote>
<blockquote
style="margin: 0 0 0
40px; border: none;
padding: 0px;"
class="">
<blockquote
style="margin: 0 0 0
40px; border: none;
padding: 0px;"
class="">
<div class="">B4=doors3</div>
</blockquote>
</blockquote>
<blockquote
style="margin: 0 0 0
40px; border: none;
padding: 0px;"
class="">
<blockquote
style="margin: 0 0 0
40px; border: none;
padding: 0px;"
class="">
<blockquote
style="margin: 0 0
0 40px; border:
none; padding:
0px;" class="">
<div class="">bit1
= awake/asleep
(awake=1 /
asleep=0)</div>
</blockquote>
</blockquote>
</blockquote>
<div class=""><br
class="">
</div>
<div class="">In the v2
code, we simply sent
this as doors3 value
(in the ‘D’ protocol
message).</div>
<div class=""><br
class="">
</div>
<div class="">The v3
code has this as:</div>
<div class=""><br
class="">
</div>
<blockquote
style="margin: 0 0 0
40px; border: none;
padding: 0px;"
class="">
<div class="">
<div class="">case
0x96: // Doors /
Charging yes/no</div>
<div class=""> {</div>
<div class="">
m_awake = d[3]
& 0x01;</div>
</div>
</blockquote>
<div class="">
<div class=""><br
class="">
</div>
<div class="">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’.</div>
<div class=""><br
class="">
</div>
<div class="">Over the
years, it seems that
the meaning of
doors3 has changed.
It originally just
specified bit #1,
but now the protocol
specifies:</div>
<div class=""><br
class="">
</div>
</div>
<blockquote
style="margin: 0 0 0
40px; border: none;
padding: 0px;"
class="">
<div class="">
<div class="">
<div class="page"
title="Page 11">
<div
class="layoutArea">
<div
class="column">
<ul
style="list-style-type:
none" class="">
<li class="">
<p class=""><span
style="color:
rgb(0, 0, 10);
font-style:
normal;
font-size:
14px;"
class=""><font
class=""
face="Andale
Mono">Door
state #3 </font></span></p>
<p class=""><span
style="color:
rgb(0, 0, 10);
font-style:
normal;
font-size:
14px;"
class=""><font
class=""
face="Andale
Mono">bit0 =
Car awake
(turned on=1 /
off=0)<br
class="">
bit1 = Cooling
pump
(on=1/off=0)<br
class="">
bit6 =
1=Logged into
motor
controller<br
class="">
bit7 = 1=Motor
controller in
configuration
mode</font></span><span
style="font-size: 12.000000pt; font-family: 'ArialMT'; color:
rgb(0.000000%,
0.000000%,
3.921000%)"
class=""> </span></p>
</li>
</ul>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class="">
<div class="">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’.</div>
<div class=""><br
class="">
</div>
<div class="">So,
where are we now? A
general car can be
defined as at least
these states:</div>
<div class=""><br
class="">
</div>
<div class="">
<ol
class="MailOutline">
<li class="">Ignition
off, asleep,
consuming as
little power as
possible</li>
<li class="">Ignition
off, awake, with
some systems
using power</li>
<li class="">Ignition
on to the first
stop (just some
systems on, but
car not started)</li>
<li class="">Ignition
on all the way
(engine running
or starting)</li>
<li class="">Ignition
past on all the
way (turning the
engine starter
motor)</li>
</ol>
</div>
<div class=""><br
class="">
</div>
<div class="">We can
ignore #5 for
electric cars.</div>
<div class=""><br
class="">
</div>
<div class="">In v3,
we have these
metrics:</div>
<div class=""><br
class="">
</div>
<div class="">
<ul
class="MailOutline">
<li class="">v.e.awake</li>
<li class="">v.e.on</li>
<li class="">v.e.charging12v</li>
</ul>
</div>
<div class=""><br
class="">
</div>
<div class="">I
assumed that
v.e.awake
corresponds to state
#2, and v.e.on to
states #3 and/or #4.</div>
<div class=""><br
class="">
</div>
<div class="">The
v.e.charging12v
doesn’t really work
for the Roadster.
The cooling pump is
not related to the
little 12v battery
charging system.</div>
<div class=""><br
class="">
</div>
<div class="">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?</div>
<div class=""><br
class="">
</div>
<div class="">Regards,
Mark.</div>
<div class=""><br
class="">
</div>
<div class="">
<blockquote
type="cite"
class="">
<div class="">On 8
Feb 2020, at
5:46 AM, Greg D.
<<a
href="mailto:gregd2350@gmail.com"
class=""
moz-do-not-send="true">gregd2350@gmail.com</a>>
wrote:</div>
<br
class="Apple-interchange-newline">
<div class="">
<meta
http-equiv="Content-Type"
content="text/html; charset=UTF-8" class="">
<div
text="#000000"
bgcolor="#FFFFFF" class=""> Hi Michael, Mark,<br class="">
<br class="">
Ok, very
interesting
that this is
an old
feature. I
only just
started seeing
the message
very
recently.
What changed?<br
class="">
<br class="">
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.
<br class="">
<br class="">
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.<br
class="">
<br class="">
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.<br
class="">
<br class="">
What changed?<br
class="">
<br class="">
Greg<br
class="">
<br class="">
(*) Actually,
the script
does a bit
more, to work
around the
CAN3 bus
hangs:<br
class="">
<meta
http-equiv="content-type"
content="text/html; charset=UTF-8" class="">
<br class="">
<tt class="">power
ext12v off</tt><tt
class=""><br
class="">
</tt><tt
class="">obdii
ecu stop</tt><tt
class=""><br
class="">
</tt><tt
class="">obdii
ecu start can3</tt><tt
class=""><br
class="">
</tt><tt
class="">power
ext12v on</tt><br
class="">
<br class="">
<br class="">
<br class="">
<div
class="moz-cite-prefix">Michael
Balzer wrote:<br
class="">
</div>
<blockquote
type="cite"
cite="mid:39ff043f-34e9-4f28-29cb-4d24ce43a65c@expeedo.de"
class="">
<meta
http-equiv="Content-Type"
content="text/html; charset=UTF-8" class="">
<div
class="moz-cite-prefix">Greg,
Mark,<br
class="">
<br class="">
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.<br
class="">
<br class="">
This also
needs to
trigger during
charging, but
of course not
if the vehicle
wakes itself
for some
internal
checks or OTA
updates /
whatever.<br
class="">
<br class="">
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?<br
class="">
<br class="">
Regards,<br
class="">
Michael<br
class="">
<br class="">
<br class="">
Am 07.02.20 um
08:43 schrieb
Mark
Webb-Johnson:<br
class="">
</div>
<blockquote
type="cite"
cite="mid:2E9FB03E-E1F9-4471-85DC-3530F197795B@webb-johnson.net"
class="">
<meta
http-equiv="Content-Type"
content="text/html; charset=UTF-8" class="">
Greg,
<div class=""><br
class="">
</div>
<div class="">That
would be the
system
thinking the
vehicle is
asleep, but
speed > 0.</div>
<div class=""><br
class="">
</div>
<div class="">I
did fix the
roadster
awake/sleep
flag (which
was not being
set correctly
before), so
most likely
this is
something new.</div>
<div class=""><br
class="">
</div>
<div class="">The
logic is
in VehicleTicker1()
in
vehicle.cpp.
It is:</div>
<div class=""><br
class="">
</div>
<blockquote
style="margin:
0 0 0 40px;
border: none;
padding: 0px;"
class="">
<div class="">
<div class=""><font
class=""
face="Andale
Mono"><span
style="font-style:
normal;
font-size:
14px;"
class="">//
Idle alert:</span></font></div>
<div class=""><font
class=""
face="Andale
Mono"><span
style="font-style:
normal;
font-size:
14px;"
class="">if
(!StdMetrics.ms_v_env_awake->AsBool() ||
StdMetrics.ms_v_pos_speed->AsFloat()
> 0)</span></font></div>
<div class=""><font
class=""
face="Andale
Mono"><span
style="font-style:
normal;
font-size:
14px;"
class=""> {</span></font></div>
<div class=""><font
class=""
face="Andale
Mono"><span
style="font-style:
normal;
font-size:
14px;"
class="">
m_idle_ticker
= 15 * 60; //
first alert
after 15
minutes</span></font></div>
<div class=""><font
class=""
face="Andale
Mono"><span
style="font-style:
normal;
font-size:
14px;"
class=""> }</span></font></div>
<div class=""><font
class=""
face="Andale
Mono"><span
style="font-style:
normal;
font-size:
14px;"
class="">else
if
(m_idle_ticker
> 0
&&
--m_idle_ticker
== 0)</span></font></div>
<div class=""><font
class=""
face="Andale
Mono"><span
style="font-style:
normal;
font-size:
14px;"
class=""> {</span></font></div>
<div class=""><font
class=""
face="Andale
Mono"><span
style="font-style:
normal;
font-size:
14px;"
class="">
NotifyVehicleIdling();</span></font></div>
<div class=""><font
class=""
face="Andale
Mono"><span
style="font-style:
normal;
font-size:
14px;"
class="">
m_idle_ticker
= 60 * 60; //
successive
alerts every
60 minutes</span></font></div>
<div class=""><font
class=""
face="Andale
Mono"><span
style="font-style:
normal;
font-size:
14px;"
class=""> }</span></font></div>
</div>
</blockquote>
<div class="">
<div class=""><br
class="">
</div>
<div class="">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).</div>
<div class=""><br
class="">
</div>
<div class="">For
roadster, that
work work. The
car can
‘awake’ itself
for
charging,etc.</div>
<div class=""><br
class="">
</div>
<div class="">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).</div>
<div class=""><br
class="">
</div>
<div class="">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.</div>
<div class=""><br
class="">
</div>
<div class="">Regards,
Mark.</div>
<div class=""><br
class="">
</div>
<div class="">
<blockquote
type="cite"
class="">
<div class="">On
7 Feb 2020, at
2:22 AM, Greg
D. <<a
href="mailto:gregd2350@gmail.com"
class=""
moz-do-not-send="true">gregd2350@gmail.com</a>>
wrote:</div>
<br
class="Apple-interchange-newline">
<div class="">
<div class="">Hi
folks,<br
class="">
<br class="">
I'm starting
to get an
alert "Vehicle
is idling /
stopped turned
on"<br
class="">
when my
Roadster is
charging.
Seems to
occur every
hour.<br
class="">
<br class="">
Is this
something new
with OVMSv3,
or did
something
change / break
on my<br
class="">
car?<br
class="">
<br class="">
Greg<br
class="">
<br class="">
_______________________________________________<br class="">
OvmsDev
mailing list<br
class="">
<a
href="mailto:OvmsDev@lists.openvehicles.com"
class=""
moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a
class="moz-txt-link-freetext"
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
<br class="">
<fieldset
class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
<br class="">
<pre class="moz-signature" cols="144">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
<br class="">
<fieldset
class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
</div>
_______________________________________________<br class="">
OvmsDev mailing
list<br class="">
<a
href="mailto:OvmsDev@lists.openvehicles.com"
class=""
moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a
class="moz-txt-link-freetext"
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br class="">
<fieldset
class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br class="">
OvmsDev mailing list<br
class="">
<a
href="mailto:OvmsDev@lists.openvehicles.com"
class=""
moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a
class="moz-txt-link-freetext"
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br class="">
<fieldset
class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
</div>
_______________________________________________<br class="">
OvmsDev mailing list<br class="">
<a
href="mailto:OvmsDev@lists.openvehicles.com"
class="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a class="moz-txt-link-freetext"
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
</div>
_______________________________________________<br
class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.openvehicles.com"
class="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
class="" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
_______________________________________________<br class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.openvehicles.com" class=""
moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
</body>
</html>