Failed to discover curtain device

[fraho67]

Currently I'm on version v1.5.0-rc.11. As I've extracted three keys for the three curtain devices and wasn't 100% sure which key belongs to which DevID I did a step-by-step test by giving one of the devices each of the keys but it always ends up with "Failed to discover device......" then it says "Connected to %devicename% "respectively [TuyaAccessory] Socket had a problem and will reconnect to %devicename% (Error: ERR_PING_TIMED_OUT) when using the ip-address in the device block. To ensure that no app is blocking the TuyaLAN connection attempts I shut down my iPhone.

[AMoo-Miki]

If you aren't sure which IP belongs to which id and key, let's try a different strategy.

1. Update the plugin with npm i -g AMoo-Miki/homebridge-tuya-lan
2. Edit the device configs, removing all the IPs and change the id to something else; change the last character to 0.
3. Restart Homebridge and monitor the logs.

Look for Discovered a device that has not been configured yet which will include IP and id. If you see that, the solution is easy.

If you don't see any of them, remove all the devices but keep only one. Then, try each of the IPs you have on it to see if it connects and keeps the connection.

---

If you are sure that you have the correct IPs:

Add "pingTimeout": 3600 to each device; this will prevent the ping from timing out, allowing us time to figure the root cause of the problem.

---

Do you have a Mac?

[fraho67]

Yes I have a Mac. I'm sure about the IPs because I can see the corresponding MAC-Addresses on my router respectively in the Tuya app (which shows me ip-addresses in the WAN for each device, not the internal ip by the way). I'm just not 100% sure about the localkeys. I meanwhile also deleted all files in the persist and accessories folder in homebridge but that did change nothing. So I will add the pingTimeout to each device(?)

I did that and now it's looping in "Socket had a problem and will reconnect to %devicename% (ECONNRESET) [TuyaAccessory] Closed connection with %devicename%" (for each device)

One more thing that I noticed: It's always logging this twice for each device. Is that normal?

[fraho67]

I've now tried it with only one device and all three keys - the error message stays the same.

[AMoo-Miki]

Logging two entries, one for the error and another for closing is expected.

Since you have a Mac, it would be easy to debug what's going on. Follow these instructions to see how the Tuya Smart app is communicating with the curtains.

If you trust me enough, you can send me the files and the key to decode manually. I am also in the process of adding the capability to the plugin to decode these on your end so you don't have to send me anything in the mail; I will try and finish that piece today. If you choose to wait, at least get done till before step 24 to save time.

[fraho67]

O.k., I'll give it a try but first have to install xcode for running rvictl. I guess it's important to do the sniffering inside the network where the curtain devices are located(?)

[fraho67]

I meanwhile tested that outside my own network but it seems that the first thing the Tuya app is always trying to do is to resolve m1.tuyaeu.com / a1.tuayeu.com. (which doesn't of course work because of the DNS-settings). Setting the wireshark filters to internal IPs or external IPs of my Tuya devices results in nothing. So I think I have to repeat the steps when I'm at home

[AMoo-Miki]

You are right; you would need to have it run locally so we get the packets that it uses to talk to the particular device.

[fraho67]

Now I've done all the steps again locally but none of the internal IPs from any of the three devices can be found within trace.pcap. What else could I try to filter which gives a hint to what's wrong here?

Edit: When searching for a string (not a display filter) with one of the ip-addresses I'm finding a lot entries referencing these (AR protocol). So shall I mail you the whole file?

[fraho67]

Tried it once more and now however I could also filter out tcp and udp entries for the corresponding ip address and save it in two files. I will sent them to your email-address as well as the key(s)

[AMoo-Miki]

I got the files and decoded them; thanks for sending them. I am a bit puzzled though about the packets.

Can you help me with a few things:

1. If you remove the IP and wait for 5 minutes, do the devices get discovered?
2. In Wireshark, was the UDP port anything other than 6667?
3. In Wireshark, was the TCP port anything other than 6668?

The odd thing I see is that after every set command, an empty command is also sent. I am making changes to allow us to do the same. It would be great to know the answers to the above questions before I wrap up.

[AMoo-Miki]

After you look at the 3 questions above, please

1. update to the latest unreleased code with npm i -g AMoo-Miki/homebridge-tuya-lan
2. add these to your config

   "cmdOpen": "on",
   "cmdClose": "off",
   "cmdStop": "stop",
   "sendEmptyUpdate": true

   The first 3 are specific to your device. The last one is to have an empty update command sent after any set communication.

3. restart Homebridge

Lemme know if this helps.

[fraho67]

Hi Miki,

the data I sent you was already generated without ip-addresses in the config file. Entries in the wireshark logfile concerning the ip-Addresses of the devices as source or destination - the ports were always 6667 (udp) and 6668 (tcp). I just installed the version from above, added the parameters and restarted without (visible) effect: "Failed to discover .......in time but will keep looking"

[AMoo-Miki]

Let's see if we can figure why discovery is failing. I put in some extra logging during discovery. Please update with npm i -g AMoo-Miki/homebridge-tuya-lan and restart Homebridge.

Please post everything you see that starts with [TuyaDiscovery] UDP from or [TuyaDiscovery] ERROR: UDP from that contains the IP of your device.

[fraho67]

Installed it and wiresharked once more but searching for string tuyadiscovery results in nothing Homebridge logifile looks also the same (Failed to discover....), no additional Info

[AMoo-Miki]

The logs won't appear in Wireshark. Remember you were seeing Socket had a problem and will reconnect? Those are the logs.

[fraho67]

I know, that became clear to me when I thought about it for a second after the first try with wireshark. But as I wrote, there was also no additional info in the TuyaLAN logs, just failed to discover....so now I've re-added the ip-parameter for one of the devices in the config-file but there is also no additional info, it's looping in ``` [TuyaLan] Failed to discover Rollladen (0402268384f3ebe9d67d) in time but will keep looking. [9/19/2019, 5:30:03 AM] [TuyaLan] Connected to Rollladen [9/19/2019, 5:30:03 AM] [TuyaLan] Connected to Rollladen [TuyaAccessory] Socket had a problem and will reconnect to Rollladen (Error: ERR_PING_TIMED_OUT) [TuyaAccessory] Closed connection with Rollladen [TuyaAccessory] Socket had a problem and will reconnect to Rollladen (Error: ERR_PING_TIMED_OUT) [TuyaAccessory] Closed connection with Rollladen [TuyaAccessory] Socket had a problem and will reconnect to Rollladen (Error: ERR_PING_TIMED_OUT) [TuyaAccessory] Closed connection with Rollladen [TuyaAccessory] Socket had a problem and will reconnect to Rollladen (Error: ERR_PING_TIMED_OUT) [TuyaAccessory] Closed connection with Rollladen

[fraho67]

[TuyaLan] Marked Rollladen unreachable by faulting Service.Rollladen.Target Position

is something that is before "failed to connect..." in the logfile (but not in the homebridge protocol) for every of the three devices. What does that mean?

Found your answer here https://github.com/AMoo-Miki/homebridge-tuya-lan/issues/5#issuecomment-453819944

[AMoo-Miki]

What troubles me is that between Connected and ping timeout there is nothing else; there should have been a Sending first query there.

Add "pingTimeout": 3600 to your config; this will not ping the device for an hour.

Another thing that troubles me is that the device is clearly advertising. Why is it still not being discovered? There should be a few lines from TuyaDiscovery before Failed to discover. Not having them is also troubling.

What machine are you running Homebridge on? Is it possible that a firewall is interfering with us?

Also, can you share a link to the product; I might be able to buy one if its available locally.

[fraho67]

Hi Miki, it's a Synology NAS and the firewall is turned off. Here's what's been logged with ip and pingtimeout parameters

Failed to discover Rollladen (0402268384f3ebe9d67d) in time but will keep looking. [9/20/2019, 8:05:19 AM] [TuyaLan] Connected to Rollladen [TuyaAccessory] Socket had a problem and will reconnect to Rollladen (ECONNRESET) [TuyaAccessory] Closed connection with Rollladen I have no idea why there is absolutely nothing from TuyaDiscovery, probably because "Socket had a problem"(?) But I have no idea why. The device is this one https://www.amazon.de/gp/product/B07PS5LRPQ/ref=ppx_yo_dt_b_asin_title_o08_s00?ie=UTF8&psc=1

[AMoo-Miki]

Do you have anything before Failed to discover?

[fraho67]

........[9/20/2019, 8:04:19 AM] [TuyaLan] Marked Rollladen unreachable by faulting Service.Rollladen.Target Position......... [9/20/2019, 8:04:19 AM] [TuyaLan] Starting discovery...

[AMoo-Miki]

Can you please do npm i -g AMoo-Miki/homebridge-tuya-lan, restart homebridge, and see if anything new shows up between Starting discovery and Failed to discover.

[fraho67]

Did that (once more :-)) - nothing else between Discovery started and Failed to discover

[AMoo-Miki]

This is simply crazy. Do you have a smart TV or any other smart devices?

Gimme 10 mins to cook a script up.

[fraho67]

I have AVM Thermostats which work fine in homebridge and Lifx bulbs which support Homekit natively (and are also working fine). I also have a Smart TV from Philips and Sonos speakers

[AMoo-Miki]

1. Download this file onto your NAS and rename it to discover.js.
2. Stop Homebridge.
3. Open the terminal and navigate to the folder the file is placed.
4. Run it with node discover.

Lemme know if you have trouble with any of those steps or don't know how to do any.

Do you see IP addresses and other data? Do you see the IP of your device? discover.txt

[fraho67]

Renamed the file, copied it to the NAS, opened a SSH session, went to the directory where the file resides and executed "node discover" -> command not found

[AMoo-Miki]

How are you running Homebridge? Did you by chance install node somewhere specific?

[fraho67]

No, hadn't installed it at all :-) Now that it's installed the result is: module.js:540 throw err; ^

Error: Cannot find module 'node-forge' at Function.Module._resolveFilename (module.js:538:15) at Function.Module._load (module.js:468:25) at Module.require (module.js:587:17) at require (internal/module.js:11:18) at Object. (/volume1/downloads/discover.js:1:77) at Module._compile (module.js:643:30) at Object.Module._extensions..js (module.js:654:10) at Module.load (module.js:556:32) at tryModuleLoad (module.js:499:12) at Function.Module._load (module.js:491:3)

[AMoo-Miki]

hmm, how was Homebridge running without Node?

I forgot to remove the first line. Can you please open the file and get rid of the first line that has forge in it? Lemme know if you need help figuring out how to edit the file.

[fraho67]

[TuyaAccessory] Discovery started on 6666. [TuyaAccessory] Discovery started on 6667. 192.168.0.113:6667 {"ip":"192.168.0.113","gwId":"0402268384f3ebea974a","active":2,"ability":0,"mode":0,"encrypt":true,"productKey":"key5seknqafuq9un","version":"3.3"}......and so on

[AMoo-Miki]

~Is that the IP of your device? Is that the id of your device?~

I think 0402268384f3ebe9d67d is what we are looking for. Is that there?

[fraho67]

The deviceID we are looking for should be 0402268384f3ebea974a - 0402268384f3ebe9d67d is also there but belongs to one of the other two devices

[fraho67]

I see all of the three device IDs

[AMoo-Miki]

Great. How do you run Homebridge?

[fraho67]

I've installed it via this package https://github.com/oznu/homebridge-syno-spk

[AMoo-Miki]

I have a theory; gimme a few mins to think about it.

[fraho67]

So now that I've installed a dedicated version of node it's no more working. Is that also the reason for the problems with TuyaLAN?

[AMoo-Miki]

That package must have its own node setup. Backup your homebridge config file and then reinstall that package; that should get it to work again by overwriting the node you installed.

[fraho67]

Yes, but that will not be the solution for the actual problem......

[AMoo-Miki]

No, I am reading on that package to figure if my theory is valid or not.

"A" solution would be to install Homebridge and NodeJS and forgo that package. You won't have an interface on your NAS admin, but you probably don't need that UI. Lemme know if that's something you are okay with.

Gimme a few mins to test something.

[AMoo-Miki]

Can you reinstall that package so we can test with it?

My theory is that the UDP packets are not being passed into the docker container that is running Homebridge. Checking to see how we can work around that.

From https://runnable.com/docker/binding-docker-ports

Docker containers can connect to the outside world without further configuration, but the outside world cannot connect to Docker containers by default.

[fraho67]

Yes, the problem currently is, that I am not at home and connected via VPN. I could reinstall the package but cannot install any plugins this way. This maybe is also a symptom of what you linked above. So I can continue in a few hours at the earliest.

[AMoo-Miki]

Cool.

One way to punch a hole (create a bridge actually) is to pass -p6666:6666/udp -p6667:6667/udp to the docker run.

The other way might be via the settings; I see Port Settings shown on a picture here.

PS, don't uninstall that one; just install over it. That might save you from reinstalling the plugins.

[fraho67]

It seems I have a bigger problem now. Although I am now within my network homebridge ui is in status stopped and I can no more install any plugin. I uninstalled, deleted and reinstalled everything including docker but I'm stuck with this now :-(

Edit: This was weird, it was a problem with the (Chrome) Browser, had to quit and relaunch, now the bridge is displayed again as running with the same plugins and status.

[fraho67]

These are the port setting in the docker run - what shall I add here?

[AMoo-Miki]

Can please you add two rows with container ports as 6666 and 6667, both UDP, and see if you have any new stuff under in the log for TuyaDiscovery after restarting Homebridge?

PS, I am glad it wasn't anything bigger than Chrome's cache.

[fraho67]

Tried it this way but no changes in the log. However, in principle TuyaLAN should work inside Synology/docker without any additional Port-settings Question: If the node version inside Homebridge UI would be the wrong one, would TuyaLAN then work at all? One more question: What would be the error message if something was wrong with the key?

[AMoo-Miki]

The "discovery" component opens 2 UDP ports to listen for messages being broadcasted by others on those two ports. Since the plugin is loaded by Homebridge and Homebridge is run inside a docker container, docker will need to be informed to "expose" those 2 ports for incoming packets. Else, with no way to hear from outside, the plugin won't be able to discover the existence of others.

One way is to inform the container that we "expose" a certain port; the instruction is called EXPOSE and launching the container with the -P switch would automatically map the ports.

Or, launching the container with -p <outer-port>:<inner-port>, maps the external port to an internal one; we would want to use -p 6666:6666 -p 6667:6667.

I am hoping that the interface in the screenshots actually does that; please change the "automatic" on the left column to match the port numbers and see if it works or not.

If it doesn't, we either need to find a way to modify the container's "Dockerfile" or just run Homebridge and node outside docker (which is super easy since you already know how to install node).

If the node version inside Homebridge UI would be the wrong one, would TuyaLAN then work at all?

The native modules I am using have been available for ages, perhaps as early as v0.11. I don't believe the version of node inside the docker image is that old at all given how often they have updated that image (2 weeks ago).

What would be the error message if something was wrong with the key?

The key is only used for decrypting the messages from the device and sending commands to it. If the key is wrong, the plugin will fail to decrypt incoming messages and will show you Odd message from ... or Malformed message from ....

[fraho67]

Adding the ports on both sides doesn't make any difference as well. Node version is 10.16.3. So far I haven't found info of how to run homebridge on a Synology outside docker. Why does it work for the garage opener with homebridge inside docker? The UDP Ports are always the same, aren't they?