LeeG

bbtm The fact the LampLincs are Red indicates the ISY understands the device has Controller capability and should have an A201 .. .. .. Responder link in the ISY PLM. These devices have load sensing circuits such that if the manual ON/OFF switch on the lamp itself is used to control the load the LampLinc will turn On and Off in response. This state change is reflected to whatever devices have been linked as responders which includes the ISY. When I turn the lamp plugged into my v.33 LampLinc On and Off, the Admin Console display for the LampLinc changes the Current State to reflect the status of the load. Also the Insteon device that is linked as a responder to the Scene for which the LampLinc is a Controller turns On and Off. This allows a lamp on a night table next to the bed to control and primarily turn Off the bedroom lights if left On. Actually I find load sensing more convenient that reaching down to Outlet level to use the buttons on the newer Dual Band Lamplincs. Lee

bbtm All the devices which have an A201 .. .. .. Responder link record in the PLM are capable of being a Controller. That is, these device can send status changes to the PLM. All the devices which do not have an A201 .. .. .. Responder link record in the PLM are Responder only devices (no Controller function) which cannot send status changes to the PLM. The LampLinc v.33 seems wrong. LampLincs have Controller capability which can send status change messages to the PLM. I have a v.33 2456D3 LampLinc which does send On/Off state change messages as the lamp plugged into the LampLinc is turned On/Off manually. What is the numeric device type of that LampLinc? The OutletLinc is a Responder only device. It cannot send status changes to any device as it has no Controller capability. Only InLineLinc w/Sense has Controller capability. ApplianceLincs do not have Controller capability. EDIT: a device that is a Responder only (cannot send status change messages) can be identified by the lack of information in the Quick Start Guide and online User Guide for linking it as a Controller. Lee

mbrett Use New INSTEON Device, enter Address, Name and Device Type ([07.07] Compacta EZIO6I). I just deleted and added my EZIO6I using 3.1.2. If this does not work I suggest moving to 3.1.2. Describe what problem is being encountered at that level. How old is the EZIO6I? Lee

sanders2222 Be careful if purchasing new switches. The industry standard nomenclature for NO/NC magnetic switches refers to their state when the magnet is away from the reed switch. That means you need a NC magnetic switch, closed when the magnet is away from the reed. Unfortunately some companies (including some of the switches Smarthome adversities) are labeled the opposite. Some of their NC magnetic switches are open when the magnet is away from the reed. The nice aspect of the wide gap magnetic switch that Smarthome distributes with the Garage Kit is the switch contains both a NO and NC switch so the same switch will give a Sensor On or Sensor Off with the door closed depending on which side of the switch is actually used. Lee

sanders2222 If the magnetic switches are changed AND the Trigger Reverse option is turned OFF, the Sensor will be physically ON when the door is open (opposite of today) but the ON/OFF commands will also be reversed because of the change to the Trigger Reverse option being done at the same time. When the door is open the Sensor will show ON in the Admin Console (Green LED will be ON), the KPL button will be ON, etc. When the door is closed the Sensor will show OFF in the Admin Console (Green LED will be OFF), the KPL button will be OFF, etc. By changing both the magnetic switches from NC to NO (or maybe the reverse of that) and change the Trigger Reverse option, the effect is to keep the same ON command for door open, OFF command for door closed relation you have today and the Query will return the same result. The Query will return ON when the door is open and OFF when the door is closed. There is one addition change that is required. With two doors being monitored by a single IO Linc, with the magnetic switches in series today, when the magnetic switches are changed they will have to be wired in parallel. Today if either switch is open (either door is open) the Sensor no longer sees GND. When the magnetic switches are changed, when either switch is closed (either door open) the Sensor needs to see GND which requires the magnetic switches to be in parallel. It sounds a little complex but when all the changes are implemented, when either door is open, the Sensor will show ON in the Admin Console and the KPL button LED will be ON. No Program changes are required because the effect of changing the magnetic switches and changing the Trigger Reverse option at the same time keeps the commands issued by the IO Linc for door open/closed remains the same. Lee

sanders2222 From the IO Linc perspective the Sensor is ON when the door is closed. This is what the Green LED being ON indicates when the door is closed. For the posted Program to work the IO Linc must have the Trigger Reverse option set. This causes the IO Linc to send an OFF command when the Sensor turns ON (door closed) and send an ON command when the Sensor turns OFF (door open). This arrangement works fine but does expose one situation. If the IO Linc is Queried the actual state of the Sensor is returned, not the reverse indication the Trigger Reverse option causes. When the door closes and the Sensor turns ON (Green LED ON) an Off command is sent to the ISY because of the Trigger Reverse option. If the IO Linc is Queried an ON status is returned (opposite from the last command sent from the IO LINC) because the Senor is actually ON. The bottom line is the IO Linc should not be Queried when the Trigger Reverse option is used. Use of Query puts the IO Linc Sensor state in the ISY out of sync with the commands that are normally received. This is why I always recommend NOT using Trigger Reverse. If you used the Smarthome garage kit the magnetic sensors have a NO and NC magnetic contact. Simply use the other contact from what is currently used and stop using the Trigger Reverse. Cannot say this is your problem but it is a common situation when using Trigger Reverse and Query. Lee

sanders2222 What is the state of the IO Linc Green LED when things are not in sync? Is the IO Linc Green LED normally On or Off when the door is closed? Lee

oberkc I'm always amazed at what I learn every time I try something new. A loop is a possibility as I created one by mistake. Coded a Dim rather than a Bright so the status never exceeded 25%. Changed the Program statement while it is was running and it eventually came out of the loop. This technique is actually very interesting. It in essence provides the function of a While loop as the If is executed at the beginning of each loop interation. As with all While statements an unending loop can be the result if the Program is not coded correctly. Now that I look at this with benefit of some sleep the status updates associated with Scene execution are what is running behind rather than unexecuted Scene commands being stacked. Does not change the end result. Lee

oberkc I coded the Program and ran it with Event Trace to see what was actually occurring command wise. The "Run Program X25 (If Clause)" Action causes the Program to repeat starting at the If. Run is not affected by the fact that the Program is Disabled. The Disable does stop the ISY from independently dispatching the Program when the status of "X" changes. Lee

ergodic The Scene command runs faster (executes more commands) because there is no device ACK associated with a Group Broadcast message. I'm still unclear on the objective versus method. I understand the desire to keep the status LEDs in sync. I think what is confusing me is that the point of using a Direct device command is to change its state/status without affecting other devices that might be in a Scene with that device. If the objective is to keep the three devices in sync then a Scene is the method of choice. If a Direct command is the mechanism of choice for whatever reason then send a Direct command for 25% On to each device individually. The devices respond sequentially rather than simultaneously but they will be in sync. Perhaps knowing why a Direct command is preferred over a Scene. Sorry if I am missing the obvious. I am a little sleep deprived. Lee

Ergodic The Program is running faster than the device is responding. By the time the “status†has been updated to 25% or higher several more Program Action statements have been executed and the I/O queued for execution. The Program stops issuing Action statements when the If becomes false but that does not stop the queued I/O commands from executing causing the device to effectively over run the desired stop point. This type of programming would require a new ISY Insteon Action variant that waits for the Insteon command to complete execution and post the results before continuing with the next Action statement. Scenes can be defined to set each Responder to a specific On level. The On Level can be dynamically changed for each Responder with a Adjust Scene but this is changing the stored On Level value in the Responder link record, not actually changing the On Level. To see the effect of an Adjust Scene the Scene would have to be commanded On again. This is not a fast process as a few commands are required to change the data in the responder link record before issuing the Scene On which is another command in itself. What cannot be done at the Scene level is to dynamically specify the On Level when the Scene On is specified. The Insteon Scene command has no placeholder for an On Level for every possible Responder that could exist in the Scene. The Bright and Dim commands alter the On Level across 32 steps so from an Off status a Dim Action can be executed 9 times to reach a status above 25%. Perhaps if you can explain the objective there are other alternatives. Lee

PBusby There is no limit to the number of devices that can react to a Scene command. The ISY issues a Group Broadcast message containing the particular Scene (Group) number. All Insteon devices capable of receiving Insteon messages look at the Group Broadcast message and scan their respective link database for a match to the Controller (PLM) Insteon address and Scene (Group) number. If a match is found the device reacts, essentially having all the devices react near simultaneously. If the Group Broadcast message fails to reach a particular device of course it will not respond. That is why powerline reliability is so important. There have been cases where a device will turn On but have difficulty turning Off if the load it controls is generating noise. Some CFLs can cause this. Lee

Vipola Remember that KeypadLinc Secondary button LEDs cannot be turned Off using a Scene On with 0 % On Level. Lee

The Variable Init value is what the variable is set to when ISY boots. The Program is setting the Init value to a number that is bumped each time the ISY boots. The effect is to have an incrementing Variable Init value which reflects the ISY boot count.

Not that I know of through the ISY. If you have a spare PLM or can temporarily connect the ISY PLM to a PC with XP the free Simplehomenet Utility Suite can remove/change an X10 code definition. The Utility makes not changes to the PLM so it can be safely used in this manner.

ergodic Don't know if any of this tracks to what you see. I have a very intermittent situation where the Admin Console does not display any device status. Normally I just shutdown the Admin Console and invoke it again with correct results. However, if I miss the fact that device status is not being displayed and try to do some Link Management function such as Start Linking, I see similar results to what you describe. Removing power from the ISY is the only way I have found to clear the situation. Restarting the Admin Console does not clear the problem. I normally do not try any Admin Console function when device status does not display as I know the thread the Admin Console is dependent on to get status from the ISY is not working. The failure to display device status is intermittent to begin with and trying to do link management in that situation is even more rare. Never tried adding an EZX10RF X10 code when device status is not being displayed but there is such similarity in symptoms they seem related. Watch for device status not being displayed by the Admin Console and see if it is associated with problems with link management and the EZX10RF. Lee

kagale If the KeypadLinc button controlling the fan is the primary load control button it can be turned Off directly by the Program. If the KeypadLinc button is a Secondary button an ISY Scene must be used to turn the KeypadLinc button Off. Define an ISY Scene. Under the My Lighting tree right, click on the KeypadLinc Secondary button, select Add to Scene and add button as a Responder to the Scene. In the Program turn the ISY Scene Off to turn the Secondary KeypadLinc button Off. Lee

Define an ISY Scene. Right click the KepadLinc button that you want to use and add it to the ISY Scene as a Controller. Right click on the LampLinc and add it to the ISY Scene as a Responder. When the updates to both devices are complete the LampLinc will turn On/Off using the KeypadLinc button.

That approach should work. The default maximum zone run time for each zone is 30 minutes. The maximum run time needs to changed using the Admin Console Set Options button for each zone. Otherwise the EZFlora will shut the zone off at 30 minutes.

Vipola You are confusing the Scene On/Off command with Responder action. Since the beginning of Insteon many years ago a Responder has always been able to respond to a Scene On command with a unique On Level/ Ramp Rate or be turned Off by the Scene On command. A Scene Off command turns the responders Off. Because a Scene may consist of multiple responders the way an individual Responder reacts to the Scene On command is stored in the responder, in the link record in the responder that represents the Scene. The On Level and Ramp Rate for each Responder is set by Scene management. Either through the Admin Console or Program Action statements the set change the On Level and Ramp Rate values stored in each responder. What you need is some means of knowing the last Scene command issued or that any command has been issued for a particular Scene. This is accomplished by triggering on the device button/paddle that initiates the Scene if initiated at the device itself. If a Program is issuing a Scene On/Off command it can also set a State variable which would trigger the same Program that is monitoring for a button/paddle press that issues the Scene On/Off command. Currently the ISY has no facility to trigger a Program based on a named Scene command. This would be something unique to the ISY not based on Insteon architecture as the architecture has no concept of Scene status. Could be an interesting ISY function so long as it was understood to be last Scene command issued having nothing to do the current status of the actual responders. Lee

Insteon architecture has no concept of Scene On/Off status. Take a Scene that when turned On Sets Responder A to 100% Sets Responder B to 50% Sets Responder C to Off Now, what do changes to these Responders do to Scene status. If Responder B is set to 100% does that constitute a Scene Off status. If Responder C is turned On does that constitute a Scene Off status. I suspect if you asked 6 people you would get 7 different answers. A simple “last Scene command issued†could be tracked with an ISY variable. Whenever a Program turns the Scene On set the variable to 1, when it turns the Scene Off set the variable to 0. That might provide some meaning but would have no relationship to the actual status of the Scene Responders. If the Scene is being controlled by a button/paddle press than a Program could be triggered on the button/paddle press such that when button/paddle On is received the variable is set to 1. A Program can be triggered by defining the variable as a State variable and have a Program triggered whenever the state variable becomes 1.

ergodic When the New INSTEON Device completed there should have been a node defined for the EZX10RF. When the Add X10 Device to EZX10RF ran it assigned the X10 code to the node that was created by the New INSTEON Device. Another node would not be defined. The posted trace for the Add X10 Device to EZX10RF for the first node is very quick. It matches what I traced on my system. Remember the EZX10RF node is not displayed in collating order in the My Lighting tree. It should appear at the end of the devices before the Scenes. Once the C1 X10 code has been assigned to the first node I don't think it can be assigned to another Group number (that is from memory). Sending an X10 C1 On would not generate an On for multiple nodes. Lee

ergodic Using Add X10 Device to EZX10RF to initially add the EZX10RF to the ISY creates a conflict between the link record being created using Set button simulation and the process of determining the EZX10RF PLM memory size (or maybe the fact the link record is subsequently deleted later). Results in a link active bit not being set that is required for the EZX10RF to use the link record. The solution is to use “New INSTEON Device†to add the EZX10RF device to the ISY. Then use the “Add X10 Device to EZX10RF†to define X10 codes. Be sure to allow enough time for each function to complete before pressing the Set button on the EZX10RF to proceed to the next step. The left corner of the Admin Console shows a flag (yellow/green) and a message when the ISY is busy processing the various steps. Lee

I've not traced a Delete but from the speed I would say that all active links are not deleted. Use the "Remove existing links" the next time it is added to the ISY. It is a good idea to Factory reset a device before adding it so that would take care of the links as well.

ergodic Sorry to hear of the problem with backup/restore. Appreciate the heads up. I've done hundreds of hours of testing on the SHN devices. Have many installed and working so I'm not worried about the exposure. I'd be more concerned about not running the latest 3.1.x beta than working with SHN devices. Good luck with the recovery. Lee