PitWatch

Sewage ejector pump monitoring

When an ejector pump fails,
nothing tells you.

PitWatch watches the motors, the floats and the panel's own contacts. When something is wrong it sends a message to the people responsible, within seconds, wherever they are.

What it watches

Current, on each motor

A clamp on each pump, read once a second while it is turning. That is what a pump is actually doing rather than what the panel thinks: the load on a start, the steady draw through a cycle, and the slow drift upward that comes long before anything trips.

The panel's own contacts

The lead and lag floats, the high water float, the motor overloads, the run signals and the panel alarm. Every contact on its own topic, reported the instant it changes rather than polled.

Together they catch a pump on its way out. Current alone says a pump is running but not why it started. Contacts alone say a float is wet but not that the motor is straining.

CT monitors amps, once a second Sensors floats, runs, faults MQTT broker PitWatch alerts, history, answers

What it does with that

  • Alerts that reach a phone

    Rules over the readings and the contacts, and a message the moment one is met. An overload has tripped. The high water float is wet. A pump has run far longer than a normal cycle, or started and drawn nothing at all, or gone quiet when it should have run. Text and email, with a matching message when the condition clears.

  • History that answers questions

    Every call for water, how long each pump ran, what it drew, and the rain over the top of it. Day against night, this week against last, this month against the one before. Any window you are looking at comes away as a spreadsheet.

  • AI, over your own data

    Ask a question the way you would ask a person. What changed this week. Whether a pump is slowing down. What the rain did to the run count last month. The model reads the same rows the charts do and answers in a sentence, so nobody is left interpreting a graph at two in the morning. It runs through your own model account, so your readings go where you decide and nowhere else.

  • Anything that speaks MQTT

    Nothing in the code knows what any particular device is. A source is a topic and a path into the body, typed into a settings page. Any broker, including a managed one over mutual TLS, and anything that can publish to it.

  • A page that says now

    What each pump is drawing this second, which one is lead, when each last ran and for how long, which contacts are closed, and whether every source is still talking. Live, without reloading.

  • Who gets in, and who gets told

    Every building has an administrator who decides that. Add other administrators, add viewers who can watch everything and change nothing, and set who is on the alert list and for how serious a problem. Run several buildings on one installation and an administrator at one of them sees that one, and never learns the others exist.

What it looks like

What it sends

Text messages and emails, to the people entered by the administrator of the building it is installed in. Every message is an operational alert about the equipment: an overload tripped, the high water float is wet, a pump has run far longer than a normal cycle, the monitoring hardware has stopped reporting. A matching message goes out when the condition clears.

There is no marketing of any kind, and no public sign up. A phone number reaches this system only by an administrator entering it on behalf of somebody who agreed to it. Replying STOP to any message ends them. In normal operation the equipment is quiet and nothing is sent at all, sometimes for months.

The Terms & Conditions set all of that out in full, including consent, frequency and how to stop.