hgross / node-red-contrib-tuya-smart

NodeRED nodes to get data from tuya smart devices (like smart plugs, bulbs, ...).
MIT License
43 stars 14 forks source link

weird answer #3

Closed geertvercamer closed 5 years ago

geertvercamer commented 5 years ago

Hi,

I have a smart plug working fine with the app, but in node-red it gives a very different answer: {"data":"ë<GU•š/F\u0006l»\MJP”","deviceIp":"192.168.1.61","deviceId":"xxxxxxxxxxx","deviceName":"Plug1"}

I also have a power strip, but I cann't toggle any part of it. It looks ok (I think) in debug: msg.payload : Object object data: object devId: "xxxxxxxxxxxx" dps: object 1: true 2: true 3: true 4: true 102: 31 103: 10 104: 2196 105: 1 106: 1608 107: 35750 108: 101000 109: 216 deviceIp: "192.168.1.200" deviceId: "xxxxxxxxxxxxxx" deviceName: "strip"

status of individual sockets is correct.

I tried to inject a string with the text {"set": true, "dpsIndex": 1} but nothing happens. I may have this wrong though.

Any help highly appreciated! Thanks

hgross commented 5 years ago

Hi,

my guess for the first would be a failed deserialization due to a wrong deviceId/deviceKey combination.

Do you see any error-logs regarding the power-strip in the NodeRED or browser log? Sending a message payload (msg.payload) of

{"set": false, "dpsIndex": 1} 

should disable the 1st socket and

{"set": false, "dpsIndex": 1} 

should re-enable it.

Cheers

geertvercamer commented 5 years ago

Thanks, but if that combination is wrong, the plug wouldn't shown 'connected' in Node-Red, would it?

Complete Linux noob, node-red is very new too. I see the process running, but no idea how to see the log. Found this, but I don't think it's very useful: sudo strace -e trace=open -p 975 -s 80 strace: Process 975 attached --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8177, si_uid=0, si_status=0, si_utime=0, si_stime=0} --- --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8172, si_uid=0, si_status=0, si_utime=0, si_stime=0} --- --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8436, si_uid=0, si_status=0, si_utime=0, si_stime=0} --- --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8435, si_uid=0, si_status=0, si_utime=0, si_stime=0} --- --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8701, si_uid=0, si_status=0, si_utime=0, si_stime=0} --- --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8696, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---

hgross commented 5 years ago

The connected state is assumed to be ok, if we successfully received (https://github.com/hgross/node-red-contrib-tuya-smart/blob/master/lib/tuya-smart.ts#L30) or sent data (https://github.com/hgross/node-red-contrib-tuya-smart/blob/master/lib/tuya-smart.ts#L74) to the device. Since you got some data this is technically the case - the nodes do not look further into the content of data (and do not validate a correct deserialization/decryption).

You can further validate the correctness of your deviceId/key using the tuyapi-cli (https://github.com/TuyaAPI/cli) - for example like this:

$ tuya-cli get --id xxxxxxxxxx --key xxxxxxxxx --ip 192.168.1.200

Regarding the Logs:

geertvercamer commented 5 years ago

and then, one realises rest is needed when one sees that two plugs have almost the same mac address and ids/keys/ip were mixed.

thanks for your help anyway. Works like a charm now