LeeG

JCBond Right click on the EZIO8SA primary node and select Query. I believe you can set up all the 1-wire requirements with the SHN Utility and the EZIO8SA will signal Off to On and On to Off conditions based on the 1-wire trigger points. The ISY will not be aware Input 7 is not in digital mode. You will not have access to the actual temperature value. Lee

One solution is to use two programs. Program 1 contains the If and runs Program 2 Then. That way when the If condition changes the reevaluation that occurs does not abort Program 2.

Rand, Thanks for the update. I'm still not sure about vandede situation. He did a Remove/Delete Modem. Does the ISY still have all the link information about the deleted PLM such that a Restore Modem will restore the configuration despite the Remove/Delete Modem being performed (assuming the ISY was not reset)? Lee

gfridland There is conflicting guidance regarding the recovery path after doing a Remove/Delete Modem. John indicates a Backup Restore is required and devices must be Restored. Rand indicates a Backup Restore is not required and a Restore Modem (PLM) will restore normal operation. Hoping from some clarification soon. http://forum.universal-devices.com/viewtopic.php?t=5415 http://forum.universal-devices.com/view ... =3401#3401 Lee

Rand, I am not trying to get in between you and John Chris but what you just posted and what John posted (follow the link I posted to John's post) are at complete odds with each other. Excert from full post by John Chris .... Remove PLM Use this with care because the only way to get this back is to restore a backup, and then do restore devices. This removes all links to the PLM from all of your devices. Lee

Doing a Remove PLM removes all references to the PLM from all the devices. I think you need to restore an ISY Backup that reflects the ISY configuration before the PLM was removed and then Restore each device. See the following link ..... http://forum.universal-devices.com/view ... =3401#3401

The [ignored] entry is the end of active link list marker which is in the device link database but the ISY does not keep in the ISY database so it will show ignored. That is normal. The relay node will not change state from On to Off when the I/O Linc turns the relay off automatically in one of the Momentary modes. The I/O Linc does not notify any device about the automatic relay Off associated with Momentary mode so the Admin Console relay node stays at On unless a Query or the Off Admin Console button is clicked or a Scene Off is initiated where the I/O Linc relay is a responder. In the example I assume the door does Open but the Admin Console does not reflect a state change for the Sensor node. The fact that the Admin Console Sensor node changes to Off when the door closed tells me the On/Off commands from a Sensor state change are the reverse of what you want. The Senor node shows On in the Admin Console, the door opens and the Sensor in the I/O Linc changes to Off state and sends an On command. Not the command you want issued when the IO Linc Sensor turns Off but I think a command is sent to the ISY. When the door closes and the Sensor state at the I/O Linc turns On it now sends an Off command which is expected since it sent an On command when the door opened and the state change sent an On command. When you said the Sensor is On when the door is closed, is that the Green LED on the I/O LInc is On when the door is closed? If so it sounds like the Trigger Reverse option is in effect causing the I/O Linc to send an On command when the I/O Linc Sensor turns Off (Green LED Off). Turn the Trigger Reverse option Off and try cycling the door. It may be necessary to cycle the door twice before the I/O Linc Sensor and the Admin Console Sensor node are in sync. Ignore the relay status not changing, that is normal. The I/O Linc does not send a notification when it automatically turns the relay Off because of Momentary mode. I think once you get the appropriate On/Off command sequence you want things will be working as far as the I/O Linc and Admin Console are concerned. There may be program issues we have not looked at yet by design as I did not want any more variables involved than absolutely necessary.

If the KeypadLinc button is the load control button an Insteon Direct command can be issued to the primary KPL node. http://192.168.2.2/rest/nodes/15 9A F9 1/cmd/DON/255 http://192.168.2.2/rest/nodes/15 9A F9 1/cmd/DOF If the KeypadLinc button is a Secondary button the button has to be controlled as a responder to an ISY Scene http://192.168.2.2/rest/nodes/scenes will display a list of ISY Scenes. An example of a Scene follows …. 34024 SceneKPLBC 32 F12 - 14 71 3C 3 The 34024 tag value is needed in the rest command. http://192.168.2.2/rest/nodes/34024/cmd/DON http://192.168.2.2/rest/nodes/34024/cmd/DOF

killervette Define an ISY Scene with the ToggleLinc as the Controller and the specific KeypadLinc Button B (?) as the Responder if all you want is KPL button B to show the ToggleLinc status. If you want to Control the ToggleLinc from KPL button B as well define the KPL button B as a Controller of the same Scene. You will have two Controllers of the Scene with no explicit Responders defined. The ISY assumes a Controller is a Responder if the device has responder capability. Once the Scene has been defined and written into both devices either will control the lights and both will reflect On/Off status (assuming both are defined as Controllers). Lee

With several folks having successfully installed that image, including myself, sounds like something happened during download. I seem to remember a past post where a firewall was preventing a good download. Maybe download new copy and try again. Good idea to take a backup before trying though.

Michel Many thanks for taking the time to detail the thinking behind the ISY approach to running Scenes. That was helpful. I have some experience queuing PLM requests, having to wait for the Group report message before issuing the next PLM command. It is a pain to say the least! However, I think the designers had a reason for using follow up Group Cleanup messages so I think we just agree to disagree on this one. I still think ISY is the best Insteon product on the market and the support provided is a major reason for its success! My deleted post was way over the top even for me. Thanks again Michel. Lee

Sure looks like the I/O Linc link records are not what the ISY thinks they should be. When I run a Compare on my I/O Linc it shows [identical] along side of each displayed link record. I would do a Restore Device (right click on Sensor node) and run the Show Device Links Table and Compare again to verify. The objective is to see consistent and correct status updates of the I/O Linc Sensor node status on the Admin Console. I don’t care about the Admin Console display itself but without that being correct ISY Programs do not have accurate information about the I/O Linc status. Once that is achieved then attack whatever symptom is left if any.

gfridland That is good news on the one hand as it explains the ACKs. May be unrelated to your original problem since all the expected devices reported succeeded. The ISY defines link records when any device is added to the ISY, independent of adding the device to a Scene. The link records are used to keep track of device status changes. I did not think a Restore Modem (PLM) actually rewrites individual device link databases unless the PLM address changed. I could be wrong about that. It is only "I think" rather than "I know". I don't know of any ISY function that will delete individual link records. MIght exist. Anyone who knows how please jump in. Lee

Michel, Thanks for the effort and answers. I was thinking in terms of the fact that the PLC has a "linked list" type link database rather than the "linear" link database in all the other Insteon devices. Did not know if the ISY had code to handle that unique type of link database. Was not thinking about the way the ISY looks at the world regarding defining large number of nodes. As far as a responder a single node works fine. Just like a SwitchLinc can be a responder to many different Scenes the PLC could be a responder to many different Scenes. I think the PLC is a non starter unless the ISY really does have support for a "linked list" style link database. Might be time to remove the 2414 from the Device Type list. I then got the idea of using a PLM. That would require tpolito to switch from PLC to PLM which might be a problem. Actually added a Dual Band PLM to the ISY successfully. Then made it a responder to a KeypadLinc button as controller. That physically worked but the link record in the PLM is not functional because of the different memory size. The ISY would have to adopt the same logic for determining PLM memory size now being used for SHN devices. Again likely a non starter as that only resolves the responder side and not the issue of what to do with potentially 254 controller nodes (one for each Group number possible). In addition that would expand the number of link records used in the ISY PLM significantly for each user PLM installed. tpolito I think the idea of defining your PLC or even a PLM (assuming you could switch from a PLC to a PLM) to ISY is not an option. If you can receive network messages Michel's suggestion of using the Network module to send messages to your environment and use REST to control the Insteon devices and ISY Scenes seems the only option at this point. Sure did sound like an interesting possibility in the beginning. Perhaps the ISY will support a PLM in the future but I doubt there is much call for that support compared to other requirements on the wish list. I had hoped to use a PLM when I first got my ISY as I have them in use with other software but I can see the difficulty using predefined nodes. EDIT: just saw your last post. The ISY should still be on the powerline even if only used for link management. Every Scene that the ISY creates has a link back to the ISY PLM so that it is aware of device state changes. Removing the ISY PLM would cause unwanted Insteon message retry as the Insteon devices were manually turned On/Off. Lee

gfridland That is the device address that sent both ACKs. I see the problem as that address is not in the succeeded list suggesting that device address is not one of the responders ISY is expecting to answer for that Scene. That is odd as the PLM would not send a Group Cleanup Direct message to a device address for which no controller link record existed in the PLM. I would do a Tools | Diagnostic | Show PLM Links table looking for a link record with that Insteon address. Perhaps something left over from a device that has been Removed in the past. It may take multiple attempts to get the full PLM link database displayed as active Insteon traffic can cause the PLM link display to repeat or skip entries. Has that PLM been used by any other software/firmware in the past or present? Lee

That is correct. You would need an ISY Program that reacts to an X10 message from your other environment and controls the appropriate Insteon devices. The other possibility is the REST interface. That can be used to tell the ISY to turn On/Off Insteon devices or ISY managed Scenes.

gfridland That is a duplicate ACK message from the device to the Scene Group Cleanup Direct message. The PLM will send another Group Cleanup Direct to a device as part of the Scene retry protocol if the device failed to send an ACK or the PLM failed to receive the ACK. Not sure why two ACKs from the device. Is this the device you are having trouble with that prompted the Scene test to begin with? Lee

Michel Does the ISY support adding a PLC as any other Insteon device? Both 2414 variants are listed in the New INSTEON Device, Device Type pulldown. If the PLC is supported as any other powerline connected Insteon device it could be added to ISY created Scenes as a Responder for those paddle/button presses the other software needs to be aware of. The PLC would receive the Group On/Off messages from those Insteon device interactions, needed by the other environment as it does today, but NO Insteon device or Scene management would be performed by the other environment. All Insteon device and Scene management would be done by the ISY. This is all dependent on whether the PLC is supported as any other Insteon device communicated with over the powerline. I tried a test when the post showed up on the other forum but my last PLC is so dead its LED would not stop flashing just by plugging in the device. I had no way to test adding the PLC using New INSTEON Device. tpolito If the PLC is supported by the ISY as just another powerline connected Insteon device then the ISY would do ALL Insteon device and Scene management. The PLC would be just another Responder in some ISY created Scenes. This would give your other environment the awareness of a paddle/button press and you would continue to interface to your other non Insteon devices the same way you do today. You would have all the power and features the ISY provides for Insteon device support with the other environment responsible for everything else. Just depends on Michel’s answer regarding the ability to add a PLC as any other Insteon device. I believe the Network Module is one way communication so that would not be an alternative. Lee

Douyon Divide and conquer. Define a Scene with the I/O Linc Sensor as a Controller and the KeypadLinc button you want to represent garage door open/close status as a Responder. Open and close the garage door using the existing door control button. Some folks want the KeypadLinc button On when the garage door is closed, some want the KeypadLinc button Off when the garage door is closed. Use the black/green or black/red wires on the magnetic switch, whichever one gives you the desired KeypadLinc button On/Off condition for a garage door closed condition. If you are using Trigger Reverse I suggest turning that option off and use the black/green or black/red wire to give the desired KeypadLinc button LED condition for garage closed. The Query command output from the I/O Linc Sensor is not affected by the Trigger Reverse option. That is documented in another topic. Just means the Admin Console status value when Querying the I/O Linc Sensor can be different than the reported On/Off state using Trigger Reverse. With a magnetic sensor that has both NO and NC contacts build into the one magnetic switch it is easy to achieve the desired On/Off Sensor state without have to use Trigger Reverse. When the above is achieved and the KeypadLinc button LED reliably reflects the door open/close status, move to the KeypadLinc button that will control door open/close operation. Is one keypadLinc button to be used in Toggle mode such that each KPL button press alternates between On and Off commands. Are two KPL buttons planned for door Open/Close operations. One dedicated to Open and one dedicated to Close. In this case one KPL button would be set to non-toggle On mode so that only On commands are issued and the other KPL button would be set to non-toggle Off mode so that only Off commands are issued. Likely Momentary C mode will be used in either case. Using one KPL button in Toggle mode or two KPL buttons is simply a matter of personal choice. Define another Scene that uses the door control KPL button as Controller and the I/O Linc Relay as a Responder. If two KPL buttons are planned for door control two Scenes will be needed. I am assuming Momentary C mode as you indicated On command should only open the door and Off command should only close the door. Momentary C is the only mode that provides specific command reaction/no reaction based on Sensor (door) statis. If the On and Off commands are working opposite to what you want change the responder I/O Linc Relay On level from 0% to 100% to reverse the On/Off command reaction. Lee

I will have to think about my response to that 2009 post. What I just wrote and deleted would not be appreciated by some.

Does the Sensor node status change some of the time or not at all? If some of the time then communication between the I/O Linc and PLM location is in question. If the Sensor node never changes status then link records, either in the I/O Linc or PLM are suspect. A Show Device Links Table request for the I/O Linc should show a Controller link record (E2) for Group 1 pointing to the ISY PLM address. The PLM must have a Responder link record (A2) with the I/O Linc address and Group 1. Program execution will never be reliable until the Admin Console is showing consistent status updates. I am assuming the Admin Console is showing accurate status changes for other devices. Not clearing the Java cache after an image update can also prevent status updates from appearing in the Admin Console. The Sensor messages can be viewed using the Event Viewer at Change level 3 – Device Communications Events if there is concern the Admin Display node status may not be updating correctly.

When temp > 50 and pump Off turn pump On

TJF1960 I would have to trace a Scene command sequence where the ISY is the Controller but I would doubt the Group Broadcast is the only message sent. Scenes could/would be very unreliable if only the Group Broadcast message was sent. Positive command acknowledgment and command retry is a hallmark of Insteon protocol and a major reason Insteon enjoys the reliability it has. All Insteon devices being a repeater and the mess RF/powerline network is also a major factor. There is a specific PLM serial command that initiates a Group/Scene. The PLM does all the heavy lifting to send the Group Broadcast message and follow up Group Cleanup Direct messages to each responder, including retrying any Group Cleanup Direct that is not ACKed. The PLM sends back a message to the application (ISY) if any responder fails to ACK the Group Cleanup Direct after all retries have been attempted. It would not be normal protocol for an application to reissue the PLM serial command to initiate the Scene again for an individual responder failure. The responder has already failed multiple attempts by the PLM to initiate the Scene command. No reason to think the next set of retries would be any more successful. All Insteon devices when functioning as a controller issue both Group Broadcast and Group Cleanup Direct messages. There are some exceptions for Dim and Bright Group command sequences. These are very time dependent sequences. It would be impossible to issue a Start Manual Change followed by a Stop Manual Change to every responder in sequence when a paddle/button is pressed and held. For normal On/Fast On/Off/Fast Off Group commands Insteon controllers always send both Group message types. Lee

TJF1960 Only the initial Group Broadcast message issued for a Scene is not ACKed by any individual Responder because it is not sent to any specific responder device. Following the Group Broadcast message the controller sends Group Cleanup Direct messages to every Scene responder in sequence and this message must be ACKed or it is retried. A Scene responder failure is known. Lee

douyon The missing piece in my first post was how to get Momentary A mode to react to an On command only. In my first post Momentary A mode responded to Off commands only. When I defined the Scene with the I/O Linc Relay as a responder the Scene was defined with the Relay On level as 0%. Moving the slider to 100% On for the Relay reverses the command the I/O Linc relay responds to in Momentary A mode. Momentary A mode 0% On Level - Off command only 100% On Level - On command only Also changing the Relay On level to 100% reverses how Momentary C mode responds Momentary C mode with 0% On level Sensor Off - On command energizes relay Sensor On - Off command energizes relay Momentary C mode with 100% On level Sensor Off - Off command energizes relay Sensor On - On command energizes relay With the various combinations of Sensor On/Off and Relay Responder ON Level 0%/100% the I/O Linc Relay will respond with whatever On command/Off command result you want. If you set up a test Scene with a KeypadLinc button as a Controller of the Scene and the I/O Linc Relay as a Responder, keep in mind that there is a Relay On level for the KeypadLinc button as Controller and a separate Relay On level for the ISY as Controller. Setting the I/O Linc Relay to Momentary C mode and the appropriate Relay Responder On level to 0% or 100% you can achieve whatever KeypadLinc button press (On versus Off command) reaction of the I/O Linc Relay you want. Lee