You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey @DasBasti, I have looked further into the question of what the mileage refers to. I'm now pretty sure it's as follows: the mileage of a car usually refers to the entire vehicle and not just the engine. The odometer is therefore not usually reset when the engine is replaced. The replacement of an engine is considered a type of maintenance or repair, similar to the replacement of other wearing parts. When selling the vehicle, the mileage of the new engine should also be stated in order to avoid committing fraud.
Therefore, the use of "total_increasing" would be more appropriate as it ensures that the mileage only increases. If the Smart API server mistakenly returns an incorrect (lower or even 0) value, this would be ignored when calculating the statistics. If "total" is used, the reduction would be taken into account in the statistics and would therefore distort the result, unless the integration ensures that the value is correct. However, such a validation is not possible for us and could also only check whether the last queried value is greater than or equal to. This is exactly what "total_increasing" ensures.
Can you go along with this? I am not a developer and do not fully understand the status tables in the documentation. I just want to make sure that I get the monthly kilometers driven displayed correctly using the HA statistics integration.
Maybe I could convince you to reconsider the change.
edit: Incidentally, as far as I have understood, the use of "total_increasing" for the trip meter is not correct, as the counter is never reset in this case. If "last_reset" is known, i.e. the API outputs when the counter was reset, "total" could be used. Otherwise the state class "measurement" would be appropriate. I have not tested it, but I assume that the trip meter is currently never reset.
edit2: You can test the behavior of the sensors if you use a statistic card and display the change of the sensor within a period of time in HA. The normal entity card does not show any statistical values and will not confirm the faulty behavior.
You might also want to take a look at the sensor values with the statistical graph card. Here you can display the kilometers driven, for example, in the last day/week/month as a bar chart. This should no longer work with the trip meter as "total increasing" as the trip meter should now behave like an odometer.
Hey @DasBasti, I have looked further into the question of what the mileage refers to. I'm now pretty sure it's as follows: the mileage of a car usually refers to the entire vehicle and not just the engine. The odometer is therefore not usually reset when the engine is replaced. The replacement of an engine is considered a type of maintenance or repair, similar to the replacement of other wearing parts. When selling the vehicle, the mileage of the new engine should also be stated in order to avoid committing fraud.
Therefore, the use of "total_increasing" would be more appropriate as it ensures that the mileage only increases. If the Smart API server mistakenly returns an incorrect (lower or even 0) value, this would be ignored when calculating the statistics. If "total" is used, the reduction would be taken into account in the statistics and would therefore distort the result, unless the integration ensures that the value is correct. However, such a validation is not possible for us and could also only check whether the last queried value is greater than or equal to. This is exactly what "total_increasing" ensures.
Can you go along with this? I am not a developer and do not fully understand the status tables in the documentation. I just want to make sure that I get the monthly kilometers driven displayed correctly using the HA statistics integration.
Maybe I could convince you to reconsider the change.
edit: Incidentally, as far as I have understood, the use of "total_increasing" for the trip meter is not correct, as the counter is never reset in this case. If "last_reset" is known, i.e. the API outputs when the counter was reset, "total" could be used. Otherwise the state class "measurement" would be appropriate. I have not tested it, but I assume that the trip meter is currently never reset.
edit2: You can test the behavior of the sensors if you use a statistic card and display the change of the sensor within a period of time in HA. The normal entity card does not show any statistical values and will not confirm the faulty behavior.
https://www.home-assistant.io/dashboards/statistic/
You might also want to take a look at the sensor values with the statistical graph card. Here you can display the kilometers driven, for example, in the last day/week/month as a bar chart. This should no longer work with the trip meter as "total increasing" as the trip meter should now behave like an odometer.
https://www.home-assistant.io/dashboards/statistics-graph/
Originally posted by @Kanecaine in #135 (comment)
The text was updated successfully, but these errors were encountered: