• 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.
  

TPMS ALERT:
FR wheel ALERT: Health=91% Pressure=9.1kPa Temp=21C
RR wheel WARNING: Health=90% Pressure=9kPa Temp=9C

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@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.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@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