Refactor DeviceType

[proddy]

          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:

Originally posted by @MichaelDvP in #1124 (comment)

[MichaelDvP]

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:

• system, shower, analogsensors, dallassensors, scheduler and the detected ems-devices.

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]

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]

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]

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

2. 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.