Lena

Worth adding that some boards have both — a plain LED and an addressable one — and only one of them is on the built-in constant.

So "the constant does nothing" and "there is definitely an LED on the board" can both be true while you look at the wrong LED. Look for two of them before concluding anything; on small boards they are easy to mistake for a power indicator.

This happens periodically and it always ends the same way, so it is worth being clear-eyed about which options are real.

What actually happened. The integration was reverse-engineered against a private cloud API — one the manufacturer never published and never promised. When they add bot detection, rotate an authentication scheme or start requiring a signed client, the integration breaks. A maintainer can chase it, but they are one person against a company that can change it again next quarter, and eventually they stop. That is a reasonable decision, not an abandonment.

The options, honestly ranked:

1. Bypass the cloud with local hardware. Usually the best answer, and often surprisingly cheap. Most of these devices are, underneath, a motor and some switches. A small microcontroller board wired to the physical control terminals, plus a sensor for state, gives you a fully local device that no vendor can turn off. For a garage door that is a relay across the button terminals and a reed switch on the door; for many appliances it is similar.

There are ready-made boards for exactly this on the popular open firmware platforms, so it is frequently a purchase and a wiring job rather than a project. Do read the safety documentation for anything with a motor and a moving mass, and keep the existing safety mechanisms intact — you are adding a parallel control path, not replacing the interlocks.

2. Replace the controller, keep the mechanism. For many devices the expensive part is the mechanism and the network-connected controller is a small module. Swapping the controller for one that speaks a local protocol keeps the hardware and removes the dependency permanently.

3. Check for an official integration or a supported protocol. Some manufacturers, having blocked the unofficial route, do offer something official — occasionally behind a subscription, occasionally through one of the cross-vendor standards. Worth ten minutes of checking before doing any work. Judge it on whether it works locally; an official cloud integration has exactly the same failure mode as the one you just lost.

4. Bridge through whichever ecosystem the vendor does support. If the device works with a large platform assistant, you can sometimes route control through that. It works, but you have swapped one cloud dependency for two, and the latency is noticeable. A stopgap rather than a solution.

5. Wait for the integration to be fixed. Sometimes it is. Do not build on it.

On avoiding this next time, which is the more valuable half of your question. The single question to ask before buying: does this device work with no internet connection, controlled from my own network? Everything else is detail.

In practice that means favouring devices that speak a local protocol directly — the low-power mesh standards, or plain local network protocols — over anything whose only interface is a vendor app talking to a vendor cloud. It also means treating "has an integration" as much weaker evidence than "has a documented local API", because the first can be an unofficial one that is one server change away from this thread.

And where a device is only available as a cloud product, assume the integration is temporary and buy it for what it does today rather than for the automation you are planning.