Guy Lavoie

Yes, two antennas. One for zwave and one for zigbee

Which would make sense because you have to manually put it in linking mode, contrary to line powered devices that you can link by just entering the device id. However, how would links get written into it?

The advantage would be the added zigbee functionality, as well as the upcoming Matter support. I think you would also get a better security protocol (S2) on the zwave. The Zmatter board can be installed inside the Polisy, or added externally as a USB dongle. The eisy only the supports the dongle option.

What is a "RL"? A Keypadlinc? If the scene isn't triggered by that same keypadlinc (sounds like it isn't) then you can make the keypadlinc a responder to the scene that controls the light. I have a few keypadlinc buttons that get updated that way, so that they are always in the correct next toggle mode. If the keypadlinc is also controlling that light, then you need to create two scenes: one with the keypadlinc as a controller and the light as responder, and a second scene where the roles are reversed. In my naming scheme, I have for example "Scn table" and "Scn table rev", where that second one updates the keypadlinc button if the light was turned on other than by the keypadlinc button (could be the switch itself, a program, even another keypadlinc).

I've just been reading through the whole thread for the past hour. Sounds like there is something fundamental that changed in the execution logic, when it went from a standalone program to one that runs as a unix application. It also reminds me of my own thread about how the execution order is "unknown", which could do crazy things, especially if the order is not only unknown, but possibly different from time to time.

If it ain't broke, don't fix it.

For zwave, you'll need a network of devices if you're looking to get reliable communications over a house that has many rooms. Also, battery powered devices like door locks will not function as signal repeaters.

Stocking up on spares is a significant part of my strategy. Watch for people swapping out devices that you use and score some deals.

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.