Hi all, Merry Christmas if you celebrate - beautiful hot weather here in Cape Town but surely a different story for most of you! (Michael: Thanks for the help with that "BC".) My car's OBD currently goes off after a while whenever it's not READY (to drive) (whether charging or not), This obviously affects the usability on my car, especially when charging since you can't follow the charging process properly. I did find that if you use the remote key it will wake things up; if you use BMW Connected drive app to lock/unlock then that also wakes things up. I see that the MGEV seems similar - the docs for that car say: The car is accessible over the OBD port when it is running (ignition on) and for around 40 seconds after it is turned off or the car is "tweaked" (lock button pushed, etc). The OBD port may be kept awake by using the "tester present" message to the gateway ECU. This keeps a lot of systems awake and draws roughly 5A on the 12V bus, so it's not a good idea to do. If the car is unlocked, the gateway can be woken if the car is unlocked by pinging the "tester present" message continuously every 100ms until it responds. If the car is locked this simply causes the gateway to go into some kind of zombie proxy mode that isn't very useful. If the car is locked, the gateway may be woken by sending a session 2 command every 250ms to the gateway. I'm looking at the MGEV code to see how it's done - can see the gist of it. It looks like Chris Staite was the author of the MGEV support - Chris are you on the list? Can you answer some questions for me or give me an outline as to how it goes? My logic would be that if the car is charging it doesn't do much harm to try to keep the OBD-II responsive. I suppose it diverts a little power from charging, but when you are on a long trip and fast charging somewhere you want to know if charging stops! Thanks, Steve
On Sat, 26 Dec 2020 at 16:35, Steve Davies <steve@telviva.co.za> wrote:
My car's OBD currently goes off after a while whenever it's not READY (to drive) (whether charging or not),
Trying not to spam with questions - but ... If the car is off and not responding on OBD then obviously information going through to the apps becomes stale. But the apps still show "Live" in the corner and it's not obvious that the info is out of date. Is there a way to show how many minutes old the data is or something like that? Does this interact with the autostale stuff in some way? I'm not really understand the effect of this - I changed the metrics for 12v current to SM_STALE_MID and it must be stale by now but the misleading 8.9A figure is still showing in the OVMS web "status" page. Also in "metrics list". Is it supposed to disappear when it goes stale. Thanks, Steve
Steve, the V3 metrics framework has staleness for every metric. You can query the staleness by the command "metrics list -s". Values aren't supposed to disappear/clear when becoming stale. The "live" indicator on the App is showing if the App has received any update recently (i.e. within the last minute). It doesn't indicate that update had new values, just that the connection to the car is alive. Regarding value staleness, the V2 protocol (which the Apps still use and probably will continue to use, as it's much more efficient than MQTT) only has support for staleness info on a handful of values, mostly the temperature readings. Those get grey when becoming stale. See https://docs.openvehicles.com/en/latest/protocol_v2/index.html for the protocol details. You can add some more staleness info to the V2 message protocol quite easily, and adding support for greying out the values in the App also isn't hard. Add new data to messages at the end for compatibility. Think about which staleness actually matters. Up to now, the staleness indication for temperatures has been sufficient, as these also indicate general staleness. If you plan to add data to the V2 protocol, it's probably best to discuss that first here. The web UI currently doesn't care about staleness. If you miss that info, it isn't hard to add as well, just a bit of work to connect the dots. Regards, Michael Am 26.12.20 um 16:00 schrieb Steve Davies:
On Sat, 26 Dec 2020 at 16:35, Steve Davies <steve@telviva.co.za <mailto:steve@telviva.co.za>> wrote:
My car's OBD currently goes off after a while whenever it's not READY (to drive) (whether charging or not),
Trying not to spam with questions - but ...
If the car is off and not responding on OBD then obviously information going through to the apps becomes stale.
But the apps still show "Live" in the corner and it's not obvious that the info is out of date.
Is there a way to show how many minutes old the data is or something like that?
Does this interact with the autostale stuff in some way? I'm not really understand the effect of this - I changed the metrics for 12v current to SM_STALE_MID and it must be stale by now but the misleading 8.9A figure is still showing in the OVMS web "status" page. Also in "metrics list". Is it supposed to disappear when it goes stale.
Thanks, Steve
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi Michael, On Sat, 26 Dec 2020 at 20:21, Michael Balzer <dexter@expeedo.de> wrote:
the V3 metrics framework has staleness for every metric. You can query the staleness by the command "metrics list -s". Values aren't supposed to disappear/clear when becoming stale.
Yes - thanks. I did find that option in the code - many values seem to report stale in the normal course of running even though the age might even be 0 seconds.
The "live" indicator on the App is showing if the App has received any update recently (i.e. within the last minute). It doesn't indicate that update had new values, just that the connection to the car is alive.
Yes - I did understand that live just meant that the OVMS was sending data. I think that the "stale" attribute of a metric is a very nice idea - though for my current issue it might be enough just to add a private metric saying the last time I got data from the car overall - then in the apps etc I can show the overall age of the displayed info.
Regarding value staleness, the V2 protocol (which the Apps still use and probably will continue to use, as it's much more efficient than MQTT) only has support for staleness info on a handful of values, mostly the temperature readings. Those get grey when becoming stale.
See https://docs.openvehicles.com/en/latest/protocol_v2/index.html for the protocol details. You can add some more staleness info to the V2 message protocol quite easily, and adding support for greying out the values in the App also isn't hard. Add new data to messages at the end for compatibility. Think about which staleness actually matters. Up to now, the staleness indication for temperatures has been sufficient, as these also indicate general staleness. If you plan to add data to the V2 protocol, it's probably best to discuss that first here.
The web UI currently doesn't care about staleness. If you miss that info, it isn't hard to add as well, just a bit of work to connect the dots.
OK - thanks for all that. I think I will start by trying to find a way to keep the OBD awake when it matters - like charging - and see how much of an issue this "staleness" is after that is fixed. Regards, Steve
participants (2)
-
Michael Balzer -
Steve Davies