BUG(?): Suddenly cannot "Add a Task" in WebCoRE piston

[LibraSun]

Though I'm fairly new to WebCoRE, I get the concepts and can navigate my way around just fine, with a couple of working pistons under my belt.

But all of a sudden, while building out a subsequent ELSEIF portion of my current piston, WebCoRE seems reluctant to let me complete an "Add a Task" (as shown in screenshot).

I have chosen the predicate device(s) -- all of which are basic virtual switches, btw -- and normally would proceed to assign a task like "Toggle" which applies to the group.

Nope! WebCoRE has other ideas. I Save'd my work for the day and gave up.
Anyone else stumble across this roadblock?

Seems that lately, when attempting to venture into deeper waters, I keep encountering stumbling blocks like this which give me pause (esp. knowing I'll spend the next 20 minutes documenting and filing a bug report or Goggling up a quick fix).

Insights welcome! Feels like either a basic glitch/anomaly, or somehow a browser-related bugaboo unique to Chrome/Win10.

BONUS POINTS for anyone who can tell me whether SWITCH/CASE statements are available in the Hubitat-specific instance of WebCoRE, as I'd very much prefer using that syntax vs a series of nested IF-THEN-ELSEIF's.

[nh.schottfam]

webcore should have switch / case (as much it had in ST)

If you can private message me more details on how to reproduce your issue, I'll take a look.

I do agree try another browser to ensure it is not browser related.

[nh.schottfam]

[LibraSun]

Thanks for the tips. I had yet to turn on "Advanced" in order to see Switch as a command option; now, I do. However, like many before me, I found the SWITCH / CASE unfriendly toward matching particular Physical Devices to a {$currentEventDevice} situation.

I had to fall back to handling each match with a series of IF - THEN - ELSE IF's, which worked. I'll revisit my piston on a better day.

[nh.schottfam]

If you can show me a small example piston that demonstrates the problem on the match, I can look into what is the issue.

A small green piston is best here.

[LibraSun]

I can boil it down to the following four approaches, only one of which "works".

THEN

VERSION 1 (indicated actions in Case don't take place):
SWITCH {$currentEventDevice}
CASE 'Porch Light' ◄— the exact name of device that triggered, as a (text) Value

<actions go here>

VERSION 2 (indicated actions in Case don't take place):
SWITCH {$currentEventDevice}
CASE 'Porch Light' ◄— the physical device that triggered, as a Physical Device (which forces you to select an attribute, either *switch* or *status*)
<actions go here>

VERSION 3 (indicated actions in Case don't take place):
SWITCH {$currentEventDevice}
CASE {[Porch Light]} ◄— the physical device that triggered, as a bracketed Expression
<actions go here>

VERSION 4 (indicated actions in Case DO take place):
IF {$currentEventDevice} is equal to 'Porch Light' ◄— name of device that triggered piston, as a Physical Device (no attribute selection required)
THEN
<actions go here>

Sorry, I know you asked for a green piston copy, but I'd have to go build it and I'm actually making lunch for the family. I Googled the heck outta this issue, and found others having the same complaint(s) about implementing SWITCH and CASE reliably for $currentEventDevice, and none of the offered solutions seem too well founded.

[LibraSun]

OK, finally had the chance to concoct a test piston solely to check which version(s) of the IF-THEN-ELSE or SWITCH-CASE clauses will successfully match against a particular trigger device. Posting the green snapshot below. Hope it's clear what I'm doing, but in case not...

The piston is set to trigger when the virtual switch Grid_UL is turned on. I preset four variables to false which later get changed to true if their surrounding statement matches. Then the piston sends me an email showing the values of all four variables (is there a simpler way to monitor local variables at runtime?!?).

And here's what the email said:

IF clause = true 
CASE clause (Exp) = false 
CASE clause (Val) = true
CASE clause (Phy) = false 

Gotta say I was a bit surprised by the third one (CASE using 'Value') succeeding, because it differs from earlier experience. I may need to reevaluate its utility going forward.

[nh.schottfam]

Here is my test that seems to work...

I was able to match either device

I'm running latest webcore (do HPM repair to ensure you have it) and I'm on latest HE firmware.

I don't think this should really matter.

I used a variable and a value match. Value was not quoted in any way.

[LibraSun]

Excellent! I follow your example perfectly. My only question here is, "Could you have placed that vswitch1 directly inside the first CASE without resorting to defining dev? I think that's essentially where I was running into confusion for some reason.

[nh.schottfam]

Porch Dimmer

was me putting it directly in the case. It is a value, no quotes.

[LibraSun]

I was referring specifically to your first CASE statement, not the second one. Could you have designated a device directly there instead of defining an interim variable?

That is, instead of
define
device dev = vswitch1;
end define;
...
case {dev}

could you have written it more compactly as
case vswitch1 ◄— this is where the "physical device" picker was confounding me.

[nh.schottfam]

I did not try a physical device type comparison, but you can give it a try if you like.

I did variable, and value comparisons to see that they worked. (where variable was a device type variable).

If you find a problem, post short piston and I can see if webcore is doing something strange.

I do think webcore if you say physical device the UI tries to force you to select an attribute.

ie physical device is really phyiscal device attribute.

@ipaterson could likely comment on this.

[ipaterson]

@nh.schottfam

I do think webcore if you say physical device the UI tries to force you to select an attribute.

ie physical device is really phyiscal device attribute.

Technically the switch case can be an expression [Porch Dimmer] but that doesn't provide any benefit over just testing the device name. It might even be interpreted as just the device name, I'm not quite sure how that works (but it does).

It's also worth noting that the switch case does not work if the device variable includes multiple devices. I've experienced plenty of misery in the past trying to do fancy things with device references.