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:
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 MQTT.org 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
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.
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!
Hi:
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.