Keep a Bond Ceiling Fan Reliable Behind a Lutron Switch

A Bond-controlled ceiling fan becomes unreliable when an upstream smart switch removes power from its one-way RF receiver. Keep the receiver powered, make Bond the normal control surface, and reserve the wall switch as a guarded upstream boundary.

The hardware I was trying to join

The wall control is a Lutron Caséta PD-8ANS switch. It supplies power to a ceiling fan/light with its own RF receiver. A Bond Bridge duplicates the handheld remote, and Home Assistant exposes the Bond light and fan as separate entities.

That sounds straightforward until the wall switch is turned off. Bond can still transmit, but the receiver in the ceiling has no power. The command goes nowhere.

I checked the live Home Assistant device registry instead of guessing which bridge generation I own. It reports manufacturer Olibra, internal model zermatt, and firmware v3.17.4. Home Assistant’s current Bond documentation identifies zermatt as Bond Bridge v2 and lists it as tested. The current Bond product page uses the retail model number BD-1000.

Those model names matter for a buying article because “Bond Bridge” spans more than one generation. They do not identify the fan receiver itself. I can document how this bridge behaves with my fan, but I cannot claim that every RF fan exposes the same light, speed, direction, or state behavior.

Attempt one: keep my own version of the truth

My first setup used input booleans to remember whether Home Assistant thought the RF light and fan were on. Four automations updated those helper states. A fifth watched the Lutron switch and tried to put the fan back into the expected state after power returned.

That was a lot of machinery devoted to a state I could not actually measure. Bond was sending one-way RF, so a handheld-remote press or a missed command could make my helpers wrong. Once that happened, the recovery logic was confidently acting on fiction.

Attempt two: turn power-up into a sequence

I removed 91 lines of state-tracking automation and replaced them with one power-on routine. When the Caséta switch changed from off to on, Home Assistant waited three seconds for the ceiling receiver to boot, turned on the light, waited another second, and set the fan to its lowest speed.

It was cleaner, but it still made a wall switch responsible for booting a radio receiver before the room could work. A quick off/on cycle could cut power during that four-to-five-second window. Bond would transmit to a dead circuit and the ceiling unit would “never turn on.” I had also welded two independently controllable things—the fan and its light—into one synthetic control.

There was a smaller clue that I was fighting the abstraction: on this six-speed fan, 17% landed on speed two. I changed the low-speed command to 16%. That fixed the rounding problem, not the design.

The fix: stop power-cycling the receiver

I now treat the Caséta switch as a power feed, not the normal control. The circuit stays energized. Home Assistant exposes the Bond light and Bond fan separately, just like the handheld remote. The raw Lutron switch is hidden from Google Assistant so a voice command cannot cut power out from under Bond.

I kept one small guard automation. If the switch is turned off by the paddle, a scene, or a stray command, Home Assistant turns it back on after one second:

- id: livingroom_ceiling_keep_powered
  alias: Living Room Ceiling - Keep Powered
  trigger:
    - platform: state
      entity_id: switch.living_room_ceiling_fan
      to: "off"
  action:
    - delay:
        seconds: 1
    - service: switch.turn_on
      target:
        entity_id: switch.living_room_ceiling_fan
  mode: single

And this is the important part of the Google Assistant exposure. The useful Bond entities are visible; the switch that can break them is not:

google_assistant:
  exposed_domains:
    - switch
    - light
    - fan
  entity_config:
    light.ceiling_fan_2:
      name: Living Room Ceiling Light
    fan.ceiling_fan_2:
      name: Living Room Ceiling Fan
    switch.living_room_ceiling_fan:
      expose: false

The fastest way to diagnose this failure

I spent too long debugging automations because the dashboard made the system look more observable than it was. The useful test is to separate power, transport, and state:

1. Confirm the receiver has continuous power. A successful Bond call proves only that the bridge transmitted. The fan may never have heard it.
2. Send one simple command. Start with light on or one known fan speed, not a scene that changes several things.
3. Watch the physical fan. For one-way RF, the room is the source of truth. The Home Assistant state can be a tracked assumption.
4. Power-cycle only as a test. If the first command after power returns fails but a later command works, the receiver’s boot time is part of the system.
5. Inspect every other control path. The handheld remote, voice assistant, dashboard, scene, and upstream switch can each change—or merely appear to change—the same device.

Home Assistant’s Bond integration exposes actions that change the tracked fan or light state. Those actions repair Home Assistant’s belief; they do not create feedback from a receiver that never transmits its state. That distinction would have saved me from building the first five automations.

What continuous power fixed

The remaining limitation matters. A conventional RF remote does not report what the fan actually did. Bond’s displayed state is based on commands, not feedback from the ceiling receiver. Bond itself has described this as a one-way protocol, and Home Assistant calls devices without feedback “assumed state.” I can make that behavior less fragile; I cannot manufacture telemetry the hardware does not provide.

What I would do if I were wiring it today

1. Decide whether the receiver needs permanent power. If the fan is controlled by RF commands, assume it does unless its documentation says otherwise.
2. Do not make power cycling part of normal operation. A smart switch plus a smart receiver can be worse than either one alone when both think they own on/off.
3. Expose the controls people should use. In my case that is the Bond light and fan, not the upstream Caséta switch.
4. Accept the one-way boundary. If accurate state is mandatory, choose hardware with real feedback instead of building more helpers around guessed state.
5. Leave a maintenance path. My guard automation is easy to disable when I actually need the circuit off.

When I would buy a Bond Bridge—and when I would not

The current Bond Bridge product page describes support for ceiling fans, fireplaces, and Somfy shades, while Home Assistant lists Bond as a Local Push integration. I would still check the exact remote against Bond’s compatibility search before buying. “RF remote” is a category, not a compatibility guarantee.

Would I still use Bond and Caséta?

Yes, for different jobs. Caséta is still what I want for ordinary permanent lighting because the wall controls work without Home Assistant. The Home Assistant Caséta integration is local push and exposes switches, dimmers, fan controls, scenes, sensors, and Pico remotes through the bridge.

The Bond Bridge is useful when a fan I already own is controlled by a compatible RF remote. My live bridge is the v2 zermatt generation, and Home Assistant classifies the integration as Local Push. I just would not put the fan receiver behind a switch that gets used as part of the daily control path.

This is the distinction I missed at first: both products worked. The architecture did not.

Disclosure: I bought and use the Bond and Lutron equipment described here.