I've written some code to make iDetect work with the TP-link Omada WiFi controller. I've successfully tested it against Omada version 3.2.6 on Linux.
Note that although newly connected devices are detected quickly, devices that disconnect from WiFi remain up to 5 minutes in the Omada clients table for some reason. This is an Omada thing and I haven't found a solution for it yet.
I hope the code is useful
Regards,
Erik
Thanks Erik!
I merged your contribution on GitHub.
So I increased time-out to 10 secs. And now I get only about 2 time-out errors per day (was 30). So this helps. I have about 45 devices in my LAN, and the Orbi does some other stuff (see my previous posts). Apparently this makes the Orbi rather slow in generating the device list. I will soon lower the polling frequency a bit to stress the Orbi less.
For now it works. Maybe someone else can help in future with a better solution. I know Orbi is Linux based, Telnet can be enabled, and even a SSH server can be installed by a hack. This can probably deliver a more time-efficient way to request devices from router. However I want to keep my router secure...
EscApe wrote: ↑Thursday 16 April 2020 7:01
Could you try increasing the hard coded timeout in the plugin code? It's on line 20 of http_orbi.py (but I guess you already knew that;-))
If a longer timeout solves this issue, then it still might not be the best solution to permanently increase it. A lot of waiting connections could cause Domoticz to hang when trying to stop the plugin.
Domoticz beta, on Raspberry Pi 3B, Raspian Buster
Zwave, Zigate, RFlink etc.
Thanks for your hard work in this, it works fine but there is one issue. First I'm on a RPI3 B, latest Domoticz beta, Asus RT-AC86U Merlin and it's shares it's data with the main Domoticz machine that is also running on a pi. All of the other sensors and devices on the pi with iDetect share their data to the main one without a problem, except iDetect devices.
dpcreel wrote: ↑Saturday 16 May 2020 21:06
Thanks for your hard work in this, it works fine but there is one issue. First I'm on a RPI3 B, latest Domoticz beta, Asus RT-AC86U Merlin and it's shares it's data with the main Domoticz machine that is also running on a pi. All of the other sensors and devices on the pi with iDetect share their data to the main one without a problem, except iDetect devices.
Any idea what's wrong?
Sorry, no idea... I had a look at the plugin system documentation and can't find anything specific on sharing devices between Domoticz instances. The 'presence' switches are created as simple on/off switches with custom icons. Nothing special about that.
Seems unlikely, but maybe it is a limitation/bug in the python plugin system for Domoticz(?) Did you try sharing devices from other python plugins?
What I did to make it work was create dummy or virtual switches (one for each iDetect device)and used dzvents to activate the dummy switch when there was a change in an associated iDetect device. I then shared the newly created dummy switches with the main RPI which worked fine.
Thanks again for your hard work in this. One thought, could you also use bluetooth to check if a device is near or arping. I do know that my android phone does not respond to arping reliability well.
What I did to make it work was create dummy or virtual switches (one for each iDetect device)and used dzvents to activate the dummy switch when there was a change in an associated iDetect device. I then shared the newly created dummy switches with the main RPI which worked fine.
Thanks again for your hard work in this. One thought, could you also use bluetooth to check if a device is near or arping. I do know that my android phone does not respond to arping reliability well.
Great find! So, a plugin framework issue after all. At least you found a work-around.
Bluetooth or arping could be great additions to the available trackers. The plugin is designed to be framework for all sorts of presence detection, but someone has te write a tracker for Bluetooth and/or arping. I might pick up the Bluetooth implementation when I have to much time te spare, but I wasn't planning to any time soon. Maybe someone else wants to pick up the challenge?
Strange... you could try a custom ssh command as a workaround (as described in the readme). Set your tracker config on the plugin configuration page to:
This skips the auto-detection of router capabilities. If it still doesn't work then the entire ssh connection is not working as expected. You could then try to upgrade paramiko, python etc..
I was in doubt if I may reply on this topic or should have started a new one.
My Domoticz log shows a constant error on iDetect. For the past years all was working fine (before the last Domoticz update/reinstallation issue) but now:
It looks like your routers has a different brctl command syntax. Maybe it does not have a standard linux/busybox based router operating system? If you can figure out the correct syntax (or completely different command) for your router than it can be added to the plugin as a new tracker type (requires some programming and please provide a pull request on GitHub). The readme and examples are available on GitHub.
An easier way is to just put the command you found in the configuration of the plugin like:
ESFnl wrote: ↑Wednesday 28 October 2020 19:15
Thank you for your suggestions!
What i do not understand is that everything was working fine but after a new installation it doesn't. I did not change anything on my router.
I have a TP-Link Archer C7 v2 and running OpenWrt by LuCI (Chaos Calmer 15.05.1) on it.
Do you know what file I've to edit?
I don't know what changed. I also don't know why the plugin is using brctl in the first place. I think one of the chipset-specific commands should work with openwrt on an atheros chipset based router. A full debug log might shed some light on that.
You can also just experiment using ssh on the router and if you find a working command use that in the plugin configuration. No need to edit files in that case.
Maybe the iDetect wasn't working for a longer period of time. But because everything in the house was working fine, I didn't check the log for a long time. Maybe it has something to do with the update of iDetect. Currently it's v2 maybe I had v1 before.
I found a switch 'debug mode'. This showed a lot more info (although I don't speak this language):
From what I can find online I would expect the Archer C7 v2 running openwrt to have the iwinfo command, but the plugin can't find it. Even arp does not seem te be available. Maybe this openwrt version had been heavily modified(?)
Without acces to the router there is not much I can do. You will have to google and experiment to find a command and syntax that is working for your router. Have you tried running the brctl command from the router command line? That could be a starting point to at least find a working syntax for that.
You could also look for the chipset specific tools on the router. Maybe there is something unusual going on paths(?)
If you try this on your router cli the resulting error messages might help you find a working syntax:
The OpenWrt is original (as a newbe, I was glad I managed it a few years ago ).
By help of this forum https://forum.archive.openwrt.org/viewt ... p?id=42551
I came a bit closer I believe.
0. ssh into router
1. Update opkg: opkg update
2. Remove the symbolic link to busybox: rm /usr/sbin/brctl
3. Install the bridge package: opkg install bridge
Now my brctl and showmac errors in the domoticz log are replaced by:
2020-11-01 22:52:37.654 Error: (iDetect) 192.168.0.1 ====> SSH returned error:read of forward table failed: No such device
2020-11-01 22:52:37.654
2020-11-01 22:52:52.684 Error: (iDetect) 192.168.0.1 ====> SSH returned error:read of forward table failed: No such device
2020-11-01 22:52:52.684
2020-11-01 22:53:07.715 Error: (iDetect) 192.168.0.1 ====> SSH returned error:read of forward table failed: No such device
2020-11-01 22:53:07.715
You might be better of looking for help on the right command in a forum dedicated to your router/firmware. Experts on your router firmware can probably even help you to find a chipset specific command (better than brctl). Search for things like 'assoclist archer c7 openwrt' or 'show connected clients archer c7 openwrt'.
I am no expert on openwrt or the archer c7, but my first guess would be that 'br0' is not the name of your network bridge. 'brctl show' might show you the bridges and interfaces on your router. Otherwise ifconfig could be helpful. (Depending on what commands your router does support)
The OpenWrt is original (as a newbe, I was glad I managed it a few years ago ).
You are not running the same version as a few years ago I hope? That would be a major security risk without any patches/updates.
).