ESPHome is a system to control your ESP8266/ESP32 by simple yet powerful configuration files and control them remotely through Home Automation systems.
Since there is no official documentation we can refer our device datapoints, we have to tust any list that someone else compiled for maybe a different device. This is no problem when trying to read something.
This might be a problem when trying to write some value to an arbitrary datapoint.
If for instance "the list of choice" declares datapoint 0x1234 as "display background light" with possible values 0 and 1, I may be tempted to define a switch for that. If however, the current value of DP 0x1234 reads as "36" because in reality this DP maps to "condensor target temperature" or something on MY device, then it is a solid hint that this value does not fit with a "switch" and I might eventually break my device. I would notice, that the light does not go on as expected when writing a 1 and to be on the safe side, I could reset it to the previous value "0" which is equally wrong. I would not even know that this DP previously had a "36" in it and thus unable to undo my choice.
The same for a selector that is documented to allow for values 1-6 but reads as 8 for the current value. I would be unable to reset it to the previous (and probably correct) value, if I define the documented values as possible selections.
Certainly, we should make a snapshot of all current values before changing anything, but that too sounds easier as it turns out.
It would be of great value, if the program checks, whether the current value does fit into the range of selectable values for the component and refuse the creation or activation of the switch/selector/... with a suitable error.
Since there is no official documentation we can refer our device datapoints, we have to tust any list that someone else compiled for maybe a different device. This is no problem when trying to read something.
This might be a problem when trying to write some value to an arbitrary datapoint.
If for instance "the list of choice" declares datapoint 0x1234 as "display background light" with possible values 0 and 1, I may be tempted to define a switch for that. If however, the current value of DP 0x1234 reads as "36" because in reality this DP maps to "condensor target temperature" or something on MY device, then it is a solid hint that this value does not fit with a "switch" and I might eventually break my device. I would notice, that the light does not go on as expected when writing a 1 and to be on the safe side, I could reset it to the previous value "0" which is equally wrong. I would not even know that this DP previously had a "36" in it and thus unable to undo my choice.
The same for a selector that is documented to allow for values 1-6 but reads as 8 for the current value. I would be unable to reset it to the previous (and probably correct) value, if I define the documented values as possible selections.
Certainly, we should make a snapshot of all current values before changing anything, but that too sounds easier as it turns out.
It would be of great value, if the program checks, whether the current value does fit into the range of selectable values for the component and refuse the creation or activation of the switch/selector/... with a suitable error.