LeeG

The EZIO6I I1+, I2+, I3+, I4+ are connected to the +12v connection on the EZIO6I. The EZIO6I GND is connected to each of the 4 Dakota Alert Relay Common connections. The Normally Open (N/O) of each Dakota Alert relay goes to a separate Ix- connection. Whenever one of the Dakota Alert Relays turns On when an RF signal is received it will turn On the corresponding EZIO6I Input. The Relays do not stay energized for more than a few seconds so it is necessary to trigger an ISY Program when the EZIO6I Input node turns On. EDIT: The Dakota Alert User Guide can be downloaded from the Dakota Alert web site. The EZIO6I normally comes with a Quick-Start guide which can be downloaded from the Simplehomenet web site if missing.

Glad the information has been helpful. The latest beta is now 3.2.4. Best to go with the latest available at the time.

"will the timer program terminate as soon as 'Away ApplianceModule' is turned Off? " It will terminate when it hits a Wait or Repeat. "When the timer program is reevaluated, are the conditions of the parent folder evaluated as well?" Yes.

Clay is one of the worst soils to water. It absorbs water very slowly compared to other soil types. I am not familiar with the Irrigation module but do live where clay is prevalent. Often necessary to break watering cycles into multiple short cycles to avoid water just running off clay.

The Program is triggered at Sunset, at Sunrise (next day) and whenever the TriggerLinc Opened node Status changes. If the TriggerLinc Status is On at Sunset or Sunrise the Then Clause Runs. Using If Control rather than If Status will cause the Then clause to run only when an On command is received between Sunset and Sunrise (next day). EDIT: the Else should be moving into the Then of another Program that is conditioned with an If Control xxx is switched Off and same time range unless the Off logic should be gated on different conditions.

That is pushing the limit for a serial port connection. I would try it before physically moving the PLM. May just trade a powerline problem for a serial port problem. Is it not possible to filter other equipment or move the ISY as well. An Ethernet connection can be much longer than a serial port connection.

That is an older level of ISY before they put the 3- back. Does not make any difference. I did not see any FilterLinc listed. If there is other electronic equipment plugged into the same circuit as the PLM the signal from the PLM could be attenuated. The simple test is put the PLM on an extension cord and plug it into a circuit away from the electronic equipment.

If the mobile app is using the ISY to turn the Scene On (not the device) the same Insteon command is being used through the ISY PLM with the mobile app as the ISY Program. If different results are achieved it is time of day related or general powerline issue that works some times and fails others. The use of the same command can be confirmed by running Tools | Diagnostics | Event Viewer with Level 3-Device communications events selected. Issue the Scene On through the mobile app and Run Then one of the Programs.

It sounds like the Program is triggered with an If Control which is looking for a command to flow from the KeypadLinc. Change the trigger to an If Status which triggers when the button is pressed and triggers when the button is turned On/Off by another Controller.

Along the lines, if it ain't broke, CHANGE IT!

Ran a test on one of the TriggerLincs. It did not require the battery to be removed for it to switch from 1 scene to 2 scene mode and then back again as the jumper was removed and restored, This TriggerLinc is several months old so it may not operate the same as newer models. Simple matter to remove the battery to be sure.

muck4618 Check the jumper on the TriggerLinc printed circuit board. It sounds like the jumper is not there or installed such that it is not across both pins. When the jumper is in place the Opened node will cycle from Off to On to Off as the magnet is moved away and brought back to the TriggerLinc. When the TriggerLinc is working in 2 Scene mode (jumper removed) an On command is sent to the Opened node and then the Closed Node as the magnet position is moved. The TriggerLinc normally comes with the jumper installed, which causes it to operate in 1 Scene mode, where the Opened node cycles from Off to On to Off and so on.

I don't use Avast but it is blocking. There are a number of posts on the forum about Avast. Some of those may provide the necessary information.

Is Avast or Kaspersky being used?

I don't think the SwitchLinc Dimmer is an I2CS device. To be sure right click the SwitchLinc node in the My Lighting tree, select Diagnostics | Show Device Links Table. When the display has completed click the Compare button. Are the links as ISY expects? If the link table is correct the problem sounds like a communications problem to the SwitchLinc location. Insteon Direct On/Off commands have a different retry pattern than an ISY Scene command. The other possibility is the Scene Responder On Level for the SwitchLinc is set to 0% so a Scene On is really turning the device Off.

What type of switch and what ISY firmware?

Insteon Direct commands and ISY Scene commands have different retry characteristics. A Direct command can work in an unreliable location because of retries not available to the ISY Scene. I saw the post on the Smarthome forum that indicated the OutletLinc Relays did not work, the OutletLinc Dimmers do. The OutletLinc Relay is an I2CS device which requires 3.2.4. The OutletLinc Dimmer has not yet appeared as an I2CS device.

3.2.4 is required. The OutletLincs must be Deleted and added back under 3.2.4. Run Help | About and verify the Firmware line and UI line are both displayed and both indicate 3.2.4. If both lines are not there or not showing 3.2.4, clear the Java cache and use the URL for invoking the 3.2.4 Admin Console

Not sure if that is in the insteondetails.pdf document on insteon.net, maybe something at smartlabsinc.com The documents are very old. The link record format has not changed since 2005. The insteondetails.pdf does describe the link record relationship if not the actual record format. The basic format of 8 byte link record is Flag - 1 byte Group - 1 byte Insteon address - 3 bytes On Level - 1 byte Ramp Rate - 1 byte Group - 1 byte Flags E2 - active Controller record A2 - active Responder record 62- deleted Controller record 22 - deleted Responder record 02 – deleted record 00 - End Of List The Simplehomenet web site use to have a link record document but I was not able to locate it. Looks like they have dumped a bunch of old stuff. The above may get you started.

That link record in the SwitchLinc is a problem. Add the KeypadLinc ON/OFF button back to the Scene that has the SwitchLinc as either a Controller or Responder and delete it again. If the SwitchLinc record does not get deleted try a Restore Device for the SwitchLinc. Even if the KeypadLinc Controller link record was deleted for that SwitchLinc the SwitchLinc will continue to respond until the Responder link in the SwitchLinc is made inactive. The link record in the SwitchLinc Flag byte should go from A2 to 22 when the ISY deletes the link.

It may not be a link in the KeypadLinc that remains active. What do you mean by the KeypadLinc is still controlling the Scene? Other Controller/Responders are reacting to the KeypadLinc button press? Even when the link in the KeypadLinc is deleted the other device(s) could be reacting because they still have links in their database. If you identify the Insteon address, how many buttons the KeypadLinc has (6 or 8 ) and which KPL button is involved I can post what the links of interest will look like in the KeypadLinc and the other devices. That way you can determine if it is the KeypadLinc itself for other devices that actually have the active link. As a side note you should move to 3.1.17 which is the official 3.1.x release.

Illusion The 2D version of the KeypadLinc is apparently a problem child as Michel suggests replacing them but I do not know what the symptoms are associated with the 2D firmware. Run an event viewer trace and see if I2 commands or I1 Peek/Poke commands are being used to configure the KeypadLinc toggle mode. I have a 6 button v.36 that shuts Off the OFF button LEDs when the ON button is set to non-toggle (Off) mode. It is necessary to cycle the ON/OFF buttons once after changing the toggle mode to see the effect. My v.36 is being set with I2 commands. If I1 Peek/Poke commands are being used try the Query Insteon Engine.

The way any application knows the real time state of a Responder is to be notified when a Controller sends a message that affects the Responder and the application has been made aware of the Controller/Responder relationship. Insteon Responders do not notify another device (ISY PLM is this case) that they (the Responder) have been commanded. It is not part of the Insteon architecture. Devices should not be linked outside of the ISY. The ISY does not know about those links and will eventually overlay or delete the links done outside the ISY. The ISY will be aware of Responder states when all Controllers have been defined to the ISY and the links established with ISY Scenes.

Illusion Had a different post but see the Query Insteon Engine fixed the problem. It is new to one of the 3.2.x betas. With the advent of a third variant, I2CS, the Engine information the ISY is carrying for some devices may not be correct. The Query Insteon Engine may refresh with the correct information.

The ISY is not notified of actions by devices that have not been added to the ISY. For the ISY to be aware the Controller has to be added to the ISY so the links necessary for that awareness are created. How can you Query a device that is not known to the ISY?