I really like Button Controller 5.1 vs. 3.1. I was hoping that if I cloned a 3.1 rule the clone would be a 5.1, but that didn't work. Is there any way to "upgrade" a 3.1 Button Controller rule to 5.1? (And likewise for any of the other rule apps?)
If, as I think, it is not possible now, that would be a big one on my wish-list of desired changes.
That's what I did with a simple one. But since they are a whole bunch of them and I'm not really looking to change how any of them work, I'm just going to leave well enough alone.
No. The feature set has changed enough you'd need to manually re-create. They have historically only done these kind of changes before specifically because automatic migration is not possible (they don't do it just because new features were added--they do that all the time if it doesn't affect existing rules).
I also do think that the UI could be improved a lot, but I appreciate they are a small company and are trying to add features at the same time too. I know improvements to the UI take a lot of effort and resources, so I do appreciate how much better they have made it from where it was previously.
I'm apologize if my post to that effect struck you as being without merit, and apologize for wasting your time reading this as well.
Since my original post was asking if I could convert my 3.1 rules to 5.1, as I do appreciate those changes, I do not regret starting this thread.
Quite the opposite. Your post complimenting the UI chances came within a few hours of someone else (@pascal.nohl) deriding the UI.
Your post illustrates that the Hubitat continues to make progressive changes as and when possible, and while I realize now that it came across as offensive, in reality it was commending you for recognizing continual progress with the limitations you’ve noted.
BTW, I do have a question about setting a dimmer in 5.1. We now have a Delay setting that defaults to None, while the Fade setting still defaults to "null" (not having been set at all). I have always set the Fade to 0. Does it make any difference between never setting the Fade time vs. setting it to 0?
I am not sure I can give any type of intelligent or official answer, but I would not ever leave a null. I would put something in there for fear it would break the automation at some point. I am not sure if others would agree with my assessment, but I would call this a bug, or at the very least an oversight. To me, there should be some default value in the box (maybe upon saving?) even if it is zero.
The "Set dimmer" action in Rule Machine and Button Controller calls the setLevel() command on the device. The level is required (of course; why else would you do this?), but the transition time, or fade, is optional. If specified in the action, that transition time will be used; if not specified, the device/driver default will be used. That is the difference between "null" (or not specified) and zero. Typically, an asterisk is displayed next to labels for required fields, which is also what I see here.
I don't actually see "null" anywhere in the UI when this vaue isn't provided, but if you do, maybe your options are slightly different from mine or we are looking at different thing (a screenshot may be helpful). In any case, the above is the difference between nothing and 0.
Thanks for the reply. I was using "null" to indicate a value that was never set. I didn't realize that leaving it blank would set it to the device's default as opposed to being zero. For thanks for clearing that up. That certainly helps. By setting it to zero then I can be sure I want a zero fade time.
When you say that when no Fade is set it will take whatever the default is, is this default what is set in the device itself under params 3 and 4 for the ramp rate?
This depends on your device and driver, whatever it does if you don't pass the second parameter to the "Set Level" command on the device detail page. Many devices provide a configurable option for this default by way of a preference, which you can find below that (in Preferences) for such a devices.
The specific parameter or other means it uses to implement this will vary but is handled by the driver, not the app, which just calls the command.