Retain modus offsets when new EMS entities are added

[proddy]

Reported in Discord

Hi, I´m using Modbus TCP, and I wonder if it's possible to avoid frequent changes of the offset register. With each update, most of the offset numbers change, so I have to change all my numbers in the logic.
Maybe you could keep the existing offsets, at least for a while and create new information with a higher offset number.

[proddy]

@mheyse any suggestions how to do this in the scripts?

[mheyse]

The offsets are already kept if new registers are added with the generate_csv_and_headers.sh script as documented here: https://docs.emsesp.org/Modbus-Dev/

They only change if all registers have to be re-generated when breaking changes are introduced (like modifying the tags, change data types as has happended during 3.7.0 development). This requires a dev to manually delete all mappings in modubs_entity_parameters.hpp .

[chriscortez1976]

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)

[proddy]

That makes perfect sense, thanks @mheyse

[proddy]

@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.

[mheyse]

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

[mheyse]

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.

[proddy]

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?

[mheyse]

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.