I have noticed offset changes from 3.7.0 Dev (around V46) to the final version and again from 3.7.0 to 3.7.1.
(I´m the one who has posted in discord)

@mheyse, when you have some time, could you check /scripts/update_modbus_registers.py? I think the part where you check for existing registries based on short names isn't working anymore after other EMS-ESP core changes. On each new EMS-ESP build, when we add or change entities, the registry mappings will change.

OK, I will. Not sure though when I have the time - will be after Christmas.

I took a look. My script scripts/update_modbus_registers.sh does not exist any more. @proddy, you replaced it with generate_csv_and_headers.sh in 21acd90? The new script unconditionally overwrites modbus_entity_parameters.hpp completely, re-generating all entity mappings. That will ignore existing mappings and create new ones which will be different. update_modbus_registers.sh on the other hand only did this with the --reset command line option, specifically warning you in that case that it will re-generate everything. Without --reset it kept the all mappings, only adding new mappings. So the solution is not to overwrite modbus_entity_parameters.hpp in generate_csv_and_headers.sh. I double checked that update_modbus_registers.sh is still working as intended by restoring it from 0c76a24.

yes, I wanted to run one script to generate all header files which can be used on each PR. There might be new device entities and sometimes not. Is there a way to adjust the Modbus script so it works for each scenario, without manually intervention deciding whether or not to include the reset flag?

The reset flag is only required when breaking changes were made that require a complete rebuild anyways (I added it because the tags changed completely during modbus development). So I would just remove the cat >./src/modbus_entity_parameters.hpp <<EOL ... EOL lines from generate_csv_and_headers.sh and put them into a separate script like reset_modbus_entity_parameters.sh or something like that. If any breaking changes occur in the future we need to individually decide anyways how to keep modbus register mappings the same.