How Smart Plants Use Android Sensors for Downtime

Step 1: Tag Machines and Rank Candidate Downtime

Open your CMMS downtime register or the past 8 weeks of shift logs and rank stop events by frequency — not duration. In a rubber glove plant around Klang Valley, the usual suspects are short conveyor jams that last 2 to 6 minutes and never get logged by the operator. In Penang’s semiconductor back-end factories, it is chiller pump trips and cooling tower fan stalls.

Define the downtime signature you are hunting: a continuous drop in vibration RMS below the running baseline for more than 2 seconds. That is the “unpowered state” your Android sensor will flag. Target the 3 to 5 machines with the highest stop count; do not chase the longest stops first, because those already appear in the manual records. The unlogged micro-stops are where the recovery value sits.

Step 2: Mount Android Units on Failure-Prone Drives

The best hardware is a rugged device you can leave bolted down. A Samsung XCover Pro or a Zebra TC5x (second-hand units from Malaysian distributors run RM 800 – RM 1,200) has IP68 ingress protection and a replaceable battery. Mount it on the non-drive end bearing housing of the motor using industrial VHB tape or a steel L-bracket bolted to the pump volute.

Do not mount on flimsy sheet metal access panels — resonance on those surfaces masks frequencies above 100 Hz and destroys your threshold baselines. If the device sits near palm oil mill processing areas with solvent vapour, use a Zone 2-rated enclosure around it. Switch the phone to airplane mode and use Wi-Fi only for the plant LAN. This cuts cellular interference and extends charging cycles.

Step 3: Tune Accelerometer Sampling and Thresholds

Use an app like Physics Toolbox Sensor Suite or a custom build on Android’s SensorManager API. Request SENSOR_DELAY_FASTEST and log the accelerometer at 200 Hz; compute the RMS over a 1-second sliding window. Do a 30-minute baseline run on each machine in normal operation and record a second baseline at idle.

Typical values on a fixed-frequency motor: running RMS between 0.2g and 0.35g, idle below 0.05g, and a failing bearing spiking above 0.7g with harmonics at 2x and 3x rotational frequency. Configure two separate triggers: a “drop below 0.05g for 2 seconds” counts as downtime; a “spike above 0.7g” counts as a fault warning. Use the Android battery temperature sensor as a crude thermal probe — press the device against the motor side and you can catch a 10°C rise before the winding trips.

Step 4: Pipe Sensor Payloads into MQTT and Node-RED

Run a local Mosquitto MQTT broker on the plant IT PC or a Raspberry Pi 4 on the LAN — no cloud required for the first pilot. Every time the RMS crosses below the downtime threshold, the device publishes a JSON payload with device ID, timestamp, and RMS value to the topic `plant/line2/ah-03`. Keep publish latency under 300 ms.

Node-RED 3.x subscribes to that topic and stages the event. Because most Malaysian plants already run Odoo Maintenance or SAP PM on premise, write a Node-RED function node that POSTs the “stopped” event to the CMMS REST endpoint — this auto-creates a downtime work order with the machine code, cost centre, and stop timestamp. If your CMMS has no API, drop the event into a Google Sheet via the Sheets API as a stopgap; the goal is a machine-readable record, not a pretty dashboard.

Step 5: Tie Alerts to Shift Log and Response SOP

Do not page the maintenance manager on the first 2-second dip. Assign a two-tier escalation rule in Node-RED: if RMS stays below threshold for 30 seconds, push a Telegram bot message to the production supervisor. A typical message: “AH-03 CONVEYOR STOPPED 22:14:03 | RMS 0.04g | Duration 32s”. If the event clears within 30 seconds, log it silently as a micro-stop count.

Train the supervisor response as an explicit SOP: 30-60 seconds is a re-tension or cut-out; beyond 5 minutes requires the electrician to check the motor contactor and VFD fault code. The Telegram bot removes the “who logs it” debate entirely — the sensor proves the stop existed, and the shift log now has a timestamp to reconcile against.

Step 6: Back-Boil the Pilot and Expand to Other Lines

Run the pilot for two weeks on three machines without changing operator behaviour. At the end, compare the Android log to the CMMS records. A realistic result for a Senai, Johor plastics moulder: 50 unlogged micro-stops caught per week, each lasting 3 to 5 minutes — that is 2.5 to 4 hours of recoverable production time weekly that simply vanished before. You are not measuring OEE improvement yet; you are measuring detection coverage.

To scale, switch to fleet-managed Android devices using Device Owner mode via an MDM agent like Hexnode, which is commonly used in Malaysian industrial deployments. That allows remote configuration of the sensor app, auto-reboot schedules, and central VPN certificates. Re-baseline each machine monthly — bearing wear shifts the vibration floor, and a stale threshold will either false-trip or go deaf.