I have the same feeling… I guess the developers are not getting the notifications from the opened bug reports.
Respectfully, these are (typically) volunteers working for free. They may have other life issues going on or they have other items that they feel are needed more by the community. This isn’t to say that your reported issues aren’t important, but due to the limited resources are probably pushed down a little.
For your INNR issue, there is the possibility of creating a custom quirk for the device until support is added in ZHA or by submitting a request at the ZHA Device Handlers project repository on GitHub.
2 Likes
it might sound harsh, not intended to attack developers, rather to counterargument instead:
they have time to break things but have it no more to fix, right?
Besides inevitable bugs that might happen in sw development, we face changes that shouldn’t be executed without acknowledge from some form architecture committee. there are code reviews, and afaik at least in the past some of changes have been rejected as not aligned with the project strategy. In such cases it’s not the original developer who is accountable for the change.
I simply cannot believe that a random developer can do random change to HA.
1 Like
First issue you got dev response from agners. His last input was If you want something fixed, I need to exactly understand under what condition something is misbehaving, so that we can reproduce and fix it. and crickets afterwards. How are devs supposed to fix things without a way to reproduce the issue? (they can’t)
Second issue you wrote in the wrong area, frontend issue vs backend issue. You also deleted the entire issue form, so the bots couldn’t triage it and it went stale as a result. (Lesson here, don’t delete the form, fill it out completely).
3rd issue, there’s no information there. What are we even looking at? Blink is ran by 2 volunteers, they likely ignored your issue instead of asking for more info. And by the looks of it, I had fill out the form so that it would triage it properly… notice the “Petro31 added integration: blink”. That means you didn’t take the time to fill out the issue form.
4th issue, could be a legitimate issue. You filled out the form this time, however incorrectly. mib fixed it, however there’s still little to no information. Just a circle highlighting lifetime used being empty. Not much to go on there.
5th issue is triaged incorrectly. You listed it as system health. I’ll go ahead and fix that.
6th issue is against zigbee with very active developers, it will get looked at however take a look at the bot notes and make sure you provide all the information the bot is requesting.
9 Likes
If they are volunteers, they are not obligated to fix anything they accidentally break. That’s what it means to volunteer. So yes, they have the time to “break” things but may not have the time to fix it.
The PR process is long and painstaking with multiple code reviews. There’s not much else that can be done without testing on live hardware… which the code reviewers likely don’t have. The requirement is that any new code that’s added has test cases that cover 100% of the added code. This is to reduce bugs and issues, however sometimes things slip through.
By all means maxym, try your hand at making a single PR. You’re always here to side with people bashing the devs, lets put some money where the keystrokes are and push a PR through to the end.
9 Likes
Frontend needs user testing as it is difficult to cover via test cases. As noted earlier, 2025.12 and Markdown is a good case to learn from where changes to a ‘core’ Frontend element (ha-markdown → hui-markdown-element) for Assist feature, created a lot of Dashboard issues unrelated to Assist.
No developer or reviewer can predict 100% of issues from review and/or testing. However improved testing and review could prevented some of the issues of 2025.12 and Markdown.
5 Likes
I feel like this is a fair criticism, but at the risk of going off-topic that could open a can of worms.
- Are these user-testers more volunteers?
- If so, what do they do if they’re all unavailable?
- Would we push back the change or push forward?
- What if no more user testers step forward/the quality of testing isn’t what we are looking for?
- Would HomeAssistant need to provide a test script, and if so who’s creating and maintaining that?
Granted, some of these could have been thought of already (and again, I am not knocking the idea I actually like it), but the project would have to tread carefully to avoid creating more issues.
Specifically what I meant here is in general that auto script testing does not occur in Frontend. But maybe it should but that is indeed another topic to delve into.
No different that many of the devs being volunteers. So the more the merrier for polishing the product.
Same, no dev volunteers means no product.
Not to be specific, but there are many cases I am aware of where volunteer user test input (some myself) has meant improvements, fixes, or even reverts prior to and/or during beta.
Same if no more devs or the quality of devs is not what makes for a good product.
As per my earlier comments on Markdown, some specific test focus can be highlighted in the #beta discord.
2 Likes
Firstly, he didn’t ask to me. It was to another comment to another subject.
Everyone can reproduce what I wrote in the report. HA is flooding the DNS requests by no reason. Just look at your DNS requests.
This could be managed on the bug report rather than marking them as “Stale”.
Come on, the screenshot says by itself, did you really understand the issue there? 
You just need to read what I wrote above the screenshot.
Already reported in 2023:
Let’s be honest: HA must give a break and focus on bug fixes rather than releasing a new version every month.
A 6 month “Bug fix marathon” could be a very nice option to reduce those 2700 bugs opened, instead of releasing new versions.
2 Likes
You could always submit a pull request and help with the fixes 
7 Likes
Ignoring the users and saying to fix the problem by themselves won’t work.
I don’t think that’s the case. There are tons of examples where users have been heard.
The problem is rather that everyone thinks their issues are the important ones and should trump everything else, while (for the most part) using a free product.
This point will forever be true for HA: If you care enough, and have the skills, you can jump in and help. It’s not an unreasonable ask.
That said, a bug fix sprint once or twice a year might be quite nice.
13 Likes
And most of those issues don’t have enough information or are for integrations without code owners.
Again, HA is largely volunteer based, the only way to reduce that number is to get more volunteer devs. Bitching about volunteer devs is the most entitled position anyone can have. This is a community, not us vs them like you always make it out to be.
as a volunteer myself, I largely ignore the people who bitch about devs… many of my peers do the same.
14 Likes
Doesn’t make sense to stop this crazy monthly releases and focus in a Bug Fix Sprint?
No new features, just bug fixes.
I never saw a single bug report bitching devs. Ignoring bugs is not a good approach.
2 Likes
No, because it won’t fix bugs in unowned integration and most people don’t own the devices for every integration. You can only fix what you can work with.
Bugs aren’t ingored, combative individuals are likely to be ignored. That’s the thing, if you volunteer, you have the choice to ignore assholes.
And I wasn’t referring to bug reports, I was referring to spending the majority of posts on the forums bitching about the devs.
8 Likes
You are oversensitive.
I’m not aware of bitching devs. But yes, there are negative voices about development or (design) decisions. And it’s completely natural. Actually, it is surprising that one expects no criticism of broken software.
It’s naive to think it cannot happen to volunteers, especially if it impacts a pretty wide range of users.
Such a development is about responsibility and accountability. Not only about writing lines of code.
3 Likes
This coming from the guy who was banned for a couple of months because they badgered a developer. Sorry, I’m not being over sensitive. We protect the developers from users. There is less than 3000 volunteer developers and an estimated 1 million+ users. Retaining developers is a high priority. Retaining always-complaining users is not. It’s the boy who cried wolf, but replace “crying wolf” with “constantly complaining about development”.
22 Likes
Genuine question, because I have only been involved in bug reporting etc. to a limited extent, but is there no process to mark reported bugs as “not enough info” or similar and automatically close them after X days? Or, well, I guess I’m suggesting maybe this would be a good solution for both the users and the devs (I can’t imagine it’s a great feeling for devs to have so many open bugs out there).
3 Likes
Yes, there’s a Needs more info tag.
By default there’s a bot that will mark issues as stale if there’s been no activity for 3 months. The issue then has 1 week for anyone to reply for it to remove the stale flag.