Plugins whats still being developed and whats not

Am I missing some connotation or interpretation here?


Sent from my iPhone using Tapatalk

Am I missing some connotation or interpretation here?


Sent from my iPhone using Tapatalk

"Knocked up" is US idiom for pregnant. Or making someone pregnant.

Ah!

I knew about that idiom, and considered it, but didn't put the two together at the right time to interpret the response!

I thought C4W was implying my plugin would be awful - but didn't think he'd be saying that out loud


Sent from my iPhone using Tapatalk

I thought C4W was implying my plugin would be awful - but didn't think he'd be saying that out loud

I'm hardly one to be throwing stones at glass houses!

Hi all,

I had a thought on this - but not that much of a educated thought to actually do the coding..

What about a plugin - that reads the info.plist files of the other plugins.
If the About info.plist URL always pointed to the GitHub repository. (As it does now in some)
Surely we could use the exisiting update checker to check current versions against this and update or return a list of what needs updating? (Or force update)

Glenn

For example, there is one feature that is very important to me (being able to change the wake interval for battery devices from a schedule).

I've just knocked up 90% of a plugin that does one thing - sets the wake interval for a device. I've gotta dash out now but when I'm back later I'll finish it and send you it.

Peter

Now live: ZWave Wakeup Scheduler

What about a plugin - that reads the info.plist files of the other plugins.
If the About info.plist URL always pointed to the GitHub repository. (As it does now in some)
Surely we could use the exisiting update checker to check current versions against this and update or return a list of what needs updating? (Or force update)

I had considered a plugin that checks the state of other plugins -- but I hadn't thought of storing the update information in the .plist file which is an excellent idea; that or adding it to the plugin IOM object that the plugin can read would make it pretty darn easy to do. And that way the "auto-update check" could easily be subscribed to or ignored by plugin developers simply by including or not including the node in the plist file.

Could actually support two URL variants - a GitHub repository and a link to the entry in the file repository IF Matt/Jay could do some coding to automatically pull the version number out of the plist file when a plugin is updated in the library.

Of course the chicken-and-the-egg problem somewhat occurs with the "How does one know to install the plugin update checker plugin..."

What about a plugin - that reads the info.plist files of the other plugins.

I actually already have that library written. It's part of all my new plugins because I use that, among other files, to farm out the plugin details so I can fire plugin specific actions. I considered this as an option for this topic but it still doesn't really resolve whether or not that farmed version is the latest one.

I considered this as an option for this topic but it still doesn't really resolve whether or not that farmed version is the latest one.

But we already have code for checking the latest (released) version of a plugin on GitHub, all you need is the user and repository name... of course, that still only resolves those who choose to utilize and publish on GitHub.

For example, there is one feature that is very important to me (being able to change the wake interval for battery devices from a schedule).

I've just knocked up 90% of a plugin that does one thing - sets the wake interval for a device. I've gotta dash out now but when I'm back later I'll finish it and send you it.

Peter

Now live: ZWave Wakeup Scheduler

Brilliant .... downloading it now.

THANKYOU!!!!

I've started creating individual GhostXML Plugin devices that are linked to the GitHub API.

Just a quick followup to this post. For folks that may be looking to do this, it's exceptionally simple. I'm using the following 2 URLs (one GhostXML device per URL)

Code: Select all

https://api.github.com/repos/USER_NAME/REPO_NAME
https://api.github.com/repos/USER_NAME/REPO_NAME/releases/latest


The first one is a general API call which provides information for the whole repo, and the second one provides information for the latest release only. There's many more that could be used.

Not to hijack, but I've been thinking about this very thing--although my motivation may be a bit different. I would love a tool to be able to query installed plugins (enabled and disabled) and compare their version numbers to the most current version. Then, maybe once per week, I could receive an email message from my Indigo server with a report that would flag those plugins that aren't current. There might be a not-too-difficult way to do that for all enabled plugins that use the Indigo Plugin Update Checker code, but right now I can't think of an easy way to do that for all installed plugins. There's not really any easy way to do that with all known plugins without an Apple-like (mandatory) plugin store.

There's been some volunteers working on a user-based Wiki; perhaps, if there's enough demand, a matrix could be made that lists plugins, their known current version, and maybe their last know update date. But that would only be as good as people make it.

This is the real need. A plugin that checks the update status of all your enabled plugins and asks if you want to force update? Right now we're doing this plugin by plugin manually and checking the event log. Then going back and updating those plugins that are out of date. A simple loop through all the github plugins with some preferences to prompt or force would keep us all up to date and decrease administrative overload on forum threads.

[jay (support)]

I'd like everyone to use caution here - this is definitely something we're going to be doing as part of the product, but it's going to require some coordination and some careful specification in terms of how Github repos are constructed. Only the timing is up in the air.

We certainly understand the need, but we have some must do things leftover from the Indigo 7 rollout that have to be done by June 1 that we have to keep focused on (bad things would happen if we don't get those done).

We will start thinking about it though and involve our 3rd party developers in the discussion. What we don't want is to get the Github repo construction stuff wrong - that would have some bad repercussions in the future that with a little planning can be avoided.

[jay (support)]

I just got caught up with updating the plugin lists and MAN are we cooking with gas! Thanks to our developer community for making such a huge surge over the past several months.

I've also broken my rule this one time and have added an Announcement Post about all the new plugins since we sent out our November newsletter.

I'd like everyone to use caution here - this is definitely something we're going to be doing as part of the product, but it's going to require some coordination and some careful specification in terms of how Github repos are constructed. Only the timing is up in the air.

We certainly understand the need, but we have some must do things leftover from the Indigo 7 rollout that have to be done by June 1 that we have to keep focused on (bad things would happen if we don't get those done).

We will start thinking about it though and involve our 3rd party developers in the discussion. What we don't want is to get the Github repo construction stuff wrong - that would have some bad repercussions in the future that with a little planning can be avoided.

Thanks Jay. Good to see that it's a feature on in the backlog!