Giter VIP home page Giter VIP logo

node-red-contrib-tuya-smart-device's Introduction

node-red-contrib-tuya-smart-device

npm NPM Build and Publish package License

A node-red module which helps you to connect to any tuya device.

image

Table of contents

Requirements

  • nodeJS >= 16.0.0
  • node-red >= 2.5.0

Features

  • Controls tuya device
  • Controls multiple device using a single node using generic node (hub node)
  • Can use device IP for communication
  • Configure retry and find intervals
  • Ability to setup Tuya Protocol Version
  • Ability to listen to both Data and DP-Refresh event
  • Can store deviceId and deviceKey as crendentials
  • Better error handling
  • Better log handling

Getting Started

Instructions for getting the device id is available here

Another technique for getting all deviceid linked to your tuya account

https://github-wiki-see.page/m/iRayanKhan/homebridge-tuya/wiki/Get-Local-Keys-for-your-devices

You will get the device id and the key once you run the wizard program as per the instructiions

Get more details about latest version changes in the CHANGELOG.md

Setup

(Back to top)

The node takes one input and one output. Once you drop the node into the flow, you need to use the deviceid and devicekey that you got from the getting started step.

Once you setup the node, you can then use input to send any command to the device as per the tuya standards.

Input Format

(Back to top)

image

Output Format

(Back to top)

image

If you need the error thrown by the node use the catch node.

The status output sends the state of the client (CONNECTING,CONNECTED,ERROR or DISCONNECTED). It will only send message if the state has been changed. . eg: even though multiple errors have been thrown, only once the ERROR state will be send. One possible scenario is ERROR -> CONNECTING -> CONNECTED. again if ERROR occurs , then the state is send out of the node.

Examples

You can refer the example flow to get started

Troubleshooting

  • I am getting "Can't find device error"

    The can't find device error can be due to many reasons

    1. Make sure the device is powered on
    2. Make sure the Device ID / IP / Key are correct
    3. Make sure that you haven't created multiple nodes for the same device. Multiple connections to the same device is not possible. This is a limitation of TuyAPI.

  • What is the difference between FindTimeout and RetryTimeout?

    FindTimeout is the time in milliseconds that tuya api will check for a device. Once the timeout has breached, the can't find device error is shown.

    RetryTimeout is the time in milliseconds to wait for the node to retry the connection once the device connection is disconnected due to some unexpected errors.

  • What is the purpose of the status output ?

    The status output can be used to get the state of the current node(client). Whether disconnected or in error. You can make logic in node-red using this status. If you need to catch the whole error use the catch node.

License

(Back to top)

MIT License - Copyright (c) 2020 Vinod S R

Contributing

(Back to top)

Your contributions are always welcome! Please have a look at the contribution guidelines first. 🎉

node-red-contrib-tuya-smart-device's People

Contributors

saimond avatar vinodsr avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar

Forkers

neosource 2bad2b007 daesdel unknownwyj zigit 8none1 ouyang789987 msillano hbomb2003 fabcia halaszk anetdev saimond tadthies

node-red-contrib-tuya-smart-device's Issues

Version 4.1.1 error Base64 string

Hey ich möchte einen datenpunkt in Base64 setzen

{
   "dps": 1,
   "set": "fwgAAQF/DgABAH8TAAEB"
}

jedoch mit der Version 4.1.0 wird nur noch ein fehler ausgegeben

TypeError: Converting circular structure to JSON --> starting at object with constructor 'Socket' | property 'parser' -> object with constructor 'HTTPParser' --- property 'socket' closes the circle

ich muss auf [email protected] downgraden

Ich bitte um hilfe

Gruß
Matten Matten

Timeout at generic node

Hello,
the device-node works fine for me. However, I get error messages in 3 out of 10 cases with the generic node:

An error had occured : find() timed out. Is the device powered on and the ID or IP correct?

or

An error had occured : Error: Error from socket
An error had occured : Timeout waiting for status response from device id:XXXXXXX

Of course the device is powered on and the IP or ID are correct; a ping from the raspberry with node-red to the device works fine and stable. It makes no difference if you use ID or IP.
Thanks for any help,
Achim

Code data?

I getting strange data from tuya device. Anyone has the same issue?

data:
p�@x�J�K�=n���!�A2�}����2���hzmW

image
image

Connecting to Tuya Device from Node Red in Docker Container

Hi,

I can't connect to my tuya Device from Node Red in Docker Container. It is working from a Node Red directly installed on a Raspberry PI.

I added the Ports

- "6666:6666/udp"
- "6667:6667/udp"
- "6668:6668/udp"

to the container but with out success.

Any Tipp?

Thank you.
Markus

Data is in binary not JSON

I am working with a Gosund LB3 bedside lamp. I have it all connected and when I switch it on and off, or change the settings, I get an event as expected. But payload.data contains a string full of gibberish - except I can recognise "3.3" as the first three characters.

{"log":"9 May 11:28:33 - [info] [tuya-smart-device:Colin Bed] Data from device [event:data]: \"3.3\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0000\\u0012\\u0000\\u0000\\u0000\\u0001x��M�ל\\u0014��S~(����=|�}c����I\\u0017L/\\u0013���ʛ���hu����ÚR\u0015��\u0000VA�\b/P\u0015�a\u0019��[t�룠���j�_\u000e�"\n","stream":"stdout","time":"2021-05-09T09:28:33.967091852Z"}`

Does anyone have any idea what is going on here?
I have tried to look at the data in binary, but as it is contained in a string, loads of values get converted to 0xfffd so I can't really analyse it like that. I end up with (might not be the exact same message as above):

0033 002e 0033 0000 0000 0000 0000 0000 0000 0000 0012 0000 0000 0000 0001 0078 fffd fffd 004d fffd 05dc 0014 fffd fffd 0053 007e 0028 fffd fffd fffd fffd 003d 007c fffd 007d 0063 fffd fffd fffd fffd 0049 0017 0
04c 002f 0013 fffd fffd fffd 029b fffd fffd fffd 0068 0075 fffd fffd 0060 fffd fffd 00da 0052 0015 fffd fffd 0000 0056 0041 fffd 0008 002f 0050 0015 fffd 0061 0019 fffd fffd 005b 0074 fffd b8e0 fffd fffd fffd 00
6a fffd 005f 000e fffd

More device control

Production scenario:

  • Many tuya devices (20+), each device uses a node-red-contrib-tuya-smart-device.
  • Some devices are permanently in use (thermometer sensor, fire alarm, door sensors, etc.).
  • Others are in use only for short periods (power strip, humidifier, TV ... etc.) mainly because they are turned off.

The problem

  • Too many connection retries, too many debug pad messages, too many resources used.
  • The node-red 'disable' node feature works, but need a 'Deploy'. Not a solution at run-time.
  • see ISUUE# 35
  • The support-timeout ISSUE#41 is a good help (thanks vinodsr), but it is static, i.e. cannot be changed at run-time.
    It is better to have a fast (2-10 s) timeout when the device is working (to reconnect it soon in case of any problem) and a very slow (60-600 s) timeout when the device is OFF (so we polling it, and auto-reconnect when turned on).

The proposed solution

  1. A new command findTimeout, to set dynamically the findTimeout, in millisecond.
    Syntax: msg ={"findTimeout": 10000}.
    It can be sent alone or with standard SET/GET/MULTIPLE/SCHEMA commands.

Example: look at IR #1, default timeout 10 s.

21 Apr 12:31:08 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
21 Apr 12:31:08 - [info] [tuya-smart-device:Smart IR #3] initiating the find command
21 Apr 12:31:08 - [info] [tuya-smart-device:BLE MESH（SIG）Gateway] initiating the find command
21 Apr 12:31:08 - [info] [tuya-smart-device:power strip] initiating the find command
21 Apr 12:31:08 - [info] [tuya-smart-device:meter] initiating the find command
21 Apr 12:31:10 - [info] [tuya-smart-device:meter] Connected to device! 4864416*****
21 Apr 12:31:11 - [info] [tuya-smart-device:power strip] Connected to device! 36136661*****
21 Apr 12:31:13 - [info] [tuya-smart-device:BLE MESH（SIG）Gateway] Connected to device! bf0b2ef30ff*****
*21 Apr 12:31:18 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
21 Apr 12:31:18 - [info] [tuya-smart-device:Smart IR #3] Cannot find the device, re-trying...
21 Apr 12:31:28 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
*21 Apr 12:31:48 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
21 Apr 12:32:07 - [info] [tuya-smart-device:BLE MESH（SIG）Gateway] Disconnected from tuyaDevice.
......  // IR #1: default every 10+10s:
21 Apr 12:33:49 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
*21 Apr 12:33:59 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
21 Apr 12:34:09 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
*21 Apr 12:34:19 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
21 Apr 12:34:29 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
*21 Apr 12:34:39 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
21 Apr 12:34:49 - [info] [tuya-smart-device:Smart IR #3] initiating the find command
21 Apr 12:34:49 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
21 Apr 12:34:54 - [info] [tuya-smart-device:meter] Data from device  [event:dp-refresh]: {"devId":"486441603c*****","dps":{"18":58},"t":1619001294}
...... // slow findTimeout. 40+10
21 Apr 12:37:30 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
21 Apr 12:37:40 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
==> 21 Apr 12:37:48 - [info] [tuya-smart-device:Smart IR #1] Updated findTimeout. New value:40000    
21 Apr 12:37:50 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
*21 Apr 12:38:00 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
21 Apr 12:38:14 - [info] [tuya-smart-device:meter] Data from device  [event:dp-refresh]: {"devId":"486441603c*****","dps":{"20":2306},"t":1619001494}
21 Apr 12:38:29 - [info] [tuya-smart-device:Smart IR #3] initiating the find command
21 Apr 12:38:39 - [info] [tuya-smart-device:Smart IR #3] Cannot find the device, re-trying...
21 Apr 12:38:40 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
*21 Apr 12:38:50 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
21 Apr 12:39:12 - [info] [tuya-smart-device:meter] Data from device  [event:dp-refresh]: {"devId":"486441603c*****","dps":{"20":2317},"t":1619001552}
21 Apr 12:39:41 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
*21 Apr 12:39:51 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
21 Apr 12:40:19 - [info] [tuya-smart-device:Smart IR #3] initiating the find command
21 Apr 12:40:29 - [info] [tuya-smart-device:Smart IR #3] Cannot find the device, re-trying...
21 Apr 12:40:31 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
*21 Apr 12:40:41 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
.........  // fast findTimeout. 5+10
21 Apr 12:43:11 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
==> 21 Apr 12:43:22 - [info] [tuya-smart-device:Smart IR #1] Updated findTimeout. New value:5000
21 Apr 12:43:51 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
21 Apr 12:43:59 - [info] [tuya-smart-device:Smart IR #3] initiating the find command
21 Apr 12:43:59 - [info] [tuya-smart-device:smart umidifier] initiating the find command
*21 Apr 12:44:01 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
21 Apr 12:44:06 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
21 Apr 12:44:09 - [info] [tuya-smart-device:Smart IR #3] Cannot find the device, re-trying...
*21 Apr 12:44:16 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
21 Apr 12:44:21 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
*21 Apr 12:44:31 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
21 Apr 12:44:36 - [info] [tuya-smart-device:Smart IR #1] initiating the find command

Here the code used: tuya-smart-device.js, line 43

    node.on('input', function (msg) {

            if ((msg.findTimeout !== undefined) &&
            (!isNaN(msg.findTimeout)) &&
            (msg.findTimeout > 0)){
                node.findTimeout = ~~msg.findTimeout;
                node.log("Updated findTimeout. New value:" + node.findTimeout);
        }
  1. A new command standby, to hibernate the device. It is not an alternative to findTimeout,. It uses a user command to set in a 'suspended' state the device, with a good saving of resources.
    Syntax: msg ={"standby": true|false}.
    It can be sent alone or with standard SET/GET/MULTIPLE/SCHEMA commands.

Example: look at IR #1, default timeout 10+10 s.

21 Apr 13:16:55 - [info] [tuya-smart-device:meter] Connected to device! 486441603c61*****
21 Apr 13:16:56 - [info] [tuya-smart-device:power strip] Connected to device! 3613666124a*****
*21 Apr 13:17:04 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
21 Apr 13:17:04 - [info] [tuya-smart-device:Smart IR #3] Cannot find the device, re-trying...
21 Apr 13:17:14 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
*21 Apr 13:17:24 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
21 Apr 13:17:34 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
==>21 Apr 13:17:44 - [info] [tuya-smart-device:Smart IR #1] not retrying the find as shouldTryReconnect = false
21 Apr 13:18:44 - [info] [tuya-smart-device:Smart IR #3] initiating the find command
21 Apr 13:18:54 - [info] [tuya-smart-device:Smart IR #3] Cannot find the device, re-trying...
21 Apr 13:20:34 - [info] [tuya-smart-device:Smart IR #3] initiating the find command
21 Apr 13:20:44 - [info] [tuya-smart-device:Smart IR #3] Cannot find the device, re-trying...
21 Apr 13:20:44 - [info] [tuya-smart-device:smart umidifier] Cannot find the device, re-trying...
==> 21 Apr 13:21:01 - [info] [tuya-smart-device:Smart IR #1] End standby: re-trying...
21 Apr 13:21:11 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
*21 Apr 13:21:21 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
21 Apr 13:21:31 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
*21 Apr 13:21:50 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
21 Apr 13:22:00 - [info] [tuya-smart-device:Smart IR #1] initiating the find command
*21 Apr 13:22:10 - [info] [tuya-smart-device:Smart IR #1] Cannot find the device, re-trying...
21 Apr 13:22:20 - [info] [tuya-smart-device:Smart IR #1] initiating the find command

Here the code used: tuya-smart-device.js, after the 'findTimeout ' code:

             if ((msg.standby !== undefined) &&
            (typeof msg.standby === 'boolean')) {
            shouldTryReconnect = !msg.standby;
            if (tuyaDevice.isConnected()){
               if ( msg.standby){
                    tuyaDevice.disconnect();
                    node.log("Received standby: disconnecting...");
                    clearTimeout(findTimeoutHandler);
                    }
            } else {
               if (!msg.standby){
                   node.log("End standby: re-trying...");
                   findTimeoutHandler = setTimeout(findDevice, node.findTimeout);
                   }
            }
      }
// a test is  required around the old operation code:

   if (msg.payload !== undefined) {
             let operation = msg.payload.operation || 'SET';
             .....
            }

(updated: now standby, if the device is connected, does disconnect() )

The proposed enhancements are backward compatible with ver 4.0.1

I'm using this code on my project, for now without problems.

Best regards
m.s.

json obj data invalid

Hello,

The ID and key seem to be correct as the node displays "connected" underneath.

But I did not send anything through it, debug already says "json obj data invalid" with a msg: Object listing dps 1, 2, 3, 101, 102, 103 as null.

Flow with multiple devices will sometimes report "Cannot call write after a stream was destroyed" after re-deploy

Hi,
first of all thank you for that awesome extension of node-red. Works quite well so far!

Sometimes I get an error Error from socket: Cannot call write after a stream was destroyed after I re-deploy my flow for some nodes that use the tuya-smart-device node. Mostly it is the same node. The only solution to fix the problem is restarting node-red. Otherwise the error will continue to be thrown.

Does anyone has an idea why that happens?

I've configured all nodes to use Device Virtual ID and Device Key.

Best,
Jakob

Howto pass strings to DPS keys ?

Guys,

I have a heat pump that is controlled by Tuya. I have successfully extracted the keys and have control of it for basic functions such as ON/OFF

However some of the DPS keys require text to be sent to them DPS 2 for instance supports the following commands

silence
turbo
smart

I can not for the life of me work out what syntax to use in a node to pass this across to the system

ANy ideas ??

Craig

version 2.0.0 Error messages

I'm updated to 2.0.0, thanks, very good.
I set

  options.nullPayloadOnJSONError = false
  options.issueGetOnConnect = false

Thanks.

Now I have still a big problem: tuya-smart-device don't catch 2 errors from tuyapi, in case of device disconnection:

4 Jan 14:10:33 - [info] [tuya-smart-device:5a17a058.f17be] Cannot find the device, re-trying...
4 Jan 14:10:34 - [info] [tuya-smart-device:5a17a058.f17be] initiating the find command
4 Jan 14:10:44 - [error] [tuya-smart-device:5a17a058.f17be] Error: find() timed out. Is the device powered on and the ID or IP correct?
4 Jan 14:10:44 - [info] [tuya-smart-device:5a17a058.f17be] Cannot find the device, re-trying...
4 Jan 14:10:45 - [info] [tuya-smart-device:5a17a058.f17be] initiating the find command
4 Jan 14:10:55 - [error] [tuya-smart-device:5a17a058.f17be] Error: find() timed out. Is the device powered on and the ID or IP correct?
4 Jan 14:10:55 - [info] [tuya-smart-device:5a17a058.f17be] Cannot find the device, re-trying...
4 Jan 14:10:56 - [info] [tuya-smart-device:5a17a058.f17be] initiating the find command
4 Jan 14:10:59 - [info] [tuya-smart-device:5a17a058.f17be] Connected to device! 123301602cf4325eae00

and same for the error message: "Error: Error from socket"

As you can see the timeout is about 10s. The unique solution is to disable the device, but it is not a solution, because in normal use some devices can stay a disconnected long time, such as some power sockets or power strips used only on request.
Some like this:

24 Jan 14:10:33 - [info] [tuya-smart-device:5a17a058.f17be] Cannot find the device, re-trying after XXX sec...

So, after study how to catch this tuyapi error (the INFO existing messages are enough) a VERY useful extension will be the ability to change at runtime the timeout (or adding a delay between tries).
A very long timeout is equivalent to a 'disable', and the user will be able to restart when required.
Maybe an extra parameter on the input message? or a unique parameter into a special msg? Get the simplest way.

Dynamic timeout will be VERY appreciated, making tuya-smart-device better!

Best regards
m.s.

Getting a cryptic output from Device

Sorry, I'm a bit new to this but I've double checked, that every value is correct (IP, Key, ID)

I'm getting this output when I'm setting the switch to off/on via the Tuya App.

I'm using Gosund Devices SP211 (I think.)

grafik

IP Camera Motion detection - "json obj data unvalid"

Hi,

first of all I would like to thank you for this cool project.

I am using a tuya IP camera and would like to trigger an event if motion is deteced.

Unfortunately I also have the problem that the device returns "json obj data unvalid" if I try to get the schema.

Is there a another way to get the list of dps or an event?

image

Need more optimised code

The logic has to be more optimised for the single node and multi node features. Currently there is lot of code duplication.

Litemate 9 W Wifi LED Lamp - Error: find() timed out

I get an error when using the node. (I changed the device ID before posting) The node initially shows connected with the below msg.payload:

{"data":{"devId":"26701815d8bfc0eeXXX","dps":{"20":true,"21":"white","22":1000,"23":520,"24":"003a03e803e8","25":"07464602000003e803e800000000464602007803e803e80000000046460200f003e803e800000000464602003d03e803e80000000046460200ae03e803e800000000464602011303e803e800000000","26":0}},"deviceId":"26701815d8bfc0eeXXXX","deviceName":"Bulb"}

But then after a few seconds it shows this error and the it disconnects:

10/24/2020, 9:56:18 AM295487d4.17f058
msg : error
"Error: find() timed out. Is the device powered on and the ID or IP correct?"

I did test with a Connex Wifi Bulb and it works.

Light bulb color control

I managed to start up the bulb using localkey and dps changed to 20 based on the flow1.js example

are there any examples to change to white/color, and select color for the bulb?
See documentation link is only stated in a picture.

thanks

4.1.0 issues

I found a grave problem testing the ver. 4.1.0, setting the device ON/OFF: the transition OFF => ON is OK, but the transition ON => OFF generates any time a "Unhandled promise " error that requires node-red restart.

Trace case OFF => ON, runs OK

I tested it 'in the project', where it is implemented a 'dynamic timeout'. Don't care about it.

2 Jun 20:36:11 - [info] Node-RED version: v1.2.6
2 Jun 20:36:11 - [info] Node.js  version: v14.15.1
2 Jun 20:36:11 - [info] Windows_NT 10.0.18363 x64 LE
..... omissis
//--------------- note: this info still too many data
2 Jun 20:36:15 - [info] [tuya-smart-device:WiFi plug] Recieved the config {"id":"cb0e33e6.f0a6b","type":"tuya-smart-device","z":"173260fb.d021ff","deviceName":"WiFi plug","deviceId":"bf94066e80b*******","deviceKey":"ddfd532e9*******","deviceIp":"","retryTimeout":"100003","findTimeout":"100019","tuyaVersion":"3.1","eventMode":"event-both","x":1180,"y":700,"wires":[["2ec83963.a7d146","3396211c.9a5dee"],["35577170.232cde","572ec9e9.c41048"]],"info":"CUSTOMIZATION\n\n  - duplicate for any new device\n  - set proprties: deviceId (or IP), key, retry timeout (1000 ms), find timeout (5000 ms).","disableAutoStart":false}

2 Jun 20:36:15 - [info] [tuya-smart-device:WiFi plug] Event subscription : shouldSubscribeData=>true , shouldSubscribeRefreshData=>true
2 Jun 20:36:15 - [info] [tuya-smart-device:WiFi plug] Auto start probe on connect...
2 Jun 20:36:15 - [info] [tuya-smart-device:WiFi plug] Cleaning up the state
2 Jun 20:36:15 - [info] [tuya-smart-device:WiFi plug] Clearing the find timeout handler

// ===============  Wifi Plug is OFF
2 Jun 20:36:16 - [info] [tuya-smart-device:WiFi plug] Connecting to Tuya with params {"id":"bf94066e80ba*******","key":"ddfd532e99*******","ip":"","issueGetOnConnect":false,"nullPayloadOnJSONError":false,"version":"3.1"} , findTimeout :  100019 , retryTimeout:  100003

//  ==============  dynamic findTimeout: every  failed  re-trying, the  find timeout grows (random): min 2s, max 60s
2 Jun 20:36:16 - [info] [tuya-smart-device:WiFi plug] Initiating the find command
2 Jun 20:36:16 - [info] [tuya-smart-device:WiFi plug] Recieved input : {"toDev":"bf94066e80ba0*******","payload":{"operation":"CONTROL","action":"SET_FIND_TIMEOUT","value":1382},"_msgid":"d9e5ec31.7424c"}
2 Jun 20:36:16 - [info] [tuya-smart-device:WiFi plug] Setting new find timeout :1382

2 Jun 20:36:26 - [info] [tuya-smart-device:WiFi plug] Cannot find the device, re-trying...
2 Jun 20:36:27 - [info] [tuya-smart-device:WiFi plug] Initiating the find command
2 Jun 20:36:27 - [info] [tuya-smart-device:WiFi plug] Recieved input : {"toDev":"bf94066e80ba0*******","payload":{"operation":"CONTROL","action":"SET_FIND_TIMEOUT","value":1383},"_msgid":"dabd6913.ba3c98"}
2 Jun 20:36:27 - [info] [tuya-smart-device:WiFi plug] Setting new find timeout :1383

2 Jun 20:36:37 - [info] [tuya-smart-device:WiFi plug] Cannot find the device, re-trying...
2 Jun 20:36:39 - [info] [tuya-smart-device:WiFi plug] Initiating the find command
2 Jun 20:36:39 - [info] [tuya-smart-device:WiFi plug] Recieved input : {"toDev":"bf94066e80ba0*******","payload":{"operation":"CONTROL","action":"SET_FIND_TIMEOUT","value":1509},"_msgid":"54aa03b5.fbba4c"}
2 Jun 20:36:39 - [info] [tuya-smart-device:WiFi plug] Setting new find timeout :1509

2 Jun 20:36:49 - [info] [tuya-smart-device:WiFi plug] Cannot find the device, re-trying...
2 Jun 20:36:50 - [info] [tuya-smart-device:WiFi plug] Initiating the find command
2 Jun 20:36:50 - [info] [tuya-smart-device:WiFi plug] Recieved input : {"toDev":"bf94066e80ba060*******","payload":{"operation":"CONTROL","action":"SET_FIND_TIMEOUT","value":1581},"_msgid":"1d396d62.c551a3"}
2 Jun 20:36:50 - [info] [tuya-smart-device:WiFi plug] Setting new find timeout :1581

2 Jun 20:37:00 - [info] [tuya-smart-device:WiFi plug] Cannot find the device, re-trying...
2 Jun 20:37:02 - [info] [tuya-smart-device:WiFi plug] Initiating the find command
2 Jun 20:37:02 - [info] [tuya-smart-device:WiFi plug] Recieved input : {"toDev":"bf94066e80ba0*******","payload":{"operation":"CONTROL","action":"SET_FIND_TIMEOUT","value":1752},"_msgid":"7b8143d8.cd795c"}
2 Jun 20:37:02 - [info] [tuya-smart-device:WiFi plug] Setting new find timeout :1752

2 Jun 20:37:12 - [info] [tuya-smart-device:WiFi plug] Cannot find the device, re-trying...
2 Jun 20:37:14 - [info] [tuya-smart-device:WiFi plug] Initiating the find command
2 Jun 20:37:14 - [info] [tuya-smart-device:WiFi plug] Recieved input : {"toDev":"bf94066e80ba060*******","payload":{"operation":"CONTROL","action":"SET_FIND_TIMEOUT","value":2150},"_msgid":"daf869b9.51f598"}
2 Jun 20:37:14 - [info] [tuya-smart-device:WiFi plug] Setting new find timeout :2150

2 Jun 20:37:24 - [info] [tuya-smart-device:WiFi plug] Cannot find the device, re-trying...
2 Jun 20:37:26 - [info] [tuya-smart-device:WiFi plug] Initiating the find command
2 Jun 20:37:26 - [info] [tuya-smart-device:WiFi plug] Recieved input : {"toDev":"bf94066e80ba0*******","payload":{"operation":"CONTROL","action":"SET_FIND_TIMEOUT","value":2364},"_msgid":"d75eb566.8364d8"}
2 Jun 20:37:26 - [info] [tuya-smart-device:WiFi plug] Setting new find timeout :2364

2 Jun 20:37:36 - [info] [tuya-smart-device:WiFi plug] Cannot find the device, re-trying...
2 Jun 20:37:38 - [info] [tuya-smart-device:WiFi plug] Initiating the find command
2 Jun 20:37:38 - [info] [tuya-smart-device:WiFi plug] Recieved input : {"toDev":"bf94066e80ba060*******","payload":{"operation":"CONTROL","action":"SET_FIND_TIMEOUT","value":3092},"_msgid":"be7a2d8.50048d"}
2 Jun 20:37:38 - [info] [tuya-smart-device:WiFi plug] Setting new find timeout :3092
..... omissis

// =============== WiFi plug ON at 20:44:50 (via power strip)
2 Jun 20:44:50 - [info] [tuya-smart-device:power strip] Data from device  [event:data]: {"devId":"3613666124a*******","dps":{"1":true,"2":true,"3":true,"4":true,"5":true},"t":1622659489}
2 Jun 20:45:06 - [info] [tuya-smart-device:WiFi plug] Initiating the find command
2 Jun 20:45:06 - [info] [tuya-smart-device:WiFi plug] Recieved input : {"toDev":"bf94066e80ba0*******","payload":{"operation":"CONTROL","action":"SET_FIND_TIMEOUT","value":67377},"_msgid":"ae11a06a.06fa1"}
2 Jun 20:45:06 - [info] [tuya-smart-device:WiFi plug] Setting new find timeout :67377

// ======= connected, so find timeout back to min: 2000
2 Jun 20:45:11 - [info] [tuya-smart-device:WiFi plug] Connected to device! bf94066e80ba0*******i
2 Jun 20:45:11 - [info] [tuya-smart-device:WiFi plug] Recieved input : {"toDev":"bf94066e80ba0*******","payload":{"operation":"CONTROL","action":"SET_FIND_TIMEOUT","value":2000},"_msgid":"416b6595.f2823c"}
2 Jun 20:45:11 - [info] [tuya-smart-device:WiFi plug] Setting new find timeout :2000
..... omissis

Trace case ON => OFF, fatal error

2 Jun 21:07:40 - [info] Node-RED version: v1.2.6
..... omissis
2 Jun 21:07:44 - [info] [tuya-smart-device:WiFi plug] Recieved the config {"id":"cb0e33e6.f0a6b","type":"tuya-smart-device","z":"173260fb.d021ff","deviceName":"WiFi plug","deviceId":"bf94066e80ba0*******","deviceKey":"ddfd532e9*******","deviceIp":"","retryTimeout":"100003","findTimeout":"100019","tuyaVersion":"3.1","eventMode":"event-both","x":1180,"y":700,"wires":[["2ec83963.a7d146","3396211c.9a5dee"],["35577170.232cde","572ec9e9.c41048"]],"info":"CUSTOMIZATION\n\n  - duplicate for any new device\n  - set proprties: deviceId (or IP), key, retry timeout (1000 ms), find timeout (5000 ms).","disableAutoStart":false}
2 Jun 21:07:44 - [info] [tuya-smart-device:WiFi plug] Event subscription : shouldSubscribeData=>true , shouldSubscribeRefreshData=>true
2 Jun 21:07:44 - [info] [tuya-smart-device:WiFi plug] Auto start probe on connect...
2 Jun 21:07:44 - [info] [tuya-smart-device:WiFi plug] Cleaning up the state
2 Jun 21:07:44 - [info] [tuya-smart-device:WiFi plug] Clearing the find timeout handler
..... omissis
2 Jun 21:07:45 - [info] [tuya-smart-device:WiFi plug] Connecting to Tuya with params {"id":"bf94066e80ba060a04vmxi","key":"ddfd532e9962d0a8","ip":"","issueGetOnConnect":false,"nullPayloadOnJSONError":false,"version":"3.1"} , findTimeout :  100019 , retryTimeout:  100003
2 Jun 21:07:45 - [info] [tuya-smart-device:WiFi plug] Initiating the find command
2 Jun 21:07:45 - [info] [tuya-smart-device:WiFi plug] Recieved input : {"toDev":"bf94066e80ba*******","payload":{"operation":"CONTROL","action":"SET_FIND_TIMEOUT","value":1380},"_msgid":"f3c13e33.9b875"}
2 Jun 21:07:45 - [info] [tuya-smart-device:WiFi plug] Setting new find timeout :1380
..... omissis
2 Jun 21:07:50 - [info] [tuya-smart-device:WiFi plug] Recieved input : {"toDev":"bf94066e80ba0*******","payload":{"operation":"CONTROL","action":"SET_FIND_TIMEOUT","value":1439},"_msgid":"577b10ae.d6573"}
2 Jun 21:07:50 - [info] [tuya-smart-device:WiFi plug] Setting new find timeout :1439
2 Jun 21:07:51 - [info] [tuya-smart-device:WiFi plug] Connected to device! bf94066e80ba*******
..... omissis

// =============== WiFi plug OFF at 21:12:13 (via power strip)
2 Jun 21:12:13 - [info] [tuya-smart-device:power strip] Data from device  [event:data]: {"devId":"3613666124a1600db127","dps":{"1":false,"2":false,"3":false,"4":false,"5":false},"t":1622661132}
2 Jun 21:12:23 - [info] [tuya-smart-device:WiFi plug] Disconnected from tuyaDevice.

2 Jun 21:14:03 - [info] [tuya-smart-device:WiFi plug] Recieved input : {"toDev":"bf94066e80ba0*******","payload":{"operation":"CONTROL","action":"SET_FIND_TIMEOUT","value":1630},"_msgid":"4f618be1.8e3f84"}
2 Jun 21:14:03 - [info] [tuya-smart-device:WiFi plug] Setting new find timeout :1630

(node:16444) UnhandledPromiseRejectionWarning: Error: connection timed out
    at Socket.<anonymous> (d:\node-red\flow-1984\node_modules\tuyapi\index.js:446:18)
    at Object.onceWrapper (events.js:421:28)
    at Socket.emit (events.js:315:20)
    at Socket._onTimeout (net.js:483:8)
    at listOnTimeout (internal/timers.js:554:17)
    at processTimers (internal/timers.js:497:7)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:16444) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:16444) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

// ============ WiFi plug:  no re-trying...
// =============== WiFi plug ON at 21:26:09 (via power strip)
2 Jun 21:26:09 - [info] [tuya-smart-device:power strip] Data from device  [event:data]: {"devId":"3613666124a160*******","dps":{"1":true,"2":true,"3":true,"4":true,"5":true},"t":1622661968}
// ======== WiFi plug dead, requires node-red restart

A question about timeouts

What is the mind of retryTimeout? It is used only on data RX?

..... omissis
2 Jun 21:51:22 - [info] [tuya-smart-device:WiFi plug] Connecting to Tuya with params {"id":"bf94066e80ba0*******","key":"ddfd532e99*******","ip":"","issueGetOnConnect":false,"nullPayloadOnJSONError":false,"version":"3.1"} , findTimeout :  2000 , retryTimeout:  2000
2 Jun 21:51:22 - [info] [tuya-smart-device:WiFi plug] Initiating the find command
..... omissis
// ===== using: findTimeout :  2000 , retryTimeout:  2000 I get  2s and 10s delays
2 Jun 21:51:32 - [info] [tuya-smart-device:WiFi plug] Cannot find the device, re-trying...
2 Jun 21:51:34 - [info] [tuya-smart-device:WiFi plug] Initiating the find command
2 Jun 21:51:44 - [info] [tuya-smart-device:WiFi plug] Cannot find the device, re-trying...
2 Jun 21:51:46 - [info] [tuya-smart-device:WiFi plug] Initiating the find command
2 Jun 21:51:56 - [info] [tuya-smart-device:WiFi plug] Cannot find the device, re-trying...
2 Jun 21:51:58 - [info] [tuya-smart-device:WiFi plug] Initiating the find command
..... omissis
2 Jun 21:59:04 - [info] [tuya-smart-device:WiFi plug] Connecting to Tuya with params {"id":"bf94066e80ba*******","key":"ddfd532e99*******","ip":"","issueGetOnConnect":false,"nullPayloadOnJSONError":false,"version":"3.1"} , findTimeout :  3000 , retryTimeout:  5000
..... omissis
// ===== using: findTimeout :  3000 , retryTimeout:  5000 I get  3s and still 10s delays
2 Jun 21:59:27 - [info] [tuya-smart-device:WiFi plug] Cannot find the device, re-trying...
2 Jun 21:59:30 - [info] [tuya-smart-device:WiFi plug] Initiating the find command
2 Jun 21:59:40 - [info] [tuya-smart-device:WiFi plug] Cannot find the device, re-trying...
2 Jun 21:59:43 - [info] [tuya-smart-device:WiFi plug] Initiating the find command
2 Jun 21:59:53 - [info] [tuya-smart-device:WiFi plug] Cannot find the device, re-trying...

So I use only findTimeout to control the connection retry period.

note on COMMAND implementation.
The chosen implementation works good, but presents some drawback that reduces the bandwidth:

  • Requires separate msg for every command, because it can only handle one COMMAND at a time.
  • Requires separate msg for DATA and COMMANDS, because it can't handle SET/GET and COMMAND at a time.
  • Is verbose

I found also in output some problems: e.g. the 'CONNECTED' state is repeated several times in vain, I had to add a filter.

Best regards
m.s.

Error not catched by CATCH node

The catch node fails to catch the error, for example "Error: Error from socket". I would like to request that node.error is called with a 2nd parameter to permit the catch node to catch errors it raises.

The rationale behind. When tuya-smart-device cannot connect to tuya bulb it generate error and report it to debug window. But when the bulb swith is off then it is normal situation and there is need to handle that programatically. For example catch error from the node and decide not to display in debug.

Feature request: ability to inject device properties

First of all - thank you for great job! This node works flawlessly, and quicker, than all other ways.

Would be great to have possibility to inject device ID, name and local key via incoming message parameters. For sure, it would make updates auto-receiving impossible, but maybe, you could create one more node, some "generic SET".

I got around 20 devices, and generic set command would speed up tuning drastically.

Thank you.

TypeError: ID and IP are missing from device

I'm using the generic node to pass on the device details via parameters however I keep getting this message
TypeError: ID and IP are missing from device

image

Am I doing anything silly?

Example: how to use REFRESH

The new tuyapi REFRESH operation (see issue54) can be easily handled with the following flow:

[{"id":"293b07da.95ad08","type":"tab","label":"Flow 1","disabled":false,"info":""},{"id":"c30a6be5.9fdf78","type":"inject","z":"293b07da.95ad08","name":"SET FAST","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"dps\":\"_fast\",\"set\":true}","payloadType":"json","x":140,"y":80,"wires":[["eccbc7b6.1ffa78"]]},{"id":"62a20a49.6f81b4","type":"inject","z":"293b07da.95ad08","name":"SET SLOW","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"dps\":\"_fast\",\"set\":false}","payloadType":"json","x":150,"y":120,"wires":[["eccbc7b6.1ffa78"]]},{"id":"1f720d7e.950623","type":"inject","z":"293b07da.95ad08","name":"GET","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"operation\":\"GET\",\"dps\":\"_fast\"}","payloadType":"json","x":130,"y":160,"wires":[["eccbc7b6.1ffa78"]]},{"id":"ef226712.feeda8","type":"tuya-smart-device","z":"293b07da.95ad08","deviceName":"meter","deviceId":"486441603c6105*****","deviceKey":"84bb4******","deviceIp":"","retryTimeout":"2279","findTimeout":"6291","tuyaVersion":"3.3","x":750,"y":200,"wires":[["63a04dbd.11fc44"]]},{"id":"eccbc7b6.1ffa78","type":"function","z":"293b07da.95ad08","name":"fast control","func":"\nconst FASTDP = \"_fast\";\n// same values as tuya device node\nconst DEVID = \"486441603c6105*****\";\nconst DEVNAME = \"meter\";\n\n// builds the output message\nvar newMsg = {\n    \"payload\": {\n        \"deviceId\": DEVID,\n        \"deviceName\": DEVNAME, // as device node\n        \"data\": {\n            \"dps\": {}\n        }\n    }\n};\n//  SET/GET case\nif (msg.payload.dps === FASTDP) {\n    if (msg.payload.set !== undefined) { // is set\n        context.set(\"fast\", msg.payload.set);\n        newMsg.payload.data.dps[FASTDP] = msg.payload.set;\n        if (msg.payload.set) {\n            return ([{ payload: { operation: \"RFR\" } }, null, newMsg]);\n        } else {\n            return ([{ payload: \"stop\" }, null, newMsg]);\n        }\n    } else { // is get\n        newMsg.payload.data.dps[FASTDP] = context.get(\"fast\");\n        return ([null, null, newMsg]);\n    }\n}\n// MULTIPLE case\nif ((msg.payload.data !== undefined) && (msg.payload.data[FASTDP] !== undefined)) {\n    let fst = msg.payload.data[FASTDP];\n    delete msg.payload.data[FASTDP];\n    context.set(\"fast\", fst);\n    newMsg.payload.data.dps[FASTDP] = fst;\n    if (fst) {\n        return ([{ payload: { operation: \"RFR\" }}, msg, newMsg]);\n    } else {\n        return ([{ payload: \"stop\" }, msg, newMsg]);\n    }\n}\n// SCHEMA case\nif (msg.payload.schema !== undefined) {\n    newMsg.payload.data.dps[FASTDP] = context.get(\"fast\");\n    return ([null, msg, newMsg]);\n}\n\nreturn [null, msg];\n","outputs":3,"noerr":0,"initialize":"// Code added here will be run once\n// whenever the node is deployed.\ncontext.set(\"fast\",0);","finalize":"","x":430,"y":220,"wires":[["3b402872.17d208"],["ef226712.feeda8"],["63a04dbd.11fc44"]]},{"id":"3b402872.17d208","type":"looptimer2","z":"293b07da.95ad08","duration":"6","units":"Second","maxloops":"20","maxtimeout":"3","maxtimeoutunits":"Minute","name":"fast rate","x":600,"y":180,"wires":[["ef226712.feeda8"],[]]},{"id":"c29a682a.613dd8","type":"inject","z":"293b07da.95ad08","name":"MULTIPLE FAST","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"multiple\":true,\"data\":{\"1\":true,\"_fast\":true}}","payloadType":"json","x":160,"y":200,"wires":[["eccbc7b6.1ffa78"]]},{"id":"7f00b50e.36125c","type":"inject","z":"293b07da.95ad08","name":"SCHEMA","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"operation\":\"GET\", \"schema\":true}","payloadType":"json","x":140,"y":280,"wires":[["eccbc7b6.1ffa78"]]},{"id":"63a04dbd.11fc44","type":"debug","z":"293b07da.95ad08","name":"TEST","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":890,"y":240,"wires":[]},{"id":"aee9fe1a.db9fb","type":"inject","z":"293b07da.95ad08","name":"MULTIPLE SLOW","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"multiple\":true,\"data\":{\"1\":true,\"_fast\":false}}","payloadType":"json","x":170,"y":240,"wires":[["eccbc7b6.1ffa78"]]}]

Works with 4.0.1 modified.
This flow adds a new DP to a device (e.g. the '_fast' dp, but you can change this) with values false|true. In FAST mode, the node 'fast rate' defines the sampling rate (e.g. smartLife uses 5 sec.) and the max. FAST mode duration.
The new '_fast' DP is compatible with SET/GET/MULTIPLE/SCHEMA commands.

Best regards
m.s.
refresh02

Control Bulbs or get what commands i can use ?

Hi i have use this contrib rlly amazing but i only can TURN OFF AND ON bulb...

I don't understand the "DPS" part

My bulb information show this:
imagen

Where i can see what its DPS and WHY dps ? -.- idk how to change color or other thing.

Issue connecting to Tuya light under 4.1.1

I'm consistently getting the following error:

find() timed out. Is the device powered on and the ID or IP correct?

Here are the steps I followed:

I retrieved all of the keys using tuya-cli wizard:

root@ha:/var/log# tuya-cli wizard
? Do you want to use these saved API credentials? xxxxxxxxxxxxxxxxxxxx yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy us Yes
? Provide a 'virtual ID' of a device currently registered in the app: 805..............aad
[ { name: 'Light #7',
    id: '805..............aad',
    key: '9cb..........57a' },
			:
			:
			:
  { name: 'Light #1',
    id: '....................',
    key: '................' } ]

I then deployed a tuya - smart - device node and filled in:

Device Name: Light #7
Device Virutal ID: 805..............aad
Device IP (Static):
Device Key: 9cb..........57a

I deploy it and the node cycles between connecting and Can't find device.

I have verified these values in the Tuya IoT Platform; the device id is definitely correct.

Any suggestions as to what might not be working?

json obj data unvalid

Hi, I'm trying to get the power, current and voltage data from a Tuya device. Following your example, the node workds perfectly to switch on/off the Tuya smart plug. When I try to use GET, I receive the error "json obj data unvalid".
I tried in node-red to write:
msg.payload ={
operation : "GET",
dsp: 19
}
return msg;

I tried also:
msg.payload ={
operation : "GET",
schema: true
}
return msg;

But I continue to get the same error with this answer from the device:
{"payload":{"data":{"dps":{"1":null,"2":null,"3":null,"101":null,"102":null,"103":null}},"deviceId":"[my deivce ID]","deviceName":"[My device name]"},"_msgid":"47701b1b.667bb4"}

Would you please help with some GET examples?

Thank you

can't connect with old protocol version and a fixup

hello,

i'm not so familiar with GIT. So i apologize to deliver some changes via this post.

I had a relatively new tuya based device, which requires protocol version [3.3]
Its not located in the same Subnet of my node red server.

To solve this problem i change the html and js file a bit.

  • html: i added IP Input and Version Input
  • Js: i changed the constructor to add IP and Version and do some checkup before

I'm not a JS crack.

i would be happy if you could add the extension to the code base. I think that makes it more valuable.
kind regards
Kai

NR crashes after Uncaught Exception (connection timed out)

Every time when the smart device is turned off or there is a problem with connection with device, Node-Red crashes with an error message.

Release 4.0.1:

kwi 15 20:19:11 DietPi node-red[23385]: 15 Apr 20:19:11 - [red] Uncaught Exception:
kwi 15 20:19:11 DietPi node-red[23385]: 15 Apr 20:19:11 - Error: connection timed out
kwi 15 20:19:11 DietPi node-red[23385]: at Socket.<anonymous> (/mnt/dietpi_userdata/node-red/node_modules/tuyapi/index.js:442:18)
kwi 15 20:19:11 DietPi node-red[23385]: at Object.onceWrapper (node:events:435:28)
kwi 15 20:19:11 DietPi node-red[23385]: at Socket.emit (node:events:329:20)
kwi 15 20:19:11 DietPi node-red[23385]: at Socket._onTimeout (node:net:470:8)
kwi 15 20:19:11 DietPi systemd[1]: node-red.service: Main process exited, code=exited, status=1/FAILURE
kwi 15 20:19:11 DietPi systemd[1]: node-red.service: Unit entered failed state.
kwi 15 20:19:11 DietPi systemd[1]: node-red.service: Failed with result 'exit-code'.

And previously for the version 3.1.0:

kwi 15 11:55:35 DietPi node-red[20850]: 15 Apr 11:55:35 - [red] Uncaught Exception:
kwi 15 11:55:35 DietPi node-red[20850]: 15 Apr 11:55:35 - Error: connection timed out
kwi 15 11:55:35 DietPi node-red[20850]:     at Socket.<anonymous> (/mnt/dietpi_userdata/node-red/node_modules/tuyapi/index.js:343:18)
kwi 15 11:55:35 DietPi node-red[20850]:     at Object.onceWrapper (node:events:435:28)
kwi 15 11:55:35 DietPi node-red[20850]:     at Socket.emit (node:events:329:20)
kwi 15 11:55:35 DietPi systemd[1]: node-red.service: Main process exited, code=exited, status=1/FAILURE
kwi 15 11:55:35 DietPi systemd[1]: node-red.service: Unit entered failed state.
kwi 15 11:55:35 DietPi systemd[1]: node-red.service: Failed with result 'exit-code'.

or

kwi 13 23:40:58 DietPi node-red[11340]: 13 Apr 23:40:58 - [info] [tuya-smart-device:xxx] Disconnected from tuyaDevice.
kwi 13 23:40:58 DietPi node-red[11340]: 13 Apr 23:40:58 - [error] [tuya-smart-device:xxx] Error: Error from socket
kwi 13 23:40:58 DietPi node-red[11340]: 13 Apr 23:40:58 - [red] Uncaught Exception:
kwi 13 23:40:58 DietPi node-red[11340]: 13 Apr 23:40:58 - Error: connect ECONNRESET 192.168.0.113:6668
kwi 13 23:40:58 DietPi node-red[11340]:     at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1128:16)
kwi 13 23:40:58 DietPi systemd[1]: node-red.service: Main process exited, code=exited, status=1/FAILURE
kwi 13 23:40:58 DietPi systemd[1]: node-red.service: Unit entered failed state.
kwi 13 23:40:58 DietPi systemd[1]: node-red.service: Failed with result 'exit-code'.

Node-Red v1.2.3.
Device model : NanoPi M1/T1 (armv7l), DietPi v7.0.2.
The device I connect to is a smart plug Gosund SP111.

Problem with ver. 4.0.1

Updated to ver. 4.0.1. I found a big problem, missed the output msg!
Example:
The simplest flow, using a Smart_Switch plus 2 nodes:

[{"id":"4c90f0fb.6e6d2","type":"tab","label":"extra.test","disabled":false,"info":""},{"id":"9aec7c62.dedc2","type":"debug","z":"4c90f0fb.6e6d2","name":"FROM SWITCH","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":320,"y":80,"wires":[]},{"id":"adcdaeb2.6e71f","type":"inject","z":"4c90f0fb.6e6d2","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"dps\":\"1\",\"set\":false}","payloadType":"json","x":130,"y":160,"wires":[["5ba5abff.f3fcb4"]]},{"id":"5ba5abff.f3fcb4","type":"tuya-smart-device","z":"4c90f0fb.6e6d2","deviceName":"switch module#1","deviceId":"bfa355aa196ae*******","deviceKey":"10ad2960ff******","deviceIp":"","retryTimeout":"4000","findTimeout":"4000","tuyaVersion":"3.1","x":110,"y":80,"wires":[["9aec7c62.dedc2"]]}]

The debug output:

  TuyAPI Pinging 192.168.1.16 +10s
  TuyAPI Received data: 000055aa00000000000000090000000c00000000b051ab030000aa55 +119ms
  TuyAPI Parsed: +2ms
  TuyAPI { payload: false, leftover: false, commandByte: 9, sequenceN: 0 } +3ms
  TuyAPI Pong from 192.168.1.16 +1ms
  express:router dispatching POST /inject/adcdaeb2.6e71f +2m
  express:router query  : /inject/adcdaeb2.6e71f +1ms
  express:router expressInit  : /inject/adcdaeb2.6e71f +3ms
  express:router mounted_app  : /inject/adcdaeb2.6e71f +1ms
  express:router dispatching POST /inject/adcdaeb2.6e71f +1ms
  express:router query  : /inject/adcdaeb2.6e71f +0ms
  express:router expressInit  : /inject/adcdaeb2.6e71f +1ms
  express:router corsMiddleware  : /inject/adcdaeb2.6e71f +1ms
  express:router jsonParser  : /inject/adcdaeb2.6e71f +1ms
  body-parser:json content-type undefined +2m
  body-parser:json skip parsing +0ms
  express:router urlencodedParser  : /inject/adcdaeb2.6e71f +2ms
  body-parser:urlencoded content-type undefined +1ms
  body-parser:urlencoded skip parsing +1ms
  express:router mounted_app  : /inject/adcdaeb2.6e71f +1ms
  express:router dispatching POST /inject/adcdaeb2.6e71f +5ms
  express:router query  : /inject/adcdaeb2.6e71f +0ms
  express:router expressInit  : /inject/adcdaeb2.6e71f +3ms
  express:router serveStatic  : /inject/adcdaeb2.6e71f +0ms
  express:router mounted_app  : /inject/adcdaeb2.6e71f +1ms
  express:router dispatching POST /inject/adcdaeb2.6e71f +0ms
  express:router query  : /inject/adcdaeb2.6e71f +1ms
  express:router expressInit  : /inject/adcdaeb2.6e71f +0ms
  express:router mounted_app  : /inject/adcdaeb2.6e71f +1ms
  express:router dispatching POST /inject/adcdaeb2.6e71f +0ms
  express:router query  : /inject/adcdaeb2.6e71f +1ms
  express:router expressInit  : /inject/adcdaeb2.6e71f +0ms
  TuyAPI SET Payload: +8s
  TuyAPI {
  TuyAPI   devId: 'bfa355aa196ae*******',
  TuyAPI   gwId: 'bfa355aa196ae*******',
  TuyAPI   uid: '',
  TuyAPI   t: 1618227689,
  TuyAPI   dps: { '1': false }
  TuyAPI } +4ms
  TuyAPI Received data: 000055aa00000021000000070000000c00000000167be2e10000aa55 +218ms
  TuyAPI Parsed: +1ms
  TuyAPI { payload: false, leftover: false, commandByte: 7, sequenceN: 33 } +1ms
  TuyAPI Got SET ack. +1ms
  TuyAPI Received data: 000055aa00000000000000080000004b00000000332e3300000000000000ac00000001f3fc6d8608d019e3d7c7e5022c16e184883cc6cbd441c8b209250a0222ae613e4ab9f738ccf13e1cc293961a60ddb6431b66f5220000aa55 +97ms
  TuyAPI Parsed: +0ms
  TuyAPI {
  TuyAPI   payload: { dps: { '1': false }, t: 1618227687 },
  TuyAPI   leftover: false,
  TuyAPI   commandByte: 8,
  TuyAPI   sequenceN: 0
  TuyAPI } +2ms
  TuyAPI Received DATA packet +1ms
  TuyAPI Pinging 192.168.1.16 +2s
  TuyAPI Received data: 000055aa00000000000000090000000c00000000b051ab030000aa55 +54ms
  TuyAPI Parsed: +2ms
  TuyAPI { payload: false, leftover: false, commandByte: 9, sequenceN: 0 } +2ms
  TuyAPI Pong from 192.168.1.16 +2ms
  engine:ws received "2" +19s
  engine:socket packet +19s
  engine:socket got ping +2ms
  engine:socket sending packet "pong" (undefined) +0ms
  engine:socket flushing buffer to transport +1ms
  engine:ws writing "3" +4ms`

The log shows data send and received by tuyapi, but nothing in output from node-red-contrib-tuya-smart-device !! Strange.

p.s.
Reinstalled ver. 3.0.2: all works well with all devices.

Best regards
m.s.

Nide is hanging often

Hi again!
I use your node for my smart home together with Hassio, to make bulbs and switches fast and local.
I noticed, that access to devices is hanging, and they become unresponsible time to time. I have to restart/redeploy to make them working.
Is there maybe a way to restart nodes without restarting node red, or redeploying flow?

Thank you in advance.

Example: add example to send multiple dps in single payload

I am trying to send multiple DPS in single payload. I tried following payload but it didn't work

{"multiple":true, "data": {"dps":{"20":true,"21":"white","22":1000,"23":44}}}

any idea what could be wrong. also if you can add example in your wiki for sending multiple dps that will be helpful to others.

Syntax Payload get command

Hi,
the installation is fin and I can switch on and off. But I can't execute the get Command. Can you help? perhaps with an example script? Thank you.

can't connect at all

first of all thanks for this awsome node-red plugin

Well i did insert the device id and key, retrieved from tuya-cli wizard

getting this error

"Error: find() timed out. Is the device powered on and the ID or IP correct?

regards

GET option

Hello,

How can I send GET option. I need to get power consumption.

SET option works fine

New Tuya API ... same as HA?

Hi, I'm using your current node but it is not detecting all devices

Can you use the same API functions as HA team ... the devices are getting detected perfectly

thx for considering

Feature: Instructions for getting the device id

  1. open: https://iot.tuya.com/index/ and LogIn
  2. -> Cloud
  3. -> API Explorer (https://iot.tuya.com/cloud/explorer)
  4. ->Data Center: Europe
  5. -> Get device details
  6. -> insert device_id
  7. -> submit request

"ta...da..."

the local_key!

{
  "result": {
    "active_time": ,
    "biz_type": ,
    "category": "",
    "create_time": ,
    "icon": "smart/icon/....jpg",
    "id": "",
    "ip": "",
    "lat": "",
->  "local_key": "xxxxxxxxx",
    "lon": "",
    "name": "",
    "online": true,
    "owner_id": "",
    "product_id": "",
    "product_name": "",
    "status": [],
    "sub": ,
    "time_zone": "",
    "uid": "",
    "update_time": ,
    "uuid": ""
  },
  "success": true,
  "t": 
}

datacenter
datacenter 2

Gruß
Matten Matten

Problems with 'GET' on all devices

I have 20+ Tuya devices, like switches, sensors, ad some ZigBee devices. All devices work well in smartLife app.
I'm testing node-red-contrib-tuya-smart.device to do some logging and more advanced control using node-red.
The node-red actual comportment is:

  1. All devices (except some sensors) accepts "SET" commands:

Example, using a real device, a switch, the command (sets the switch on for 10 s) :
payload: { multiple: true, data: { 1: true, 102: 10}}
produces the answer:
12 Dec 11:50:26 - [info] [tuya-smart-device:fe3fbeb2.ac31f] Data from device: "{"dps":{"1":true,"102":10},"t":1607770225}"

Using a virtual device, i.e. a radiator controller and ZigBee hub, the command (sets the target temperature)
payload: { "devId": "60a423fffeb5b90d", "dps": 103, "set": 220 }
produces the answer:
12 Dec 12:06:24 - [info] [tuya-smart-device:a9ea9736.7483f8] Data from device: "{"dps":"103":220},"cid":"60a423fffeb5b90d", "type":query,"t":1607771183}"

  1. I get a message also when some values are changed via smartLife, e.g.:
    12 Dec 12:14:08 - [info] [tuya-smart-device:fe3fbeb2.ac31f] Data from device: "{"dps":{"1":true},"t":1607771648}"
    12 Dec 12:16:12 - [info] [tuya-smart-device:a9ea9736.7483f8] Data from device: "{"dps":{"101":47},"cid":"00158d00056e5022","t":1607771771}"

  2. I get also messages in case of a status change on a device, or from a sensor (without any request):
    Switch countdown end:
    12 Dec 11:50:36 - [info] [tuya-smart-device:fe3fbeb2.ac31f] Data from device: "{"dps":{"1":false,"102":0},"t":1607770235}"
    Temperature from a ZigBee sensor, (about every 3600s, request by Tuya cloud?):
    12 Dec 12:14:28 - [info] [tuya-smart-device:a9ea9736.7483f8] Data from device: "{"dps":{"103":215},"cid":"60a423fffeb5b90d","t":1607771667}"

It sounds good, so all ok? Sorry, not really.

  1. Any 'GET' command in any device (real, virtual, ...) in any form, don't work! Always I get:
    12 Dec 11:32:32 - [error] [tuya-smart-device:fe3fbeb2.ac31f] json obj data unvalid

This is a big problem because I cannot read in polling any RO device data points, so some parameters are unreachable.

Maybe the problem is in TuyApi: see also issue #246 and issue #23.

Any other user has found this behavior?

Any idea for solutions?

Best regards
m.s.

Can you provide examples of GET and REFRESH

As stated, I can't seem to figure out how to get status info. Can you provide an example? I've tried using both the generic and device nodes and nothing is returned.

UPDATE: I found if I don't use any parameters for device, I can GET a full dump of the device status. I cannot figure out how to request a specific dps for GET.

I cannot get generic device to work with GET at all.

standard behavior of node-red-contrib-tuya-smart-device (4.1.connection issue)

node-red-contrib-tuya-smart-device used:

tuya-smart-device.zip It is a modified version to meet requirements.

TEST flow used:

Devices tested: Wifi Plug: passed, Power Strip: passed, LED 700ml Humidifier: passed.

These devices are chosen because all accept SCHEMA. Tuya devices can present many variations to expected behavior.

Expected behavior REFRESH

9/6/2021, 11:04:11node: Device INPUT
msg.payload : Object
object
   operation: "REFRESH"
   requestedDPS: array[7]
		0: 1
		1: 9
		2: 6
		3: 17
		4: 18
		5: 19
		6: 20

9/6/2021, 11:04:11node: Device Data
msg.payload.data.dps : Object
{ 18: 62, 19: 53 }  // ERROR !!!, expected 1,9,6,17,18,19,20 DPS, found only 18,19

note:
The expected behavior is not provided by ANY device because the 'tuyAPI' definitions are equivocal, and the tuyAPI implementation is not consistent with the definitions.
The RULES I found on all my devices are, see ISSUE#469:

  • The REFRESH causes an immediate re-sampling and all data are re-calculated.
  • In output are sent ALWAYS only the CHANGED dps (not all (SCHEMA) or requestedDPS !).
  • REFRESH, REFRESH SCHEMA, REFRESH DPS works ALL the same way: i.e. exists only one REFRESH function (at least, with the implementation under the test of tuyAPI ver. 7.1.0 ).

In applications I use only one vanilla REFRESH, applying previous rules, and it works as expected.

Expected behavior STARTUP, device ON, Disable auto-connect on start: false

9/6/2021, 13:20:41node: Node State
msg.payload : Object
{ state: "DISCONNECTED" }

9/6/2021, 13:20:42node: Node State
msg.payload : Object
{ state: "CONNECTING" }

9/6/2021, 13:20:43node: Node State
msg.payload : Object
{ state: "ERROR", context: object }

9/6/2021, 13:20:43node: Node State
msg.payload : Object
{ state: "DISCONNECTED" }

..... more

9/6/2021, 13:20:50node: Node State
msg.payload : Object
{ state: "CONNECTING" }

9/6/2021, 13:20:51node: Node State
msg.payload : Object
{ state: "CONNECTED" }

note:

  • The CONNECTING-ERROR-DISCONNECTED cycle can be repeated more times: it is OK, can be
    a consequence of too small findTimeout value.
  • In this case, the ERROR msg is superfluous: enough to ignore it in apps.
  • Required: the initial 'DISCONNECTED' and the final 'CONNECTED'.

Expected behavior STARTUP, device ON, Disable auto-connect on start: true

9/6/2021, 17:15:05node: Device State
msg.payload : Object
{ state: "DISCONNECTED" }
OK ---- waiting  CONTROL CONNECT
------ now CONTROL CONNECT

9/6/2021, 17:15:30node: Device INPUT
msg.payload : Object
{ operation: "CONTROL", action: "CONNECT" }

9/6/2021, 17:15:31node: Device State
msg.payload : Object
{ state: "CONNECTING" }

9/6/2021, 17:15:33node: Device State
msg.payload : Object
{ state: "CONNECTED" }

note:

  • 'Disable auto-connect on start' is for only the first start after Deploy or Restart flows.
    If later the device goes OFF then back ON, the device is auto-connected.

  • Required: user CONTROL 'CONNECT'|'RECONNECT' and the final 'CONNECTED'.

Expected behavior STARTUP, device OFF, Disable auto-connect on start: false

9/6/2021, 12:51:53node: Node State
msg.payload : Object
{ state: "DISCONNECTED" }

9/6/2021, 12:51:54node: Node State
msg.payload : Object
{ state: "CONNECTING" }

9/6/2021, 12:52:14node: Node State
msg.payload : Object
state: "ERROR"
    context: object
       message: "Error: find() timed out. Is the device powered on and the ID or IP correct?"
       device: "Wifi plug"
	   
9/6/2021, 12:52:14node: Node State
msg.payload : Object
{ state: "DISCONNECTED" }

9/6/2021, 12:52:24node: Node State
msg.payload : Object
{ state: "CONNECTING" }

9/6/2021, 12:52:44node: Node State
msg.payload : Object
state: "ERROR"
   context: object
      message: "Error: find() timed out. Is the device powered on and the ID or IP correct?"
      device: "Wifi plug"
......  more

note:

  • Never-ending loop CONNECTING-ERROR-DISCONNECTED.
  • In this case, the ERROR msg is superfluous: enough to ignore it in apps.
    • Between CONNECTING-ERROR, 20s == findTimeout
    • Between ERROR-DISCONNECTED 0s
    • Between DISCONNECTED-CONNECTING, 10s == retryTimeout

Required:

  • the initial 'DISCONNECTED'.
  • Infinite loop CONNECTING-(ERROR)-DISCONNECTED.
  • No node.error messages.

Expected behavior device OFF => ON

9/6/2021, 13:37:53node: Node State
msg.payload : Object
{ state: "DISCONNECTED" }
// ---- here device goes ON

9/6/2021, 13:37:58node: Node State
msg.payload : Object
{ state: "CONNECTING" }

9/6/2021, 13:38:03node: Node State
msg.payload : Object
state: "ERROR"
   context: object
      message: "Error: find() timed out. Is the device powered on and the ID or IP correct?"
      device: "Wifi plug"
	  
9/6/2021, 13:38:03node: Node State
msg.payload : Object
{ state: "DISCONNECTED" }

9/6/2021, 13:38:08node: Node State
msg.payload : Object
{ state: "CONNECTING" }

9/6/2021, 13:38:10node: Node State
msg.payload : Object
{ state: "CONNECTED" }


9/6/2021, 13:38:32node: Device Data
msg.payload.data.dps : Object
{ 18: 62, 19: 53, 20: 2295 }

note:

  • Required: the final 'CONNECTED'.

Expected behavior device ON => OFF


9/6/2021, 13:50:21node: Device Data
msg.payload.data.dps : Object
{ 18: 62, 19: 53, 20: 2299 }
//---- here device goes OFF

9/6/2021, 13:50:32node: Node State
msg.payload : Object
{ state: "DISCONNECTED" }

9/6/2021, 13:50:37node: Node State
msg.payload : Object
{ state: "CONNECTING" }

9/6/2021, 13:50:42node: Node State
msg.payload : Object
{ state: "DISCONNECTED" }

9/6/2021, 13:50:52node: Node State
msg.payload : Object
{ state: "CONNECTING" }

9/6/2021, 13:50:57node: Node State
msg.payload : Object
{ state: "DISCONNECTED" }

9/6/2021, 13:51:07node: Node State
msg.payload : Object
{ state: "CONNECTING" }
..........  more

note:

  • Never-ending loop CONNECTING-DISCONNECTED.
  • difference from STARTUP-OFF case: the STATE ERROR message is now missed: no problem, it is superfluous.
    • Between CONNECTING-DISCONNECTED 5s == findTimeout
    • Between DISCONNECTED-CONNECTING, 10s == retryTimeout

Required:

  • Infinite loop CONNECTING-(ERROR)-DISCONNECTED.
  • No 'node.error' messages.

Expected behavior CONNECT/DISCONNECT/RECONNECT

start condition: STARTUP, device ON

9/6/2021, 14:03:39node: Node State
msg.payload : Object
{ state: "DISCONNECTED" }

9/6/2021, 14:03:40node: Node State
msg.payload : Object
{ state: "CONNECTING" }

9/6/2021, 14:03:43node: Node State
msg.payload : Object
{ state: "CONNECTED" }
------- now CONTROL DISCONNECT

9/6/2021, 14:03:48node: Device INPUT
msg.payload : Object
{ operation: "CONTROL", action: "DISCONNECT" }

9/6/2021, 14:03:48node: Node State
msg.payload : Object
{ state: "DISCONNECTED" }
OK, done ---- now more CONTROL DISCONNECT

9/6/2021, 14:04:13node: Device INPUT
msg.payload : Object
{ operation: "CONTROL", action: "DISCONNECT" }
OK, no effect ----  now CONTROL CONNECT

9/6/2021, 14:04:24node: Device INPUT
msg.payload : Object
{ operation: "CONTROL", action: "CONNECT" }

9/6/2021, 14:04:25node: Node State
msg.payload : Object
{ state: "CONNECTING" }

9/6/2021, 14:04:26node: Node State
msg.payload : Object
{ state: "CONNECTED" }
// OK, done  ----  now more CONTROL CONNECT

9/6/2021, 14:04:31node: Device INPUT
msg.payload : Object
{ operation: "CONTROL", action: "CONNECT" }
//  OK, no effect --- now CONTROL RECONNECT

9/6/2021, 14:04:44node: Device INPUT
msg.payload : Object
{ operation: "CONTROL", action: "RECONNECT" }

9/6/2021, 14:04:44node: Node State
msg.payload : Object
{ state: "DISCONNECTED" }

9/6/2021, 14:04:45node: Node State
msg.payload : Object
{ state: "CONNECTING" }

9/6/2021, 14:04:45node: Node State
msg.payload : Object
{ state: "CONNECTED" }
//  OK, done --- now second CONTROL RECONNECT

9/6/2021, 14:04:50node: Device INPUT
msg.payload : Object
{ operation: "CONTROL", action: "RECONNECT" }

9/6/2021, 14:04:50node: Node State
msg.payload : Object
{ state: "DISCONNECTED" }

9/6/2021, 14:04:51node: Node State
msg.payload : Object
{ state: "CONNECTING" }
// ok, re-done .....
...........   more

9/6/2021, 15:36:55node: Node State
msg.payload : Object
{ state: "DISCONNECTED" }
------------ now RECONNECT (but device DISCONNECTED)

9/6/2021, 15:36:57node: Device INPUT
msg.payload : Object
{ operation: "CONTROL", action: "RECONNECT" }

9/6/2021, 15:36:59node: Node State
msg.payload : Object
{ state: "CONNECTING" }

9/6/2021, 15:37:00node: Node State
msg.payload : Object
{ state: "CONNECTED" }
// OK, done: connected

Required:

  • CONNECT; connects the device, if DISCONNECTED, else does nothing.
  • DISCONNECT; disconnects the device, if CONNECTED, else does nothing.
  • RECONNECT: disconnects the device, if CONNECTED, then (re)connects them.

Expected behavior SET/GET/SCHEMA

//------------ SET 1, true
9/6/2021, 15:59:47node: Device INPUT
msg.payload : Object
{ dps: 1, set: true }

9/6/2021, 15:59:47node: Device Data
msg.payload.data.dps : Object
{ 1: true }
// OK: as expected --- SET 1, false

9/6/2021, 15:59:49node: Device INPUT
msg.payload : Object
{ dps: 1, set: false }
9/6/2021, 15:59:49node: Device Data
msg.payload.data.dps : Object
{ 1: false }
//  OK: as expected --- GET 1

9/6/2021, 15:59:55node: Device INPUT
msg.payload : Object
{ operation: "GET", dps: 1 }

9/6/2021, 15:59:55node: Device Data
msg.payload.data.dps : Object
{ 1: false
9: 0
17: 2
18: 0
19: 0
20: 2299
21: 1
22: 627
23: 29228
24: 17033
25: 2460
26: 0
38: "memory"
41: ""
42: ""
46: false }
//  ** Device quirk: the GET answer is like 'SCHEMA'
//--------- else using: SET 1, null

9/6/2021, 16:06:10node: Device INPUT
msg.payload : Object
{ dps: 1, set: null }
9/6/2021, 16:06:10node: Device Data
msg.payload.data.dps : Object
{ 1: true }
//  OK, as expected ----- with this device use alway 'SET dp, null' in place of 'GET dp'
// now--------  SCHEMA

9/6/2021, 16:06:16node: Device INPUT
msg.payload : Object
{ operation: "GET", schema: true }

9/6/2021, 16:06:16node: Device Data
msg.payload.data.dps : Object
object
1: true
9: 0
17: 2
18: 0
19: 0
20: 2299
21: 1
22: 627
23: 29228
24: 17033
25: 2460
26: 0
38: "memory"
41: ""
42: ""
46: false }
//  OK, as expected

note:

  • The unusual behavior of the 'Wifi Plug' in the case 'GET 1' was known.
  • The SET/GET/SCHEMA device behavior is complicated by the presence of some fallbacks on tuyAPI implementation, so an unexpected result can become from the devices but also from tuyAPI.
  • As tuyAPI users, we must accept the tuyAPI + device as a unique black-block, ready to accept possibles differences in the behavior for every new version.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.