After searching the existing Support Documentation, I couldn't find any mention of this minor bug, so I'm posting it here. When an existing hub variable, which is already referenced in one or more 5.x rules, is renamed, the reference to that variable, as displayed in the rules, continues to make use of the prior hub variable name. This behavior persists upon rebooting. It seems to me that it would be cleaner design for all references to the hub variables as used by rules to change to the current name.
In short, the hub variable rename function seems to be lacking the code needed to globally swap out the prior name.
Interestingly, if one tries to change the variable reference from within the edit function of the rule, the drop-down list shows only the prior hub variable name and not the current name.
That seems most odd, since devices are known internally by the UID, with the name/label looked up from that presumably from the sole database - and I had expected the variables would be the same! Do they still work? I mean does the variable you meant to update or reference get updated or referenced in spite of the different name?
For rules older than 5.1, this may very well be true. For 5.1, there is code that updates the renamed variable, so it would be helpful if you were explicit instead of 5.x. There are a couple of things going on. (1) In some UI contexts of the rule, the renamed variable name may not appear in the display until the underlying element is actually opened (a UI glitch). (2) It is possible that we missed some specific case where the rename is not being applied. If you could provide very specific examples with screenshots, that would be helpful.
The rules in question that exhibit this behavior are 5.0. Below is a subset of the rules in my system, with rule: [BRDG - Virtual Laundry Lights to Actual Laundry Lights - ON] being one of the examples that shows this non-renaming property:
I tried that. However, when reconstructing the conditional statement that makes use of that hub variable, what is listed as a choice of switches to use (the hub variable is connected as a virtual switch) is the hub variable old name and not the current name.
I've found no way to even see the current hub variable name from within that rule, even if making new statements.
I'm thinking that the only clean solution here is to delete the 5.0 rule and just make a new one as the current 5.1 version. Do you agree?
You're using a connector, not a Hub Variable. When you rename a Hub Variable that does not rename a connector for it, which retains the old name. You can confirm this easily, by clicking on the connector in the Hub Variables table. You have two choices: (1) leave it as is, just bearing in mind the fact that the connector now has the old name while the variable it is connected to has the new name, or (2) rename the connector device to match the new name for the variable. If you do that, that device renaming is automatically reflected in apps that use the connector, just as it would be with any device.
There is no need to redo the rule from 5.0 to 5.1. Even with 5.1, connectors do not get renamed when the Hub Variable is renamed. I think it's fair to say that connectors should be renamed when the Hub Variable is renamed, and this should be fixed in a future release.
Thank you! I had not appreciated the distinction between a hub variable and the translation layer of connecters (when utilized), which map to a distinct and separate name / device. I get it now. What is interesting is that it appears that when a hub variable is connected, it is no longer available for selection itself, under its name. This makes sense, as otherwise, there would be confusion as to which named layer is being update by which app.
This is not true. A connector is a virtual device, and a Hub Variable is a variable. There are two entirely different types of selectors for these. You can't find connectors under variables, and you can't find variables under any type of device.
When a Hub Variable is renamed, in Rule 5.1 references to it will get the new name. As mentioned above, the connector is not renamed, and it still has the old name. Like this:
As mentioned above, this behavior should be changed, so that the connector is renamed when the variable is renamed. Attempting to delete the connector of a renamed variable, where the connector has not been renamed, leads to an error. So, the next release will address this issue.
