[MSA] Activating and deactivating I2C shifts the input of the IO module by one.

[maramend]

This is how it was tested in the MSA application with an IO8 module:

1. I2C was activated in the global settings, configured as SHT4x with "Lüfterphase vor Messung" set to 0 s, and the MSA ETS application was programmed.
2. I2C was then deactivated in the global settings and the MSA ETS application was programmed.

This resulted in a shift in the IOs that I had configured as inputs. When I triggered IO1, the connected group address was not activated. When I triggered IO2, however, the group address of IO1 responded, and so on.

I was able to restore the expected behavior by resetting all SHT4x-specific settings to their default values (“Lüfterphase vor Messung” to 60 s), setting SHT4x to inactive in the I2C settings, and disabling I2C in the global settings, and then reprogramming.

[maramend]

I had a closer look at the behavior and I think the root cause is the allocation order of the communication objects.

Currently, the optional I²C modules are allocated before the ARM IO modules, both in the KNXProd and in the firmware. This means that enabling or disabling an I²C device changes the communication object numbers of all following IO modules.

Example with SHT4x:
• With SHT4x enabled, it reserves 4 communication objects before IO1.
• With I²C disabled, these 4 objects disappear and all IO communication objects move by 4 positions.

This explains the observed behavior very well: after disabling I²C, IO1 no longer uses the object number that was previously assigned to its group address, while IO2 can end up using the previous object number of IO1.

I therefore think the clean solution is to allocate the ARM IO communication objects first and the optional I²C communication objects afterwards. This would keep the IO object numbers stable, independent of whether I²C devices are enabled or disabled.

The same allocation order must be used in both the KNXProd and the firmware.

I can prepare a patch for this. One question before doing so: should the fix be based on the current main branch, or on PR #98?

PR #98 changes the number of communication objects used by an ARM input from 4 to 6 because of the new toggle status and DPT 2.001 support. The underlying issue already exists in main, but the exact object layout is therefore different in PR #98.