Sorry, can’t really help you. Seems like your python environment is not properly setup.

I would start undoing whatever you tried to do with the python path, but repairing a broken python installation is not my area of expertise.

As long as you are running the same version of the plugin there is no reason to remove any iDetect elements. That step is only needed if you switch between the (still) "beta" and the master version, because the beta uses the DomoitczEx framework and the older version uses the old plugin framework ...

Indeed, the plugin won't be able to detect any wifi presence if you disabled wifi on the router. The ip-address works because it will use ping instead of wifi detection. The ping approach won't even use the router.

Great that you got it working! The default (ssh autodetect) tracker queries the router on a pretty low (chipset) level so you need te query every node in your mesh separately or use another tracker type that queries the mesh on the master router. For Asus the "aimesh_json" tracker type should work ...

Maybe the Domoticz log level setting is limiting it. Can you start Domoticz without a log-level setting? The error message indicates that the plugin failed to load a required module for the tracker. You could try installing paramiko globally, just to rule out the venv as a possible cause. Which ...

It doesn't seem te find the required modules. Since you installed paramiko to a venv my first guess would be that Domoticz is not using the same venv. Otherwise the debug mode might give some more clues.

Can anybody help me with the first step, I get errors when installing paramiko with 'sudo pip3 install requests paramiko'. I am running Python 3.7.3 and Domoticz 2025.1_build16576 on Rpi4. After multiple tries, I still get this error: Python 3.7 support ended in 2023. I would try a more recent ...

I already spent many hours trying to reproduce your issues back in januari. Unfortunately I could not, so I am unable to offer any new insights. Maybe someone with a comparable setup can help? Btw: i would not consider replacing the plugin directory a “clean install”. The files in the plug-in dir ...

Update: deleted everything in the iDetect folder, reinstalled the Beta without the logging on in the iDetect sheet, all ok again with 192.168.2.1#type=aimesh_json I don't get it ........ This is how the install must go, but why then the installs with the errors? If you switch back and forth between ...

I changed my router to Asus XT8. I'm still running into issues using type=aimesh_json. It used to be fool-proof, not so much anymore. Thats why I was wondering about the Beta The beta uses the newer DomoticzEx framework to manage the Domoticz devices. There have also been some structural changes ...

Is there any planning for the beta to be released? we are not running domoticz to control nuclear power plants ;) My wife and kids think otherwise, when it does not work, it's 'rubbish' and they don't want to have it in their house. So like a nuclair plant, it has to work all the time, or we get a ...

Is there any planning for the beta to be released? I have been testing it for a while because it looked like something was causing a memory leak. However, on my setup the Domoticz memory usage indeed rises the first few days but then stabilizes. I don't know if there is any relation with the plugin ...

Looks like your Fritzbox is not allowing the login at these times. iDetect doesn’t do anything different around 22:00, so I would look at the Fritzbox configuration. Any maintancance (update) jobs on the Fritzbox at 22:00? Maybe some timed blocking rules?

After looking at a more detailed debug log I noticed that (at least in the log) the onconnect sent content is different when you select xlm of http as the protocol (other protocols I tested look the same as the xml protocol below, so it is the http that is different from the rest). When configuring ...

I am trying to write a plugin that reads the XML alertstream of a Hikvision security camera and I want to use the connection object offered by the plugin framework to do so. I know how to solve this using requests, but I want to see if plugins behave better if they avoid using additional modules ...

The error returned, after quite a number of time restarting and trouble shooting of another error. I then simply deleted the iDetect and reinstalled the app and it is running again without error. And it all worked again. That is what I call strange. Very strange indeed. Nothing is stored or changed ...

I reset everything by deleting the previous iDetect and installing it with: sudo git clone -b DomoticzEx-based-beta https://github.com/d-EScape/Domoticz_iDetect.git iDetect guess what, no errors ......... and I see that the frequency of logging with all the data from the router has increased to ...

I increased the timeout in ssh_tracker from 5 --> 10 and 3 --> 6. def getfromssh(self, tracker_cli, alltimeout=10, sshtimeout=6): Same result: 2024-01-30 09:44:42.269 IDetect: 192.168.2.1 Timed poll starting like clockwork. 2 threads active (including me) 2024-01-30 09:44:42.269 IDetect: 192.168.2 ...

Where can I find the timeout? They are hard coded in ssh_tracker.py. Just search for timeout in the file. Have you tried if resetting the nuc has a different effect than only restarting Domoticz? Since the plug-in first worked and failed after a Domoticz restart, it might be a clue if that is ...

After a restart the error is coming again. It is functioning properly. 2024-01-29 11:33:11.884 IDetect: 192.168.2.1 ====> SSH tried for 12 milliseconds. 2024-01-29 11:33:11.884 IDetect: 192.168.2.1 Could not be polled 2024-01-29 11:33:11.884 Status: IDetect: 192.168.2.1 ====> SSH resetting ...