Domoticz

edg1972 wrote: ↑Friday 24 April 2020 10:48 Hi,

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;-))

Code: Select all

http_response = self.http_session.get(self.orbi_url, verify=False, timeout=8)

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.

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?

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?

After some research I found this: https://github.com/domoticz/domoticz/issues/2642, also there is additional information about the issue several posts down.

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.

dpcreel wrote: ↑Tuesday 19 May 2020 6:19 After some research I found this: https://github.com/domoticz/domoticz/issues/2642, also there is additional information about the issue several posts down.

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?

Hi,
Has anyone managed to get this plugin to work with an Unifi Dream Machine Pro (with unifi-http metod) ?
The API url seems to be different.

Hi,
Plugin can't find proper device (wlan0). When I use iwinfo or ifconfig command its shows properly all interfaces.

/usr/bin$ ifconfig | cut -d ' ' -f1| tr ':' '\n' | grep -E '^eth|^wlan|^ath|^wl'
eth0
eth0.1
eth0.2
wlan0



Any idea?

Spoiler: show

2020-10-19 20:44:57.838 (Kontrola obecności) 192.168.1.1 ====> SSH Fetching data using:
2020-10-19 20:44:57.838 for iface in $(ifconfig | cut -d ' ' -f1| tr ':' '
2020-10-19 20:44:57.838 ' | grep -E '^eth|^wlan|^ath|^wl');do
2020-10-19 20:44:57.838 /usr/bin/iwinfo $iface assoclist > /dev/null 2>&1 && printf "~$iface"
2020-10-19 20:44:57.838 done
2020-10-19 20:44:57.838 exit

2020-10-19 20:44:57.916 (Kontrola obecności) 192.168.1.1 ====> SSH returned (decoded):
2020-10-19 20:44:57.916 (Kontrola obecności) 192.168.1.1 ====> SSH session took 77 milliseconds.
2020-10-19 20:44:57.916 (Kontrola obecności) 192.168.1.1 Available interfaces for iwinfo: ['']
2020-10-19 20:44:57.916 (Kontrola obecności) 192.168.1.1 Prepared to poll using: /usr/bin/iwinfo assoclist
2020-10-19 20:44:57.916 exit
2020-10-19 20:44:57.916 (Kontrola obecności) 192.168.1.1 tracker will autodetect ssh cli
2020-10-19 20:44:57.916 (Kontrola obecności) 192.168.1.1 Data will be received and interpreted by <bound method BasePlugin.onDataReceive of <plugin.BasePlugin object at 0x5ef4e630>>
2020-10-19 20:44:57.917 (Kontrola obecności) Trackers initialized as:{'local pinger': <trackers.ping_tracker.ping_tracker object at 0x64053f10>, '192.168.1.2': <trackers.ssh_autodetect.ssh_autodetect object at 0x64053ef0>, '192.168.1.1': <trackers.ssh_autodetect.ssh_autodetect object at 0x63b431f0>}

Hi softone13

have you tried this? What is the make and model of your router?

Yes, its working.
It is WDR3600 (TP-link) with openwrt (Gargoyle 1.6.2.2)

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..

Big thanks EscApe!
It's working

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: Does anyone have some suggestions for me how to fix this? Even Google can't help me with these keywords...

Hi ESFnl,

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: Maybe others can share some experiences/tips if you tell us about the make and model of your router and provide a full debug log of the plugin.

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?

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):

Spoiler: show

Code: Select all

30-10-2020	20:26:50.153	(iDetect) 192.168.0.1 Tracker is of the ssh kind
30-10-2020	20:26:50.153	(iDetect) 192.168.0.1 ====> SSH Fetching data using:
30-10-2020	20:26:50.153	export PATH=/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:$PATH
30-10-2020	20:26:50.153	type wl
30-10-2020	20:26:50.153	type iwinfo
30-10-2020	20:26:50.153	type wlanconfig
30-10-2020	20:26:50.153	type wl_atheros
30-10-2020	20:26:50.153	type qcsapi_sockrpc
30-10-2020	20:26:50.153	type ip
30-10-2020	20:26:50.153	type brctl
30-10-2020	20:26:50.153	type arp
30-10-2020	20:26:50.153	[ -f /proc/net/arp ] && type cat
30-10-2020	20:26:50.153	echo 0
30-10-2020	20:26:50.153	exit
30-10-2020	20:26:50.153	(iDetect) 192.168.0.1 ====> SSH not connected ... connecting
30-10-2020	20:26:50.153	(iDetect) 192.168.0.1 ====> SSH start connect
30-10-2020	20:26:54.799	(iDetect) 192.168.0.1 ====> SSH returned (decoded):wl: not found
30-10-2020	20:26:54.799	iwinfo: not found
30-10-2020	20:26:54.799	wlanconfig: not found
30-10-2020	20:26:54.799	wl_atheros: not found
30-10-2020	20:26:54.799	qcsapi_sockrpc: not found
30-10-2020	20:26:54.799	ip: not found
30-10-2020	20:26:54.799	brctl is /usr/sbin/brctl
30-10-2020	20:26:54.799	arp: not found
30-10-2020	20:26:54.799	cat is /bin/cat
30-10-2020	20:26:54.799	(iDetect) 192.168.0.1 ====> SSH session took 646 milliseconds.
30-10-2020	20:26:54.801	(iDetect) Available commands on 192.168.0.1:{'brctl': '/usr/sbin/brctl', 'cat': '/bin/cat'}
30-10-2020	20:26:54.802	(iDetect) 192.168.0.1 Prepared to poll using: /usr/sbin/brctl showmacs br0
30-10-2020	20:26:54.802	exit
30-10-2020	20:26:54.802	(iDetect) 192.168.0.1 tracker will autodetect ssh cli
30-10-2020	20:26:54.802	(iDetect) 192.168.0.1 Data will be received and interpreted by <bound method BasePlugin.onDataReceive of <plugin.BasePlugin object at 0x5e3bc590>>
30-10-2020	20:26:54.802	(iDetect) Trackers initialized as:{'192.168.0.1': <trackers.ssh_autodetect.ssh_autodetect object at 0x5db228d0>}
30-10-2020	20:26:54.802	(iDetect) Plugin initialization done.
30-10-2020	20:26:54.747	Status: (iDetect) 192.168.0.1 ====> SSH connection established
30-10-2020	20:26:54.802	Status: (iDetect) 192.168.0.1 No supported chipset found. Using generic mode: brctl
30-10-2020	20:26:54.802	Status: (iDetect) Tracker activated:192.168.0.1 port 22, user: root,type: default and options: {}
30-10-2020	20:27:04.324	(iDetect) onHeartbeat called
30-10-2020	20:27:04.325	(iDetect) 0 devices are present (excluding ignored devices)
30-10-2020	20:27:05.153	(iDetect) 192.168.0.1 Timed poll starting like clockwork
30-10-2020	20:27:05.154	(iDetect) 192.168.0.1 Start poll and return results to <bound method tracker.receiver_callback of <trackers.ssh_autodetect.ssh_autodetect object at 0x5db228d0>>
30-10-2020	20:27:05.154	(iDetect) 192.168.0.1 ====> SSH Fetching data using: /usr/sbin/brctl showmacs br0
30-10-2020	20:27:05.154	exit
30-10-2020	20:27:05.191	(iDetect) 192.168.0.1 ====> SSH returned (decoded):
30-10-2020	20:27:05.192	(iDetect) 192.168.0.1 ====> SSH session took 37 milliseconds.
30-10-2020	20:27:05.211	(iDetect) Inbound data from: 192.168.0.1 containing []
30-10-2020	20:27:05.211	(iDetect) 0 devices are present (excluding ignored devices)
30-10-2020	20:27:05.191	Error: (iDetect) 192.168.0.1 ====> SSH returned error:brctl: invalid argument 'showmacs' to 'brctl'
30-10-2020	20:27:14.973	(iDetect) onHeartbeat called
30-10-2020	20:27:14.973	(iDetect) 0 devices are present (excluding ignored devices)
30-10-2020	20:27:20.213	(iDetect) 192.168.0.1 Timed poll starting like clockwork
30-10-2020	20:27:20.214	(iDetect) 192.168.0.1 Start poll and return results to <bound method tracker.receiver_callback of <trackers.ssh_autodetect.ssh_autodetect object at 0x5db228d0>>
30-10-2020	20:27:20.214	(iDetect) 192.168.0.1 ====> SSH Fetching data using: /usr/sbin/brctl showmacs br0
30-10-2020	20:27:20.214	exit
30-10-2020	20:27:20.246	(iDetect) 192.168.0.1 ====> SSH returned (decoded):
30-10-2020	20:27:20.247	(iDetect) 192.168.0.1 ====> SSH session took 32 milliseconds.
30-10-2020	20:27:20.251	(iDetect) Inbound data from: 192.168.0.1 containing []
30-10-2020	20:27:20.251	(iDetect) 0 devices are present (excluding ignored devices)
30-10-2020	20:27:20.246	Error: (iDetect) 192.168.0.1 ====> SSH returned error:brctl: invalid argument 'showmacs' to 'brctl'
30-10-2020	20:27:25.000	(iDetect) onHeartbeat called
30-10-2020	20:27:25.001	(iDetect) 0 devices are present (excluding ignored devices)
30-10-2020	20:27:34.973	(iDetect) onHeartbeat called
30-10-2020	20:27:34.974	(iDetect) 0 devices are present (excluding ignored devices)
30-10-2020	20:27:35.253	(iDetect) 192.168.0.1 Timed poll starting like clockwork
30-10-2020	20:27:35.254	(iDetect) 192.168.0.1 Start poll and return results to <bound method tracker.receiver_callback of <trackers.ssh_autodetect.ssh_autodetect object at 0x5db228d0>>
30-10-2020	20:27:35.254	(iDetect) 192.168.0.1 ====> SSH Fetching data using: /usr/sbin/brctl showmacs br0
30-10-2020	20:27:35.254	exit
30-10-2020	20:27:35.287	(iDetect) 192.168.0.1 ====> SSH returned (decoded):
30-10-2020	20:27:35.287	(iDetect) 192.168.0.1 ====> SSH session took 32 milliseconds.
30-10-2020	20:27:35.289	(iDetect) Inbound data from: 192.168.0.1 containing []
30-10-2020	20:27:35.290	(iDetect) 0 devices are present (excluding ignored devices)
30-10-2020	20:27:35.876	(iDetect) onStop called
30-10-2020	20:27:35.877	(iDetect) 192.168.0.1 ====> SSH client closed
30-10-2020	20:27:35.877	(iDetect) 192.168.0.1 ====> SSH wait for transport to close
30-10-2020	20:27:35.904	(iDetect) 192.168.0.1 Poll timer canceled
30-10-2020	20:27:35.853	Status: (iDetect) Stop directive received.
30-10-2020	20:27:35.853	Status: (iDetect) Exiting work loop.
30-10-2020	20:27:35.287	Error: (iDetect) 192.168.0.1 ====> SSH returned error:brctl: invalid argument 'showmacs' to 'brctl'
30-10-2020	20:27:35.287	
30-10-2020	20:27:36.353	Status: (iDetect) Stopping threads.
30-10-2020	20:27:36.354	Status: (iDetect) Stopped.

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:

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.