emsesp / EMS-ESP32

ESP32 firmware to read and control EMS and Heatronic compatible equipment such as boilers, thermostats, solar modules, and heat pumps
https://emsesp.github.io/docs
GNU Lesser General Public License v3.0
580 stars 101 forks source link

Refactor DeviceType #1125

Closed proddy closed 3 months ago

proddy commented 1 year ago
          It's a enum and must match the emsdevice.h enum, the icons are shifted by one before, e.g boiler shows up with thermostat icon.

Scheduler is listed as device because commands/api check for valid device from this list, system, analog, dallas are also no ems-devices, but devices for api/command.

Before fix and after fix: grafik grafik

_Originally posted by @MichaelDvP in https://github.com/emsesp/EMS-ESP32/pull/1124#discussion_r1136803102_

MichaelDvP commented 1 year ago

I've never understood what you declare as "device". Sometimes only "ems-devices", like in telnet "show devices". But sometimes this includes system and dallassensor like in https://emsesp.github.io/docs/Commands/.

Bt the mqtt publishes the values with topic "device_data". API uses "/api/device/...", etc. In my understanding these device definitions fit's to:

If you want to remove scheduler from this scheme, also remove system, shower, sensors. But please describe the different endpoints for mqtt, api, etc., because it will get confusing.

proddy commented 1 year ago

The framework is based on a design that I had created 2 years ago for v3 where I wanted to make EMS-ESP extendable and support multiple devices. The shower, system etc came afterwards as a bit of hack and I never anticipated the adoption of the project. The code needs a good re-factor. Something for v4 if we get there and I'm still around.

MichaelDvP commented 1 year ago

The design principals only mention "EMS-devices", i think "devices" is umbrella term for "EMS-devices" and "other-devices". I started with v1.9 and there was "shower_data", dallassensors were published as "sensors" and the system was called "settings_data", but mainly handled the same way as an ems-device. Ok, the commands were caotic without any name scheme, now it's much more in line. I like the way to have all in one unified scheme: "call" shows me possible devices, "call device" the possible commands, "/api/device" all values, etc.. No documentation needed.

norberts1 commented 1 year ago

Is it possible to differ between:

  1. Logical devices:

    • heating-sources like: boiler(s), heating-pump(s), etc.
    • heating-circuits (1...8)
    • Domestic Hot Water parts
    • solar thermal parts

    and

    1. Physical devices (device-id):
      • EMS-devices
      • dallassensors
      • any other hw-sensor

Then it would be easier and more flexible to assign messages from the physical- to the logical-devices. Examples:

  1. The dallassensors can measure any temperature in the system. Depending on there placement the assignment differs and can be to heating-circuits, DHW-tanks etc.
  2. The powermodul IPM200 (Bosch/Junkers) is configure able to handle 2 mixed-heating-circuits or 1 heating-circuit and one DHW-generation. Depending on this configuration the messages differs and the assignment to logical devices make it easier to handle.
  3. "shower_data" can be assigned then to logical-part: DHW.

Most of that messages from EMS-devices are unique and assigned to logical parts of the system but not close linked to the hardware device-id.