Multi-platform rule conflict decision tree — deleted the Mi Home automation but the light still turns off at 21:00

There is a particularly confusing smart-home failure: the user says "I clearly deleted the 'turn off living-room light at 21:00' automation in the Mi Home app, but the light still goes out at exactly 21:00 every night, like clockwork". The first reflex drifts toward "the bulb is broken" or "the gateway crashed", and some even reset the device — yet after reset, the light still turns off at 21:00.

The signature of this fault is "the place you deleted is not the place that actually executes". In the Mi ecosystem, the Mi Home app (cloud) and the geek edition / local gateway (local) are two independent rule engines; deleting one does not delete the other. The decision tree below handles the "multiple platforms co-manage one device, rules won't fully delete" class.

60-second check — are two engines managing it?

Self-test with one sentence:

You deleted the automation on platform A, but the device still acts on the original schedule; and the device is attached to both Mi Home cloud and some local gateway/geek edition/Home Assistant → strongly suspect two independent rule engines each executing.

If deleting it stopped the action immediately, it is a single engine — outside this page.

Troubleshooting decision tree

User reports: deleted "21:00 turn off light" in Mi Home, light still turns off at 21:00 nightly
  │
  ├─ Confirm how many engines the device is attached to
  │    ├─ Only Mi Home cloud? → it should have stopped; check Mi Home "scene/shortcut/linkage" leftovers
  │    └─ Also on geek edition/local gateway/HA? → two engines, cloud deleted but local remains ★most common
  │
  ├─ Log into the local engine backend (geek edition / gateway / HA)
  │    ├─ "Scheduled tasks" has 21:00 turn-off? → delete it, light should stop
  │    ├─ "Scene linkage" has a turn-off trigger? → compare conditions, delete the linkage
  │    └─ Neither?                      → maybe firmware built-in schedule or a third-party plugin
  │
  ├─ Compare log timestamps (key step)
  │    ├─ Local engine log shows "turn off" at 21:00? → confirms local rule is executing
  │    └─ No log but light still off?        → not a rule, check firmware schedule / physical timer
  │
  └─ Root-cause locating
       ├─ Two engines issuing opposite commands to the same light? → priority conflict, tug-of-war
       └─ Only local has the rule, cloud already deleted?   → cloud delete was ineffective, fix is delete local

The hinge of the whole tree is one line: first confirm where the "executing rule engine" lives, then delete in that one. Logging into the local backend and comparing the 21:00 timestamps are the pivot — they directly prove "who is turning the light off on schedule".

Three-step locating procedure

Step 1 — confirm how many engines the device is attached to

Open the Mi Home app to see device ownership, then open the geek edition (or local gateway, Home Assistant) to see whether the same device is also there. If both have it, assume by default "cloud delete ≠ local delete".

Step 2 — inspect inside the local engine item by item

1. Enter the geek edition / gateway / HA "Automation" or "Scheduled tasks" list
2. Search keywords like "light" "living room" "21:00" "off" to locate the 21:00 turn-off rule
3. Open "Scene linkage" and see if there is a "time = 21:00 → turn off light" linkage triggered
4. Temporarily DISABLE (do not delete first) this rule and observe one night whether it still turns off

Note: "disable first, observe, then delete" is safer than deleting directly — if it was a misjudgment, recovery is one click and you will not lose a useful rule.

Step 3 — confirm with log timestamps

1. Open the local engine's run log / automation trace
2. Find records around 21:00 and see whether there is "executed: turn off living-room light"
3. That record's timestamp matches the user's reported off-time → confirms this local rule

The local engine's trace log is far more reliable than the user's verbal description. Many "haunted lights" are crystal clear in the log: a "turn off" line at 21:00:00, to the second.

Emergency stopgap — disable and clean the dual-end rules

This is a checklist performed in the corresponding backend (not a script you can run on a terminal; smart-home rules must be changed in the respective console):

1. Locate the 21:00 turn-off rule/linkage in the local engine
2. First "disable" and observe one night to confirm effect
3. After confirming, "delete" the rule
4. Go back to Mi Home app and confirm the cloud rule of the same name is also deleted (clear both ends)
5. Register in the "multi-platform rule mapping table": which engine has sole control of this light

Honest note: smart-home rule cleanup must be done in the corresponding consoles (Mi Home / geek edition / HA); there is no universal "one-click script". The above is a checklist for troubleshooting and cleanup, not copy-run code; the entry points differ by platform (Mi Home geek edition, Aqara gateway, Home Assistant).

Root cause — stop "incomplete deletion" from recurring

Clearing the rule on one device is only a stopgap. As long as the same device is co-managed by two engines, it will be hit again. Close it off in three layers:

Layer	Action	Prevents
Ownership	Route one device class's automation to a single engine (all to HA or all to geek edition); the other does manual/read-only	two engines issuing opposite commands, overwriting each other
Process	Set a "Dual-end sync cleanup SOP": for multi-platform co-managed devices, cleanup must delete cloud + local synchronously	cloud deleted but local remains, rules won't fully delete
Ledger	Build a "multi-platform rule mapping table" registering each device's sole control engine and platform	new automation collides with the other engine's rules

One often-missed point: the geek edition and the Mi Home app do not share "automations". The geek edition is a locally executed hard rule that runs even on power/outage; the Mi Home cloud rule depends on the network. So "cloud deleted but light still off" essentially means the local rule is the fallback executor — which is actually its reliable side; you just forgot it was still there.

Quick decision table (use it directly)

Symptom	First reflex (misjudged)	Real root cause	Where to look
Deleted Mi Home automation, light still off	bulb / gateway hardware fault	local engine (geek edition) still has the rule	geek edition scheduled tasks / linkage
Still on schedule after device reset	device remotely controlled	rule is on gateway, not the device	gateway / HA automation list
Light flickers on/off randomly	signal interference / zigbee drop	two engines' priority conflict tug-of-war	compare both engines' commands to the light
Stops after disabling local rule	problem gone	confirms local rule is the culprit	log 21:00 timestamp
Only off after going offline	cloud bug	local rule runs offline (as it should)	local engine, not a fault

This table is the landing version of "what it is most easily misjudged as" — eight out of ten tickets of this class open as "light broken" or "gateway glitch", and checking against this table skips most wasted effort.

FAQ

Q: I deleted the automation in the Mi Home app, so why does the light still turn off?
A: Because the rule that turns off the light is not in the Mi Home cloud — it lives in a second local rule engine (the geek edition or local gateway). The Mi Home app and the geek edition are two independent engines: deleting in the cloud leaves the scheduled task on the local gateway untouched. You deleted "the cloud copy"; the light is controlled by "the local copy", so it keeps turning off.

Q: How do I confirm which engine actually controls the light?
A: The most direct way is to temporarily remove the light from the local gateway/geek edition or disable its automation, and see whether it still turns off on schedule. The safer way is to log into the geek edition (or gateway) backend, open "Scheduled tasks" and "Scene linkage" logs, and compare the trigger records against the 21:00 time point — whichever log timestamp matches the light-off time is the culprit.

Q: Do the two engines fight each other? How is priority decided?
A: Yes. The Mi Home cloud rule and the geek-edition local rule can both control the same light; when they issue opposite commands to one device, you get a tug-of-war of "cloud turns on, local turns off". Many users think only the Mi Home app manages the light, but the local gateway keeps running its own rules — priority conflict is the common root cause of this "haunted light".

Q: Should I manage automation with Mi Home or with the geek edition / HA?
A: The key is not either/or, but "who has sole control". Route the automation of one device class to a single engine (e.g. all to Home Assistant or all to the geek edition), and let the other do manual control or read-only. The worst case is both engines writing rules for the same device — that buries two switches that overwrite each other.

Q: How do I avoid incomplete deletion in the future?
A: Set an SOP: for any device co-managed by multiple platforms, cleanup must delete from both "cloud + local gateway/geek edition" synchronously, and register each device's sole control engine in a "multi-platform rule mapping table". Before adding automation, check the table to ensure it will not collide with the other engine's rules.