A Pixel2-3022-70-4 project built in SMLogix 3.36.0067 with DIN1 and DIN2 feeding an AND block into a memory map entry (mqtt:events) shows nothing at the broker. The network reports healthy and the broker answers, but no subscriber receives a message. Total silence means the fault sits before the broker's log, at the TCP connect, the MQTT session, the topic binding, or the trigger. A working link would at least show a connection attempt in the broker log.
Where can a Pixel2 MQTT publish stop before the broker logs it?
A publish travels through six hops. Each has a distinct silence signature, so test them in physical-to-application order.
| Hop | What must be true | Signature when it fails |
|---|---|---|
| 1. Pixel2 Ethernet, IP, mask, gateway | Controller is in the broker's subnet, or the gateway routes to it | No ARP or SYN from the controller on a capture |
| 2. TCP to broker port | Broker listens on the configured port (1883 plain, 8883 TLS by convention) and no firewall drops it | SYN with no SYN-ACK, or RST. Ping still succeeds |
| 3. MQTT CONNECT / CONNACK | Client ID unique, credentials accepted, protocol version matches | Broker log shows refused or dropped connection. CONNACK return code is non-zero |
| 4. Topic binding in SMLogix | Memory map entry is bound to the MQTT device and carries the intended topic string | Session is up in the broker log, but no PUBLISH follows |
| 5. Trigger | The mapped variable actually changes after the session is up | Session is up, binding is right, still no PUBLISH |
| 6. Broker authorisation and subscriber filter | Client may publish to the topic, and the subscriber's filter matches it | PUBLISH visible in a capture, absent at the subscriber |
Why does a reachable broker still show nothing?
"Network is fine, broker is available" usually comes from a check made from a PC. It proves nothing about hops 2 and 3 as seen from the controller. Ping tests ICMP only. The controller's own subnet mask, gateway, or a broker-side firewall rule on the MQTT port can block it while the PC succeeds.
Two broker behaviours produce exactly the silence described:
- Silent ACL drop. A publish at QoS 0 to a topic the client may not write is discarded by common brokers with no indication to the publisher. The session looks healthy, and the subscriber sees nothing.
- Client ID collision. Two clients with the same ID make the broker disconnect the older one. If the ID is left at a default, or copied from a test tool, the Pixel2 and that other client evict each other in a loop and no traffic reaches a subscriber.
A topic mismatch also gives silence. A subscriber on events does not receive plant/events. Wildcards (#, +) are the only way to widen the match.
Does the DIN1 AND DIN2 test logic ever generate a publish?
The test chain produces one boolean. Whether that boolean produces a message depends on the publish mode configured for the memory map entry: on change, cyclic, or on a write event. Read the mode in the memory map properties. If the mode is on change, the output must transition after the MQTT session is established. If both inputs are already true at program start, the AND output starts at 1 and never changes, so nothing is sent. Toggle one input low, then high, and watch for a single PUBLISH.
The label mqtt:events is ambiguous. It may be a memory map name, a topic, or both. Open the map entry and read the literal topic string that the MQTT device publishes to. Do not infer it from the map name.
A missing component or library for Pixel2 is unlikely to look like this. If the target lacks MQTT support, SMLogix normally refuses the configuration or build with an error. Confirm that the controller's runtime supports the MQTT device type used in 3.36.0067. Read the controller's firmware version from its device information and compare it with the SMLogix release notes.
How do I capture each hop from the Pixel2 to the subscriber?
- Subscribe to everything on the broker. Use a PC on the same segment as the broker:
Addmosquitto_sub -h <broker_ip> -p 1883 -t "#" -v-uand-Pif the broker requires authentication. Some brokers exclude system topics from#. Also subscribe to$SYS/#if you need broker statistics. - Open the broker log at connection-level verbosity. Power-cycle or re-download to the Pixel2 and look for a connect line from the controller's IP address. No line means the failure is at hop 1 or 2. A line followed by a refusal or disconnect means hop 3.
- Capture the Pixel2 port on a mirror port or an inline tap. Filter on the controller IP and the broker port. Expected order: ARP, SYN, SYN-ACK, ACK, CONNECT, CONNACK, then PUBLISH on each trigger.
- Read the CONNACK return code. In MQTT 3.1.1, 0 is accepted, 1 unacceptable protocol version, 2 identifier rejected, 3 server unavailable, 4 bad user name or password, 5 not authorised. MQTT 5 uses a different reason code set.
- Compare the topic string in the captured PUBLISH byte for byte with the subscriber's filter. Check case, leading or trailing slashes, and spaces.
How do I correct the device, memory map, and topic settings?
| Setting | Check | Action |
|---|---|---|
| Broker address | Hostname versus IP | Enter the IP address. Hostnames add a DNS dependency that the controller may not have configured |
| Broker port | Plain versus TLS | Match the broker listener. A plain client on a TLS port fails the handshake with no usable message |
| Client ID | Unique per broker | Set a fixed, unique ID for the Pixel2 |
| User name and password | Broker allows anonymous? | Enter credentials, or enable anonymous access on a test listener |
| Memory map to device link | Entry belongs to the MQTT device | Re-select the device in the map entry, then rebuild |
| Topic | Literal string | Use a plain path such as one level with no wildcards. Publish topics cannot contain # or +
|
| Direction | Publish versus subscribe | Set the entry to send. A receive-direction entry never publishes |
| Broker ACL | Write permission | Grant the Pixel2 user write access to the topic pattern |
After each change, rebuild the project and download it. A stale runtime keeps the old MQTT configuration.
How do I confirm the publish end to end?
- With the capture running, download the project and confirm the broker log records a connection from the Pixel2 IP with a CONNACK return code of 0.
- Set
DIN1andDIN2low, then raise both so theANDoutput goes 0 to 1. - Confirm a PUBLISH frame leaves the controller and the
mosquitto_sub -t "#" -vwindow prints the topic and payload. - Drop one input and confirm a second message carries the value 0 or the equivalent payload for the mapped variable.
- Replace the wildcard subscriber with a subscriber on the exact topic string. Repeat the toggle and confirm it still receives the message, which proves the topic and the subscriber's ACL rights.
FAQ
How do I tell whether the Pixel2 is connecting to the MQTT broker at all?
Enable connection logging on the broker and power-cycle or re-download the controller. A connect entry with the Pixel2's IP address and a CONNACK return code of 0 confirms the session. No entry means the failure is at IP, gateway, port, or firewall level.
How do I force a message from a DIN1 AND DIN2 test in SMLogix?
Start with both inputs low, then raise both so the AND output goes 0 to 1 after the session is up. If the map entry publishes on change, an output that is already 1 at download never sends anything.
How do I find out if the broker is dropping the Pixel2's publishes?
Compare a packet capture with the subscriber window. A PUBLISH leaving the controller that never reaches a wildcard subscriber points to an ACL denial. Raise the broker's log level or check its ACL file for the Pixel2 user and topic.
How do I check that the memory map topic matches my subscriber?
Read the literal topic string in the memory map entry, then subscribe to that exact string. Matching is case-sensitive and slash-sensitive. If the exact subscription works but your application filter fails, the filter is wrong.