I agree, but I don’t think it should be limited to just things like shopping or to-do lists.
To me, the ideal component would be the select component but allow multiple values. The component would store the items as a dictionary attribute with each key being the items and the value being a boolean for if it’s checked. This would allow services and scripts to quickly look up what’s checked and what isn’t checked. It would also have a service so items could be checked off programmatically.
An example use case could be security cameras with object recognition where the user chooses which types of objects should be recorded. Instead of having a dozen switches to enable detection of humans, dogs, cars, werewolves, giraffes, Santa, bikes etc., you could just have a single entity with items enabled.
My personal case involves a mechanism I created to handle our Hue and Ikea switches. Since I hate opaque and hard-to-adjust automations, I created a dashboard that allows the user to select what device is controlled by which button of the switch and what actions to perform. Behind the scenes, a handful of automations, scripts, and template entities determine how to perform the actions required. It would be very useful for me if I could allow the user to select as many entities as they wish instead of either being limited to a single entity or requiring the user to create a group entity for the custom setup.
This is very late, but as nice as it would be to have a generic list that could be used in playlists, queues, and whatever with arbitrary data, it is way too big of an extension of scope compared to the current demand of just having multiple lists for separate things.
Pointedly I just want multiple lists purely so there’s a list for things to shop for and a list for home maintenance tasks populated by automation, because the alternative is using a third party to manage the lists which goes against my plan to have a landing view to glance at vitals and anything that needs attention. I prefer to not have to check multiple places if I can avoid it.
So the simple extension of scope is just being able to have multiple, todo-like lists with simple text just like how the current integration works, and rename it to “Local Checked List” or “Todo List” since it can be more than just a shopping list, and a shopping list is a kind of todo-list anyways.
Later we can decide to create an integration for advanced usage. And maybe I should try my hand at making it happen, though I haven’t developed for HA before but I do have some Python experience.
Since home assistants primary function is home automation, the reason I suggested more generic / expanded types of lists is that the current shopping list is extremely narrow from an automation point of view. The Calendar object has become more useful for scheduling, and more date / time based options where just added in general.
I think LISTS would be an excellent area where instead of having a UI only string based shopping list we could have more complex list types where shopping is just a TYPE of list .
So going back to the original request, at the VERY least it would be nice if shopping lists, became multiple named lists, even if they only had the same functionality.
Booth google home and siri ecosystems support named lists already, it would better align HA lists with the functions of other systems, especially if we want to have voice support.
“Add [eggs] to the [shopping] list” is a function in both ecosystems and should be an intent that can function in HA. Where LIST is a key word not a specific list type.
I would love to add other things in the future like “add [tent] to the [camping] list” Or “add [blinding lights] to the [play] list.”
I did give a bit more thought about it while I was out and about today and I ended up with the same thought of it being a different type of list. Like [Checkbox, Textbox] or [Checkbox, Date, Textbox], for todo/shopping lists and tasks with deadlines. But for now just being able to have multiple checkbox’d text lists would definitely be useful now and would be easier to implement in a short amount of time.
I don’t really want to figure out how service calls would change, deal with a list of multiple types, and the additional complexity of how to deal with all these types at this time, but I’ll keep it in mind when refactoring to make the behind-the-scenes data structure ready to do such a thing and someone else could do the work or me if I want to dedicate some time later.
Hopefully during the weekend I’ll crack open an IDE and get myself introduced to developing for Home Assistant. Plan being:
get the current integration to support multiple lists,
rename it to Local List like Local Calendar,
some upgrade logic to convert existing shopping lists to a new list named Shopping List, then
submit a PR.
It’ll have some burden to get people to update their automations to specify a list, but at least their existing items would be preserved.
I’ll share what I considered when I wrote ActivityManager which heavily borrowed from the ShoppingList integration.
If I wanted to do multiple Shopping Lists, I would add a new field called “list”. Then I would update the Shopping List Card to require the “list” field and it would filter that card to Shopping List items matching that name. Now this doesn’t solve some of the broader use cases here, but the core need of a list for Store1, Store2, and Store3 would be supported.
This is essentially what I did with my integration (in addition to a bunch of other changes) and I really like it.
I have another use case: I currently store my recipes in HomeAssistant in an attribute on a template sensor.
While looking for a way to display the ingredients with checkboxes next to them, I discovered that the Shopping List integration is the only way to do this (outside of custom components). Unfortunately, I’m already using the shopping list.
While multiple Shopping Lists would fix my problem, I agree that there needs to be a more general solution.
I’ve been seeing a need for general-purpose variable helper entities. These would include various types like string, list and dict (or mapping), and should be able to be updated with service calls. If this were implemented, the shopping list integration could use an entity variable.shopping_list that is the list type and is modifiable from the frontend. Its attributes might look something like this:
friendly_name: Shopping List
read_only: false
variable_type: list
checkboxes: true
Displayed in the frontend, this would appear as a card with a list of text edit fields with checkboxes next to them. When you tick off an item, it should trigger an event like variable-checkbox with data that indicates which variable and list item, and whether it was checked/unchecked.
For my use case, I’d create a variable.recipes entity that’s a read-only mapping, along with a variable.current_recipe entity that’s a read-only list with checkboxes, which is updated whenever a recipe is selected in an input_select dropdown.
Tons of possibilities with these, and it would preclude the need for custom components for simple things like maintaining custom lists.
We want to work towards supporting the most common tasks that people use with other voice assistants. This includes support for multiple shopping lists, timers and weather forecasts
Fairly sure going back to my previous comments we need to get away from “shopping lists” and just implement LISTS, where shopping may be a special type.
Thx devs 