What is the smartest way to manage "seasonal" smart plugs?

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 :slight_smile:

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.

Hope this helps

Thomas

Multiple Items for each plug Thing, one for each use case and each with its own label.

I assume you are not referring to physical labels on the physical plugs.

2 Likes

@Dibbler42 I did bring option 3 to life!

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.

1 Like

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

1 Like

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.

1 Like

Indeed, my solution was not designed for this purpose. I built it so be able to repurpose the smart plugs I have that can be used anywhere from a UI.

@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.

1 Like

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.

I will post later this evening, busy day today.

1 Like

The best solution of course is to treat yourself and solve the problem by putting some extra plugs under the Christmas :christmas_tree:
:grinning:

1 Like

Thank you all!
I think I’m gonna try a couple of the suggested solutions and see what suits me best (additional items and/or using rules)

The Jython one seems a little overkill for me (considering also I’ve never used it).

As the Christmas is near…also the “treat” choice could be viable :grimacing:

Thanks!

I forgot I had submitted it as a community script to the helper libraries long long ago. You can see Selector by comparing the branches.

It will generate a sitemap called Selector that looks like this:
image

@Dibbler42

1 Like

I have to check that very carefully, but it look impressive.

This is what i do as well. I use the visibility tag as well as a virtual switch in a “settings” sitemap called “christmas time”

Christmas time switches the labels on some of my switches to go from “end table lamp” to “LR xmas lights”

It also acts as a trigger in a few of my automations.

Going to bed, if xmas time, when i turn off the lights for the evening it turns off my outside xmas lights too.

It also triggers my xmas lights and decorations to turn on right around sunset.

1 Like

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.