IndyUDIuser

OK, dumb question... How do I link a wall switch to a lamp module in ISY? Do I have to create a scene? I think I already know this but want to confirm, before I mess anything up. Thanks.

Hmm. Maybe you've taught an old dog a new trick. I always assumed if I did linking through ISY then every time I tapped a switch the ISY would recognize my "switch on" action and THEN send a command to the lamp module. Thus a short delay. Next time I have to do any linking I'll use just the ISY and then see how things go. Thanks! Another question... If I suspect some older devices may have bad link entries in them, is there a way to wipe them clean (like a factory reset) using the ISY? For example, I've never liked trying to pull the little tab below a light switch paddle (air gap) to reset it. Always feared it would break off. It would be nice to tell ISY to "initialize" a device's memory somehow. Or if Insteon could design their switches so you just hold the OFF position for 15 seconds to force a reset.

I link devices directly together for speed. e.g. A wall switch linked directly to a lamp module turns the lamp on instantly. I then link all my devices to the ISY so that I can use programs, see their status, etc. Yesterday at 7AM all my lights suddenly came on. The same thing happened at 5PM a couple of days earlier. I looked in the ISY Log and there are no entries showing the devices being activated. No explanation. I gave up and deleted the ALL LIGHTS scene. Hopefully no more Insteon hallucinations.

When I discovered the pole lamp was no longer responding to the bedroom wall switch, the first think I did was try to link the wall switch to the appliance module. The linking beeped successfully, but the lamp still did not turn on/off with the wall switch. So next I did a factory reset on the appliance module and then manually linked it to the wall switch. Just like I've done for years. This got the wall switch working correctly again with the pole lamp. Then I had to remove it from Admin Console and re-link it to Admin Console in order to fix the broken Bedroom Lights scene so Alexa would turn the lamp off again. Anyways, everything is back to working the way it has for many years. Going back to the beginning of my post, why would simply adding a device (or devices) to an existing scene (All Lights) in EISY cause existing links in the devices to be wiped out? I just used "Add to scene". It never said anything about wiping out existing links between devices. Annoying to say the least. And the "New modules" dialog box thing is a bug that I've been having since v6.0.0. I have to reboot EISY to clear it out. I'm currently on v6.0.5. Oh, and here's another nit to pick... When I click Start Linking in console, the Linking In Progress dialog box appears, as well as a small timer dialog box. NEITHER ONE can be cancelled (if I change my mind for instance). The red X in the corner doesn't close either box (which UI standards usually require). But that flaw has been around for years, so never mind. LOL Thank you all of you for your comments. I'll try to remember this as yet another foible in Insteon programming (which often seems like a Jenga game).

Reboot got rid of the "New Insteon Devices" false dialog.

Oh, and now when I start up Admin Console I get a pop-up box titled "New Insteon Devices" and shows me the address for an 2635-222 On/Off Module. Sure enough it is the pole lamp's module. Every time I open Admin Console this dialog appear, and all I can do is close it. This module has been in use for years and worked perfectly until the changes described earlier. This is reminiscent of problems on several devices I was having before I upgraded to v6.0.5. Now it's happening again. Ugh. I'll reboot EISY and see if this goes away.

IDK. This is first time I've added so many things to a scene. But how is the EISY wiping out existing links within and between the modules? Makes no sense.

A few days ago, I was checking my EISY's setup in Admin Console. (V6.0.5) I had a scene called "All Lights" that I set up years ago. I decided to update it by adding more light switches and lamp modules. I right-clicked a number of items and selected "Add to Scene" and selected All Lights. After saving the changes I tested the Scene by turning it on and off. All the lights around me were activated as expected. So far so good. Then awhile later I went to my kitchen and turned on one of the three wall switches. No response. I tried a second switch, and it was nonfunctional as well. The third switch (master switch connected to the load) worked OK. I had to re-link the two slave switches to the main switch again (in both directions). Later I went to my bedroom and turned on the light switch. A pole lamp on an appliance module formerly linked to the wall switch no longer worked. I had to link it to the switch again. When I told Alexa to turn off the lights, the pole lamp didn't react. I had to go to the "Bedroom Lights" scene in Admin Console and remove and then re-add that module to the scene again. My memory is faint, but I believe this is not the first time something like this has happened to me (I've been using EISY and Insteon for 25 years). It's very rare, but then I don't make changes to my Admin Console very often. I haven't checked all my other devices to see if anything else was messed up, yet. Why did the simple act of adding devices to a scene corrupt so many links, both in the devices themselves and in the EISY? Rather frustrating.

Oh wow, thanks for the tip about FInd/Replace. I have never used that before. Very useful feature for the next time I tweak a line of code but forget to CAREFULLY click "Update" and then "Save". And therefore don't notice the wrong variable has been plugged into the code.. I run into that problem every so often.

OK, I confess... I found a line in one of my sub-programs (one I have not been paying attention to until now) that was setting iCurrentDayOfMonth to zero. I had accidentally used the wrong variable name in that program and didn't notice it until now. I corrected that and now all of the variables seem to be setting correctly. I added code to the beginning of the master program to initialize all variables to zeros before calling all the sub-programs (just so I can see this happening). I eliminated some of the waits, although I still wait 1 second between each sub-program call. So far so good. I'll check this tomorrow to see if it is working in production as expected. FIngers crossed.

Ugh. Programs still aren't working as expected. I added more WAITs between every line of code in every program so I can try and see what it is doing to the variables, but that made it worse. I can see what appears to confirm my original post, in that the variable iCurrentDayOfMonth gets set correctly, then the INIT gets set, and the variable is ZEROED OUT. So I added another line to set the variable again (after copying it to the INIT) and that seems to work. To me this looks like a bug in the OS. But now all the WAITs I've been adding are causing other things to malfunction. Programs are running out of order. More variables are being set incorrectly. I'm thinking I may have to throw out all the individual programs I wrote and write just one large program that does all of the calculations in sequence as I expect. More debugging..... DATTM SetCurDayOfMonth - [ID 0078][Parent 0028] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $iCurrentDayOfMonth = 0 Wait 2 seconds $iCurrentDayOfMonth Init To 0 Wait 2 seconds $iCurrentDayOfMonth = [Current Day of Month] Wait 2 seconds $iCurrentDayOfMonth Init To $iCurrentDayOfMonth Wait 2 seconds $iCurrentDayOfMonth = [Current Day of Month] Else - No Actions - (To add one, press 'Action')

I only learned about "INIT TO" in the last year. Setting the INIT value allows the ISY to reset variables to the desired values if the ISY reboots for some reason (i.e. power blip).

Well, the problem came back again after the program executed at midnight on schedule. The variable shows 0 while the INIT shows 14. I experimented with adding a couple of initializer statements (so I can watch the variables get flipped while the program is running) as well as WAIT statements between each line, thinking the executor is not running them in the sequence they are coded (or running too fast?) Then I removed the WAIT statements one by one, testing over and over to make sure the code still worked. The following code finally does what I expect when the THEN clause is executed. For now at least. DATTM SetCurDayOfMonth - [ID 0078][Parent 0028] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $iCurrentDayOfMonth = 0 $iCurrentDayOfMonth Init To 0 Wait 3 seconds $iCurrentDayOfMonth = [Current Day of Month] $iCurrentDayOfMonth Init To $iCurrentDayOfMonth Else - No Actions - (To add one, press 'Action') Note that if I set the wait statement to 1 second, the program doesn't work for some reason. I don't see the variable or its INIT being changed. Change it back to 3 seconds and then I can see the values changing. Weird.

Thanks for the information. I have not looked at Plug-ins in a long time because I don't use them and haven't taken the time to learn about them. I'm just an Admin Console user, controlling Insteon devices in my home. I poked around in the PG3 interface and see two listed as "Purchased". I don't remember purchasing them or what they are for. Perhaps from years ago. Both are described as "Notification Node Server for Pushover and Telegram" with one labeled Beta and one Production. I'm guessing they have to do with sending notifications to my phone, so I'll leave them as-is. I'm a retired batch developer (C and Unix) so all this Polyglot/GitHub programming stuff is foreign to me. Will take time to learn. Wish there was a good old-fashioned hard-copy book on all this to follow. I waste too much time wandering around lost in the forum and wiki. LOL ;-)

I agree with oberkc. I upgraded to 6.0.5 a few days ago. After reboot the "Added" dialog went away. Today it came back. Rebooting again cleared it. Don't quite understand what is going on here.