[Ovmsdev] indirect TPMS in app

[sharkcow]

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.
>
> Regards,
> Michael
>
>
> 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.
>>
>> sharkcow
>>
>>
>> Am 08.01.21 um 18:33 schrieb Michael Balzer:
>>> Sharkcow,
>>>
>>> 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
>>> solution.
>>>
>>> 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
>>> metrics?
>>>
>>> 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.
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> 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
>>>> wheel.
>>>>
>>>> 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
>>>> ok).
>>>>
>>>> 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
>>>> accordingly?
>>>>
>>>> sharkcow
>>>>
>>>> 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
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at 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
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>