entity_ids not always removed from emsesp_customizations

[HansRemmerswaal]

This issue is absolutely not critical for me but its would be good if this gets fixed one day.

When excluding entitites and enabling them again, the ones with a min/max remain in the emsesp_customizations even if you do no have changed the min/max.

Steps to reproduce

• Factory reset or manually clean and load the emsesp_customizations.json
• In customization exclude entries from MQTT and dashboard. One with and one without min/max values
  
• Save and export customization
  emsesp_customizations (6).txt
• In customization enable the entries again
  
• Save and export customization
  emsesp_customizations (7).txt

From the emsesp_customizations the one without min/max has been removed, the one with min/max is still there.

"masked_entities": [
  {
    "product_id": 172,
    "device_id": 8,
    "entity_ids": [
      "00selflowtemp|>0<254"
    ]
  }

Expected behavior
Ensure that also the entries with min/max gets removed after they are made available again.

Device information
emsesp_info (2).txt

[MichaelDvP]

Customization is used for:

• flag entitiy to 08 - favorite, 04 - readonly, 02 - remove from api/mqtt, 01 - rmove from web
• set custom min/max
• set custom name

each of these customizations makes an entry in the file. To delete all customizations, click on the line, delete custom name, min and max value, save.

[HansRemmerswaal]

I get that, but the tapwateractive was added and removed automatically, the selfflowtemp stayed. So this is not a consistent behavior.

    "entity_ids": [
      "03tapwateractive",
      "03selflowtemp|>0<254"
    ]

"entity_ids": [
  "00selflowtemp|>0<254"
]

[proddy]

That's true, it's just lazy design and I was aware at the time of coding it. When an entity's customization is reset it still gets written to the JSON file but prefixed with '00' and ignored by EMS-ESP when the file is read during start-up. Ideally, it should be removed at the time of saving but its not harmful. It just means the filesize will grow but we have loads of Flash memory so it's ok for now.

I'll refactor it for 3.6.0

[MichaelDvP]

No, we have the customization as flags-name|customname>min<max
if the custom is reduced to 00selflowtemp it is removed.
01selflowtemp is saved because a flag is set
00selflowtemp|headertemp has a custom name and is saved
00selflowtemp|<100 is saved because of custom max.
you have to remove all customization to have it removed from file.

[HansRemmerswaal]

Starting point is zero customizations
Flag tapwateractive and selfflowtemp to be excluded from MQTT and display
Save
emsesp_customizations contains the entry for tapwateractive and selfflowtemp
Flag tapwateractive and selfflowtemp to be included again for MQTT and display
Save
emsesp_customizations contains the entry for selfflowtemp

So for both I did exactly the same but the result is different.

[HansRemmerswaal]

It's a very low prio this issue, more a nice to have.

[MichaelDvP]

It's not ideal, but we don't want to have original min/max and custom min/max in memory. First implemntation was with unset min/max the field in dialog is empty, but users prefere this variant with min/max shown. This makes that each time you click to save in this dialog the min/max is stored. As you see in your fist setting: "03selflowtemp|>0<254". To remove this you have to clear the min max values:
This stores min/max:

This clears min/max:

[HansRemmerswaal]

Ok, then maybe we better close this issue.