Use text representation of enum options

[jaroschek]

Switch to use text representation of enum options (like already done in select entity) to initially show readable options instead of numeric values.

This should solve onboarding issues, where new (and currently unknown) devices with unknown enum options do only show numeric values nobody understands.

As we currently use the numeric values for states in history too, we need to preserve the original translations that allowed localization of enum options.

But there is one downside to this:

Nibe has currently some enum parameters that include redundant text values for different numeric option values like the following:

  {
    "category": "NIBE S1255-6 E PC EM 3X400V",
    "parameterId": "1965",
    "parameterName": "Oper­ating mode com­pressor",
    "parameterUnit": "",
    "writable": false,
    "timestamp": "2024-01-11T20:34:18+00:00",
    "value": 60,
    "strVal": "On",
    "smartHomeCategories": [],
    "minValue": null,
    "maxValue": null,
    "stepValue": 1,
    "enumValues": [
      {
        "value": "20",
        "text": "Off",
        "icon": ""
      },
      {
        "value": "40",
        "text": "Starting",
        "icon": ""
      },
      {
        "value": "60",
        "text": "On",
        "icon": ""
      },
      {
        "value": "100",
        "text": "Stop­ping",
        "icon": ""
      },
      {
        "value": "120",
        "text": "Defrost­ing",
        "icon": ""
      },
      {
        "value": "140",
        "text": "Defrost­ing",
        "icon": ""
      },
      {
        "value": "160",
        "text": "Defrost­ing",
        "icon": ""
      }
    ],
    "scaleValue": "1",
    "zoneId": null
  },
  {
    "category": "NIBE S1255-6 E PC EM 3X400V",
    "parameterId": "55027",
    "parameterName": "Int elec add heat",
    "parameterUnit": "",
    "writable": false,
    "timestamp": "2024-01-11T18:45:24+00:00",
    "value": 4,
    "strVal": "Blocked",
    "smartHomeCategories": [],
    "minValue": null,
    "maxValue": null,
    "stepValue": 1,
    "enumValues": [
      {
        "value": "0",
        "text": "Alarm",
        "icon": ""
      },
      {
        "value": "1",
        "text": "Alarm",
        "icon": ""
      },
      {
        "value": "2",
        "text": "Active",
        "icon": ""
      },
      {
        "value": "3",
        "text": "Off",
        "icon": ""
      },
      {
        "value": "4",
        "text": "Blocked",
        "icon": ""
      },
      {
        "value": "5",
        "text": "Off",
        "icon": ""
      },
      {
        "value": "6",
        "text": "Active",
        "icon": ""
      }
    ],
    "scaleValue": "1",
    "zoneId": null
  }

As soon as we use the text values of the options we can not differentiate the different states any more. But may be this ist noch that important, as Nibe seems not to bother with that too.

[7RST1]

Looks like this is the way. I'd guess most other API implementations don't include redundant state values as you show, I don't think mine has any.

Worst case scenario might be a new user has a device where two states like these differ drastically in meaning but have the same string, where they could either contact their manufacturer or we add an exception. Should not happen though.