Indigo Domotics

I wonder if that has to do with them shutting down public api access. Not sure if today was “the day” but I know the end is soon.

It is extremely unlikely that the change in OS affected the plugin in this way, but rather more likely that the plugin got into a bad state when it was restarted. My production installation looks to be working as expected (although WU is taking a LONG time to respond to API calls). However, when I restarted my development environment, I saw the behavior you described. I disabled and re-enabled the plugin and normal operation resumed. I've looked at the changes between 7.0.10 and 7.0.11 and don't see anything that would have caused this behavior. I did find a typo in the setting of the initial plugin configuration DEFAULTS though, which will be fixed in the next version.

The plugin checks every 30 seconds to see if an update is called for. If an update is called for, it does its thing and updates the next scheduled poll value (the next scheduled poll value is displayed within the plugin configuration dialog). I'm guessing that the plugin got into a state where it was not updating this value properly such that it was always time for an update (the current time exceeded next poll time every 30 seconds). You can always see when the plugin thinks the next poll is due by examining this value in the plugin configuration dialog box.

The API call limit is "hard coded" into the plugin such that it is a user-defined number set within the plugin configuration dialog (the default value is 500). The WU API doesn't return the number of calls to it--a long sought feature that WU never implemented--so as a proxy, the plugin attempts to track this on the users' behalf to keep it from burning through your raindrops when things go sideways.

If and until I can find (and fix) whatever caused this bad state, I would suggest that the workaround is to disable and re-enable the plugin.

lanbrown wrote:

DaveL17,

Thank you. It does appear it got into a bad state. Another mitigating step I took was to lower the daily limit to 300 in the config. I shouldn't use more than 288 in a day and if I do, then hopefully it would just be at the end of the day. I added the extra 12 so that it would be an additional hour (think of when daylight savings time ends). If I go through the 300 because the plugin gets into a bad state again, then I at least have a reserve of 200 API calls.

Setting the API call limit to a value roughly equivalent to the total number of expected calls per day is excellent advice. If you see the behavior resurface, please tell me as much as you can about the circumstances so that I can try to recreate the problem.