Reactive flow cards that pause and wait for device states to change
⚠️ Experimental Feature
I'm still exploring if Waiter Gates provide real value in practice. Your feedback is welcome! This feature may evolve or change based on user experience.
What Are Waiter Gates?
Waiter Gates let your flows pause and wait for specific device states to change, with YES/NO paths based on the outcome:
YES path (green): The device capability reached the target value
NO path (red): Timeout expired before reaching the target value
How It Works
Flow hits the wait condition - Checks the current value immediately
Doesn't match? → Register listener and wait for change ⏳
Value changes to target? → YES path ✅
Timeout expires? → NO path ❌
Flow Cards
Wait until device capability becomes value
Type: CONDITION
Waits for a device capability to reach a target value. Has YES/NO paths.
Parameters:
Device: The device to monitor
Capability: Which capability to watch (e.g., onoff, dim, alarm_motion)
Target value: The value to wait for (e.g., true, false, 0.5)
Timeout: How long to wait before giving up
Waiter ID (optional): Unique identifier (auto-generated if empty)
Example Flow:
WHEN motion detected
AND wait until [Living Room Light].onoff becomes true (timeout: 5 minutes)
THEN ✅ announce "Light turned on!"
ELSE ❌ notify "Light didn't turn on - check bulb?"
Control waiter gate
Type: ACTION
Enable, disable, or stop a waiter gate by its ID.
Parameters:
Waiter ID: The ID of the waiter to control
Action: Enable, Disable, or Stop
Actions:
Enable: Allows waiter to trigger YES/NO paths
Disable: Prevents waiter from triggering (stays in waiting state)
Stop: Removes waiter completely (no output)
Wait
BONUS
Type: ACTION
Simple delay without device monitoring. Just pauses the flow for a specified time.
Parameters:
Duration: Number value (e.g., 5)
Unit: Milliseconds, Seconds, Minutes, or Hours
Example:
WHEN motion detected
THEN turn on light
AND wait 5 seconds
AND turn off light
Real-World Examples
💡 Light Confirmation
Verify that a smart bulb actually turned on after sending the command.
WHEN light switch pressed
THEN turn on [Smart Bulb]
AND wait until [Smart Bulb].onoff becomes true (timeout: 10 seconds)
THEN ✅ continue normally
ELSE ❌ send notification "Bulb failed to turn on"
AND log error
🚪 Door Security
Make sure door closes after opening, with notification if it stays open.
WHEN front door opened
AND wait until [Front Door].alarm_contact becomes false (timeout: 2 minutes)
THEN ✅ log "Door closed normally"
ELSE ❌ send notification "Front door still open!"
AND flash lights red
🌡️ Temperature Monitoring
Wait for heater to reach target temperature, alert if it fails.
WHEN heater turned on
AND wait until [Heater].measure_temperature becomes 22 (timeout: 30 minutes)
THEN ✅ log "Target temperature reached"
ELSE ❌ notify "Heater not reaching temperature - check it!"
🔌 Device Power State
Verify a device actually started consuming power after turning on.
WHEN washing machine turned on
AND wait until [Power Meter].measure_power becomes >100 (timeout: 5 minutes)
THEN ✅ log "Washing machine started"
ELSE ❌ notify "Washing machine didn't start - door open?"
Waiter ID Management
Auto-Generation (Recommended)
Leave the Waiter ID field empty, and the system automatically generates a unique ID like waiter_1704123456789_x3k9m2
Each waiter ID must be unique across ALL flows. If you use the same ID in multiple flows simultaneously, they will conflict.
⚠️ Known Limitations
IDs must be unique across flows Using the same waiter ID in multiple flows simultaneously will cause conflicts. Use auto-generation to avoid this.
Active waiters consume memory Each waiter listening for changes uses system resources. Clean up old waiters with the "stop" action.
Capability must exist on device The system validates that the selected capability exists. Selecting wrong capability will show an error.
Real-world usefulness still being evaluated This is a BETA feature. I'm still figuring out if this pattern is valuable for actual home automation. Your feedback is appreciated! 🤔
Troubleshooting
❌ Waiter not triggering
Check that the device capability actually exists
Verify the target value format is correct (true/false for boolean, number for numeric)
Check Homey app logs for error messages
Ensure timeout is long enough for the change to happen
❌ Always takes NO path
Check that timeout is reasonable (not too short)
Verify the device is actually changing the capability value
Use auto-generated IDs to avoid conflicts
❌ Error: "Capability not found"
The selected capability doesn't exist on the device
Check available capabilities in device settings
Some capabilities are write-only or read-only
💬 We Need Your Feedback!
Waiter Gates is an experimental feature. I'd love to hear about your experience:
✅ Does this pattern make sense for your automations?