Closed gazzmanzx6 closed 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.
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.
Yeah. Tried that and it made no difference.
Another one here with the same problem. Any solution please?
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
That sucks, sounds like it is something in the firmware that broke it.
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.
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
@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.
@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.
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!
Hi @AMoo-Miki
Here is my result:
Nmap scan report for 192.168.0.33 PORT STATE SERVICE 49154/udp open|filtered unknown
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.
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
:( 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.
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.
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);
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
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
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
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
Hi @AMoo-Miki any updates what this could mean?
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.
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?
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);
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
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
@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.
I am also having this issue. I hope you are able to figure it out 👍
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...
@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
@9SL9 Alternatively we can do some digging for you if you tell us what to look for/provide us some code to test
Agreed.
Any update on this? Just bought 4 plugs today and upgraded the firmware straight away...
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?
@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, ...
yea a fix for this would be amazing. Again, same if there's anything I can do to help, totally up for it.
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.
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
.
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.
@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.
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.
@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.
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)
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.
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)
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:
Ready to handle Socket 3 (Outlet:3.3) with signature {"1":true,"2":0}
. That is a good sign.PS, do you have a Mac handy?
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!
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.
@AMoo-Miki Thanks for all your work on this. It is much appreciated. 👍
Thank you. This worked for me! :)
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?