Residents Platform: House Pub

A pub that runs on a few shifts a week cannot have software that needs babysitting, so everything that keeps it running (the screens, the sound and lights, the schedule, the sales numbers) has to look after itself and explain itself. This project is the whole system behind it, built as a set of modules that share one backend. I built it as part of Affective Technologies, which serves the residents.

Affiliation. Affective Technologies provides the website and technical infrastructure for resident-led I-House projects. Not affiliated with International House NYC or AVI Foodsystems.

At a glance

Status: in production, except the hardware-maintenance module, which is still in progress.
Modules: five, each with its own write-up below.
Built on: Cloudflare (backend, databases, and storage), a Q-SYS audio system, two K-array amplifiers, and a Raspberry Pi.
Used by: tenders, residents, and technology stewards.

See it

The public House Pub web page on a dark background, showing the pub is closed and opens Wednesday at 9 PM, this week's serving hours, and links to the menu, specials, announcements, and tutorials — The public House Pub page: whether the pub is open, this week's serving hours, and links to the menu, specials, and announcements. The same backend drives the bar TVs.

You can try the live page at pub.ihnyc.affectivetech.com.

The modules

Each module is a project of its own. Open one for the full story.

TV Wall, Scheduler and Admin

The software behind the pub, from the bar TVs and tender scheduler to an audited admin console.

Room Control

A Q-SYS audio system, an in-room touch panel, and a DMX lighting rig that follow the same rules as the rest of the pub.

Now Playing

Identifying the song in the room by tapping the audio DSP over AES67 and showing it on the bar's right-hand TV.

Maintaining the Room's Hardware

Keeping a Q-SYS Core and two K-array amplifiers maintainable, by proving every change offline and making every trial reversible.

Sales Reporting Pipeline

A reliability case study in ingesting nightly sales reports from a system that offers no integration to us.

How the modules fit

flowchart TD
  H[Room hardware] <--> Pi[Raspberry Pi]
  Pi <--> B[Pub backend]
  S[Sales reports] --> B
  C[House Desk events] --> B
  B --> T[TVs and website]
  B --> A[Admin console]

The Raspberry Pi is the bridge between the audio network, which has no internet access, and the backend. The backend serves the public website and the TVs, and gives the people who run the pub one admin console. Events come from Residents Platform: House Desk, so a correction made once appears everywhere.

What is live and what is not

TV wall, scheduler, and admin: in production.
Room control: in production.
Now Playing: in production.
Sales reporting pipeline: in production.
Maintaining the room’s hardware: in progress, partly verified on hardware and partly lab-only.
An iPhone app: in development, against mock data and a read-only staging sign-in.

For how this fits with the rest of the platform, including shared principles, see The Platform Map.

Resident-facing guides are public: how the setlist works, how pub scheduling works, and Photo Flash and DJ Mode. The engineering documentation sits behind a login for the people who run the system.