I think you’ve made up your mind Pascal, to be honest 
I would consider parking automations to go out and live a little.
I’ve not been on the forum an awful amount since I sorted out Thread with HA
There are very interesting apps keeping me engaged with Homey, such as Flowbits and HomeWindow. I’m also interested to see what else I might use on HA once HACS is integrated with HA 26.11
I do. 
I’m currently working on automations, writing forum posts, getting started with ESPHome and writing a book.
But I also walk the dogs, work on the house, go to the theatre and cinema, meet friends and do plenty of other things.
I’m retired, so I simply have a lot more free time to fill than someone working full-time. And at my age, sleeping only five or six hours isn’t unusual either.
I also think keeping the brain active is important as we get older. Technical projects, learning new things and solving complex problems are part of that for me.
So don’t worry — I’m living quite well. I simply happen to enjoy this stuff too.
I think negativity is a horrible thing, it should be banned. I appreciate everybody trying to make homey a more reliable platform. Thanks! please stay, continue the good work!
Years ago i also started with homey. But i got frustrated by its lack of reliability. Especially with hue!
So i switched to HA. so many more possibilities and also much more complicated.
So recently i bought a homey 2026. And my HA is now integrated in Homey: perfect combination especially with more exotic equipment. Best of borh worlds.
Which devices are you missing in Homey? You can also make an app request:
I build many Homey apps (also for the exotic devices) and depending on how the mobile app communicates, it may be possible to build a Homey app for it.
Just one thing to keep in mind with Sven’s offer.
He has a very strong preference for cloud-based integrations and often considers them perfectly acceptable even where a local solution might also be possible.
If that is fine for your use case, then his offer may be a good fit.
If you specifically want a local-first integration without depending on the manufacturer’s cloud, I would make that requirement very clear from the beginning.
That’s exactly the problem.
One system combining the best of both worlds would probably be the perfect fit.
But maybe smart-home platforms are a bit like partners: finding one that ticks absolutely every box is about as likely as getting all six numbers right in the lottery. 
At least for the apps that I build, I have a few requirements:
But those are my own requirements, I’m sure there are other developers that have other (maybe less strict) requirements for an app request. That’s why I would recommend posting them in the app requests topic:
And again, Sven: calling other requirements “less strict” is your personal opinion, not an established best-practice rule.
For core smart-home functionality, the industry is actually moving strongly in the opposite direction: local-first, with cloud as an optional additional service where it adds value.
Matter itself is a local connectivity technology. Google explicitly promotes local Matter control because it offers lower latency and higher reliability than cloud-to-cloud communication. Amazon says local connectivity allows devices to keep working during internet outages. Even SmartThings now describes reducing cloud dependency and moving processing to the edge as a growing industry priority.
That doesn’t mean cloud services are inherently bad or insecure. They can be useful for remote access, backups, analytics, updates or additional services.
But making basic device control dependent on a manufacturer’s cloud adds another external dependency and attack surface that is simply unnecessary when the same function can run locally.
So your preference for cloud integrations is perfectly valid for you.
What I object to is presenting it repeatedly as if it were the stricter or safer architecture.
Today, the much more common design principle is:
Local for core functionality whenever possible. Cloud where it adds optional value.
Beginners reading this forum should understand that distinction, because otherwise they may build a cloud-dependent system believing that this is somehow the recommended security architecture, only to discover later that much of the industry is deliberately moving the other way.
Yes, these the things I would never ask someone while building an app: I won’t request access to anyone’s network or ask for passwords when building apps, as in my opinion that’s too privacy invasive. The testers provide their password inside the Homey app, the app uses that to log in and the relevant device information gets sent to me. No passwords or session tokens are shared.
If you think that’s fine to ask someone, then that’s your choice of course. But I would never do that, as I also wouldn’t allow anyone access to my own network either.
What do you count as “core functionality”? If that means, controlling a smart plug with its physical button on the device when there’s no internet (which is at least what that would mean to me), that isn’t even dependent on Homey or your network at all, and doesn’t need the Homey app to be running either.
In most cases (even with Tuya devices, the newer models at least), you can also control devices from your phone when the internet drops out via Bluetooth fallback. I also used this several times during a router update: you don’t even need your local network. The manufacturer’s mobile app just connects straight to your device via Bluetooth during an internet outage. When the internet is back, the devices automatically disable their Bluetooth radios again to make sure others nearby can’t control your devices.
Bluetooth is a very interesting offline control method, at least for me: you can keep using your devices during internet outage, or while your router is updating or when you’re performing network changes (which happens very often in my own house). Since Bluetooth allows your phone to connect directly to the device with no “hops” inbetween, it’s a good solution for emergencies. However, this is only s solution for outages, and also not suitable for Homey (Homey’s BLE implementation contains many bugs and connection drops often occur). But this is still useful to control your devices from the manufacturer’s mobile app on your phone.
Where did you get this from? Appearantly not from your own use, because the second I pull the internet connection, all Google Home speakers stop responding to voice commands. And there’s a reason behind that: Gemini, the AI model that powers Google Home, is far too large to run on the speaker itself.
honestly don’t understand why you keep bringing this up.
My local devices don’t require me to give an app developer access to my network or passwords.
Matter devices communicate securely and locally and don’t need a manufacturer cloud or a special driver from the developer. A normal Wi-Fi device may need my Wi-Fi credentials to join my network, but I enter those myself. A developer can test the integration on their own network and the user installs it on theirs.
So this has very little to do with whether an integration should be local or cloud-dependent.
And again, that completely misses the point.
Bluetooth fallback may allow you to manually operate a nearby device with your phone. That is not a replacement for a locally functioning smart home.
My automations should continue to work without Internet. Motion sensors should still trigger lights. Physical buttons should still work. Heating, shutters and other basic functions should continue without me walking around the house with a phone.
Otherwise I don’t really need a smart home — I have simply replaced a wall switch with a phone.
Local-first means that the core functionality continues locally without Internet access, without depending on the manufacturer’s servers and without a mandatory cloud service.
Cloud services can then be added where they provide useful additional functionality.
And this doesn’t contradict local-first either.
Google is heavily involved in Matter, and Matter control is designed to work locally. Google also supports local execution for suitable automations.
If Google Assistant stops understanding voice commands when the Internet is disconnected, that only tells us that voice recognition is cloud-dependent. It does not mean that the underlying Matter devices or local automations have to stop working.
And if your lights can only be controlled by cloud-based voice commands, then in my opinion the smart-home architecture itself is already missing something important.
Lighting should still work through local automations, motion or presence sensors, physical buttons or switches — preferably more than one of those.
Voice control is convenient, but it should be an additional interface, not the single point of failure for basic functions.
That is the whole idea behind local-first:
Core functionality local whenever possible. Cloud where it adds value.
Nobody says that cloud services are useless. Voice recognition, remote access, AI services, weather data and many other things can perfectly well use the cloud.
But making basic smart-home functionality depend on that cloud when it could run locally is a completely different architectural choice.
Guy wake up. What says the bile about that “God they have eyes but they don’t see.”
Ill just say, its disappointing to hear this response in many regards.
When someone requests an app, I will check some things first before replying to the request. What I will usually do is create an account on the manufacturer’s mobile app, which is running inside a rooted Android emulator. Then, I will log in with that account. That immediately tells me:
Since my account is empty (there are no devices since I don’t own any), the app won’t do much. I build the login and device list requests into a Homey app, ask the user to install it and log in to the app on Homey. The app will then collect the response of the device list and send that back via a diagnostics report. I don’t see any passwords or session tokens.
I replicate this response in my Android emulator. The mobile app then thinks that there’s a device and sends the next request (f.e. for device status). Then I repeat the same process until I have all the requests and responses needed to build the app.
However, local devices work very differently. You need to get the discovery packets, often the devices also communicate using non-standard protocols (while remote devices often use standard protocols like HTTPS, WebSocket and MQTT). This means I can’t replicate these responses. To build the app, the only way to reverse engineer it is to ask the user for remote access into their network, and I won’t ask that since IMO that’s too privacy invasive.
Just because all of your devices are supported, doesn’t mean every device is supported. There are many users who use devices that are not supported by Homey.
Also, you’re an app developer yourself, so then all of this doesn’t apply to you since you don’t have to request an app if you can already build it yourself
Okay, Sven. I’ll stop the discussion here before it once again turns into a ridiculous argument going around in circles.
And, frankly, this kind of exchange is one of the reasons this thread exists in the first place.
Thanks mate for being the wiser guy!
