MQTT3

To setup a MQTT3 pubsub create a component of type . See on how to create and apply a pubsub configuration

Warning

The above example uses secrets as plain strings. It is recommended to use a secret store for the secrets as described .

To configure communication using TLS, ensure that the MQTT broker (e.g. emqx) is configured to support certificates and provide the caCert, clientCert, clientKey metadata in the component configuration. For example:

Consuming a shared topic

When consuming a shared topic, each consumer must have a unique identifier. By default, the application ID is used to uniquely identify each consumer and publisher. In self-hosted mode, invoking each dapr run with a different application ID is sufficient to have them consume from the same shared topic. However, on Kubernetes, multiple instances of an application pod will share the same application ID, prohibiting all instances from consuming the same topic. To overcome this, configure the component’s consumerID metadata with a {uuid} tag (which will give each instance a randomly generated value on start up) or {podName} (which will use the Pod’s name on Kubernetes). For example:

Warning

The above example uses secrets as plain strings. It is recommended to use a secret store for the secrets as described here.

Note that in the case, the value of the consumer ID is random every time Dapr restarts, so you should set cleanSession to true as well.

You can run a MQTT broker like emqx locally using Docker:

You can then interact with the server using the client port: tcp://localhost:1883

You can run a MQTT3 broker in kubernetes using following yaml: