Connect
Industrial IoT solutions that start with the machines you already own
Most plants do not need new machines to become measurable. They need the data that already exists inside the PLC, the drive and the energy meter to leave the shop floor. We build the connectivity layer that makes that happen — sensors, gateways, protocols, edge processing and a place for the data to land.
The problem
The data already exists. It just never leaves the machine.
Your PLC knows the cycle count. Your VFD knows the current draw. Your temperature controller knows the setpoint deviation. All of it is overwritten every scan and none of it reaches anyone who could act on it. The result is a plant that is fully instrumented and completely invisible.
- 01
Production numbers are collected on paper and typed into Excel the next morning
- 02
Nobody can say why line 2 stopped for 40 minutes on the night shift
- 03
Energy bills are one number per plant, not one number per machine
- 04
Every report is at least a shift old, so every decision is reactive
- 05
Machine data exists but sits inside four different vendor systems that do not talk
What we build
Concrete deliverables
Nouns, not adjectives. This is what actually gets handed over.
- 01
Machine connectivity survey
A tag-level audit of what each machine can already expose — PLC make and model, available protocols, spare I/O, drive parameters, existing meters — and what needs sensors added.
- 02
Sensor and instrumentation design
Where a machine exposes nothing, we specify and install the instrumentation: energy meters and CTs, vibration and temperature sensors, proximity and photoelectric counters, flow and pressure transmitters.
- 03
Industrial gateway layer
DIN-rail edge gateways that speak the machine's protocol on one side and MQTT or HTTPS on the other, with store-and-forward buffering so nothing is lost when the link drops.
- 04
Protocol normalisation and a tag model
A single, consistent naming and unit model across mixed-vendor equipment, so machine 7's 'RPM_ACT' and machine 12's 'speed_fb' become the same field.
- 05
Edge processing rules
Aggregation, deadbanding, rate limiting and local alarm logic at the plant, so you send meaningful data instead of raw noise.
- 06
Data platform and dashboards
A time-series store, retention policy, and the dashboards and APIs that make the data usable by people and by your other systems.
How it works
The technical path, step by step
Where the engineering decisions actually get made.
- 01
Read the machine
We connect to the existing controller over its native protocol — Modbus TCP/RTU, OPC UA, Ethernet/IP, Profinet, S7 or a serial link — in read-only mode. Where there is no controller, we add instrumentation.
- 02
Normalise at the edge
A gateway maps raw registers to named, typed, unit-consistent tags, applies deadbands and sample rates per tag, and timestamps everything at source.
- 03
Buffer and transmit
Data is queued locally and published over MQTT (usually Sparkplug B) or HTTPS. If the network drops, the buffer holds and back-fills on reconnect.
- 04
Store and contextualise
Values land in a time-series database alongside asset context — which machine, which line, which shift, which product — because raw values without context cannot be analysed.
- 05
Serve it back
Dashboards, alerts, scheduled reports and an API. The API matters: it is what stops this becoming another silo.
Protocols & technologies
Specifics, because vague answers cost you money later
Chosen per site according to what is installed, not according to what we would prefer to work with.
| Technology | Where it is used | Engineering note |
|---|---|---|
| Modbus TCP / RTU | Legacy PLCs, energy meters, drives, temperature controllers | The workhorse of Indian retrofits. Simple, universal, read-only safe. |
| OPC UA | Modern PLCs and SCADA, structured tag models | Preferred where available — typed, secure, self-describing, no register maps to maintain. |
| MQTT / Sparkplug B | Gateway to cloud or broker | Report-by-exception with birth/death certificates, so you know when a device goes silent. |
| Ethernet/IP | Allen-Bradley / Rockwell environments | Read via CIP; tag-based addressing on ControlLogix and CompactLogix. |
| Profinet | Siemens environments | Usually read via an OPC UA server or an S7 connection rather than tapping the fieldbus. |
| S7 comms | Siemens S7-300/400/1200/1500 | Direct DB reads where OPC UA is not licensed on the controller. |
| Modbus over serial + converter | Very old equipment | RS-485/RS-232 to Ethernet converters where the machine predates any network port. |
| Dry contacts / pulse | Machines with no controller at all | Counters, run signals and energy pulses wired into a remote I/O module. Crude, effective, cheap. |
| REST / HTTPS | Cloud ingestion and integration | For low-frequency data and for integrating with ERP, MES and third-party platforms. |
Brownfield
We do not ask you to replace your machines
Almost every plant we look at has equipment from three or four decades and five or six vendors. That is normal and it is workable. We connect to what exists, in read-only mode wherever possible, and we add instrumentation only where the machine genuinely exposes nothing. Your control logic is not modified, your line does not get re-engineered, and the work is scheduled around your shutdown windows.
Works with
- Siemens S7-200 / 300 / 400 / 1200 / 1500
- Allen-Bradley MicroLogix / CompactLogix / ControlLogix
- Mitsubishi FX / Q / iQ-R
- Delta, Schneider, Omron, Fatek, Wecon
- VFDs from ABB, Danfoss, Yaskawa, Delta, Schneider
- Machines with no PLC — retrofitted with sensors and remote I/O
Use cases
What people actually ask us for
Each one is a situation followed by the outcome it produces — not a feature list.
Production counting without operator entry
NowOutput is recorded by hand and reconciled at end of shift.
AfterCounts stream from the PLC or a retrofitted sensor; the dashboard and the shift report agree, automatically.
Per-machine energy visibility
NowOne electricity bill for the whole plant, no idea which asset drives it.
AfterEnergy meters per machine or per feeder, with consumption attributed to machine, shift and product.
Downtime capture with reasons
NowStoppages are known, causes are not.
AfterStops are detected automatically; the operator confirms a reason code on an HMI or tablet in a few seconds.
Multi-plant consolidation
NowTwo or three plants, each with its own systems and its own numbers.
AfterOne normalised data model and one view across sites, with drill-down to the individual machine.
Condition data for maintenance
NowMaintenance is calendar-based or breakdown-driven.
AfterVibration, temperature and current trends per asset, with thresholds and trend alerts.
Cold-chain and environment monitoring
NowTemperature excursions found after the fact, if at all.
AfterContinuous logging with alerting and an audit trail suitable for compliance review.
Implementation
How a project runs
Eight stages, each producing something you own. Full detail on the process page.
- 01
Discover
1–2 conversations
- 02
Audit
1–3 days on site
- 03
Design
1–2 weeks
- 04
Engineer
2–8 weeks per phase
- 05
Integrate
1–2 weeks
- 06
Deploy
Your shutdown window
- 07
Monitor
First 4–6 weeks
- 08
Optimise
Ongoing, if you want it
Mixed-vendor machine monitoring rig
Three PLC brands and one machine with no controller at all, read through one gateway and normalised into a single tag model — the situation almost every Indian plant is actually in.
Read the write-upQuestions
Industrial IoT — common questions
Can you connect a PLC without changing the program?
In most cases, yes. Modbus TCP, OPC UA and Ethernet/IP reads are non-intrusive — we poll existing registers or tags without modifying the control logic. Occasionally a small addition is needed to expose a value that is only held internally; when that is the case we say so up front, scope it, and schedule it in a planned window.
What if a machine has no PLC?
We instrument it externally. A current transformer on the motor feed tells you run/stop and load. A proximity or photoelectric sensor on the output gives you a count. A thermocouple or vibration sensor gives you condition. These go into a remote I/O module or a small edge controller — no change to the machine itself.
Does this require internet on the shop floor?
Not necessarily. The system can run entirely on-premises, with dashboards served on your local network. Cloud is an option, not a requirement — and where it is used, only the gateway needs outbound connectivity, typically over a separate, segmented network.
How much data will this generate?
Far less than people expect, because we apply deadbands and report-by-exception at the edge. A machine sampled at one second with sensible deadbands typically produces a few megabytes per month, not gigabytes. High-frequency data, such as vibration waveforms, is processed at the edge and only features are transmitted.
Who owns the data?
You do. We build on infrastructure you control — your cloud account or your on-premises server — and we hand over the schema, the credentials and the documentation. There is no arrangement in which your production data lives somewhere you cannot reach it.
How long does a first project take?
A pilot covering a handful of machines is typically a few weeks from survey to live dashboard, depending on site access, network readiness and how much instrumentation has to be added. We deliberately structure the first engagement small so it can be proven before it is scaled.
Will this interfere with production?
Reading from a controller adds negligible load and is done in read-only mode. Physical installation — sensors, meters, gateway, cabling — is planned around your shutdown or maintenance windows. Nothing is installed on a running line without an agreed method statement.
Tell us what your machines are
Send us the makes and models on your floor. We will tell you what can be read today, what needs instrumentation, and what a first phase would involve.