The manufacturer blocked the unofficial API my automation depended on, and now my device is a dumb device again. What are the options?

One thing to check before you cut anything: whether your device has a physical low-voltage control interface at all.

Older equipment usually has screw terminals for a wall button — trivially easy. Newer equipment increasingly uses a proprietary digital bus between the controller and the wall unit, precisely so third-party controls do not work. On those, a relay across two terminals does nothing and you need a different approach.

Five minutes with the manual or the wiring diagram tells you which world you are in, and it determines whether option one is an evening or a non-starter.

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.

Strongly seconding the local-hardware route, having done exactly this after the same thing happened to me.

The part that surprised me was how much better the result was. The cloud integration had a delay of a second or two, failed whenever my connection did, and reported state that was sometimes wrong. The local version is instant, works during an outage, and the state comes from a sensor on the actual mechanism rather than from what a server believes.

Worth saying plainly: you are usually not downgrading. You are removing a middleman that was adding latency and a failure mode.

Budget an evening, not a weekend. The wiring is simple; the time goes into mounting things tidily and testing the safety behaviour properly.