Indigo Domotics

Umtauscher wrote:

Since nobodyˋs life is depending on it I certainly can wait a bit longer.

Good grief! I hope not.

DaveL17 wrote:

Umtauscher wrote:

Since nobodyˋs life is depending on it I certainly can wait a bit longer.

Good grief! I hope not.

I have just published a new release of the plugin which should now retain device states when communication is lost and adds a trigger that fires when the plugin has automatically disabled a device. You can download the latest version here.

Great!
I will try it right away.
Cheers
Wilhelm

Hi Dave,

it's working great so far.
It took me a while to find the disabled trigger. I suppose there were technical problems why you didn't put it in the "Device state changed" section?
Thanks

Wilhelm

Thanks for the report Wilhelm. Glad to hear that the changes are working for you.

The device state changed trigger is a built in trigger defined by Indigo. The new trigger is a plugin-based trigger.

Hi Dave,

today the first time in real life the interface which is queried by you GhostXML plugin disconnected form the wlan.
From the first timeout on, the cpu load of the pluginhost and/or python went up to more than 85% which led to an unresponsive indigo server as well.
My server is a 2011 Mac Mini and the only thing I could do to get the server back was killing indigo via the activity monitor.

So running into a timeout seems to do something that stresses the server more than it can handle.
Unfortunately the only thing I can do ist to limit the number of unsuccessful requests to a minimum and diabling the correspondig device very early, which in fact is the opposite of what I was trying to accomplish.
I hope there is something you can do about that.
Cheers
Wilhelm

Hi Wilhelm - sorry to hear that the plugin is causing trouble for you. I'll take another look at the code, but off the top of my head, I can't think of a reason that CPU load would jump that high based on the first failed attempt. I've not seen that behavior in my testing, but there may be something unique about your setup that I haven't considered. Yours is the first report of such behavior that I can recall.

Maybe most people don‘t experience it, because the plugin normally disables the device sooner.
I have. specified a timeout of 10 sec. with a polling cycle of 15 sec. Disable is set to 100 requests.

Thanks Wilhelm -- I'll see what I can find.

Hi Wilhelm -- I wanted you to know that I didn't forget about your issue. I have done a lot of testing with a MacBook Air (Core i5, 8G) and have consistently seen the following with your settings. The tests were performed multiple times. These results were with several other programs running like Mail, Safari, PyCharm and BBEdit (recognizing that the OS will manage those apps' memory when they're running in the background). I'm not seeing loads anywhere near what you reported.

15 second refresh, 10 second timeout, 100 fails.
Allowed repeated fails.

Test 1:
Server has no access to LAN or WAN.
CPU at 0.5% idle, max 6%
Re-enabled network access, max 1%.

Test 2:
Created a device to hit a non-existent IP when pinned to WAN.
CPU at 0.4% idle, max 1%

Test 3:
Created a device to hit a non-existent IP when pinned to LAN.
CPU at 0.4% idle, max 1%

I will continue to go through the code to see if I can find anything, but it's somewhat like finding a needle in a haystack since I don't know where to look. I suppose that something could be happening when the plugin has been running for days or weeks at a time, but I have personally not seen that behavior on my production machine which has currently been online for 2 weeks.

You might try using a shorter timeout to see if that has any effect.

Thanks Dave,

for all your work. I have to do some more tests myself, but I have little time next week.
I will report back as soon as I have more....
Cheers
Wilhelm

Thank you Wilhelm -- there may be something about your target source that I'm unable to replicate. Let me know.

Hi Dave,

thanks for all your work and I am so sorry to bother you again.
I have been trying to analyze a problem for the last month now (To my excuse: I haven't had much time)

I have tested the timeout functionality from 0.4.36 to 0.4.40.
What I have found now is that once a timeout appears, the corresponding device never seems to recover by itsself. This is odd, since I am most certain that this worked once.
So the sympton on my side is :

1. device state goes to red (e.g. network disconnected)
2. device doesn't become green again when the connection is back. it just shows the state"red processing"
3. Once I change the timeout setting inside the GhostXML-device the state changes to green (starting..updated) immediately.

The manual change of the timeout reactivates the GhostXML device and the coresponging PluginHost increases the number of threads by one. So I suppose the timeouted thread does never terminate...
Does that make sence?
I hope you can reproduce this. If you need any debug log, please let me know.
Thanks
WIlhelm

Hi Wilhelm - once the device has been disabled by the plugin due to too many unsuccessful communication attempts, it won't ever come back online by itself. In order to have the device try to recover automatically, you need to create an Indigo Trigger:

Trigger: GhostXML Event --> Device Disabled
Condition: Optional
Actions: Server Actions --> Enable/Disable/Reload Actions --> Enable Device (and then pick the GhostXML device you want to enable).

I'd recommend adding a delay to the Trigger so that when the GhostXML device goes offline, the Trigger waits a while before re-enabling the device.

Yes, I think I knew that.
The devices don‘t get disabled. The first timeout sets them into that state. (red, processing)
Normally they should recover during the 100 retries, right?