Guy Lavoie

I couldn't get the ZMatter enclosure in Canada, so I ended up making my own. Because my enclosure was bigger, I could put the whole board in it.

I periodically run the update on my test Polisy and I just did so now. Still showing 5.9.1_18 and has been the same since March 20.

Have you updated your eisy (or Polisy) very recently, like in the past two weeks or less? The earlier 5.9.1 updates would give you that error. If you haven't, do the update and try again.

It's specified elsewhere, but you need to snap off the top half of the card before installing it in the enclosure.

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

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?