Guy Lavoie

The zwave standard has it's own version of "scenes"... that the eisy doesn't support. These would likely be used within a zwave only system, where devices communicate directly with each other. This is similar to how the Insteon spec also allows direct device to device links, but the eisy doesn't use those either. Indeed, the idea of a controller like the eisy is that it wants to include itself in every link, so that it can track device status for making program logic decisions. So it tends to treat devices as slave devices only; as inputs and outputs. It does support some of the more useful features of zwave devices, like the errors or status conditions that can come from door locks.

I think it's always worthwhile to keep up to date, especially if you'll be doing a migration to another UDI controller.

The ISY language operates more like a simplified multitasking operating system than as an application. The "applications" are the individual If/then programs that you create, as well as monitor the input/output devices it can receive and send from. If you ever programmed in VB6 and created routines that send and receive data through sockets or serial ports for example, then you know that you had to sprinkle "DoEvents" commands in your code that sent data and waited for received data, to allow the operating system to do those and other tasks as you program waited for the next event. DoEvents releases control to the operating system so that it can scan for the possible events. In the ISY, it evaluates the status of each If/then program, to see if the next step is due. If so, then it initiates it...and keeps monitoring the rest of the system.

If you ever find such a device, it would need to be controlling a load that can allow some current to leak through when it's off, to provide power to the module itself. That was the main characteristic of incandescent light bulbs. If you only have one or two such loads, then you might consider (don't shoot me...) an X10 switch for that, and you would need to have either an incandescent bulb as a load, or one along with the newer low power LED type lighting. Not likely to happen.

If the switch has 3 screws terminals (not counting the ground screw), then it's a 3 way switch (possibly just being used as a 2 way. But you would need to explain each cable, with each conductor going where. For example: 1- cable A with white and black conductors, white connected to white of cable B, black going to "common" on swtich 2- cable B with white, read and black conductors. white connected to white of cable A, black to black of cable C, red to switch terminal 3- cable C with white and black conductors. going to... That kind of detail.

Switches and modules don't store programs. They only have links to other devices, including a PLM that can be used by a device like the eisy to do things. A hub could also store scheduled events.

You need to indicate which wires go to which terminal. Are you counting the ground screw as one of the three screw terminals? Let me guess what you're saying here (and correct me if I'm wrong). 1- There are three wires actually going to the switch: a red and two blacks, and the two black wires are connected together. 2- No white wires go to the switch (this sounds different from your first post), the two white wires are simply connected together and taped up. If (and only if) that's right, could you try measuring the voltage between the white wires (you'd have to remove a bit of tape) and the black wires? Do you get 110 volts, no matter if the switch (and light) is on or off? If that's right, then measure the voltage between the white wire and the red wire. Do you get 110 volts if the light is on and 0 volts if it's off? That's a lot of ifs..

Well if you view it in the admin console, what does it show for "mode"?

Auto usually means that it will automatically switch between heating and cooling modes as needed (you set the heating and cooling setpoints and it heats and cools as needed to maintain the temperature within that range). Program usually means it follows the programmed time schedule, while hold tells it to override the program and just use the current setpoints continuously. If you're just playing around with it, how are you triggering heat and cool events? Normally if you set the heat setpoint to a temperature above the current indicated temperature, you should see it go into heat mode. Same with setting the cool setpoint below the current temperature to trigger cooling mode.

Careful, an unused white wire, plus the presence of a red wire could indicate that there is 240 volts there. Is there any electric heating in the garage? Does the red wire go to one of the screws on the switch? How many screw terminals are on the switch, 2 or 3? How many cables come into the switch box? So there are two white wires (one taped and one going to the switch). The one going to the switch is not necessarily a neutral. It could be the switched leg going to the light. That's almost certainly the case if there are two wires (black and white) going to the switch and both wires are in the same cable. You really need to tell us what goes where, all the wires.

Tell us more about the echo Hub. Looks like a rather new device. How do you go about programming it, and what makes it different from Alexa? I always like learning. Off the top, it looks like a echo show dedicated to home automation, a sort of Alexa app running on a dedicated hardware device.

In most cases, we want Alexa to control a device like a switch directly (on/off), and that's easily done with no programming needed. When you want to do fancier stuff like take action or not, depending on status, then programming will usually get you there. An example of this is my own garage door (what is it about garage doors?). My garage isn't attached to my house, it's a separate building. It is also a zone on my alarm system. I can open and close it about 6 different ways, including asking Alexa, pressing a button on a keypadlinc, and in UD mobile. The thing with the great majority of garage door openers is that they're toggle devices. Momentarily close a contact to open it if it's closed, or to close it if it's open. So it's not an on/off device. When I ask Alexa (or the other methods) to open it, I want it to ignore the command if it's already open. Same with close commands. Add to that the complication that I don't want to allow the automation methods to open it during nighttime hours, or when the alarm is armed. I was able to do all that by programming.

That's right. I just tested it and you can't turn a scene on or off with a virtual switch. Think of it as a on/off status flag, that you can test in a program. It fills a nice function as a device that you can add to a scene (as a responder) so that you can then test the status of a scene in a program, to do additional things. It's been discussed recently that a scene doesn't really have a "status" because you could turn on a scene composed of several devices, and then change some of those devices individually, so would the scene still be "on"? Think of it as being able to detect a scene trigger command. For some reason, IoX doesn't make scene "control" or "status" commands available for testing in programs, they don't appear in your device list. This is thus a handy workaround. For your echo hub application, how about having it set a state variable instead, and look for the variable value as the trigger to have a program run a scene?

I'm afraid I'll disappoint you... You'll need a program to do this, to trigger a scene that updates the keypadlinc button. It's great that we can do this though, because it allows the button (especially when configured in toggle mode) to always be in the correct state for the next, alternate action. Seeing the status light is also a nice plus, for situations like yours where direct observation of the garage door isn't easy.

You would need to try it with a program, looking for the virtual switch status then triggering the scene.

Not sure if it's the same as with a eisy, but if in the admin console you go into "Configuration" and then "Portals", do you see portal integration as "online" and "registered"? Do your existing Alexa controlled scenes still work?

Are you looking for the "status" or "control" event in your program? As far as I can tell from experimenting, only the status change is detected for virtual switches (created by the "Virtual" plugin). Have tested it by doing something simple, like incrementing or setting a variable when the status changes? I use a virtual switch (that I turn on in UD Mobile) to set a variable that is then tested in a separate program to open a garage door, and turn off the virtual switch.

https://wiki.universal-devices.com/ISY_Developers:API:REST_Interface There are a few things that need consideration when setting this up, one of which is user authentication. This recent thread discusses it: It's the same command format for scenes or devices. Just the device ID format is different; use the scene id instead.

You would probably do best with a physical controller device (eg. a palmpad if you're using X10) that then triggers scenes. If you really want a phone app, then you'd need to find an app that allows you to configure buttons that could send http GET commands, and use REST interface commands to trigger scenes in your eisy. Alexa voice control is also a user friendly way of triggering commands.

Well you can't really have two physical switches controlling the same light (unless you wired two relay switches in parallel or something...). Sounds like you have one switch, the one that works, actually controlling the light. The second one would probably be set up as a virtual 3 way switch, controlling the first one. If that's the case, then it probably doesn't have any load connected to it. Thus turning that switch on or off remotely, such as through the admin console, wouldn't do anything. It won't receive the command and then retransmit it as if it had been manually activated. So that sounds normal.

Well it's not zwave (it communicates by wifi) but the Venstar T7900 Colortouch thermostat can control a humdifier, and also has a cool to dehumidify (with optional reheat) function, so you can do both. It has a plugin for eisy. I have one of these thermostats, though I'm not using it for humidity control functions.

Could you post an example? Screenshot? What device type is this?

Well, just wondering what you have as a test setup and yes, if there is any kind of zwave network that operational. You mention being able to control the switch from the admin console, so I'm deducing that actual communications are working. As for Insteon vs zwave, I'm actually still new to it all. I've only been a UD user since about August, and implemented Insteon switches throughout since that time. I haven't store bought a single new Insteon device; they're all from ebay or marketplace, though a few of them were still new in box. I even bought my eisy as used. I had been using X10 quite reliably for the past 25 years... So my experience has been that Insteon seems very reliable, fast, and versatile. Then again, coming from X10, anything would appear better. As for zwave, I have several zwave door locks. I also bought a half dozen inexpensive zwave appliance modules that are actually for the purpose of creating the mesh network, since the devices I really want to use (the door locks) are battery operated so they don't act as repeaters. I also have a zwave watercop valve. All this installed in the past couple of months so I can't really say much about long term reliability. I do find the zwave reliability somewhat iffy, though my sparse network might be a factor. But it's still a bit odd that it usually works, though sometimes querying a lock will fail to respond. It's as if the network itself isn't consistent.

I've actually done that by starting linking in the admin console, then pressing the button on the device. So both methods probably work.

Is your zwave setup currently just the eisy and that one switch you're trying to configure?