Keep a Bond Ceiling Fan Reliable Behind a Lutron Switch

In this article

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 that requests power restoration one second after Home Assistant observes the switch turning off. This intentionally overrides an off command, including a paddle press. It is appropriate only where everyone understands that behavior. The switch is not a dependable way to keep the fan de-energized.

Before maintenance, isolate the circuit correctly; disabling an automation alone is not electrical isolation. The fan or light may resume its own power-on behavior when power returns. Do not copy this guard onto equipment where automatic re-energizing would be unsafe. Use an electrician for line-voltage work.

The example is one list item for automations.yaml; replace the switch entity ID. In the individual automation editor, remove the leading list dash and unindent the remaining keys. This documents my existing workaround, not a new hardware test:

- 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

This guard cannot prevent the initial power interruption or ensure the receiver has rebooted before the next RF command. If Home Assistant is offline, it cannot restore power; if the switch stays off after a failed action, this example has no retry loop. With mode: single, additional triggers during the running sequence are ignored.

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. Merge these settings into the existing manual Google Assistant configuration; this is not a complete integration setup. Hiding the entity here does not disable its paddle or other control paths:

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. Software settings do not replace proper circuit isolation. The installation must remain safe to service independently of Home Assistant.

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.

Clarified October 10, 2026: automatic power restoration does not prevent a power cycle, guarantee recovery, or provide electrical isolation.