Confidential client · Monitoring, alerting and reporting

UniFi environment monitor

Temperature sensors already on the network, turned into alerts that arrive in time and reports that arrive on their own.

The hardware already knew the temperature. What was missing was everything around it: nobody was watching at two in the morning, nothing kept a history long enough to be evidence, and the monthly paperwork was somebody reading a display and typing it into a spreadsheet. This polls the sensors on their own schedules, shouts when a reading crosses a line, and e-mails the report before anyone has to ask for it. The client is not named here at their preference; the system itself is still maintained by the person who built it.

Laravel
Vue
Inertia
MySQL
Docker
UniFi Protect API

What it does

Each sensor on its own clock

Polling intervals are configured per schedule rather than one global loop, so a freezer can be read every few minutes while an office is read hourly, without collecting data nobody needs.

Alerts with a threshold per sensor

Every sensor carries its own limit. Readings are checked continuously and the people assigned to that sensor are e-mailed when one goes over — not a dashboard nobody is looking at.

Reports that send themselves

Daily, weekly or monthly, generated as a PDF from the stored history and e-mailed to named recipients at a fixed hour. The paperwork arrives whether or not anyone remembered it was due.

Built so a slow queue cannot double-send

The next run time is written before the job is dispatched, not after. It is a small detail, and it is the difference between a busy worker sending one report and sending four.

Ships as a container

Web server, scheduler and queue workers defined together and deployed as one unit, so the environment it runs in is part of the repository rather than something reassembled from memory.

More work

Own product

Got something like this?

Describe the process and you will get a straight answer about what it would take.

Start a project