Warning "wrong formatting options for api/mqtt enum format"

[harvey637]

Hi, running ems-esp-3.7.0-dev4 (and before) with enum settings as "Index". Now with iobroker.emsesp v3.4.0 this warnung about wrong use of this setting, so I changed into "Value" to get a green adapter status.

I am not using km200.

In my opinion the setting "use enums as INDEX" make perfect sense for an API, as "Value" is language dependent.

This is the output with "Value":

  "hpcompon": 0,
  "hpactivity": "Abtauen",
  "hpswitchvalve": 1,
...  
  "hp4way": "Kühlen & Abtauen",
  "auxheaterstatus": 0,
  "auxheatrmode": "Eco",
  "auxheatmix": 0,
...
  "hppumpmode": "auto",

this is the fetch with enums as "Index"

  "hpcompon": 0,
  "hpactivity": 1,
  "hpswitchvalve": 1,
...
  "hp4way": 0,
  "auxheaterstatus": 0,
  "auxheatrmode": 0,
  "auxheatmix": 0,
...
  "hppumpmode": 0,

My expected behaviour is to transport easy formats in API/MQTT .... In the object states ther is the translation of index into value:

{
  "_id": "ems-esp.0.boiler.hpactivity",
  "type": "state",
  "common": {
    "id": "boiler.hpactivity",
    "name": "ems: Kompressor-Betriebsmodus",
    "type": "mixed",
    "read": true,
    "write": false,
    "role": "value",
    "states": {
      "0": "keine",
      "1": "Heizen",
      "2": "Kühlen",
      "3": "Warmwasser",
      "4": "Pool",
      "5": "Unbekannt",
      "6": "Abtauen"
    },

So my whish is to keep the "correct" setting of api/mqtt settings for enums as index. And dont throw this as warning, the status color of the iobroker-emsesp should be GREEN (not yellow).

thank you for looking into this! cu Harvey PS: until updated I need to stay at "index" with yellow adapter flag .... as some scripts also parse the api-call and fixing "hpactivity": "Abtauen" into a graph seems not beeing helpfull:

(see te orange background for heating and WP Aktivität for none/heating/defrost .... textual representation seems useless)

[tp1de]

The checks for boolean and enum are according to the existing documentation. (since > 2 years) When not passed polling is stopped in adapter version 3.4.0 because I had too many people not reading docu. But I understand your argument.

Please reinstall version 3.3.0. I need to check what to do.

[harvey637]

It looks from the changelog that this was introduced with 3.3.0 on the 2024-04-20.

Stopping the adapter to read from ems-esp makes it impossible for me to continue this (and 3.4.0) version without scripts. I need the numerical value to put them into graphs.

Now I did some scripts to read the textual enums (enums=VALUE) back into the index to write them into my own variables. Looks awfull and is not transportable, will breeak with any change in the text, even with language change of the ems-eps GUI.

# 2024-04-26 !!!!!!! ems-esp: api-enums=VALUE !!!!!!
# --- WP-hpactivity
#      "0": "keine",
#      "1": "Heizen",
#      "2": "Kühlen",
#      "3": "Warmwasser",
#      "4": "Pool",
#      "5": "Unbekannt",
#      "6": "Abtauen"

    set hpactivity 9

    regexp "hpactivity.:(.*?)," $input dummy hpactiv ;

    if {[regexp "keine" $hpactiv]} {
       set hpactivity 0
    }
    if {[regexp "Heizen" $hpactiv]} {
       set hpactivity 1
    }
    if {[regexp "Kühlen" $hpactiv]} {
       set hpactivity 2
    }
    if {[regexp "Warmwasser" $hpactiv]} {
       set hpactivity 3
    }
    if {[regexp "Pool" $hpactiv]} {
       set hpactivity 4
    }
    if {[regexp "Unbekannt" $hpactiv]} {
       set hpactivity 5
    }
    if {[regexp "Abtauen" $hpactiv]} {
       set hpactivity 6
    }

or is there a way to read the INDEX even with setting enums=VALUE ????? like http://ems-esp/api/thermostat&??????

[harvey637]

Hi, I even think that some of these setting (and the possibility to set them differently for GUI and API) was requested and implemented in the ems-esp gateway firmware by me. My idea behind setting GUI and API in two settings was to get a language dependent GUI like:

and a language independent API (with index). Also the boolean could be "An/Aus" in the gui and still 1/0 in the API.

Now your "demand" for using VALUE for the enums reintroduces the language dependent stuff in the API call again :-( Sometimes translations are wrong and my scripts need(ed) to adopt even the slightest changes, with the INDEX. Even sometimes I have to change the GUI-language to understand translations back to english, as the german wording is misleading.

Thank You for understanding my point of view!

[harvey637]

For me it looks, that the GUI always uses the VALUE in the selected language for enums (see above for "Wetter kompensiert"). As seen in the iobroker objects I see (and saw since long time) that the enums have the textual representation in the iobroker-object, so they are fetched from the api-call when a object is created.

What is the use case for reading the value for enums and not the index? Just asking to understand ....

(as you already know them without setting enums=VALUE)

[harvey637]

Thank You!!!! I see you commiting in ems.js now accepting index and value !!!!!! Will recheck after 3.4.1 of the adapter. (no other problems, but I am not using the heat demand and energy stuff right now)

cu Harvey

[tp1de]

3.4.1 is out without the check for enum settings.

I recognized that I was already accepting both ways within the code since a long time to avoid errors. Just bool 0/1 is mandatory.

The ems-esp gateway way of creating objects was made similar to the output of km200 api and objects created by the old km200 adapter.

While testing again, I recognized that the last admin adapter version (6.17.6) does not show the enum values anymore within the object browser. Other users already opened GH issues.

Version 3.7 firmware is changing names and structure of warm water objects unless you use km200 structure. Be careful.

[harvey637]

testing .... working !

thank you.

With warm water I am lucky, my warm water comes from the sun (solarthermie without connecting to heatpump :-)

cu Harvey