Ooo! I can help with this one!
I picked up a Jabra Speak 410 (Just a basic USB speakerphone), and plugged it into my raspberry pi, and the set up the Assist Microphone Add-On, along with the usual Wyoming/voice assistant pipelines/openwakeword etc, and it’s a working voice assistant for basic commodity hardware.
Thanks @madelena and @jenova70 for sharing these insights, the product manager in me is super happy to get that level of structure and overview from my favorite (and only 
) home automation platform. I saw in the blog post that collaboration/input from other product people is actually something you could make use of? Then I’d be more than happy to contribute!
As a start maybe some questions and ideas around the content you provided so far:
NorthStar: I love the HomeApprocalFactor as a Northstar (as I have the same topic in my own household, and in the one of my parents), but I’d like to understand better which metric you want to use to measure it, and how. Qualitative feedback via multiple surveys over time? Or number of different accounts per HA instance as a sign for more users per household? Accounts who trigger actions vs accounts who only consume information? …?
In line with measurability: is there somewhere a documentation which data points the anonymous usage stats already capture today? And how good is the current percentage of instances that allow those stats to be capture? I could imagine that if the usage stats would cover insights into the HAF, but the number of instances who allow them are low, a nice little communication campaign might motivate people to switch it on.
Personas: I’m not 100% sure which personas you had in mind when putting together the current roadmap. From reading the intro around the HAF, my guess was that planned enhancements would directly target the people who are not the main admins of the HA instance, but the other members of their households. With one exception though (improve assist capabilities), all other items in the roadmap target the person that maintains the HA instance. The impact on the other people is therefore only an indirect one. Making dashboards more customizable does make it easier for the person who BUILDS the dashboard to create dashboards for the others to USE it, I get that. But I could think of various things that would have a direct impact on the non-admin-users, and therefore a more direct impact on the HAF. (better error/fallback messages when an entitiy isnt available, simplified “hey, we updated your HA app, these are the tons of code changes we made” notification in the companion app, making it harder to get lost in sub-menus, …)
To speak in personas from my own experience (cliched, but true, I swear):
John is in his mid-40ies, aging nerd with a background in tech, likes to tinker and has a preference for “whodunit” movies. Other apps and tools he uses: remote desktop app, android tasker, resistor color code identifier, spotify.
Jane is in her mid-40ies, lives with John. Likes to go for long walks in nature, has a background in art and works as a coach. Other apps she regularly uses: spotify, google calendar, public transport connection infos.
Margarete, mid 70ies, Johns mother. Loves meeting her friends for breakfast and a chat around the coffee table, riding her ebike, and watching linear tv which she picks by reading a paper tv magazine. She uses her phone to play mayong and to watch photos of her grandson that she gets via whatsapp, and to occasionally check the data from the weather station that John set up in his parents household via a dedicated HA instance. Margarete doesn’t have a clue what HA actually is.
Anyway, I’ve got tons of ideas, and time on my hand, and cannot contribute by coding (for lack of abilities ), so let me know if you’d like to talk more around product-stuff, I’d love to join!
…and to add a few thoughts around automations:
Automations in the end are the underlying technical representation of a real-world “homeflow” (I don’t like workflow there as a word 
), or pain point, or need.
Example: “I don’t want to waste energy when I air out the bathroom in winter”
Automation representation of that: “if the zigbee magnet window contact opens, switch off the zigbee radiator walve”.
Improving the organisation and creation of automations in their current form does help the John-Persona to get things done quicker for the Jane- and the Margarete-Persona, but for Jane and Margarete themselves nothing changes => little to no impact on the HAF northstar.
To just quickly scribble an idea which I didnt validate at all, but still:
How about we give HA the concept of self-definable “household entities”. These entities have a represenation in the real world, but can be made up of multiple underlying “tech entities”. Example: the household entity “fridge” might under the hood contain a wifi power meter plug, a zigbee door contact and a zigbee thermo sensor. Jane and Margarete don’t have to (and don’t want to) care about zigbee and wifi and magnet contacts, andandand. But having a “fridge” entity lowers the threshold to create your own “Hey homeassistant, remind me to close the fridge when it’s open for more than a minute” homeflow. On the side it would tie in nicely with the whole assists voice control landscape…
We already have the concept in rooms, but in my opinion more granular entities could help.
Anyway, enough braindump for today, let me know if you’d like to continue the conversation, inside or outside this thread. I’d love to
To be fair, that used to be a thing in the past. Automations used to be powered by Almond (I think?) and you could simply enter the above description (using “valve” instead of “walve” 
) and it would create the automation for you.
I guess we lost that when we moved to Assist. Maybe it’s time to reintroduce it to make things simpler when creating Automations.
My point is: when it’s about making things easier for people who are not the primary admins of a HA instance, then the whole world of what “we” currently see as automations shouldnt need to play a role. It’s not going to help my mother that she can write a sentence about zigbee and valves ( 
) that turns into an automation yaml.
Personally I don’t really think it’s a realistic expectation. There’s way too many technical details behind even simple automations to consider. The technical naming is the easiest part to understand really.
Considering your example:
“I don’t want to waste energy when I air out the bathroom in winter”
It’s really not as simple as what you said:
“if the zigbee magnet window contact opens, switch off the zigbee radiator walve”
In reality, what people would expect from such automation is much more:
What I’m trying to say, when building automations, you need to think in a structured way, analytically, considering all things that may affect the automation, all possible outcomes and all possible results you want from it.
I don’t think this is currently possible to automate even with an AI, considering it would have to be near perfect to make sense. Automation that produces wrong result even only 5% of time is worse than no automation.
I fully agree. In the end the point I wanted to make in scope of the communicated roadmap: how it’s currently planned to optimise working with automations is improving things for the people who maintain the HA instance, but it doesn’t have a direct impact on the HAF northstar.
The experimental sections launched in March are really nice!
But this new abstraction of grouping cards could offer way more, to enable us creating dashboards that fit various screen sizes:
I also want to second the idea mentioned earlier by @ivanfm to natively support card reuse. Custom Decluttering and Button cards are good starting points
I see what you’re getting at and read your thoughtful comments. I think there is an important line of thinking there.
Just had a quick thought about this one point. Is this something “labels” could be used for? It may not be their exact intent, but in effect it provides a user configurable way of grouping entities.
If you use labels for other cases too your household could determine to prefix these “device labels” however you thought made sense. I.e. “D-Main Refrigerator”.
I get where you’re going with this, and depending on the usecase and how far one would want to dive into the household entity concept, it could be a start. It would be limited for certain scenarios though.
Let’s say I create the label “fridge”, and I would add that label to a zigbee temperature sensor, a magnetic door sensor, and a wifi power meter plug. This would make it easier to search for devices belonging to a label, and I could simplify dashboard creation e.g. (“Give me a new entities card with all devices that have the fridge label”), but it would miss one layer of abstraction.
I don’t want to know the status of the door sensor that is linked to the fridge label. I want to know if the fridge is open or closed. So the household entity concept would have to support one abstraction level for the real-world aspects of it. Going with the fridge again: I would need a layer that tells me if the fridge is open, no matter which (type of) sensor underneath provides that information.
I’m coming up with this as I go, so don’t be surprised if this isnt bulletproof, but I could think of something like this:
top layer: household entity (e.g. “fridge”)
middle layer: standardised and custom-generatable abstract properties (open/closed, temperature, energy costs, …)
tech layer: the sensors and devices that “fill” the abstract properties of the middle layer so to say.
This would e.g. allow to create a standardised “fridge” card for HA, which would be usable by not so techy endusers, even to build new dashboards. The tech layer underneath would still be set up by the more techy main admin of the HA instance.
And going beyond dashboards, this would also massively simplify the definition of new automations by non-techy people. They would then interact (in HA) with real-life concepts and things like fridges, not with weird techy things like the 0/1 status of a hopefully correctly named and labled zigbee sensor
I just realised that HA “almost” has something like that already. Template sensors and switches are going in that direction (you can define the type, the name, the unit, the icon, the underlying “source”, …), but: it’s always only one sensor or switch each. So if the template concept would support “parent template entities” which could group multiple template sensors and switches, then we would basically have the whole package Interestingly enough they already seem to support a base-level unique_id (Template - Home Assistant), but I’m not sure if this goes in the direction I’m thinking of. If so, then maybe just adding type (fridge, …), icon, name etc would be enough. But this is now beyond my detailed coding skills.
I do realise though that this is way outside of the scope of the original roadmap post above, so I’ll leave it with this I think
I think what you are looking for is a device. That’s what groups all entities related to the same device.
Sensors from different integrations can already be under the same device. Though I don’t think there a simple way to move things around or create your own devices.
Nope, there’s no easy way to do this. It’s a pretty popular feature request IIRC.
Just dove a bit into the developer documentation, and it’s indeed pretty much exactly what i mean. Would be awesome to be able to create devices manually.
I’d like to know how AI/Machine Learning is being used with all the data gathered through HA Analytics. Is this data being mined to direct the improvement of HA?
There must be some patterns in all that data to identify some common combinations of integrations that could be used to put together some pre built automations that would benefit a large number of users.
I’d love to see how the data being collected is being used to benefit the community.
Perhaps more than 1/3 of users would opt in if it was clearer what impact it has on the roadmap.
Hah, it’s not just New Zealand. I live in Canada and had the same problem. Seems to be a general issue with the Whisper model, however. IDEALLY there would be a (better… which may mean larger…) language model integrated with the voice recognizer that could correct such things based on context.
Two possible short-term fixes:
Why continue using passwords? Isn’t 2FA and Passkeys a better path forward?
Not for me.
Please. I would take this before the grid.