UE5.2 - Official MQTT Plugin

Development Pipeline & Plugins
, ,
1

Hey everyone,

I want to connect to an MQTT broker and recently learned that Unreal has an official MQTT Plugin, which is experimental.

I understand that being experimental means that some things may not work properly, or are subject to change, but the plugin does not seem to work at all. None of the Delegates are fired, whether on Connection, Publish, or Subscription… and connection also simply doesn’t work, with no errors or feedback.

I know the MQTT broker is working since I created a Python script to test it properly.

I was wondering if anyone here has used the official MQTT plugin before, and if/how you were able to work around these issues.

2 Likes
2

I’m also interested in any updates about this plugin.

2 Likes
3

Just FYI, the issue remains for UE5.3.2.

I ended up switching to WebSockets, but it would be nice to have the MQTT protocol working.

1 Like
4

I have the same issues. Trying to use it on 5.3.2 but no success.

1 Like
5

Same issue here

1 Like
6

I tried the plugin and it works. But I can not get the connected callback to fire.

image
image1630×457 117 KB

2 Likes
7

I seem to have found -a- solution though it feels… wrong. It does seem to work though, gets connected then subscribes to the correct topic. Even logs the messages sent to the broker.

Fix
Fix2177×758 238 KB

1 Like
8

I have tried the plugin in 5.3.3, with two different brokers (Mosquitto and NanoMQ), and I can’t get it to connect. The brokers complain about parse errors, so it looks like the protocol isn’t implemented correctly?

Editor Output Log:

LogMQTTCore: Error: Error connecting socket to: 172.104.228.166:1883: SE_EISCONN, Connection state: Connected
LogMQTTCore: Verbose: Abandoning Operations
LogMQTTCore: Warning: Couldn't connect to MQTT server: There was a socket error.
LogMQTTCore: Verbose: Set State to: Connected

NanoMQ broker log:

2024-03-19 11:36:11 [35] WARN  /nanomq/nng/src/sp/transport/mqtt/broker_tcp.c:909 tcptran_pipe_recv_cb: tcptran_pipe_recv_cb: parse error rv: 139

Mosquitto broker log:

1711034343: New connection from 87.236.176.51:57167 on port 1883.
1711034346: Client <unknown> disconnected due to protocol error.
1 Like
9

I got the built in MQTT plugin to work with the latest Mosquitto (in both blueprints and c++) - but occasionally the plugin will crash the editor seemingly because it receives an unknown packet type from the broker. I traced the issue to the call to MQTT::GetMQTTPacketTypeName on line 570 in MQTTConnection.cpp - this function call crashes

void FMQTTConnection::HandleMessage(const EMQTTPacketType InMessageType, const TSharedRef<FArrayReader>& InPacketReader)
{
	switch(InMessageType)
	{

<SNIP>
		
	default:
		{
			UE_LOG(LogMQTTCore, Error, TEXT("Unhandled, unknown message type: %d (%s)"), int(InMessageType), MQTT::GetMQTTPacketTypeName(InMessageType));
		}
	}
}

This function is implemented in MqttOperations.cpp as:

const TCHAR* MQTT::GetMQTTPacketTypeName(EMQTTPacketType InMessageType)
{
	return Internal::PacketTypeNames[InMessageType];
}

This lookup results in a nullptr if InMessageType does not have an entry in the PacketTypeNames map. Which in turn causes the editor to crash.

I am still exploring why/when this unknown packet is received, and/or modifying the MQTT plugin to better handle this situation.

UPDATE: So the issue arises when calling MqttClientObject->Publish(…) with a FString payload with a certain minimum length. What appears to happen is that the published MQTT packet is also received - and when it is received the packet parser finds a garbage byte that is identical to whatever the last character in the published string is. That results in an erratic/unknown packet type, and the above highlighted code not knowing how to process the incoming packet data. This happens with both NanoMQ and Mosquitto.

UPDATE: The received MQTT message packet seems to drop the last 2 byte(s) of the payload string - so it gets truncated. That explains the garbage byte remaining in the data stream read from the socket.

Solution: In FMQTTPublishPacket::Serialize(FArchive &ar) in the file MQTTOperations.cpp, when deserializing the packet, the calculated payload size is too small. Debugging the code shows that all the raw payload data is actually present in the archive, but due to the error in calculated payload size, all but the last 2 bytes are deserialized. Modifying the magic number in the deserialization code in line 299 from

	PayloadLength += 2;

to

	PayloadLength += 4;

seems to do the trick.

3 Likes
10

Would you be able to provide a little more information about your implementation? I’m very new to UE5 or this type of development, in general, but I’m trying to use MQTT in UE5 to use “real-time” data. The blueprint I tried creating a blueprint based on your image, but I keep getting an infinite loop error.

1 Like
11

受到上面的启发，可以在mq客户端发送的时候多添加一个空格来解决MQTT插件多删除一个字节的问题，测试后大数据量也不会崩溃了
我的代码

{933489D2-6F37-498f-B133-807187194166}
{933489D2-6F37-498f-B133-807187194166}1574×756 132 KB

1 Like
12

That does not work for me. I can connect and even get an answer from the broker, but after the answer the engine crashes with this error:

Assertion failed: Pair != nullptr [File:D:\build++UE5\Sync\Engine\Source\Runtime\Core\Public\Containers\Map.h] [Line: 672]

Do you have any Ideas I tried your approach but that didn’t work.

1 Like
13

I tried this plugin and it only works in local host with local mosquitto broker in my case.
Anyone knows how to make it work with cloud broker? I tried with hive and got errors.
First error was because the url needs to be an IP address, I did nslookup on the broker url ,used the IP address and now I got different errors like socket error but still doesn’t work. I’ve already tested the broker with python script clients and it’s good.
Thank you all

1 Like
14

I kept using localhost, wich is working, but if i try to receive messages fast (and print them for example), like every 0.5 seconds, after a few messages unreal editor crashes… Is this a limitation of the mqtt implementation in unreal or am i doing something wrong?
If i turn down message speed to like 1 per second it never crashes