<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><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 color="#000000" class="">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="">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="">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">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 wrap="" class="">_______________________________________________
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 class="">
</div>
_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class=""><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" class="">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="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></body></html>