Guy Lavoie

Well you'll need to wait until UDI releases the update that supports Matter. That should be very soon according to the latest announcement: https://www.universal-devices.com/2025-liftoff/

I'm referring to scenes, created in IoX, not programs.

Sounds like it's somewhat like z-wave, where a device can only belong to one network at a time. Some topologies, like Insteon, can be controlled by more than one main controller (ie: PLM) but each controller needs to be able to respect (leave) any links that aren't to devices it knows about. That's what the eisy does when you add a new Insteon devices and it gives you the option of leaving any existing links intact. Other networks like z-wave require you to remove a device from any other network in order to add it to a new controller. Zigbee might be similar.

I got my weekly test email just fine, today at noon.

This sounds similar to the problem I had with the i/o linc status being incorrect for my garage door. The sensor status indicated the door was closed, even after opening it. And a query would update it. A discussion of this in another thread brought up the fact that the i/o linc is powerline only (not dual band), and that the electrical noise of the opener motor might be inhibiting the status update that the module is sending out right after the door starts opening. As a workaround I tried adding a couple of query statements, sent a few seconds after the door is fully open and the motor stops (I timed the door opening and added a few extra seconds). It seems to have helped. I also added a lamplinc in the garage, as a signal booster and converter to rf signal as well. Interesting that we're both talking about a garage. These tend to be farther away and isolated (physically and electrically) from the rest of our living spaces, which might make any signal issues more relevant. If you have a spare lamplinc on hand, you might give that a try. Also, how is your motion sensor configured? Does it send both on and off commands, and what is the on time? On the ones I use, I have the time set to the minimum 30 seconds, and sending on/off commands.

Question: are you able to trigger scenes (created in IoX) with those Lutron switches? If you create a scene where a Lutron switch is a controller and an Insteon switch is a responder, does the Lutron switch control the Insteon one?

It would be clearer if you could post the actual program(s). Bring up the program, right click on the program name, and then "copy to clipboard" at the very bottom.

I've also been leaving the admin console open for days on end, at least when I was still actively implementing new devices and programs. After reading several posts about it not being a good idea, I'm avoiding doing that now. I'm not sure exactly how it might affect the operation of the eisy itself, but it certainly does end up freezing sometimes, which can be a cause of unneeded resource (cpu, memory, sockets) consumption.

First thing to try with any motion sensor related issues is try a fresh battery.

Great! Keep us posted...

Interesting. Could this in any way have affected UD Mobile in local mode? Earlier this morning UD Mobile wouldn't connect, and give me a "no proxies available" message. To get to connect I had to go into settings and re-enter my admin password, or so I thought. Coincidence or related? My question is: does UD Mobile need to be able to see anything external even if used in local mode?

It's not really about the feeling of abandonment, but about trading away known reliability for something new that has yet to make us feel as confident.

How do you think I feel about my 25 year old Ocelot controller, that's never missed a beat? It's like an old friend. It's still running a few things, like my solar pool heating. One of my projects is to make a PG3 plugin for it, so I can keep using the relay modules and other features. Right now I do that with X10 commands, not the best way. I've already tested serial communications with it from the eisy in Python. So it's just a question of getting it done.

That's the very first thing to check. If you have a spare device that was never added to a z-wave network, try adding that one first. If it works, that would pretty well indicate that this is the problem. To know if your eisy is seeing the adapter, in admin console, go to z-wave -> advanced -> z-wave information. Check that it says "Connected".

Ah yes, the "use a bigger hammer" approach. Works as a short term solution, but will leave you unsatisfied over the long term, and cynical about the technology. As Paul said, the real solution is to try and work out the communications issues by testing, making small fixes or changes and observe if it improves, by not using the programming workarounds that you have added. Are your devices dual band? Are the ones that aren't reliable in an isolated location, where signal strength might be a problem. If you put other types of Insteon devices in the same area, so they also fail to respond? Sometimes, just adding something like a lamplinc to act as a signal booster/coupler helps. All things to consider. The Insteon support forum also has good suggestions, though it appears to be down, has been for at least a week.

Yes, and the learning curve is quite steep. There is little or no tutorial information, it's mostly just reference material. The way to learn for most (including myself) is to install a simple plugin, and reverse engineer it to try and understand what does what. So far I've done two simple plug ins, mostly as an exercise to eventually make a more complex one. I'm also learning python at the same time. It's rewarding, but consider it mostly as a hobby, if you're counting the time you're putting into it.

The currently installed firmware version will remain. I've factory reset a ISY994i with a 300 series Zwave card and it didn't cause any issues.

So the second scene did the trick. In my naming convention (to avoid going crazy) I'll usually give the scene a name (eg: "scn kitchen") for the scene where the keypadlinc controls the light, and "scn kitchen rev" for the reverse scene that updates the keypadlinc if the light is operated directly from the switch.

The networking module comes by default with the eisy. Not sure about the Polisy.

Did you create a second scene with the on/off switch as the controller and the keypadlinc button as a responder?

Well since 14.1 seems to be part of the promised January upgrade, I'll just wait until it's announced (and let a few early adopters dip their toes first). Maybe UDI will streamline the process too. I'm in no rush.

If I log into my eisy with ssh and do the unix command "uname -a", I get: FreeBSD 13.2 release p11

Well turning on/off keypadlinc button backlights isn't something distinct or particular, it's just a regular Insteon device as far as commands go. You're controlling a light. I'm grateful that Insteon designed-in the capability and programmability that the keypadlinc has. The toggle mode would really be annoying to use if there was no way to keep a button's next on or off command in sync with the actual status of the device it's controlling. Now not only is the next button press always correct, but you also get a visual indication with the backlight. I love it. Yes, I've done scenes similar to "all off". My previously mentioned kitchen lights are a good example. I can (by programmed Insteon commands or Alexa) I can control individual lights, I have a kitchen scene that control all 3 together, a "back of the house" scene that controls those 3 lights plus two others, and a "ground floor" scene that controls those and every other light on the floor, which gets turned off when I arm my alarm system. The beauty with Insteon scenes is that the response speed stays the same, whether you control 2 lights or 20. The multiple link system can appear to be daunting at first, but it is very well thought out.

Yes, that should solve your need. You can keep it simple because there is only one way to turn on the fan. When you have more than one trigger, such as a 3 way setup, then you need to create a second scene that gets triggered by that alternate switch so that it can also "turn off" the keypadlinc C button. I actually call those scenes "reverse" scenes. The alternative is to use a program, as you have done. A program will work fine if it's a single device like the fan that is being controlled because you can watch it's status with If statements. If there are multiple devices though (I have 3 switches in the kitchen that often get turned on and off as a scene, but can also be controlled individually) well there is no "If scene Status..." command in IoX to trigger on. That's where the virtual switch comes in. I have the virtual switch turned on and off as part of the scene, but it can't get turned on manually... So now my program can watch the status of that virtual switch to keep the keypadlinc button correctly lit or not. Keypadlinc buttons are great in toggle mode, but need a bit more programming to keep in sync.

The way I do that kind of thing is to have the button turn on a scene, and include a virtual switch in the scene (use the "Virtual" plugin to create the switch). Then have a program that looks for the status of the virtual switch getting turned on, waits 1800 seconds (30 minutes) then turns off the button and virtual switch.