search

AMoo-Miki / homebridge-tuya-lan

Homebridge plugin for IoT devices that use Tuya Smart's platform
MIT License
204 stars 52 forks source link

Teckin Smart Plug SP23 #23

Closed gazzmanzx6 closed 5 years ago

gazzmanzx6 commented 5 years ago

I made the mistake of updating the firmware in my Teckin SP23 plugs to version 1.0.5. Since doing this they will not connect in TuyaLan. My Jomarto smart plugs still show up and work fine. I have tried deleting the Teckin plugs and creating a new key but this hasn't helped.

Any ideas why they should be unavailable after the firmware update?

rshnthmb commented 5 years ago

Hi, after upgrading my Teckin smartbulb to 1.0.5 I am also having issues for the device to be discovered on homebridge service start.

I can confirm that it is definately the firmware upgrade issue, as my other bulb which have not been ugpraded works without issues.

[2019-3-11 20:31:24] [TuyaLan] Failed to discover Bed Light (22xxxxxxxxxxxxx66xx) in time but will keep looking.

twistedindustries commented 5 years ago

Have you guys tried removing the device from the app and re-adding it which generates a new key? You may have to re-setup your homebridge config with a new pin and user as well as clearing persist and accessories folders.

gazzmanzx6 commented 5 years ago

Yeah. Tried that and it made no difference.

Stratosdj commented 5 years ago

Another one here with the same problem. Any solution please?

rshnthmb commented 5 years ago

Yeah same, I have tried unregistering and generating a new key. Plus the firmware was updated before introducing to home bridge.

Still no luck, please help

twistedindustries commented 5 years ago

That sucks, sounds like it is something in the firmware that broke it.

AMoo-Miki commented 5 years ago

I know that some devices stop responding to discovery requests or have a different discovery sequences. I have not gotten my hands on one of these latter ones to be able to figure them out. However, if you know the IP address of the device, add an ip parameter to the definition block of the device in your config file with the value being the IP address of the device. You will need the latest version of the plugin which hasn't been released yet; to get it, run npm i -g AMoo-Miki/homebridge-tuya-lan.

After updating the plugin, adding the ip parameter to your config, and restarting homebridge, look at the logs; after 60 seconds, you should see something about failing to discover but using the IP to connect. If it works, you should see a Ready to use ... with signature message.

Lemme know if this solves the problem or not.

Good luck.

rshnthmb commented 5 years ago

Hi, Thank you for your response. I have followed your instructions. I am tailing my syslog and can see the following messages. It seems like it connects and disconnects straight away.

Mar 13 21:50:30 homebridge homebridge[3339]: [2019-3-13 21:50:30] [TuyaLan] Failed to discover Test Light (22551008840d8e8c669b) in time but will connect via 192.168.0.33. Mar 13 21:50:30 homebridge homebridge[3339]: [2019-3-13 21:50:30] [TuyaLan] Connected to Test Light Mar 13 21:50:30 homebridge homebridge[3339]: [TuyaAccessory] Closed connection with Test Light Mar 13 21:51:06 homebridge homebridge[3339]: message repeated 10 times: [ [TuyaAccessory] Closed connection with Test Light] Mar 13 21:51:06 homebridge homebridge[3339]: (node:3339) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 timeout listeners added. Use emitter.setMaxListeners() to increase limit Mar 13 21:51:06 homebridge homebridge[3339]: [TuyaAccessory] Closed connection with Test Light Mar 13 21:51:36 homebridge homebridge[3339]: message repeated 1170 times: [ [TuyaAccessory] Closed connection with Test Light] Mar 13 21:51:36 homebridge homebridge[3339]: (node:3339) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 timeout listeners added. Use emitter.setMaxListeners() to increase limit Mar 13 21:51:36 homebridge homebridge[3339]: [TuyaAccessory] Closed connection with Test Light Mar 13 21:52:07 homebridge homebridge[3339]: message repeated 1153 times: [ [TuyaAccessory] Closed connection with Test Light] Mar 13 21:52:07 homebridge homebridge[3339]: (node:3339) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 timeout listeners added. Use emitter.setMaxListeners() to increase limit Mar 13 21:52:07 homebridge homebridge[3339]: [TuyaAccessory] Closed connection with Test Light Mar 13 21:52:12 homebridge homebridge[3339]: message repeated 15 times: [ [TuyaAccessory] Closed connection with Test Light] Mar 13 21:52:12 homebridge homebridge[3339]: (node:3339) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 timeout listeners added. Use emitter.setMaxListeners() to increase limit Mar 13 21:52:12 homebridge homebridge[3339]: [TuyaAccessory] Closed connection with Test Light Mar 13 21:52:37 homebridge homebridge[3339]: message repeated 879 times: [ [TuyaAccessory] Closed connection with Test Light] Mar 13 21:52:37 homebridge homebridge[3339]: (node:3339) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 timeout listeners added. Use emitter.setMaxListeners() to increase limit Mar 13 21:52:37 homebridge homebridge[3339]: [TuyaAccessory] Closed connection with Test Light Mar 13 21:52:37 homebridge homebridge[3339]: message repeated 20 times: [ [TuyaAccessory] Closed connection with Test Light] Mar 13 21:52:37 homebridge homebridge[3339]: (node:3339) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 timeout listeners added. Use emitter.setMaxListeners() to increase limit Mar 13 21:52:37 homebridge homebridge[3339]: [TuyaAccessory] Closed connection with Test Light Mar 13 21:52:43 homebridge homebridge[3339]: message repeated 240 times: [ [TuyaAccessory] Closed connection with Test Light] Mar 13 21:52:43 homebridge homebridge[3339]: (node:3339) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 timeout listeners added. Use emitter.setMaxListeners() to increase limit Mar 13 21:52:43 homebridge homebridge[3339]: [TuyaAccessory] Closed connection with Test Light

AMoo-Miki commented 5 years ago

@rshnthmb, I have seen this happen when the IP or port are incorrect or the device doesn't follow the original protocol. When you removed the device from the Tuya app and re added it, did you get a different id and key, or was it the same old one? If you haven't done that, it is a good idea to do.

To debug, I would start with a port-scan of the device:

sudo apt-get install nmap
sudo nmap -sU -Pn -v -p- 192.168.0.33

nmap will take a couple of hours and make sure Homebridge is stopped, your Tuya app is closed, and nothing is talking to the device. If nmap exits immediately, it is because it thinks the device is down; run t again.

I will wait to hear the your results before proposing anything more. Good luck.

rshnthmb commented 5 years ago

@AMoo-Miki Yes I have factory reset the device which removed it from the Tuya app. When adding it back in, it did give me a different key, however the ID did not change.

I am currently running nmap, whilst my apps are stopped, will let you know on my results.

Thanks for your response.

P.S. I can confirm the IP is correct.

AMoo-Miki commented 5 years ago

Thanks for updating me. Let's hope it is just a simple port difference. There is also something I had done when I was initially messing with the Tuya API. I will try to sleep a bit so that I can remember what that was!

rshnthmb commented 5 years ago

Hi @AMoo-Miki

Here is my result:

Nmap scan report for 192.168.0.33 PORT STATE SERVICE 49154/udp open|filtered unknown

AMoo-Miki commented 5 years ago

Can you please add "port": 49154 to your definition block of the device in the config file of Homebridge? I have seen others mentioning that their devices worked via communicating with this port. Any messages from your log would be helpful if it doesn't work; please include timestamps like you did earlier.

Good luck.

rshnthmb commented 5 years ago

Hi @AMoo-Miki sounded like a good suggestion, but no look, it seems like the connection keeps closing.

I have run a packet capture against 192.168.0.33 (the light bulb) and tailed the logs during startup, please take a look:

Mar 14 18:18:48 homebridge homebridge[9539]: [2019-3-14 18:18:48] [TuyaLan] Starting discovery... Mar 14 18:18:48 homebridge homebridge[9539]: [2019-3-14 18:18:48] Homebridge is running on port 51826. Mar 14 18:18:48 homebridge homebridge[9539]: [TuyaAccessory] Discovery started. Mar 14 18:19:48 homebridge homebridge[9539]: [2019-3-14 18:19:48] [TuyaLan] Failed to discover Test Light (22551008840d8e8c669b) in time but will connect via 192.168.0.33. Mar 14 18:19:48 homebridge homebridge[9539]: [TuyaAccessory] Closed connection with Test Light

18:18:41.345024 IP (tos 0x0, ttl 255, id 53332, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188 18:18:43.642059 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.33 tell 192.168.0.33, length 46 18:18:46.345049 IP (tos 0x0, ttl 255, id 53333, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188 18:18:51.346463 IP (tos 0x0, ttl 255, id 53334, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188 18:18:53.635716 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.33 tell 192.168.0.33, length 46 18:18:56.345764 IP (tos 0x0, ttl 255, id 53335, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188 18:19:01.348340 IP (tos 0x0, ttl 255, id 53336, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188 18:19:03.641731 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.33 tell 192.168.0.33, length 46 18:19:06.347108 IP (tos 0x0, ttl 255, id 53337, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188 18:19:11.345775 IP (tos 0x0, ttl 255, id 53338, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188 18:19:13.643591 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.33 tell 192.168.0.33, length 46 18:19:16.347224 IP (tos 0x0, ttl 255, id 53339, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188 18:19:21.348795 IP (tos 0x0, ttl 255, id 53340, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188 18:19:23.641175 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.33 tell 192.168.0.33, length 46 18:19:26.347064 IP (tos 0x0, ttl 255, id 53343, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188 18:19:31.347620 IP (tos 0x0, ttl 255, id 53344, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188 18:19:33.642052 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.33 tell 192.168.0.33, length 46 18:19:36.348342 IP (tos 0x0, ttl 255, id 53345, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188 18:19:41.351834 IP (tos 0x0, ttl 255, id 53346, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188 18:19:43.644266 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.33 tell 192.168.0.33, length 46 18:19:46.346524 IP (tos 0x0, ttl 255, id 53347, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188 18:19:48.462692 IP (tos 0x0, ttl 64, id 41802, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.34.39486 > 192.168.0.33.49154: Flags [S], cksum 0x81c2 (incorrect -> 0xe488), seq 3851511210, win 29200, options [mss 1460,sackOK,TS val 58050272 ecr 0,nop,wscale 7], length 0 18:19:48.520484 IP (tos 0x0, ttl 255, id 53348, offset 0, flags [none], proto TCP (6), length 40) 192.168.0.33.49154 > 192.168.0.34.39486: Flags [R.], cksum 0x77a2 (correct), seq 0, ack 3851511211, win 4380, length 0 18:19:51.346839 IP (tos 0x0, ttl 255, id 53349, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188 18:19:53.468618 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.33 tell 192.168.0.34, length 28 18:19:53.522320 IP (tos 0x0, ttl 64, id 59543, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.34.39488 > 192.168.0.33.49154: Flags [S], cksum 0x81c2 (incorrect -> 0xc115), seq 1182147398, win 29200, options [mss 1460,sackOK,TS val 58051537 ecr 0,nop,wscale 7], length 0 18:19:53.533976 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.0.33 is-at 84:0d:8e:8c:66:9b (oui Unknown), length 46 18:19:53.533999 IP (tos 0x0, ttl 255, id 53350, offset 0, flags [none], proto TCP (6), length 40) 192.168.0.33.49154 > 192.168.0.34.39488: Flags [R.], cksum 0x5920 (correct), seq 0, ack 1182147399, win 4380, length 0 18:19:53.637313 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.33 tell 192.168.0.33, length 46 18:19:56.348109 IP (tos 0x0, ttl 255, id 53351, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188 18:19:58.534714 IP (tos 0x0, ttl 64, id 43893, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.34.39490 > 192.168.0.33.49154: Flags [S], cksum 0x81c2 (incorrect -> 0x26f9), seq 2200861635, win 29200, options [mss 1460,sackOK,TS val 58052790 ecr 0,nop,wscale 7], length 0 18:19:58.542181 IP (tos 0x0, ttl 255, id 53352, offset 0, flags [none], proto TCP (6), length 40) 192.168.0.33.49154 > 192.168.0.34.39490: Flags [R.], cksum 0xc3e8 (correct), seq 0, ack 2200861636, win 4380, length 0 18:20:01.347124 IP (tos 0x0, ttl 255, id 53353, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188 18:20:03.542203 IP (tos 0x0, ttl 64, id 24812, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.34.39492 > 192.168.0.33.49154: Flags [S], cksum 0x81c2 (incorrect -> 0xec25), seq 2137568630, win 29200, options [mss 1460,sackOK,TS val 58054042 ecr 0,nop,wscale 7], length 0 18:20:03.563099 IP (tos 0x0, ttl 255, id 53354, offset 0, flags [none], proto TCP (6), length 40) 192.168.0.33.49154 > 192.168.0.34.39492: Flags [R.], cksum 0x8df9 (correct), seq 0, ack 2137568631, win 4380, length 0 18:20:03.641696 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.33 tell 192.168.0.33, length 46 18:20:06.347139 IP (tos 0x0, ttl 255, id 53355, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188 18:20:08.563156 IP (tos 0x0, ttl 64, id 48821, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.34.39494 > 192.168.0.33.49154: Flags [S], cksum 0x81c2 (incorrect -> 0x5456), seq 1670472756, win 29200, options [mss 1460,sackOK,TS val 58055297 ecr 0,nop,wscale 7], length 0 18:20:08.687599 IP (tos 0x0, ttl 255, id 53356, offset 0, flags [none], proto TCP (6), length 40) 192.168.0.33.49154 > 192.168.0.34.39494: Flags [R.], cksum 0xfb10 (correct), seq 0, ack 1670472757, win 4380, length 0 18:20:11.349760 IP (tos 0x0, ttl 255, id 53357, offset 0, flags [none], proto UDP (17), length 216) 192.168.0.33.49154 > 255.255.255.255.6667: [udp sum ok] UDP, length 188

AMoo-Miki commented 5 years ago

:( Lemme think and search a bit about this. I will also try and find this locally so that I can do all these experiments without annoying you.

rshnthmb commented 5 years ago

Thanks! Don’t worry about disturbing me, I don’t mind the troubleshooting. But seeing from the initial post, I’m not sure how the latest firmware has changed the behaviour, if there is a way for me to downgrade I would! It’s weird, I have an exact bulb which works fine on the older version. It’s a shame I can’t find out what it’s running.

AMoo-Miki commented 5 years ago

Great. Paste the code below into a file and make sure DEVICE_ID and IP_ADDRESS are correct. Run it with node filename and wait a minute or two to see if and what we hear back.

const DEVICE_ID = '22551008840d8e8c669b';
const IP_ADDRESS = '192.168.0.33';

const net = require('net');
const _socket = net.Socket();
_socket.setKeepAlive(true);
_socket.setNoDelay(true);

let sent = false;
const send = () => {
    if (sent) return;
    sent = true;

    console.log(Date.now(), 'Sending handshake...');

    const prefix = Buffer.from('000055aa000000000000000a', 'hex');
    const suffix = Buffer.from('000000000000aa55', 'hex');
    const len = Buffer.allocUnsafe(4);
    const payload = Buffer.from(JSON.stringify({
        gwId: DEVICE_ID,
        devId: DEVICE_ID
    }));
    len.writeInt32BE(Buffer.concat([payload, suffix]).length, 0);
    return _socket.write(Buffer.concat([prefix, len, payload, suffix]));
};

_socket.on('connect', () => {
    console.log(Date.now(), 'Socket connected');
    setTimeout(send, 5000);
});

_socket.on('ready', () => {
    console.log(Date.now(), 'Socket ready');
    setTimeout(send, 1000);
});

_socket.on('data', msg => {
    console.log(Date.now(), '----\n', msg.toString(), '\n----');
});

_socket.on('error', err => {
    sent = true;
    console.log(Date.now(), 'Socket error', err);
});

_socket.on('close', err => {
    sent = true;
    console.log(Date.now(), 'Socket closed:', err);
});

_socket.on('end', () => {
    sent = true;
    console.log(Date.now(), 'Socket ended');
});

console.log(Date.now(), 'Connecting ...');
_socket.connect(6668, IP_ADDRESS);
gazzmanzx6 commented 5 years ago

I have been in touch with Teckin technical support to try and find what changes are in the new firmware but I think the language barrier is causing them not to understand. No luck except being offered replacement plugs. Having tried the tests with my Teckin plug I get the same port number (49154) and the following results from the last test:

1552647886629 'Connecting ...' 1552647886686 'Socket connected' 1552647886695 'Socket ready' 1552647887703 'Sending handshake...' 1552647888421 '----\n' '\u0000\u0000U�\u0000\u0000\u0000\u0000\u0000\u0000\u0000\b\u0000\u0000\u0000k\u0000\u0000\u0000\u00003.3\u0000\u0000\u0000\u0000\u0000\u0000\b\u001d\u0000\u0000\u0000\u0001W�Fu�\u0005�m�V+��k�T��\u001b��\u0006�\u000b\u001eDu2���oS��\f��2��j9\u001c��2�{\u0000�f��cb�WH����s*��%�A���\b���\u0018��\u0000\u0000�U' '\n----' 1552647893469 '----\n' '\u0000\u0000U�\u0000\u0000\u0000\u0000\u0000\u0000\u0000\b\u0000\u0000\u0000[\u0000\u0000\u0000\u00003.3\u0000\u0000\u0000\u0000\u0000\u0000\b\u001e\u0000\u0000\u0000\u0001W�Fu�\u0005�m�V+��k�T��\u001b��\u0006�\u000b\u001eDu2���ڤЕ]�_\'�x�@\u0014��ں\u0003\u0003���\u0019��������\r�Ҷ\u0000\u0000�U' '\n----' 1552647923410 'Socket error' { Error: read ECONNRESET at TCP.onStreamRead (internal/stream_base_commons.js:111:27) errno: 'ECONNRESET', code: 'ECONNRESET', syscall: 'read' } 1552647923430 'Socket closed:' true

AMoo-Miki commented 5 years ago

Interesting! Can you please change the line console.log(Date.now(), '----\n', msg.toString(), '\n----'); to:

console.log(Date.now(), '----\n', msg.toString('hex'), '\n----');

... and try again?

I see a 3.3 there which might be the version which would mean a bump. While I can't say from the blob (hence the code change), it might be that the handshake is encrypted too. If true, let's just hope that they haven't changed the algorithm :P

gazzmanzx6 commented 5 years ago

Here is the result:

1552738595941 'Connecting ...' 1552738595993 'Socket connected' 1552738596001 'Socket ready' 1552738597008 'Sending handshake...' 1552738597748 '----\n' '000055aa00000000000000080000006b00000000332e3300000000000009320000000157964675c9059f6dcf562b89f26b8b54a6fa1b8f96067ff09a0b1e447532c6ffb6020e961d209fbe691696bb9de17a6c8620591be83dadbe07cfcee4b775ae169f24767d9dbc0400e615249276d18c19b30001880000aa55' '\n----' 1552738602768 '----\n' '000055aa00000000000000080000006b00000000332e3300000000000009330000000157964675c9059f6dcf562b89f26b8b54a6fa1b8f96067ff09a0b1e447532c6ff36aa08f214621e4701e2cb6b229a177fbc5ae9bedb50cafe8a8657c907bae793ac7178b6dda31c40b1530051b068bcc1c15e43340000aa55' '\n----' 1552738632721 'Socket error' { Error: read ECONNRESET at TCP.onStreamRead (internal/stream_base_commons.js:111:27) errno: 'ECONNRESET', code: 'ECONNRESET', syscall: 'read' } 1552738632742 'Socket closed:' true

rshnthmb commented 5 years ago

Hi @AMoo-Miki

Thanks, however I am getting a different result to @gazzmanzx6 :

1552815081168 'Connecting ...' 1552815081249 'Socket connected' 1552815081250 'Socket ready' 1552815082252 'Sending handshake...' 1552815117988 'Socket error' { Error: read ECONNRESET at TCP.onread (net.js:622:25) errno: 'ECONNRESET', code: 'ECONNRESET', syscall: 'read' } 1552815117990 'Socket closed:' true

rshnthmb commented 5 years ago

Hi @AMoo-Miki any updates what this could mean?

HidYn commented 5 years ago

Just to confirm also having the same issues with this brand of Outlet since the Firmware update.

Adding the ip to the device confirm I just get the same disconnections as the others above.

Nuarton commented 5 years ago

Also having this same issue with a Teckin SP23 outlet on firmware 1.0.5. Have tried the new build with a direct IP connection and on both a RasPi Zero & a Mac and still repeatedly get 'Unable to discover...' message. @AMoo-Miki any more ideas/things we can do to test and help get this working?

AMoo-Miki commented 5 years ago

Let's try and send it an encrypted handshake.

Create a folder wherever you like and inside the folder do, npm i node-forge. Create a file name discover.js in the same folder and paste this content in it. Set the correct values for DEVICE_ID, DEVICE_KEY, and IP_ADDRESS. Finally run node discover.js. Let's hope it likes our handshake this time.

const forge = require('node-forge');

const DEVICE_ID = '22551008840d8e8c669b';
const DEVICE_KEY = '20b01df3fb09ce6a';
const IP_ADDRESS = '192.168.0.33';

const net = require('net');
const _socket = net.Socket();
_socket.setKeepAlive(true);
_socket.setNoDelay(true);

const cipher = forge.cipher.createCipher('AES-ECB', DEVICE_KEY);

let sent = false;
const send = () => {
    if (sent) return;
    sent = true;

    console.log(Date.now(), 'Sending handshake...');

    cipher.start({iv: ''});
    cipher.update(forge.util.createBuffer(JSON.stringify({
        gwId: DEVICE_ID,
        devId: DEVICE_ID
    }), 'utf8'));
    cipher.finish();

    const msg = forge.util.encode64(cipher.output.data);
    const hash = forge.md.md5.create().update('data=' + msg + '||lpv=3.3||' + DEVICE_KEY).digest().toHex().toString().toLowerCase().substr(8, 16);

    const payload = Buffer.from('3.3' + hash + msg);

    const prefix = Buffer.from('000055aa000000000000000a', 'hex');
    const suffix = Buffer.from('000000000000aa55', 'hex');
    const len = Buffer.allocUnsafe(4);
    len.writeInt32BE(Buffer.concat([payload, suffix]).length, 0);
    return _socket.write(Buffer.concat([prefix, len, payload, suffix]));
};

_socket.on('connect', () => {
    console.log(Date.now(), 'Socket connected');
    setTimeout(send, 5000);
});

_socket.on('ready', () => {
    console.log(Date.now(), 'Socket ready');
    setTimeout(send, 1000);
});

_socket.on('data', msg => {
    console.log(Date.now(), '>>>>', msg.toString('hex'), '<<<<');
});

_socket.on('error', err => {
    sent = true;
    console.log(Date.now(), 'Socket error', err);
});

_socket.on('close', err => {
    sent = true;
    console.log(Date.now(), 'Socket closed:', err);
});

_socket.on('end', () => {
    sent = true;
    console.log(Date.now(), 'Socket ended');
});

console.log(Date.now(), 'Connecting ...');
_socket.connect(6668, IP_ADDRESS);
Nuarton commented 5 years ago

No luck:

pi@raspberrypi:~/Desktop/TestFIle $ node discover.js 1554747119815 'Connecting ...' 1554747119974 'Socket error' { Error: connect ECONNREFUSED 192.168.0.13:6668 at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1087:14) errno: 'ECONNREFUSED', code: 'ECONNREFUSED', syscall: 'connect', address: '192.168.0.13', port: 6668 } 1554747120026 'Socket closed:' true

gazzmanzx6 commented 5 years ago

No luck here either.

1554748817896 'Connecting ...' 1554748817938 'Socket connected' 1554748817946 'Socket ready' 1554748818951 'Sending handshake...' 1554748855166 'Socket error' { Error: read ECONNRESET at TCP.onStreamRead (internal/stream_base_commons.js:111:27) errno: 'ECONNRESET', code: 'ECONNRESET', syscall: 'read' } 1554748855185 'Socket closed:' true

AMoo-Miki commented 5 years ago

@Nuarton, your connection refused message indicates that someone was already talking to the device. Make sure you kill the Tuya app and halt Homebridge while this test is running.

@gazzmanzx6 that is bad news. I will need to get my hands on one to figure out the communication; I couldn't find one locally but I will keep looking.

SimonTurp commented 5 years ago

I am also having this issue. I hope you are able to figure it out 👍

drheck commented 5 years ago

I have the same issue. And i have seen the same issue exists in the other tuya plugin (https://www.npmjs.com/package/homebridge-tuya). Good luck for finding out. Thank you...

9SL9 commented 5 years ago

@gazzmanzx6 that is bad news. I will need to get my hands on one to figure out the communication; I couldn't find one locally but I will keep looking.

Alternatively we can do some digging for you if you tell us what to look for/provide us some code to test

gazzmanzx6 commented 5 years ago

@9SL9 Alternatively we can do some digging for you if you tell us what to look for/provide us some code to test

Agreed.

sylwester- commented 5 years ago

Any update on this? Just bought 4 plugs today and upgraded the firmware straight away...

michael-c-hoffman commented 5 years ago

I can confirm that this is happening now with new products shipped from amazon. I have 3 original ones (id started with 60077043) new ones (id starts with 00676338). This looks to be a difference in firmware. Utilizing OpenHab2. updated to latest versions of all npm modules. is there a way to possibly downgrade firmware?

sergigracia commented 5 years ago

@AMoo-Miki any news on this? I'm really looking forward to this fix. Let me know if I can do anything to help, debugging, logging, ...

jsalexjs commented 5 years ago

yea a fix for this would be amazing. Again, same if there's anything I can do to help, totally up for it.

AMoo-Miki commented 5 years ago

I need to get my hands on some of these products that use the new API. If you bought them from Amazon US, please give me some ASINs so I can order them.

AMoo-Miki commented 5 years ago

Please give the latest rc release a shot by doing npm i -g homebridge-tuya-lan@rc. It includes logic to understand this newer API.

A known issue is that the current state is not reported by some devices; they however work fine as soon as you interact with them. I have reached out to Tuya for a solution.

The Setup Instructions have changed in case you need to obtain a fresh id and key.

gazzmanzx6 commented 5 years ago

I've tried the latest rc version and it finds the sockets but they don't work. They show in the Home app but do not switch.

AMoo-Miki commented 5 years ago

@gazzmanzx6 It would help to have some log messages. Could you please share some? Specifically, I am looking for anything that happens after you press a button in the Home app and see Sending in the logs. I got my hands on SP10s for testing and I hope SP23 is not very different.

gazzmanzx6 commented 5 years ago

I see the following in the log when trying to switch on the socket: HAPServer [CC:22:3D:E3:CE:30] HAP Request: PUT /characteristics +0ms Accessory [RaspberryPi2] Processing characteristic set: [{"aid":24,"iid":10,"value":1}] +3ms Accessory [RaspberryPi2] Setting Characteristic "On" to value 1 +1ms EventedHTTPServer [::ffff:192.168.2.41] Sending HTTP event '24.10' with data: {"characteristics":[{"aid":24,"iid":10,"value":true}]} +4ms EventedHTTPServer [::ffff:192.168.2.21] Muting event '24.10' notification for this connection since it originated here. +3ms EventedHTTPServer [::ffff:192.168.2.21] HTTP Response is finished +1ms [TuyaAccessory] Socket had a problem and will reconnect to Fairy lights (Error: ERR_PING_TIMED_OUT). This is common for v3.3 devices. [TuyaAccessory] Socket had a problem and will reconnect to Socket 3 (Error: ERR_PING_TIMED_OUT). This is common for v3.3 devices.

AMoo-Miki commented 5 years ago

@gazzmanzx6, Can you please update to the latest rc to get rid of ping timeouts.

I should have mentioned that I wanted to see the [TuyaAccessory] Sending ... messages and whatever happens after it; my bad! All of those Sending HTTP event are homebridge and HAP's own events which won't help us figure things out.

A better way to look at the logs would be tail -f -n 100 LOGFILE | grep Tuya, replacing the log file with the file where the logs are stored. If you are using RPi for your homebridge, sudo journalctl -f -n 200 -u homebridge | grep Tuya would be the way to go.

gazzmanzx6 commented 5 years ago

This is the result from the log file. I tried switching 'Switch 3' but it didn't respond. The socket called 'Fairy lights' just showed as 'No Response'. Sep 07 17:37:31 raspberrypi2 homebridge[20094]: [TuyaAccessory] Sending first query to Fairy lights (3.3) Sep 07 17:37:32 raspberrypi2 homebridge[20094]: [9/7/2019, 5:37:32 PM] [TuyaLan] Discovered Socket 3 (81358500840d8e809929) identified as Outlet (3.3) Sep 07 17:37:32 raspberrypi2 homebridge[20094]: [9/7/2019, 5:37:32 PM] [TuyaLan] Connected to Socket 3 Sep 07 17:37:32 raspberrypi2 homebridge[20094]: [TuyaAccessory] Sending first query to Socket 3 (3.3) Sep 07 17:37:33 raspberrypi2 homebridge[20094]: [TuyaAccessory] Socket had a problem and will reconnect to Socket 3 (ECONNRESET) Sep 07 17:37:33 raspberrypi2 homebridge[20094]: [TuyaAccessory] Sending first query to Socket 3 (3.3) Sep 07 17:37:37 raspberrypi2 homebridge[20094]: [9/7/2019, 5:37:37 PM] [TuyaLan] Ready to handle Socket 3 (Outlet:3.3) with signature {"4":141,"6":2159} Sep 07 17:38:02 raspberrypi2 homebridge[20094]: [TuyaAccessory] Socket had a problem and will reconnect to Fairy lights (Error: ERR_PING_TIMED_OUT) Sep 07 17:38:04 raspberrypi2 homebridge[20094]: [TuyaAccessory] Socket had a problem and will reconnect to Socket 3 (Error: ERR_PING_TIMED_OUT) Sep 07 17:38:07 raspberrypi2 homebridge[20094]: [TuyaAccessory] Sending first query to Fairy lights (3.3) Sep 07 17:38:09 raspberrypi2 homebridge[20094]: [TuyaAccessory] Sending first query to Socket 3 (3.3) Sep 07 17:38:30 raspberrypi2 homebridge[20094]: [TuyaAccessory] Sending Socket 3 {"1":true} Sep 07 17:38:38 raspberrypi2 homebridge[20094]: [TuyaAccessory] Socket had a problem and will reconnect to Fairy lights (Error: ERR_PING_TIMED_OUT) Sep 07 17:38:40 raspberrypi2 homebridge[20094]: [TuyaAccessory] Socket had a problem and will reconnect to Socket 3 (Error: ERR_PING_TIMED_OUT) Sep 07 17:38:43 raspberrypi2 homebridge[20094]: [TuyaAccessory] Sending first query to Fairy lights (3.3) Sep 07 17:38:45 raspberrypi2 homebridge[20094]: [TuyaAccessory] Sending first query to Socket 3 (3.3) Sep 07 17:38:52 raspberrypi2 homebridge[20094]: [TuyaAccessory] Sending Socket 3 {"1":false} Sep 07 17:39:14 raspberrypi2 homebridge[20094]: [TuyaAccessory] Socket had a problem and will reconnect to Fairy lights (Error: ERR_PING_TIMED_OUT) Sep 07 17:39:16 raspberrypi2 homebridge[20094]: [TuyaAccessory] Socket had a problem and will reconnect to Socket 3 (Error: ERR_PING_TIMED_OUT) Sep 07 17:39:19 raspberrypi2 homebridge[20094]: [TuyaAccessory] Sending first query to Fairy lights (3.3) Sep 07 17:39:21 raspberrypi2 homebridge[20094]: [TuyaAccessory] Sending first query to Socket 3 (3.3)

AMoo-Miki commented 5 years ago

Can you plz post the output of this command?

tuya-lan-find -v

Socket 3 is responding with a signature that doesn't seem right.

While monitoring the logs, manually switch the socket on and off with the button on the device itself. See if you see any messages in the log at exactly the same time.

gazzmanzx6 commented 5 years ago

tuya-lan-find -v gives: v1.5.0-rc.7

Switching the socket manually doesn't show and messages in the log. I switched it multiple times during the period shown. Sep 08 10:03:12 raspberrypi2 homebridge[15272]: [TuyaAccessory] Sending first query to Socket 3 (3.3) Sep 08 10:03:43 raspberrypi2 homebridge[15272]: [TuyaAccessory] Socket had a problem and will reconnect to Fairy lights (Error: ERR_PING_TIMED_OUT) Sep 08 10:03:43 raspberrypi2 homebridge[15272]: [TuyaAccessory] Socket had a problem and will reconnect to Socket 3 (Error: ERR_PING_TIMED_OUT) Sep 08 10:03:48 raspberrypi2 homebridge[15272]: [TuyaAccessory] Sending first query to Fairy lights (3.3) Sep 08 10:03:48 raspberrypi2 homebridge[15272]: [TuyaAccessory] Sending first query to Socket 3 (3.3) Sep 08 10:03:55 raspberrypi2 homebridge[15272]: [9/8/2019, 10:03:55 AM] [TuyaLan] Ready to handle Socket 3 (Outlet:3.3) with signature {"1":true,"2":0} Sep 08 10:04:19 raspberrypi2 homebridge[15272]: [TuyaAccessory] Socket had a problem and will reconnect to Fairy lights (Error: ERR_PING_TIMED_OUT) Sep 08 10:04:19 raspberrypi2 homebridge[15272]: [TuyaAccessory] Socket had a problem and will reconnect to Socket 3 (Error: ERR_PING_TIMED_OUT) Sep 08 10:04:24 raspberrypi2 homebridge[15272]: [TuyaAccessory] Sending first query to Fairy lights (3.3) Sep 08 10:04:24 raspberrypi2 homebridge[15272]: [TuyaAccessory] Sending first query to Socket 3 (3.3) Sep 08 10:04:55 raspberrypi2 homebridge[15272]: [TuyaAccessory] Socket had a problem and will reconnect to Fairy lights (Error: ERR_PING_TIMED_OUT) Sep 08 10:04:55 raspberrypi2 homebridge[15272]: [TuyaAccessory] Socket had a problem and will reconnect to Socket 3 (Error: ERR_PING_TIMED_OUT)

AMoo-Miki commented 5 years ago

Socket 3 is now returning a signature which is right.

The latest rc fixes a bug with the "pinger"; please update with npm i -g homebridge-tuya-lan@rc. After you update:

  1. look for Ready to handle Socket 3 (Outlet:3.3) with signature {"1":true,"2":0}. That is a good sign.
  2. try switching the device on or off manually and look for anything interesting in the logs.

PS, do you have a Mac handy?

gazzmanzx6 commented 5 years ago

Good news, it seems to work now. Sep 09 20:02:36 raspberrypi2 homebridge[7275]: [TuyaAccessory] Heard back from Socket 3 with command 8 Sep 09 20:02:38 raspberrypi2 homebridge[7275]: [TuyaAccessory] Heard back from Socket 3 with command 8 Sep 09 20:02:43 raspberrypi2 homebridge[7275]: [TuyaAccessory] Heard back from Socket 3 with command 8 Sep 09 20:03:23 raspberrypi2 homebridge[7275]: [TuyaAccessory] Sending Socket 3 {"1":false} Sep 09 20:03:23 raspberrypi2 homebridge[7275]: [TuyaAccessory] Heard back from Socket 3 with command 8 Sep 09 20:03:26 raspberrypi2 homebridge[7275]: [TuyaAccessory] Sending Socket 3 {"1":true} Sep 09 20:03:26 raspberrypi2 homebridge[7275]: [TuyaAccessory] Heard back from Socket 3 with command 8

I do have a Mac or 3!

AMoo-Miki commented 5 years ago

That is great news. Lemme know if you ever need anything more.

PS, we would have used the Mac to sniff the device if it hadn't worked; fortunately we need not.

gazzmanzx6 commented 5 years ago

@AMoo-Miki Thanks for all your work on this. It is much appreciated. 👍

codyc1515 commented 5 years ago

Thank you. This worked for me! :)