Yes there is a sequence number, as far as I know the controller doesn't use this field in any way apart from returning it in as is in the response.
PellMon checks that the returned sequence number is the same as the one sent and regards the frame as invalid if not (see
https://github.com/motoz/PellMon/blob/3e2511ada9e2cd5715c5c9ad67f45a41ef8d82f3/src/Pellmonsrv/plugins/nbecom/nbeprotocol/frames.py#L177 ), but the nbetest client doesn't check the returned seqnum at all. It's up to the client to increase the sequence number for each request or not, nbetest sends a random number since it is a stateless client.
The protocol is not completely stateless in the controller. Setting changes are rsa encrypted (since they require the password to be transmitted), and that takes a long time to process in the controller (seconds for each frame). To make this work there is an option to set a client specific key for the much simpler xtea protocol. The key is set using rsa encryption, and then the controller remembers the key for that client and can use it to decrypt xtea encrypted setting changes much faster. Due to this the controller only supports a limited number of clients, four or five maybe as I remember it. I think it just drops the key for the oldest 'connection' when the table if full.
The nbetest client doesn't support xtea encryption at all since it is stateless, supporting it would require the xtea key to be stored somewhere. Pellmon sets an xtea key when it connects to the controller and periodically changes it here:
https://github.com/motoz/PellMon/blob/3e2511ada9e2cd5715c5c9ad67f45a41ef8d82f3/src/Pellmonsrv/plugins/nbecom/nbeprotocol/protocol.py#L320The stokercontrol protocol is actually only the controller polling stokercloud with http GET with current data in the query string and commands and setting changes in the response payload.