What MQTT is, without jargon
MQTT is a lightweight way to exchange messages between devices and systems. In plain language: a sensor, machine, or gateway sends a short message to a broker, and systems that need that message can retrieve or receive it.
This makes MQTT attractive on the shop floor. It is fast, relatively simple, and suitable for many small messages: machine running, order ready, temperature measured, box passed, fault active. For Odoo, the business significance is especially important. Not every technical message belongs in ERP; only data that improves a registration, decision, or action.
A good Odoo MQTT connection therefore does not start with the protocol itself, but with the question of which decision is now too late, too manual, or too uncertain. Do you want to automatically start and stop work orders? Do you want to schedule maintenance based on actual running hours? Do you want to see quality measurements directly with the right batch? Only then does it become clear which messages are relevant.
Why factories often end up with MQTT
Factories often turn to MQTT because modern sensors, gateways, and some PLC environments already support it. In that case, MQTT is the easy route. There is no need to devise a heavy custom protocol, and the messaging can neatly remain local before Odoo only receives the relevant results.
For manufacturing companies with multiple machines, this is practical. A packaging line can provide counts, a temperature unit can report measurements, and a gateway can collect status information. Odoo does not need to know each device itself. Odoo gets the meaning needed for planning, inventory, quality, or maintenance.
This prevents operators from retyping data at the end of the day. The shop floor tells what is happening sooner, and Odoo can respond to that more quickly.
Broker local or in the cloud
The broker is the intermediary where MQTT messages come together. It can run locally, for example, within the factory network, or in a cloud environment. Which choice is wise depends on the process, the network agreements, and the availability needed on the floor.
For many manufacturing environments, starting locally makes sense. The shop floor continues to operate when the internet connection falters, and only the information that Odoo needs continues. This suits companies that want real-time insight without making their entire machinery directly dependent on an external connection.
The goal is not to forward as much technical data as possible. The goal is for Odoo to know in time what is operational where: an order has started, a batch has a measurement, a line is stopped, or a planner needs to adjust the sequence.
From MQTT message to Odoo record
An MQTT message is only valuable when it leads to better registration or action in Odoo. A notification that a line is running is not a result in itself. The result occurs when Odoo registers a work order more reliably, sets up a quality control, or makes a maintenance task visible earlier.
The chain must remain business-followable: signal on the shop floor, gateway or broker that makes it readable for the integration layer, Odoo record that is updated, and then a decision. For example: the planner sees that the actual processing time structurally deviates from the routing and adjusts the planning before the next order is promised.
That is exactly where the difference lies between a technical project and a useful connection. The technology is only successful if someone in sales, planning, production, quality, or maintenance makes a better decision because of it.
What if the machine does not speak MQTT?
MQTT is nice when a device can already do it. But it is never a requirement to connect a machine to Odoo. Many machines were purchased before MQTT, OPC UA, or modern data connections were common. Adding such an interface afterwards can be expensive, may be blocked by the machine builder, or simply may not fit within warranty and certification.
That is why Linky Business does not only look at protocols. If a device produces a readable signal, we can connect it. Think of categories such as digital and analog I/O, relay and contactor contacts, limit switches, light screens, sensor outputs, and power consumption on an existing cable. The machine itself remains untouched; nothing is modified in the machine and no cooperation from the machine builder is needed.
This does require work that a software-only ERP partner usually does not provide. You need to be able to read the electrical diagram, work safely in the control cabinet, and understand which signal has business significance. This is not an Odoo configuration, but industrial practical knowledge. More about that approach can be found on our page about machine connectivity with Odoo.
Example: a packaging line and a lathe from 1995
Take a manufacturing company with two starting points. The packaging line already has an MQTT-capable counter. The lathe from 1995 has no protocol and no digital interface to ERP. Yet both cause the same problem: operators register too late, causing planning to rely on assumptions.
With 36 work orders per week, the routing for a recurring operation is set at 45 minutes. After the connection, Odoo shows that the effective time is on average 57 minutes. That difference of 12 minutes per order is 432 minutes per week, or 7.2 hours of capacity that was previously invisible.
The chain is concrete. On the packaging line, the counting via MQTT reaches the Linky gateway; at the old lathe, a readable machine signal becomes available through the same industrial layer. Odoo records the actual start, stop, and output for the work order. The planner sees that the routing is too tight, adjusts the standard time, and prevents sales from promising the next series too optimistically again.
The commercial consequence is more important than the protocol. The machine does not need to be replaced, the operator has to type less, and the planning gains capacity that was previously blocked. For such a first step, a two-machine pilot is usually sufficient: about two weeks until the first real data in Odoo, with a fixed price after a technical quick scan.
Security and network separation
An Odoo MQTT connection should not mean that every device on the floor talks directly to the internet. In a serious production environment, you want separation between the machine environment, broker, gateway, and ERP. Not out of fear, but because working without disruptions is more important than a nice demo.
In practice, it’s about clear boundaries. The shop floor remains locally usable, Odoo only receives what is necessary for the process, and rights are limited to what the connection needs to do. This way, MQTT becomes a robust link in the operation instead of a loose technical hobby layer.
This is also where the choice between standard software and a partner with hardware knowledge becomes visible. The question is not only whether Odoo can receive a message. The question is whether the connection fits within the factory, the control cabinet, the network, and the process.
When MQTT is not the right choice
MQTT is not always the best route. If a machine already provides reliable Modbus values, Modbus may be simpler. If a machine builder has set up OPC UA neatly, OPC UA can be the comfortable option. And if there is no modern protocol at all, raw I/O often works better than trying to force a missing interface.
The mistake is to see MQTT as the goal. The goal is real-time operational data in Odoo. Sometimes it comes via MQTT, sometimes via Modbus or OPC UA, and sometimes via an existing contact, sensor output, or power image. The protocol is the easy case when it already exists; it is not a ticket for digitization.
For Linky Business, the practical rule is simple: start with the device that is already there and the decision that needs to be improved. Then you choose the route that is reliable and maintainable. See also our page about connecting machines, devices, and sensors to Odoo.
What a first step concretely means
A good first step is small enough to prove and concrete enough to measure value. For example, choose one modern source that already speaks MQTT and one older machine without a protocol. Then you will immediately see the difference between the easy route and the approach that always works when there is a readable signal.
The scope should be sharp: which two devices, which Odoo registration, which decision needs to improve, and which reporting is sufficient to determine the next steps. Linky Business works with a low, fixed, and predictable monthly fee per location for the gateway and per additional node. Customization may require more work at the beginning, but it does not increase the monthly fee due to complexity. The current rates are on the pricing page.
Important: the gateway and nodes are provided by Linky Business as part of the subscription. The customer owns their own machines, their own data in Odoo, and the results. Support, expansions, and changes can be agreed upon separately. This way, the first step remains clear without pretending that there are no recurring costs.
Conclusion
MQTT can be an excellent route to bring shop floor data to Odoo. Especially when sensors, gateways, or PLCs already support it, it is often light, fast, and practical.
But an Odoo MQTT connection should never start with the assumption that every machine must speak MQTT. Older machines, label printers without a network port, simple sensors, and existing contacts can still provide valuable data. If the signal is readable, Odoo can do something operational with it.
The profit is not in the protocol. The profit is in better work orders, more realistic planning, less manual input, and decisions that are closer to the shop floor. Therefore, do not start with the question of which protocol is the most beautiful, but with the question of which machine or action causes the most uncertainty today.
Do you want to know if MQTT is the right route?
Linky Business looks at your machines, signals, and Odoo process and determines which connection provides practical value.