Re-reading this, perhaps I was not clear… I think the proposal is: Rename ‘v.e.awake’ to be ‘v.e.accessory’, and change all code in our firmware to reflect that (both definition and uses). Rename ‘v.e.aux12v’ to be ‘v.e.awake’, and change all code in our firmware to reflect that (both definition and uses). The implementation of the ‘awake’ command is still vehicle dependent. Is that correct? If so, I have no objections, and really don’t mind either way. Regards, Mark.
On 18 Feb 2020, at 9:34 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Greg,
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.
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.
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.
Regards, Mark.
On 18 Feb 2020, at 8:43 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Hi Mark,
Forgive me, but I'm not quite ready to let this one go. Please help me untangle some of this in my mind.
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.
Foundational concepts. 1. 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.
2. 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.
3. 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.
I believe all of the 1, 2, & 3 above is correct. Yes?
What I don't know 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? Do any of the EVs respond in this way? If not, then we have not correctly defined what Awake is.
Proposal 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...
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.
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.
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.
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.
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.
Thanks,
Greg
Mark Webb-Johnson wrote:
Greg,
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 https://docs.openvehicles.com/en/latest/userguide/metrics.html <https://docs.openvehicles.com/en/latest/userguide/metrics.html> we can see:
v.e.awake yes = Vehicle/bus awake (switched on) ie; my state #3 (Ignition on to the first stop)
v.e.on yes = “Ignition” state (drivable) ie; my state #4 (Ignition on all the way)
and the new v.e.aux12v yes = Auxiliary 12v system is on
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.
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.
The choices we had were:
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.
or
Add a new metric ‘v.e.aux12v’ to properly track the 12v auxiliary power.
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.
Bottom line is that the states for Roadster are now:
Car asleep. v.e.awake=off, v.e.on=off, v.e.aux12v=off. 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. The ignition is turned on. v.e.awake=on, v.e.on=on, v.e.aux12v=on.
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.
Regards, Mark.
On 10 Feb 2020, at 2:08 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Hi Mark, Michael,
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.
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.
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.
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.
Greg
Mark Webb-Johnson wrote:
OK. This is in 3.2.010-6-gac7c26d.
@Greg can you try this one (OTA) and let me know if you see any more of these alerts.
Regards, Mark.
On 9 Feb 2020, at 5:50 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
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: > > Ignition off, asleep, consuming as little power as possible > Ignition off, awake, with some systems using power > Ignition on to the first stop (just some systems on, but car not started) > Ignition on all the way (engine running or starting) > 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@gmail.com <mailto:gregd2350@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@gmail.com <mailto:gregd2350@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> > > > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev