Two trivial PRs - round v.b.consumption down to 0 when tiny; make v.b.voltage SM_STALE_HIGH
Hi, Michael please see PRs #515 and #516 two trivial tweaks that came out of the I3 work. Steve
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?!)
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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
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
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
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@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
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-m... 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@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
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-m...
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@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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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-m...
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@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
_______________________________________________ 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
Michael, well, "initially", I also wrote that we get two values per wheel :) Probably I wasn't being perfectly clear though: we get two relative health values per tyre. From my understanding, the ESP-based TPMS values derive the "tyre emergency" from different (relative) rotation speeds. So that indicates that one tyre has lower pressure than the others. Since this does not cover the case when the pressure reduces simultaneously in all tyres (by diffusion), some sophisticated frequency analysis is performed which yields the diffusion values. But I agree that for a normal user, the most important information is that something's wrong with the pressure. And we even provide more information than the car by showing which tyres are affected. So I'll just use the minimum value out of the two for each tyre as health indicator. And of course I'll set the alert values depending on thresholds. Regards, sharkcow Am 23.01.21 um 17:26 schrieb Michael Balzer:
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-m...
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@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
_______________________________________________ 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
participants (3)
-
Michael Balzer -
sharkcow -
Steve Davies