Indigo Domotics

Full message:

Code: Select all

   Error                           process (pid XXX) failed to quit after polite request -- forcing it to quit now


I get this intermittently with the Lutron plugin, and I'm trying to figure out why. Any insight on where to start looking? Does the timer start after all the devices are shut down? My Lutron system, if fully mapped to Indigo, creates over 500 Indigo devices. That's a lot of devices to run devStopComm() on. Or does it start when the shutdown flag is set for runConcurrentThread()?

My solution to stop them all is to blind stop them or stop them in a thread. I had the same issue with HKB trying to shut down the various servers, it exceeds the allotted time frame. Blind stopping ensured that I did that without risking that Indigo would kill the process before the servers were told to stop and leave them running if the plugin wasn't.

What do you mean by "blind stop"?

FlyingDiver wrote:

Full message:

Code: Select all

   Error                           process (pid XXX) failed to quit after polite request -- forcing it to quit now


I get this intermittently with the Lutron plugin, and I'm trying to figure out why. Any insight on where to start looking? Does the timer start after all the devices are shut down? My Lutron system, if fully mapped to Indigo, creates over 500 Indigo devices. That's a lot of devices to run devStopComm() on. Or does it start when the shutdown flag is set for runConcurrentThread()?

The most common cause of this is network timeouts. If your plugin is waiting for some incoming data or a reply and is down in the Python networking code, it may not come back in the right amount of time (default Python network timeouts are usually 30 seconds or more). Setting relatively short timeouts to any network calls often solves the problem.

It could also happen if you have a tight loop in the runConcurrentThread method that doesn't call the sleep() method.

Thanks for reminding me to look at the network timeout. I think I found the issue. All I can say is that I didn't write that particular piece of code.

FlyingDiver wrote:

Thanks for reminding me to look at the network timeout. I think I found the issue. All I can say is that I didn't write that particular piece of code.

- I still sometimes forget to set it (and it was less than intuitive in Python 2.5 and pre-requests).

jay (support) wrote:

FlyingDiver wrote:

Thanks for reminding me to look at the network timeout. I think I found the issue. All I can say is that I didn't write that particular piece of code.

- I still sometimes forget to set it (and it was less than intuitive in Python 2.5 and pre-requests).

In this case, whoever originally wrote the Caséta code (I don't think it was Jim), set the timeout to 35 sec because the login process to that device was taking a long time. But it was never reset to something more reasonable.