As you know HA become a tool for not only the advanced users, but also for those who are not that well trained for the dark side of the internet.
I would propose to figure out a list of requirements (couple hundred, thousand) of which HA would decide on a scoring for each product/manufacturer regarding the products the user is using or planning to use. This score requires to set some standards focusing heavily on security of the IoT devices out there. I belelive thats the biggest challenge an average user has now. We should not only focus on the new and shiny (UI and other features) as HA reached a critical mass, but rather focus on the security. We should make sure we protect the users of HA from all sides and kinds of attacks.
A possible attack vector would be if the IoT device is using unsecure connection, available without authentication, open to the internet, etc.
This scoring will help the everyday user to decide whether the device is worth to integrate it and use or not.
There are multiple issues to be aware of in that suggestion.
The list would need to keep track of,
the firmware version
the hardware revision
the configuration, both the ones done by the user, but also the ones down by resellers of the many white label products
the users network setup and devices
the versions of the users network devices
the integration chosen
the version of the integration
Many of these information would be harder to find for an inexperienced user than to come to the forum and ask or search with Google and it would be nearly impossible to keep a list updated unless it is crowd-controlled.
I completely agree, but on the other hand most of this should be visible by Home Assistant.
At this point we should lay down one the many standards:
An IoT device should be able to respond to a special query made by home assistant or any similar device for example with a proper key exchange, token or some other secure way.
This response should contain these information from the device itself. We should make sure all IoT devices are communicating this information. HA has a huge community and therefore this massive amount of users might have an impact on these implementations.
To be honest at some point whoever would not follow this predefined standard would be considered untrusted anyhow.
This feature must be well thought as usage of these information like versions can be used for the wrong reasons as well.
This is one part of it.
Second part is actually identifying the proper versions.
To me this feature would be a guide in the first run. It would be an indicator about known issues which are not solved or known issues with known versions, etc.
Finding the proper combinations would be as hard as filling up the z2m with profiles. It will take time and has to be done one at a time.
I would start small and define an MVP for it.
The topics mentioned by you are important and can be solved in the long run, but what I am really concerned of is the personal preference and opinion. This is something I am personally having trouble with.
Do you trust ewelink with the cloud connection or you prefer esphome on the sonoff devices with direct connection? [for example I would say direct without cloud is always preferred due to privacy and availability]
What score would your implementation get if you publish your HA to the internet directly? (a little twist to the scoring)
I am happy for an open discussion on this with some brainstorming.
I am almost certain security of IoT is something everyone is neglecting, though it should be one of the most important topic.
The HA userbase is not a uniform group.
It is a group of users that use a huge amount of different brands and thereby only becomes subgroups of those brands.
If you want to use the HA userbase’s amount of users to anything, then start your crusade by making theusers drop Tuya products.
Tuya products is hell in this sense, because manufacturers make a standard product, then find a Tuya codebase and make some correction and give it a new version number and flash the product.
The codebase chosen is not always the newest and when they give it a new version number, then they hide the original codebase. This means you can risk to find two or more physical identical products with the same firmware version number, but in fact the firmware is based on different codebases. one might be okay and the other might be bugged.
Knowing the firmware number is not enough. You would need to analyze each and every device to figure this out and you would never know if you already tested a product elsewhere, because of the ways chinese manufacturers copy each other.
So the above kills the idea of using firmware version numbers for anything.
Hardware revisions require the user to open up the product case to learn this and maybe be able to somewhat read electronic layouts, which is not something many inexperienced users want to do.
And the configuration of the device depends on what is possible in the firmware and hardware, so not knowing the 2 earlier infos makes this part moot too.
Knowing the versions of the users network devices can run into the same issues as with Tuya products, so only general network advices can really be given beforehand.
Left is the work with integrations and here it is up to the developers. Some are core integrations and will be able to be and also already is handled somehow, al though there is examples of core integrations that have no maintainers attached, so bugfixes are a long process.
Non-core integrations are not possible to handle, because the developers often do the work voluntarily and can sometimes just go missing for periods or even forever.