GadgetAngel
commented
5 years ago I updated my branch again. This time I incorporated the ability of the user to request or query the tuya device on one of its dps States. The MQTT topic STATE will reflect the value of that dps until the next command is sent.
Usually MQTT Topic only displays the STATE of DPS=1 but if the user uses the following JSON string it can the server will display the STATE of the specified DPS in the STATE TOPIC
The JSON string: { "dps": 7 }
I got the update pushed to you. Have fun.
TheAgentK
This new update allows the user to set multiple dps' or force a status update of all dps values via MQTT messages or topics
tuya/tuyaAPI-type/tuyaAPI-id/tuyaAPI-key/tuyaAPI-ip/state tuya/tuyaAPI-type/tuyaAPI-id/tuyaAPI-key/tuyaAPI-ip/command
the latest change: I got ride of the additional topic, I use the COMMAND topic. where the command topic can be followed by the JSON string for the dps settings or the message string(on="" or off="") can hold the JSON string of dps settings. The JSON string can also be for multiple dps settings. The JSON string can also force a request for all dps settings to be returned.
the "on" or "ON" or "off" or "OFF" or "1" or "0" can also follow the command topic or appear in the message area (on="" or off=""). IT all works now.
the three JSON strings are as follows:
So to put this all together, the dps topic still returns the status of the device.
the state topic : tuya/tuyaAPI-type/tuyaAPI-id/tuyaAPI-key/tuyaAPI-ip/state
the command topic: tuya/tuyaAPI-type/tuyaAPI-id/tuyaAPI-key/tuyaAPI-ip/command
to set one dps the command topic can look like the following: tuya/tuyaAPI-type/tuyaAPI-id/tuyaAPI-key/tuyaAPI-ip/command/ON tuya/tuyaAPI-type/tuyaAPI-id/tuyaAPI-key/tuyaAPI-ip/command/OFF tuya/tuyaAPI-type/tuyaAPI-id/tuyaAPI-key/tuyaAPI-ip/command/1 tuya/tuyaAPI-type/tuyaAPI-id/tuyaAPI-key/tuyaAPI-ip/command/0 tuya/tuyaAPI-type/tuyaAPI-id/tuyaAPI-key/tuyaAPI-ip/command/ { "dps": 1, "set": true } tuya/tuyaAPI-type/tuyaAPI-id/tuyaAPI-key/tuyaAPI-ip/command/ { "multiple": true, "data": { "1": true, "7": true } tuya/tuyaAPI-type/tuyaAPI-id/tuyaAPI-key/tuyaAPI-ip/command/ { "schema": true }
OR command topic: tuya/tuyaAPI-type/tuyaAPI-id/tuyaAPI-key/tuyaAPI-ip/command with the on="" or off="" being used as follows: 1 0 ON OFF { "dps": 1, "set": true } { "multiple": true, "data": { "1": true, "7": true } { "schema": true }
NOTE: During my tests, i noticed that when the tuya-mqtt.exe program is first started (initial boot up) the program gets a unhandledpromise rejection warning. I found a way to suppress the error message so that the user will not see these errors in the openhab2 error log.
If you are not aware the error message only shows up on initial boot or initial communication with a tuya device. After the first communication has been establish by sending the first command twice in a row then as long as the tuya-mqtt server is up and running and have talked to the device, the error will not return until reboot of the tuya-mqtt server.
Therefore, users should be made aware of openhab2 that if they use tuya-mqtt.exe they should upon reboot send two state commands to each device they plan to talk to ( { "schema": true } ).
I believe this is a TCP/IP problem. These tuya devices use a TCP and that protocol is not considered to be deterministic. The error message is coming from a routine outside the scope of tuya-mqtt code.
Here is the output of the init error (this is all the debug statements -TuyAPI debugs from sending one command topic:
================================================
TuyAPI-device switch -> OFF +1ms (node:2104) UnhandledPromiseRejectionWarning: Error: No connection has been made to the device. at TuyaDevice._send (C:\Users\joann\WebstormProjects\tuya-mqtt\node_modules\tuyapi\index.js:245:13) at Promise (C:\Users\joann\WebstormProjects\tuya-mqtt\node_modules\tuyapi\index.js:105:14) at new Promise (=========================================================
i hope this helps.