Greg,
there is no way you could have seen TPMS data with the current Android App and the V3 module firmware before Mark's fix of the TPMS record transmission in issue #357.
The App checks for at least 9 fields in the record, which never was fulfilled because a comma was missing.
The App hides the TPMS info if it is undefined (stale < 0). That is the case if the module has just rebooted and not got the sensor data yet.
So you need to provide some more detail on this, i.e. which versions of the firmware and App are you currently using, and samples of your TPMS record data as transmitted via the V2 server (see server log download).
Regards, Michael
Am 21.04.20 um 22:09 schrieb Greg D.:
Hi folks,
So, I seem to be going backwards with OVMS and my Tesla Roadster...
I'm looking at the OVMS app on my Android phone.
Used to be that I'd see the TPMS data - pressure and temperature - as it was the last time the car was driven.
Then it turned into zeros.
Today I see it's gone altogether. This is not progress.
What I want to see is the data from the car, as last it was read. I do not care that it is not live. In fact, if it were live, that would mean that the car is in Drive, which (hopefully) means that I am in my car. If so, I have *no use* for the OVMS, as the data is sitting right there on the car's display.
Is there any way to get the old functionality back?
Greg
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
Greg,
What firmware version are you running in the module? If EAP/MAIN 3.2.011, can you try updating to the edge release? I suspect you are seeing the bug with 3.2.011 and the TPMS protocol v2 message.
Regards, Mark.
On 22 Apr 2020, at 4:09 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi folks,
So, I seem to be going backwards with OVMS and my Tesla Roadster...
I'm looking at the OVMS app on my Android phone.
Used to be that I'd see the TPMS data - pressure and temperature - as it was the last time the car was driven.
Then it turned into zeros.
Today I see it's gone altogether. This is not progress.
What I want to see is the data from the car, as last it was read. I do not care that it is not live. In fact, if it were live, that would mean that the car is in Drive, which (hopefully) means that I am in my car. If so, I have no use for the OVMS, as the data is sitting right there on the car's display.
Is there any way to get the old functionality back?
Greg
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Greg,
I think the issue you have is that after a firmware update the module will reboot. That will mean it will lose the metrics for TPMS.
Those metrics won’t come back until the car has been driven.
I don’t see a simple solution. We could address it in v2 protocol by not sending the tpms message unless the metrics are defined, but that might still mess up the stale indicator. That wouldn’t affect the individual metrics and v3 protocol we are trying to move to for the future.
There is a small amount of RTC ram that is retained through a reboot. Perhaps we could have a mechanism to save+restore certain metrics there? But not at all simple.
Regards, Mark.
On 22 Apr 2020, at 11:07 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark, Michael,
I am on Edge, and it updated 2am local on the 20th (2 days ago). Firmware: 3.2.011-13-g7d83320/ota_0/edge (build idf v3.3-beta3-775-gdc1ca69 Apr 20 2020 15:10:37). The app is 3.16.1 (2020031801).
I just put the car in Drive for a few minutes, and all the stats got populated. The car is off and sleeping now, so I'll check it again in the morning.
Greg
p.s. Just saw your EAP announcement. With the 3.2.012 code coming, it will be interesting to see what happens after the reset. I'll let you know!
Mark Webb-Johnson wrote:
Greg,
What firmware version are you running in the module? If EAP/MAIN 3.2.011, can you try updating to the edge release? I suspect you are seeing the bug with 3.2.011 and the TPMS protocol v2 message.
Regards, Mark.
On 22 Apr 2020, at 4:09 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Hi folks,
So, I seem to be going backwards with OVMS and my Tesla Roadster...
I'm looking at the OVMS app on my Android phone.
Used to be that I'd see the TPMS data - pressure and temperature - as it was the last time the car was driven.
Then it turned into zeros.
Today I see it's gone altogether. This is not progress.
What I want to see is the data from the car, as last it was read. I do not care that it is not live. In fact, if it were live, that would mean that the car is in Drive, which (hopefully) means that I am in my car. If so, I have no use for the OVMS, as the data is sitting right there on the car's display.
Is there any way to get the old functionality back?
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>
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On 2020-04-21 20:21, Mark Webb-Johnson wrote:
I think the issue you have is that after a firmware update the module will reboot. That will mean it will lose the metrics for TPMS.
Those metrics won’t come back until the car has been driven.
I don’t see a simple solution. We could address it in v2 protocol by not sending the tpms message unless the metrics are defined, but that might still mess up the stale indicator. That wouldn’t affect the individual metrics and v3 protocol we are trying to move to for the future.
There is a small amount of RTC ram that is retained through a reboot. Perhaps we could have a mechanism to save+restore certain metrics there? But not at all simple.
I think the same situation exists for soc, if you decide to go with the "don't send when undefined" it would be good to change it too.
I just did some testing and I guess the V3 protocol already works this way.
CraigI think best to move to EAP and see if that improves the situation. On ‘edge’, you will be getting an update (and reboot) once every night or two.
Regards, Mark.
On 22 Apr 2020, at 12:58 PM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
Yes, I understand that. Not expecting such a dramatic change as saving data in NV RAM. The end user presumably won't have their module rebooting very often, so this isn't worth trying to save stuff across reboots.
I'm trying think back to when the behavior started to change. It might have been when I moved off the Main branch to Edge because of the bug with OBD2ECU CAN initialization, so module reboots are far more frequent. I'm tempted to get back on Main, or at least EAP, but I'm also vaguely remembering that there was a change related specifically to "stale" data that put a lot of data out of reach for a day. This latest UI behavior change was the straw that caused me to write.
It seems like populating data takes a lot longer now than, say, 6 months ago. Did something change a while back that has led to this? Part of the puzzle, perhaps, is that we have two moving pieces, the Module and the App. I'm on Android, if that matters.
Greg
Mark Webb-Johnson wrote:
Greg,
I think the issue you have is that after a firmware update the module will reboot. That will mean it will lose the metrics for TPMS.
Those metrics won’t come back until the car has been driven.
I don’t see a simple solution. We could address it in v2 protocol by not sending the tpms message unless the metrics are defined, but that might still mess up the stale indicator. That wouldn’t affect the individual metrics and v3 protocol we are trying to move to for the future.
There is a small amount of RTC ram that is retained through a reboot. Perhaps we could have a mechanism to save+restore certain metrics there? But not at all simple.
Regards, Mark.
On 22 Apr 2020, at 11:07 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Hi Mark, Michael,
I am on Edge, and it updated 2am local on the 20th (2 days ago). Firmware: 3.2.011-13-g7d83320/ota_0/edge (build idf v3.3-beta3-775-gdc1ca69 Apr 20 2020 15:10:37). The app is 3.16.1 (2020031801).
I just put the car in Drive for a few minutes, and all the stats got populated. The car is off and sleeping now, so I'll check it again in the morning.
Greg
p.s. Just saw your EAP announcement. With the 3.2.012 code coming, it will be interesting to see what happens after the reset. I'll let you know!
Mark Webb-Johnson wrote:
Greg,
What firmware version are you running in the module? If EAP/MAIN 3.2.011, can you try updating to the edge release? I suspect you are seeing the bug with 3.2.011 and the TPMS protocol v2 message.
Regards, Mark.
On 22 Apr 2020, at 4:09 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Hi folks,
So, I seem to be going backwards with OVMS and my Tesla Roadster...
I'm looking at the OVMS app on my Android phone.
Used to be that I'd see the TPMS data - pressure and temperature - as it was the last time the car was driven.
Then it turned into zeros.
Today I see it's gone altogether. This is not progress.
What I want to see is the data from the car, as last it was read. I do not care that it is not live. In fact, if it were live, that would mean that the car is in Drive, which (hopefully) means that I am in my car. If so, I have no use for the OVMS, as the data is sitting right there on the car's display.
Is there any way to get the old functionality back?
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>
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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Ok, EAP is set. Let's see what happens at 2am...
Greg
On April 21, 2020 11:05:01 PM PDT, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I think best to move to EAP and see if that improves the situation. On ‘edge’, you will be getting an update (and reboot) once every night or two.
Regards, Mark.
- as it was the last time the car was driven.
On 22 Apr 2020, at 12:58 PM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
Yes, I understand that. Not expecting such a dramatic change as saving data in NV RAM. The end user presumably won't have their module rebooting very often, so this isn't worth trying to save stuff across reboots.
I'm trying think back to when the behavior started to change. It might have been when I moved off the Main branch to Edge because of the bug with OBD2ECU CAN initialization, so module reboots are far more frequent. I'm tempted to get back on Main, or at least EAP, but I'm also vaguely remembering that there was a change related specifically to "stale" data that put a lot of data out of reach for a day. This latest UI behavior change was the straw that caused me to write.
It seems like populating data takes a lot longer now than, say, 6 months ago. Did something change a while back that has led to this? Part of the puzzle, perhaps, is that we have two moving pieces, the Module and the App. I'm on Android, if that matters.
Greg
Mark Webb-Johnson wrote:
Greg,
I think the issue you have is that after a firmware update the module will reboot. That will mean it will lose the metrics for TPMS.
Those metrics won’t come back until the car has been driven.
I don’t see a simple solution. We could address it in v2 protocol by not sending the tpms message unless the metrics are defined, but that might still mess up the stale indicator. That wouldn’t affect the individual metrics and v3 protocol we are trying to move to for the future.
There is a small amount of RTC ram that is retained through a reboot. Perhaps we could have a mechanism to save+restore certain metrics there? But not at all simple.
Regards, Mark.
On 22 Apr 2020, at 11:07 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Hi Mark, Michael,
I am on Edge, and it updated 2am local on the 20th (2 days ago). Firmware: 3.2.011-13-g7d83320/ota_0/edge (build idf v3.3-beta3-775-gdc1ca69 Apr 20 2020 15:10:37). The app is 3.16.1 (2020031801).
I just put the car in Drive for a few minutes, and all the stats got populated. The car is off and sleeping now, so I'll check it again in the morning.
Greg
p.s. Just saw your EAP announcement. With the 3.2.012 code coming, it will be interesting to see what happens after the reset. I'll let you know!
Mark Webb-Johnson wrote:
Greg,
What firmware version are you running in the module? If EAP/MAIN 3.2.011, can you try updating to the edge release? I suspect you are seeing the bug with 3.2.011 and the TPMS protocol v2 message.
Regards, Mark.
On 22 Apr 2020, at 4:09 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Hi folks,
So, I seem to be going backwards with OVMS and my Tesla Roadster...
I'm looking at the OVMS app on my Android phone.
Used to be that I'd see the TPMS data - pressure and temperature
Then it turned into zeros.
Today I see it's gone altogether. This is not progress.
What I want to see is the data from the car, as last it was read.
I do not care that it is not live. In fact, if it were live, that would mean that the car is in Drive, which (hopefully) means that I am in my car. If so, I have no use for the OVMS, as the data is sitting right there on the car's display.
Is there any way to get the old functionality back?
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>
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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- This space for rent...
Hi all I would like to point to this thread: http://lists.openvehicles.com/pipermail/ovmsdev/2020-March/006730.html The code for TMPS has been changed for vehicles that don't support TPMS Regards Chris
Am Mittwoch, den 22.04.2020, 11:23 -0700 schrieb Greg D.:
Ok... So the module updated to EAP last night, as expected. The display (screen shot) shows zeros for Ambient, Charger/PEM, Motor, and battery; 12v is live, as is the odometer. TPMS is missing. Is there a reason that the bulk of the metrics aren't read? Are they not present on the CAN bus, or is the module explicitly not watching for them until the car wakes up?
If I wake the car up, Ambient, Charger/PEM, motor, and battery are immediately updated, but TPMS is still missing.
For consistency and less confusion, I would like for the TPMS to be populated in both screen shots, and showing zeros until the car is driven. And by "consistency" I do NOT mean "remove the other metrics too". I'm trying to be careful what I wish for...
When I put it in Drive for a few minutes, the TPMS icons do appear with live data. I'll let the car sit for a few days, and see what happens to the display. What I expect is that they will remain present, even if not live.
Greg
Greg D wrote:
Ok, EAP is set. Let's see what happens at 2am...
Greg
On April 21, 2020 11:05:01 PM PDT, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I think best to move to EAP and see if that improves the situation. On ‘edge’, you will be getting an update (and reboot) once every night or two.
Regards, Mark.
On 22 Apr 2020, at 12:58 PM, Greg D. <gregd2350 @gmail.com> wrote:
Hi Mark,
Yes, I understand that. Not expecting such a dramatic change as saving data in NV RAM. The end user presumably won't have their module rebooting very often, so this isn't worth trying to save stuff across reboots.
I'm trying think back to when the behavior started to change. It might have been when I moved off the Main branch to Edge because of the bug with OBD2ECU CAN initialization, so module reboots are far more frequent. I'm tempted to get back on Main, or at least EAP, but I'm also vaguely remembering that there was a change related specifically to "stale" data that put a lot of data out of reach for a day. This latest UI behavior change was the straw that caused me to write.
It seems like populating data takes a lot longer now than, say, 6 months ago. Did something change a while back that has led to this? Part of the puzzle, perhaps, is that we have two moving pieces, the Module and the App. I'm on Android, if that matters.
Greg
Mark Webb-Johnson wrote:
Greg,
I think the issue you have is that after a firmware update the module will reboot. That will mean it will lose the metrics for TPMS.
Those metrics won’t come back until the car has been driven.
I don’t see a simple solution. We could address it in v2 protocol by not sending the tpms message unless the metrics are defined, but that might still mess up the stale indicator. That wouldn’t affect the individual metrics and v3 protocol we are trying to move to for the future.
There is a small amount of RTC ram that is retained through a reboot. Perhaps we could have a mechanism to save+restore certain metrics there? But not at all simple.
Regards, Mark.
On 22 Apr 2020, at 11:07 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark, Michael,
I am on Edge, and it updated 2am local on the 20th (2 days ago). Firmware: 3.2.011-13- g7d83320/ota_0/edge (build idf v3.3-beta3-775- gdc1ca69 Apr 20 2020 15:10:37). The app is 3.16.1 (2020031801).
I just put the car in Drive for a few minutes, and all the stats got populated. The car is off and sleeping now, so I'll check it again in the morning.
Greg
p.s. Just saw your EAP announcement. With the 3.2.012 code coming, it will be interesting to see what happens after the reset. I'll let you know!
Mark Webb-Johnson wrote:
> > Greg, > > > > What firmware version > are you running in > the module? If > EAP/MAIN 3.2.011, can > you try > updating to the edge > release? I > suspect you are > seeing the bug with > 3.2.011 and the TPMS > protocol v2 > message. > > > > Regards, Mark. > > > > > > On 22 Apr 2020, > > at > > 4:09 AM, Greg > > D. <gregd2350@gmail.com> > > wrote: > > > > > > > > > > > > Hi folks, > > > > > > > > So, I seem > > to be going > > backwards > > with OVMS and my > > Tesla > > Roadster... > > > > > > > > I'm looking > > at the OVMS app > > on my > > Android phone. > > > > > > > > Used to be > > that I'd see the > > TPMS data - > > pressure and > > temperature > > - as it was the > > last time > > the car was > > driven. > > > > > > > > Then it > > turned into zeros. > > > > > > > > Today I see > > it's gone > > altogether. > > This is not > > progress. > > > > > > > > What I want > > to see is the > > data from > > the car, as last > > it was > > read. I do not care > > that it is > > not live. In > > fact, if it > > were live, that > > would mean > > that the car is > > in Drive, > > which (hopefully) > > means that > > I am in my car. > > If so, I > > have no > > use for > > the OVMS, as > > the data is > > sitting right > > there on > > the car's display. > > > > > > > > Is there > > any way to get the > > old > > functionality back? > > > > > > > > Greg > > > > > > _______________________________________________ > > > > OvmsDev > > mailing list > > > > 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 > >
OvmsDev mailing list
OvmsDev@lists.openvehicles.co m
http://lists.openvehicles.com /mailman/listinfo/ovmsdev
_______________________________________
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_____________________________________________ __
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinf o/ovmsdev
--
This space for rent...
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
@Chris: Thanks for the reminder - I am aware of it and that was the area of code I fixed for 3.2.012. The issue was a simple typo - missing the comma between the left rear tyre temperature and the stale indicator.
@Greg:
The approach Chris mentioned indeed differentiated between a metric NEVER being defined (by a car module) and the value merely being stale (not currently updated). It should not affect the roadster.
There are four types of sensor (in the roadster modules at least):
One that transmit continuously, and always, no matter the state of the car (e.g. SOC%). One that transmits only while the car is awake (e.g. PEM temperature). One that transmits only when the car is doing something (e.g. TPMS). One that transmits only on specific request (e.g. CAC).
We typically can’t control those (although in the case of #2 we can in some circumstances wake up the car to force it to update the sensor, but that has other consequences).
In the case of TPMS in the roadster, when the module resets we don’t have any record of the TPMS value. We also have no known way to request the car to transmit it. There is also a limitation of the TPMS (W) message in OVMS protocol v2 in that the stale indicator is at the end of the message so we can’t update that indicator without also transmitting the TPMS values. So, we are faced with three choices:
Don’t transmit any TPMS (W) message at all. The App will then get the old stored value from the server, but the stale sensor maybe incorrect. Not good. Transmit a TPMS (W) message, using zeros for temperatures and pressures. Terrible for a car like the roadster that supports TPMS. Transmit a TPMS (W) message, with a ’stale' indicator to show that the TPMS values are not defined / valid at all.
We chose #3, as it seems the best we can do.
The current behaviour (with 3.2.012) should be that if you drive the car, the TPMS should be shown in bright white. If you then park, after some time the values will go stale and show as gray in the App. That should continue, so long as you don’t reboot the module. If you reboot the module, the TPMS will be lost and the App won’t show the values until you next drive the car. That is the best we can do with v2 protocol, imho.
Please try it for a few days, without rebooting the module, and make sure that works for you as above.
Regards, Mark.
P.S. From a metric point of view, I am convinced that the approach we currently have of a metric recording meta data on whether it has ever been set (defined), if it has not been updated for a while (stale), as well as the value itself (with units) is the correct one. We need to think about protocol v3 and the future - in particular how the stale and defined meta data can be indicated to apps.
On 23 Apr 2020, at 2:46 AM, Greg D. <gregd2350@gmail.com> wrote:
So, this is affecting ALL cars? Not what I would want to see.
Fundamentally, there is a difference between a metric being undefined for a vehicle, and one which the car supports but which has not yet been populated. Did this fix take too broad a swipe at the TPMS metric? That approach could get confusing over time, as some cars support some metrics and not others.
Greg
Chris van der Meijden wrote:
Hi all
I would like to point to this thread:
http://lists.openvehicles.com/pipermail/ovmsdev/2020-March/006730.html <http://lists.openvehicles.com/pipermail/ovmsdev/2020-March/006730.html>
The code for TMPS has been changed for vehicles that don't support TPMS
Regards
Chris
Am Mittwoch, den 22.04.2020, 11:23 -0700 schrieb Greg D.:
Ok... So the module updated to EAP last night, as expected. The display (screen shot) shows zeros for Ambient, Charger/PEM, Motor, and battery; 12v is live, as is the odometer. TPMS is missing. Is there a reason that the bulk of the metrics aren't read? Are they not present on the CAN bus, or is the module explicitly not watching for them until the car wakes up?
If I wake the car up, Ambient, Charger/PEM, motor, and battery are immediately updated, but TPMS is still missing.
For consistency and less confusion, I would like for the TPMS to be populated in both screen shots, and showing zeros until the car is driven. And by "consistency" I do NOT mean "remove the other metrics too". I'm trying to be careful what I wish for...
When I put it in Drive for a few minutes, the TPMS icons do appear with live data. I'll let the car sit for a few days, and see what happens to the display. What I expect is that they will remain present, even if not live.
Greg
Greg D wrote:
Ok, EAP is set. Let's see what happens at 2am...
Greg
On April 21, 2020 11:05:01 PM PDT, Mark Webb-Johnson <mark@webb-johnson.net> <mailto:mark@webb-johnson.net> wrote:
I think best to move to EAP and see if that improves the situation. On ‘edge’, you will be getting an update (and reboot) once every night or two.
Regards, Mark.
On 22 Apr 2020, at 12:58 PM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Hi Mark,
Yes, I understand that. Not expecting such a dramatic change as saving data in NV RAM. The end user presumably won't have their module rebooting very often, so this isn't worth trying to save stuff across reboots.
I'm trying think back to when the behavior started to change. It might have been when I moved off the Main branch to Edge because of the bug with OBD2ECU CAN initialization, so module reboots are far more frequent. I'm tempted to get back on Main, or at least EAP, but I'm also vaguely remembering that there was a change related specifically to "stale" data that put a lot of data out of reach for a day. This latest UI behavior change was the straw that caused me to write.
It seems like populating data takes a lot longer now than, say, 6 months ago. Did something change a while back that has led to this? Part of the puzzle, perhaps, is that we have two moving pieces, the Module and the App. I'm on Android, if that matters.
Greg
Mark Webb-Johnson wrote: > Greg, > > I think the issue you have is that after a firmware update the module will reboot. That will mean it will lose the metrics for TPMS. > > Those metrics won’t come back until the car has been driven. > > I don’t see a simple solution. We could address it in v2 protocol by not sending the tpms message unless the metrics are defined, but that might still mess up the stale indicator. That wouldn’t affect the individual metrics and v3 protocol we are trying to move to for the future. > > There is a small amount of RTC ram that is retained through a reboot. Perhaps we could have a mechanism to save+restore certain metrics there? But not at all simple. > > Regards, Mark. > >> On 22 Apr 2020, at 11:07 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote: >> >> Hi Mark, Michael, >> >> I am on Edge, and it updated 2am local on the 20th (2 days ago). Firmware: 3.2.011-13-g7d83320/ota_0/edge (build idf v3.3-beta3-775-gdc1ca69 Apr 20 2020 15:10:37). The app is 3.16.1 (2020031801). >> >> I just put the car in Drive for a few minutes, and all the stats got populated. The car is off and sleeping now, so I'll check it again in the morning.
>> >> Greg >> >> p.s. Just saw your EAP announcement. With the 3.2.012 code coming, it will be interesting to see what happens after the reset. I'll let you know! >> >> >> >> >> Mark Webb-Johnson wrote: >>> Greg, >>> >>> What firmware version are you running in the module? If EAP/MAIN 3.2.011, can you try updating to the edge release? I suspect you are seeing the bug with 3.2.011 and the TPMS protocol v2 message. >>> >>> Regards, Mark. >>> >>>> On 22 Apr 2020, at 4:09 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote: >>>> >>>> Hi folks, >>>> >>>> So, I seem to be going backwards with OVMS and my Tesla Roadster... >>>> >>>> I'm looking at the OVMS app on my Android phone.
>>>> >>>> Used to be that I'd see the TPMS data - pressure and temperature - as it was the last time the car was driven.
>>>> >>>> Then it turned into zeros. >>>> >>>> Today I see it's gone altogether. This is not progress. >>>> >>>> What I want to see is the data from the car, as last it was read. I do not care that it is not live. In fact, if it were live, that would mean that the car is in Drive, which (hopefully) means that I am in my car. If so, I have no use for the OVMS, as the data is sitting right there on the car's display. >>>> >>>> Is there any way to get the old functionality back? >>>> >>>> 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> >> >> _______________________________________________ >> 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>
-- This space for rent...
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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On 2020-04-21 20:21, Mark Webb-Johnson wrote:
There is a small amount of RTC ram that is retained through a reboot. Perhaps we could have a mechanism to save+restore certain metrics there? But not at all simple.
I figured out how to do this and implemented it with this pull request:
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/377
The trick is the RTC_NOINIT_ATTR macro which places data into RTC slow memory, in a memory section that is not initialized on boot:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/gener...
There is a new persist argument that can be used when creating a metric:
- ms_v_bat_soc = new OvmsMetricFloat(MS_V_BAT_SOC, SM_STALE_HIGH,Percentage); + ms_v_bat_soc = new OvmsMetricFloat(MS_V_BAT_SOC, SM_STALE_HIGH, Percentage, true);
This is only implemented for OvmsMetricFloat and I only enabled it for a small set of metrics. "metrics persist" shows what's being saved, how many bytes are in use, etc. (It just occurred to me it would be better to add a flag to "metrics list" to only show persist metrics ...)
The changes solve my desire for v.b.soc to be visible in the app after a reboot. I wanted to use it for v.p.direction but minor drifts in the calculated gps position foil that. I enabled it for the tpms metrics but since my cars don't have working tpms code even when I manually populate values (e.g. "metrics set v.tp.fl.p 202.29") the app doesn't show them because (I believe) they are stale.
I expect there are metrics you "big battery" guys will want to add. (And it won't hurt my feelings if somebody completely rewrites this.)
CraigOVMS# metrics persist ? Usage: metrics persist [-r] OVMS# metrics persist version 1 serial 2 size 340 slots used 13 of 16 v.b.soc 82.0 v.b.temp 19.0 v.m.temp 0.0 v.e.temp 20.0 v.p.odometer 0.0 v.tp.fl.t 0.0 v.tp.fr.t 0.0 v.tp.rr.t 0.0 v.tp.rl.t 0.0 v.tp.fl.p 0.0 v.tp.fr.p 0.0 v.tp.rr.p 0.0 v.tp.rl.p 0.0
participants (6)
-
Chris van der Meijden -
Craig Leres -
Greg D -
Greg D.
-
Mark Webb-Johnson -
Michael Balzer