Guy Lavoie

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

1) Assigning a fixed IP address isn't supported anymore. I've seen several mentions that having a fixed IP address caused support issues (though I've never seen any mention of what the actual issue was). The current trick is to reserve an IP address for your device (MAC address) in your router, so that DHCP always assigns it the same IP address. 4) When you open the admin console from the IoX finder, are you selecting LAN or Cloud? Selecting cloud might have updated the version on your ISY994i

Have a look at the REST commands ISY Developers:API:REST Interface - Universal Devices, Inc. Wiki https://share.google/VeNzNTVUR22A0brq4

Alternately, you could try plugging the USB adapter into the eisy and see if it can mount the filesystem.

You might have better luck connecting the SATA drive to a USB adapter and examining it with a PC, assuming the SATA drive isn't damaged. If you are used to doing things with ssh, scp and such, you might be able to reinstall the generic plugins on your new eisy, and then overwrite them with the files from the Polisy's SATA drive. The installed plugins are in: /var/polyglot/pg3/ns Then you'll see a pathname for each plugin, made up of your UUID and polyglot slot number, such as 0029b102618f_2 Of course, the subdirectory name will be different on the eisy (with it's own UUID) but the customized files should all be there, and you'd overwrite the default ones with yours. Then there is any licensing issues to deal with. I've never tried this, but I'm just giving you some tips to explore.

The second one seems to best reflect what you want to do, visually. Both are actually equivalent.

Yes, if you're referring to a sharing code. Matter devices usually come with QR and/or PIN codes. Currently the only way to add a Matter device to your eisy is with a QR code. Unfortunately, some sharing applications will only give you a PIN code. So use one that offers a QR code. The Hue app does this, as does the Google Home app. I can't remember if the Alexa app does too. The share code is created in the app and expires, sometimes as quickly as after just a couple of minutes. Another inconvenience is that the sharing QR code will often be displayed on your phone (almost everything today is managed with a phone app) and you also need to scan that QR code in UD Mobile...on your phone. So you either need two phones, or do what I did: use the phone's buttons to take a screen shot as a photo, email the picture to yourself, open the email on your PC screen, scan the QR code off the PC screen. All that before it expires!

The eisy isn't meant to be used with just UD Mobile. Some things need to be configured in IoX. In the Configuration settings (in IoX) you define the timezone you're in, and the controller will get the time automatically, from a time server. If you have no PC, then I figure you don't have a way of running IoX to set that up.

Well that nanoleaf bulbs use thread, and I've tested them successfully. Well Matter is over IPv6. Both ethernet and wifi are IP based so that isn't really a distinction, since the difference is at the physical and data link layers. The network layer is the same. Matter also implements IPv6 over Zigbee, which is what makes up the Thread communication option. This appears to be optimized for low power/battery device operation. The implementation of Matter for the UDI controllers seems to have somewhat stalled, or slowed down. It's still in Alpha testing. It looks like a few other projects (like Homekit implementation) might have been given a bit more priority for the time being. The current release of IoX is still 5.9.1_18, and has been since April. It would be nice to have an update from UDI.

The best way to do the actual flashing would be by putting all the lights you want to flash in a scene, and have the program turn the scene on and off. However be aware the communications will be busy after a scene command (at least with Insteon) due to the "cleanup" messages that follow between the PLM and the individual lights. I would start with a 3 second wait between scene on and off commands, and try to notice if the timing is reliable or not.