Muster

Inspiration

I love integrating systems. There is something deeply satisfying about finding a connection between two things that were never designed to work together—and discovering what that connection makes possible for someone else.

That is what inspired Muster. I wanted to build something for the community, especially for people who feel limited by the technology they already have. When useful equipment has no modern API or cloud connection, moving forward can seem to require starting over. I wanted to explore another possibility.

Some legacy environmental monitors can already tell you what is happening. You just have to call them and listen.

That small detail became the starting point: could CALL-E listen to those reports and help bring their information into a modern workflow?

For a greenhouse operator, those readings represent plants they have tended, time they have invested, and work they care about. Making that information easier to collect and understand felt like a meaningful place to put my love of integration to work.

What it does

Muster is a prototype for bringing supported, phone-based legacy monitors into a shared operations view.

It uses CALL-E to obtain spoken status reports, preserves the source evidence, and converts supported readings into structured observations that an operator can inspect.

The current demonstration uses a simulated four-zone greenhouse. An operator can start an observation, follow its progress, and review the transcript before examining the readings derived from it. Fleet Health keeps the latest call attempt separate from the latest complete observation, making gaps and stale information visible.

If the evidence is incomplete or unclear, Muster shows that uncertainty. A missing reading never quietly becomes a reassuring result.

The intended role is a read-only supplement to existing monitoring and native alarms, helping people understand the equipment they already operate.

How we built it

Muster is built in TypeScript, with React and Vite for the interface, NestJS and Fastify for the API, and PostgreSQL with Prisma for persistence. Background work runs through pg-boss.

The CALL-E TypeScript SDK powers the phone interaction. An owned Twilio endpoint supplies the synthetic greenhouse report used to exercise the integration.

The central design decision was to preserve evidence before interpreting it. Readings remain connected to their source so an operator can review how the system reached its result.

I also built a repeatable simulator experience so people can explore normal, abnormal, and incomplete reports without placing a live call. Replay remains clearly labeled SIMULATED.

Challenges we ran into

Connecting the systems exposed several different kinds of uncertainty: phone routing, callback timing, transcript availability, and the relationship between spoken words and structured values.

Even a number required care. A transcript might contain a number written in words while the extracted result uses digits. Muster needed to recognize supported equivalence while keeping the original evidence intact.

Another challenge was making the interface dependable during refreshes and interruptions. Following an observation’s progress must preserve its identity without accidentally starting another call.

These details shaped the project. Every stage needed a clear account of what had happened, what the evidence supported, and what remained unknown.

Accomplishments that we're proud of

I’m proud of taking the idea through a successful, authorized CALL-E-to-Twilio phone call in the synthetic greenhouse environment. That run produced retained evidence and four grounded readings.

It demonstrated a working integration across the phone call, evidence handling, and observation pipeline. Physical-device compatibility and production readiness remain future work.

I’m also proud of the complete, repeatable demonstration: someone can explore the workflow, inspect its evidence, and see how it handles uncertainty.

The community idea now has something concrete behind it that people can try, question, and help improve.

What we learned

I learned how much responsibility comes with turning spoken information into something a person might act on.

A completed call, a usable transcript, and a trustworthy observation each require their own evidence. Keeping those distinctions visible became part of the product experience.

The project also deepened what I enjoy about integration: understanding each system’s limits well enough to create a useful connection. Sometimes an existing interface holds more possibility than it first appears to.

What's next for Muster

The next step is to learn from greenhouse operators, installers, and others who work with this equipment: which checks take their time, which information matters, and where Muster could fit into their routines. I'm not entirely sure if there is a niche market for this, but I'd like to see if there is some opportunity for integrations. But it doesn't simply end with Sensaphone.

Alongside that feedback, I want to validate supported physical devices through authorized testing and document compatibility carefully, including whether observation leaves native alarms unaffected.

Future work includes qualified device adapters, dependable scheduling, and consent-based escalation with people retaining responsibility for decisions and recovery confirmation.

My hope is that Muster helps someone look at the system they already have and see a new possibility.

Built With

• call-e
• docker
• fastify
• nestjs
• ngrok
• node.js
• pg-boss
• postgresql
• prisma
• react
• twilio
• typescript
• vite
• vitest