This update allows for an essential TuyAPI command to be implemented and fixes issues with the TuyaColorLight.prototype.setColor Method label:enhancement

[GadgetAngel]

1. This update allows for an essential TuyAPI command to be implemented via the tuya-mqtt.exe MQTT server. {"schema": true} is the ONLY COMMAND that the TuyAPI GET method implements. Also fixes a problem with the setColor method of TuyaColorLight.
2. This pull request (fa22807) does NOT set dps 3 and dps 4 when setting the bulb in 'colour' mode because some tuya bulbs ignore the dps 5 setting if you set either dps 3 or dps 4 which forces the bulb to display white values even tho dps 2 is set to 'colour'. See issues: #20 and #22
3. As far as I can tell, the correct format for dps 5 is as follows:

If the bulb is in 'colour' mode than the dps 3 and dps 4 are ignored but if you set them now, some tuya bulbs will ignore dps 5 because you set dps 3 or dps 4. The Tuya bulb will get it brightness setting and saturation setting from the dps 5 hex digits.

A. FOR 'colour' mode the bulb looks at dps 1, dps 2, and dps 5.

1. DPS 5 is in the following format:
2. HSL to HEX format are the leftmost hex digits (hex digits 14 - 9). This is as you did before.
3. hex digits 8 - 5 are the HSB/HSL Hue value in HEX format.
4. hex digits 4 - 3 are the HSB/HSL Saturation percentage as a value (converted to "0 - 255" scale) in HEX format. I give you the correct linear fit equation that I obtained from the live data. The saturation conversion and the color temperature conversion are the same linear fit equation.
5. hex digits 2 - 1 are the HSB Brightness percentage as a value (converted to "25 - 255" scale) in HEX format. I give you the correct linear fit equation that I obtained from the live data.

B. FOR 'white' mode then the dps 5 value is ignored by the bulb, FOR 'white' mode the bulb looks at dps 1, dps 2, dps 3 and dps 4

1. hex digits 2 - 1 are the HSB Brightness percentage as a value (converted to "25 - 255" scale) in HEX format. I give you the correct linear fit equation that I obtained from the live data.
2. DPS 4 is the HSB/HSL Saturation percentage converted to a value; "0 to 255" in decimal format. I give you the correct linear fit equation that i obtained from the live data.

C. The color temperature and saturation scale (DPS 4) conversions can be done with the following linear fit equation: Math.round( 2.5498*percentage_value - 0.4601) , in pull request fa22807

D. The brightness scale conversion (DPS 3) can be done with the following linear fit equation: Math.round( 2.3206*percentage_value + 22.56), in pull request fa22807

{"schema": true} allows the user to establish that proper communications with the tuya device can occur WITHOUT actually changing the present STATE of the device. This is the only command that will query the tuya device.

Please ignore commit 4ea15db. It is NOT needed

The current documentation says that you can query the tuya device over the "dps" TOPIC but from what I see the present state of the software does not force the tuya device to respond when using the "dps" TOPIC.

Since {"schema": true} is a command that forces a response from the tuya device, this command has been implemented under the "command" TOPIC. So "command" is the action and '{"schema": true}' becomes the command. The response is returned just like all other commands. I, use this command to guarantee communications has been established with the tuya device. If this "schema" command fails, tuya-mqtt will indicate the result in the openhab.log file and then I, can find out what is physically wrong with the communications. If this command fails the first time due to "socket" error and then goes through on the second attempt then I know that the error was due to TCP communications problem on initial startup. This command helps as a work-a-round for the "ERROR: socket problem"

[tsightler]

Thank you for this submission, I'll start reviewing soon (probably a week or two) and look to merge and publish along with my backlog of updates.