kclenden

Insteon is a mesh network. This means that in theory the more devices you have the more reliable the network is. This reliability comes from the fact that most devices on the network repeat all commands on the network. For the devices to all repeat commands without talking over each other, there has to be some rules. That is where "Hops" come in. When a device sends out a command, it specifies how many "Hops" are allowed for the command. This tells all devices on the network how many times to repeat the command. When a device first receives a command, it subtracts one from the "Max Hops" and repeats the command. It continues repeating the command like this until the "Max Hops" becomes -1 at which point it stops repeating the command. While devices are repeating commands, they can't send out any commands of their own. Additionally, even devices that don't repeat commands (battery operated devices) aren't allowed to send out commands until the other devices are done repeating the original command. So a command sent out with "Max Hops" equal to 3 will use up four times as much of the network's time as a command sent out with "Max Hops" equal to 0. But that command will also be more likely to reach its intended target because each repeater adds a little power to the signal. What the Event Viewer log shows you is the earliest point that the device received a command. If it received the command when the originator initially sent it, the "Hops Left" will be 3. If it didn't hear the original command, but did hear it the first time other devices repeated the command then "Hops Left" will be 2. And so on. As larryllix says, a "Hops Left" of 0 means the device heard the command but not until the very last possible moment. Since you're seeing some "Hops Left" of 0, it means that there are likely times where commands are just lost and don't appear in the Event Viewer log at all. You definitely have communication issues. They could be the result of a failing PLM, but they also could be caused by noise or signal suckers on the powerline. The link (https://wiki.universal-devices.com/index.php?title=INSTEON:_Troubleshooting_Communications_Errors) posted by Techman is as good a place as any to start to understand some of the things that can hurt and help the powerline network.

Try opening the Event Viewer (Tools->Diagnostics->Event Viewer). Set it to Level 3. Then select one of your dimmers and perform a "Query". In the Event Viewer you should see a [Std-Direct Ack] record that displays "Max Hops" and "Hops Left". Are those two values the same? If not, what are they? Do the "Query" several times for several different devices. If the "Hops Left" is regularly less than the "Max Hops" it means that there are consistent communication issues.

As you found via your searching, the changed value in the device links table is because there are two bits that the device manages on its own to account for communication errors that it perceives. The ISY isn't informed about these changes so its copy of the link table remains as it was from the beginning. Since UD commented in the thread to which you linked, they may be filtering those bits out in V5, (I'm assuming you're on V4 since your screenshot are a little different than my screen) but I wasn't able to confirm that since I couldn't find any of my devices with a Controller record that had been changed in its link table. I did find some devices that had an extra record in the device link table but they were always for Responder records and changed "no clean-ups" to "Broadcast for a cleanup". They also changed a byte in the device link record that the developer documentation says is ignored, so I'm guessing they may be a later change to firmware that Smarthome hasn't documented to the public. As larryllix says, Insteon devices essentially contain mini CPUs and memory so it is possible for them to get corrupted via voltage spikes or line noise. Additionally, I'm led to believe that Smarthome does testing before devices leave the factory and sometimes the device doesn't get reinitialized correctly. So I always do a factory reset immediately after installing a new device. Learned that one the hard way.

Based on the model # and date purchased I think we can rule out a couple things: Spurious X-10 commands since this plug-in module does not support X10 Spurious local load changes since this plug-in module does not support load sensing Spurious All-On commands since this is a newer plug-in module and presumably doesn't support the All-On command That would leave a couple other things to consider: Corrupted link table - factory resetting and restoring the device should fix this. Activation by other programs - your search should have found any other programs. If you used "Your Devices" and selected the device when you did your search, you might try changing to "Raw Text" and typing just a portion of the device name, say "Theater", then click "Find". But keep in mind that "Raw Text" searching is case sensitive. I seem to recall some reports that searching by "Your Devices" didn't always find every instance. Accidental inclusion in a scene - you didn't specifically answer larryllix about whether the device was included in any scenes, but the fact that there were only three lines in the device link table seems to confirm it's not in a scene. Just to be sure you should select the device and look at its memberships. Local activation - is there any way something could occasionally bump the ON switch? Maybe a curious pet? Hardware issue - a defective ON button could cause spurious local ON commands

I don't believe that the log actually shows command actions, but merely status changes. There's clearly no Web line associated with the 12:09 status line, but depending on what kind of plug in module you have there are other things that could cause it to come on that wouldn't appear in the log. Is the module Insteon? Z-wave? X-10?

I'm running v5 of the firmware, and under Action->Your Devices there is a "Write Changes" option. I'm not sure if this is available in V4. I think the only reason you need to press the SET button on wireless devices is to wake them up so that they can receive the updates. Whenever a motion sensor senses motion it wakes itself up to send an "On" command. It remains awake for a little bit of time after that. So all you have to do is look for the motion sensor to switch on and then write updates. Something like: If 'Motion Sensor' is switched On Then Set 'Motion Sensor' Write Changes Else You could do something similar for your leak sensors, but instead of looking for it to switch on, you could look for the heartbeat, though I'm only guessing that a leak sensor wakes itself up to send a heartbeat.

I don't know what the timeout is on the older motion sensor, but my guess is that the motion sensor timeout is kicking in after 1 minute, turning the motion sensor off. This would cause the IF to be reevaluated and the ELSE being run. I think you want to use IF 'Mouv. Garage - Sensor' is switched On instead of IF 'Mouv. Garage - Sensor' Status is On. Edit: Just noticed the "3.0" in the Timeout dropdown. While this would seem to indicate that the timeout on the MS should be 3 minutes, I'm not sure the ISY always knows the internal values of sensors. You could try waking the MS up and then setting the timeout value to something longer to ensure that what the ISY is displaying for Timeout matches what has been set internally in the MS. Then your program above should allow a longer WAIT. Even if that works, I'd use "switched On" instead of "Status".

A little late to the party since Michel has said the current behavior in V5 is a bug, but yes in V4 when you set the backlight level for a device, the ISY remembers that value and displays it for you when you next look at the device's backlight level - even when the Admin Console is restarted. Though I'm on V5 now, I know V4 acts that way because I routinely used that capability when I installed new devices so that I could set their backlight level to match other devices near them.

What TrojanHorse is referring to is that your IF statement checks the status of the thermostat, and your third line has the potential to change the status of the thermostat. However, I don't think it's correct that the fourth line won't ever be executed. My understanding is that the IF statement won't be reevaluated unless a WAIT statement is running (which happened earlier, but not after you change the set point) or a REPEAT is executed or the program concludes normally (i.e. runs out of line to execute).

When I had a light mysteriously turning itself on, I eventually discovered that it had an X10 address set, even though I never set one. A factory reset and ISY "device restore" solved the problem. A factory reset and device restore may not help you, but takes little effort as a hail mary.

Thanks. That has removed my need to use the Themes option to change the Admin Console font size so whatever causes the Admin Console to reset back to default settings shouldn't impact me any more.

I have similar issues with Themes. I have a 4k monitor and need the font size set at 18 to make it readable. I can't pinpoint exactly what makes it revert to default, but it mostly happens when the computer is rebooted as opposed to the Admin Console merely being closed and reopened. Edit: I'm also running 5.0.14.

Having the write icon next to the buttons implies that the ISY needs to save information to the 2334-2. It could be that information is the links that would include each button in the scenes that you have configured. That would explain why nothing happens when you press each button. As Techman indicated, it seems like there could be a communication problem between the 2334-2 and the PLM. Have you tried opening the Event Viewer and the executing the write commands? That would allow you to see whether the 2334-2 is responding to the ISY when it tries to execute a write.

I'm glad Michel chimed in because it made me look at the Log. In doing so, I realized my post above wasn't correct because although I think of the Event Viewer as the Log, it's not what the Admin Console calls the Log. So I edited my post above to refer to the Event Viewer instead of the Log.

I don't have a thermostat so can't really provide any ideas based on experience, but wonder if maybe the thermostat doesn't push data to the ISY but instead needs to be queried. Perhaps querying the thermostat on a regular basis (e.g. every 30 minutes) would resolve the need to login to the ISY or use Mobilinc.

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.