Nice G.O. Gate v1.0

Two-way control of Nice-family gate openers, garage door openers, and connected accessories for RTI XP-8 processors.

Works across the Nortek-owned brand family: Nice, Mighty Mule, Linear, and Entrematic. Two operating modes:

Cloud mode (production-ready) — works for any device paired with the Nice G.O. or Mighty Mule app. This is the recommended path for the vast majority of installs.

Local mode (beta, requires Nice IT4WIFI hardware) — talks directly to the IT4WIFI module on the LAN, no cloud dependency. See the Local Mode Beta section below before relying on it.

Supported equipment

The general compatibility rule: if the equipment pairs with the Nice G.O. or Mighty Mule phone app, this driver can control it in Cloud mode. That covers every Nortek/Nice gate or garage door product line.

Gate operators

Mighty Mule MM371W / MM372W / MM571W / MM572W (W-suffix models have WiFi built-in; non-W models need the MMS100 Wireless Connectivity Kit to pair with Nice G.O.)

Nice gate motors paired with Nice G.O. via the IT4WIFI accessory or any Nice gateway

Linear gate operators using Nice G.O. cloud pairing

Garage door openers

Nice / Linear LDCO841, LDCO850, LDCO852, LDCO863b

Nice G.O. WiFi Wallstation

Mighty Mule MM9333H, MM9434K, MM9545M, MM9555M

Entrematic Amarr840, Amarr860

Verified vs expected compatibility

Verified on real hardware: Mighty Mule G.O. cloud path (full open / close / status / live state updates).

Expected to work (same Nice G.O. cloud API): every other product in the list. If you install on a model not listed above and run into anything unexpected, please reach out — Custom Control Drivers will fix any compatibility issue free of charge, typically within a day or two.

Quick start

Decide which mode fits your install

Local mode — choose this if the gate has a Nice IT4WIFI module installed. Talks directly to the IT4WIFI on the LAN over TLS. No internet required for day-to-day operation; survives any cloud outage Nice / Nortek may have. This is the most defensible install long-term.

Cloud mode — choose this for any Mighty Mule gate, any Linear or Entrematic garage door, or any Nice gate without an IT4WIFI, where the customer already uses the Nice G.O. (or Mighty Mule) phone app. Auth routes through the Custom Control Drivers relay (one-time per session) and then the driver talks to Nice's real-time push API directly. Receives state changes the instant they happen.

Mix-and-match is fine across separate driver instances — install one driver instance per gate or garage door system.

Cloud mode setup

1. Open Driver Properties for the Nice Gate Driver instance.

2. Set Connection Mode to Cloud (Nice G.O. account).

3. Under Cloud Mode Settings, enter the same email and password the customer uses for the Nice G.O. or Mighty Mule app.

4. Leave the Relay URL at its default unless you operate your own relay.

5. Save. The driver will fetch tokens, connect to Nice's push API, and populate all discovered gates and openers within ~10 seconds.

The driver refreshes tokens periodically (every ~30 min) from the Custom Control Drivers relay. Credentials transit the relay only at authentication time and are never logged or stored.

Local mode setup (beta — see disclosure below)

1. Verify the gate controller has a Nice BusT4 (Opera) port — typically a small RJ-11 / RJ-12 jack labeled BUS or BUST4. Many Mighty Mule consumer boards (MM571W, MM572W) do not expose this port and are therefore Cloud-only. Check the controller before purchasing IT4WIFI hardware.

2. Install the Nice IT4WIFI module per Nice's installer documentation (connects via RJ-11 to the BusT4 port, gets power from the gate controller).

3. In the IT4WIFI app on a phone, confirm the IT4WIFI is paired to the gate and showing in the app.

4. Note the IT4WIFI's LAN IP from your router's DHCP table (or the IT4WIFI app).

5. Note the pairing code shown in the IT4WIFI app under device setup — this is required for the initial handshake.

6. In Driver Properties, set Connection Mode to Local (IT4WIFI on LAN).

7. Under Local Mode Settings, enter the IP, username (usually admin), and pairing code.

8. Save. The driver will connect, complete the SHA256 challenge handshake, and start receiving push events for state changes.

Local Mode Beta — what "beta" means here

The local-mode path was implemented against the published Nice IT4WIFI protocol spec (cited from the working PatrikTrestik Home Assistant integration), but has not yet been validated on real IT4WIFI hardware in v1.0. The code is structurally complete — STX/ETX framing, SHA256 challenge-response auth, signed messages — but Custom Control Drivers has not yet had an IT4WIFI module on hand to verify against.

What you can expect:

The handshake and door open/close commands should work as documented (they exactly mirror a proven open-source reference).

Light control and vacation mode commands use element names guessed from the protocol; they may need adjustment for your specific hardware.

TLS-related connectivity issues are possible if the IT4WIFI's older TLS stack rejects the RTI processor's handshake.

If you hit any issue in Local mode: open Force Reconnect to fall back to Cloud mode, then email support with the trace. We will fix it free of charge — typically same-day — and publish an updated driver. Cloud mode is the production-tested path; treat Local mode as a low-latency optimization for advanced installs.

Capabilities

Per-barrier commands (up to 10 barriers)

| Command | Description |

|---|---|

| Open Barrier | Drive the gate or door to its fully-open position |

| Close Barrier | Drive the gate or door to its fully-closed position |

| Stop Barrier | Halt mid-travel (where the motor supports it) |

| Toggle Barrier | Open if closed/closing, close if open/opening |

| Light On / Off / Toggle | Control the gate or opener light output |

| Enable / Disable / Toggle Vacation Mode | Block automatic operation for security |

By-name commands

For voice macros and dynamic UI: Open Barrier By Name, Close Barrier By Name, Stop Barrier By Name, Light On By Name, Light Off By Name. Names match either the override set in Driver Properties or the name reported by Nice.

Master commands

Open All Barriers, Close All Barriers, All Lights On, All Lights Off, Enable Vacation Mode (All), Disable Vacation Mode (All).

System commands

Refresh State (force a fresh poll), Force Reconnect (recycle the connection — useful after credential changes), Clear Cache (wipe persistent state; preserves the trial counter).

System variables (per barrier, slots 01-10)

Every barrier exposes 22 sysvars for maximum binding flexibility:

Identity & availability: Available, Display Name, Discovered Name, Device ID

Status (integer + text): Status Code (0=Closed, 1=Opening, 2=Open, 3=Closing, 4=Stopped, 5=Obstructed, 6=Unknown), Status Text

Status (booleans) — for templated buttons and condition logic: Is Open, Is Closed, Is Opening, Is Closing, Is Stopped, Is Stationary, Is Moving, Is Obstructed

Light: Light On (boolean), Light State Text ("On" / "Off")

Vacation: Vacation Mode (boolean), Vacation State Text ("Active" / "Inactive")

Connectivity: Online, Firmware Version

Last operation: Last Operation Epoch, Last Operation Text

System variables (aggregate)

Barrier Count, Online Barrier Count, Open Barrier Count, Closed Barrier Count, Any Barrier Open, All Barriers Closed, Any Barrier Moving, Any Barrier Obstructed, All Barriers Online, Any Light On, Any Vacation Active.

Plus driver status: Connection State, Connection Mode, Connection Mode Text, Last Error, Driver Version, Last Update Text, Last Update Epoch.

Plus licensing: License Valid, License Status Text, Trial Minutes Remaining.

Events

Every barrier signals on state transition:

Opened, Closed, Opening, Closing, Stopped, Obstructed, Light On, Light Off, Vacation On, Vacation Off, Online, Offline.

System-level: Connected, Disconnected, Connect Failed, Auth Failed, API Error, Rate Limited, License Valid / Invalid, Trial Expiring / Expired, Any Barrier Opened, All Barriers Closed, Any Barrier Obstructed, All Barriers Online, Any Barrier Offline.

Debug console

Telnet to the processor IP on port 12511 (default) for live diagnostics:

telnet <processor-ip> 12511

> help

> state

> barriers

> license

> open 1

> close 1

> log med

> quit

The debug port is configurable under the Debug category in Driver Properties.

How Cloud mode works (and why we built it this way)

Cloud mode authenticates against Nice's servers using AWS Cognito SRP — a cryptographic challenge-response handshake that protects the customer's password from ever travelling over the wire in any recoverable form. SRP requires large-integer modular exponentiation, which RTI's embedded JavaScript runtime cannot perform natively.

Beyond SRP, AWS's web-application-firewall in front of Nice's GraphQL real-time API rejects RTI's TLS-handshake fingerprint with a 307 redirect (it accepts the same payload from modern Node.js / browser clients). The driver cannot reach the cloud API on its own.

To bridge both gaps, Custom Control Drivers operates a TLS-encrypted relay server that does the SRP handshake on the driver's behalf and proxies the GraphQL real-time WebSocket between the driver and Nice. The relay is in the path for the lifetime of the connection — not just for auth.

What happens when you save Cloud mode credentials

1. The driver opens a TLS-encrypted connection to the Custom Control Drivers relay

2. The driver sends the customer's Nice G.O. email + password over that secure channel

3. The relay performs the Cognito SRP handshake against Nice's servers and obtains the customer's authentication tokens

4. The relay opens its own WebSocket to Nice's real-time GraphQL API on the customer's behalf

5. The driver receives gate-state updates and sends gate commands through the relay — all over TLS end-to-end

What the relay does NOT do

It does not persist the customer's password to disk (used once for the SRP handshake, then immediately discarded from memory)

It does not log the customer's password (only the email is recorded, and only for support diagnostics)

It does not share gate traffic across customer sessions (each customer's connection is fully isolated)

It does not get in the way of latency — measured response times are faster than the Home Assistant Nice G.O. integration

The relay infrastructure is operated by Custom Control Drivers, hosted on Fly.io, and the source is available on request for any installer who wants to audit the privacy guarantees themselves. If you prefer no internet path at all, use Local mode with the IT4WIFI accessory (when local-mode beta status fits your install).

Trial mode and licensing

There are two independent trial mechanisms at play. Both let you evaluate the driver freely before purchase — they protect different things. The shorthand sometimes used elsewhere ("15/hr") is rate-per-hour, NOT a duration.

Driver trial — 120 minutes of full driver use

The instant the driver loads on a processor, a 120-minute wall-clock trial starts. During those 120 minutes, every command and feature works exactly as a licensed driver — open / close commands, sysvar updates, event signaling, both Local and Cloud modes. When the 120 minutes elapse, all commands block locally with "License required" until a valid license key is pasted into the Licence Key field.

The trial is per-processor (MAC-bound) and does not reset across reboots, driver reloads, or cache clears. You get one 120-minute window per processor — use it for evaluation.

Cloud relay rate limit — 15 authentication attempts per hour (Cloud mode only)

Separately from the driver trial, the relay that handles Cognito authentication for Cloud mode limits unlicensed callers to 15 cloud authentication attempts per hour per IP address. This is rate-per-hour, not a duration — it means "the relay will perform up to 15 fresh Cognito handshakes per IP per hour" before refusing additional ones.

A single driver running steady-state hits the relay's auth endpoint roughly once per driver-load — once the TLS-TCP connection is established and the relay's WebSocket to Nice is up, the relay refreshes the customer's Nice tokens internally without involving the driver. In normal operation a driver might re-auth 1–2 times per day (after a planned reboot or genuine network outage). 15 attempts per hour is orders of magnitude more than legitimate use requires and you will never hit this limit in production. The only time you encounter it is during initial setup when you might be reloading the driver every couple of minutes to dial in settings — eventually a heavy debug session can exceed the limit.

If you hit it during setup, the trace shows:

Cloud auth rejected: IP rate limit (15/hr trial)

Two ways to clear it: wait for the current hour to roll over, or paste a valid license into the Licence Key field. Licensed callers get 50 cloud authentications per hour per IP plus 200 per day per license, which exceeds any realistic install scenario by a wide margin.

Activating your license

Paste the license key from your purchase email into the Licence Key field under Licensing. The license is bound to the processor's MAC address (visible in the License sysvar after install).

Troubleshooting

"Cloud auth failed: invalid credentials" — wrong email or password. Confirm by logging into the Nice G.O. app with the same credentials. Use Force Reconnect after fixing.

"IT4WIFI auth rejected - check pairing code" — the pairing code from the IT4WIFI app didn't match. Re-check it in the IT4WIFI app; pairing codes are case-sensitive.

"Lost contact with gate" — the watchdog hasn't seen traffic in too long. Driver auto-reconnects with backoff. Check the gate is powered and on the network.

"Cloud auth rejected: IP rate limit (15/hr trial)" — the relay has already performed 15 fresh Cognito authentications from this IP address within the current hour. The "15/hr" notation means 15 authentications per hour, not a 15-hour duration. This only happens during aggressive debug reloads — normal operation only triggers ~2 authentications per hour. Either wait for the hour to roll over, or activate your license to move to the licensed tier (50 authentications per hour per IP).

Cloud mode but no events arriving — the AppSync WebSocket may have been blocked. Check that outbound TCP 443 is open from the processor; the driver will log "Cloud WS keepalive timeout" if so.

"License required: license MAC mismatch" — license was issued for a different processor. Contact support with the MAC shown in the error.

Trial expired during testing — license keys can be reissued; contact support. Note that ClearCache does NOT reset the trial (this is intentional).

About Custom Control Drivers

Built and supported by Custom Control Drivers LLC. Updates and support at https://customcontroldrivers.com.

This driver is part of the Custom Control Drivers SDK driver family — every driver in the family uses the same trial mechanism, license format, and update cadence so integrators only learn it once.