From your description, it’s possible that your clients might be exceeding the connection rate limit set on the HiveMQ Public MQTT Broker. The broker enforces this limit to ensure fair usage for all users.
To confirm if this is the issue, you can check the CONNACK code from the broker when your clients try to connect. If the code is CONNECTION_RATE_EXCEEDED (0x85), it indicates that your connection attempts are too frequent.
Steps to Address This:
Reduce Connection Frequency: Ensure your clients reconnect only when necessary. Implement exponential backoff for reconnection attempts to avoid overwhelming the broker.
Use Another Public Broker: If you need a higher connection rate for testing, consider using another public broker with a higher rate limit or one that fits your specific requirements. Some options are test.mosquitto.org or emqx.io.
Alternatively, if you require more control and flexibility, you can deploy the HiveMQ Community Edition on your own infrastructure for testing. It’s free to use and gives you full control over limits and configurations.
Let us know if this helps or if you need further assistance!
I only try to reconnect when the connection is lost. But it might be the problem, one of my repeaters was broken and one client had a bad connection to the WLAN. This might be the reason why reconnections occur often.
I am using the PubSubClient from Nick O’Leary and I did not find a way to check the return code from the broker.
I understood that you need a connection rate limit. For my understanding: How this is done in your implementation?
I have a fixed IP address, so it would be easy for you to identify a client with too many connections tries in my area. But when this will be reset, so that all other clients from the same IP address are again able to connect? Is this counted for each client or for all clients from the same IP address? I assume the second part is true, because my MQTT explorer is also blocked?
Thanks for your message and for sharing your experience.
The public HiveMQ broker is indeed a shared, open-access service, meaning many users connect to it simultaneously for testing, learning, and experimentation. During peak load times, when the number of active connections is high, the broker may reject new connections to maintain overall stability and performance.
Since you’re using the public broker for your experiments, it’s important to understand that this can occasionally lead to connection issues due to the shared nature of the service. Even with properly configured clients, there’s always a possibility that your specific device may not be able to connect during times of heavy traffic.
If your use case requires a more reliable, guaranteed connection, and you want to avoid the challenges of shared broker access, you might consider setting up your own MQTT broker or opting for a private broker solution. Hosting your own broker or using a private service will give you full control over the connection rates and allow for a more stable and predictable environment for your devices.
Let us know if you’d like more guidance on setting up your own broker or signing up for HiveMQ Cloud.