Sensor: fix state class according to dev doc #135
Conversation
|
Hey @DasBasti, I have read through the developer documentation several times and tried to understand it. I am of the opinion that your first implementation was correct when "total increasing" was used for the odometer. The description on the page you linked in the code is somewhat misleading in my opinion. ChatGPT sees it the same way and gave me, confirming, this as an answer: "For the odometer (kilometer counter) of a car, you should use the total_increasing state class. This is because the odometer value can only increase over time, and any decrease would indicate a reset or replacement. This aligns with the definition of total_increasing, which is suitable for sensors like gas meters, electricity meters, or water meters, where values only increase." Maybe you can check this again. By the way: why not setting the correct state class for all correspnding entities like „maximum range at 100% soc“ or for the values of the 12V battery? |
|
Yeah I found it confusing as well. How is it handled in electric cars, is the odometer connected to the motor(s) or the car? So can it be reset? The docs read like total increasing is the right for the trip meter and will give a reset time when it reseted? I will try that one tomorrow if I do not forget. Also a good look at all the other sensors would make sense. Thanks for the feedback. |
|
Thank you very much. Please have a deeper look at the further description for calculating the sum column - this is how i understand it (assuming that a car’s odometer should never reset): The main difference between the "total" and "total_increasing" status classes for a counter that is never reset lies in the way in which the statistics are updated. total_increasing: used when the value of the sensor can only increase and a decrease is considered a reset or error. The total column is only updated with positive differences. total: Is used if the value can both increase and decrease without a reset being considered an error. This status class takes into account both increases and decreases in the total. |
|
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. |
|
Thank you for further investigation @Kanecaine . I had peek into the Tesla custom integration and they also have the odometer as total_increasing. I read the documentation the way that total is used for values that never reset and that values that can be reset to 0 it's total_increasing. But I think this change is wrong and needs to be switched back to total_increasing for odometer and measurement for the trip since we do not have a reset timestamp. If you would like to have a try changing it you are very much welcome to do so. Otherwise I will put it as a bug into 0.4 and work on it in the next days. |
I agree and yes, the documentation is unfortunately not clear on this really important topic. I've read it up and down and asked ChatGPT about it ... but if the Tesla integration handles it the same way, we have this as additional confirmation. I appreciate you taking on the Smart API integration and that you value my feedback. However, I'm afraid I have to decline your offer that I could try to change it myself. On the one hand, I would definitely be interested in doing this, but on the other hand, I would have to deal with the whole development topic first, which I unfortunately don't have the time for at the moment. I would therefore ask you to open the bug ticket and take a look at it in the next few days. Thank you very much for this and for everything you contribute here. |
No description provided.