From what I’ve read here in this Topic it seems your dislike is very much pointed at sertain users, but you seem to put the blame, or at least the consequences on the whole community.
I don’t think that’s fair. I don’t even know you, or your Apps.
I have ppl here I dislike, or disagree with, I shrug my shoulders and move on..
That’s a valid point.
The question is how we build our perception of a community. If most of the people who actively respond to you are repeatedly negative, humiliating or destructive, while almost nobody steps in and says “I understand your point” or “that’s unfair”, then naturally your experience becomes that the community as a whole has a negative attitude towards you.
I know that forums distort reality somewhat. People often participate because they need help, because they strongly disagree with something, or because they feel they need to defend the platform they love. People who simply agree usually remain silent. They rarely comment just to say that another reply was unfair or unnecessarily hostile.
I understand that intellectually. But even knowing that, it is sometimes difficult not to be affected by the hostility and the almost obsessive defensiveness of some people who repeatedly come after you.
That is also what I tried to explain to @Doekse.
Moderators are often quick to react when somebody repeatedly criticises the product the forum represents. But they seem much less likely to intervene when people personally attack, ridicule or try to silence someone for expressing that criticism.
My experience on another platform taught me something: once even the official moderation starts adopting that attitude, rather than protecting constructive disagreement, that is the point where I personally start wondering whether it is time to leave the platform behind.
And that is exactly what this thread is about. It is a call for opinions from people who may have remained silent until now.
Even replies like yours — saying that you don’t really know me or my apps and therefore don’t want to judge — are useful, because they give me a broader picture than the few very vocal people who repeatedly attack or dismiss me.
If most people who feel differently simply decide that it is not worth saying anything at all, then from the perspective of someone contributing here, positive support effectively becomes invisible.
So yes, you are right: a few vocal users are not necessarily representative of the entire community. But when the quieter majority remains invisible, unfortunately the vocal minority is what shapes the experience.
Hmm, now I somehow get the feelings it’s my fault for not stepping in and babysitting everyone. There’s very little moderation here, and I kinda like that.
If that happens to me (and it hase sometimes) I start evaluating my own kind of conduct. Most of the time I get mixed responses, some good some bad, not just all bad…
I’m gonna leave it at that, I don’t think I can be of any help in this..
Just as a general comment, because this is a good example of what I mean by communication.
I recently mentioned that Home Assistant already supports Matter 1.6.1 while Homey is currently Matter 1.5 certified.
I got criticism for mentioning it.
But nobody replied:
“Matter 1.6 is still very new, almost no devices depend on it yet, so this difference is currently not very important.”
That would have been a perfectly valid counterargument.
And nobody could simply say:
“Homey will support it in November/December anyway.”
because Athom does not publish that kind of clear roadmap.
And that is exactly where a lack of communication makes a company unnecessarily vulnerable to criticism.
If there were a public roadmap saying Matter 1.6 support is planned in one or two months, the whole comparison would immediately become much less relevant. Two months difference on a new Matter version is hardly a major competitive advantage.
In the thread concerned, I deliberately presented the information as neutrally as possible. I did not write “one point for HA” or claim Homey was falling behind.
Part of the reason I mentioned it was simply to see whether somebody knew when Homey would move further — and, indirectly, to highlight the fact that there is no roadmap where users can find that answer themselves.
Criticism is much easier to answer when people know where a product is going.
Silence leaves everyone guessing.
I think that is partly a question of how Homey chooses to manage community apps.
Homey does not force developers to publish their source code, and I actually think that is a good thing. Some developers may be willing to create an app, but not necessarily to make all of their code public.
But the policy around abandoned apps could be different.
For example, developers could be required to provide the source code to Athom under clearly defined conditions, while still retaining full ownership as long as they actively maintain and support the app.
If a developer stops responding to users or leaves an app broken and unmaintained for, say, three months, the developer agreement could allow Athom to look for another developer willing to take it over.
That way, the original developer keeps full control of the code while the app is actively maintained.
But once it is effectively abandoned, Athom could publicly ask for a new maintainer and transfer the maintenance rights under predefined conditions.
Of course, that would have to be part of the developer terms from the beginning. Athom could not simply take someone’s code without such an agreement.
But as a policy, I think it could solve a real weakness of community-developed apps: users would not be left with completely unsupported software just because the original developer disappeared.
@Doekse That could be an interesting point for Athom to look at. In fact, I wrote my Fronius app because the developer of the already existing app no longer answerd my requests.
In regard to Fronius, they are very much on our radar and we are in touch with their team about an official partnership. We’ll most likely also involve Thomas in this process if he’s willing.
Regarding community apps in general, this is exactly why we make a distinction between official and community apps. For most developers, community apps are ultimately hobby projects, and we can’t expect or require them to maintain those projects indefinitely.
Of course it’s great when developers are willing to open-source their apps, and even better when they’re open to transferring them to another developer if they no longer want to maintain them themselves.
We’re always open to feedback on how we can improve things in this area. The huge influx of AI-built apps also raises some new questions about how we should approach community apps going forward. That’s something we’re actively looking into at the moment.
That’s nice to hear — but I assume you are not talking about my Fronius app. 
Thomas wrote the other Fronius app. I originally tried to contact him with questions, never received a reply, and eventually decided to build my own implementation.
His app has not been updated for quite some time, while mine has evolved considerably and now does much more than simply expose inverter data. It also adds statistics, calculated balances and other derived values.
I am not offended by your plans at all.
And just to be clear: when I said that I would not simply hand my code over to another community developer, that does not mean I would refuse to contribute it to an official Fronius integration.
If Athom and Fronius are interested in using parts of my implementation or code for an official app, I would be perfectly open to that.
The other point, however, is exactly where I think many users experience a weakness in the current model.
Athom distances itself almost completely from responsibility for community apps, even though users often depend heavily on them.
I suggested one possible alternative above: keep ownership with the developer while the app is actively maintained, but define a clear process for abandoned apps so another maintainer can take over under predefined conditions.
That is only my idea, of course, and Athom may decide that it doesn’t fit its model.
But simply saying “community app, not our responsibility” leaves users with exactly the problem that was raised here in the first place.
That is not really the same point.
Removing or delisting an abandoned app may stop new users from installing it, but it does nothing for existing users who may already have many automations depending on that app.
My point is about making continued development possible instead of simply removing the app.
And since we are talking about constructive criticism, Home Assistant has an interesting model here.
A community integration can be developed towards a clearly defined quality level and then the developer can actively submit it for inclusion in Home Assistant Core.
So the initiative does not have to come from Home Assistant deciding that it likes a project.
The developer can improve the integration, meet the published technical and quality requirements, build a real user base and then ask for it to become official.
Of course there is still a review and no automatic right to inclusion.
But there is a transparent path from community integration to official integration.
I think that is another idea Homey could consider.
Not every community app needs to become official, but mature and widely used apps should at least have a clear route towards becoming part of the official platform if the developer is willing to meet the required standards.
I am indeed referring to the Fronius app developed by Thomas Houssin, it was the first integration available for the Fronius devices. We’d mainly be looking at expanding it with controls alongside the insights it already provides. But this is ofcourse all dependent on how Thomas thinks about this as well. Derived values aren’t something we’d be particularly interested in at this stage.
In general, we try to avoid adding too many derived values, as it can sometimes become unclear which data comes directly from the device and which values are calculated. Especially adding a whole driver/device for something which isn’t a physical device. We’d rather focus on making sure the relevant information is available through Homey Energy for example. That said, it’s nice that you’ve added these to your app. Having options is always a good thing.
The broader goal here is to bring as many brands as possible into an official Works with Homey partnership. That’s how we’d like to support the platform, the brands, and the developers involved. There are already plenty of examples where an official app is developed and maintained by a community developer working directly with the brand.
We simply don’t have the resources to get directly involved with every community app out there, which is also why we put so much effort into establishing these partnerships.
That’s a clear choice, and as said, I’m not offended by it at all. If the cooperation with Thomas works well, that’s perfectly fine.
My offer still stands, though.
If things don’t work out with Thomas, or if at some point you decide that derived values should also be included, you’re welcome to come back to me.
Those derived statistics and balance values are actually one of the main reasons many users choose my app, so I still think they add real value.
And my offer can apply either to the complete app or simply to specific parts of the code that may be useful for an official integration.
Of course, I cannot know what to do or what is best.
…
I went a slightly different way.
I use Home Assistant as a backup automation system. Homey SHS and Home Assistant share Zigbee devices supplied by Zigbee2MQTT running on a Pi 4.
I use only 10 apps on my Homey SHS. Most of the services I need do run on a Pi 5 and are used by Homey SHS.
The plan is for all devices and services needed by Homey SHS to be supplied by Python scripts, MQTT integrations, HTTP endpoints, and other services running on the Pi 5.
It’s actually not that different, although my intention is almost the opposite.
I currently have exactly three reasons for keeping my Homey Pro 2026 — apart from the fact that I genuinely still like Homey:
For my personal needs, Home Assistant has become the primary system. I find it more powerful, more stable in my setup and, surprisingly, even more readable once automations become very complex. At some point, structured logic with Choose, Scripts and Helpers becomes easier for me to follow than a huge canvas full of crossing connections.
Because I use Matter devices, they can be paired natively with both systems using Matter Multi-Admin. Each controller manages the device directly; Homey does not depend on Home Assistant and Home Assistant does not depend on Homey.
At the moment, my old Homey automations are disabled. But my plan is to create a second, much simpler automation layer on Homey.
For example, my shutter system in HA is far too complex to reproduce sensibly in Homey. But basic opening in the morning and closing at night is easy.
The same applies to heating. In HA I am building logic that decides between TRVs and air conditioning based on temperatures, efficiency and the financial comparison between oil heating and the heat pump. I wouldn’t try to reproduce all of that in Homey.
But something basic such as:
window opens → heating off
window closes → heating on
is very easy to implement there.
Eventually, both systems will have one master switch controlling all their automations.
If HA completely fails, I simply enable the Homey flows.
If HA is still running but has a serious problem, I disable its automations and enable the Homey ones.
The house would then lose some intelligence, but it would continue to function at a perfectly usable basic level.
So for me Homey may actually become something quite valuable: an independent fallback automation system for Home Assistant.
Indeed, the opposite direction
I chose this because I want:
As much control as possible over which devices may access which network segments.
The ability to determine whether any cloud or manufacturer connection exists at all.
Full visibility into the tokens, flows, and triggers in use.
Control over credential lifetime and rotation policy.
To avoid Big Tech wherever possible.
No additional Thread border router, commissioner, or vendor ecosystem.
Given my privacy requirements, I would generally consider Home Assistant to be the stronger choice.
Somehow, my intuition tells me the opposite, but both are capable of meeting the same automation goals.
I still support Homey as a product. That is why I follow along and help where it makes sense. My silence is not a lack of interest, and here are a few thoughts from my side 
On abandoned apps.
That is one route for abandoned apps. Open source is another good one, because if the code is open, ownership can be handed over when the original developer stops. One idea of my own is that if Homey Self-Hosted Server (SHS) were open source, it would give more options 
Agreed. For me, Advanced Flows are easier than writing YAML, because the visual layout is so simple My wish is that Homey and the community find the approaches that work well in HA, so equally advanced things can be built in Homey.
For me it is about community, support and contributing, not the brand. The negativity wears people down, and I want to keep contributing.
After six months I still run debug on Zigbee and Matter, and the reason is insight. It was never about pointing fingers. It was about learning and understanding 
I would like to give back what I have learned, and I have an older promise to follow up on. Would people be interested in an online get-together about the community around Homey? People would help each other and share what they have learned, whatever platform they own. Anyone who wants to join is welcome, and I would be glad to have a co-host or two 
Nothing is settled yet, but I would try to find a place where everyone can take part, also those who find English hard. Think of it as an open mic, with live talk, a chat alongside, and topics taken from the forum 
Does something like this already exist that I have missed? If there is interest, the details will follow in its own thread
Regards, Ulrik
I also still support Homey as platform or advertise it as an easy platform for home automation if they seek answers to their homeautomation challenges. Same as for the Homewizard products and my Homewizard app for Homey.
But the enthusiasm is dropping by the years. Where in the beginning I got thrilled to keep adding and evolving the app and adding features it is getting less and less due the amount of affection or feedback commitment of the community. Last year I hoped for some confirmation with the community award but noticed that that was not the case.
Probably also due to growing collection of apps in the Homey store or amount of apps maintained by a developer. Also the ease of coding tools that assist the process of any of these apps these days. For me the amount of EMS apps is already an example that. And sure I also make use of it as it is sometimes impossible to maintain or keep up with my free time.
I dont like the idea apps have full access without even asking or make reference that this information is retrieved or made possible via an other app but that seems to be way Homey and the community works these days.
Even was tempted to cripple the refresh rate for energy but rather should not.
I’ll take it as it is now and accept that what I do will not have the same affection like 5 years ago.
I’d like to share a short story with you to illustrate my perspective.
I come from a background in Home Assistant and decided—just for fun—to switch to an entirely different system. I wanted to share my hobby with my daughter, and I saw Homey’s simplicity as the perfect platform for us to get started with her in this world.
Well, I took the plunge! Full of enthusiasm and anticipation, I didn’t look left or right—I just went for it… but the sobering reality soon set in. I found myself facing issues I could hardly believe. I was desperate and wanted to throw in the towel several times, but a handful of guys in this community kept helping me out. We kept pushing forward until we even managed to convince Athom that the problems weren’t necessarily just down to our own local networks! 
My point is: if it hadn’t been for these people—and ultimately Athom itself—supporting me, I would have definitely quit, and I wouldn’t be part of the solution today. This experience led me to develop a “love-hate” relationship with Homey—the kind of relationship this system truly deserves.
Now, months later, I want to say: thank you to the community developers who provide the features missing from the official platform; thank you to the folks from other systems who show us that things can be done differently; and thank you to all the vocal critics—without all of this, Homey wouldn’t be where it is today, nor would it continue to evolve!
The moral of the story—much like in football (the Champions League is on right now! )—is that you win matches as a team, not as an individual player. For the future, I hope to see unity, more constructive criticism, and a willingness to help anyone who needs it—all without feeling the need to fiercely defend a product we happen to love!
I come from project management, and one of the keys to success for me was always learning how to deal with criticism.
I worked with people I genuinely loved working with, and many of them were permanently critical.
If ten critical opinions came in, I might dismiss five because they were irrelevant or simply wrong. Three others might be interesting and worth investigating. And perhaps two of them were real showstoppers that needed immediate attention.
But I would never tell those people that they were not welcome just because five of their criticisms turned out to be ridiculous or because three were not critical enough to act on immediately.
The alternative would be much worse: surrounding yourself only with people who tell you how great everything is and that everything will be fine — until one day the whole house of cards collapses.
Maybe that background explains why I am naturally quite critical.
I am not offended if someone tells me that one of my criticisms is wrong, exaggerated or irrelevant. Maybe it is.
What matters to me is how that disagreement is expressed.
What I find unhealthy is the fanboy mentality where every criticism is treated as an attack on the platform itself.
Permanent praise and permanent defence may feel supportive, but in the long run they can actually become harmful because they remove exactly the pressure that drives improvement and innovation.
My posts are certainly often critical, but that is not the same as being negative.
I have said many times that I still like Homey. At the same time, I point out things that I think are weak or missing and could be improved to make Homey better in the future.
One example is Helpers, which I consider one of Home Assistant’s biggest advantages.
Homey could implement a similar concept as a separate system layer rather than as additional Flow cards. Advanced Flow would then simply get cards to read from or write to those Helpers.
A Helper can take many forms, but a simple example would be a template sensor.
In Homey terms, that could mean:
take one or more existing Tags
calculate or transform their values
expose the result as a new Tag
optionally make that Tag a measured value with history and Insights
then use that new Tag everywhere else in Flows
Today, achieving something similar in Homey usually requires an app.
In Home Assistant, I can create that derived value myself whenever I need it.
That is what I mean by constructive criticism.
I am not saying “Homey is bad.”
I am saying “here is something another platform does very well, and here is how Homey could adopt the idea in a way that still fits Homey’s own philosophy.”
It really depends on the angle you look at it from.
For simple to moderately complex automations, I completely agree that Advanced Flow is very appealing. The visual layout is easy to understand and often faster to build.
But even there, it has limits that Home Assistant does not have.
Once automations become very complex, an Advanced Flow can turn into a huge canvas with dozens of crossing connections, and following one particular logic path becomes increasingly difficult.
I even tried to work around that with cards from my own Flow Gadgets app, using things like Continue elsewhere to split the logic into several smaller flows on the same canvas.
That helps, but it still becomes difficult to read at some point.
In Home Assistant, complex logic can instead be structured into multiple Choose blocks and clearly separated branches. The more complex the automation becomes, the more I actually prefer that structure.
And importantly: you do not have to write the automation in YAML.
I build my automations in the visual editor. Even some of my extremely complex automations only contain a few small Jinja expressions in specific places.
For my own use, I have now reached a level of automation complexity that would either become extremely difficult to represent in Advanced Flow or simply isn’t technically possible in Homey at all.
So for me:
simple automation → Advanced Flow is often nicer
very complex automation → Home Assistant becomes easier to structure and follow
