Weld robots, paint booths and end-of-line testers publish in the plant; telematics units, EV chargers and fleet trackers publish from the road. ConnectMQ is the managed MQTT broker between them and your MES, vehicle backend and analytics.
No card required
One stopped weld robot or conveyor on a JIT/JIS line stalls the whole sequence. Alarms buried in a PLC or a local HMI reach maintenance minutes later than they should.
Telematics units drop out in tunnels, car parks and rural areas. Polling HTTP APIs burns data plans and loses events, and a command sent while the vehicle is offline simply vanishes.
Test benches, tier-1 equipment, telematics boxes and chargers each come with their own protocol, portal and cloud. Getting them into one backend is a new integration project every time.
One standard protocol for the plant floor and the vehicle edge, on a broker you don’t have to operate.
An isolated broker instance speaking MQTT 3.1.1 and 5 over TCP, TLS and WebSocket. The same client libraries work for PLC gateways, TCU firmware, backend services and web apps.
Each gateway, vehicle and charger gets its own credentials, and per-topic ACLs keep a vehicle on its own topics. All traffic is encrypted with TLS.
Persistent sessions and QoS 1 hold commands until a vehicle reconnects, Last Will marks a unit offline the moment it disappears, and retained state brings a new app up to date at once.
Threshold rules on robot weld current, booth temperature, battery state of charge or charger faults trigger alerts and notifications, and the live topic monitor shows what every device sends.
Automotive teams run MQTT in two places — on the plant floor and on the road. These are the use cases they start with.
Vehicle telematics, remote commands and OTA campaign messaging over one MQTT connection
Explore the use caseStream vibration, temperature and motor current to your models and open work orders before a machine fails
Explore the use caseSite telemetry, load management and live charger status for apps, alongside OCPP
Explore the use caseLive location, vehicle and driver data for dispatch, your TMS and customer ETAs
Explore the use caseplant/dallas/body-shop/cell-12/robot-03/telemetry
plant/dallas/body-shop/cell-12/robot-03/state (retained)
vehicles/vh-4821/telemetry
vehicles/vh-4821/commands
vehicles/vh-4821/status (retained)A telematics control unit (TCU) keeps one lightweight MQTT connection over cellular, publishes position, diagnostics and battery data to its own vehicle topics and subscribes to a commands topic. Persistent sessions and QoS 1 make sure a command — a configuration change, a remote action from the app — reaches the car once it is back online.
HTTP opens a new request for every reading and can’t push a command to a car. MQTT keeps one connection open, adds only a few bytes of header, delivers commands as soon as the vehicle is online and tells you when it drops off (Last Will). On intermittent cellular links it is the more efficient fit.
Yes, if you separate them by topic and permissions: a plant/… tree for the factory, a vehicles/… tree for the fleet, and separate credentials and ACLs for every gateway, vehicle and application. Choose the plan for your number of connections and message rate — many teams simply run plant and vehicles on two ConnectMQ instances.
ConnectMQ is an MQTT broker, not an OCPP central system. Chargers usually speak OCPP to your charge point management system (CPMS); the CPMS, site controllers and energy managers then publish sessions, meter values and faults over MQTT, and some chargers publish MQTT directly. ConnectMQ carries that data to monitoring, billing and load management.
Start on the Free plan — no card required. Connect a test cell or a handful of vehicles today, then move to Basic or Scale when you go live. No overage charges, cancel anytime.
