Closed z571 closed 2 years ago
Hi @z571, Can you see if the new v3.1.0 version of tplink-smarthome-api still has this issue? The discovery process was changed as it was causing certain devices to reset when they received the discovery command. Not sure if it would help in your case. Also a new option has been added to the CLI, --broadcast
, you can override the default address of '255.255.255.255'
with one more specific to your network. For example: tplink-smarthome-api search --broadcast 192.168.0.255
If a more specific broadcast address works for you, you can set the configuration option in the homebridge plugin.
The discovery process sends out a command via UDP Broadcast and waits for responses from the devices. The issue could be a firewire rule on your router/switch or local device (although it would be odd that only some work if this was the cause), also some users have said rebooting their router or changing some router settings fixes their issues.
I ran into an issue with homebridge recently losing connection to a few HS103 plugs, so I did some investigation. I found that the discovery search results are different on different devices.
Here are some results from my homebridge on a Raspberry Pi Zero W running homebridge-raspbian.
And running the same command on my Macbook Pro:
And again the same on an older iMac I have at home:
I did some preliminary troubleshooting like factory reseting all the devices, restarting the router and unplugging the rPi and the amp plug switches, removing them from my network but the homebridge OS never sees the lamps anymore. Another search on the homebridge returned an empty result, while the other devices still showed the lamps. The only apparent difference is the
sendDiscovery
happens on a different port.