Your Domoticz is starting before the network interface of the raspberry is completely initialized. When introducing multi router support i removed the retry, so it no longer copes with this situation. Just pressing update on the settings page will fix it (no need to disable/enable). You can also configure Domoticz to start after the network is fully operational (which i prefer anyway), but that takes some tinkering with the startup script or systemd (depending on which u use).
The plugin should recover from the network not being up when starting.... will fix this in the next couple of days. For now, just press update or never reboot the raspberry
EscApe wrote: ↑Thursday 06 September 2018 22:34
You can also configure Domoticz to start after the network is fully operational (which i prefer anyway), but that takes some tinkering with the startup script or systemd (depending on which u use).
If you use a Raspberry Pi this is very easy to do: just start "sudo raspi-config" from the command line, go to "Boot Options" and select "B2 Wait for Network at Boot".
Raspberry Pi 4 - RFXtrx433 - CC2531 Zigbee - Opentherm Gateway - P1 smart meter - Netatmo - Philips Hue - ELV Max! - ESP8266 DIY water meter - 6 x Sonos - 4 x IP cameras - Wall mounted tablet + Dashticz - Google Home integration - MANY switches/sensors
The command "do qcsapi_sockrpc get_station_mac_addr wifi0 $i" must start from 0 instead of 1 (i=1). The While loop loops too far, so I get this errorcode: "QCS API ERROR 34: PARAMETER VALUE OUT OF RANGE".
So ik there are 2 devices on the 5G Wifi, then:
qcsapi_sockrpc get_station_mac_addr wifi0 0
qcsapi_sockrpc get_station_mac_addr wifi0 1
must be queried.
I don't know why I didn't see it earlier
Last edited by wizzard72 on Friday 07 September 2018 17:02, edited 1 time in total.
I will fix the qcsapi loop (next version is coming soon). Starting at 1 is based on the information i got when we implemented this, so i do hope it is not router specific.
The override button could be disabled in the plugin settings. What is your current 'override mode'?
Fixed: Error handling that was insufficient after introducing multi router support.
Fixed: Query for Quantenna chipset (Asus AC87 and others) was starting at wifi0 1 but should start at wifi0 0.
2018-09-07 21:12:48.766 Error: (iDetect iPhones) 'onStart' failed 'NameError'.
2018-09-07 21:12:48.766 Error: (iDetect iPhones) ----> Line 616 in '/home/pi/domoticz/plugins/iDetect/plugin.py', function onStart
2018-09-07 21:12:48.766 Error: (iDetect iPhones) ----> Line 430 in '/home/pi/domoticz/plugins/iDetect/plugin.py', function onStart
2018-09-07 21:12:48.819 Error: (iDetect RPi Fnatenrahmen) 'onStart' failed 'NameError'.
2018-09-07 21:12:48.819 Error: (iDetect RPi Fnatenrahmen) ----> Line 616 in '/home/pi/domoticz/plugins/iDetect/plugin.py', function onStart
2018-09-07 21:12:48.819 Error: (iDetect RPi Fnatenrahmen) ----> Line 430 in '/home/pi/domoticz/plugins/iDetect/plugin.py', function onStart
2018-09-07 21:13:05.864 Error: (iDetect RPi Fnatenrahmen) Plugin initialization did not complete successfully. Check the (debug) log for startup errors.
2018-09-07 21:13:05.864 Error: (iDetect iPhones) Plugin initialization did not complete successfully. Check the (debug) log for startup errors.
2018-09-07 21:13:15.881 Error: (iDetect RPi Fnatenrahmen) Plugin initialization did not complete successfully. Check the (debug) log for startup errors.
2018-09-07 21:13:15.881 Error: (iDetect iPhones) Plugin initialization did not complete successfully. Check the (debug) log for startup errors.
2018-09-07 21:13:25.847 Error: (iDetect RPi Fnatenrahmen) Plugin initialization did not complete successfully. Check the (debug) log for startup errors.
2018-09-07 21:13:25.897 Error: (iDetect iPhones) Plugin initialization did not complete successfully. Check the (debug) log for startup errors.
2018-09-07 21:13:35.863 Error: (iDetect RPi Fnatenrahmen) Plugin initialization did not complete successfully. Check the (debug) log for startup errors.
2018-09-07 21:13:35.863 Error: (iDetect iPhones) Plugin initialization did not complete successfully. Check the (debug) log for startup errors.
2018-09-07 21:13:45.879 Error: (iDetect RPi Fnatenrahmen) Plugin initialization did not complete successfully. Check the (debug) log for startup errors.
2018-09-07 21:13:45.880 Error: (iDetect iPhones) Plugin initialization did not complete successfully. Check the (debug) log for startup errors.
2018-09-07 21:13:55.895 Error: (iDetect RPi Fnatenrahmen) Plugin initialization did not complete successfully. Check the (debug) log for startup errors.
2018-09-07 21:13:55.896 Error: (iDetect iPhones) Plugin initialization did not complete successfully. Check the (debug) log for startup errors.
2018-09-07 21:14:05.862 Error: (iDetect RPi Fnatenrahmen) Plugin initialization did not complete successfully. Check the (debug) log for startup errors.
2018-09-07 21:14:05.862 Error: (iDetect iPhones) Plugin initialization did not complete successfully. Check the (debug) log for startup errors.
My bad!
Left a test in there that broke the plugin for multiple routers. Should be fixed now... however... I had to edit directly on github (am not at my computer) and could not test, so I hope that didn’t introduce indentation errors in python (probably not).
0.6.4 is available
So it does recover from these errors? Glad to hear that
Using multiple servers increases the amount of error logging, which is unnecessary in this situation. I will see what I can do about that in the next version.
A wait time is not an option, because the plugin system is single threaded and it would block everything else. To prevent these errors at startup you will have to make sure that the network is up before Domoticz starts. Did you follow the instructions given by mvzut?
This might help... new and improved on GitHub. Please keep an eye on the log and check if absence/presence is properly detected. I had to make some major changes to better accommodate multiple routers. It works well on my single router setup, but i cannot test in a multi router environment.
The plugin will now only log an error after 3 failures in a row on the same router. It will also throttle the poll frequency after a ssh failure. 30 seconds of minimum wait time for every failure, with a maximum of 2 minutes. That should reduce error message drastically. You will still get 3 messages for your three routers if the network is not operational, but chances are that the network is up before the 3 errors have occurred. Especially since after the first error the polling will start throttling the frequency.
I am considering to start throttling a little later (after 2-3 failures), but let's first see how this works in real life.
**version 0.6.5**
- Improved: Lowering poll frequency on errors on a per router basis (one failed router will no longer affect the rest).
- Improved: Less logging of non critical errors (one or two ssh failures is no reason to worry .. or log .. since the connection can recover on the next poll.)
Now new features or fixes, but i have tweaked the logging a bit
**version 0.6.6**
- Improved: Debug logging for the ssh session now hides the ssh password.
- Improved: Presence changes are now logged (without needing debug mode), so you can see something is going on.
- Improved: Some more log tweaking (removed some redundancies and changed log levels for some messages)