Nubee simple virtual 3-way help

#1

1.a) Background
Consider myself fairly intelligent but finding very little beginner help available. I have been playing with this for about a week, but cannot get over that initial hump that non-programmer types will have.

1.b) Give a description of the problem
Cannot get a very basic piston to work.

  1. What is the expected behavior?
    Front floodlight switch to turn on my barn floodlight switch (virtual 3-way)

  2. What is happening/not happening?**
    nothing

4)

download
download.png1178×605 53.7 KB

  1. Attach any log
    |+1ms|╔Received event [Home].test = 1533357029033 with a delay of 0ms|
    |—|---|
    |+81ms|║RunTime Analysis CS > 11ms > PS > 47ms > PE > 23ms > CE|
    |+83ms|║Runtime (37162 bytes) successfully initialized in 47ms (v0.3.106.20180731) (81ms)|
    |+84ms|║╔Execution stage started|
    |+98ms|║║Condition #10 evaluated false (8ms)|
    |+99ms|║║Condition group #1 evaluated false (state did not change) (10ms)|
    |+102ms|║╚Execution stage complete. (17ms)|
    |+103ms|╚Event processed successfully (103ms)|
#2

Hi Blaine,
Here is what I understand:
Front Flood Light is a simulated switch or an actual switch???
and
Barn Flood Light is a smart switch or a smart bulb
please correct me if I am wrong,
What is ($device) variable???

#3

Front floodlight is a GE switch and the barn floodlight is the same. the $device was a mistake. I deleted it.

download%20(1)
download (1).png1178×479 41.7 KB

#4

I don’t see why that wouldn’t work

#5

After about 20 trips up and down the stairs switching the front floodlight on and off I got it to work with this below. Something i don’t quite get is that the barn floodlight switch showed as on in the smarthings IDE when it was off. I asked alexa to turn off the barn light (which was already off) and it changed to off when I refreshed ST IDE. Why would the switch state be different than the actual state? Anyway, it works now until the barn floodlight state gets out of wack again. This is the most basic piston and it took a tremendous amount of effort and perseverance to get it to work. I am on the fence as to whether anything more complicated is worth the effort.

download%20(2)
download (2).png1178×685 58.4 KB

#6

I encourage you to not loose faith. I agree there is a learning curve for new-comers, but our community is filled with lots of great people who are more than willing to help with hurdles you encounter.

Remember, we are pioneers venturing into the future… so there are bound to be ‘unclear paths’ at times…

The good news is, I have not yet encountered a problem where I was unable to find a solution…
(even if I have to think outside the box)

I guess good advice for those just joining us is…

  • Start each piston off simple and basic…
  • Test it out…
  • and then add more code before testing again…

I basically follow this guideline for 90% of my pistons…

#7

You have your Off operator nested inside of the else of the On, which isn’t necessary. I would have that as it’s own function listed separately instead of in the else. Because the else will evaluate true more often then when it hasn’t changed.
Also, you mention that the switch isn’t reporting correctly in ST. Are you sure that both switches report correct in ST? Obviously the piston won’t work if it can’t get a report or control a device.

#8

Thanks for that. I did move the off action to it’s own function. It works everytime when I turn the front floodlight on or off from the ST app, but hardly ever when the front floodlight switch is physically activated. I changed the action to physical interaction instead of any interaction, but no fix. Even when I verify first that the barn floodlight is reporting off in ST IDE, then physically turn on the front floodlight, the barn light does not come on. I’m stumped. Several other simple pistons work fine with the front floodlight and barn floodlight.

download
download.png1178×786 90.3 KB

Toggle navigation
Front Floodlight
Status
This piston is currently active and humming happily.

Piston Category

Quick Facts
Piston state: true

Last executed: 8/6/2018, 9:25:33 PM

Next scheduled: never

Subscriptions: 1 event, 1 control

Devices used: 2

Memory used: 46% (45603 bytes)

External URL: (click to open/execute)

Automatic Backup
Automatic backup enabled.

Touch the box to reveal your backup bin code. Make a note of this code as you may use it later to restore a deleted piston.

oiw96

Do NOT share this code with anyone.

Script
//
/* Front Floodlight */
//
/* Author : blaine phillips /
/ Created : 4/24/2018, 9:48:59 PM /
/ Modified : 8/6/2018, 9:23:55 PM /
/ Build : 38 /
/ UI version : v0.3.107.20180806 */
/**************************************************************/

/* Turns barn floodlight on or off */
execute
end execute;
Logs
8/6/2018, 9:25:33 PM +991ms
+1ms ╔Received event [Front Flood Light].switch = off with a delay of 341ms
+123ms ║RunTime Analysis CS > 11ms > PS > 46ms > PE > 66ms > CE
+125ms ║Runtime (38184 bytes) successfully initialized in 46ms (v0.3.106.20180731) (123ms)
+126ms ║╔Execution stage started
+134ms ║║Comparison (enum) off changes_to (string) on = false (1ms)
+135ms ║║Cancelling condition #10’s schedules…
+136ms ║║Condition #10 evaluated false (5ms)
+137ms ║║Cancelling condition #1’s schedules…
+138ms ║║Condition group #1 evaluated false (state changed) (6ms)
+140ms ║║Condition group #11 evaluated true (state did not change) (1ms)
+145ms ║║Comparison (enum) off changes_to (string) off = true (0ms)
+147ms ║║Cancelling condition #16’s schedules…
+147ms ║║Condition #16 evaluated true (4ms)
+148ms ║║Cancelling condition #13’s schedules…
+149ms ║║Condition group #13 evaluated true (state changed) (7ms)
+151ms ║║Cancelling statement #14’s schedules…
+169ms ║║Executed physical command [Barn Flood Light].off() (14ms)
+169ms ║║Executed [Barn Flood Light].off (16ms)
+172ms ║╚Execution stage complete. (45ms)
+173ms ╚Event processed successfully (173ms)

#9

The last I heard, most devices do not distinguish between the two, which means webCoRE usually cannot tell the difference. I recommend going with “Any Interaction”. (which will catch all events regardless)

On a totally unrelated note, I would delete both occurances of these lines of code:

temp

I mean, technically, it shouldn’t hurt to keep them there, but it’s usually a good practice to tidy up useless code. (which will also keep your log less cluttered)

Although even after saying that, your log looks healthy to me…
(executed in less than 0.2 seconds)

+1ms ╔Received event [Front Flood Light].switch = off with a delay of 341ms
+169ms ║║Executed [Barn Flood Light].off (16ms)
+172ms ║╚Execution stage complete. (45ms)
+173ms ╚Event processed successfully (173ms)

To help me understand this part better… is your:

a) front floodlight BULB smart?
b) front floodlight SWITCH smart?
c) front floodlight bulb & switch BOTH smart?

If your answer is c) then I think I know what is happening…

#10

I really appreciate your response.

I originally had it set to Any Interaction as that was my thinking too. It did not work and that’s when I tried Physical Interaction. You appear to be correct that it doesn’t make any difference because it still works from the ST app when I turn on the front floodlight when I have Physical Interaction set in the piston.

Your last question is understandable, so I won’t take offense :wink:

Front floodlight is GE Zwave switch with Halogen bulbs
Barn floodlight is GE Zwave switch (not the add on type) also with Halogen bulbs.

I do have a GE Zwave add on in my garage that controls the barn light as well as a virtual 3-way. It is very fast and I think is controlling it direct connect? or something like that.

I also have my back deck light HomeSeer that controls it via double tap.

#11

Just a note on switch interaction — ST removed that capability in their Z-Wave Switch handler sometime near the end of last year :frowning_face:. However, I think one of the Z-Wave Switch handler templates (From Example tab, selectable when you create a handler in the IDE) still has interaction enabled. You can try to use that if you really need interaction detection with your GE switches (other than their dimmers, I think.)

#12

Uggg, I did not realize that SmartThings pulled the plug on those devices… Unfortunately I do not have one of those to test. Maybe a user of GE Zwave Switches can chime in…

Thanks for bringing that to our attention @elf. You make a great point… If SmartThings is not detecting the Zwave switch, then we cannot expect webCoRE to see any changes either…

What this means is you can totally ignore this piston (for now) and focus on getting SmartThings to detect when the Switch is physically toggled. Once ST reliably sees the changes, your piston should be a breeze to get working.

I would try @elf’s suggestion in the last post to work around this issue…

On a positive note, this also means your logic has been sound in creating this piston from the very beginning. We can direct our frustration towards SmartThings instead of webCoRE! :sunglasses:

#13

Just as an FYI. I have the same virtual 3-way setup in my bathroom using 2 GE Zwave+ switches. We have a physical switch that turns on the light next to the door from the bedroom. We also have a set of switches that turn on heating or exhaust fans near the other door.
So I wired a switch to the power for the heat/exhaust switches and didn’t wire the load at all. Then I rigged up a piston that looked very similar to yours to “sync” the two switches. It mostly worked, but occasionally I could “confuse” the switches if I toggled one back and forth within 5 seconds.
I already had the “Smart Lighting” Smart App installed and jkp suggested I use that instead. You have to set up two rules (one for each switch to “mirror” the other). Not only does it work without the confusion issue, but the lag time between the mirror action is faster than the piston as well. (The two are probably related as I suspect the confusion is related to latency.)
So, the tldr bottom-line is that you can use GE Zwave switches and I’d suggest you use the Smart Lighting Smart App to make them work together.