kclenden

How do you have buttons A-D configured? Do you have them setup in scenes? If so, are they setup as controllers or responders? Do you have programs setup to execute based on button presses? If so, are you reacting to button status or control (i.e. switched on or switched off). In general, the more information you can provide, the better.

I don't think program execution is captured in the logs. For that reason, I created a state variable called "sCodeTrack". The first statements in the programs that I want to track are "$sCodeTrack=1" followed by "$sCodeTrack=0". I change the "1" to a different number for each program I'm tracking. So, for example, if I was tracking two programs, I would set sCodeTrack to 1 for the THEN of Program 1; set it to 2 for the ELSE of Program 1; set it to 3 for the THEN of Program 2; set it to 4 for the ELSE of Program 2. Changes to state variables are shown in the Event Viewer, so you know exactly when the programs you're tracking are executed. Note, though, that I said changes to state variables are captured. What this means is that if a state variable is assigned the same value that it already has nothing will appear in the Event Viewer. That is why I assign a value to sCodeTrack and then immediately assign the value 0 to sCodeTrack. This guarantees that if a program is executed twice in a row, both executions of the program will be tracked in the Event Viewer.

To put a finer point on what Larry wrote, a device can create a "switched on" event or a "switched off" event. Programatically they are two different events even though they come from the same device and represent opposite states. To handle this you could write two programs: Program 1 If device is switched on Then Send email "Device is on" Else Program 2 If device is switched off Then Send email "Device is off" Else or you can do as you have done above and handle it in one program via the "Else" section Program 1 If device is switched on and device is not switched off Then Send email "Device is on" Else Send email "Device is off" The "switched on" captures the switched on event and executes the "Then" section while the "not switched off" captures the switched off event and executes the "Else".

I setup a short-press routine and my button blinks twice also. I tried setting the button to non-toggle OFF and the button still blinks twice when pressed. I tried playing with button options like (LED on TX and No LED), but couldn't prevent the blinking while also having the LED illuminated. So I think the blinking is normal behavior, done by the switch, and is probably meant to confirm that your button press was accepted. In toggle ON/OFF mode you don't need the blinking as confirmation because the LED changes state from ON to OFF or OFF to ON. Interestingly, the length of time that the button blinks in non-toggle mode is similar to the length of time that you have to hold the button down in toggle mode to get consistent fade results. I wonder if that is a coincidence.

It appears that the 35% off special applies as well, so it's really only $3.24.

A quick search of my email archives show a couple years were they've had 20% off everything on the site for Black Friday through Cyber Monday. Those usually popped up in my email in the morning the day before Thanksgiving. So I would expect a notice literally any minute. Edit: Or I could have gone to the site, like Brian, and had better info. ?

I created the same two programs in my system, with the exception of leaving out the Lamplinc and Relay commands. I got exactly the same results as you. So I looked at your logs but didn't see anything that stuck out as wrong. So, like you, I removed the "scene on" command and then everything worked as expected. Then instead of readding the "scene on" command, I added a "beep" command so that there would be some feedback. The programs continued to work as expected. But I also noticed that the button light was still coming on when I released it, and going off when the timer turned it off. This got me to thinking about the keypad toggle modes. Mine was clearly in "toggle ON/OFF" mode. Clearly the keypad has to use something to know whether to toggle ON or OFF. Perhaps it was using the button light as that indicator. So I changed my button to "non-toggle ON", and added the "scene on" command back to the program. Magically the programs continue to work correctly. So my theory is that turning the button light on while in the middle of a fade up is confusing the keypad. But I don't know why holding it down an extra second and a half keeps the keypad from becoming confused. In any case, by taking it out of "toggle ON/OFF" mode, it seems to relieve the keypad of the need to monitor the toggle state and keeps it from becoming confused. By the way, while I was doing this testing, I used a trick that I think might be useful for you in the future. I have a state variable called "sCodeCheck". At various points in the programs I want to check, I add "sCodeCheck=x" where "x" is unique at each point in the code. So I had "sCodeCheck=1" as the first line of the THEN in "KeypadLongTrip", and "sCodeCheck=2" as the first line of the ELSE. The first line of "SensorLongTimer" THEN was "sCodeCheck=3" and the first line of the ELSE was "sCodeCheck=4". Immediately following each of those lines was "sCodeCheck=0". The reason I do this is because the Event Viewer log shows changes in state variable values. This not only allows me to confirm in the Event Viewer that specific sections of code were executed, but also makes it easier to tell which Insteon communication was a result of which section of code. The "sCodeCheck=0" is to make sure that if a section of code is executed sequentially (e.g. because a WAIT is interrupted and the IF is reevaluated with the same result as before) the value assigned to the state variable will be different and the action will be shown in the Event Viewer. For example, if you assign 1 to a variable, that will appear in the Event Viewer. If you again assign 1 to the variable it will not appear in the Event Viewer because the value has not changed. By assigning 0 in between, You'll see both times that 1 is assigned.

Joe, It might be helpful if you use the Event Viewer, set at Level 3, in the Admin Console to watch what happens when you press the keypad button. That will allow you to observe the communication between devices. I have a very similar setup to you (Keypad Button B controls Garage Light) but have two Switchlincs in the garage that control one light. Here is the Event Viewer output from pressing the keypad button to turn the light on, then waiting about 15 seconds and pressing the keypad button to turn off the light. All the entries from 06:50:46 PM are the result of pressing the keypad button to turn on the garage light. 22.8D.EB is the address of my keypad and the following 2 means second button. 22.AA.32 and 22.A6.F4 are the Switchlincs in the garage. The entries from 06:50:59 PM are the second press of the keypad button to turn off the garage light. What do you see in the Event Viewer when you try this? When you press the button a second time, do you see the initial communication from the keypad? If so, is there any response from the switch in the garage? Do the "Max Hops" and "Hops Left" equal each other? Edit: I'm on v5 of the ISY firmware. If you're on v4 the output in the Event Viewer might not read exactly the same, but should still represent the same set of communication events.

If I understand what you're saying (i.e. ran a long cable between PLM and ISY) then you should know that the ISY does not communicate with the PLM via ethernet even though it uses what looks to be an ethernet cable. I believe it uses serial communication. The theoretical maximum serial cable length when communicating at 9600 baud would be able 50 feet, though YMMV.

Your point of clarification was good as most people probably think once a program with no IF conditions starts to run it will eventually complete. I was only commenting about what I perceived to be the OP's use case. Something like this: Program1 If A and B Then Call Program2 (Then) Else Program2 If Then Turn On Light Wait 60 Seconds Turn Off Light Else In this case, while Program2 isn't really completely isolated from Program1, it is effectively isolated since a change in A or B would cause the Else to run not the THEN. But... Program1 If ( A and B) or C Then Call Program2 (Then) Else Program2 If Then Turn On Light Wait 60 Seconds Turn Off Light Else In this case Program2 really isn't isolated from Program1 since either "(A and B)" or "C" could have originally caused the THEN to run such that a change in either "C" or "(A and B)", respectively, could cause the THEN to run again which would restart Program2.

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.

Thanks. Between the state diagram and the program comments your programs are really easy to follow.

Nice state diagram! Having been playing around with a motion sensor for the last couple of weeks, I'd love to see your programs.

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