SWITCH Case or IFs?


#1

Greetings peeps,

I’m trying to “clone” the actions of one switch with another without have a piles of IFs. I thought about using SWITCH and CASE, but I don’t think I’m using it correctly. I just want to:

If any of these switches turns on… (start the cloning)
then
If This Switch… do this,
If That Switch… do that,
If The Other Switch… do something else…
etc.

But when I try CASE, it asks for an attribute of the case… I.E. case Switch:Mirror’s switch

I don’t want to reference each physical switches attribute… just the physical switch itself.
i.e.
case Switch:Mirror (but no attribute).
do something
case Switch:Shower (but no attribute).
do something
_case … etc

This can replace having to do something like
If WhichOne = SwitchMirror then
If WhichOne = SwitchShower
etc.

Am I wrong to try and use SWITCH and CASE?


#2

instead of physical device, use expression for the case statements. In the expression, just enter the device name in brackets, e.g. [Dimmer 8]. Not sure if it will function properly but it will accept the devices as cases in that way.


#3

You’re right. Switch/case doesn’t work the way you’re expecting.
{Dimmer 9’s switch} will evaluate to ‘on’ or ‘off’ so you’re better off using IFs.
You can also use the Smart Lighting in Automations to mirror switches. Since it runs internally on the hub, it will operate faster than webCoRE, which has to go out to the cloud and back to function.


#4

agree with @qoheleth the Smart Lighting is probably easier. The switch statement does work with devices, however, as I tested in this simple piston.


#5

Interesting… {deviceList} is nowhere in your code…
How is that possible?!? Where is the trigger?


#6

Sorry for the confusion. I inserted the deviceList definition but later realized I didn’t actually need it and never went back to delete it. The point was being able to use devices as switch cases and I just set ‘whichOne’ to one of the four devices in switch statement. Interestingly, the green snapshot obfuscated the original list but not the device names in the case statements.


#7

Thanks for the replies.
FYI… for some reason my email client on my phone wasn’t letting me know I was getting mail (updates from this thread) since last week. I’m not trying to be rude by the absence. :frowning:

Anyway… yes the EXPRESSION suggestion did work for the CASE statements.

The reason I’m not using smart lighting is I also want to match LEVELS back and forth from the light to the switch… depending which one’s level changed first. My issue is my bathroom has two independently controlled RGBW LED strips, but the modules are the Fibaro RGBW Controllers. Cannot directly add switches to them. So what I’ve done was get two Leviton DZ6HD-1BZ dimmer switches. They are 110v powered, but NOT connected to anything. I just use the info (on/off or adjusted levels) in webCoRE. If either light or switch is turned off, then the piston matches that to the other. These switches make it easier to use for us instead of accessing though a wall-mounted tablet. Now the trick is getting the levels to match. I’ve got that working, but the problem is, when the switch gets turned on or off, in either the light (though the tablet) or the switch on the wall, the piston reacts to both and not just one.

So what I mean is, if you turn on the switch, it turns on the light. But the piston also sees the light turning on and says, hmmm… time to turn on the light switch. This is why I wanted to use the CASEs. I was hoping that when a switch would turn on, it’ll turn on the light, match the switches level, and stop. But the piston also reacts to the fact that the light was turned on (even though I told it to programming wise) and tries to match the switch (i.e. turn on the switch and match the level). It’s kind like a loop that gives up on itself. Very frustrating.

And that without actually adjusting the levels on the switch yet. That produces it’s own problems. I’m trying a boolean variable “SomethingAlreadyON” to act as a logic toggle so when the switch is physically turned on and the light gets matched… it’ll stop. It won’t go and try to match the switch too because the piston turned on the light.


#8

A good rule of thumb:
Never code a command that matches a trigger in the same piston.

IE, do not do this:

ϟ IF Switch1 changes
     Then with Switch1, do X
  END IF

This can create an infinite loop…


In your case, I would avoid double triggers in the same piston:

ϟ If Switch1 changes
     Then turn on Light2
  End IF

ϟ If Light2 changes
     Then with Switch1, do X
  End IF

This can also create an infinite loop…


Very very few devices report any difference between physical and programmatic interactions…
I always choose “ANY” like this:

temp


#9

Thanks for the reply.

Here’s two images. The first is the piston with the ON/OFF part only set to run for testing purposes.
What I’ve determined (with the counter) is:

  • switch turns on, which I then turn on the Smart Light.
  • counter increases by 1
  • LOG displays “made it though the ON phase” and counter total to prove piston completes the entire CASE and doesn’t execute the Smart Light CASE
  • the piston exits normally
  • now because the Smart Light turned on, piston runs again :frowning:
  • LOGGED message proves the Smart Light CASE ran… when it wasn’t needed

These shenanigans need to stop.

You can see in the second image the name of the Smart Light showing the piston ran for a second time.


#10

Well, to be fair, you are sending a command that is also a trigger in that piston.

In other words, do not do this:

IF any of RGB Bulb 3 or Dimmer 9's switch changes
Then
    With RGB Bulb 3 and Dimmer 9, Set level to 100%
END IF

Sometimes, a “Set Level” command is seen as a “switch” command, so you run the risk of creating a loop here.

IE: If level is X, and the bulb is turned off, then a future command of “Set level to X” will be seen as a “Turn on” command (since the level does not change). …and of course, a “Turn on” command starts the piston over at the top


#11

I agree.

So the problem is, how can I get around this? I need to do this to two pairs of switch/light combos.
Then there will be the issue of matching levels while all is on, but that’s later. :wink:


#12

I would re-think your logic. Commands sent should never trigger the same piston, unless you want a loop for some reason…

Another way to say this, don’t try to control a device’s attributes that is also in the trigger.

Device A trigger sends a command to Device A = Asking for trouble
Device A trigger sends a command to Device B = Smooth sailing