The standard machine learning answer is to train on examples of the fault. In industrial monitoring you almost never have them. Nobody breaks a working pump to collect training data, and the faults that do occur are rare, undocumented and specific to that machine.
Model normal instead
The workable approach is to model what normal looks like for one machine and score how far the present moment sits from it. This is a one-class problem, and it has a practical advantage: the training data collects itself during the first days of operation.
Normal is a set of states, not a number
Most equipment has several legitimate operating modes. A pump running, a pump idle, a pump starting and a pump running against a partly closed valve are all normal, and they look nothing alike. If you model normal as a single distribution you will flag every mode change as an anomaly. Segment states first, then learn a baseline per state.
Features beat raw samples
Feed the detector a compact set of features, such as band energies, crest factor, temperature rise over ambient and the shape of the start transient. Features are stable, cheap to compute on a microcontroller and far easier to explain afterwards than a raw window.
Persistence is your best false-alarm filter
A single sample crossing a boundary means very little. A deviation that holds across many cycles means something. Requiring a condition to persist, and reporting how long it has persisted, converts a noisy detector into a credible one. This is also what makes the eventual alert readable, since duration is information a technician can use.
Be honest about drift
Machines change legitimately: seasons change the load, and a rebuilt bearing resets the baseline. Any baseline needs a way to be updated deliberately after maintenance, otherwise the system will keep comparing against a machine that no longer exists.
The metric that matters
The measure of success is not detection rate on a test set. It is whether the person receiving alerts still reads them after a month.