[Enhancement] Additional order history

[mdolejsi1]

Dobrý den,

bylo by možné přidat do integrace statistiky nákupů?

• měsíční útraty již máme

Přidat

• roční (atribut pro volbu roku)
• celkové (za všechny objednavky)

Děkuji

Good day,
would it be possible to add purchase statistics to the integration?

• we already have monthly spending
  Please add
• annual (attribute for year selection)
• total (for all orders)
  Thank you

[eMeF1]

Plus breakdown by categories.

[dvejsada]

This will take some time to implement. I would like to implement it differently than to call each time complete history of all orders (response takes a long time from server) and recalculating the amounts after each call. Probably I would store all order data locally in json or CSV and only check for new orders.

Please let me know if you have any implementation ideas.

[eMeF1]

I was wondering how you plan to design that.

Instead of using a CSV file, how about this:

• Track the last fetched timestamp
• Query only the new orders since that timestamp
• Add the new totals to a stored cumulative value

[eMeF1]

You could also expose the last fetched timestamp as an entity, allowing it to be manually edited when needed — for example, to re-fetch data starting from a specific date.

Alternatively, you could create a service that retrieves the value for any date range, then manually update the cumulative value entity.

This would mainly be useful for initializing the sensor (e.g., starting from 2025-01-01) or correcting the data if something goes wrong.

For ongoing tracking, I’d rely on the utility_meter integration to calculate monthly, yearly or any other deltas from the cumulative sensor.

[eMeF1]

With my last commit, it should now be relatively easy to create a yearly or total spending sensor since the integration is aware of which orders have already been added to the metric. This way, it doesn’t need to fetch all the data for the given period. Obviously, only orders since the integration setup would be considered.

I was also checking how difficult it would be to break down spending by categories, and that would require many more API calls. Essentially, we would need to retrieve the category for each item in the order. This could increase API calls by up to 1000%. One way to optimize is to cache products and their categories and fetch data only for items that haven’t been processed earlier.

@dvejsada, if you want, I can take a look at that.