How to Automate Devices from 3 Different Brands in One Home Assistant Setup

1. The Mixed-Brand Problem (and Why Home Assistant Solves It)

Every smart home device brand wants you locked into their ecosystem. Aqara works in the Aqara Home app. Shelly has its own app. Tapo lives in the Tapo app. Each ecosystem is a walled garden — devices from one brand generally can't trigger actions in another brand's devices without a complex workaround or yet another hub.

This is the fundamental frustration of the traditional smart home: you end up with five apps, three hubs, and automations that stop working every time a company changes their API or drops a product line.

Home Assistant solves this completely. It speaks every protocol and integrates with virtually every brand through official integrations, community-built integrations, and open protocols like MQTT. Once a device is in Home Assistant, it becomes a generic HA entity — a switch is a switch, a sensor is a sensor, regardless of who made it. Your automations don't know or care about brands; they just see entity states.

In this guide, you'll build a practical automation where an Aqara motion sensor (Zigbee, Chinese manufacturer) triggers a Shelly relay (Wi-Fi, Slovenian company) and a Tapo plug (Wi-Fi, Taiwanese manufacturer) simultaneously — then turns them both off after 10 minutes of no motion. Three brands, one clean automation. This is exactly what Home Assistant is for.

2. Setting Up the Aqara Motion Sensor via Zigbee2MQTT

Aqara sensors use Zigbee, so you need a Zigbee coordinator (the Sonoff dongle) and either Zigbee2MQTT or ZHA to bridge them to Home Assistant. This guide uses Zigbee2MQTT — see our Zigbee2MQTT beginner setup guide for the full installation walkthrough.

Once Zigbee2MQTT is running:

1. Open the Zigbee2MQTT frontend at http://YOUR-HA-IP:8099
2. Click Permit join (All) to open pairing mode
3. On the Aqara motion sensor, hold the reset button (usually a small button on the side) for 5 seconds until the LED blinks three times
4. The sensor appears in the device list within 30 seconds
5. Click the sensor in the list, rename it to something clear like hallway_motion
6. Disable permit join immediately after

In Home Assistant, you'll now have a binary_sensor.hallway_motion_occupancy entity. Go to Developer Tools → States, find it, and walk in front of the sensor — the state should flip from off to on instantly. That responsiveness is what makes Zigbee sensors great for motion-triggered lighting — no Wi-Fi latency, sub-second response time.

3. Setting Up Shelly Plus 1PM via Native Integration

The Shelly Plus 1PM is a single-channel relay with power monitoring. Wire it behind a wall switch or in a junction box to control a light circuit or any mains-powered load. It connects to your Wi-Fi during initial setup via the Shelly app.

To add it to Home Assistant:

1. Power on the Shelly and complete Wi-Fi setup via the Shelly app or its built-in web interface
2. In HA, go to Settings → Devices & Services → Add Integration → Shelly
3. HA auto-discovers Shelly devices via mDNS — your Plus 1PM should appear immediately
4. Click Configure and follow the prompts

After setup, you'll have a switch.shelly_plus_1pm_channel_1 entity. Toggle it from the HA dashboard to verify it controls your light. The Shelly integration is 100% local — no cloud, no Shelly account required once it's on your Wi-Fi.

4. Setting Up Tapo P115 via TP-Link Integration

1. Plug in the P115 and configure it in the Tapo app (one-time setup, requires a TP-Link account)
2. In HA, go to Settings → Devices & Services → Add Integration → TP-Link Kasa Smart
3. The integration scans your network for TP-Link devices — the P115 will appear
4. Add it; you'll get switch.tapo_p115_plug and energy monitoring sensors

The TP-Link integration communicates locally with the plug after the initial cloud setup. No ongoing internet dependency. Test it by toggling switch.tapo_p115_plug from Developer Tools to confirm it responds.

5. Creating the Cross-Brand Automation

Now for the payoff: one automation that bridges all three brands. Go to Settings → Automations → Create Automation → Edit in YAML and paste the complete automation below.

This automation triggers when the Aqara sensor detects motion, simultaneously turns on both the Shelly relay and the Tapo plug, waits until the sensor reports no motion for 10 continuous minutes, then turns both devices off:

alias: "Motion Activated Multi-Brand Setup"
description: "Aqara motion triggers Shelly relay and Tapo plug"
trigger:
  - platform: state
    entity_id: binary_sensor.aqara_motion_sensor_occupancy
    to: "on"
condition:
  - condition: sun
    after: sunset
    before: sunrise
action:
  - parallel:
      - service: switch.turn_on
        target:
          entity_id: switch.shelly_plus_1pm_channel_1
      - service: switch.turn_on
        target:
          entity_id: switch.tapo_p115_plug
  - wait_for_trigger:
      - platform: state
        entity_id: binary_sensor.aqara_motion_sensor_occupancy
        to: "off"
        for:
          minutes: 10
  - parallel:
      - service: switch.turn_off
        target:
          entity_id: switch.shelly_plus_1pm_channel_1
      - service: switch.turn_off
        target:
          entity_id: switch.tapo_p115_plug
mode: restart

Let's walk through each section so you understand exactly what's happening:

• trigger: The automation fires when binary_sensor.aqara_motion_sensor_occupancy changes to "on". That's the Aqara sensor detecting motion.
• condition: Only runs between sunset and sunrise (at night). During the day, motion won't trigger anything. Remove this block if you want 24/7 operation.
• parallel: turn on: Sends the turn-on command to both the Shelly and the Tapo plug simultaneously — not one after the other. Both switch on within milliseconds of each other.
• wait_for_trigger: The automation pauses here, waiting for the motion sensor to stay "off" for a full 10 minutes. If motion is detected again during this wait, the mode: restart setting restarts the entire automation from the trigger, resetting the timer.
• parallel: turn off: Once the 10-minute no-motion period elapses, both devices turn off simultaneously.
• mode: restart: This is crucial. If motion triggers the automation again while it's already running (i.e., while waiting for no-motion), the automation restarts. This means the lights stay on whenever someone is in the room — the 10-minute timer only counts down during actual inactivity.

6. Adding Timeout: What Happens If wait_for_trigger Never Fires

wait_for_trigger waits indefinitely by default. If your motion sensor gets stuck in "on" state (a known issue with some sensors), the automation would never turn the lights off. Add a timeout as a safety net:

  - wait_for_trigger:
      - platform: state
        entity_id: binary_sensor.aqara_motion_sensor_occupancy
        to: "off"
        for:
          minutes: 10
    timeout:
      hours: 2
    continue_on_timeout: true
  - parallel:
      - service: switch.turn_off
        target:
          entity_id: switch.shelly_plus_1pm_channel_1
      - service: switch.turn_off
        target:
          entity_id: switch.tapo_p115_plug

With timeout: hours: 2 and continue_on_timeout: true, the automation will turn the lights off after 2 hours maximum, even if the sensor never reports no-motion. Adjust the timeout to whatever makes sense for your use case — a bathroom might be 30 minutes, a living room might be 4 hours.

7. Adding Time Conditions: Only Run at Night

The automation already has a sun condition (after: sunset, before: sunrise). This automatically adapts to the season — it calculates sunset/sunrise based on your home's latitude and longitude (set in Settings → System → General → Location).

If you prefer fixed times instead of sunset/sunrise, replace the sun condition with a time condition:

condition:
  - condition: time
    after: "22:00:00"
    before: "07:00:00"

Or combine both — only run at night AND only on weekdays:

condition:
  - condition: and
    conditions:
      - condition: sun
        after: sunset
        before: sunrise
      - condition: time
        weekday:
          - mon
          - tue
          - wed
          - thu
          - fri

8. Expanding: Adding a Fourth Device from Another Brand

The beauty of this pattern is that adding more devices is trivial. Suppose you want to also turn on a Philips Hue bulb (via the Hue integration) when motion is detected. Just add its entity to both parallel blocks:

  - parallel:
      - service: switch.turn_on
        target:
          entity_id: switch.shelly_plus_1pm_channel_1
      - service: switch.turn_on
        target:
          entity_id: switch.tapo_p115_plug
      - service: light.turn_on
        target:
          entity_id: light.hue_hallway_bulb
        data:
          brightness: 180
          color_temp: 370

Notice you can pass additional data to specific device types — the Hue bulb gets a brightness and colour temperature setting, while the switches just get a simple on command. Each brand's capabilities are exposed through their entity type's service calls.

Other brands you might add to a similar automation: IKEA Tradfri bulbs (via Zigbee2MQTT), ESPHome custom devices (via the ESPHome integration), Sonoff switches (via Zigbee2MQTT or eWeLink), or even a WakeOnLAN command to spin up a computer. Home Assistant treats them all equally.

9. Dealing with Race Conditions and Edge Cases

Real automations encounter edge cases. Here are the common ones for this pattern and how to handle them:

Motion detected while devices are already on (manually turned on)

If someone manually turned on the Shelly light before the automation fires, switch.turn_on on an already-on switch has no effect — that's fine. But the automation will still start its 10-minute wait and potentially turn the light off when they don't expect it. Solution: add a condition checking if the light is currently off before running the full automation, or use a different "light was turned on manually" detection approach using input booleans.

Network device temporarily unavailable

Wi-Fi devices like Shelly and Tapo can briefly drop off the network. If a service call targets an unavailable entity, HA logs an error but continues the automation — it won't crash. The device will generally turn on/off when it reconnects. For critical automations, add a retry using a script with repeat.

Multiple motion sensors in the same area

If you have two Aqara sensors in a large room, use a group entity. In HA, go to Settings → Devices → Groups → Create Group and add both motion sensors. The group reports "on" if either sensor detects motion — use the group entity as your trigger instead of a single sensor.

mode: restart vs mode: single

This automation uses mode: restart. If you used mode: single instead, a second motion event while the automation is running (in the wait_for_trigger phase) would be ignored. That could mean the lights turn off mid-conversation because the automation already started its countdown. Always use mode: restart for motion-triggered automations with timeouts.

10. Troubleshooting

Automation triggers but one device doesn't respond

Test each device individually first: go to Developer Tools → Services, call switch.turn_on with the specific entity ID, and verify it responds. If it doesn't, the issue is with the device integration, not the automation. Check the integration's logs in Settings → System → Logs.

Automation fires during the day despite the sun condition

Check your HA location settings: Settings → System → General. The latitude and longitude must be set correctly for sunset/sunrise calculations to be accurate. If your location is set to 0,0 (the default on new installs), sunrise/sunset times will be completely wrong.

Lights don't turn off after 10 minutes

The Aqara motion sensor might still be reporting "on" even though no one is there — many PIR sensors have a configurable re-trigger period. Check Zigbee2MQTT's device settings for your sensor: look for an "occupancy_timeout" setting (often configurable via Zigbee2MQTT's device-specific settings panel). Set it to 30 seconds or 1 minute.

Automation runs multiple times simultaneously

Confirm mode: restart is set. Without it, mode: parallel is the default, which allows the automation to run multiple instances at once — leading to race conditions on the turn-off step.

11. FAQ

SmartWired participates in the Amazon Associates Programme. We may earn a commission from qualifying purchases at no extra cost to you.