[REQ] Entity Optimization - Rewards

[ccpk1]

Is your feature request related to a problem?

• Yes

Please describe the problem

Now that I’ve built out the majority of features in the dashboard, I wanted to take a step back and evaluate which entities are actively contributing value versus those that may be redundant or underutilized. This aligns with my previous request regarding badge entities and extends the idea to a broader entity review.

The goal is to streamline entity usage and upkeep while maintaining flexibility for those who need specific details.

Describe the solution you'd like

I’d like to propose consolidating three reward-related sensors into a single status sensor to reduce entity count while maintaining functionality. The affected sensors are:

1. sensor.kc_jiri_simon_reward_approvals_1_dollar
2. sensor.kc_jiri_simon_reward_claims_1_dollar
3. sensor.kc_jiri_simon_reward_status_1_dollar

Proposal

• Merge the approvals and claims into the existing status sensor by adding attributes for pending approvals and claims.
• Implement this change over 2-3 releases to allow users time to adjust.
• Mark the old sensors with a deprecated attribute, e.g., Deprecating April 2nd, before removal.

Expected Impact

• For an average setup (e.g., 2 kids × 4 rewards), this would eliminate 16 unnecessary entities, simplifying maintenance and improving performance.

Let me know if this is something you want to consider.

Describe alternatives you've considered

No response

Additional context

No response

[ad-ha]

While I agree we could simplify those sensors, some users may not rely on the dashboard and still want the sensors working.

I will give it another thought, but I heard that some people at HA want to get rid of attributes, so we need to be careful with that, although the community is pretty much against that.

Anyhow, I will consider it, but if we do this, it will have to be a breaking change in just one release, if people get frustrated, at least it will be only once 😁

[ccpk1]

We're in a lot of trouble if they get rid of attributes anyway, regardless of this potential change... 😄

No worries if, after considering it further, you don’t think removing those entities is the best approach. In that case, my request would still be to add the missing attributes—specifically, claim count and approval count—to the status sensor. I think there's just a few others for chore and badge.

From a frontend perspective, it’s a bit of a hassle to track down different sensors when 90% of the data is in one place, but then one or two additional values require querying separate entities. The badge sensor is especially difficult, since I have to go through full transliteration and special character handling just to reconstruct the badge entity name—when all I actually need is the multiplier.

Just a quick aside—one thing I realized is that users of the dashboard won’t be able to rename chores and rewards; instead, they’ll have to delete and recreate them. I’ve listed this as a known issue at the bottom of the dashboard README. The reason for this limitation is that while the integration allows renaming, the entity ID remains the same as when it was originally created. Because the dashboard relies on name matching, it won’t detect the updated name correctly. https://github.com/ccpk1/kidschores-ha-dashboard#-known-issues--workarounds

I’m not looking for a solution on this—just wanted to give you a heads-up in case someone reports it. The first issue they’ll likely notice is that the approve/disapprove buttons may show "None" instead of the expected name.

[ad-ha]

Thanks. I agree, removing attributes is self-shooting on the foot. I believe that will not move forward, but even though, better have it mind.

I will try to get those attributes added. My issue is that I am now getting this growing so much, that sometimes I get lost myself on everything. I try to keep the same structure for everything, so I know where things are, but on a rush (to test things) sometimes I get things misplaced and after need to get it all together again. 🤣

I imagine that with time some users will move into their own dashboard, so they may personalize a bit more, that's why I believe having the sensors is better, but even though, now it's quite easy to pull attributes on the frontend on almost every card, so no need for templating and weird things as before.

I never thought this would blow so quickly and get so many people interested... but is being fun to learn so much and see so many ideas people have about these chore things. Amazing, really.

Let's enjoy the ride 👍

[ccpk1]

Yeah, it has been fun, but my wife is looking at me a little funny when I tell her I'm still working on kids chores. 😄 And I understand a little of what you're saying with it getting complicated. Especially over the last week figuring out how to handle all the special characters and then deciding to tear the whole thing apart to try to support translation... I know the backend is even more complicated, but I've felt a little the same way. Between trying to clean up and standardize after testing, but you can miss one "," in that front end and then be searching for 20 minutes why it no longer works. 🤯

[ccpk1]

Another point about using attributes instead of entities is that anyone can easily create template sensors for any attributes they need, making them available for use in cards. This provides flexibility for those who need it, while avoiding unnecessary entities for the majority of users who likely won’t need them.