Guy Lavoie

It's model 43095, I had posted a picture of it on page 4 of this thread, plus a link to some other information. I also displayed the DH cluster line that shows energy consumption. This model seems to be discontinued. I also have a GE branded one that seems to be the same internally. I have 9 of these, including one that's brand new in it's box. I'd be willing to give you that one (I'd send it to you) in order to have it supported in a future IoX release. Would that work? Thanks.

Hah, I'm far from "knowledgable" on this stuff, but google has given me many answers!

Yes, the Beecon supports RTS and Zigbee, while the Switch does both of those plus a newer protocol called IO

Existing shade controllers shouldn't be affected. My URTSII or existing remotes weren't affected. The general idea with RTS is that you push a button on an existing controller or remote, so that the gateway listens to the signal to learn the RTS address of that shade. Somfy remotes learn the same way. Setting up a new shade (ie: with no paired remote yet) is a bit more work because as you say, you need to access a tiny button on the shade itself. I suppose you could delete the app once you're done, but why? Just keep it on your phone for testing, adding new shades, etc.

Yes, the Switch (or Beecon) needs the TaHoma app to add the shades to the gateway device. You also need the app to generate the unique key that will give local access to the gateway, and that you need to eneter as a parameter when configuring the Somfy plugin. For your second question, Somfy says "up to 65 feet in optimal conditions", so I'd position the gateway as high and centrally (to your shades) as possible. Mine is on top of a disk cabinet that's near the center of the house. There are also RTS repeaters available.

I get a sense that it might get incorporated into UDI's support, possibly as a self-help screening process if you want to open a ticket. Not that I'm against the idea. Just something that seems to be in the queue. It could be useful for some of the usual questions that can be hard to search on the forum, such as "What updates are still supported on the Polisy?" or "What is the proper procedure to replace a Insteon PLM?".

Zwave LR is now supported, but you'll need to update IoX to 6.1 2, by enabling the staging repository in eisy-ui and upgrading.

@Michel Kohanim Just getting back to this (following the updated Zigbee processing in 6.1.1). Is the "energy cluster" that was implemented referring to: 1794 (0z0702)? If so, then the format of the Jasco must have something that's slightly different, since it's not showing up in admin console, even though DH Clusters for the device is showing a detailed output, and the last field does show the demand in real time if I refresh it.

Have you tried simply rebooting your eisy?

Ah yes, in that case do A new buzzword is born: eisy-ai clever!

UDI did signal last January that support for the Polisy would be in a maintenance mode, meaning that updates would continue as long as they were feasable, but if any new eisy features aren't possible on the Polisy for whatever reason (such as the operating system version) then so be it. Some people are still using their isy994i, so the Polisy probably still has a lot of life left in it, unless you want the absolute latest in performance.

A Polisy won't upgrade from a menu. You need to do it from the command line, using ssh. sudo pkg upgrade udx isy eisyui pg3x This is explained earlier in this thread.

That's a good question. I'll probably be redoing some of my tests with 6.1.1

What version did you upgrade from?

Dying batteries in motion sensors can also be a cause of unexplained events.

Have you verified that the file is actually missing? You would need to access your controller with ssh and look for the file. The full path is /var/isy/FILES/CONF/2B9FCE.REC. If it's missing, you might try and see if an older backup has it, and restore just that file. IoX backups are compressed folders, that you can just browse through on a windows PC. Find the backup you want to check (they're helpfully named by date), click on the folder, and follow the path. First you'll see a folder with your UUID, then FILES, then CONF, and look for the specific file. Look for the most recent backup that has that file. Then try and extract it and copying it back to the eisy. Several steps are involved: create a temporary folder on your pc and extract the backup to it. For example, create a folder such as c:\tmp2 and then from the file browser that you're using to view through the compressed backup, click on "extract all" at the top and restore to c:\tmp2. Now you'll be able open a DOS command prompt and browse to the folder where the file is. use the scp command to copy the file to the eisy. To avoid permission issues, first restore it to admin's home directory (/home/admin), like this: scp c:\tmp2\FILES\CONF\2B9FCE.REC admin@eisy.local:/home/admin/2B9FCE.REC You'll be prompted for the admin password. ssh into your eisy and verify that the file is there. Then use: sudo cp 2B9FCE.REC /var/isy/FILES/CONF/2B9FCE.REC to copy it to the needed directory. See if that fixes your missing config file issue. If you're confident that the version of that device is up to date in the restored file, try restoring the device.

In fact that's what I also did, get Yolink temperature sensors.

Once every 20 years isn't so bad 😃 If you haven't modified your programs recently, then it can be just a freak occurrence. There are programming tips you can use to minimize the possibility of this happening, such as avoid issuing any new commands right after sending a scene command.

I'm not sure what it's called in Alexa. Maybe it's a routine. But I'd create an Alexa routine that would trigger on a variable being equal to each value. So if variable = 75 then say "the temperature is 75 degrees". One routine per temperature.

I looked for a way of doing this a while back and making an announcement for each temperature was the only workaround I had found. I did ask the author of the Virtual plugin to see if he could add a virtual temperature device (for Alexa), but that doesn't look like it might happen.

Yes, though a lot of the plugin developer information went missing a while back. I'll poke around.

How do we do that? Command line? And what is "install time"...when the upgrade is performed? Learning and taking notes here 🙂

Well that's it, I didn't want to bet my life either! Lol. I figured the node names would be the same since the slot number is part of the name, but the recreated names might end up at a different pointer in a device table. So I played it safe and replaced the plugin like an insteon device, by creating the new one and using find/replace.

Ok thanks, I just did that, which solved the problem. But...I could only reinstall it as a new plugin, in a new slot. I didn't find a way to update the existing one. This means that I lost the existing references in programs. So I installed it in a new slot, leaving the old non-working plugin in place until I could find and replace the program references to the nodes. Then I deleted the old one. That's not cool...there has to be a better way?

Very likely. I updated 3 Polisys this way and didn't need to set the repository on any of them. Not sure why it happens for some cases.