kclenden

But.... That should only be a problem if the initiating program contains an OR in the IF logic. If it's a bunch of ANDs then a change in any of the conditions should cause the opposite program section to run (THEN -> ELSE or ELSE -> THEN) and the command that started the second program shouldn't be executed again.

While you may be correct when you refer to "nodes", my testing indicates you are not correct about PLM links and scenes. Starting from what I shared above, I'll expand. The highest record number in my PLM links table was 274 (Count=275). I added one more device to a scene that the two switches above were in. The highest record number in my PLM links table increased to 275 (Count=276). I added one more device to the same scene and the highest record number increased to 276 (Count=277). Then I removed both of the devices that I just added and the highest record number decreased to 274 (Count=275). Not content with just seeing the highest record number increase, I also examined the actual links in the PLM links table for the two new devices I had just added to the scene. Both devices now had a record in the PLM links table that began "E2 13" followed by their address. After removing the two devices from the scene, both devices no longer had a record in the PLM links table that began "E2 13" followed by their address. Additionally, there were 8 records in the PLM links table that began with "E2 13" before my experiment adding two devices to a scene. That is exactly the number of devices included in the scene. After adding the two new switches, there were 10 records in the PLM links table that began with "E2 13". After removing the two devices from the scene, there were again 8 records in the PLM links table that began with "E2 13". The "13" in those PLM links table records is called the "Group" in Insteon documentation. It seems clear that when you create a new scene, a new group is created in the PLM links table. And when you add a device to the scene, a record assigning the device to that group is added. Using your concept of "nodes", it seems that adding a device to a scene creates a new node for that device and thus a new record is added to the PLM links table.

I don't think this is quite accurate. When I look at my PLM table, it appears to me that there is are two records in the PLM for every device (one as a controller and one as a responder) and then a link for every device for each scene it is contained in. Here are two examples: 1B.D6.A7 and 1B.D6.F1 are each a Dual Band SwitchLinc Dimmer (2478D). They each are responders in two scenes. Based on that I think lines 0, 1, 4 and 5 are the default links that every device gets in the PLM table which allow the PLM to issue commands to, and receive status from those devices. I think lines 2 and 6 are links for one scene to which both switches are responders, and lines 3 and 7 are links for the other scene to which both switches are responders. Additionally, keypads counts as 6 or 8 devices since each button can be controlled, or responded to individually.

You don't need to put the button into the scene. Are you sure you're using a state variable and not an integer? If you are using a state variable, then you'll probably need to post your programs 3 and 4 for people to review. Simply right-click on the program and choose "Copy to Clipboard" (not "Copy") and then you can paste them into your forum reply.

Or if you don't want to try those two things yet, you could "Show Device Links Table" for the motion sensor and post the result here so that some of the more knowledgeable people could ascertain whether any important links are missing.

That is indeed strange. It's as if no link exists between the ISY and the motion sensor so that when the motion sensor sends a motion event the PLM ignores it. Have you tried deleting the motion sensor from the ISY and then relinking it? Have you tried factory resetting the motion sensor? If not, you might try both of those things.

Insteon device to device communication has built-in retries that I'm not sure exists between the motion sensor and the ISY. Additionally, the motion sensor is an RF device that relies on other devices to put its communication onto the powerline for it. So perhaps the motion sensor is in an area that results in marginal communication. What devices are near the motion sensor? Have you tried moving the motion sensor to another location temporarily to see if its communication is picked up by the ISY?

It looks like you did a "Copy" or an "Export to Clipboard" instead of a "Copy to Clipboard". "Copy to Clipboard" is much more readable.

Thanks. I did a brief check of the wiki and it wasn't immediately clear to me that the extra user id's were for nodeserver authentication, but it was late at night and I didn't dig deep. ?

I don't seem to be able to add a new user id. Well, more exactly, I can add a user id but it doesn't appear to work. I'm running v5.0.13D. Here's what happens: Under "Set User ID #1" - I add a name and password Select "Yes" on confirm screen Logout of Admin Console Login attempting to use new User ID and receive "Failed, Retry Authentication ISY" Login using Admin ID Now here are two more strange things: I am able to change the name and password for the Admin ID The name I set for User ID #1 seems to have been saved for User ID #1 because if I try to create User ID #2 using the same name I used for User ID #1 I get an error after clicking "Yes" on the confirm screen, though the error says "Userid length not valid". If I choose a different name for User ID #2, I can click "Yes" on the confirm screen without getting an error. What am I doing wrong?

Thanks Michel. That makes sense. And I've been able to confirm that the heartbeat records in my log each appear the day after my ISY was rebooted (either by me or a power outage) or in other words on days where the heartbeat changed from OFF (because of the previous reboot) to ON.

Interesting. I don't have an answer for you, but my system does the same thing. Running 5.0.13C. My log has about 3-1/2 months of data and within it I see three heartbeats from my open/close switch that monitors my garage doors. They show up on 7/13, 8/18, and 9/06. So they're not evenly spaced being 36 days and 19 days apart. I have a set of programs running that alerts me if a heartbeat is missed, and I've only had a couple alerts over the last three months, so there should be way more heartbeats in my log.

As Larry said, with these two programs you have setup a notification loop that begins when the temperature reaches 80 or lower and then keeps occurring every 15 minutes (plus the time it takes for the temperature to change by a degree). Not to mention that the temperature is probably never going to get up to 94 because you always turn the AC back on 15 minutes after the temperature got to 80. Why not have something like: Temp too Hot If Status 'Thermostat - Main' >= 94 (Temperature) Then Set 'Outlet-AC' On Send Notification to 'Yahoo' content 'AC ON Message' Enable Program 'Temp too Cold' Disable Program 'Temp too Hot' Else Temp too Cold If Status 'Thermostat - Main' <= 80 (Temperature) Then Set 'Outlet-AC' Off Send Notification to 'Yahoo' content 'AC Off Message' Enable Program 'Temp too Hot' Disable Program 'Temp too Cold' Else

Your programs look fine to me. If you hit the switch, then under the "Summary" screen you should see that "Garage Motion Timer" or "Laundryroom Timer" is "Running 'Then'" under the Activity column. When the lights go out 1 or 2 minutes later, are "Garage Motion Timer" and/or "Laundryroom Timer" still "Running 'Then'"? If so, then something else is turning the lights out. Either another program, or a link between the motion sensor and the light / switch.

You can sort of do this with the event viewer (at least in v.5.0.13C). The last two entries show me changing the value of a state variable from 0 to 1 and then back to 0. Only state variables, not integer, seem to appear in the event viewer, probably because they are triggering variables and integers aren't. While you can't choose to track just a particular variable, you do get a detailed log of when the variable changed and to what value.

The WAIT statement executes the specified wait, but also allows the IF to be reevaluated any time one of its conditions changes. So you need to move the commands under the THEN to another program that has no conditions in its IF and call that program from your existing THEN.

Yep, I read the page, but clearly missed it buried in the bullet points. Though even what's listed isn't very specific. Up to a 90 degree arc? Is that left & right? Up & down? And why "up to"? What will impact whether it's 90 degrees or only 60? And 30 feet detection is straight ahead, I assume. What about at 15, 30, 45, 60, 75 or 90 degrees off center (left & right and/or up & down)? Then I read the "SPECS" page where I expected to find it, but didn't, so assumed there was no reason to read the overview page again. My bad, I guess.

This isn't really an ISY question, but I know some of you have the 2844-222 so I thought I'd take a shot at asking a question here. What are the sensing specs for this Insteon device. By that I mean how far away can it sense motion and at what angles (left & right and up & down)? The Smarthome spec page for the 2844-222 doesn't provide this information so I realize that your answer will just be based on experience but that would better than nothing. It seems strange to me that a manufacturer wouldn't provide this information for one of their devices. How is a potential buyer supposed to know if the device will meet their need? Thanks for any response and trust that if I buy some and they don't match your specs, I won't blame you. I'll blame Smarthome.

I believe that two or more years ago the "All On/All Off" command was removed from many Insteon devices. So you're probably seeing your older devices respond to the "All Off" command and your newer devices ignore it. By design, I don't think devices ever sent a reply to "All On/All Off" commands because that could cause a huge flood of activity on the powerline all at once. So it's likely that the ISY just assumes that after it sends an "All Off" command that all devices have switched off so it changes the status of all devices to "Off". Then when you do query a device that is still on, its reply tells the ISY that it is still on and the ISY changes its status accordingly. If you want one command to be able to turn all your devices off, you'll have to create a scene that includes all of your devices. Then you merely turn that scene off.

What version of the firmware are you using? What is the model # of your switches. I'm currently on firmware 5.13B. I've tried the Admin Console page for both a 2477D dimmer and a 2477S switch and both the "Backlight %" and the "Options-No LED" have an immediate effect on the switch's backlight. If you're not seeing the same, you should try opening the "Event Viewer" from Tools->Diagnostics. With it open, try changing the "Backlight %". You should see three lines appear in the Event Viewer". One that says "Writing 1 bytes to devices". One that says "Memory: ...". And one that says "Writing 0 bytes to devices". You can also change the backlight programatically via the ISY. Within the THEN or ELSE of a program, choose the Action "Your Devices", specify which device from the dropdown, choose "Backlight" as the command, and then choose a %.

The white-on-green "10011" icon indicates that the ISY has information to write to those devices. You should try right-clicking them and choosing "Write Updates to Device".

You didn't mention how old your PLM is, nor how old it was when this started happening. If the answer is 2+ years, then that combined with your symptoms really point the finger at a dying PLM.

If I remember correctly, when I wired up my Fanlinc, the old wiring was setup with a switch that controlled power to the fan and the pull switches on the fan controlled the motor and light. So I didn't have an option to wire the fan light to the keypad switch. Are you sure your load wire is just supplying power to the fan light and not the whole fan? If it is just supplying power to the light, I'd probably use the red load wire to control the fan light since direct switch control is going to be a smidge more reliable than Insteon traffic when operated locally than a scene, but in actual practice I doubt it matters.

But how do you get the value into the programs? When I enter "12.10", it puts "12.1" into the program.

I liked your idea for using two decimal places for looks until I saw what the ISY does with far right zeros (hint - same thing it does with far left zeros). So the 10th, 20th or 30th of a month ends up as MM.D. Should still work correctly but not as pretty.