Guy Lavoie

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.

That goes for most plugins where you configure it by making parameter changes or doing some type of discovery. You need to exit the admin console and log back in to see the results.

Yes, that's the idea: to redo the variable reference. I still have your mention in the back of my mind that this worked fine on the ISY but not on the eisy. This problem potentially popped up between the two. I'm looking forward to hearing how it goes this evening.

Well that should be easy to troubleshoot, if it's repeatable. One thing: In both the program(s) that sets the variable, and the program that looks for it being set to 1: edit the program, select the variable again from the list (as if you were selecting another variable), click on update to save the line, and save the program. I've seen odd stuff happen with variable references looking right but not working. It could be an admin console thing.

Scheduled event - [ID 000E][Parent 0001][Not Enabled] If On Wed Dec 25 Time is 12:01:00AM Then // Merry Christmas! Else - No Actions - (To add one, press 'Action')

That's good to know. I would have thought that the PLM would have done that, not the ISY. That way, a failed scene command could have been reported back to the ISY as a communication error with a device.

Interesting. I did think about motor noise interference, but hadn't looked up the fact that the i/o linc is powerline only, which would certainly make the problem more likely. I also have a separate closed door sensor and Insteon thermostat in the garage (which is detached from the house but close by). Maybe adding an unused lamplinc might be an idea for signal strength.

I thought I'd start this thread after another user (oberkc) mentioned a problem similar to one I've been having, where the status of the door closure detector doesn't seem to be updating. In my case, it seems that the status of the door detection remains On (ie: the door is closed) even after opening the door. The result is that a command to then close the door doesn't do anything. In testing it, I would issue a Query from the admin console and that seems to update the status. In response, I've added a few Query commands, spaced with Wait statements after opening the door. This hasn't been implemented for long enough to know if it's a viable workaround, but I'd like to know if others have experienced the same thing with this module?

Interesting, a few days ago I also created a test program (but simpler than yours) to test that a series of waits would always complete, as part of trying to understand this problem. I created 9 integer variables, and a program like yours that incremented one variable, sent a few Insteon commands (turning off basement lights), wait a few seconds, then increment the next variable, etc, all the way to the end. Then I had a second program trigger it every few minutes. My thinking was that if the program ended before all the waits had executed, then some of the later integer increments would be missing. I let it run overnight. The next day, all the integers had incremented to the same value, about 550. None were missing. Both our tests seem to indicate that the problem is elsewhere. Having motion sensors in the mix can certainly be a factor. I suggest that CoolToys try to simplify it down to something more linear (without anything that might cause random triggers, like motion sensors) and/or break it up into several programs that would make it easier to troubleshoot.

Yes, I hope they give out a few more details of how it works, what's needed, etc. A teaser screen shot of the new admin console wouldn't hurt

Not to hijack the thread, but are you talking about the Insteon garage door kit that has an i/o linc? Just reply yes or no. If yes, it might be worth starting a separate thread on it. Thanks.

I'd do it like this: If 'Motion Detector' is switched On (Control) And $Test1 is 0 Then Set 'Test Switch' On Wait 1 minute Set 'Test Switch' Off ------------------------------------------------- Override motion sensing If 'Test Switch' is switched On (Control) >>> paddle the switch ON Then Stop program 'Motion turns on Switch' Set $Test1 = 1 ------------------------------------------------- Wait 15 seconds after turning off the switch before resetting the variable (to prevent motion restarting timer) If 'Test Switch' is switched Off (Control) Then Wait 15 seconds $Test1 = 0 The idea is that $Test1 is a flag that enables the motion sensor (when = 0) or disables it (when = 1). The override program sets it to 1 to disable the motion sensor from generating a switch On command. The last program looks for the switch getting turned off manually, and waits 15 seconds before re-enabling the motion sensor to turn the light on again.

Well the text says: Link WiFi-based Matter switches/plugins directly. Link Thread-based Matter switches/plugins through the Nest Hub (2nd Gen) or Apple HomePod. All through UD Mobile! I'm guessing that for the wifi based devices, the Zmatter dongle shouldn't be needed. For the thread based devices, it's not as clear. Thread is a wireless communications standard that requires a controller that acts as a router. It's like an extension to wifi, allowing a mesh network between devices, and using low power, which is important for battery powered devices. I'm guessing that the dongle will play a role here, though the mention of the Nest Hub or HomePod seems to imply that either one of those devices is also needed, or that it might be an alternative to the dongle. That should certainly all be cleared up soon enough for us. But your question is a good one: is the dongle necessary for Matter to work?

That's not an easy question to answer. It varies with how many walls you have what they're made of, etc. Ideally, any given devices would be able to "see" at least two other repeating devices, allowing the alternate paths to set up based on signal strength. That's what mesh is all about: getting redundancy through multiple alternate paths, instead of manually determining and configuring a signal path.

Well the version itself could always be fully capable, but could offer wizard style utilities for people who want to do simpler stuff like scheduled tasks or macros. A bit like the Alexa app from Amazon, which steps you through programming a routine. That could help someone get started. Then if they want to get in deeper, access the full programming screens. The mention of ipads in the case of Chris's friend Warren is another thing. I actually commented on this elsewhere, when it was mentioned that Apple Homekit support would be added. Apple users are more often than not non-geeks. They just want things to work without needing to go into technical stuff. This is where wizard like features might help with that.

Well, the more features and device support that gets added, the harder it is to create a dumbed down version. What do you leave out? I suppose you could have it just do macros and scheduled tasks...like a hub.

Any difference in range would probably be very minor. Zwave really depends on it's mesh network topology to get signals to devices that often aren't even in the same room.

Hopefully, they meant to say browser based...

Hah, naming devices for voice control has it's quirks. When you start to have many devices, finding good, unique names becomes a challenge.

My question is: how different will the look and feel of the new admin console be? For all it's quirks, we get used to them, so needing to relearn stuff is always a bit annoying. Will there be new console user features too? For example, it would be handy to be able to comment out program lines instead of always needing to delete them. New monitoring tools? Another thing that would be useful is a user log file that you can write to by program action. It would be handy to be able to do things like log the locking/ unlocking of doors, alarm activation, or for troubleshooting. It would be easier than needing to try to filter through hundreds of lines of the activity log. Just a few ideas.