ClientID in MQTT is too long against MQTT standards

I tried to test your service by sending data from OpenHAB. Basically every mqtt client should be able to connect and send data to your service, but it seems to you do not follow official MQTT specificaiton:

According to that

Client Identifier
The first UTF-encoded string. The Client Identifier (Client ID) is between 1 and 23 characters long, and uniquely identifies the client to the server. It must be unique across all clients connecting to a single server, and is the key in handling Message IDs messages with QoS levels 1 and 2. If the Client ID contains more than 23 characters, the server responds to the CONNECT message with a CONNACK return code 2: Identifier Rejected.

So other issue is that there is no Identifier Rejected in CONNACK packet.
I took a network trace and you return:

    .... .... 0000 0000 = Connection Ack: Connection Accepted (0)

it is confusing for well implemented clients.


Hi @grzesiek.golec, welcome to the Cayenne Community!

Thanks for the technical feedback. In doing some research I found that the latest spec is MQTT 3.1.1, superseding 3.1 in 2014. Both 3.1 and 3.1.1 are linked on the site.

3.1.1 states

The Server MUST allow ClientIds which are between 1 and 23 UTF-8 encoded bytes in length, and that contain only the characters

“0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ” [MQTT-3.1.3-5].

The Server MAY allow ClientId’s that contain more than 23 encoded bytes. The Server MAY allow ClientId’s that contain characters not included in the list given above.

I assume that’s how we arrived at our 36 character Client IDs with hyphens in them, but I’m tagging our engineering manager @asanchezdelc1 in case he has anything more to say on this decision. :slight_smile:

1 Like

I’ll also tag @croczey so he can be aware.


I wasn’t aware of the newer version. I gave the same feedback to OpenHAB community. In this case they should re-implement it.
But would be also good if during client-id generation process have possibility to select how long it may be. Does it make sense?


It does make sense and I’ll share your suggestion with our product team for a potential future change.

We’re big on developing to community needs with Cayenne, so if anyone else comes across this thread and desires this feature (custom length client IDs), then please post here to voice your support!

1 Like


Any news about the client id length issue?

I’ve got the same issue using an OSGI Framework and by the way using MQTT Spy

I have also found the same issue with some MQTT clients and bridges.
The issue I have is that I have devices that communicates only via HTTP Get/Post and I could find a Cayenne API in order to include the traffic. As an alternative I have tryied to use an external HTTP/MQTT bridge but in this case I have the same issue posted here where the ClientID length is very long. I found the same issue trying to work with standard MQTT web and Android clients that are not complying with the latest spec.
In my case it will be great to have an HTTP Get/Post API but if the MQTT Client ID could be manually modified will be also an alternative.


I replied to another post with you, but figured I will also repeat here in case anyone else is reading…check this out :slight_smile: