ESPHome Device v2.3 – RTI Driver

Control any ESPHome device from RTI – no Home Assistant required.

One driver for every ESPHome device. It connects straight to your ESP8266 or ESP32, finds everything it can do – lights, switches, dimmers, covers, fans, locks, buttons, numbers, selects, climate, and every kind of sensor – and gives you two-way control and feedback on your RTI panels and remotes.

It works with encrypted devices (the modern default). And because an ESP32 running ESPHome can act as a Bluetooth bridge, it even reaches BLE-only gear – adjustable beds, locks, sensors – that RTI can't control on its own.

WHAT THIS DRIVER IS

If your device runs ESPHome, this driver controls it – directly, over your network, with no Home Assistant, no cloud, and nothing to program by hand. Add the driver, point it at the device, click one button to import every control by its real name, and drag those onto your pages. That's the whole job.

WHAT'S NEW IN 2.3

It now notices if the device stops listening. Previously the driver treated any incoming data as proof the connection was healthy. Most ESPHome devices publish sensor readings on their own schedule, so that traffic kept arriving even in the rare case where the driver's own commands were no longer getting through, and the driver had no way to tell the difference. It now checks that the device actually answers, and rebuilds the connection within about 45 seconds if it stops answering. Nothing to configure.

Every command is confirmed onto the network. If the processor ever refuses a send, the driver detects it, keeps the secure session in step with the device, and recovers instead of carrying on as though the command went out.

Recovery is guaranteed. Rebuilding the connection is now scheduled no matter what else happens while the old one is being torn down.

It reports for itself in the System Log. The driver now writes to the processor's System Log (Integration Designer, enter the processor IP, System Log), including a short status summary every minute for the first five minutes after a reload and every five minutes after that, so there is something to look at whenever you happen to check rather than only in the seconds after a reload. Real faults are always logged regardless of the Debug Level.

New status variables for diagnosing a link at a glance: Mute Recoveries, Connect Stalls, Watchdog Trips, and Last Handshake ms.

WHAT'S NEW IN 2.2

Rock-solid under load. A device with lots of controls sends the state of everything at once the moment it connects. The driver now takes that in small batches instead of all in one go, so it never ties up the processor or loses its own connection while catching up – it stays responsive even on a busy system running many drivers.

Smarter reconnect timing. If a connection ever stalls, the driver now retries in step with the device's own timeout, so it recovers quickly instead of waiting too long.

Cleaner disconnects. When you reconnect or the processor reboots, the driver now tells the device it's leaving, so the device frees the connection right away and the next connect is clean.

WHAT'S NEW IN 2.1

Self-healing connection. If the secure connection ever stalls while connecting – for example right after the device reboots – the driver now notices and reconnects on its own, instead of sitting there until you reload it.

Everything from 2.0 still applies: one-click AutoConfig, support for encrypted devices, and very light CPU once the one-time key exchange is done.

SET IT UP

You do everything in Integration Designer – no app, no terminal.

1. Add the driver and enter the connection settings. Add one ESPHome Device driver per device, select it, and fill in its settings:

Device IP Address – your device's IP, e.g. 192.168.1.50. Give it a static IP or DHCP reservation so it never changes. (RTI connects by IP, not a hostname.)

Port – leave at 6053 (the ESPHome default).

Encryption Key – paste your device's base64 key (see Finding your encryption key below). Leave blank only for older, unencrypted devices.

License Key – paste your purchased key, or leave it blank to start the 2-hour free trial.

Startup Delay (seconds) – leave at 45 for now (explained in Options).

2. Import your controls – click "Get Config from ESPHome Device". With the driver selected, look in the Driver Configuration panel (left side, just below Driver Info) and click Get Config from ESPHome Device. It's a normal single click.

The driver connects, reads every control on the device, and creates functions and feedback variables labeled with the device's real names – "Living Room Lamp On," "Bed Head Up" – grouped by type. No guessing what a button does, and no slot numbers to fill in by hand. Run it again any time the device's controls change.

3. Place your controls. Drag the named functions onto your page buttons (e.g. Bed Head Up) and bind the named variables for feedback. Done.

4. Give the first connection a minute or two. Watch Connection State and Status Text. After a reboot, an encrypted device takes up to a minute or two to come online – this happens only once per reboot:

First it waits out the Startup Delay so your other drivers finish booting. Status Text shows "Waiting 30s before connecting..."

Then it makes its secure connection (the only slow step). Status Text then shows "Connected - N entities".

After that it stays connected, and day-to-day button presses and feedback are instant. The startup wait only happens after a processor reboot or driver reload.

About that first connection – high CPU is normal. Encrypted devices do a one-time security handshake (an elliptic-curve key exchange) when they connect. On RTI hardware that handshake is heavy: it briefly pushes this driver's CPU high (and bumps its memory) for the ~20–30 seconds it runs. This is expected, it is a one-time cost paid only on connect, and it self-recovers – the moment the handshake finishes, CPU drops back to near zero and stays there. You'll see the same brief spike if the device reboots and the driver reconnects. The Startup Delay above exists to hold this handshake off until your other drivers have finished booting, so it has the processor to itself. If you run many drivers on one processor, raise the Startup Delay (90–120s) so the handshake never competes with the boot. (Plaintext devices skip the handshake entirely and connect instantly.)

FINDING YOUR ENCRYPTION KEY

Modern ESPHome devices have API encryption on by default – for those the key is required (the device won't connect without it). You do not need Home Assistant to get it; it lives in the device's own ESPHome config:

From the ESPHome Dashboard (the usual way): open the device you flashed and look at its YAML (often secrets.yaml). The key is under:

api:

encryption:

key: "<your 44-character base64 key>"

Copy that exact 44-character value into Encryption Key.

From Home Assistant (only if you use it): Settings - Devices & Services - ESPHome - (your device) - Encryption key.

The key is write-only on the device – it can only be read from your config, never pulled back off the ESP. If it's lost, re-flash the device with a new key. If a device needs a key and the field is empty, Last Error says so; paste the key and it reconnects on its own.

OPTIONS

Startup Delay (seconds) – how long to wait after the processor boots before connecting (default 30, range 0–300). Encrypted devices do a one-time, CPU-heavy security handshake on connect, so delaying it lets your other drivers finish booting first and gives the handshake room to complete. Raise it on a heavily-loaded processor (90–120); lower it (even to 0) if you want the device online sooner on a quiet one.

API Password – only for legacy devices that set a plaintext API password. Most devices use the Encryption Key instead; leave this blank if yours has none.

Debug Level: how much detail the driver writes to the processor's System Log (enter the processor IP in Integration Designer, then click System Log). Low is the default and is right for normal use: it includes the five-minute status summary, which is what makes the log worth opening later. Raise it to High only while troubleshooting. Real faults are always logged regardless of this setting.

WHAT YOU CAN CONTROL

AutoConfig surfaces only the controls your device actually has, named for what they are:

Lights / dimmers: On, Off, Toggle, Set Brightness – with on/off and brightness feedback.

Switches / relays: On, Off, Toggle + state.

Covers / shades / garage doors: Open, Close, Stop, Set Position + position and operation feedback.

Fans: On, Off, Set Speed + speed feedback.

Locks: Lock, Unlock, Open + lock-state feedback.

Buttons: Press – fire any momentary control on the device (great for BLE-bridged gear like beds).

Numbers: Set Value (sliders, setpoints) + value, min/max feedback.

Selects: Set By Index (choose from the device's option list) + current selection.

Climate / thermostats: Set Mode, Target Temp, Target Temp Range, Fan Mode, Swing Mode, Preset + current temperature, target, action, and mode feedback.

Sensors / binary sensors / text sensors: read as values, on/off states, and text.

The driver also raises events – Connected, Disconnected, Entities Discovered, State Changed, plus license and trial events – so device changes can trigger RTI macros.

A note on safety: AutoConfig automatically omits the device's Factory Reset and Safe Mode buttons (nobody needs those on a touchpanel) and tucks ESP Restart into a System category alongside Reconnect and Refresh All.

MANUAL SETUP (OPTIONAL – WITHOUT AUTOCONFIG)

The driver works the moment you add it, even before you run AutoConfig: discovered controls fill numbered slots by type, and each slot's ..._Name variable shows the control's real name. Bind your pages to the slot variables (for example Light01_Name, Light01_State, Light01_Brightness, Cover01_Position, Climate01_CurrentTemp) and drive them with the slot command functions, picking the slot number from each function's dropdown.

Heads-up: slots are ordered alphabetically by name, so a "Button 1" isn't always the one you'd expect. Check the matching Button##_Name variable before assigning a Button Press – or just use Get Config, which names every button for you and hides the dangerous ones.

IF IT WON'T CONNECT

Check Last Error first – it names the problem in plain language:

"requires an encryption key" – the device is encrypted; paste its key into Encryption Key.

"Could not reach ESPHome device..." – check the IP address, that the device is powered and on your network, and that the Port is 6053.

A handshake that stalls now retries on its own (new in 2.1) – give it the minute-or-two startup window before assuming it failed.

Two System functions are always there if you need them: Reconnect (drop and rebuild the link) and Refresh All (re-pull every control's current state).

IF IT CONNECTS BUT NOTHING RESPONDS

If Connection State reads true, the controls were found, and yet nothing happens when you press a button, check Mute Recoveries. From 2.3 the driver watches for this itself: it confirms the device is still answering, not just still sending, and rebuilds the link within about 45 seconds if it goes quiet. A count above 0 means that happened and was handled.

If the count keeps climbing, the link is being rebuilt repeatedly. Raise Startup Delay and check Last Handshake ms: on a processor running many drivers, the secure handshake needs room to finish, and Connect Stalls rising alongside it points at the same cause.

STATUS & LICENSING

The Status variables show connection state, device info (name, model, MAC, ESPHome version), how many controls were found, and the reconnect count. The Licensing variables show your trial or license status. The driver reconnects on its own if the device drops, and it verifies that the device is still answering rather than only that it is still talking, so a link that stops accepting commands is rebuilt automatically.

Four counters are there for diagnosing a link at a glance. All four sitting at 0 on a connection that has been up a while is exactly what a healthy system looks like:

Mute Recoveries: times the device stopped answering and the link was rebuilt.

Connect Stalls: connection attempts abandoned because the secure handshake did not finish in time. On a heavily loaded processor, raising Startup Delay gives it more room.

Watchdog Trips: times the device went completely silent.

Last Handshake ms: how long the last secure handshake took. Useful for judging whether a processor is under load, since the handshake is the most CPU-heavy thing the driver does.

LICENSE

The driver runs for 2 hours per processor as a free trial. To license it permanently, purchase a key at customcontroldrivers.com and paste it into License Key. The license is locked to that processor.

SUPPORT

Questions or issues: support@customcontroldrivers.com

– Custom Control Drivers LLC customcontroldrivers.com