Guy Lavoie

If it's that device that's going bad, then this will be a good solution. But if it's a noise issue, then it might just be a band aid on a bigger problem. Just be aware.

The 2486D isn't dual band, so will be more prone to signal issues, esp if there is noise on the powerline.

Yes, there is a migration you can do. See here: https://www.universal-devices.com/4x-migration/

That's another purpose of my Polisy as a test controller: to learn plugin programming. I've done a couple of simple plugins to get the hang of it. It's a steep learning curve

Thanks for the replies, and that is pretty well what I expected: there there would be no real difference, at least as far as making an "upgrade" from Polisy to eisy worthwhile is concerned. I'm happy about that. I first got the eisy, and then came across a used Polisy with the ZMatter board that cost me little more than the ZMatter board itself. I have the Polisy as my "lab" system and as a standby spare if the eisy should die an untimely death.

The initial question hasn't been answered: how much faster is the eisy compared to the Polisy? It would be interesting to know.

No, not as a Wait statement, within a single program. But you can do it if you break it up into more than one program. I have my bathroom fan timer set up like that. For example, you want to perform Action B a number of minutes after Action A, where the number of minutes is in variable "i_wait". In this example s_timer is a status variable. If original trigger condition Then Action A Then s_timer = 1 If s_timer > i_wait Then Action B Then s_timer = 0 If s_timer > 0 Then s_timer +=1 Then Wait 1 minute The third program is the "timer", incrementing by 1 every minute, as long as the s_timer is set to any value above 0.

Which version of the UD Mobile app do you have, Android or IOS? I'm not sure it's been successful yet with IOS. A few of us have succeeded with Android, though it only configures devices as on/off devices for now. This is still beta. Have a look at our discussions here:

Did you do the migration using a backup and restore? Here is the procedure I found elsewhere on the forum: 1) Make sure 5.5.3 is installed (we're already past that now) 2) Leave your Zooz dongle connected and ZMatter Z-Wave dongle not connected 3) Create a backup of your Polisy/eisy (File | Backup ISY) 4) Create a backup of the Polisy/eisy you are migrating to (if different than in step 3) 5) Go to configuration tab in Admin Console and select "Migrate to ZMatter ZWave" 6) Choose the option that allows you to create a "migration" backup (first option) 7) Once you have your "migration" backup you are ready to migrate To migrate, you remove the Zooz dongle and plug in the ZMatter Z-Wave dongle. If you have a ZMatter Z-Wave board then you would power down Polisy, add it, then power on again. Next, use (File | Restore ISY) to restore the "migration" backup you just created (in step 6). When your Polisy/eisy restarts it automatically migrates and creates the new nodes, does the device interviews etc.

Ok, so you want to be able to issue a scene command from UD mobile and have your controller "filter" it through a time of day condition, to allow it to be executed or not. Since you mention that you have a eisy on the way, I can tell you that there is a very nice way to do that on the eisy, using a free plugin (called "Virtual"). The idea is that you create a virtual switch that you add to your existing scene. You then create a program that watches for changes in the status of that virtual switch, and ANDs that with your time of day criteria and anything else to then execute your command(s). Since this virtual switch can only get turned on by your scene, this is how you can get a scene to execute a program. You would actually need to create this as two scenes: one that turns on the virtual switch (and triggers the program) from UD Mobile, and then the actual scene that you want to execute, which is run by the program.

I can't really see an alternative to opening a ticket with UDI.

Well that's one for our collective wisdom... and a good first thing to try if this ever happens to someone else.

That's really odd, and interesting. It's as if even manual operation of the switch somehow requires Insteon communications to be used, or something like that. So are you saying that just powering down the eisy would let all the switches work ok manually?

I have all Alexa devices myself. I got the Google home mini several years ago as a used device for $15, and this is the first time it's come in handy for anything. Most sharing apps (Hue, Alexa) only offer pin codes for sharing. The UD Matter implementation is still beta and I'm sure the remaining options will get added over time once it works reliably.

Do you happen to have a Google Home device, like a mini? If your Matter device is wifi, you can configure it in Google Home, and then use the Google app to create a qr sharing code to add it to the eisy.

Sounds like quite a stretch. But then again, the actual problem observed is hard to believe too! It has to be something totally freaky.

How many switches are you unable to turn on manually? Did they all begin to have this problem at the same time?

Not sure I understand. You seem to be saying that manually controlling the switch ("Manually pushing the switch") itself isn't working (at the physical switch, not in Admin Console), but that they work from Alexa and Home Assistant. Unless a bunch of microswitches have all failed at the same time, that sounds impossible. As you say, if Alexa and Home Assistant are controlling them through the eisy, then it wouldn't be a PLM issue.

Here's a little project if you're like me, without a way to buy the ZMatter enclosure by itself (The Canadian distributor for UDI products doesn't offer it for sale). I started by finding the needed mPCIe to USB adapter, and found this one on amazon. I first tested it with the bare ZMatter board I took out of my Polisy. Then it was just a question of getting an enclosure for it. I also used a USB extension cable, such that the enclosure is now a standalone unit, making for easier placement, and connection to a Polisy (I can't see how the UDI enclosure could be plugged directly into a Polisy, given the proximity of it's power connector to the USB slots). So there you have it, the Canadian ZMatter enclosure...

The slots in the Polisy are mini PCIe

Cool, and thanks for the experiment. Adds to the science! It's pretty well how we would expect things to go with RF jamming. I had already seen a similar effect with commands getting delayed and retried when something was happening with the signal path (I forget the exact circumstances). Insteon is quite effective at that. When I decided to power cycle the mini remote, I first ran my fingers lightly over the buttons to see if any appeared to be stuck, and didn't find any. It could still have been a problem internal to the device.

It's a mini remote, so it's RF only. That's why I suspected it in particular, since I only added it a few days ago, and that it appeared as though RF communications was being impacted (though the was switch I tried was dual band). But I certainly could send out commands from the admin console. It would have been interesting to try to send out a command over RF, though devices controlled only by RF are rare. An Insteon thermostat would be one example. I'm just wondering if others have ever had a similar problem occur. Learning as I go. If it ever happens again, the first thing I'll try will be to power cycle that mini remote.

I was just searching for a thread discussing problems with incoming Insteon status changes not being detected and came across this one, which was recent and left unresolved. I just had a similar experience, where I noticed motion detectors were not firing off programs. Then I tried manually activating an Insteon wall switch and status was not updating in admin console. Yet I could turn devices on and off from the admin console. Hmm, that was unusual: commands going out were ok but not status coming in. The things I tried in order: 1 - reboot the eisy 2- unplug and plug back in the PLM 3- restore the PLM. As that was happening, I also went to the bedroom and took the mini controller I added just a few days ago, and turned it's power switch off and back on. The motion sensors started working again, and going back to the admin console, receiving status updates was also ok. I can't tell if it's the PLM restore or power cycling the mini controller (or maybe neither) that fixed it. Has anyone else ever had a similar experience?

The fact that the status is not updated when this happens seems to indicate some kind of communication issue, or something that is falsely triggering them on. Yet if they all belong to the same scene and they always come on together, then something would be triggering the scene. But I don't see the reason why status tracking would be lost at the same time. Until you reboot your eisy, are you able to control them from the admin console?

Did you keep the PLM from your ISY994i and installed it on your eisy? How old is it?