Guy Lavoie

It's especially handy in UD Mobile, because it's both a button and status indicator, like a keypadlinc. One main use for it is to trigger programs on scene on/off commands, since IoX doesn't offer "If scene command..." directly. I include a virtual switch in the scene I want to watch and the program triggers on the status change of the virtual switch (which can't ever get turned on manually...). I often use two virtual switches in pairs. One use is to control my garage door opener, and indicate open/close status, even if the opener is controlled manually. Another pair controls/indicates watercop valve atatus. Again for pool solar heat control The only downside is that you don't get control events, only status.

Virtual is a hidden gem among the plugins. I use it for several different things, though not the garage option. Thanks!

Sounds like the devices already belonged to another Z-Wave network, and needed to go through an exclusion procedure in order to allow them to join a new network.

Yes, that's right. I think that for the Polisy, the only difference was that the pro version had wifi capability.

Yup that's a classic. It looks like a field label, but it's actually a button to write the new value.

Next step: Alexa, please remind me your device name for the living room lights? 🤨

Programs and scenes are the best ways to get the most out of keypadlincs and status indications. The only annoying thing when using programs is the slight delay before seeing the backlight update.

Yes, looks like you're at that point.

Have you tried connecting a HDMI monitor to it, so see if anything happens?

I'd try a different power supply. I have a Polisy that would show it had power (one LED would light up) but not power up. It turned out to be a bad power supply.

Finding good, reliable and non conflicting spokens becomes a challenge as the number of them grows. I have over 60 different ones and creating any new ones is getting difficult. Then you gotta remember them all!

Good information. But if the PLM is also able to recognize the reception of an All On command, it would be great if the eisy could look for it as an "If" event, and we could program mitigation commands for the more critical items.

You aren't the first...you won't be the last 😁

Alternately, click on "Start Linking" (under Link Management at the top in Iox) and then press the link button on the keypad module.

My preferred way of doing things like this, where the initial triggering condition will cease to be true, is to set a state variable, and then have a separate program look for the variable to become true, do the wait, turn off the light, and reset the variable. - So your first program would be If garage door is violated Or other trigger... Then Turn light on Then Variable garage_light = 1 - Second program If Variable garage_light = 1 Then Wait 1 minute Then Turn light off Then Variable garage_light = 0

No idea about any issues. I haven't used this myself. I just thought I'd mention it because I remember seeing this option

In the System configuration options, there is a checkbox that allows you to "Catch up schedules on restart", which you might want to try.

Going from a Polisy already using the zmatter board to eisy should be as simple as a backup and restore, because they are both running the same version of IoX. You only really have the enclosure to be concerned with, and convert the PLM to USB (with the serial adapter cable, or get a USB PLM).

I've seen mentions of the All On command events, and have experienced one myself. One question comes to mind: since it's a valid Insteon command, is the PLM able to receive and recognize this command? If so, shouldn't IoX give us the capability to look for the reception of an All On command, and allow us to use it as a trigger event, which would allow us to mitigate the effects?

There you go. When you can combine information from otherwise isolated sources and add some program logic between them, things like that become possible.

Well, there are device types that just don't exist as Insteon, like door locks, smart bulbs, thermostats, etc. Having these connectivity options expands your possibilities.

Well since you've already been using the ISY994i, you're already familiar with the basics. The programming language is essentially the same. The main difference will be the new or expanded connectivity options (zwave, zigbee, and now Matter) and the plugins. If you didn't have the portal and networking modules, then that will also create new connectivity options. You might be best starting by asking what you'd like to do that you couldn't do before.

Well, contrary to most of us, now you have the privilege of starting afresh with a technology you are alreay familiar with! Depending on the complexity of your programs, especially if there is a lot of if/then logic, you might find that adapting them to a different home might be difficult. If you do intend to reuse or adapt programs, I'd try leaving the original programs intact, install the devices in the same locations as much as possible, and then work with copies of the original programs, not deleting anything until you're happy with the adaptations. For mesh network devices like zwave and zigbee, you also now have a golden opportunity to create the network from scratch, establishing where you want repeaters, etc, using your experience gained from your first home.

Doing it with UDM would require some type of option to lock it to the "favorites" screen, or something similar. Should be easy to implement as a new feature. Otherwise, you would need to create or find a custom app that allows you to define buttons that could trigger the sending of REST commands. If I ever get around to one of my projects (a plugin to communicate with a Applied Digital Leopard screen), I'd do it that way myself, to display information and allow commands to be sent, though the appeal for this is much less now that we have things like Alexa.

You also need to include port number 8443 after your IP address. For example: https://192.168.0.123:8443/desc