SOSentryOSM
SystemHardwareAbout NateContact
● HARDWARE INTEGRATION · REAL HOME ENVIRONMENT

If I contact you about hardware, I already have a real job for it.

SentryOSM is my private home security and automation testbed. Hardware goes into an actual running network with cameras, Frigate, Home Assistant, Sentri, local storage, audio and automation. I am not collecting samples and I am not pretending to be a production OEM.

BASED IN Louisville, KentuckyENVIRONMENT private home lab + live security systemPROJECT LEAD Nate House
Email NateSee the running system
What it plugs into

A real stack, not an isolated bench demo.

The point is interoperability. Equipment has to work beside the rest of the system, recover cleanly, expose useful local interfaces and remain serviceable after the five-minute demo is over.

VIDEO

IP cameras + Frigate

RTSP/ONVIF, multiple streams, detection, recording, clips, snapshots and source stability.

AUTOMATION

Home Assistant

Device state, controls, notifications, dashboards, MQTT and normal household automation.

SECURITY LOGIC

Sentri

Event normalization, policy outcomes, authorization state and security-specific context.

NETWORK

PoE + segmented LAN

Link recovery, power behavior, local management and whether devices behave well when isolated.

LOCAL SERVICES

Linux / Proxmox infrastructure

Self-hosted services, monitoring, backups and repeatable configuration rather than one-off app setup.

EDGE COMPUTE

Local accelerators + AI

Camera detection and local inference workloads where the hardware actually adds useful capability.

What fits

The useful categories are broader than cameras.

If a device can improve the reliability, visibility or local control of the property, it may have a place in the test environment.

Cameras

RTSP, ONVIF, sub/main streams, low-light behavior, event metadata, local recording, audio and talkback.

Networking + PoE

Switches, injectors, managed/segmented network behavior, PoE recovery and link stability.

Door stations + intercom

SIP, ONVIF events, relays, microphones, speakers, talkback and local acknowledgement paths.

Sensors + automation

MQTT, Home Assistant, local APIs, state accuracy, latency and reconnect behavior.

Storage + power

Surveillance storage, UPS equipment, power-loss behavior, service restart and recovery.

Edge compute + client devices

GPUs, inference accelerators, small systems, wall panels and other local clients.

Real test example 01

Camera problems get isolated instead of blamed on the first layer that looks broken.

A recent unstable camera case was tested through the browser path, direct RTSP, repeated connection attempts and a physical switch/port-path comparison against a known-good control camera.

SOURCE ISOLATION

Separate player failure from device failure

The browser could sometimes play the camera, but repeated direct-source tests showed the endpoint itself was intermittently refusing or timing out.

  • Compare direct RTSP and application playback
  • Use a stable control camera
  • Swap the network/PoE path
  • Track outage windows rather than guessing from one failure
RESULT

Stop changing the wrong software

Once the instability followed the camera instead of the switch path, the useful conclusion was that the source device/path needed physical attention. That prevented “fixing” a working media gateway to compensate for an unreliable endpoint.

Real test example 02

Intercom work is tested end-to-end.

The current home system includes a door-station event path tied into Home Assistant and Sentri, with local acknowledgement/audio work rather than a cloud-only doorbell workflow.

Sentri event policy screen
Hardware event first.The actual button/event transition has to arrive reliably instead of being inferred from video.
Then software processing.Home Assistant and Sentri can add state, policy and automation around that hardware event.
Then local audio.The acknowledgement/talkback path is treated as its own system that can be traced and tested when it fails.
And failures stay diagnosable.Authentication, event delivery, audio generation and SIP/device signaling are separated so one broken layer does not turn into guesswork.
How I test

“It powered on” is not a test result.

I care about whether a device integrates cleanly, tells the truth about its state, survives normal failures and remains understandable months later.

IntegrationUse documented local interfaces when possible and avoid fragile one-off workarounds.Return the known-good setup and anything unusual required.
State accuracyCheck whether reported state matches the real device and whether confirmation is timely.Document delays, mismatches and edge cases.
Failure + recoveryReboot, service restart, network loss or power interruption where safe and appropriate.Document whether the device recovers by itself and how consistently.
Network behaviorTest local management, segmentation, reconnects and dependence on external services.Call out unnecessary cloud or connectivity requirements.
Longer-term useLeave it doing the real job instead of judging it from a five-minute setup session.Capture repeatable failures, thermal issues, drift or maintenance problems.
ServiceabilityUpdate it, diagnose it, document it and determine whether replacing it later will be straightforward.Keep install/service notes that are actually useful.
What you get back

Useful engineering feedback, not a guaranteed favorable review.

If a device belongs in the environment, the output should be enough to reproduce the setup and understand the caveats.

Known-good setupInterfaces, relevant configuration and the exact role the device filled.
EvidenceScreenshots, useful logs, repeatable failure details and recovery behavior.
Integration notesInteroperability with the surrounding local system and anything that required special handling.
Service notesWhat happens after updates, reboots, loss of connectivity or replacement.
Practical conclusionWould keep using it, would use it with caveats, or would replace it with something else.
PrivacyCompany name or test results are not published as an endorsement without permission.
No fake volume promises. This is currently a private home system and engineering environment. I would rather provide a useful technical result than pretend I have production quantities or customer deployments that do not exist.

Have hardware that fits one of these jobs?

Send the model number or technical documentation. I can tell you where I would use it and what I would test.

Email NateAbout Nate