You don't have to change anything. Everything you have setup will continue to work just as it does now -- as usual when we add features.
7 Likes
Well, you say that. But if we have to recreate rules entirely to make use of new capabilities then it's not much of a migration. I'm sure it's easier for you to add another version of the Rule Machine than to work through delivering migration functionality. Understood. But how about tools to assist migration of your users to new capabilities? Rather than rewrite a rule in RM v x.y, an ability to migrate then fix-up the rule. That would be appreciated.
Why do you need to migrate anything? If it isn't broken, why fix it? I still have rules in my system called Rule, from four years ago. They work, so why would I update them?
4 Likes
To use the new capabilities that you provide. If I could do everything in an old version, why are you developing new versions and why would I bother to upgrade? Right now I have to recreate the rule in your latest RM version. I think you should think through how to make that migration easier.
By the way, I work for a company which prides itself in customers being able to open legacy files in our latest version and we take responsibility for doing whatever is necessary to make it work. Then they can add the additional functions without recreating everything. Different scale of business and different industry (complex engineering and simulation systems). But the principle is one we hold dear.
2 Likes
I can see Bruce's point. If they had not have introduced this new functionality then your system would carry on working without it.
They have introduced something. Your system will carry on working in it's current form.
If you want to use the new functionality then you will have to amend your set up to be where you are now but with added functionality.
I'm not trying to be controversial but I can see Bruce's point. I think we will be agreeing to disagree on this one. 
4 Likes
I'm not understanding why? Your existing rules work fine without needing the new features. If you need those features, you can create a new one.
Otherwise. just leave well enough alone ....
5 Likes
You're missing the point. I have an existing rule I want to improve by changing one aspect to take advantage of new functionality in a new version of RM. Today I have to completely recreate the rule. It is not even possible to clone and then edit in the new version of RM. For trivial rules of course it is no big deal. Otherwise it is a pain as I indicated. Of course its not the end of the world and its a hobby anyway. But nevertheless I wish the team would think about how to move a rule from one version to the next with as little fuss as possible.
2 Likes
Of course we will disagree and that is fine. I can tell you that if my company introduced the next version of our software and told our customers they had to recreate their files in order to take advantage of new functionality we wouldn't be around in business for long. As I said, different scale of business and different more complex environment/system. But the principle is a sound one. The best systems allow you to migrate your data to the more advanced new functionality without literally recreating the data and don't require you to retain multiple versions of the app (which is essentially fragmentation).
3 Likes
Just a thought - I wonder if exporting and importing a rule would permit switching from a global-variable-device-connector-device to a hub-variable-device-connector-device.
1 Like
Your stated reasons are basically ridiculous. To listen to you, we should only introduce new features that somehow magically can be migrated to from existing things, even though that flies in the face of the basic fact that these are NEW features.
Ha ha ha to listen to you I couldn't possibly understand why Microsoft (as an example, but think about it there are many others, in fact almost all software companies) issue a new version of Word and PowerPoint and Excel with new functionality that, lo, can read old files, open them gracefully and allow for the new functionality to be added if the user chooses. And I don't have to keep an old version of their software at hand to do so, every revision. You think your software is a special case or is somehow more complicated than that? Your position is the absolutely ridiculous one.
Perhaps it would help the conversation if you can provide a concrete example to move this from a theoretical discussion on philosophy to a real use case that might benefit customers.
4 Likes
Sure, read above for the context. The discussion covered variables as an example.
As I said, no big deal and rules can of course be recreated. However, I do wish some thought was put into making such a migration easier for users. For the principle of this subject to be called ridiculous is classic Bruce and frankly not a complete surprise. If sincere user feedback can't be taken seriously then so be it. Many other options ahead as always 
On the other hand, I hate the Microsoft "update it even if it breaks things" model. I am glad that Hubitat doesn't do this.
And I can't see having to remake dozens of rules or all your rules or anything like that. Wouldn't it be more likely you might want to remake one or maybe a couple rules to take advantage of this?
2 Likes
Maybe, it would be good to test that and see. It may save some time. It's a good idea. Not sure if it's possible between RM versions.
When tables were first introduced to Word, and before a document had hand constructed tables, was there a way to covert those hand constructed tables into the new table feature?
Backwards compatibility is a huge requirement. Every new feature has to leave intact every existing app, because they are in use 24x7. If that can’t be done, for whatever reason, then a new version of the app is required so as not to disrupt those existing running apps. It is generally not feasible (or worth the effort even if theoretically feasible) to migrate running apps to a new version.
4 Likes
Ah, I think there are countless examples. of software companies providing the latest version of their product with new functionality and yet it can read legacy data. Don't get hung up on my example of Microsoft just because you don't like them in some way. You update Google Chrome and it can still read an old website yet provides new capability that can be accessed without a complete website rewrite. You don't have to rebuild your website to use the new version and you definitely don't need to retain multiple copies of Chrome depending on which website you want to access. That is a type of fragmentation.
Critical thinking guys. It's supposed to be a positive thing ok and, until Bruce's remark, was offered in good spirit.
1 Like
No, you opened the file, and edited/removed/added the new capability. You didn't have to start your entire file again.
It's commonly done in software as I've indicated above and certainly is absolutely required in enterprise software. Of course its a choice and your business may not care to make the investment required to support it given it is largely a consumer product aimed at the ease of use market place and the guidance anyway is to keep rules simple (and hence quite easy to recreate). I get it ok. I'm not stupid. Show some respect and don't call my position "basically ridiculous" when it evidently (through multiple examples provided) is not.
I won't be posting on this thread again.
Have a nice day.
1 Like
Thanks for your support of our ongoing efforts to improve Hubitat Elevation.
4 Likes
Just wanted to say a massive thank you to the people who had the vision to bring this product to life in the first instance, and still continue to improve things on a regular basis.
These new updates aren't something that'll improve my life, but I can see them being pretty awesome for some people.
7 Likes
