Samples code compatibility with old hardware version

[AlbanDurrheimer]

Hello,

Firstly, thank you for this project, I assembled my first board last week.

Concerning my question, I would like to know if the latest versions of the samples code (currently in the main branch) are compatible with older hardware versions (personally, I have 1.2.0 boards)?

I'd also like to know if the samples code specify a version somewhere? I've noticed that this information isn't passed on by the Zigbee code, and this would make it easy to find out if the firmware is up to date.

Thank you

[rbaron]

Hi @AlbanDurrheimer,

As of now all the samples are compatible with all hardware versions from 1.0.0 to 2.0.0, with the exception of samples/input, because it showcases the push button that only 2.0.0 has.

We have a way of fetching the board revision via the CONFIG_BOARD_REVISION Kconfig. For example here's where it's defined for nRF52840@1.2.0, but it's not currently used by any sample.

[AlbanDurrheimer]

Hi @rbaron,

Thank you for your response.

I had indeed noticed the existence of CONFIG_BOARD_REVISION and its non-use, which put me in doubt about backward compatibility.

Do you have the answer to my second question about the code version? For those of you who, like me, are currently using the example codes, it would be useful to know whether we're using the latest version or not.

Thank you

[rbaron]

That's a good idea, I'll send a PR shortly. My original goal when setting the CONFIG_BOARD_REVISION was to put it in the HWVersion attribute, but it expects an integer version. We use a semantic ID type of versioning, and I'd rather not have two things meaning the same thing. I think a reasonable compromise is to put it together in the model identifier, like "b-parasite 1.2.0".

[AlbanDurrheimer]

Yes, I can see the problem. However, won't the solution with the model identifier create problems with the converter for Zigbee2MQTT?

[rbaron]

@AlbanDurrheimer that's a good point, I forgot about z2m. I closed #139.

[rbaron]

I wanted to avoid having a different revision ID, but that may be a reasonable compromise. I opened #140 for it.

[AlbanDurrheimer]

Alternatively, you could use the SWBuildID attribute to make a compound version from the hardware version and the firmware version (example: [hardware version]-[firmware version], or vice versa)?
(I don't know much about Zigbee, so sorry if this isn't relevant)

[rbaron]

@AlbanDurrheimer that could work too, but I think using the HWVersion is slightly more correct semantically, and we actually fix an inconsistency (we previously unconditionally wrote 2 there, instead of the default 0).