This is a build-to-order module, so it is not an instant download. Typical lead time is one working week from a confirmed brief and access to your machine signals. The schedule depends on how many machines/tags are in scope, whether you use MQTT, OPC-UA, or both, and how quickly we can reach live signals for commissioning. After a short discovery call we give you a firm timeline and milestones (connector build, tag mapping, commissioning, training, go-live).

Every build includes a defined post-launch support and warranty window with a named contact for bug fixes, tag-map adjustments, and questions. Because you receive the full addon source in your own repository, you are never locked in. We also provide an Odoo version-compatibility guarantee for your target version and can quote an ongoing support/maintenance plan that covers upgrades to future Odoo releases (17 → 18 → 19 and beyond) and additional machines or connectors as your shop floor grows.

The module is built for Odoo 17, 18, and 19, and runs on both Community and Enterprise. Core capabilities — MQTT/OPC-UA ingestion, tag mapping, auto counter recording, buffering, and the status dashboard — work on Community. Deeper Manufacturing touchpoints such as native work-order OEE, work-center productivity/loss reasons, and PLM links are richer on Enterprise, and we tailor the integration to whichever edition you run.

Yes — the gateway ships with both an MQTT inbound connector and an OPC-UA client connector, and you can mix them across machines. If a controller only speaks Modbus TCP, Siemens S7, EtherNet/IP, or a vendor REST API, we typically bridge it into MQTT or OPC-UA at commissioning (many brokers/edge gateways do this) or extend the connector layer as part of the scoped build. Tell us your controllers and protocols in the brief and we will confirm the approach before you commit.

The gateway uses store-and-forward buffering: when Odoo, the broker, or the link is unreachable, readings are queued locally and replayed in order once the connection returns, so you don't silently lose an hour of counts. Connectors reconnect automatically with backoff, and an ir.cron watchdog flags any feed that has gone stale so you know a machine is offline rather than assuming it produced nothing. Counter debounce and rollover handling ensure replayed data doesn't double-count.

Security is built in on both ends. Toward Odoo, every machine feed and configuration record is protected by ir.model.access.csv access rights and record rules, so OT data is scoped to the right roles. Toward the plant, MQTT connections use TLS with credential or client-certificate auth and OPC-UA uses Sign & Encrypt security policies. By default the gateway is read-only (inbound) for safety. Where you explicitly want two-way control, it can push setpoints or acknowledgements back via OPC-UA, and machine data can be exposed to MES/SCADA/BI over Odoo's XML-RPC / JSON-RPC API.

Machines usually report cumulative cycle counters, so the module stores the last known value per tag and computes produced deltas with @api.depends computed fields rather than trusting raw absolute numbers. It debounces duplicate pulses, handles counter rollover (16/32-bit) and machine/PLC resets, and only posts positive deltas to the linked mrp.workorder / mrp.production. During commissioning we reconcile the module's counts against the machine HMI over real shifts so you go live with numbers you can defend.