Smart Opener and Network Setup Handover

Purpose

Connecting a door does two things at once. It gives the household a door they can watch from anywhere, and a door they can close from anywhere, including from where they cannot see what is under it. This SOP guarantees the second capability is only ever enabled on an operator listed for it, and that the account holding the keys to the house belongs to the customer rather than to a previous tenant or a technician's phone.

Without it two failures recur: a gateway bolted onto an old operator so a phone can close a door with no warning device on it, and an account left attached to whoever set it up first.

Scope

Covers connected residential and light commercial operators, whether the radio is built into the head or added as a separate gateway, through app pairing, account ownership, feature configuration and handover.

Does not cover transmitters, keypads and the operator's radio memory (garagedoor-keypad-and-remote-programming-handover) or the limits, forces and entrapment tests that gate this work (garagedoor-limit-and-force-verification-after-a-repair), nor commercial access control through a card reader or building system. The technician does not create customer accounts and never handles customer passwords.

Roles and responsibilities

Role Owns Hands off
Dispatcher Asking whether the property changed hands or tenants, and whether an app is already attached Puts prior-occupant risk on the ticket so the tech plans an account audit, not just a pairing
Lead technician The unattended-operation gate, network checks, pairing, configuration, handover Does not enable app close on an operator not listed for unattended operation
Customer Creating and holding the account, entering their own credentials, removing users Confirms in front of the tech that they can remove a user
Service manager Quoting a listed operator when the existing head cannot support the feature Owns the conversation when the customer wants something the head cannot legally do

What connecting a door actually changes

Three capabilities arrive in one app, and they carry very different risk.

Capability What it adds What it requires
Status and notification The customer sees open or closed and gets alerts A working sensor and network, nothing more
Remote open The door opens from the app Ordinary care; an opening door traps nobody
Remote or scheduled close The door closes with nobody watching An operator listed for unattended operation, with the 5 s pre-motion audible warning and visual indicator that listing requires

Remote close is the whole risk. An operator never listed to UL 325 for unattended operation has no warning device, so a door closing on an app command gives a person underneath no notice. That is why step 2 gates the visit.

Procedure

1. Prove the entrapment protections before enabling anything remote. Run the contact reversal and photo-eye tests under garagedoor-limit-and-force-verification-after-a-repair and record observed values. Acceptance is a recorded pass on both, taken today, not a note that they were fine last visit. Stop rule: a door failing either test gets no connectivity configured, because remote close on a door that will not reverse is the combination this trade gets sued over. Hazard: these tests drive the door onto an obstruction, so the opening stays clear and nobody's hand is ever it.

2. Establish whether the operator is listed for unattended operation. Read the head's label and the manual for that model and serial range for the warning device a UL 325 unattended-operation listing requires, which 16 CFR Part 1211 binds on residential operator makers: an audible alarm sounding for at least 5 seconds before the door moves and continuing throughout its travel, plus a visual indicator, with the manual governing where it specifies longer. Acceptance is a documented yes or no with the source named. Wrong looks like assuming a gateway confers the listing on the head it is bolted to. Stop rule: on a "no", remote and scheduled close are not enabled, configuration is limited to monitoring and open, and a listed operator is quoted. Hazard: none physical, a read at the head with the door parked.

3. Confirm the network will carry it before you pair. Most opener radios join a 2.4 GHz network only. Check that a 2.4 GHz SSID is reachable at the head, at ceiling height rather than at the floor. Acceptance is a usable signal measured at the head. Wrong looks like a band-steered SSID handing the radio a 5 GHz association, which fails pairing with no useful error. Stop rule: no usable 2.4 GHz at the head means an access point is needed first, and the ticket says so rather than the tech fighting pairing for an hour. Hazard: work off a rated platform, not off the door or a vehicle roof.

4. Have the customer create and hold the account. They enter their own email and password on their own device. Acceptance is an account the customer created and is logged into, with the tech never having seen or typed the credentials. Wrong looks like a tech creating an account "to get it working" and handing over a password. Stop rule: if the customer is not present, pairing waits, because an account created for them is one the shop is now responsible for. Hazard: none physical, a step at the kitchen table.

5. Pair the operator and confirm it reports state correctly. Follow the manual's learn sequence, then open and close from the wall control and watch the app. Acceptance is app status matching real door position on a full open and a full close, checked by eye at the door, not from the app. Wrong looks like a status stuck on open after the door closes, usually a position sensor on the wrong section or angle. Stop rule: a status that does not track the door is fixed here, because every later feature is built on it. Hazard: the door is cycling, so the opening stays clear.

6. Audit the account for people who should not be on it. With the customer driving their own device, list every user, guest, linked service and paired device. Acceptance is a list the customer can name every entry on. Wrong looks like a linked account from a previous tenant, a builder, or a module in a traded-in car. Stop rule: anything unexplained is removed by the customer during the visit, and an account predating their occupancy gets a full reset and a fresh one. Hazard: none physical, but never perform removals from your own device or under your own login.

7. Test the close path exactly as configured, from outside the garage. With remote close enabled, command a close from the app while standing outside the opening, confirm the audible warning runs for at least the 5 seconds step 2 named before the door moves and throughout its travel, with the visual indicator running, then break the photo-eye beam mid-close from outside and confirm full reversal. With remote close disabled under step 2, attempt it anyway and confirm the door does not move. Acceptance is the warning heard and seen with reversal observed, or an attempted close producing no movement. Stop rule: a close command that moves the door with no warning running means remote close is switched off before you leave. Hazard: nobody stands in the opening during any app-commanded cycle, and the customer watches from beside you.

8. Configure the rest conservatively and demonstrate each feature. Set notifications for open, closed and left-open, and treat any scheduled or automatic close as off by default unless step 2 returned a yes and the customer asks. Acceptance is each enabled feature demonstrated once in front of the customer. Wrong looks like a timer-to-close switched on because the app offered it. Stop rule: an automatic close on a head that failed step 2 is never enabled, whatever the customer requests, and the refusal goes on the ticket. Hazard: a scheduled close is an unattended close and inherits every gate in step 2.

9. Hand over the failure modes, not just the features. Show what happens when the network drops, that the wall control and transmitters keep working regardless, how to remove a user, and how to release the door by hand with it DOWN. Acceptance is the customer performing a user removal and a manual release and re-engagement while you watch. Wrong looks like a verbal explanation with nobody touching anything. Stop rule: a customer who cannot perform the release is not signed off until they can. Hazard: demonstrate the release only with the door down. The counterbalance is what holds a door up, so a correctly balanced door stays put when the carriage lets go; a weak, mis-adjusted or broken spring leaves the door heavier than its counterbalance, and that door drops.

The record this produces

  • Fields: operator make, model and serial; today's entrapment results with observed values; the unattended-operation answer with its source, label or manual; network band and signal at the head; who created the account and on which device; pairing result with the state check on a full open and close; the audit list with anything removed and by whom; features enabled and features refused with the reason; the close-path result including the warning lead time observed; and the customer demonstrations completed.
  • Where it lands: the door's equipment record against the operator serial. No customer credentials are recorded anywhere, ticket notes included.
  • Who reads it later: the next tech asked why the app cannot close the door, the manager if a security complaint arrives after a tenant change, and the customer's own record of who had access that day.

Worked pass: rental turnover on an older head, one failed step

Detached garage, single 9 by 7 door, chain-drive head with a date code in the middle 2000s. The new owner had bought a third-party gateway and wanted to close the door from work.

Step 1 passed: contact reversal on the 1 in object that 16 CFR Part 1211 uses for its compliance test, with full return to open, and photo-eye reversal on three separate closes, all recorded with observed values.

Step 2 failed and took its stop rule. The label and manual for that serial range showed no audible or visual warning device and no unattended-operation listing. The gateway's box advertised remote close regardless. A gateway confers no listing on the head it is bolted to, so remote and scheduled close were not enabled. A listed operator was quoted and the visit continued on a monitoring and open-only configuration.

Step 3: the router broadcast one band-steered SSID and the radio would not associate. The customer split off a 2.4 GHz SSID on their own router, signal at ceiling height was then usable, and pairing went ahead.

Step 4: the customer created the account on their own phone and typed their own password; the tech never saw it. Step 5: paired, then a full open and a full close watched at the door with the app checked against each, status tracking correctly both ways.

Step 6: the account was new, so the audit list held one user and one device, both named by the customer, and nothing was removed. Step 7: with remote close disabled, an app close was attempted from the driveway and the door did not move, which is the acceptance for that branch. The open path was tested once from the same position with the opening clear.

Step 8: notifications set for open, closed and left-open, each demonstrated once. No scheduled close, and the refusal and its reason were written on the ticket rather than left verbal. Step 9: the customer removed a test user themselves, then pulled the release with the door DOWN, worked the door by hand and re-engaged it.

References

  • 16 CFR Part 1211 and the UL 325 listing it incorporates, binding manufacturers of operators made on or after January 1, 1993. Unattended operation and the warning it requires are properties of the listed operator; the manual and label for that model state whether a given head has them, and the manual's figure for the pre-motion warning governs at the door.
  • Manufacturer documentation for the operator and for any add-on gateway, which states supported network bands, the learn sequence, and any feature the gateway cannot legitimately enable on an unlisted head.
  • See related: garagedoor-limit-and-force-verification-after-a-repair and garagedoor-keypad-and-remote-programming-handover.