Watchman Your AI watchman.
Watchman makes sensors smart. A thermometer that beeps at eight degrees becomes one that can tell a door left open from a compressor losing the fight, and warns you before the room is warm. Watchman monitors temperature, sound and sight, using the sensors you already have or sensors we add. It learns what normal looks and sounds like for each thing it watches, tells you when that changes, and answers questions on WhatsApp in any language.
Fully separate from your PLC and control network: its own sensors, its own encrypted link, and answers straight to your phone. For the most demanding sites, everything runs on premises.
Running today on ESP32 temperature nodes, a Raspberry Pi with a four-microphone array, and a people-counting camera that runs its own detector.
Your sensors measure. Nobody understands them.
A sensor that beeps at a threshold is a smoke detector for a problem that has already happened.
Most small plants already have sensors: a logger in the cold room, a thermostat on the oven, a buzzer on the compressor, maybe an app on someone's phone. Each one knows a number. None of them knows what the number means, what it was yesterday at this hour, or what the sensor next to it is saying. So the alarm comes late, comes wrong, or comes to nobody.
The alarm that comes too late
A dirty condenser, a tired door seal or low refrigerant make the compressor run harder for days before the room warms. Temperature is the last number to move, and it is the one with the alarm on it.
The alarm that cries wolf
A door opening, a defrost cycle, a half-degree sensor wobbling across a limit. Each one fires the same beep. After a month, nobody reacts to it.
The app nobody opens
Your floor works from a phone, in a glove, in its own language. A dashboard behind a login is something nobody on shift will ever look at, and at three in the morning nobody is looking at anything.
It does the rounds. Continuously.
Connect what you have, add what you need
Sensors you already own join, whatever they speak: if they don't talk MQTT, we build the gateway or the network they need. Ours stick on: a temperature node, a microphone near the compressor, a camera on the doorway, a plug that measures power. USB power or a battery, and Wi-Fi to the internet. Anyone on your team can mount ours in minutes, and your control network stays exactly as it is. A small site can be running in an afternoon. A large one, we plan with you.
It learns what it is watching
Tell Watchman what each sensor is attached to, and it knows what to work out. A thermometer in a freezer is not a thermometer in an oven. Then it learns normal for that thing: this sensor, at this hour of the day, and in this weather. A compressor louder than it was last Tuesday afternoon is worth a message. A cold room warmer at 14:00 than at 04:00 is not.
Ask it, or let it call you
Questions go to a WhatsApp number, typed or spoken, in any language: “what is the temperature in the cold room”, “show me a graph of the compressor since Sunday”, “is anything wrong”. Alerts arrive on the phones or the group you name, with the reading, how old it is, and a message when it recovers.
Every answer carries a unit, a timestamp and an accuracy. A sensor accurate to half a degree is quoted to half a degree, as precise as it really is.
One thermometer. Five answers.
The sensor is the smallest part of Watchman. The rest is what Watchman knows about the thing the sensor is attached to.
| You install | Watchman also tells you |
|---|---|
| A thermometer in a cold room | Door openings, defrost cycles and how long they take, the temperature the food actually feels, how fast the room leaks heat, how strong the cooling still is |
| A microphone near a compressor | Running or stopped, duty cycle, short-cycling, speed, fault buzzers beeping at an empty room In pilot |
| A door contact | Door left open, openings per hour, and which warm-ups it explains |
| A plug that measures power | Energy, cost per month, run state, and a check on everything the microphone claims |
| A camera on a doorway | People counted and line crossings, one still on request, and reading a gauge or a display |
Alarms follow what the food feels, not what the air does.
Air in a cold room jumps every time the door opens. The food barely notices. Watchman alarms on the food's temperature, worked out from the air, so a door opening is not an alarm and a room that is really warming is. A defrost cycle is expected, and a defrost that takes twice as long as usual is worth a message.
You set it up by talking to it.
“Tell me if the cold room goes over 8 degrees for five minutes.”
That sentence creates the alert, and Watchman reads it back so you can check it.
“This thermometer is in the walk-in freezer, and the microphone by the compressor belongs to it.”
That sentence tells Watchman what it is watching, and draws the map it reasons on.
“Have the cold room 2 sensor report every ten seconds.”
That sentence changes the device's own reporting interval, and the device confirms it did.
Want to change an alert or a setting? Message it from your phone, any time, in your own words. And if you prefer a big screen, there is a dashboard too.
What each sensor sends, and what gets stored.
The microphones send numbers that describe the machine's sound, and your own engineer can check every byte.
Numbers that describe the sound.
The microphone runs continuously, because an impact lasts under a tenth of a second and a device that wakes up once a minute would miss it. What it sends is numbers: a level, eight frequency bands, whether the machine is running, its speed. A few numbers a second, a thousand times smaller than the sound, and they cannot be turned back into speech.
Rows in a database.
The numbers land in a database next to the temperatures. A raw clip is stored only on an event, only for a few seconds, only with an expiry, and only if that device's clip flag is on. It ships off.
It reads a picture of the sound.
When you ask Watchman to listen, it asks the device for a short clip, renders a spectrogram in the cloud, and the model reads the image. The audio stays yours, for a human to play.
The camera works the same way: it sends detections, and one still on event or on request.
Or keep all of it on premises.
For the most demanding sites, the whole system runs inside your plant: the broker, the database, the rules and the model, on your network. The three checks below work exactly the same.
Works alongside your safety systems. Watchman is a notification system: it tells your team when to go and look. Stopping machines stays with the safety interlocks, fire panels and alarm systems built for it, and Watchman adds eyes and ears around them.
Three checks your own engineer can run
- V1 · Read the rowsEvery value the model has ever seen is a row in the database. Open it.
- V2 · Watch the wireMirror a device's traffic. The message sizes show it carries only numbers.
- V3 · Flip the flagThe per-device clip flag is a column. Switch it off and the clip topic stays empty.
Every sensor keeps its own line. A quiet one abstains.
Watchman gives every sensor its own row and its own reading, so you can see exactly where they agree. A sensor that has gone quiet shows in grey as abstaining, and the verdict is drawn from the sensors that are reporting. Every row behind it is in the database.
“No data” is an answer in its own right, and Watchman reports it as one. That is how a team keeps trusting its alerts.
- Temp · cold room4.2 °C, normal for this hour
- Mic · compressorrunning 71 % of the last hour, +40 % vs last Tuesday
- Door · cold roomno data since 09:12, device offlineabstains
- Camera · doorway3 crossings since 13:00, quiet
Compressor working harder. Room still cold. Door unknown.
Check the seal and the condenser. Door sensor offline since 09:12.
Under the hood. We insist you look.
You are going to audit this anyway, so here is what Watchman actually does, in the language of the people who will be doing the auditing.
The model explains what the sensors saw. Rules and people make the calls.
The broker, the database and a rules loop handle real time. Alerts are evaluated every ten seconds from the database rather than the live stream, because a sensor going quiet shows up as missing rows, and the database is where those are visible. The language model reads the database, answers, and issues commands through the broker. If the model's provider is down, alerts still fire.
Separate from your control system.
Watchman's devices talk to one place: the broker, over TLS. All they need from your network is an outbound connection on port 8883, so the guest Wi-Fi is enough, and your PLCs, PCs and control network stay out of the path entirely.
One protocol, one broker.
Every device speaks MQTT over TLS to one broker, with its own credential and an access list that lets it publish only under its own topic and subscribe only to its own commands. That walls each device off from the others, and all traffic leaves your site over that one outbound, encrypted connection.
Bring your own sensors, through the same door.
Shelly and Tasmota devices, Zigbee sensors through Zigbee2MQTT, and LoRaWAN sensors through their network server already speak MQTT. An adapter translates their messages into Watchman's contract, under the same per-device credential and topic-scoped access list as our own nodes. Sensors that speak something else get a gateway, or a whole network, built for the site, publishing into the same contract. The contract does not change, so the rules, the baselines and the assistant treat them exactly like ours.
One database.
Registry, readings, events, commands, alerts and chat history in one Postgres, which any engineer can operate.
Alerts that behave.
A sensor that goes quiet becomes “unknown” and gets an alert of its own, because that is the most common failure in the field. Thresholds carry a dwell time, so a half-degree sensor holds steady around a limit. One message per breach with a cooldown, and a recovery message when it ends.
Time is evidence.
Devices timestamp at source after clock sync. A device with a bad clock is stamped at receipt and flagged, so you always know which times to trust. Every publish is acknowledged, so a device writing into a dead connection notices within a few intervals and reconnects. The cloud can see that failure and the device cannot, so only the device can fix it.
Accuracy is declared per metric, and the model quotes it.
Physics before statistics.
A cold room is a heat leak and a cooling machine. The rate it warms while the compressor rests measures the leak; the rate it cools while the compressor runs measures the machine. Both are fitted daily from one thermometer and the run state.
Sound as numbers.
A-weighted level, peak, eight octave bands, crest factor, running fraction per interval, and speed by harmonic peak search. The 1 to 4 kHz bands are the ones that generalise to a real machine; low bands are wind on the microphone ports unless the array's coherence says otherwise, and it says so. An anomaly score against a per-machine baseline is published as triage, pointing a person at the right machine.
Sight as events.
The camera runs its own detector on its own chip and publishes counts and line crossings, plus a still on request or on event. The model sees one frame when asked and describes it.
Every front end is the same tools.
WhatsApp, the voice line, Claude Desktop over MCP and the HTTP API share one tool definition. What the model can do on one, it can do on all.
| Device link | MQTT 3.1.1 over TLS 1.3 · per-device credentials · topic-scoped access list · last-will presence |
|---|---|
| Network | Outbound TLS on port 8883 only · guest Wi-Fi is enough · separate from your control network |
| Sensor nodes | ESP32-S3 · DS18B20 ±0.5 °C · interval 10 s to 1 h · buffers readings offline and flushes with original timestamps |
| Microphone | 4-element USB array on Raspberry Pi · 16 kHz · features only · clips on event, off by default |
| Camera | On-device YOLO on an NPU · counts, line crossings, JPEG stills on request |
| Your sensors | Shelly · Tasmota · Zigbee through Zigbee2MQTT · LoRaWAN network servers · anything that speaks MQTT, through an adapter · anything else, through a gateway or network we build for the site |
| Cloud | One Python service, one Postgres · rules every 10 s from the database · 30-day raw retention · stills and clips capped by age and size |
| Channels | WhatsApp for questions (any language, typed or voice note) · Telegram for alerts (groups, acknowledge) · voice line · MCP for Claude · HTTP API |
| Model | Works with any provider · alerts run independently of it · budgeted per session and per day |
| Hosting | Single VPS today · dedicated instance per customer on request · fully on premises for the most demanding sites |
The pilot: one site, as many sensors as it needs.
We connect the sensors you already have, add ours where you need more coverage, and do all the integration work ourselves. You judge the result on your own cold room.
What you get
- Monitoring for the assets you pick, using your sensors, ours, or a mix of both
- Baselines learned from your own first week
- A WhatsApp number your shift can ask, in any language
- Alerts to the phones or group you name, with recovery messages
- A findings report at the end, including anything the first weeks of data say about your equipment
After the pilot:
Standard
Monitoring, alerts, the WhatsApp assistant, and a dashboard for the supervisor.
Full-Care
Everything in Standard, plus hardware care, replacement sensors, an annual visit and a baseline retrain.
Why “your AI watchman”?
Every plant had one. The night watchman walked the floor with a torch at three in the morning, listened at the compressor room door, put a hand on the cold room, and phoned you only when something was wrong. He had no dashboard. He had ears, eyes, and a sense of what the place normally sounded like.
That job is gone, and the plants that still need one cannot hire for it. Watchman is our answer: not another dashboard, but something awake at three in the morning that knows what normal looks and sounds like, and calls you when it changes.
Built by Segev Technologies
Watchman is a GoMachines.AI product, engineered by Segev Technologies, a Tel-Aviv R&D firm that has spent two decades building electronics, firmware, motion control and AI for robots and precision systems, for clients including Israel Aerospace Industries, Applied Materials, Elbit, Siemens, Mitsubishi Electric and HP.
We are machine builders. We learned factories on the factory floor.
Straight answers.
I already have sensors. Do I have to replace them?
Keep them. Whatever your sensors are and however they talk, we connect them. Ones that already speak MQTT, like Shelly, Tasmota, Zigbee2MQTT and LoRaWAN network servers, take the short path. For the rest, we build the gateway or the network the site needs. We add our own sensors where you need more coverage.
We have a PLC. Do we need to connect it?
Your PLC stays exactly as it is. Watchman watches from the outside, the way a person on rounds does, with its own sensors and its own connection.
Does it listen to conversations?
It turns sound into a few numbers a second that describe the machine, and speech cannot be rebuilt from them. A short clip is stored only on an event, only if you turned that device's clip flag on, and it expires. See “What it stores”.
Can all of it stay inside our plant?
Yes, for the sites that need it. The broker, the database, the rules and the model all run on a server on your premises, on your network. The checks in “What it stores” work the same way there.
Is it a safety system?
It is a notification system. Watchman tells you when to go and look, and works alongside your interlocks, fire panel and alarm system, which keep doing the protecting.
What if the internet drops?
The device keeps measuring and keeps its readings, then sends them with their original timestamps when it reconnects. The cloud notices the silence and tells you the device went quiet, which is itself the most common failure in the field.
Can it control anything?
Only when you say so, twice. Actuation starts switched off, per device and per person. Where you enable it, the assistant asks you to confirm in the same conversation before it sends the command. Reading data is always available.
Do the sensors talk to each other?
Through the database, yes. Every reading lands in one place, and the rules and the assistant reason over all of them together: an open door explains a warm room, a busy compressor with a cold room points at the seal. Each sensor is isolated from the others, and every conclusion rests on rows you can audit.
Which languages?
Any language your team uses, typed or spoken. Every reading comes with its unit and how old it is.
Your plant is already telling you.
At three in the morning, to an empty room.
Let's put a watchman on the five things you worry about and see what they say.
Request a pilotWatchman · a GoMachines.AI product · engineered by Segev Technologies · Tel Aviv · segevtech.com