interested as well. I have some of those Tuya power strips with USB and one in-wall switch and some other regular smart plugs from Tuya.
I have tried it running the node server on a RP3B+ alongside the other node (TP-Link). I had to get an old S3 rooted to find the key/dev ids. However it fails and punts as soon as the first command is sent from Hubitat. Haven't had the time to dig deeper except I might today
something like this:
Command sending to IP: 192.168.0.118 Command: status
/home/pi/node_modules/node-forge/lib/aes.js:203
var len = tmp.length();
^
TypeError: tmp.length is not a function
at forge.aes.Algorithm.initialize (/home/pi/node_modules/node-forge/lib/aes.js:203:19)
at new forge.cipher.BlockCipher (/home/pi/node_modules/node-forge/lib/cipher.js:118:18)
at Object.forge.cipher.createCipher (/home/pi/node_modules/node-forge/lib/cipher.js:42:10)
at new TuyaCipher (/home/pi/node_modules/tuyapi/lib/cipher.js:14:30)
at new TuyaDevice (/home/pi/node_modules/tuyapi/index.js:54:26)
at processDeviceCommand (/home/pi/TuyaHub/TuyAPI_Server_v1.js:87:13)
at Server.onRequest (/home/pi/TuyaHub/TuyAPI_Server_v1.js:53:4)
at Server.emit (events.js:182:13)
at parserOnIncoming (_http_server.js:657:12)
at HTTPParser.parserOnHeadersComplete (_http_common.js:109:17)
They have made leaps and bounds since I made this.
I set this up again the other day so I am sure we can still make it work. I simply replaced the contents of the node server with what is in my forked repo.
Use the driver in the test branch. I currently only have the one power strip with 4 switches and the USB group.
Single switch devices may need a different driver. I'd be willing to make something if we can get you going.
Let me try and update and install the codetheweb/tuyapi again. I have two strips of the same you got (4 switches with USB group) so hope to get those working first.
Hi man... good to see you spreading your coding wings!!!
I just picked up 6 of these plugs for a bargain price and would love to try your code. Just need to carve out some time. It will be a good use of my Hubitat hub since I moved all my lights back to ST.
It is too bad you've been having so much trouble on this side ken.
What sort of plugs did you get? Are they single outlets?
It has been awhile since I worked on it. The guys who mad this a pi have taken it quite a bit further. I believe you can do everything from discovery and registration right from your pi and never use any of the tuya apps. I have not played with that yet.
They also have made changes to the a pi which do not work with my driver.
I was able to get this going again though with the files in the test branch of my repo.
I have a feeling we may have issue with a single plug device. I ordered one this morning. Hopefully I can make a driver specific for it.
I appreciate the support. Hit me up when you go to give it a shot.
Yea - my troubles with Hubitat all stem from erratic behavior of my GE Zwave switches. Everything else is pretty good.
On the Tuya stuff I bought 6 single plugs. They were dirt cheap and work great using the SmartLife app. IFTTT is my default path to linking them into Hubitat or ST but your code will be much better.
So my single plug arrived today. I just confirmed that with the code as is I am able to control the device and get status. It should not be much trouble to scale the back to have it be for a single outlet. On my days off I will see if I can make that happen.
If and when you do go to install use the files in my test branch, until I get everything cleaned up and presentable. I will try and post clear instructions to install as well. As I am a using a version that is FAR behind the master repo we need to make sure it is installed.
I'm suffering from the Outlet rebooting issue. When sending some commands, it performs the command requested and then reboots (I guess) and returns to the previous state. So if it's Off and you try to power on, it will sometimes (50 50 chance) turn on then right back off. I bought about 8 of these during a good sale and it happens on all of them.
I also have an Outdoor Outlet that this happens to.
Yes and thank you for your response. I’ve also tried a Homebridge Tuya plug-in which does the same thing. After some googleing I found that a Python-Tuya program should fix this because of how it talks to the Tuyapi but I haven’t tried it yet.
That would be awesome. Thanks cwwilson08. I'll try to find what I was reading earlier about this issue and post it here. The logs do not appear any different working VS not. I've got a button that controls one. This is what was listed for the failed Power Off command. Crazy thing about it is how inconsistent it fails. This time I had to push the button 4 times before it failed but usually it's the first time my wife tries it...
dev:392018-12-23 04:21:15.645 pm infoOutlet 7 - LR null: Power: off dev:392018-12-23 04:21:15.518 pm debugdeviceCommand dev:2322018-12-23 04:21:15.354 pm infoSamsung Button button 1 was pushed
I was not using your test branch and I did not replace your files over codetheweb's. So I think I did both of those things now. After doing that, nothing worked. I did not have the SmartLife app open while doing this. I noticed in the logs (running on my HomeBridge Ubuntu Server):
Dec 29 22:54:08 HomeBridgeV10 node[2179]: [40B blob data]
Dec 29 22:54:08 HomeBridgeV10 node[2179]: IP: 192.168.99.84 sent command deviceCommand
Dec 29 22:54:08 HomeBridgeV10 node[2179]: deviceCommand sending to IP: 192.168.99.84 Command: status
Dec 29 22:54:10 HomeBridgeV10 node[2179]: (node:2179) UnhandledPromiseRejectionWarning: Error: Error communicating with device. Make sure nothing else is trying to control it or connected to it.
Dec 29 22:54:10 HomeBridgeV10 node[2179]: at Socket.client.setTimeout (/var/homebridge/node_modules/tuyapi/index.js:434:35)
Dec 29 22:54:10 HomeBridgeV10 node[2179]: at Object.onceWrapper (events.js:313:30)
Dec 29 22:54:10 HomeBridgeV10 node[2179]: at emitNone (events.js:106:13)
Dec 29 22:54:10 HomeBridgeV10 node[2179]: at Socket.emit (events.js:208:7)
Dec 29 22:54:10 HomeBridgeV10 node[2179]: at Socket._onTimeout (net.js:422:8)
Dec 29 22:54:10 HomeBridgeV10 node[2179]: at ontimeout (timers.js:498:11)
Dec 29 22:54:10 HomeBridgeV10 node[2179]: at tryOnTimeout (timers.js:323:5)
Dec 29 22:54:10 HomeBridgeV10 node[2179]: at Timer.listOnTimeout (timers.js:290:5)
Dec 29 22:54:10 HomeBridgeV10 node[2179]: (node:2179) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, o
Dec 29 22:54:10 HomeBridgeV10 node[2179]: (node:2179) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js
But if I just put back the Master js file, it's functioning as it was before. And the logs look good:
Dec 29 23:00:43 HomeBridgeV10 node[2226]: [40B blob data]
Dec 29 23:00:43 HomeBridgeV10 node[2226]: IP: 192.168.99.82 sent command deviceCommand
Dec 29 23:00:43 HomeBridgeV10 node[2226]: deviceCommand sending to IP: 192.168.99.82 Command: status
Dec 29 23:00:43 HomeBridgeV10 node[2226]: Status: false
Dec 29 23:00:43 HomeBridgeV10 node[2226]: Status (false) sent to Hubitat.
Sorry but I was incorrect. I updated 1 of my 10 switches and I was seeing systemctl logs on the others using a chopped up single switch version that I did with your original. When I click the refresh button using your test Hubitat device driver and your test js server, the js server crashes and restarts. If I use my chopped up single device driver, I get the "UnhandledPromiseRejectionWarning: Error: Error communicating with device. Make sure nothing else is trying to control it or connected to it." error but it doesn't crash the js Server. If I use the Master js Server, both device drivers return to previous mostly working behavior.
