[Ovmsdev] indirect TPMS in app
sharkcow at gmx.de
Mon Jan 11 16:30:26 HKT 2021
Sounds like a great idea to me :)
Am 10.01.21 um 22:40 schrieb Michael Balzer:
> I read something about this being typical for all (or many?) VW
> vehicles, apparently they don't have dedicated TPMS sensors but derive
> the tyre "health" from the ESP sensors.
> If that's correct, there is no way we will ever be able to map the
> values to actual temperatures & pressures.
> So… how about adding new relative TPMS metrics & warning/alert
> indicators to be used alternatively to the current absolute temperatures
> & pressures?
> We could add these now as vectors, and replace the previous single
> metrics for temperatures & pressures by vectors as well. That would
> reduce the metric payload size on both MQTT and the WebSocket transport,
> and also adapt nicely to vehicles with more or less than four wheels.
> Proposal: numbering scheme rows front to back, left to right per row.
> For four wheels:
> v.t.pressure fl,fr,rl,rr [kPa]
> v.t.temp fl,fr,rl,rr [°C]
> v.t.health fl,fr,rl,rr [%]
> v.t.alert fl,fr,rl,rr [0/1/2]
> The alert vector can use the same scheme as with the battery cells, i.e.
> 0 = OK, 1 = warning, 2 = alert.
> The MP message "W" can be replaced by a new one. Proposal: Code "Y", data:
> * number of wheels
> * pressure values + staleness
> * temp values + staleness
> * health values + staleness
> * alert values + staleness
> We can continue producing "W" messages for old clients in the field.
> Anything missing?
> If that's OK for all, I can make the necessary changes.
> Am 09.01.21 um 19:35 schrieb sharkcow:
>> Thanks for your input, Michael.
>> I agree that we could use the relative metrics to roughly estimate the
>> current assumed pressure from a reference value (which would have to be
>> updated every time a user presses the TPMS reset button...).
>> But: I'm afraid the correlation is not linear, probably not even
>> reproducible. Also, we have two pressure-related values per wheel, while
>> OVMS for now has a pressure and a temperature value.
>> So... I think I'd still prefer two relative indicators for the e-up in
>> the app. I can try to work on implementing a custom MP record.
>> Am 08.01.21 um 18:33 schrieb Michael Balzer:
>>> as we don't have a new capabilities message scheme yet, conditional
>>> blocks are the way it works right now in the App.
>>> The meanings of standard metrics and message data fields should not be
>>> changed. Introducing custom metrics and a custom MP record is a possible
>>> But having custom solutions for common things like this is a PITA. Maybe
>>> we can work something out to convert the readings into the standard
>>> For example: if you get a "health percentage", we could introduce a
>>> configuration for the "100%" health pressure level, so we can get an
>>> absolute value from that.
>>> Am 08.01.21 um 15:12 schrieb sharkcow:
>>>> I have now figured out how to read and partly how to interpret the
>>>> metrics of the indirect TPMS on the e-up.
>>>> We get a "tyre emergency" and a "pressure diffusion" value for each
>>>> Since the values are relative, I would like to transmit them to the app
>>>> as raw data and only display a percentage (100% means everything is
>>>> Would it be ok to just introduce an if-statement in the app to detect
>>>> whether the vehicle type is an e-up and change the default displays
>>>> PS: I feel this value (incl. a useful alert value) would be very
>>>> beneficial: I just found out that I had lost quite some pressure over
>>>> the 2 years I own the vehicle without TPMS reacting. The metrics on OBD
>>>> showed a nicely measureable change however, which could easily be used
>>>> to have OVMS notify me. (Yes, I should have checked the pressure
>>>> regularly, but hey: what's a TPMS for?!)
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
More information about the OvmsDev