* Add ability to set individual DPS values via <topic>/dps/<#>/command
* Can still use Tuya JSON via <topic>/dps/command
* Simple on/off sent to <topic>/command
* Brightness sent to <topic>/brightness_command
* Simple device type detection (currently only for sockets/switches/dimmers and non-RGB lights, other devices are unknown get DPS 1 on/off in state and all other values accessible via DPS
* Usese devices.json from "tuya-cli wizard" for device discovery, no topic config required
* Uses device discovery by default, but can manually edit devices.json to add IP address, protocol version, or change
* Creates short topic name using just "friendly name" or "id".
* Merge protocol 3.3 support
* Update TuyAPI to 5.3.1
* Fixes for color settings issues with some devices
* Support to force device status update with schema query
This update allows for an essential TuyAPI command to be implemented and fixes issues with the TuyaColorLight.prototype.setColor Method label:enhancement
2. This update 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
3. This update uses the correct format for dps 5: if the bulb is in colour mode than the dps 3 and dps 4 are ignored but if you set it now some tuya bulbs will ignore dps 5 because you set dps 3 or dps 4
A. So, FOR colour mode the bulb looks at dps 1, dps 2, and dps 5.
i. DPS 5 is in the following format:
ii. HSL to HEX format are the leftmost hex digits (hex digits 14 - 9)
iii. hex digits 8 - 5 are the HSB/HSL Hue value in HEX format
iv. hex digits 4 - 3 are the HSB/HSL Saturation percentage as a value (converted to 0-255 scale) in HEX format
v. hex digits 2 - 1 are the HSB Brightness percentage as a value (converted to 25-255 scale) in HEX format
B. if the bulb is in 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
i. DPS 3 is the HSB/HSL Brightness percentage converted to a value from 25 to 255 in decimal format
ii. DPS 4 is the HSB/HSL Saturation percentage converted to a value from 0 to 255 in decimal format
{"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.
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"
{"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.
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"
{"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.
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"
