Plugin Stops Working...Why?

This plugin is meant to support a little project I took on over the holidays where I've set up an ESP8266 to run as a Restful server that controls a relay. That relay is connected to my garage door opener so I can open and close it remotely via Indigo. There is a microswitch installed on the track that is closed when the garage door is closed, so this plugin polls the device and updates the state such that TRUE means the garage door is closed. It should be dead-simple to poll the URL and parse the JSON result repeatedly, but I just can't see why it keeps stopping. Once I get this all running properly, I'll document it and start a thread about it, in case others are interested in doing something similar.

Maybe this suggestion is too little too late, but I had a similar problem to solve (i..e control of relays via Wifi/ESP8266), the modules I ended up using are the NodeMCU (or Sparkfun Thing). I flashed them with an Arduino application that connects to the Mosquito MQTT Server running on the same machine as Indigo.,Hhaving the end node (in this case the ESP826) connect and subscribe, then process messages is very simple and we already have a plugin for MQTT that can send messages from Indigo.

Here is the code as it currently stands. Can anyone see why it's locking up?

And you get no indication of error / failure? One thing, you should have an except in your runConcurrentThread -- you are only catching the StopThread exception and not a more generic catch for all others.

And you should have a debug statement for every except block.

Not sure if this matters, but URLs are ascii only, not unicode. I would change theUrlBase to a plain string.

[jay (support)]

Well, the plugin only successfully updated 2557 times this last run.

This plugin is meant to support a little project I took on over the holidays where I've set up an ESP8266 to run as a Restful server that controls a relay. That relay is connected to my garage door opener so I can open and close it remotely via Indigo. There is a microswitch installed on the track that is closed when the garage door is closed, so this plugin polls the device and updates the state such that TRUE means the garage door is closed. It should be dead-simple to poll the URL and parse the JSON result repeatedly, but I just can't see why it keeps stopping. Once I get this all running properly, I'll document it and start a thread about it, in case others are interested in doing something similar.

Here is the code as it currently stands. Can anyone see why it's locking up?

No seeing anything glaring. You need to add a lot more debug logs to see exactly where it's failing.

This plugin is meant to support a little project I took on over the holidays where I've set up an ESP8266 to run as a Restful server that controls a relay. That relay is connected to my garage door opener so I can open and close it remotely via Indigo. There is a microswitch installed on the track that is closed when the garage door is closed, so this plugin polls the device and updates the state such that TRUE means the garage door is closed. It should be dead-simple to poll the URL and parse the JSON result repeatedly, but I just can't see why it keeps stopping. Once I get this all running properly, I'll document it and start a thread about it, in case others are interested in doing something similar.

Maybe this suggestion is too little too late, but I had a similar problem to solve (i..e control of relays via Wifi/ESP8266), the modules I ended up using are the NodeMCU (or Sparkfun Thing). I flashed them with an Arduino application that connects to the Mosquito MQTT Server running on the same machine as Indigo.,Hhaving the end node (in this case the ESP826) connect and subscribe, then process messages is very simple and we already have a plugin for MQTT that can send messages from Indigo.

That is something I considered when I began this project, but abandoned it when I learned about Restful/JSON as it has "fewer moving parts." That said, it's never too late and I'm always willing to learn of better ways to do things. I will certainly give MQTT another look. I assume I'll be adding more ESP8266-based devices to my setup, such soil moisture sensors, etc. in the future.

[jay (support)]

Is including the Requests library within your plugin (ie copying it into the plugin folder and importing from there) approved and/or acceptable then? That's what I've done in Evohome, but it was only meant to be temporary during alpha builds!

Yeah, that's fine. Several of our plugins include libraries in them. The plugin's source path is the first place the interpreter will look for modules/libraries (I believe).

The only gotcha is if a library isn't pure Python (has compiled code) - then you have to figure out how to compile the module itself as a fat binary so that all supported architectures are supported (which can be a HUGE PITA).

Here is the code as it currently stands. Can anyone see why it's locking up?

And you get no indication of error / failure? One thing, you should have an except in your runConcurrentThread -- you are only catching the StopThread exception and not a more generic catch for all others.

And you should have a debug statement for every except block.

Not sure if this matters, but URLs are ascii only, not unicode. I would change theUrlBase to a plain string.

Last night, I removed unneeded functions and I added more catches and debugging logs. Now, it's been running since with over 7300 successful updates. I will have to parse through the logs to see if one of the new exceptions caught a problem.

I'll change the URLs to plain strings, too.

[jay (support)]

Where this all started for me was some rare cases where urllib2 would return an error that would throw an "invalid literal for int() with base 16".

That's the error as returned from urllib2? Which call was it coming from?

Where this all started for me was some rare cases where urllib2 would return an error that would throw an "invalid literal for int() with base 16".

That's the error as returned from urllib2? Which call was it coming from?

To be honest, I'm not entirely sure. I *think* it was in the f.read() call. I found this link to a bug that appears to be fixed for Python2.6, so it may be moot at this point.

http://bugs.python.org/issue3721