Illusion

Besides Humidity, the 7 day is compatible with multi-stage systems. Even if you do not have a multi-stage system, this may be a consideration for future-proofing. 2 days after installing my 2 t-stats I had my annual AC check-up. My AC guy tells me it is time for a new system, and that this will be the last summer with this unit. Now I am looking into multi-stage systems and of course I bought the 1 day which is not multi-stage compatible. Tome, as far as multi-stage heat pumps... I am installing a multistage heat pump and I intend to use these t-stats. I have done extensive bench testing and I believe I will be able to make them work for me. The t-stat does energize W2 instead of Y2 on a second stage heat call, but by wiring W2 to Y2 at the unit, this should work fine, as the reversing valve, and fan are already being properly called for as stage 1 is running at this point. Further, in my application I also have the advantage of using a very well designed Honeywell HZ432 zone controller. This device, even if I were to connect W2 to W2 instead of Y2, converts it to a second stage compressor call before sending the signal to the unit. But I do believe that by just connecting W2 to Y2 at the unit (or jumpering it in the back of the t-stat) would accomplish the goals on a single zone system. Then you set up W3 as your aux heat call. This does leave you with the problem of no way to call for emergency heat with these t-stats though. Of course, my zone panel fixes that issue as well. EDIT: Okay Tome, one more issue. I guess you are correct that they will not work. I just realized that my method is not fool proof. If you were to force the t-stat into emergency heat, it would ask for W2 alone, which would be like asking for a second stage compressor call. Not a good idea. In my case the zone control panel also fixes this issue. It really is a brilliant piece of engineering... that Honeywell HZ432.

No easy answer here. When something like this happens, use the "Last Run" time field in the program status tab. Sort by last run time and look for every program that just ran. If you cannot catch it, also use the log. Look at every event that happened around the time of the "error" I do not have a foolproof troubleshooting method here. It can be tedious and time consuming. If all else fails, pull the motion detector down, start disabling whole groups of programs, and manually triggering the MD. See which one or combination of programs cause the problem.

Personally, I would not touch CFLs for outdoor security lighting. They take way to long to come up to full brightness on a cold night. They are just too temperature sensitive of a device for me to use in an outdoor setting unless they are going to be on for long periods of time and can achieve temperature stability. Your goal of dim always and bright on motion I fear excludes CFLs. A halogen floodlight on dim setting provides a very nice warm pleasing glow that is ready to come to full in an instant. Life span is extreme when run in dim mode. I have two floodlight that are on all hours of darkness in a dim mode. They have been running that way for 16 years without need of maintenance. Some applications call for incandescent lighting. I think this is one of them. Avoid the hassle of CFLs in this application. The cons [high cost, disappointing lifespan, line noise, dim when cold, special programming to get a hot start and then dim, non linear dimming, variances between bulbs] just way outweigh the pros. IMHO.

I will try to give a short answer here. I have over 150 interrelated temperature control programs so it will be difficult. Some of this is not yet implemented... I am in the process as we speak. 1. I use large setbacks 2. I have the deadband before aux heat as an additional 2 degrees 3. I have the time before aux heat as 1 hour. (if I need it to heat up quick and expensive I can always manually engage emergency heat) 4. I have it setback at night and the hours before I wake up it warms the room up for me 5. I have I/O link modules used as "outdoor thermostats" whereas the t-stat's call for aux heat is interrupted if the outdoor temp is above a certain value related to the unit's COP and BTU rating at various outdoor temps. Somewhere in the 30s or 20s is a good start. The ISY will be using Weather Bug data for these descisions. I may be putting in multiple I/O links activated at different temps connected to different heat strips. IE if it is below 33, allow 5KW aux heat if called for, if below 23 allow 10kW aux heat if aux is called for. Emergency heat will bypass these I/O links. 6. see also: http://forum.universal-devices.com/view ... 2258#22258 Note: With heat pumps that use electric heat strips for aux heat, this is your biggest enemy. Actions that cause the heat pump to run much much longer, but without engaging these heat strips is always desirable compared any run time with the heat strips on.

See: http://forum.universal-devices.com/view ... 1184#21184

I am going to go with no on this one. I think in the end, if you want to only send the individual commands if the devices are not already in the state in question, one way or the other you are going to end up with a program for each one.

That is how I had assumed you wanted it. Yes, as the program is now written I believe it will do exactly what you want.

Whoa Michel! If KP A is status On because it had been turned on prior to 9pm, at 9pm the program becomes true and so should execute. If KP A is status off and time is between 9p and 7a and KP A is pressed, then status is changed to On and program should execute. I think this is written correctly for what intellihome wanted to achieve.

Both The ISY is event based. The evaluations of programs are event based. When 9pm comes the "If" will get evaluated, if KP A is already on then the "If" is true and the "Then" will execute. Alternately, if you press the KP A then you have changed the status of the KP A switch and so the ISY will again evaluate the "If" in this program. If it is between 9p and 7a then the "Then" will execute. If it is not between 9p and 7a then the "If" statement is still false and the system will have to wait till 9p for it to become true for execution to take place. Not the use of "And" between the conditions. When building programs you can change that to "Or" and dramatically alter the function of the program because either condition being met then would result in the "If" becoming true. Program looks great to me. Looks like it should do exactly what you requested in your first post.

First change Control to Status If Control 'Mud Room KP A' is switched On Should be: If Status 'Mud Room KP A' is On Second click on schedule, select 9pm, select from, pick your to time like 7am, click add to if.

Nice to hear from you, Chris. Thanks for the quick response. Well that answers question 3 and 4 pretty completely. Of course when you explain it, it is obvious that the program would run twice. My brain just does not work that way. I keep forgetting just how event based the ISY is. I will be breaking that into two programs immediately. It is funny, because I have dozens of programs that I have engineered to take advantage of exactly this behavior, I just did not see it here for some reason.

Questions: 1. It looks like there were two temperatures set for the living room t-stat in the system log, one of which was 127.5. This is what I believe caused the erroneous notifications. Has anyone else had this issue with reported status? 2. Why did the system have 2 temperatures for the livingroom t-stat? 3. Why did I get 2 emails? One for the living room that the system thought was out of bounds and one for the bedroom which the system knew was still in bounds? 4. Why is the time inside the notifications before the time of the query? I got the notifications after the erroneous query was performed. Why do the notifications have time stamps before they could have been generated?

and on... More relevant log entries: Bedroom T-Stat Status Query° Sat 11/07/2009 05:01:01 PM Program Log Bedroom T-Stat Status Query° Sat 11/07/2009 05:01:01 PM Program Log Bedroom T-Stat Status 75° Sat 11/07/2009 05:01:01 PM System Log Bedroom T-Stat Humidity 75% Sat 11/07/2009 05:01:03 PM System Log And here are the notifications I received: Temperature Alert! 'Bedroom T-Stat (xx xx xx 1)' Status set to 75.00° at 11/7/2009 16:59:33. Temperature Alert! 'Living Room T-Stat (xx xx xx 1)' Status set to 127.50° at 11/7/2009 16:59:33.

Sorry. I am having to post this as multiple posts for some reason. I cannot get all the info into one post, the system just will not take it, plus I had to turn HTML off for that first post cause I guess the greater than and less than symbols mean something in HTML and were messing up the text. Anyway, continuing on.... Relevant Log Entries: Living Room T-Stat Status Query° Sat 11/07/2009 05:00:56 PM Program Log Living Room T-Stat Status Query° Sat 11/07/2009 05:00:56 PM Program Log Living Room T-Stat Status 76° Sat 11/07/2009 05:00:56 PM System Log Living Room T-Stat Status 127.5° Sat 11/07/2009 05:00:57 PM System Log Living Room T-Stat Humidity 74% Sat 11/07/2009 05:00:58 PM System Log

I have a program that alerts me if my house goes outside preset temperature ranges. I have another program that queries the t-stats about every 3 hours. Immediately after one of those automated queries yesterday at about 5p I received multiple notifications of temperature outside the range, but nothing was wrong at the house. Any thoughts as to what happened here? Temperature Alert! If Status 'Bedroom T-Stat' > 88° (Temperature) Or Status 'Bedroom T-Stat' < 56° (Temperature) Or Status 'Living Room T-Stat' > 87° (Temperature) Or Status 'Living Room T-Stat' < 56° (Temperature) Then Send Notification to All Else - No Actions - (To add one, press 'Action')

I re-wrote the programs so the test switch is first in the program and it happened again last night and the results were the same. I went to the log and found this relevant entry: XX- Test Switch V.27 On 255 Mon 10/26/2009 08:20:44 PM Program Log Front Porch KPL On 255 Mon 10/26/2009 08:20:44 PM Program Log XX- Test Switch V.27 Status 100% Mon 10/26/2009 08:20:44 PM System Log The detector sees motion, runs the initial program, but the ISY does not realize that it succedded in turning on the front porch, so when it runs Front Porch Motion Off Not Enabled it stops the program because it runs the Else Clause erroneously. Notice that there is no System Log for the KPL status! The ISY still thinks the KPL is off even though it is really on. This prevents the test switch from getting turned off because the ISY thinks the KPL is already off! So I have answered the question of how this is even possible, but now I have another question: If the ISY sends a direct command to a device like "turn on" is there a communication failure that would allow the device to turn on but have the ISY think the device is still off?

Make sure that the "ON" only jumper in the battery compartment is not set. Make sure the Motion Detector does not see any motion at all for the full amount of time that the timeout period is set for.

Are the lights directly linked to the I/O or are you waiting for a program to execute? If you are using a program, how about just putting the I/O linc sensor in a scene as a controller and the lights as a responder? If you are willing to have all the cabinet lights come on at the same time you could save a bunch of money and just use the I/O linc you just bought. Just wire all the magnetic contacts in parallel to the sense terminals. If any door opens the I/O linc will know about it.

You can also do some elegant program saving steps with something as simple as a control switch like: If Control 'Bedroom ControLinc.1' is switched On And Control 'Bedroom ControLinc.1' is not switched Off Then Send X10 'E1/On (3)' Else Send X10 'E1/Off (11)' As a new user it took a while for me to get used the the fact that the ISY is event based. This is why it does not keep sending commands. It runs the then when the conditions become true and the else when the conditions become false. This is important to remember when building new programs because this efficiency does have some unexpected consequences for the uninitiated. For example, in your program, if you were to turn off the J9 manually when it was on because the program had turned it on, the light would stay off till the next event changed the condition of this program. IE: J9 would not get turned on by the ISY until the next night, when the conditions once again became true.

Rand, Thanks for taking the time to wade through those interrelated programs. I thought the same thing about the program becoming false, but the program is Not Enabled. As I understand the ISY, and as I have these programs set up, that action changing a condition of the program should not be a factor here. The "IF" is only evaluated when specifically called on from Motion-Front Proch. A change to any condition after this evaluation should not have any effect. Or so I thought. Am I wrong on this point? Have I been misunderstanding the way the ISY functions? If so, I have a whole bunch of programs that are Not Enabled where the conditions are changed by the actions that I will have to revisit.

Lets assume a comm failure. The SWL and KPL are on the same circuit. At this point, I am only trying to understand one thing: Why does the ISY think that the test switch is on, and in fact it is on, after this program sequence has run? But it thinks the KPL is Off. If there is a comm failure to a device in a program, does the program stop running? That is the only explanation I can currently come up with. In fact, I am going to reverse the position of the devices in the program so the ISY talks to the test switch first.

Motion sensor is only linked to the PLM. ISY controls all actions.

Successful Low Battery notification. #2420 Rev 1.0B Duracell Alkaline Battery at 7.9V

I have a KPL v.2D that I have been having intermittent problems with for some time. I have my front porch light as the load for this 6 button KPL, which is triggered by the ISY in response to motion. Sometimes the light will be on when I know it should have turned off. I created a program to query the state of the switch for conformation, but that did not help. I would notice the light on when it should be off, open the Admin Console and see that the ISY was complaining of 'Failure to Communicate' with this device and the status of the device would show as off. I added a SwitchLinc v.27 to the circuit and the programs to test whether I have a comm issue, or a defective switch, but the results of this test confuse me even more. Motion-Front Porch Enabled If Control 'Front Porch-Sensor' is switched On And Program 'Dark Outside' is True Then Run Program 'Front Porch Motion On' (If) Wait 5 minutes Run Program 'Front Porch Motion Off' (If) Repeat Every 0 seconds Wait 10 seconds Set 'Front Porch KPL' Query Wait 5 seconds Run Program 'Front Porch Motion Off' (If) Wait 5 seconds Wait 15 seconds (Random) Else Repeat Every 0 seconds Run Program 'Front Porch Motion Off' (If) Wait 10 seconds Set 'Front Porch KPL' Query Wait 5 seconds Wait 15 seconds (Random) Front Porch Motion On Not Enabled If Status 'Front Porch KPL' is not On Then Set 'Front Porch KPL' On Set 'XX- Test Switch V.27' On Else - No Actions - (To add one, press 'Action') Front Porch Motion Off Not Enabled If Status 'Front Porch KPL' is On Then Set 'Front Porch KPL' Off Set 'XX- Test Switch V.27' Off Else Stop program 'Motion-Front Porch' I had the failure the other night. I open the Admin Console and get the expected warning about comm failure with the KPL, but no exclamation point on the device tree. The ISY shows the status of the KPL as off which is false, but expected with the comm failure. As the ISY believes the KPL off, the loop in 'Motion-Front Porch' is stopped. The ISY shows the status of the test switch as On. A query of both devices changes the status in the ISY to On for the KPL and the test switch also has its status stay as On. How can this be? If the program ran as it should, the test switch should have been off. Does the failure of the KPL to respond affect the ISY's ability to send the next command in a program. If I had a comm failure to the switch as well as the KPL I would expect the ISY to show an Off condition for the switch just like the KPL regardless of reality. If I did not have a comm failure, why is the test switch on? Any thoughts or help would be appreciated. I am missing something here, I just do not know what it is...

Okay, 5 months later, Verizon changed my public IP. The DYNDNS service worked perfectly, apparently being notified of the change by the router itself.