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

FYI, got the minimote today. The one I got doesn’t have the associate button labeled. After doing some reading, it seems there may be 2 version of the remote. None the less, it still worked and did the job. The one thing I did prior to associating was update the firmware on the remote which can be found here: http://aeotec.com/small-z-wave-remote-control/1265-minimote-firmware.html Seems some people had issues associating prior to this firmware update. In the end, I’m finally able to use my 3 way switch. I hope SmartThings will get this functionality added in eventually.

Also, these are the steps I used:

Associate Transmitter (LTM-5) with Switch/Module
To create the three-way switching, do the following:
Press the Button labeled “Associate” on the Minimote. The Blue LED should blink slowly
On the switch/module to be controlled, double tap the set button. the LED will blink quickly to indicate proper Z-wave communication has occurred
Double tap rocker on the Transmitter to finish the association. The Blue LED will stay on for 2 Seconds to indicate Success
Repeat Step 3 for all additional auxiliary switches if multiple.
Press Any button to exit Association Mode.

I got my minimote today. Thanks for those steps chevyman. I still can’t get it working though, even after firing up an old Windows VM (no love for Macs!) to do the firmware update. I click the Associate button, and the blue LED flashes, but double-tapping the rocker on the master switch (the one to be controller) does nothing.

Any ideas?

Never mind, apparently I hadn’t gotten the minimote associated with the SmartThings hub correctly. It all works now. Virtual three-ways! Woot!

Related…is there a limit to the number of other devices that can be controlled by an aux switch at once? It seems to be four…I have a group of five lights I’d love to tie into one aux switch, but the last one just won’t do anything when I try to associate it.

I know this is an old thread but i’ll transmit in the blind here…

How does association work via the Aeon Minimote. More specifically, will using the remote to associate a switch with an appliance module eliminate (or even drastically reduce) the delay from on/off commands initiated at the wall switch?

I’ve got a remote in my Amazon shopping cart but i want to be reasonably sure i can accomplish this task before i jump in.

Thanks in advance for any help that can be offered.

Matt

Short answer: if both of the devices support zwave direct association and they are within one hop of each other on your Z wave network (Basically in the same room, or at least within about 20 feet), then, yes, using the minimote to directly associate them should result in very quick communication between those two specific devices.

Longer answer: However, it should also be noted that this change in state will not necessarily be reported to the smartthings hub so the results are not always quite what you expected, particularly with regard to status reports. But it’s a common and quick way to have an aux switch turn on a master switch.

Also, not all switches or other devices support direct association. So you need to check the manufacturer’s description carefully, or look up the Z wave “conformance statement” on the official Z wave alliance site. And it won’t do you any good if any of the devices you want to link up are zigbee or Wi-Fi or another protocol. This is just as a zwave option. (You can “bind” two zigbee devices together for similar result, but not through the Minimote.)

So the first step is to look at the individual devices you want to communicate, and make sure that both support zwave direct association.

BTW, another thing to try when you’re seeing delays like this is a Z wave repair. This is also called healing the network. It sounds complicated, but all it really does is have every device rebuild its table of addresses so it knows where its nearest neighbors are. This can greatly improve the speed with which messages move through the network.

Many people pair every new device right next to the hub. That’s called “bench pairing.” There’s nothing wrong with it, but it does mean that the devices don’t really know who their nearest physical neighbors are. So their local routing tables may have been trying to send messages via a device which is in fact several rooms away.

You fix this by doing a Z wave repair after all the devices are in their permanent locations. Then each knows who its true neighbors are, and it can speed up the whole network.

You can do something similar for the zigbee devices.

So sometimes the problem is that the aux is trying to reach a node which is not a true neighbor, and that’s where the delay is. So just one more thing to try.

The following topic discusses this issue:

Thanks @JDRoberts. I’ll do a little research on the direct association of the devices in question.

I’ve repaired the network several times with no appreciable affect of the delay. As you mentioned, i ‘bench pair’ my devices, move them to where i want them and then i do a repair.

I guess i’m a bit concerned over the ‘change in state’ not being reported to the hub. Has that caused many problems in your experience?

Does direct association work both ways? Meaning, if i turn on the appliance switch (used for a table lamp) on using the button on the face of the switch, will that turn the wall switch on as well? There are a few times where we’ll just have the table lamp on without needing the lights controlled by the switch on as well.

Thanks for your quick and thorough response!

You may be able to have two direct associations (One going each way), it just depends on what each device supports. Some can initiate, some can only receive.

In my own experience, status not being reported to the hub doesn’t cause any problems, but I have a different background. My college major was computer information systems, and I went on to work as a network engineer. I had a lot of experience with mesh networks before ever trying anything with home automation. Consequently, I never expect the status on the status panel to be up-to-the-minute for mesh networks. “Within the last few minutes” is close enough. If I need something better for some immediate purpose, like troubleshooting, I do a poll.

The biggest advantage of mesh networks like Zwave and Zigbee is that they’re cheap. Cheap in terms of energy draw, and cheap in terms of the end devices, which don’t have to be very smart. And they don’t require constant fine-tuning from a human. I like all of that.

You pay for that by not having constant monitoring, forced sequencing, and instant updates. (To get those, you go to a different network protocol like Wi-Fi which is more expensive.)

So it never bugs me if I can see that the light is on in the room, but I open the app and it thinks the light is off. That’s just part of mesh. But I know it drives a lot of other people crazy, especially if they’ve primarily worked with Wi-Fi devices all their life.

As long as things work when I ask them to, and I can force a status refresh if I need it, I’m fine. But I’m probably not typical of residential users in that regard.

I do like “instant update” switches, just like everybody else. It’s nice. I just understand what it costs in terms of both dollars and energy draw, and I’d rather have lower energy draw.

In terms of everything working in the network, I don’t know if it can cause problems with SmartThings or not. It wouldn’t for most networks, but sometimes smartthings is too smart for its own good and doesn’t issue a command because it thinks the device is already in that state. So hopefully somebody who is using direct association can comment.

1 Like

While JD provided a detailed response, I wanted to provide a short anecdote that I bought the Aeon Minimote specifically for direct association of Z-Wave devices and it works great. I primarily use it to have Z-Wave Controller Switches directly associated to Z-Wave Lamp Modules and Z-Wave Relay Outlets.

In each scenario, the switch and controlled device are in the same room and the control is near instantaneous.

1 Like

Thanks @joshua_lyon!

@joshua_lyon, what brand switches, modules do you use? Looking through the conformance statements none of mine seem to have association listed as a command class.

This is gonna get expensive if i have to replace a bunch of modules. :frowning:

I have primarily used it with Intermatic CA5100 Scene Controllers along with GE 45602 Lamp Dimmer Modules or Intermatic CA3500 Receptacles.

What products are you looking to do this with?

I have a couple items i had considered but on checking the conformance statement, very few are even an option for association. I had considered the following:
2x GE Appliance Module 45603/ZW 4101
2x Shlage Dimmable Lamp Module
1x GE On/Off Wall Switch 45609
1x Leviton On/Off Wall Switch DZS-15

NONE of them include association in their conformance statements. I’ll just fight through having the ‘Big Switch’ do the work and suffer the delay associated with that.

Intermatic doesn’t appear often in listings of z-wave devices & i thought that i read that they had bowed out of home automation… Does that sound accurate?

The Eaton Cooper Aspire zwave line usually supports association. They’re more expensive, though.

The manufacturer name is Eaton, the division is Cooper Wiring, and the model line is Aspire. Cooper Aspire is usually a good search term to use, but the conformance statements are under Eaton Cooper.

Make sure you’re buying the zwave model, they have other protocols.

Yes, I bought a bunch of Intermatic HA equipment on discount from a local distributor as they indicated the equipment was being discontinued. The relays in the Intermatic equipment are really loud and I wouldn’t recommend them. The CA600 dimmers are silent (as you might expect), but I’ve had something like 3 of them go bad. Luckily I had bought several 6-packs so I had enough spares to swap out.

I’ve been reading everything I could find about associations to determine if I can use it to write a better garage door opener device controller. What I want to do is have my garage door sensor send a message to my opener controller so that the device will report and show the proper open/close state. I can’t do this in an App because Apps can’t change the state of an icon. To do this in the device code is fairly simple but only if the sensor device will send a message to the opener device. The z-wave documentation says this can happen if the two devices are associated in the same group. Will the mini-mote workaround described here accomplish this association? Or is there a simpler way? I found lots of garage door opener threads here but none of them seem to do what I am trying to do which is have my simple relay switch show open when open and closed when closed. Currently it is set up as a virtual momentary zwave device which shows unpushed all the time except during the brief momentary time when the button is pushed to active the door. A second tile shows the open/closed status. This works but is confusing to everyone in my home except me which results in people continuously pushing the button to close the garage even when it is already closed.

Direct Association in zwave allows for two end devices to communicate directly without going through the hub. A typical example is a motion sensor triggering a light to come on.

Because the hub is not used, it will not work with virtual devices.

Both devices must support the “association” command class. (See their conformance statements.) if they do then, yes, the Minimote can create the association.

The direct association is pretty much limited to an On or Off instruction to the second device.

Because the hub is not used, the ST mobile app will not realize the state change occurred until the next refresh. This sounds like the opposite of what you’re trying to accomplish, though.

This sounds like a time when more frequent polling might be justified.

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.