[Ovmsdev] indirect TPMS in app
dexter at expeedo.de
Mon Jan 18 01:51:16 HKT 2021
this is now fully implemented and committed.
Please note I did a slight change regarding the wheel layout and "Y"
message structure, to better support custom layouts.
* The TPMS wheel layout now is defined by
OvmsVehicle::GetTpmsLayout(), which can be overridden by a vehicle
to implement custom layouts. The default is the proposed FL,FR,RL,RR.
* The wheel layout is included in the "Y" message as the first part,
and the number of values is included for each vector.
See updated MP documentation here:
Example messages from the DEMO vehicle:
I'll take care of supporting "Y" in the Android App.
I've also added an automatic TPMS alert triggered by changes to the
v.t.alert vector. Example alert text:
FR wheel ALERT: Health=91% Pressure=9.1kPa Temp=21C
RR wheel WARNING: Health=90% Pressure=9kPa Temp=9C
No alerts will be set automatically, you need to add setting some proper
alert level if you'd like to use this new feature.
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
>>> But having custom solutions for common things like this is a PITA.
>>> 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
>>>> 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
>>>> 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
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 203 bytes
Desc: OpenPGP digital signature
More information about the OvmsDev