[Ovmsdev] indirect TPMS in app

Michael Balzer dexter at expeedo.de
Sun Jan 24 00:26:51 HKT 2021


sharkcow,

my proposal followed your request:

Am 08.01.21 um 15:12 schrieb sharkcow:
> 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). 

I don't know what "diffusion" means in regards to tyres, and I assume no 
user will know that. So it would be a useless and/or confusing display 
in the App. I suggest deriving a health percentage from that, as you 
initially wrote.

And "emergency" seems to be mappable to the "alert" metric?

Regards,
Michael


Am 23.01.21 um 17:13 schrieb sharkcow:
> Michael,
>
> this looks great, thanks!
>
> However, at least for the e-Up we get two values per wheel (diffusion
> and tyre emergency). I personally would like to display both in the app.
> From what I understand, I can't easily extend the current metric layout
> for that, right?
>
> If this approach is completely unacceptable, I could also try to merge
> the two values per wheel into one "health" indicator.
>
> Regards,
>
> sharkcow
>
>
> Am 17.01.21 um 18:51 schrieb Michael Balzer:
>> Everyone,
>>
>> 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:
>> https://docs.openvehicles.com/en/latest/protocol_v2/messages.html#car-tpms-message-0x59-y 
>>
>>
>> Example messages from the DEMO vehicle:
>>
>> Y4,FL,FR,RL,RR,4,206.8,216.5,275.8,175.8,0,4,33.0,33.0,34.0,38.0,0,4,95.0,93.0,96.0,74.0,0,4,0,0,0,1,0 
>>
>> W31.3982,33,25.4962,38,30,33,40,34,1
>>
>> 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:
>>
>> TPMS ALERT:
>> 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.
>>
>> Regards,
>> Michael
>>
>>
>> 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
>>
>> -- 
>> 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
>>
> _______________________________________________
> 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210123/80671075/attachment.sig>


More information about the OvmsDev mailing list