-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failed to discover curtain device #84
Comments
If you aren't sure which IP belongs to which
Look for 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 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) 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. |
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 |
Allow sending empty update commands after dp-update #84 Add sequence to decode Add decoding empty post-dp-update command
After you look at the 3 questions above, please
Lemme know if this helps. |
Hi Miki, the data I sent you was already generated without ip-addresses in the config file. |
Let's see if we can figure why discovery is failing. I put in some extra logging during discovery. Please update with Please post everything you see that starts with |
Installed it and wiresharked once more but searching for string tuyadiscovery results in nothing |
The logs won't appear in Wireshark. Remember you were seeing |
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 ```
|
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 #5 (comment) |
What troubles me is that between Add 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 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. Failed to discover Rollladen (0402268384f3ebe9d67d) in time but will keep looking.�[39m |
Do you have anything before |
........�[37m[9/20/2019, 8:04:19 AM]�[39m �[36m[TuyaLan]�[39m Marked Rollladen unreachable by faulting Service.Rollladen.Target Position.........� |
Can you please do |
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 |
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? |
[TuyaAccessory] Discovery started on 6666. |
I think |
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 |
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
|
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 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. |
Can please you add two rows with container ports as 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 [](https://github.com//issues/53) 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 Or, launching the container with 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
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).
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 |
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? |
Are you 100% sure that this is a network issue? In this thread we have a device that is discovered whereas at the same time another isn't with ECONNRESET URL |
Wait... now I am confused; you have a garage opener that works with this plugin? Do you know if it uses API v3.1 or v3.3? |
No, but if you click on the link I‘ve provided you‘ll see that fergburg has one device that‘s working whilst the other fails with the same error messages that I encounter. Also, do you know anybody who has these curtain devices working with TuyaLAN? |
Meanwhile I've purchased a smart socket and am also getting the same error for this device. So now it's clear that this is a weird problem within my network which seems only to have an effect on TuyaLAN :-( |
.....and the weirdness goes on: Plugging the Synology into another switch didn't change anything so I've installed homebridge on my macbook and it also gives me the "failed to discover error." for all devices. I really would like to know if anyone has these curtain devices respectively the outlet that I have successfully working with TuyaLAN |
@fraho67, I know a long time has passed since we last spoke; it took me a while to get my stuff sorted out to return home! ... but if you are still using homebridge on your macbook, please write back so we can figure this thing out. |
Hi Miki, glad to have you back, hope you're doing well - yes, I'm still using homebridge, but not on my Macbook - I just used that for testing purposes to see if the error occurs there too, which it does. I'm still using Homebridge with a Synology and we had no idea why it fails to discover my four devices. You suspected that there's something wrong inside my network but I'm having no other problems with it besides that.
Gesendet: Dienstag, 04. Februar 2020 um 03:46 Uhr
Von: "Miki" <notifications@github.com>
An: AMoo-Miki/homebridge-tuya-lan <homebridge-tuya-lan@noreply.github.com>
Cc: fraho67 <frank.hoffmann@gmx.com>, Mention <mention@noreply.github.com>
Betreff: Re: [AMoo-Miki/homebridge-tuya-lan] Failed to discover curtain device (#84)
@fraho67, I know a long time has passed since we last spoke; it took me a while to get my stuff sorted out to return home! ... but if you are still using homebridge on your macbook, please write back so we can figure this thing out.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
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.
The text was updated successfully, but these errors were encountered: