3.4 b11 - very small observations / clarifications

[harvey637]

Hi,
saving customization works great - no problems with saving in chunks!

some very small "beautifying" of things:
thermostat:

• "date/time" -> "time/date" (as this is the order of infos: "10:13:31 05.04.2022", or change the value to the more often used term date/time)
• "hc1/summermode" = "on|off" (index is shown, value is more intuitive)

boiler:

• some entities are shown as index, where a value list "On|Off" is known to the api and send correctly, (HP heating, HP Compressor, ...)
• some entities have (short and long) names, but no value (e.g. mixing switch temperature (switchtemp)): could they be marked "no_api + hidden" by default?
• "wwstarts2" -> "dhw control starts2"

The "api/system/customization" does only contain some of the customisation, and I have a lot of it in product_id=172 (boiler) :

{
  "label": "customizations",
  "Customizations": {
    "sensors": [],
    "analogs": [],
    "masked_entities": [
      {
        "product_id": 200,
        "device_id": 56,
        "entities": [
          "08dewtemperature"
        ]
      },
      {
        "product_id": 158,
        "device_id": 16,
        "entities": [
          "02errorcode",
          "02lastcode",
          "03floordry",
          "03floordrytemp",
          "03building",
          "03minexttemp",
          "03wwsettemp",
          "03wwmode",
          "03wwsettemplow",
          "03wwcircmode",
          "03wwchargeduration",
          "03wwcharge",
          "03wwextra1",
          "03wwextra2",
          "03wwdisinfecting",
          "03wwdisinfectday"
        ]
      },
      {
        "product_id": 172,
        "device_id": 8,
        "entities": []
      }
    ]
  }
} 

please notice that this is NOT complains, just "customer" oberservations in MY real life installation. I want to help to improve even small things, hopefully also only small code changes :-)

Keep on your good work please!
cu
Harvey

[MichaelDvP]

1. date/time: the esp-time is also date first, so i think we change the order of data in thermostat.
2. and
3. can not see this, what is your setting for bool/enum format? Which values are wrong, where (mqtt/api/dashboard/settings-list/terminal)? What is shown for http://ems-esp.local/api/thermostat/hc1/summertemp and for http://ems-esp.local/api/thermostat/hc1 ?
4. no value means that we have no or invalid data from ems. If data comes later the value should be shown, but if someone savesthe list before it is excluded. Not a good idea.
5. ok
6. Works for me. Have you checked if it works with less masked entities? Is there a limit?

[harvey637]

Hi,
1: mine looks like this: "date/time 16:42:07 05.04.2022", changing one or the other maks it right :-)
2: summer_mode is "0", but e.g. set_summer_mode is "auto" (also see date/time in the screenshot ... )

in the api I get the correct valuelist:

{
  "name": "summersetmode",
  "fullname": "hc1 set summer mode",
  "circuit": "hc1",
  "value": 1,
  "type": "enum",
  "enum": [
    "summer",
    "auto",
    "winter"
  ],
  "readable": true,
  "writeable": true,
  "visible": true
} 

perfect, "auto" is shown in dashboard (see screenshot) , index is given to api (as requested)

for "summermode" in iobroker/ems-esp I get:

  "_id": "ems-esp.0.thermostat.hc1.summermode",
  "type": "state",
  "common": {
    "id": "thermostat.hc1.summermode",
    "name": "ems: hc1 summer mode",
    "type": "number",
    "read": true,
    "write": false,
    "role": "value",
    "states": {
      "0": "Off",
      "1": "On"
    },

which makes me think the info (On|Off) is somewhere (found in the "states: 0: Off 1: On" part).

4: ok, perfect. My Idea was, that if a NAME is found on the bus but NO value than never a value will be found. If entities are still not all found there is also no NAME. (I have some NAMES for some sensors, that might not be in my bosch 7400, but they are reported (found) by name without value (in contrast to some non_existing sensors with value=0).
5: thank you
6: after changing one entity ONLY this entity is in the customization (only printed last part here:)

          "03wwdisinfectday"
        ]
      },
      {
        "product_id": 172,
        "device_id": 8,
        "entities": [
          "08heatingtemp"
        ]
      }
    ]

but ALL the customizations for the other devices .... strange

While looking for this clarification I found ome more strange reaading:
"hpheatingon" toggles between "0" =off and "255" = on. Others as hpcoolingon have "1|0" ... only just seen
Even stranger: dashboard is like this:

but api gives:

  "hppower": 4.9,
  "hpcompon": 0,
  "hpactivity": 1,
  "hpheatingon": 1,
  "hpcoolingon": 0,
  "hpcompspd": 48,
  "hpcircspd": 20,
  "hpsuctiongas": 1.3,

Hmmmmm .....

cu
Harvey

[MichaelDvP]

Please check your setting of bool format:

The summersetmode command is an enum with winter/auto/summer, summermode status is in RC300 bool (on/off), but i see for other thermostats we have also enum winter/summer. Maybe better to set the same scheme for all thermostats.
The entity list seems to be another full buffer, the last list is shown empty if the buffer is noot large enough to hold all entitiies.

[harvey637]

Hi Michael,
as requested by iobroker/ems-esp plugin (we have api v3) I set Boolean Format to 1|0 and Enum Format to Index (wording is a bit different ...).
I thought that this is ONLY for API, as I see everything else in dashboard as enum-values like On|Off or auto|summer|winter or auto|manual or "prog_1|prog_2". In the api I see the requesed index of enums or 1|0 for boolean values.

Only strange with summer_mode ????

One afterthought: maybe some are really booleans (summermode) but others are enums with only two values like "optimized|auto" or "prog_1| prog_2" ?????

YES!!!

{
  "name": "summermode",
  "fullname": "hc1 summer mode",
  "circuit": "hc1",
  "value": 0,
  "type": "boolean",
  "readable": true,
  "writeable": false,
  "visible": true
}

Maybe that booleans shold be "On|Off" or "true|false" in the dashboard allways to be different from the value 0 (=zero)? just an idea :-)

important settings in EMS-ESP:
API V2: MQTT Settings have to be boolean format 1/0 !
API V3: Formatting Options for Boolean Format has to be 1/0 and for Enum Format Number
The Enable API write commands settings within ems-esp has to be enabled
Bypass Access Token authorization on API calls has to be set or the token has to be entered.

[MichaelDvP]

Oh, i thought that thomas has changed it to allow also other settings. I have the ioBroker-adapter installed for testing (but using ioBroker-mqtt with publish on change), and it seems to work with my settings.

There are a few enums with only 2 options, that's because other thermostats have more options in the same files, prog_1/prog_1 is for Junkers prog_a..prog_f, see here.

[harvey637]

I will check other format settings with iobroker/ems-esp too. But I also have some tcl/shell scripts, that need adoption then, but no problem, regex is my friend.

But some things are sorted out: enums with two values versus booleans - thank you for helping. Do you even think on replacing them with "Off|On" ?

Leaves this date/time thingy (looks easy) and this funny hpheatingon=255 value, as this is boolean, but not 1|0 :-(

Buffer length can wait, as saving in chunks works. I will look further if ther might be an "restore saved settings/customizations".
cu
Harvey

[MichaelDvP]

IRC look here Thomas checks all bool states, and i think enum is also correctly indexed. Youre free to select your favorite bool format.

The hpheatingon=255 is unclear why not handled as bool. I suspect a auto compiler directive as cause.

In my github i've changed thermostat time, summermode, wwstarts2 and maybe bool is now ok, please check.

[proddy]

The "api/system/customization" does only contain some of the customisation, and I have a lot of it in product_id=172 (boiler)

This is a bug, I get the same results. The masked_entities is only saving the last batch to the file system. I'll fix it. Thanks for the testing and reporting Harvey!

[harvey637]

Hi Micheal,
date/time looks good, summer/winter is great!
api/customisations contains everything (after new setting of it)

Some very very minor opinions:

• what about date in ISO as"2022-04-05", think about british and american users?

• I really dont know, but is winter/summer for the boiler something as "heating period|cooling period" - just thinking ...

• controlstarts2 (wwstarts2) looks like "dhw control starts2" from the shortname - better long name.

• what about faking dashboard readings of boleans into "true|false" - also just thinking (the ...on shortnames should expand to ... running?)

• as I see some locale in the source, how do I set it? (do I want to set it? :-)

• hpheatingon still 255 (api is ok with 1|0) (may be "HP heating running" :-)

Thank You
Harvey

[proddy]

as I see some locale in the source, how do I set it? (do I want to set it? :-)

hmm, renaming an entity? The logic is in the code, as we do this for the sensors. Maybe a new enhancement issue in GitHub for later.

[harvey637]

Hi @ Michael,
I see a src/locale_DE.h in proddys dev branch :-)

[MichaelDvP]

• what about date in ISO as"2022-04-05", think about british and american users?

I don't think bosch heating is very common in US, and ISO is not common in some european countries (Netherlands, Belgium, Switzeland, see here: https://en.wikipedia.org/wiki/Date_format_by_country

• I really dont know, but is winter/summer for the boiler something as "heating period|cooling period" - just thinking ...

Yes, for gas/oil boilers summer is heating off, only dhw preparation. For heatpump with cooling you have to check the manual.

• controlstarts2 (wwstarts2) looks like "dhw control starts2" from the shortname - better long name.

all ww.. have full name prefixed with "dhw".

• what about faking dashboard readings of boleans into "true|false" - also just thinking (the ...on shortnames should expand to ... running?)

In an older version there was dashboard always "on/off", but was later changed to make the selected bool format visible and avoid confusion.

• as I see some locale in the source, how do I set it? (do I want to set it? :-)

See #22, there is a plan for localization, a while ago i've started to translate the full names to german, but it's not complete. You can replace the include of local_EN.h by local_DE.h and recompile, but webpage, terminal, logs have no localization yet, looks odd.

[harvey637]

Hi @ Michael,
thank your for your explanation.

• date, ok, I can live with it (although I prefer ISO for automatic sorting e.g. of images, no problem here)
• yes, my bosch has cooling, so I will wait for summer to see the summermode change (setsummermode is auto)
• sorry to say that wwstarts2 still is only "control starts" in proddys latest dev b11
• true|false versus 1|0: now I cant distinguish between eg. "0" as for zero hours running, and on|off

I changed the format to true|false, now I see true|false in the dashboard, but also in the api. So I had to change MY OWN scripts working with the api with the help of regex :-)

Maybe that the api should be (a little bit more) independant from dashboard gui? Or with different format option for dashboard and api?
By the way, the "index|value" selector works this way, changing does not change dashboard, but only api .....

cu
Harvey

[proddy]

We added the 1|0 for booleans because of Domoticz. Home Assistant can be configured to use anything. I'm not sure what ioBroker uses.

The dashboard was never really supposed to be the final end-stop for looking at the data. It's assumed most people will use home automation front-ends which is why its just a simple table (not filtering, sorting, searching...).

Adding a Boolean Format for the Dashboard is easy to do, if we want it.

[harvey637]

Hi @ Proddy,
thank you.
iobroker/ems-esp plugin uses a lot of stuff like true|false, 0|1 "true"|"false". It also knows about booleans and enumerations.
But on top I also have some homewritten scripts (curl to api) in simple tcl or shell, where I use regex to fetch the "true" state.

It was a little bit confusing for me, that the "format" option for booleans are for both dashboard AND api, but the format for enumerations is ONLY for api. I see this as changing the format of both does only alter representation of boolenas in the dashboard AND api, but enumerations are allways shown as values in dashboard (whatever format enum option), but the api representation is changed accordingly.

So I think, there should be an explanation that the boolean option is for both, enum option only for api.

OR EVEN BETTER:
format option(s) for dashboard (maybe we never need dashboard ENUM format option), so only dashboard BOOLEAN format option,
AND both format options separately for api, BOOLEANs to satisfy domotiz with "1|0" and possible others with different format, and the ENUMS as "index" (for systems handling index of enums and values of enums) or "value" (mostly for dump display systems.

just my idea .....

and please fix this simple "wwstarts2" -> "dhw controls starts2" long name (as Michael has done it)

Thank you and
cu
Harvey

[proddy]

sorry to say that wwstarts2 still is only "control starts" in proddys latest dev b11

@MichaelDvP is this changed in your build or shall I add it?

[MichaelDvP]

Partly in my build, i have to change the tag to ww, i'll make a pr. I was thinking about the clock format. The thermostat clock is read every minute, publish is mostly asynchron wth 10 seconds, showing the clock with seconds is always incorrect. What do you think about publishing only "hh:mm"?
(The "last_error" are already in format "dd.mm.yyyy hh:mm")

[harvey637]

Moin Michael,
"hh:mm" sounds very good to me! "dhw control starts2" also.
thank you
Harvey

[proddy]

yup. agree with both

[MichaelDvP]

Ok, i'll also add RCTime-Message to controller, this strange IVT in #439 publishes the thermstat time via controller if thermostat display is in sleep. (and show controller in web if it has entities)