I’d rather not.
It’ll only work with “smart” devices that are capable of cloud communication, so theoretically, the manufacturer can push an OTA update to the device to disable the local API. Which is why, once the local communication is working, you typically block cloud access for the device in your router/firewall. That’s what I do with Tuya devices too once they are under control of Local Tuya.
Why would you do that? Tuya integration with Homey is free, no subscriptions, what do you have to lose? I myself actually do it the opposite way: blocking almost all local connections and forcing everything to use cloud servers. Because I obviously don’t want my cheap IoT devices to communicate with any device on the local network, since usually they have poor authentication on the local APIs. The only exception is the Hue Bridge, I still have to finish the cloud app for that but once that’s all working, I can fully block local communication.
Why would I need it if I have full local control?
What if Homey ever drops offline and you need to quickly control it? You can’t use the Tuya mobile app anymore. Also blocking OTA is really unsafe if there’s no real reason to block it, since your devices are vulnerable when they don’t get updates. I allow internet to all of my devices, full unrestricted internet access. The only thing I block in DNS is an expired domain that one of my devices is trying to reach sometimes, since I don’t know what it sends there and if an attacker would be able to hack it if they would claim the domain. But I don’t see a reason to block internet access to a device while its API is completely free of charge.
I can install a Local Tuya CLI tool on various machines in my network in case my Home Assistant (not Homey) ever drops offline, but that’s never happened in the many years that I’ve used it.
And still, I’d rather use an Open Source controller for my Tuya devices than a closed cloud service managed by I-don’t-know-who 
I’m also not very susceptible to FUD.
Funny though that you’re saying that Samsung could close this local access API via OTA and you don’t seem to think that that is wrong in any way. The vulnerability here is having OTA support, IMO.
Well, if that’s a vulnerability then every smart device would be insecure. I don’t know of any device without OTA, even for my own ESP8266 and ESP32 projects, I can OTA them via my VPS server.
Well, that’s a personal opinion then. I’d rather have ease of use and convenience. In my case, local control doesn’t add much either. When we had an internet outage recently, I quickly disabled WiFi on my phone to check for outages but when I wanted to reconnect, I couldn’t since the main network uses WPA3-Enterprise and Zyxel Nebula needs the server to authenticate clients using the username and password. So even if local control was possible, it wouldn’t have helped. But I understand most people just have a “regular” network on a regular router 
That’s local OTA, and completely different from allowing a manufacturer to remove functionality for commercial and/or monetary purposes.
Just like yours is.
Are you saying that you can’t connect to your local WiFi network when there’s no internet connection?
Yes, but only when associating. If the client is already connected, it will stay connected. This probably has to do with how Nebula Cloud Authentication works. When I connect a device to my main network, I need to create a username and password for it on the Zyxel Nebula cloud portal. Then, I need to authorize it to use the network and then I can enter that username and password to connect.
I can also choose if the device requires 2FA, which I have on for only some devices (only devices that I don’t use/disconnect often). In case of 2FA, it will open a captive portal where I need to enter OTP from Google Authenticator. Probably, Nebula works in a fail-safe way: when there’s no internet, don’t authenticate any clients. Some systems have backup methods which use a cache, but appearantly Nebula doesn’t. I also have MAC authentication set up for my IoT network (and want to move to DPPSK soon for better protection, then you can use different WPA2-PSK passwords per device, but that requires a lot of time to reset all devices and get them to use the DPPSK instead of the currently set up password). I never checked if MAC authentication still works without internet, we luckily almost never have internet outages in my area.
Well, it doesn’t run on my local network, it runs on a Linux VPS on the cloud, but the VPS is managed by myself though.
Man you are relentless with this cloud BS 
Well, it’s just how you see it I guess. In my opinion, the cloud is the future for smart homes. Most businesses and work applications are already migrated to the cloud, so our homes would be the logical next step. Most of my self hosted web services are already moved to the cloud VPS as well (MQTT is on the cloud VPS too).
In the early days of IoT, many devices would actually work locally. The users just opened up a port in their router and then they could view their security camera (we’ll take that as an example, but it could be any device of course) from anywhere. No automatic OTA either, people had to manually upload new firmware every single time they wanted to update. This inconvenience caused many people to just ignore the updates altogether, leaving their camera (or other IoT device) wide open to the internet. In some cases, the camera could even open ports automatically via UPnP without anyone even knowing. This turned out to be a security nightmare: people would never update the camera, keep the default credentials and expose the device to the internet without any protection. There were even dedicated websites collecting insecure security camera streams for everyone to view. The IoT companies realized this, and that was the point where every vendor started migrating to a cloud-based solution. In the modern days, a device without a cloud connection and automatic OTA would still be very insecure, especially since ordinary users will find their own ways of remote access, which are often not locked down at all (port forwarding for example).
If the cloud was the future, then Apple and Unify wouldn’t be spending billions on Thread
Spend a day on the HA forums with these arguments. They’ll tear you to shreds.
I don’t understand why you’d think Thread is the future. First of all, the Matter standard is very resource-intensive, this means that the hub/bridge needs to have at least 256MB of RAM (but probably even more), instead of WiFi which just works on any cheap ESP32/ESP8266. This is also the reason why Thread-enabled gateways are very expensive (even the Tuya one from AliExpress costs like €40). Secondly, Matter has many network requirements (IPv6 for example). For anyone who doesn’t know what an “IP Address” even means (which is probably the majority of smart home users), that could be very difficult to set up. This means that anyone who just wants to control the light from their phone and don’t know anything about technology would have a hard time setting up Thread devices. Compared to WiFi lights, which work without any gateway inbetween and can just be connected to the router that you already have, Matter is much more difficult (and expensive) to set up for the “regular” users. And cloud based devices work with both mobile phones and third party gateways like Homey, while Thread devices always require an (expensive) gateway.
You really are out on a vengeance against local control and pro cloud 
Samsung starting to charge for a cloud API is the exact reason why cloud should only ever be the last option to control your home.
There’s also a free solution using automations in Google Home, virtual devices in Homey and scenes in SmartThings, you don’t have to pay if you don’t want. I used that for my Samsung Smart Monitor’s, there’s some delay but in my case that doesn’t matter since I only use it to automatically turn off my monitors when I leave home (in case I left them turned on).
At least Samsung still has a (documented) API, many vendors don’t have any API or interface for third party systems. I had to reverse engineer the mobile apps for many different brands (OSAIO, Link2Home, Asustor, ThirdReality Hub, Duux, HomeWizard Link and many more) to build a Homey app for them and use the devices in Homey. Many brands simply don’t care about publishing their API docs nowadays.
Perhaps this is a sign that you hopped on the wrong train
Well, I don’t know of any brands that sell devices as cheap as most of these do that do actually have an API. OSAIO has cameras for as little as €9,99, and also no ads in the app (many brands in that price range have an app filled with ads (like 365cam, V360Pro, V380, V380Pro, XMEye, XMEye Pro, Yi iot, Yi home, iCSee, CloudEdge, Ease Life, Yoosee and many others), but OSAIO doesn’t). Link2Home smart plug costs only €8, HomeWizard Link cost €12 for 2 door sensors and a color light bulb and the Link bridge, ThirdReality has a monopoly with their hub since it’s the only way to update firmware for those devices, so I basically have to get that hub to allow me to run OTAs on the devices. Asustor NAS I got long before Homey, so that I just need to reverse engineer anyway. The Duux dehumidifier was bought because of other reasons (it needed to last long, which cheaper brands often don’t) so that was never intended to integrate with Homey anyway when I bought it.
For regular smart devices (plugs, lights, cameras, etc.), I care more about the price than about the brand. The apps can be reverse engineered anyway, so in that case I might as well just get the cheapest one and save some money. For smart appliances, I often choose more expensive ones that last longer.
The only cheaper option would be Tuya (for the smart plug at least, OSAIO remains the cheapest for cameras), which works great but I have noticed many ad-related permissions and banners in the Tuya app, which might be a sign that they’re adding ads to the app. Many Chinese vendors have already done so, so it wouldn’t surprise me if Tuya was next.
Or, hear me out… you could just get Zigbee/Z-Wave/Thread devices and don’t need to reverse engineer any API and control them directly and locally with homey or HA or 20 different controllers…
I also use many Zigbee devices, especially the IKEA RODRET remotes (were very cheap at Ikea when they were still available, only €3,99). Unfortunately, IKEA stopped selling their Zigbee devices so I’ll have to find alternatives (I think the Hue dimmer switch is a great alternative, but Ikea was still way cheaper. I have many lights on the Hue Bridge, Hue lights of course, also Eglo Connect.z lights, Hue dimmer switches and Hue outdoor sensor, all on the Hue bridge. Then I have 1 ThirdReality Smart plug on the ThirdReality hub, a few Tuya sensors on a Tuya Zigbee gateway and an Innr plug on an Innr bridge (I’m already building the app for that). Sonoff motion sensors on eWeLink Cube and the Ikea remotes directly to Homey (the Ikea bridge is too expensive and doesn’t support the remotes in Homey anyway).
For me it also doesn’t really make sense to buy more expensive devices that support local or direct connections, because when I turn off Wifi on my phone during an internet outage, then I won’t be able to reconnect since the Nebula AP needs to check my WPA3-Enterprise credentials (and probably my subscription as well) before I can connect again, which requires internet access to check those. Same for IoT with MAC authentication via Zyxel Nebula’s servers.
