Feature Request: Add driving statistics

[CM000n]

As a continuation to this discussion: https://github.com/DurgNomis-drol/ha_toyota/issues/10#issuecomment-801730128, here is a feature request to implement driving statistics for the current year, week, day.

Currently, the following statistics are already supported in Calmjm Python Script (https://github.com/calmjm/tojota/blob/master/statistics.py), for which it would also be great to have them available in Home Assistant as (optional) sensors:

• Average fuel consumption
• EV Distiance in km/mi
• EV Distance in %
• Total Distance
• Average Speed
• Maximum Speed
• Total Trips
• Amount of Night Trips

Perhaps other metrics and time units are also possible, but they need to be found out first. Feel free to split the ticket into individual requests per sensor if helpful.

Best regards and thank you very much

[DurgNomis-drol]

I am close to releasing statistical sensors, but i have some questions about how to best implement these sensors.

My thought is to create 4 sensors, one for current week and month and one for last week and month.

And also have a sensor that gives stats from the last 24 hours.

And lastly create a sensor that contains stats from start of the year to current date.

Each sensor will contain all the points mentioned above, were available.

What are your guys thoughts on this?

[CM000n]

For me personally, sensors for the past week, the past month, etc. are rather uninteresting. Since I write away the values of the sensors relevant for me into my database, I have thus always a comparison possibility for arbitrary time series. Therefore I only need the current values for Week to Date (WTD), Month to date (MTD) and year to date (YTD). How do you actually handle the different week beginnings? In some countries a week starts with Sunday and in some with Monday. Is that determined by the country code you specify during configuration?

[DurgNomis-drol]

I think it somehow wrote the same comment twice 😆

You are raising some great points.

I will start with current week, current month and year to date.

Do you mind sharing how you save the data to a database?

About different week beginnings, i don't handle anything in the code. I use pendulum to calculate dates. It uses Monday as start of week (But can handle Sunday also). I don't know if the Toyota API changes which day it starts a week on, depending on locale setting. It might do that. More information and research are needed here. But it should be rather trivial to implement a solution for that.

[CM000n]

I once read in calmjm's github repo that the Toyota API probably stores the weekly stats not by ISO weeks but by Japanese logic starting with Sunday up to and including Saturday. At least probably for the week numbers. I don't know if you use the same method, but maybe we would have to validate that once.: https://github.com/calmjm/tojota/blob/master/statistics.py

Regarding the storage of the HA sensor values I use another custom component called LTSS: https://github.com/freol35241/ltss Since I am more familiar with SQL than InfluxQL and I think it offers more possibilities for data processing, it is the most optimal solution for me. With this custom component I can write the values into a Postgres / Timescale DB and don't have to use InfluxDB.

After that you can do funny things like this in Grafana again ;-)

[DurgNomis-drol]

Yeah, you are right about the week thing. I don't think we can do anything about Toyota's API, but actually i just spotted a problem with my code. Because pendulum starts it's week on a Monday, there is a possibility that we request the wrong information. But as far as i can see, we can change pendulum to use Sunday as start of the week. I think it is best to follow Toyota's logic to avoid strange issues were you will get incorrect data.

Also the week numbers are also wrong which is a strange problem, i am not sure how to correct this yet. Any suggestions?

Nice, i have not (yet) gonna down that rabbit hole. 😆 But it looks very interesting what you are doing with it.

[DurgNomis-drol]

Update:

It seems that the Toyota API does not like when doing the first of the month to date, when you are too close to start of the month. The same with week. I am not sure how to solve this in an elegant way.

[DurgNomis-drol]

Update:

This branch is ready for testing. I believe most problems have been sorted out. I have been running it internally for some days now. But i would love your input one this!

https://github.com/DurgNomis-drol/ha_toyota/tree/Code-rewrite-and-new-statistical-sensors

Note: I am already looking to make it compatible with Home Assistants new statistical platform, but i will keep it in a separate PR.

[CM000n]

Thank you so much! I will definitely test this! May I already ask where this design decision comes from Due to this, this integration will show last month stats instead until new information is available? In my opinion this is not good. Suppose someone would not drive for a month, then he would be shown throughout this month the value of the previous month. In my opinion, this is simply wrong information. Wouldn't it be better to just show "0" or "unavailable" as value for the current month?

[Joonaskaru]

Hello!

Updated. I like the statistics, but if anybody has ideas on how to visualize it then please let me know. I am somewhat of a beginner in this so all recommendations are welcome.

I would like to make something of the attributes but i lack the skills to create. Having a Hybrid then i am more interested in next parameters

1. EV distance
2. Cumulative EV distance vs cumulative total distance
3. Fuel consumption. create an estimated fuel cosnumtion sensor from distance and weekly fuel consumption average or something like that. Idea is to have an amount of how much the car consumes gasoline over time. I am aware of the accuracy issues but i do not mind the difference.
4. Total fuel consumed field, Is this the fuel that was consumed during the period?

[image: image.png]

[image: image.png]

On Wed, Aug 4, 2021 at 8:12 PM Simon Hörrle @.***> wrote:

Thank you so much! I will definitely test this! May I already ask where this design decision comes from Due to this, this integration will show last month stats instead until new information is available? In my opinion this is not good. Suppose someone would not drive for a month, then he would be shown throughout this month the value of the previous month. In my opinion, this is simply an wrong information. Wouldn't it be better to just show "0" or "unavailable" as value for the current month?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/DurgNomis-drol/ha_toyota/issues/12#issuecomment-892828732, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABWTZXKJZB4P3FFT3J4RC3LT3FYHTANCNFSM4ZOOMQVQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

-- With best Regards / Parimate soovidega

Joonas Karu @.***

[DurgNomis-drol]

@CM000n Yeah you are right. Right now it is a work around for the API. (Toyota's, not mine.) What would you preferer? 0 or unavailable? Or something else?

[CM000n]

Personally, I would prefer "unavailable" as a value, as it is a bit closer to reality. As long as there are no values available from the Toyota API for a current month, they are not available and not "0".

[DurgNomis-drol]

@CM000n A fix have been pushed to repository. Now sensors will go unavailable until new data exists. Attributes will be display zero instead.

I can unfortunately not test this behavior until next week of course 😃 (I am not that confident in my coding skills yet)

[DurgNomis-drol]

@Joonaskaru Better you open another issue with those questions when this is merged. This more intended for testing.

[CM000n]

I installed the updated component from the test branch once. It looks very promising so far. 😊 I will now also observe the behaviour when the week changes.

A quick note on "Total_fuel_consumed". I think the term is a little misleading. As far as I know, it is not the total consumed fuel in the respective period, but the average fuel consumption per 100 km. The Toyota API itself seems to output this as a total fuel consumption, but perhaps we can at least output it as "Average_fuel_consumption_per_100km" for Home Assistant to avoid confusion.

On the other hand, I would be happy if I only needed 5.5 litres for the 4600km this year 😀

[DurgNomis-drol]

Haha 😆 I would also love to buy one identical to yours if that is the case.

Lets rename it to Average_fuel_consumption and i will add /100km as the unit. I want to keep names as short as possible, so people don't get strange problems in UI. This is my personal experience. Sentences in English usually becomes a lot longer i Danish.

There may still be some problems on the first of the week/month/year, but should fix it self on the 2nd.

[DurgNomis-drol]

Just pushed an update:

• Changed Total_fuel_consumed to Average_fuel_consumed.
• Handling Type error when an update fails with device_tracker
• Sensors should now show no data on the first of each week/month/year.

There should only be minor issues from now on.