Skip to content
Start free evaluation

Delivery problems

Read this page when the connection works but data doesn’t flow the way you expect. Start with the sent, acknowledged, received, rejected and error values in the simulator status.

When rejected grows and error starts with OPC UA PubSub, messages arrived but the simulator subscriber didn’t accept them.

error Cause Fix
OPC UA PubSub Malformed The MQTT 5.0 message lacks the Content Type or the UAMessageType User Property, carries one of them twice, or has a badly formed value. Make the publisher add application/opcua+uadp and UAMessageType=ua-data.
OPC UA PubSub Conflict A property value doesn’t match this subscription, for example Content Type application/json or UAMessageType ua-metadata. Make the publisher send UADP data messages.
OPC UA PubSub Unsupported The payload isn’t an unsigned, unencrypted UADP NetworkMessage. Check that the publisher sends UADP without security.
OPC UA PubSub Limit The received message is larger than 64 KiB or carries too many properties. Split the message.

To see the exact bytes the simulator itself sends, follow Publish and subscribe with the simulator.

Another tool left an invalid retained message on the simulator’s topic. The broker sends retained messages on every subscribe, so the same rejection repeats each time PubSub starts. Delete the retained message of that topic:

터미널 창
mosquitto_pub -V 5 -r -n -t opcua/uadp/data/77/demo
Symptom Cause Fix
A subscriber started late gets no earlier data The simulator doesn’t retain data and starts a new session on every connection, so it can’t receive messages published before it subscribed. Start the subscriber first.
The observer sees messages but received doesn’t change The topics differ. They must match exactly, including case and any trailing /. Make MQTT topic identical to the publisher’s topic.
PubSub started without an error, but nothing arrives The broker withholds messages the client may not read. Mosquitto still answers the subscription with success. Add topic read <topic> to the ACL.
dropped grows Nobody took the received messages, and the queue of 256 filled up. Click Show received or run pubsub_received more often.
Where and message Cause Fix
Status error: MQTT publish refused: 0x87 The broker refused with PUBACK 0x87 (Not authorized) because the client may not publish there. acknowledged doesn’t grow. Add topic write <topic> to the ACL.
Status error: MQTT publish refused: 0x.. Another PUBACK failure code, such as 0x97 Quota exceeded or 0x90 Topic Name invalid. Look it up in the table in MQTT 5.0 features.
MQTT publish failed: unsupported MQTT session feature: broker publication capabilities The broker’s Maximum QoS is 0 (Mosquitto max_qos 0), and the simulator publishes only at QoS 1. Let the broker accept QoS 1.
MQTT publish failed: MQTT session resource limit The message exceeds the Maximum Packet Size the broker announced (Mosquitto max_packet_size), so the simulator doesn’t send it. Raise the broker limit or send fewer fields.
OPC UA PubSub Limit The encoded UADP message is larger than 64 KiB. Send fewer fields or shorter strings.

PUBACK reason code 0x10 (No matching subscribers) is a success code and counts as acknowledged. A publication succeeds even when nobody subscribes.

You see Explanation
mosquitto_sub prints qos=0 The observer subscribed at QoS 0, and the broker delivers at the lower of the message QoS and the subscription QoS. Subscribe with -q 1 to see qos=1.
The same Sequence appears twice QoS 1 delivers at least once, so a resent message can arrive again. Drop duplicates by sequence number. A tool that republishes the same bytes also repeats the sequence number.
The same message arrives every time PubSub starts The topic has a retained message. Delete it with mosquitto_pub -r -n as shown above.
Messages from several publishers interleave MQTT keeps the order of messages from one client on one topic only. The order between publishers isn’t defined.