Improvement: Autogenerate sensor for each Product/Chore/Task/etc.

[lukas947]

It would be nice, if each Product, Chore, Task, or equivalent was a separate sensor. All can be arranged under respective Device (e.g. Grocy Products) and disabled from the start, so it's possible to focus only on those elements of Grocy needed for automations / scripts. Consumption or tracking services can then use hass entity_id instead of GrocyID. This might require some architectural changes.

[isabellaalstrom]

Hi, not sure what you mean, they're already separate sensors. Or do you mean that every chore for example should be it's own sensor?

[lukas947]

Hi Isabell,

Yes, I mean every domain (product, chore, etc.) element should have it's own sensor. For instance:

Grocy Products

• Cat Litter (sensor.grocy_product_cat_litter)
• Windshield Wiper Fluid (sensor.grocy_product_windshield_wiper_fluid)

Grocy Chores

• Clean car (sensor.grocy_chore_clean_car)
• Water Plants (sensor.grocy_chore_water_plants)

Then service grocy.consume_product_from_stock can accept the entity_id of product sensors instead of GrocyProductID.

Use Case 1: The process for creating automations in HA for triggering consumption/tracking would be easier than keeping track of what is what ID what manually. It would be very time consuming process to manually assign a NFC or QR Tag for every chore, as well as preparing automations for consumption.

Use Case 2: Showing only relevant stock in UI in another card, e.g.:

• Sensor card for stock of Windshield Wiper Fluid in Car View
• Entities card for last tracking of chore "Water the Plants" in Flower View It can be currently done with custom:flex-table-card using filter, but i did not figure out any other way of showing the data from current sensors.

Use Case 3: Use HA notifications if specific product goes bellow min stock, or chores were not done in time.

[isabellaalstrom]

Yeah, I see what you mean. But since this is a very changable structure (adding and removing stuff regularly), I don't think this would be a feasible change to do. It would also generate SO many sensors.

[lukas947]

I agree... However I'm not sure how often is the core structure of Grocy changing. It depends on ones implementation of the logic.

Too many sensors could be manageable if they were grouped under different devices, and disabled by default.

[isabellaalstrom]

I will not implement this, sorry. I will not flood HA with sensors.

[isabellaalstrom]

I have changed my mind! :D This will be an acceptable addition. However I will not develop this myself, but I will code review and accept prs with this. It will have to be opt in, so that the sensors would be disabled to start with.

[lukas947]

Thanks for the re-consideration! :) it might be a bit of a bigger change, and I fully understand this might take time. I'm also not able to develop this on my own, but i can participate in the design/architecture phase, as well as functional testing, or other improvements.

[Tenn0]

Hey, currently im working on exposing every product as its own sensor. Ive made some local tests with polling directly from the REST api and gathering all infos i care about and storing them inside a nested dict. the first dict contains the products, the products itself are also dicts with infos (product_id, name, amount, unit_of_measurement, location and best_before). since im a python newbie im wondering where you store the infos in this component. i mean, if you store them as json, i could split the dicts (if you save them as dicts) into its own sensors. thats the first part i need some help/explenation. the second is, when you execute the services to add or consume products, do you pull all data for all products or just the product you added/consumed from and then just update the infos in home assistant?

[thost96]

Hi @Tenn0, any news on this? I would also like to get each product as a sensor, so building a dashboard using auto-entities would be much easier than fiddling around with the product's attribute. Thanks!

[pusur333]

Any news? :)