I'm looking at issues in Domoticz setting, but mostly displaying Thermostat mode devices. I feel that the API ValueList provides causes index and value of the items in the ValueList to be intermixed in client applications. This causes f.e. proper values like 31 (for Manufacturer Specific) received from the node(!) to be rejected in OZW under some circumstances.
This raised for me the question what is the intended purpose of the items in the ValueList? Are the items meant to be used for validating the values in OZW coming from either the client or the node? Or are they meant to be used to build/fill a gui element to present the supported values so an end user can read it or select one of the available options?
I see that the current implementation is to put in an extra validation on the values passed from and to the node. I think however that this is not needed: the device itself will respond with an error if the mode sent to it is not a supported mode, so why do we need to implement another check in the OZW layer for this? My opinion is that a validation of the value specified or retrieved in OZW doesn't add any extra functionality. It just makes the implementation and thus the use of ValueList overly complex.
I think the items in a ValueList should be seen only as a means to provide a GUI with human readable translations for the values supported by the device. In that matter ValueList could be implemented as a child of ValueInt, containing the int value sent to and received from the node, without any validation other than that it is in the valid range for uint8, uint16 or uint32 depending on the list "size". ValueList only adds extra methods to retrieve the list of supported modes from the device and to present that list to the GUI to build an option list or a mode description. This re-defiinition of the ValueList's purpose will reduce the complexity of the logic and API of the ValueList and eliminates the dual-purpose of the current ValueList implementation.