Open fraho67 opened 5 years ago
If you aren't sure which IP belongs to which id
and key
, let's try a different strategy.
npm i -g AMoo-Miki/homebridge-tuya-lan
id
to something else; change the last character to 0
.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?
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?
I've now tried it with only one device and all three keys - the error message stays the same.
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.
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(?)
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
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.
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?
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)
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:
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.
After you look at the 3 questions above, please
npm i -g AMoo-Miki/homebridge-tuya-lan
"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.
Lemme know if this helps.
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"
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.
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
The logs won't appear in Wireshark. Remember you were seeing Socket had a problem and will reconnect
? Those are the logs.
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
[TuyaLan][39m 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
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.
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.[39m [37m[9/20/2019, 8:05:19 AM][39m [36m[TuyaLan][39m 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
Do you have anything before Failed to discover
?
........[37m[9/20/2019, 8:04:19 AM][39m [36m[TuyaLan][39m Marked Rollladen unreachable by faulting Service.Rollladen.Target Position......... [37m[9/20/2019, 8:04:19 AM][39m [36m[TuyaLan][39m Starting discovery...
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
.
Did that (once more :-)) - nothing else between Discovery started and Failed to discover
This is simply crazy. Do you have a smart TV or any other smart devices?
Gimme 10 mins to cook a script up.
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
discover.js
.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
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
How are you running Homebridge? Did you by chance install node
somewhere specific?
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.
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.
[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
~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?
The deviceID we are looking for should be 0402268384f3ebea974a - 0402268384f3ebe9d67d is also there but belongs to one of the other two devices
I see all of the three device IDs
Great. How do you run Homebridge?
I've installed it via this package https://github.com/oznu/homebridge-syno-spk
I have a theory; gimme a few mins to think about it.
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?
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.
Yes, but that will not be the solution for the actual problem......
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.
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.
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.
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.
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.
These are the port setting in the docker run - what shall I add here?
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.
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?
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 ...
.
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?
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.