Having trouble with virtual three way (tried using Big Switch)

I don’t code smartapps (Groovy does not go well with text-to-speech), but this doesn’t sound quite right. If a smartapp causes a device to change state, it’s up to the device (not the app) to report that state change to the hub.

If it’s a light switch, it may be prohibited by the Lutron patent, but that’s a separate issue. But perhaps I’m wrong, and there’s some special ST code issue I’m unaware of.

@tgauchat or one of the other expert coders should know.

Edited to add I just tested this with The Big Switch smartapp. I set a hue bulb to trigger both a zwave switch and a virtual switch. Both updated their tiles in the ST mobile app. So I must be misunderstanding something about your use case. Could you give a few more details, including the models of the sensor and garage door controller? And the device types of the two tile switches?

JD - thanks for pointing all of this out. You are right that associations are not what I want. I will take another look at using a smartapp to do this. I did not try, rather I had just assumed I couldn’t do this with an App because the relay switch only has two defined states - off and on. I would have to add two states to get a total of four. The four states would be: open, opening, closing, closed. The current momentary push would lead to either an opening or closing state. The sensor would send a report to the relay switch device telling it that is is open or closed, and then the device can change the tile appearance. By the way, I use the LFM-20 relay devices. The problem I am having right now is figuring out how to send an event or message to the Relay switch that the door is open or closed when the device does not support such a status. Given your simple test case I think I can use Big Switch to do this but I’m not sure. In your test case was the tile update based on a pre-defined state supported by the switch? Does this matter? Anyway, now I am going to really try.

Update: I tried and no cigar. Here’s the deal. I wrote a simple edit to the Lights Off, When Closed smartapp to send a message to my Relay when the sensor reports an open or closed state. The problem is the recognized methods are only on(), off(), refresh(), and push() – and I need two new ones to change the icons. If I use on() or off() the garage will open or close and that is not what I want. This is why the simple example JD reported works but this doesn’t. If I can figure out how to register new methods in a virtual device type I will be all set. I tried just adding a def open() method as follows:

def open() {
    log.debug "switch open status reported"
}

def closed() {
    log.debug "switch closed status reported"
}

in the device type and that didn’t work. Any suggestions? Once I know the handler is called it should be easy to change the icon in the device type code.

okay - last update. I have it figured out. Added capability “Door Control” to my custom device type and that exposed two new methods named “open” and “close” that are now being called properly to report the status. Now I just need to figure out how to change the display on the tile to reflect the new status knowledge. I think this last final step will be easy!!! Stay tuned - I will post the smartapp and the custom momentary switch when it is all done in a new clean post.

EcoLink z-wave sensor for the open/close status
Evolve LFM-20 relay switch to open and close the door via momentary switch device

I made a revised virtual device type designed to have 4 states instead of 2. Now I will try to write a smart app to send an event to invoke the two new states. I hope this works.

standardTile(“switch”, “device.switch”, width: 2, height: 2, canChangeIcon: true) {
state “off”, label: ‘${name}’, action: “momentary.push”, icon: “st.switches.switch.off”, backgroundColor: “#ffffff
state “on”, label: ‘${name}’, action: “switch.off”, icon: “st.switches.switch.on”, backgroundColor: “#79b821
state “open”, label: ‘${name}’, icon: “st.doors.garage.garage-open”, backgroundColor: “#3399ff
state “closed”, label: ‘${name}’, icon: “st.doors.garage.garage-closed”, backgroundColor: “#0011cc
}

You can ignore this post … the one above is current. This experiment didn’t work.

If I understand what you’re saying (and I may not), you can’t add new states to a physical device through a device type/device handler. You can only implement states that the physical device already knows. Because it’s the physical device that will actually send the status update information to the hub.

If your relay only has two states, it only has two states. That’s all its tile can report.

You can combine information from two devices and store that as the state of a virtual device (a lot of people do that with virtual switches), but I’m not sure that’s going to get you exactly what you want, either. It sounds like that’s what you already have set up, but your family is ignoring the “status light” switch when it comes to making their decision about closing the garage door with the physical device switch…

Which makes it a UI problem.

If you’ve read my other posts on garage door you know I mostly hate unattended closure, so I may not be the right person to discuss this. But it seems to me you might solve a lot of the UI problems by just reversing the status in the device handler so that the tile reads as always closed instead of always open. But the status light tile still shows the correct status and could send notifications, etc that you yourself could then deal with.

Just a thought.

This is what I am trying to do but have the single virtual device show the sensor state and operate the momentary switch. I am almost there - just can’t figure out how to get the momentary switch to show the sensor state. I will look at some sample code from others who have done virtual devices to figure out how to do this. Looks like I found just the thing here:

You have been a huge help as always.

ST noob question here after reading this thread and posting the below to replies in the wrong forum (apologies to moderators for double posts) - advice needed for “virtual 3-way switch functionality”

About eleven years ago I remodeled my entire home & installed a boatload (over 50) high-end Leviton “old school” X-10 light switches (HCM10-1TW). My brilliant idea at the time was not to run traditional “3-wire” for 3-way switches anywhere. I instead used these “virtual 3-way” switches in such places like at the top of a set of stairs (HCC4A-1TW) where I needed to turn on/off a set of light switches that were at the bottom of the stairway - standard 3-way switch stuff here. The HCC4A-1TW is just a controller device sitting in a 1 or 2 gang box that has electricity.

Fast forward now 11 years later - X-10 is basically dead, my old switches don’t support LED, etc. I knew Smart Things along with Z-wave was a great match so I have just been waiting for the right time for things to mature.

So now my Smart Things noob question;

If I don’t want to use the ZWN-SC as a “direct replacement” for my old X-10 HCC4A-1TWs can I use an extra z-wave compatible switch (say a WD500Z-1) at the top of my stairs to simply fire off a macro when pushed that would then turn off/on/toggle three other switches that do have lights connected (say at the bottom of my stairs)?

I did read this entire thread and it seems that at least in recent months the ZWN-SC7-W is for the most part behaving for most people along with the virtual-buttons app (or whatever it is in ST speak - again I am a noob). Sounds like with that in place each button can be mapped to a function.

So my plan in a perfect world would be to use a standard WD500Z-1 wall switch as a “basic toggle” for simple use cases as a replacement for a standard 3-way switch provided the switch can be used as some sort of macro trigger. For more complex areas I would use the ZWN-SC7-W to do basally the same thing but have more buttons.

Will this work?

Thanks

Replying to my own post here because the forum only allows noobs to place three hyperlinks in a post :).

I found this WT00Z-1 Linear Z-Wave 3-Way Wall Accessory Switch that is supposed to work nicely with the WD500Z-1 switches I have been looking at.

Checkout this feedback post on Amazon

It took me a while to completely understand how this thing worked but I love it now that I understand it. In order to pair this device directly with another linear Z-wave wall switch, you need to have some type of Z-wave remote that will pair them up. However, depending on what smart hub you’re using, you may not need to do this. I use Samsung SmartThings. Instead of pairing this accessory switch with my Linear WD500Z, I just used “Smart Lights” to control the WD500Z with this switch. In other words, when I turn this switch on, SmartThings turns the WD500Z on. When I turn this switch off, SmartThings turns the WD500Z off.

I have this switch at the top of my basement stairs. I have it set so that when I turn this switch on, it turns on the stairs light AND the basement lights. Since I’m using SmartThings to control what happens when I control this accessory switch, I can make anything happen when I use it. The possibilities are endless.

So it seems that my quest for a “basic toggle” can be satisfied with this -BUT - ironically this thing costs $1 MORE than the load carrying WD500Z-1 switch! So could I still use the WD500Z-1 for the same purpose?

EDIT - OK I did some more research and think I know more now but I still need some help. Take a look at the last post / explanation in this thread by JDRoberts.

Basically the “scene controllers” (including the WT00Z-1 and ZWN-SC7-W) have the ability to communicate DIRECTLY to the switches with nearly instantaneous off/on response. This is important because the v2 ST hub still doesn’t support local processing yet (really?) not to mention what happens if the internet connection is down.

The key here seems to be first establishing this direct connection with a scene controller device & its associated switches and THEN using the Smart Things hub as a secondary communication mechanism. This seems like the the best of both worlds without trade-offs.

From what I am reading all of this seems to be possible but the exact recipe and steps aren’t clear. For instance I think I need one of those Minimotes to establish the direct connection but then I can somehow dissociate it so the ST controller can take over but in such a way that the direct connection initially still sticks.Not sure however if this causes state confusion when the button is pressed at the scene controller.

Also can MULTIPLE WT00Z-1s accessory switches be used (in “direct mode”) to control a single or more WD500Z-1 switches?

Am I getting all or any of this right?

I know you read everything in the Enerwave SC7 thread, but did you read everything in this thread? Because I think it answers most of your questions.

Briefly:

One) the Aeon minimote can create associations between 2Z wave devices, but only if each device supports association.

  1. assuming both devices do, then the minimote Will act as a secondary controller to the smartthings hub. So all the devices, including the minimote, are joined to the smartthings the zwave network before you start the associations. (Again, see the posts above for details. That should also clear up the confusion about what you’ve called a “direct connection.” The association is created by the minimote, but the devices remain known to smartthings from the beginning.)

  2. you can have multiple associations, such as two secondary switches controlling the master in a four-way set up, but only if all the devices can handle multiple associations. Some can, some can’t. i’m not sure on the linear model you mentioned, but I think it can handle a four-way set up.

  3. The main thing to understand is that if you do use direct association rather than going through the hub each time, the hub will not necessarily know the status of the devices whenever the direct association is used. That’s sort of the point. Direct association is only used when you want to bypass the hub altogether.

So most people using SmartThings won’t need to use direct Association, they will use hub communications instead. If you use hub communications, you can have a ZIgbee switch as an auxiliary and a zwave switch as the master and everything will work fine. You can also have as many auxiliaries as you want up to the total limit of devices on a SmartThings network.

You can even use virtual switches in your groups or as part of a three-way combination, which then let you use other kinds of devices to trigger events.

Finally, if you use hub communications you get to apply all your usual rules like time of day, who is home or not home, temperature, mode etc. For example the same light switch could turn on the overhead lights in the evening, but only turn on a nightlight late at night. If instead you use direct Association, you can’t apply any filters to it. Device A will always trigger device B if the two are directly associated.

So not using direct association is a much more flexible option when you have SmartThings. If you do want to use it, you can, but it’s likely that your status indicators will get slightly out of sync from time to time and you will have fewer control options.

If you do you want to use direct Association, then the minimote works very well to set it up as discussed above. :sunglasses:

Many thanks for the quick reply. The other tho threads alone had over 1,200 post to go through and I wasn’t quite connecting all of the dots. I ordered several switches, the ST hub, and multiples of basically everything I had in my post to experiment with in one area as a POC. In a perfect world I don’t think anyone wants “direct associations” between devices but due to the lack of local execution on the ST controller its seems to be a necessary evil in some cases (i.e. lag and internet connection failure situations). Hopefully if this can get fixed with either a firmware update or even new hardware all of that goes away.

I think the real problem here is a lack of a “cookbook” for what seems to be some basic & common things like 3-way or greater virtual switch scenarios in combination with what seems to be a relatively limited universe of controllers and other hardware. I know ST can’t support everything but with the help of a great community like this there is great opportunity for end users to help end users. These forums and robust dev community are evidence of that.

I will do my part by documenting as best I can the journey I am embarking on. I will create a new thread after I accumulate some notes. Hopefully I can come up with a working cookbook for at least the hardware I mention above in conjunction with my use cases. Before I go into “prod” I can experiment with options and publish the pros / cons / trade-offs of each.

Domenic

1 Like

So:

  1. get a minimote. If it’s gen 1, that’s fine, but you may need to update the firmware. Some retailers, like www.zwaveproducts.com , already update the firmware before they ship the product. Just read the product description carefully.

  2. pair all the devices, including the minimote, to ST.

  3. use the minimote to set up the direct associations that you want. (I’m assuming the devices support zwave association.) Discussion of this is in the posts above. Remember that you associate the target first, and then the controller. A lot of people get confused on this. For example, if you want a light switch to come on when a motion sensor is tripped, you first use the minimote with the light switch, then with the motion sensor.

For a three way light, the auxiliaries trigger the master. So use the minimote with the master first, then the aux.

The steps for using the minimote are in their manual. It’s not clear from what’s written, but they are using the example of setting a motion sensor to trigger a light switch. Just remember target first, then controlling device(s).

http://aeotec.com/small-z-wave-remote-control/935-minimote-manual-instructions.html

The exact method for associating a device varies from manufacturer to manufacturer, so you need to check the device manual to find out just what to do. Usually it just means flipping the switch in a particular pattern or pushing a button on a device. The minimote manual says “Press the zwave button” but what they really mean is “put the device into association mode.” Exactly how you do that will vary by device.

  1. as long as both devices support it, you can set up associations in both directions. So switch A turns on Switch B and switch B turns on switch A. This is most often used when A and B are on two different circuits and you are trying to control the lights in a zone.

Once you get used to it, it’s easy. Good luck! :sunglasses:

Before I forget, if I recall correctly the Linear documention on these switches is incorrect with regard to association. You can still do a straight association using a minimote, but you can’t do the multiple group association they describe. I believe @codytruscott has had experience with these models.

Completely understand the multiple group association issue with the WT00Z-1 (bummer). I ordered about $2K worth of switches, scene controllers, & accessories yesterday so I am all in now. I will start a new thread when my installation journey starts this weekend.

1 Like