I’m new to MQTT so forgive my ignorance. I have designed a simple interface board around an ESP32-C3 module, which I have loaded with ESP-AT firmware. The ESP-AT documentation explains all the allowable commands, but in general terms. I cannot manage to access a broker.
I have installed HiveMQ on a laptop and the log shows that it has loaded correctly and started. I can then access it through the HiveMQ dashboard. However, I can’t communicate with it from the ESP32. This is the sequence of commands I’m using:
WIFI CONNECTED
WIFI GOT IP
AT+CWMODE=1
OK
AT+CWLAPOPT=1,31
OK
AT+CWJAP=“Virgin2.4”,“Wjsh318263”
WIFI DISCONNECT
WIFI CONNECTED
WIFI GOT IP
OK
+TIME_UPDATED
AT+MQTTUSERCFG=0,5,“esp32”,“espressif”,“1234567890”,0,0,“mqtt”
OK
AT+CIPSTA?
+CIPSTA:ip:“192.168.0.136”
+CIPSTA:gateway:“192.168.0.1”
+CIPSTA:netmask:“255.255.255.0”
OK
The next step should be to connect, so I need an IP address or a web address. I’m trying initially to access the local HiveMQ broker. However, I tried looking at the router and it doesn’t show HiveMQ as a connected device, so I can’t see an IP address there. I have tried various combinations without success:
OK
AT+MQTTCONN=0,“0.0.0.0”,1883,1
+MQTTDISCONNECTED:0
When I succeed in accessing the local broker my next step would be to access a cloud broker. I want to use encryption but can’t find a means to do that other than hard-programming an encryption code into each ESP32 module. Does anyone have any guidance?
I have used the pubsubclient library to connect an esp32 to local and remote servers via mqtt. The GitHub repository has many different examples. That includes secure connections.
To start with, it looks like the addresses used here for the connection string may be a little mixed up - the address that you’d be looking to provide within the connection string from the client device would be the HiveMQ Broker’s IP address - if, for example, you were hosting this within a local network environment, and the broker’s local address is 192.168.0.1, you would use this address.
If you are accessing a broker from outside of your local network, you would want to use the public IP address, or FQDN. It is also worth mentioning that the port being used to complete this connection - typically 1883 for non-TLS and 8883 for TLS - will need to be opened.
This can be a bit confusing, as oftentimes the default configurations for MQTT brokers utilize 0.0.0.0 as their bind address. This is essentially a placeholder, indicating that the listener should bind to any address on any interface on this host, which would usually be both the local and public addresses.
A great test would be to utilize our public MQTT broker, available here, which provides connect addresses and ports to test a variety of connection types.
As for recommendations for implementing connections and encryptions, while this does depend on the library you are looking to utilize for MQTT implementation, as JT_MN mentioned above, the pubsubclient library does offer quite a variety of examples, and can be a great starting point for implementing these connection options.
Thanks for your response, Aaron, but I have made some progress since posting my query:
For background, I design telemetry products for a sister company, Churchill Controls (https://www.churchill-controls.co.uk/). Their main customers are water companies that use the systems to monitor and control the water distribution networks. The core product, Mega_Link, comprises a base-station that communicates with any number of outstations using de-regulated radio, so every station hears every command. The message protocol includes addresses so only the target station responds. There are 32 radio channels available, and the protocol also includes a system address so each customer can configure his systems to work without interference from adjacent systems. I am developing an alternative communications interface using an ESP32-C3-WROOM module so the system can work over MQTT…
When I couldn’t connect to a local broker I created a HiveMQ serverless broker and was able to successfully connect to that. I have two test beds, one being a dumb terminal that allows me to manually send commands through an ESP32-C3-WROOM module and the other is in our host, where I can automate the command sequence. I have the following queries:
I have attached a log from our host showing that after connecting successfully the module repeatedly disconnects and re-connects about every 20 seconds. This happens on both test beds. Can you explain why it is happening and how I can stop it?
I created two Credentials, named Basestation and Outstation10, believing that I would need to create one for each station. I have since realised that all stations could access the same credentials. However, this creates an issue for production applications. If we configure every system to use those credentials then every system supplied will see messages from every other system. If we alternatively create different credentials for each customer then we have to update the broker every time we sell a new system. I liken this to a manufacturer selling video doorbells where each customer can configure an app on a mobile phone to access his doorbell. How does that work without updating the broker for each customer?
If we can arrange isolation between systems we could create and finance a broker to be shared by all our customers. We would have to work out a means for charging customers to use the broker. However I could foresee customers being concerned that should we cease trading (and hence stop financing the broker) their systems will stop working. The alternative is that each customer should create and finance his own broker, which is an extra complication that may deter customers. Can you propose a solution?
I have fixed this by creating a single Credential on HiveMQ (with permission to publish and subscribe) then using our product’s station address as the client_id, since every station on one of our systems has a unique station address. However I am confused by the various parameters needed by ESP-AT (scheme, client-id, username, password and topic). These don’t seem to correlate with the MQTT descriptions I have read.
The ESP-AT manual says that setting scheme to value 2 configured MQTT over TLS (for which I assume I need to set the Port to 8883). Is that all I need to do to ensure messages are encrypted?
As you know, one of my queries is how we can supply different customers with systems communicating over MQTT without them needing the complexity of creating their own brokers. Would I be right in concluding that all our customers could use our broker with the same topic and each creating his own username and password, so each system operates independently?
It sounds like you’ve made good progress in resolving the client ID issue. Let’s break down your questions regarding ESP-AT parameters, TLS setup, and using a single broker for multiple customers.
ESP-AT Parameters
Scheme: This determines how the connection is established. If set to 2, it configures MQTT over TLS.
Client ID: Unique identifier for each MQTT client. Using a unique station address for each station is a good approach to avoid conflicts.
Username & Password: These are used for authenticating the client with the broker. Each customer can have their own username and password combination.
Topic: This is where messages are published and subscribed to. You can have different topics for different customers or systems if needed.
TLS Configuration
Setting the scheme to 2 in ESP-AT should configure the device to use TLS. You are correct that you would typically use port 8883 for secure MQTT connections. To ensure messages are encrypted:
Make sure the broker is configured to support TLS/SSL.
Ensure the correct certificates are in place on the broker and client sides.
Multiple Customers Using the Same Broker
Yes, you can definitely have multiple customers use the same HiveMQ broker. Here’s how it could work:
Single Topic: You can have all customers publish to and subscribe to the same topic, but this could lead to potential message visibility across customers.
Separate Topics: For better isolation, consider creating separate topics for each customer or system.
Authentication: By providing each customer with their own username and password, you can ensure that they can only connect and interact with their designated topics or messages.
This setup allows you to simplify the infrastructure by managing a single broker while still ensuring that customer data remains secure and isolated. Just ensure you have the proper access control mechanisms in place on the broker side to manage permissions effectively.
If you have more specific questions about the ESP-AT parameters or any other details, feel free to ask!