Hello folks,
I have a couple of smart plugs placed in bedrooms that are powering fans in the summer and are free for other equipment in other seasons…which is the best way to manage the labels of such items?
I don’t want to tell google “turn on the fan” if there is something else plugged in…and I want to avoid keeping changing labels.
How do you face this kind of issue? Just give it a “general” name like “smart plug”?
Is there a way to dinamically change labels or to give more than one name to an item something like a synonim so I can provide a list of equipment that could be plugged in?
Any hint is appreciated.
Thanks!
A.
ps. I’m talking about OH2, but I’m interested to know if it would be possible also with OH3 for the near future
I had this problem too. I created sesonal areas in my ui which could be enables by a virtual switch. Eg. One switch for summer time, one for xmas. In these areas you should be able to set the lables as required.
Another approach is to set the label in a rule based on some kind of area switch like in the example above.
An a third approach is to have v virtal switch and you assign your physical switch to this virtual using some kind of selection. So in your configuration area you have something like Living Room Fan and you should be able to assign the switch SmartPlug01 and in Winter you assign your xmas tree the Smartplug01. BEnefit from this approach is that the assigment is dynamic. If you SmartPlus01 is assigned to another thing just select SmartPlug02
Unfortunately i never brought option three to live, but this is my preferred one.
It is written for Jython though, so you’ll have to have that installed. I also currently don’t have it published anywhere but I can fix that if you’re interested.
Basically you have 4 groups that you put items in:
Command Endpoints receive commands and send them to the real device.
Update Sources provide updates from real devices.
Command Sources are virtual items that provide commands.
Update Endpoints are virtual items that receive updates.
Generally you will have a Command Source and Update Endpoint set to the same item, likewise for Command Endpoint and Update Source, but the option are separate so you have the flexibility.
Then the rule runs periodically and checks for items in those groups and generates a sitemap with all of the link items. Each item in the sitemap provides a selection list of all the items it can be linked to.
During refresh it also creates a rule that is triggered by commands and updates to each type of source. When one of these rules fires it looks for the appropriate link and forwards the event.
In order for the links to be retained, you can provide the name of your persist restore group to the script. Alternatively you could modify your persistence settings to restore the links group at startup.
Couldn’t you just create 2 items for the se channel? So you can tell google to turn on the Xmas tree or to turn on the fan with the same result -> your plug is turned on
As already suggested, I’d use multiple items pointing to the same thing/device. In sitemap you can use the [visibility==...] tag.
Option 3 is fine, too, but mind the effort involved and that it’s just for a couple of things, to change maybe twice a year.
@CrazyIvan359 I think it would great if you share your code.
In my world the option to configure things from the ui and not going into textfiles or whatever is one of the main missing parts in openhab. But such functionality keeps the WAF high.
Just pick up a pluf for the xmas tree go to the ui and select xmas tree uses plug xyz ready. That is komfort. Often the smal thing are the relvant ones.
Exactly. I have put labels on my plugs that are attached to the command and update items that control the device. You just find the front-end item (eg Christmas tree lights) that you want it to control and select it from the list.