← The Naistro work02 / NAISTRO · CONTRIBUTION

Device status that ages with the connection.

Help operators understand which devices are available.

Where this work fits

An operator might need to pause several players or change a venue’s volume. Some devices could be connected while another was unavailable. A dashboard needed to make that situation understandable.

MY CONTRIBUTION

I worked on device heartbeats, reconnection state, and cleanup of stale connections. The fleet view needed to stop treating an old connection as an active player while retaining useful device context when it reconnected.

THE IDEA, ILLUSTRATED

Connect a control with the receiving device

VENUE CONTROL · DIRECT WEBSOCKET FAN-OUT
DashboardConnected devicesWebSockets
Entrance65% volume
Main floor65% volume
Lounge65% volume
Adjust the volume. Available targeted devices receive the command.
THE ENGINEERING DECISION

A group command can have mixed results.

One unavailable device should not erase successful sends to the others. I returned per-operation delivery results and worked on aging connection state so a disconnected player would not look active indefinitely. A sent command still needed to be distinguished from observed playback.

The skills behind the work

DynamoDB
Store and retrieve device or application records using defined access patterns.
Authentication
Establish who is making a request before applying account or access rules.
Scheduled jobs
Run time-based work without waiting for a person to open the application.
THE WIDER RESULT

Operators could control players remotely and see more useful information about their availability. The backend supported venue-level actions without treating the entire fleet as one device.

Inactive-device detection
20 secTime to detect inactive devices through real-time health monitoring.
READ THIS IN CONTEXTI connected dashboard controls to the players in each venue. →
Related contributionsRemote controls with per-device resultsI built WebSocket playback controls for individual players and groups of devices in a venue. A group operation could reach some devices while another was unavailable, so its result needed to preserve that distinction instead of returning one blanket success.The right notice for each playerI built targeted player-notification behavior for different platforms and software versions. This helped clients receive messages and actions appropriate to the device they were running.A venue view shaped by responsibilityI worked on authentication and role-aware access to venue resources. Establishing who someone is and deciding which locations or devices they may access are related but different responsibilities.Product guides the team could maintainI built backend operations for ordered guide steps and editable content. Reordering used a transaction so related positions changed together, while loading defaults checked for existing steps to avoid adding them twice.