TPlink Discovery on wrong interface

Hi, trying to add HS110 (v1) hardware on a different subnet, and the plugin doesn’t discover them.

For setup I add a wireless network card on the same SSID as the HS110, but with a tcpdump I see the broadcast on port 9999 going out the wired NIC only , and not the wireless NIC, so discovery fails.

I can temporarily move them onto the same network as the wired NIC , then they are discovered, but obviously when I move them back , connection fails. Is there a method to change their IP , I assume it’s in things.conf as part of the Params of the device, though I don’t understand how to decode these parameters to change the ip.

it’s strange though that the discovery is only sent through the wired interface, as the code doesn’t specify any interface, which should cause it to be sent over all of them… The one thing I could think of though is that it opens the socket upon startup, which probably means it doesn’t deal very well with on the fly changing network interfaces… Did you restart nymead after adding the second NIC?

I tried restarting nymea after interface changes , no change

Looks like it’s a Linux thing, linux - UDP-Broadcast on all interfaces - Stack Overflow

I shutdown the Ethernet so only the WiFi Nic was up, and it then sent the broadcast out that interface and discovered the sockets ok

It would be easier if for this (and the Shelly plugins) I could add by ip as an option. Wrt Shelly , I have a 1 pm plus in a remote location to add so it’s discovery is going to be problematic too (although not a broadcast problem)

I mapped the wifi network through as a vlan to the server, the new vlan interface is the now the one getting the broadcasts, so it discovers the hs110’s fine. It would still be nice to be able to use a static IP as I have one in a remote location.

Now that it’s detected the HS110’s it keeps showing them as online/offline , these are v1 hardware and latest firmware, so could be a slight difference in the response. The logs show this repeated every second.

I | Tplink: Connecting to QHostAddress(“::ffff:X.X.X.X”)
I | Tplink: Connected to device “xxxxxx” at address: QHostAddress(“::ffff:X.X.X.X”)
I | Tplink: Has childs: 2
I | Tplink: Fetching device state
I | Tplink: Socket data received {
“emeter”: {
“get_realtime”: {
“current”: 0.515811,
“err_code”: 0,
“power”: 116.14269,
“total”: 7.635,
“voltage”: 229.117699
“system”: {
“get_sysinfo”: {
“active_mode”: “schedule”,
“alias”: “xxxxxx”,
“dev_name”: “Wi-Fi Smart Plug With Energy Monitoring”,
“deviceId”: “800660BAFB5075E7907A045030481AXXXXXXXXXX”,
“err_code”: 0,
“feature”: “TIM:ENE”,
“fwId”: “00000000000000000000000000000000”,
“hwId”: “2448AB56FB7E126DE5CF87XXXXXXXXXX”,
“hw_ver”: “1.0”,
“icon_hash”: “”,
“latitude”: 53.272112,
“led_off”: 0,
“longitude”: -6.343915,
“mac”: “50:C7:BF:5B:28:93”,
“model”: “HS110(UK)”,
“oemId”: “90AEEA7AECBF1A879FCA3C104C58C4D8”,
“on_time”: 271520,
“relay_state”: 1,
“rssi”: -74,
“sw_ver”: “1.2.6 Build 200727 Rel.121408”,
“updating”: 0

W | Tplink: Error in device connection: QAbstractSocket::RemoteHostClosedError
I | Tplink: Device disconnected

Right… I remember that the V1 had that issue… It closes the connection all the time, no idea why. Maybe it requires a certain call or something.I had one of those here at some point and remember seeing that issue but as the V1 already wasn’t sold any more at that point I didn’t spend the time to investigate and eventually threw it out… Perhaps if you can find some other open source library/tool which works properly with it we can try to figure out what’s happening…

Looking at a few projects, they all seem to connect and issue a command, so the disconnect doesn’t seem a problem. it looks like v1 hardware does a server side close on each command, and the current code is setup for a persistent connection,