ElectriFixHome Automation
Perth WA · worldwide remote
Updated 25 September 2026
Some devices in a house matter more than others. A light that turns on at the wrong time is annoying. A garage door that opens at the wrong time, a lock that doesn't lock, or an alarm that won't arm is a safety problem. So those devices are treated differently, in code, from the moment a job starts.
By default, the service refuses any change that involves:
"Involves" is read widely. A change is refused if it targets one of these directly, or if it runs a script, scene or automation that does. Reloading an integration is refused if that integration owns any of these devices or is named for one, because a reload restarts every device the integration owns. And if a change aims at a whole room, floor or label rather than named devices, it's refused too, because we can't prove from our read what that would reach. What that check can't see is what your own existing automations do in response to a change afterwards: they run on their own triggers, and nothing we can read tells us what they'll do next. That's why you test the device yourself after any change.
The honest answer is that a check you rely on a tired person to remember isn't a check. A plan that says "reload this integration" names the integration's type, not the devices behind it, and an integration with an ordinary-looking name can own a garage door. So the check doesn't read the plan's wording: it reads every device the integration owns, and refuses if any of them is on the list. That's enforced in code, not by a line in a checklist.
The service never operates these devices. It will not lock or unlock a lock, arm or disarm an alarm, open or close a garage door or gate, turn a camera on or off, or move a valve. Not as part of a fix, and not "just to test it". That's enforced in code, and no setting, tier or waiver changes it. If you connect through the ElectriFix Connect integration, it refuses those requests inside your own Home Assistant as well.
We also can't pair a device, type a password or credential, or set up an account with a manufacturer. Those need someone at the property with the device in their hands.
Sometimes the fault is the lock: an automation that should lock the door at night and doesn't, or a camera integration that won't load. For that, on the Repair & Build tier (A$179), you can lift the block for configuration only, for your job only, in up to three steps on your job page, in order:
I ACCEPT. It says what we will do, what we will never do, and that you own or control the premises.What that buys is configuration: repairing an automation that references your lock, reloading your camera integration, removing a dead registry entry for an old garage sensor. Every change is still shown to you first, still ticked by you one at a time, and still goes through the same snapshot-and-undo cycle as everything else. The block comes back when the job ends; a later job starts blocked again.
Two refusals stay even after the waiver: a change aimed at a whole area or label, and a reload where we can't read which devices the integration owns. In both cases nobody can say what the change would reach, so nobody can consent to it.
If we've changed anything that involves one of these devices, test it yourself before you rely on it. Walk to the door and try the lock. Watch the camera. Listen for the siren. A change that reads as applied isn't the same as a device that works, and only you are standing in front of it.
Because we can't see who's standing under it. A remote service operating a door, a lock or an alarm in a house it can't see is exactly the risk this rule exists to prevent.
Only if you're entitled to authorise changes to those devices. If you're a tenant, a housemate or a guest, ask the person who is.
No. On those tiers the block can't be lifted at all. Findings about these devices still appear in your report, so you know about them; you or someone at the house can act on them.