Woops I didn’t see this WTH post with much higher votes! I will add my thoughts on how I would like to use multiple lists here:
"Why can’t we have multiple lists? Are we out of space? It would be nice to use the “Shopping list” as a To-Do or reminder list, that is able to hold multiple lists.
I would like to have a morning list that gets checked off as I do my morning routines, an actual shopping list, and an evening list. Each that get controlled, edited, updated, and reset at different times by HA.
With multiple lists I could have a screen showing an “Active Items” list for example that shows dynamic tasks that still need to be done. Such as moving the laundry from the washer to the dryer before it gets smelly. (After automatically knowing the washer finished with my power monitor for example.)
Having only 1 list really limits the possibilities. The next “step up” appears to be using something like Grocy. That is a very large step up in complexity, for just needing multiple lists HA can mess with.
Given the various threads I’ve seen related to this recently I’ve been thinking we just need a generic ordered “list” helper that is distinct from the drop-down helper which is the closest I can think of to this in the currently implemented helpers.
Status of that helper should probably be the number of items in the list.
A generic list helper would be nice but I would like something that can be updated and edited by the end user in the front end like a shopping list but also generates events with every update and can be consumed / iterated through in an automation.
Chore / Shopping list updated? Generate a notification to X if the list has gotten longer or shorter.
Change the watering schedule zone list to exclude the garden as it is now out of season and we don’t need that zone turned on again till planting season.
Lists that are easy to change and update ether Text or Object lists would be great for many automation options… Maybe if the garbage can lids nolonger close the “take out the trash” chore gets added to some ones chore list? Maybe if the batteries are low in some devices you add a “change / pickup CR2023 battery for X device name” to the shopping or chore list.
Could think of the revers as well, could have automations inject items into the shopping list or daily chore lists based on
Can’t you accomplish all this with input_selects? They have a list in the backend and you can iterate on the options with jinja filters. If my wife asked me to create multiple shopping lists for different zones, with the ability to send notifications when nearing a zone, this is how I’d implement it today.
To be fair, I didn’t know there was a built-in shopping list. But looking at it I’m not even sure I’d use that rather than an input_select. The only downside I see is that there’s no frontend so you’d have to implement it with an input_text entity yourself, and it would be difficult to add “completed” checkboxes rather than just removing an item from the list.
I agree with the above, we should have instead of a shopping list a Multiple lists manager:
Id love to be able to set up multiple lists with reminders for multiple shops so whenever i go to a specific shop or place (that i dont go often) i get a reminder through the zones option; but also would like to make a chores list / to-do list for reminders that i can fill up using stt.
For example i have synced my shopping list to todoist and todoist to alexa so whenever i input items through my house echo devices they show in my alexa / todoist shop list / HA shopping list and vice-versa.
Both Alexa and Todoist have the option to also add a to-do list but im not able to replicate what i did above because we cant use more than one list in HA.
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.
It would be nice to use the “Shopping list” as a To-Do or reminder list, that is able to hold multiple lists.