Announcer

v1.0 - Custom Control Drivers LLC

Turn your RTI processor into an audio-announcement server. The processor hosts a small library of audio clips and plays them on your Sonos or other UPnP/DLNA speakers on demand - no NAS, no extra hardware, no cloud. Any RTI event can trigger an announcement: a doorbell press plays "Someone is at the front door," a camera detects motion and a speaker says "Motion in the driveway," a gate contact announces an arrival. You supply the clips (paste your own, or pick a built-in), name your speakers, and wire the Announce function to whatever events you like.

Requirements

· An RTI XP processor (firmware v24+).

One or more Sonos speakers, or other UPnP/DLNA renderers (Denon/HEOS, Yamaha MusicCast, WiiM, many AVRs).

The speakers and the processor must be able to reach each other on the network. The speaker fetches the clip *from* the processor, so this must work in both directions. Putting the speakers on the same subnet/VLAN as the processor is strongly recommended. If they are on a separate VLAN, you must allow traffic both ways (processor to speaker on port 1400, and speaker to the processor on the HTTP port you set below) on your firewall, and set the Advertised Host/IP option.

Setup

1. Server. Leave HTTP Port at 8080 (any free port above 1024 works). Leave Advertised Host/IP blank unless your speakers are on a different subnet (see Requirements).

2. Clips. Under Clips, name each clip you want (e.g. "Front Door"). For each named clip either pick a built-in Default Clip, or paste your own audio as base64 into Clip Audio (see "Preparing your own clips" below). Each new clip slot appears after you name the previous one.

3. Speakers. Under Speakers, name each target (e.g. "Family Room") and enter its IP Address. Find a Sonos IP in the Sonos app under System > [speaker] > About, or in your router's client list. Give each speaker a DHCP reservation so its IP doesn't change. Leave Resume After on to have the speaker return to what it was playing once the announcement finishes (best-effort - see notes).

4. Transfer the system. The clip server starts automatically.

5. Wire it up. In your macros, call Announce and pick a Clip and a Speaker from the dropdowns. Trigger it from a doorbell, camera, gate, alarm - anything.

Preparing your own clips (base64)

The Clip Audio field takes the base64 encoding of an MP3 file - that is, the encoded bytes of an actual .mp3, NOT base64 of typed text. Encoding a sentence like "Someone is at the front door" as text will NOT work; the speaker will reject it with "can't play, not encoded correctly". You must encode a real audio file.

How to prepare a clip:

1. Get or make a short MP3 (a few seconds; a doorbell chime or a spoken phrase). Keep it small - the field accepts roughly 32,000 characters of base64, which is about a 24 KB MP3 (more than enough for a short clip). Mono, 64 kbps is plenty.

2. Convert the MP3 file to base64 using any "file to Base64" encoder. A free one that works: base64.guru - go to Converter, set Datatype to Local File (or use the "File to Base64" tool), upload your .mp3, and choose Output Format = Plain text. (If you use a "Text to Base64" tool by mistake you'll encode the words, not the audio - that's the #1 reason a custom clip won't play.)

3. Copy the resulting base64 string and paste it into the Clip Audio field for that clip.

4. Transfer the system (or run the Reload Clips function). The clip's status shows "Ready" with its byte size, and it appears at its served URL.

Tip: to verify a clip without a speaker, browse to `http://<processor-ip>:<HTTP Port>/` for the status page, where each ready clip is downloadable for a quick listen.

What the driver gives you

The headline function - Announce(Clip, Speaker) - play any clip on any speaker. Plus Stop, Stop All, and Test Speaker.

Per-clip feedback - name, ready state, source (pasted vs built-in), byte size, the URL it's served at, and last-played info.

Per-speaker feedback - name, IP, reachable, currently playing, last result.

Aggregates - clips ready, speakers configured, any playing, plus a one-line System Health for a panel header.

Events - Announcement Played / Failed, per-speaker Played / Failed / Resumed, server started / failed, clips reloaded, plus trial/license events.

The signature automation: a UniFi Protect doorbell press fires a macro that calls Announce("Front Door", "Family Room"), and the whole house hears "Someone is at the front door" - then the music it interrupted comes back on.

v1.0 scope notes

· Resume is best-effort. After an announcement the driver tries to restore what the speaker was playing and where it was. This works well for music playing from the Sonos queue or a local/file source. Live radio and streaming-service sources (Spotify, Pandora, TuneIn, etc.) often cannot be resumed by design - the announcement will play, but the speaker may stay stopped rather than resume the stream. Turn Resume After off for any speaker where you don't want the attempt.

Grouped speakers: target the group's coordinator. Restoring grouped-room state is limited; announce to individual rooms for the most reliable behavior.

Clip size: keep clips short (a few seconds). Pasted clips are limited by the config field (about 32,000 base64 characters, roughly a 24 KB clip). Built-in defaults and short custom chimes are well within this.

Playback interrupts current audio to play the clip, then resumes (per above). That's the intended doorbell/alert behavior.

Troubleshooting

The announcement doesn't play and Last Result shows a connect failure.

Check the speaker's IP and that it's reachable from the processor. The most common cause is the speaker being on a different VLAN than the processor - put them on the same subnet, or open the firewall both ways (see Requirements).

Last Result shows the command succeeded (200) but you hear nothing.

The speaker accepted the command but couldn't fetch the clip from the processor. This is almost always a network-reachability problem in the speaker-to-processor direction (VLAN/firewall), or the speaker's volume is down. Confirm both devices are on the same subnet.

A clip shows "decode FAILED" or "not ready," or the speaker says "can't play, not encoded correctly."

Almost always this means you encoded *text* to base64 instead of an *MP3 file*. The Clip Audio field needs the base64 of a real .mp3 file (see "Preparing your own clips"). Re-encode using a "File to Base64" converter (e.g. base64.guru > Datatype: Local File), not a "Text to Base64" tool. Also re-copy the full string in case it was truncated; if you pasted a data: URI, the driver strips the "...base64," prefix automatically. Or just pick a built-in Default Clip.

Diagnostic debug console.

Telnet the processor IP on port 12512 (configurable under Debug). Commands: `status`, `clips`, `speakers`, `play <clip#> <speaker#>`, `stop <speaker#>`, `reload`, `log off|low|med|high`, `quit`. You can also browse `http://<processor-ip>:<HTTP Port>/` for a live status page and to download each clip for verification.

Licensing

A 120-minute trial is included for evaluation. Paste your purchased licence key under Licensing to unlock permanently. The licence is bound to the processor's MAC address.