HS3 to HS4 plugins ....

[goldriver]

For the benefits of all Beta and futur users of HS4 I thing it would be interesting to have a single link where Plugin developers would state their intention about their Hs3 plugins.
In fact it would be nice to know if yes or no their intention is to migrate, when and at what cost.

That page should be dynamic, I understand that developer might change their mind over time but this would give the community a high level view of what is coming up.

I have seen some post in specific developer page giving their own-opinion but to have one topic where we could find them all would be great.


just a tought...

[Dweber85rc]

I second this. There are a couple of plugins I am considering buying but if the developer isn't going to Port them or continue to support them I won't buy.

[Krumpy]

Disclosure is always a good thing. But, it might for fact be just too early. Time will tell and many of the active plugin authors will be incented one way or another to provide an upgrade at some point.

I would push to have a good communication mechanism between HS3 and HS4. Then one can leave their HS3 system to do what it does well and the HS4 system does what it does well. Why can’t they coexist? When I buy or install hardware, I utilize technologies that can be shared amongst multiple software products. For example; the ISY, the Elk M1G, and others allow multiple automation software products to connect and provide service. Get my point?

I personally still run HS2 and HS3. Didn’t really upgrade to HS3 until a year ago. Yes, I had it installed before it was released but didn’t use it in production until a year ago. Same scenario will be for HS4.

As users of automation software we should really demand coexistence and interexchange of information such that data and commands can be shared or “pushed” or ‘routed” between many different automation platforms. Oh, and without the need of silly plugins like Big5 and the like. These technologies must be built in the core product!!! We should not be locked into one ecosystem or software product or platform!!!

You get my point. Thanks for listening to my rant.

[simplextech]

As users of automation software we should really demand coexistence and interexchange of information such that data and commands can be shared or “pushed” or ‘routed” between many different automation platforms. Oh, and without the need of silly plugins like Big5 and the like. These technologies must be built in the core product!!! We should not be locked into one ecosystem or software product or platform!!!

You get my point. Thanks for listening to my rant.

I think there's always going to be some degree of "lock-in" to a product and that being the "core" software, hub, appliance etc whatever is in use. I fully agree with the sentiment that the "core" product should provide MUCH more functionality and not be dependent on so much 3rd party plugins/drivers to make the product even remotely functional for anything. On the flip side I think there's always a benefit to users with systems that do have a plugin system for 3rd party development. Developers can add unique functionality or custom functions.

[Krumpy]

I embrace the plugin concept. What I think needs to be in the core product is the ability for the new and old version to support coexistence with data and command sharing such that a user can have both systems functional while transitioning from the old to the new software. This was clearly lacking with HS2 and HS3. Yes, I understand the challenges but it can be done, and should be supported natively. I have read all of posts back and forth from Rich, but it cost me a hell of a lot more money in time to convert systems than he estimates. Now, multiply that across all of the users that went through the same process as I have, and it gets to be a significant time factor. It would have been easier for everyone if this tech was included - even if there was a supporting up charge for it. Keeping in mind that I am not demanding that a upgrade process transcodes all of my customizations; I am asking for the ability to share device data and command functionality between systems. Much like Jon’s “Connector” but more natively integrated and streamlined with supporting API’s such that third party developers can support such a concept and process. If Jon did it in vbscript then why couldn’t Rich do it in .NET? It wasn’t done because it couldn’t be done, It wasn’t done for development time reasons. This isn’t about vbscript or .NET, it’s about thoroughly creating a transition path such that we all can ride that process easily and collectively.

Your point about third party developers ability to add custom functionality is true. This creates challenges, but The hurdle can still be minimized as part of a supporting transition plan.