openHab 1.8.3: Switch in switch command possible?

  • Platform information:
    • Hardware: Raspberry Pi 3B+
    • OS: Raspbian
      PRETTY_NAME=“Raspbian GNU/Linux 8 (jessie)”
      NAME=“Raspbian GNU/Linux”
      VERSION_ID=“8”
      VERSION=“8 (jessie)”
    • Java Runtime Environment:
      java version “1.8.0_65”
      Java™ SE Runtime Environment (build 1.8.0_65-b17)
      Java HotSpot™ Client VM (build 25.65-b01, mixed mode)
    • openHAB version: 1.8.3
  • Issue of the topic:

I created a “combined” MQTT command under a new switch like so:

Switch Sw_Oversteek_Fietspadverlichting "Oversteek - Fietspadverlichting" <switchnew> (Lights)
    {mqtt="
    >[geertvc:home/gelijkvloers/LightChange/Lt_Oversteek_Garage:command:ON:MAP(openclose.map)],
    >[geertvc:home/gelijkvloers/LightChange/Lt_Oversteek_Garage:command:OFF:MAP(openclose.map)],
    <[geertvc:home/gelijkvloers/LightChange/Lt_Oversteek_Garage:state:MAP(openclose.map)],
    >[geertvc:home/gelijkvloers/LightChange/Lt_Oversteek_Inkom:command:ON:MAP(openclose.map)],
    >[geertvc:home/gelijkvloers/LightChange/Lt_Oversteek_Inkom:command:OFF:MAP(openclose.map)],
    <[geertvc:home/gelijkvloers/LightChange/Lt_Oversteek_Inkom:state:MAP(openclose.map)],
    >[geertvc:home/verdiep/LightChange/Lt_Oversteek_Kleine_Living:command:ON:MAP(openclose.map)],
    >[geertvc:home/verdiep/LightChange/Lt_Oversteek_Kleine_Living:command:OFF:MAP(openclose.map)],
    <[geertvc:home/verdiep/LightChange/Lt_Oversteek_Kleine_Living:state:MAP(openclose.map)],
    >[geertvc:home/verdiep/LightChange/Lt_Oversteek_Keuken:command:ON:MAP(openclose.map)],
    >[geertvc:home/verdiep/LightChange/Lt_Oversteek_Keuken:command:OFF:MAP(openclose.map)],
    <[geertvc:home/verdiep/LightChange/Lt_Oversteek_Keuken:state:MAP(openclose.map)],
    >[geertvc:home/verdiep/LightChange/Lt_Oversteek_Zit_En_Eetruimte:command:ON:MAP(openclose.map)],
    >[geertvc:home/verdiep/LightChange/Lt_Oversteek_Zit_En_Eetruimte:command:OFF:MAP(openclose.map)],
    <[geertvc:home/verdiep/LightChange/Lt_Oversteek_Zit_En_Eetruimte:state:MAP(openclose.map)]"
    }

However, those commands are also defined already under existing switches, like so:

Switch Sw_Oversteek_Garage "Oversteek - Garage" <switchnew> (OD_Oversteek, Lights)
    {mqtt="
    >[geertvc:home/gelijkvloers/LightChange/Lt_Oversteek_Garage:command:ON:MAP(openclose.map)],
    >[geertvc:home/gelijkvloers/LightChange/Lt_Oversteek_Garage:command:OFF:MAP(openclose.map)],
    <[geertvc:home/gelijkvloers/LightChange/Lt_Oversteek_Garage:state:MAP(openclose.map)]"
    }

As you can see, the first 3 MQTT commands of my “combined” switch command are the same as the ones defined for my single Sw_Oversteek_Garage switch.
The same is valid for the other MQTT commands in my “combined” switch command: they already exist under another switch definition.

Question:

Instead of redefining the MQTT commands literally in my “combined” switch command, can I refer to the existing switch commands from within my “combined” switch command?

Something like this:

Switch Sw_Oversteek_Fietspadverlichting "Oversteek - Fietspadverlichting" <switchnew> (Lights)
{
    Switch Sw_A,
    Switch Sw_B,
    Switch Sw_C,
    ....
}

I know this is a simplistic representation, but you know what I’m trying to achieve…

This would avoid having to type the same MQTT commands twice: once for the individual switch commands and once for the “combined” switch command.

PS: Yes, I’m still using openHAB 1.8.3 to my great satisfaction… Don’t see any reason yet to move over to the bleeding edge openHAB stuff…

OH 1 supports Groups. Send a command to a Group, it gets distributed to all member Items.

OH2 is more than 5 years old. Interesting pov to call that ‘bleeding edge’.

Read the following thread.
It’s always unexpected events that can all of a sudden force you to upgrade.
I wonder if jessie Raspbian is still available for download should your SD crash.
Better prepare in time.
Note you’ll have to completely redo your MQTT config.

With “bleeding edge” I meant the “latest and greatest” OH release, not the OH2 one…
I’m not even using OH2, it’s still OH1 by the way…

I know the stuff is “old”, but if it still serves my needs, what’s the issue? If you have a 5 years old car, do you buy the newest model because there’s… well… just the newest model? Even if it’s safer than your current one and has more options and… and…
I know the comparison is a bit exaggerated, but you get my point…

I’m not saying I’m not gonna change over time, though… My home system is not build “on top of” OH. No, OH is “on top of” my home system.
I’m using Pi4j to control my real hardware (which also talks to the MQTT broker) and openHAB is “just” there to be able to control my system from a browser, phone, tablet…
I know that using the word “just” is not correct here, absolutely not… openHAB is therefore too powerful, too multifunctional, too…
I’m also using rules in openHAB to do stuff. But since Pi4j is the core of my system, the move to OH2/3 might go a bit smoother for me. The only thing that stops me from doing it now, is that OH2/3 needs Java 11 (at least) while I’m still at Java 1.8. And since that’s still running the core of my system, I’m a bit reluctant to do it right away…

Next to this, my system is an intranet system, not an internet system. So, security is not an issue for me, all stuff remains inside (that’s one of the reasons I started to use openHAB…)

Anyway, we’ll see what the future brings and one day I will make the move…

To stay with your car analogy, an Internet (software industry) year is commonly said to be 1/4 real year, so your car is 20 years.
Fine as long as it keeps driving but what if something now breaks up and you need a replacement part but cannot obtain it any more from your dealer? What now that cities start limiting access for old Diesels, (even in Germany the land of cars and Autobahn) ?
Sure even if some oldtimer car breaks you can still handcraft something, but are you aware how much hand crafting such a part will cost you ?
It isn’t about getting a bigger-better-faster-shinier car, it’s about ensuring it keeps driving.

Please read the thread I linked, at least my first post in there. The day will come you need to have your system migrated and whenever the event to break your current setup takes place you are “under the gun” to fix it fast.
That’s like skipping maintenance of your car, then having a breakdown en-route and you need to repair it in the wild, without access to replacement parts and proper tooling.

That’s not right, actually. OH3 does but OH2 does not.

Either way, your best bet is to install and configure another box from scratch while you keep your OH1 system running (and you can go to OH3.1 then right away).
Read the migration tutorial and hints mentioned in the thread.

Will make a start of it…

Just my two cents. I can somehow understand. It was painful to migrate to OH2. And then even more going to OH3. The comparison with a car might not be so wrong. I buy/build a house and stay there for a decade or decades. The software of the house once it works as I expect can and should be forgotten. But then, out of a sudden something central breaks and you won‘t get replacement. What to do? We can‘t get to the junkyard and search for a…
I decided to stay on top of the versions for two reasons:
A) I might need to replace hardware any day and it might come with new firmware which forces me to upgrade something else.
B) being out of the loop, even 6 months gives me hard time to remember how things work. I need to stay current.

That is just the price we pay for the free software people dedicate their time to.

PS: I left security out by intension