PurdueGuy

Is the output connected to something? Otherwise, why use a relay instead of a dimmer? The relay will click on and off, the dimmer will be silent.

A program with a trigger of "If Status is On" will only trigger once when the device first turns on. It will not be "triggered continuously while it's on." It will be re-triggered to run the next time the device turns on by any means (direct, scene, local). ​OutletLinc dimmers are controllers, but I believe OutletLinc relays are not.

I only have a few that run at startup, probably the same that many due: Reboot notification: If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Send Notification to 'All' content 'Startup' Else - No Actions - (To add one, press 'Action') DSCLink heartbeat ($Alarm_Heartbeat is init'ed to 2): If $Alarm_Heartbeat is not 0 Then Repeat Every 0 seconds Wait 10 minutes Send Notification to 'All' content 'Alarm Heartbeat' Else - No Actions - (To add one, press 'Action') DSCLink status: If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Resource 'Alarm - Get Status' Else - No Actions - (To add one, press 'Action') Leak sensor startup program: see here: http://forum.universal-devices.com/topic/11566-leak-sensors-a-suggested-complete-program-package/

Any time anything in the IF changes, it is re-evaluated. At Sunset+10, if everything is off, Light3 turns on. Since Light3 is now on, the IF is re-evaluated, and since Light3 is on, it runs the else. Since the other lights are off, Light3 is turn off. The reevaluates the IF again, this time it's true. The way you have it now, adjusting any lights (1, 2, or 4) between sunset and 10 will also cause problems. A couple options: A) Remove the test of "Light3" from the IF. Since you are going to turn it on anyway, it doesn't matter if it's already on, does it? You could break it into 2 programs. One for Sunset+10, and another for 10:05 PM. Also, I would remove the "Light3" from the IF test (same reason as above). If you want to test for Light3 still, add a small wait at the beginning just so that light doesn't turn on until after the same moment in time as sunset, otherwise you might get stuck in a loop for a second with the light flashing on and off.

Assuming you already have the wiring in place for up to 8 zones, you would just need an EZFlora and transformer. Then you can use ISY logic to turn on zones as needed. You don't need any other "controller" - the EZFlora is the controller. The page here shows the wiring: http://www.smarthome.com/31270/Smartenit-INSTEON-EZFlora-8-Zone-Sprinkler-Controller/p.aspx

How do you know when power is restored? When the relay turns on? What turns the relay on? As I mentioned, the relay being turned on and ISY noticing isn't controlled by the delay in the duration settings of the IOLinc. If you want a delay, use an ISY program with a delay.

Actually, looking back over things, I don't see why you have any delay, nor do I quite understand what you are trying to accomplish. As soon as the relay turns on, ISY should notice, and turn on 'CR102 Lamp Dimmer'. It won't be immediate, but it shouldn't be long, and as far as I know, has nothing to do with the duration of the momentary relay.

Since the IOLinc turns itself off, it doesn't notify ISY that is has done so. I created a program such that whenever the IOLinc turns on, wait 2 seconds, and turn it off (even though it's already off).

I am sure there are other ways, but I go to http://ISP.IP/rest/nodes/<NODE> to figure them out. For example, my Front Door lock is node ZW006_1, so the address http://192.168.1.53/rest/nodes/ZW006_1 returns <nodeInfo> <node flag="128"> <address>ZW006_1</address> <name>Front Door</name> <family>4</family> <parent type="3">39649</parent> <type>4.64.3.0</type> <enabled>true</enabled> <deviceClass>0</deviceClass> <wattage>0</wattage> <dcPeriod>0</dcPeriod> <pnode>ZW002_1</pnode> <sgid>1</sgid> <devtype> <gen>4.64.3</gen> <mfg>144.1.1</mfg> <cat>111</cat> <model>4</model> </devtype> <ELK_ID>L01</ELK_ID> <property id="ST" value="100" formatted="Locked" uom="11"/> </node> <properties> <property id="ALARM" value=" " formatted=" " uom="15"/> <property id="BATLVL" value="70" formatted="70%" uom="51"/> <property id="ST" value="100" formatted="Locked" uom="11"/> <property id="USRNUM" value=" " formatted=" " uom="70"/> </properties> </nodeInfo>

If I were selling today, I'd probably take out the switches and plugs, and hire an electrician to put in new ones (faster than I could). I kept my RainBird lawn timer when I put in the EZFlora. If/When I go to sell in some time, I'll re-evaluate. If more is known by more people at the time, I'd be more inclined to leave them. I would leave the DSC alarm in place, but probably take the Envisalink module with me.

As long as they are not battery-operated devices, you should be able to link them the address only. That's how I do most of my linking. http://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Link_Management_Menu#New_INSTEON_Device It is recommended that you do "Remove existing links" - that way ISY is the only controller. You could choose "Add devices found in links and remove existing links" to ISY goes from device to device finding new ones, and deletes links. Don't use "Add Devices Found in Links and keep existing links" unless you want all sorts of randomly defines scenes with no clue what goes to what. When I moved from another controller to ISY, I started from scratch. Was way easier than trying to sort things out after I used the last option.

That should work. Just annoying changing it twice a year, for each fan! Be sure to test when you re-install the FanLinc before you close everything up!

The station I use is a personal station nearby. ISY shows: Condition: Rain Cloud Condition: Partly Cloudy Rain today: 0 inches Condition Tomorrow: Drizzle Rain Tomorrow: 0 inches Being in SoCal, I could only wish we were getting rain! How is the condition calculated? Do I just happen to have the lucky variables that the outcome shows as rain? If I switch to "KLGB" I no longer get "Condition" so I can't see what it would be. Switching back to the original station, and now I don't get the "Condition" or "Condition Tomorrow" fields. Now I'm confused.

I would take the FanLinc out for now. Just use the microswitch to get the fan direction reversed, then remove the switch and put the FanLinc back in. Edit: Fixed the mixed up devices at the end.

That might work. You might need to control it from another scene controller to be fast (not button clicks in the admin console), or maybe a program in ISY.

Unfortunately not that simple. It is all fan dependent. Mine has to has quick successive power cycles to reverse. You won't be able to do this with the FanLinc installed, since it probably can't react fast enough. You can try though. If no luck, you would need the fan hardwired to a switch (or breaker) and do it manually. Hopefully you have a switch that you can use for a bit? Depending on your wiring, maybe you bypassed a switch at a junction box? if you go with the breaker, are other devices on the same circuit? Many devices won't like the power being applied and taken away like that.

I had essentially the same setup. I had no idea what the communication to the relay was, but when I first installed my Leviton Z-Wave Fan control, the fan was spinning the wrong direction. I was able to quickly turn the fan off and back on with the air gap, and power. It doesn't appear to be any special communication other than power cycling. Any way you can do what's described here? https://www.askmehelpdesk.com/electrical-lighting/ceiling-fan-remote-control-1770.html That's essentially what I did and I got it spinning in "summer" direction. I'm debating if I want install some sort of mechanism to easily reverse mine in winter. I just didn't use them last winter.

I have Kwikset 910s. You need both lines for the programs to work correctly. UDI gave the examples when the beta came out. I'm guessing the user code is transmitted separately before the "unlocked" so you need both to be able to figure out which user it was. And if you have just the user code, any action from the lock causes the if to be re-evaluated, so even a "locked" would trigger it. Having the "Control ... is switched Unlocked by Keypad" makes it only occur on an unlock.

Mine work. I have 2 programs per lock, since i have 2 codes per lock. User 1: If Status 'Devices / Entry / Front Door' is Access Code 1 And Control 'Devices / Entry / Front Door' is switched Unlocked by Keypad Then Resource 'Prowl - Front Deadbolt Code 1' Else - No Actions - (To add one, press 'Action') Other user: If Status 'Devices / Entry / Front Door' is not Access Code 1 And Control 'Devices / Entry / Front Door' is switched Unlocked by Keypad Then Resource 'Prowl - Front Deadbolt Code Not 1' Else - No Actions - (To add one, press 'Action')

RemoteLincs won't have their status updated. They are battery operated devices, and not listening for messages, so ISY knows they don't update.

Ah, another 310 guy here? Or at least, you were! Just a quick tip...if you use 310#######@mms.att.net you might like the format better.

Sorry, I meant newer camera firmware. The newer camera firmware requires encrypted passwords.

Are you using new firmware? It might require encrypted passwords, that ISY doesn't have.

You need to copy the new scene settings to each controller. In the ISY Admin Console, you will need to expand the scene, click the controller you want to adjust settings for (it will be red). Then click "Copy Scene Attributes from " In general, this allows you to define a scene once, and have different setting for each device when controlled from different controllers. The name scene name is when ISY is the control (Admin console, dashboard, programs).

As far as I have seen, ISY doesn't keep track of timestamps for the current state of devices. It has timestamps for programs and variables, since you can write conditions for them, but not device/node status.