Version as string?

[nstadigs]

I'm currently using a hash of the description to generate the version. But I just realized that this is wrong according to the specification. It should be a number.

I've found that using a hash as version is deterministic, makes testing easier and simplifies reinitialization of devices.

[schaze]

I also use a hash. But I use a SipHash 1-3 which computes a 64bit key (8 bytes) that I convert to a number and use as version.
@Tieske: Can you remember why we used a number for the version instead of a string?

[Tieske]

iirc to increment it. Hashing is not really viable on small devices, and certainly not reliable with JSON (binary equality vs functional equality).

imho using a number is generally easier. On small devices comparing numbers is easier.

I use a timestamp in seconds from the date I wrote the code.

[schaze]

Thanks @Tieske!
Here my thoughs:
Using a hash on a JSON is not reliable I agree. But using a hash on the native data structure (not JSON) in my code that is used to generate the JSON is. So for me hashing is a viable option - not sure how @nstadigs is doing it. Luckily the hash algorithm available to me hashes into a 64bit result so I can still represent it as a number.

However using a string for a version would allow for more flexibility:

• if you want to use a number simply convert it back and forth from string to increase it. If you use timestamps just also convert them to string and set them as version - no need to read in the current one. A string to number conversion and vice versa must IMHO be possible on all devices otherwise you will not really be able to implement a mqtt based homie device.
• if you want to use a hash that results in some kind of base64 or other alphanumerical hash result you can use this with a string field as well

For the controller side of the homie device the only real check to be done is if the version changed, not really if it got bigger or smaller. For this usecase it is also not important if version is a number or a string.

[nstadigs]

I'm using a stable JSON implementation (with key-sorting) and then fnv1a to generate a hash. Den sön 17 nov. 2024 11:15schaze ***@***.***> skrev:

…

Thanks @Tieske <https://github.com/Tieske>! Here my thoughs: Using a hash on a JSON is not reliable I agree. But using a hash on the native data structure (not JSON) in my code that is used to generate the JSON is. So for me hashing is a viable option - not sure how @nstadigs <https://github.com/nstadigs> is doing it. Luckily the hash algorithm available to me hashes into a 64bit result so I can still represent it as a number. However using a string for a version would allow for more flexibility: - if you want to use a number simply convert it back and forth from string to increase it. If you use timestamps just also convert them to string and set them as version - no need to read in the current one. A string to number conversion and vice versa must IMHO be possible on all devices otherwise you will not really be able to implement a mqtt based homie device. - if you want to use a hash that results in some kind of base64 or other alphanumerical hash result you can use this with a string field as well For the controller side of the homie device the only real check to be done is if the version changed, not really if it got bigger or smaller. For this usecase it is also not important if version is a number or a string. — Reply to this email directly, view it on GitHub <#306 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEPTN45QF2WWJCOJ7HUITT2BBUFTAVCNFSM6AAAAABR4CWVSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBRGE2DSMJZG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[nstadigs]

I can actually get an integer out of fnv1a instead of hexes, so this isn't really an issue for me anymore, but the discussion about dropping the constraint may still be still relevant

[Tieske]

A string value makes sense. The only requirement is that it changes.

I would be in favour of limiting length btw.

[nstadigs]

I agree. Limited length makes sense imo.

[schaze]

I concur. What length limit should we choose? 24,32,64 characters?

[Tieske]

It can be way less than that. Sha-256 has 64 chars. But we don't need that for uniqueness, eg. Git uses 7 chars for the short id.

[nstadigs]

The version is only for the controller to know if the description has changed from one time to the next, right? If that's the case then even if the collision rate of your hashing algorithm is relatively high the chances of your controller getting the same version as the last visit (even tho the description has changed) seems very low. I think you can just use the fastest and shortest you can find and you'll probably be fine

[Tieske]

the technicalities are easiest solved, I think we agree there. So can you raise a PR, to validate the exact wording?

[schaze]

Just one more comment about limiting the length: is it really necessary? Technically I haven't seen a mqtt client that would be able to limit the size of a message it receives. So you can limit what you send manually from a library but what do you do with a too long version string that you receive?
So in the end it may just be a more or less useless restriction.
IMHO just defining it is to be a string is enough. What difference does it make if it is 12 or 120 characters long?