Plugin Developer Documenter Plugin

[RogueProeliator]

Can I complement you on your Documentation Plugin - It is an excellent piece of work and I have already learnt quite a few new things just by looking at the plugin source.

Thanks, Jon! I learned a couple of things as well that I didn't know were available/possible, so it was a valuable exercise all around. I think the source can help as much as the live interaction and log output.

It is good to have all the interactions documented in one place and not only that but in a real "live" plugin example.

Yeah, that was my thought as well once the idea was born in the other thread -- as well as being able to tinker with it and experiment on your own.

I can see that I am going to have to make more Indigo improvement suggestions if it is going to elicit a response like this

LOL, next time you'll have to step it up and ask for something harder... but it is someone else's turn to execute on it!

[Bollar]

That should work and is basically what I use except that I use a queue construct which makes the code a bit tidier and easier to read/understand. In practice, it accomplishes the same thing; however, Queues were built in Python to be a thread-safe way to communicate between threads and protect programmers against several common mistakes that can happen with using lists in your manner. When I put up an example in the plugin I'll use that as a best-practice technique.

As as aside, if one wanted to get super fancy, the Queue can act as a Priority Queue, the advantage being that you could assign a priority to a task in order to execute "must do now" tasks in response to user actions first and let background tasks, such as status polling, happen after that (even if they were in the Queue first). I've thought of implementing that for my A/V based plugins that poll and accept user interaction.

I'm excited to see a great Queue implementation. Seems like that fixes a number of issues I'm facing with a complete polling cycle taking a couple of minutes.

[autolog]

I create separate threads and queues for managing things such as:

• Communicating with external devices
• handling polling
• handling responses
• etc. ...

The threads all have queues and when for example an Action is requested, it is validated and then sent to a queue to be processed. The receiving thread picks it up from the queue, does whatever it has to do and then adds the response to an output queue. The response handler thread interrogates its queue and picks up the output previously queued and handles it accordingly. Typically I use the runConcurrentThread as the response handler. A polling thread just loops round and every time interval just pushes a request onto whichever queue is appropriate.

I am currently investigating using a common timer thread for time interval based actions e.g handling thermostat schedules.

To my way of thinking, this allows everything to be self contained and makes understanding what is going on easier.

[RogueProeliator]

I experimented with something similar (separate threads to process responses), but what I found is that sometimes I wanted the response to be processed before the next action -- and you gain pretty little on processing the response in another thread in my instances/uses. However, that is an excellent pattern whenever the processing of the response is independent of other actions and/or can take a while. Depends on the plugin / hardware / design I guess...

I create one thread per device so that one device's slowdown or error cannot effect other devices; all communication is done on the device's individual thread. I then use the runConcurrentThread loop is used for plugin-level actions which have their own queue. For instance, the update check is done here.

All are perfectly valid patterns, somewhat plugin dependent and someone preference of the programmer. I believe for this sample, though, may just use one queue and do processing in the runConcurrentThread. Thinking when you are getting to what we are talking about here, you know enough to be able to manage multiple threads w/o the use of the plugin sample!

[kw123]

The priority overwrites I do by adding
if xxx in self.newc :
in the loop before the loop through the pending commands.
Works but likely shows my ingrained fortran iv training.

BUT Looking forward to the proper Python way to do it.

Sent from my iPhone using Tapatalk

[jblackburn]

Your initiative is awesome but I think you should keep it simple as possible! One advantage of Indigo is it simplicity! Right now, many persons without programming skill can program with success a plugin. But I agree, on different scenarios, we need complex algorithm to solve issues. It's why you should create a "Pro" plugin with advanced technics.

Thanks!

Joël

[kw123]

Yes. We need "my first plugin" + "next step". And the "real thing" for the "experts"


Sent from my iPhone using Tapatalk

[RogueProeliator]

Right now, many persons without programming skill can program with success a plugin. But I agree, on different scenarios, we need complex algorithm to solve issues. It's why you should create a "Pro" plugin with advanced technics.

Been some discussion on that and likely will happen... I will enhance this with some of the advancements talked about here and later we can strip it down to the basics for a template / primer / new user type example. This wasn't really intended to target someone completely new to Python / Plugins but it could be made to help that target as well.

[SpencerJRoberts]

This is all so fantastic, thank you for your hard work Adam!

[RogueProeliator]

Just posted an updated version with these changes:

• Added population of the Address column in the device listing
• Added line numbers to debug output
• Added a Queue to handle asynchronous command / communication with the background thread

[autolog]

Been looking for the documentation for:

Code: Select all

self.exceptionLog()

but have only found some forum entries where it is referenced.

[RogueProeliator]

Hey Jon... I could add some comments into the plugin for "useful functions" that are available. Basically for logging you have three core functions:

Code: Select all

self.debugLog(u'My message, only output if self.debug == True')

self.errorLog(u'Same as using the Indigo Log function with isError = True')
indigo.server.log(message=u'Same as using the Indigo Log function', isError=True)

self.exceptionLog()
# this will log an error with tracing... basically, just calls this:
# self.errorLog(u"Error in plugin execution:\n\n" + traceback.format_exc(30))

Truth be told, it makes it look like the plugin crashed with an error, but it helps trace down issues... I personally call that function to log exceptions in two cases -- if the exception is caught but really kills processing of something OR if the exception is caught, I can work around it but debugging is enabled.

Adam

[autolog]

Hi Adam,
Thanks for the explanation

How did you discover what self.exceptionLog() did as AFAIK it isn't documented.

There seem to be a number of Indigo routines in this category (i.e not documented) which make understanding what is possible a bit of a "black art"

This is why your plugin is an enormous help

[jay (support)]

Right now, many persons without programming skill can program with success a plugin. But I agree, on different scenarios, we need complex algorithm to solve issues. It's why you should create a "Pro" plugin with advanced technics.

Been some discussion on that and likely will happen... I will enhance this with some of the advancements talked about here and later we can strip it down to the basics for a template / primer / new user type example. This wasn't really intended to target someone completely new to Python / Plugins but it could be made to help that target as well.

Would like to point out that the SDK example plugins are really a great place to start when first building a plugin. The advanced features exposed by this documenter plugin, while very useful for those diving into the guts of plugin development, are generally not needed by many plugins/plugin developers. I'm by no means discouraging this plugin - it's very cool and very useful. There are just already good starting points for those first developing a plugin.

[kw123]

how do I set the plugin menu item default VALUES? i.e. the equivalent to e.g. "def getDeviceConfigUiValues(self, pluginProps, typeId, devId):"
for more complex menus with configUi

the only thing I found was:
"def getMenuItemsList(self):" but that gets me the menu list

thanks

Karl