Illusion

Thanks Rand, I was confused because in the topic it was listed under the heading: "Bugs in 2.7.12" I will go for this release. Thanks.

Sorry, it is a joke. And not an inside one, it is just that so many of us have been running beta and alpha software for so long, and the litany of issues that come up after first installing just released software can be quite comical. The violin comment was just a random thing thrown out there, and many people jumped on the bandwagon. It does not refer to a feature, it is just a joke that does not translate well to the written word. Sorry for any inconvenience.

Anyone?

Please do not jump to the ISY as the problem here. It may very well be a problem with Insteon, or noise on your network and not directly an ISY issue.

See Also: http://forum.universal-devices.com/view ... 7244#27244 http://forum.universal-devices.com/view ... 6313#26313 http://forum.universal-devices.com/view ... 7244#27244 The Venstar should come back after a power outage. I have mine text and email me through the isy if temps go outside set parameters.

Question... Listed in "Fixes in next drop" shows a bug in 2.7.12 beta: Bug xxx - ActionTec/Westell Verizon FIOS routers blocked all TCP connectionss Does this mean that if I am on a Verizon FIOS ActionTec router, I should avoid this beta as I will not be able to access it from outside my LAN? Does it still allow access from within the LAN?

alf, I have a Venstar T1700, T1800, and T1900 in use. I am using the original version of the t-stat adapters. I have a completely warm and fuzzy feeling about them. The way I use them I have yet to have a failed communication event that I know of. I have actually be surprised by how well they work. It has been the best part of my Insteon system and it looks like I am on track to see a 10% reduction in energy for a full year of use, while increasing my comfort.

Boy! That is a loaded question. There has been much written on both sides of the potential answer, with the vastly greater volume being on the "yes there is an issue" side. Just do a search on this or Smarthomes forum if you have a few hours to kill. In my personal extensive testing, I was not able to show an issue with my multiple v35 devices, but many others have data that shows the opposite.

Does this mean that if I still have lots of X10 stuff, I should avoid this update?

Emergency heat from the perspective of the t-stat should be the same as your aux heat. You have what is called a duel fuel system. Switching over to the gas furnace at 25 degrees is something called the economic balance point. It is not that the air source heat pump cannot heat your home, it is that now it is cheaper (not more efficient) to heat it with gas. A heat pump is basically always the most efficient option. Efficiencies range from about 400% down to 101% based on outdoor temp. So for 1 unit of energy, we move 2 existing units of energy (heat) from outside to inside. That is 300% efficient. A gas furnace may be 70-95% efficient. Electric heat strips are 100% efficient. While the gas furnace is less efficient than the heat pump, the units of energy cost less, so at some point it is better to switch to gas from a cost standpoint. (25d in your case) If you are really interested, this can be adjusted. There are calculators online that you input your electricity cost, gas cost, unit efficiencies and it will output the best economic balance point. Bear in mind, this changes whenever the price of utilities change. So yes, in your case, emergency heat is the gas furnace. The problem is, if you have a failure of your compressor, you will not be able to force the system to skip the first two stages and jump right to the gas furnace if using the Insteon t-stats. I am not an HVAC guy, but from looking at your schematic, it looks like the furnace fan speed is determined by the furnace looking at what calls are being made and adjusting itself. That is probably why Y2 goes through the furnace before making its trip to the compressor. I am guessing that a fan call makes it run is low speed, and a fan call plus Y2 makes it step up the fan speed.

Tome, First off, I was not suggesting that you get a zone controller to do what the t-stat should do right out of the box....however, if you were going to go that route, Honeywell also makes some smaller (fewer zones) controllers for less $$ that should do it. If you are interested, and dying to automate your t-stats with Insteon, here is how I would do it: The first thing to understand is how this stuff works. Conventional t-stats are basically variable contact closure devices. You supply a power line ® and it connects that power line to various outputs (G) fan (Y) compressor. The 1900, and by implication the 1800, are indeed a little funky for use with multi-stage heat pumps. Based on my extensive bench testing with the 1900 t-stat configured to have W3 heat and Y2 second stage compressor here is what happens: First Stage Heat Call: Energize: ( reversing valve energize to heat (not on your system, Tome, you have an (O) energize to cool valve (G) Fan (Y1) First stage compressor Second Stage Heat Call: (T-Stat will display as AUX heat) ( (G) (Y1) (W2) Here is the big issue, this should be (Y2). In theory, you could just hook this wire up to the (Y2) of the unit shown in your schematic Third Stage Heat Call: ( (G) (Y1) (W2) (W3) This would be hooked up to your W/W1 in the schematic First Stage Cooling Call: (O) reversing valve energize to cool (This would be used on Tome's system) (G) (Y1) Second Stage Cooling Call: (O) (G) (Y1) (Y2) Second stage compressor call As you can see, all we need to do is make the t-stat energize Y2 on the unit when the t-stat energizes W2. A simple connection does that. So in your application, you would have two wires connected to the Y2 terminal at the unit, or alternately the Y2 and W2 would be jumpered at the back of the t-stat. But I stand by my earlier concern: This t-stat thinks W2 is aux heat, not a second stage compressor call. So, if you tell the t-stat locally to engage emergency heat, it is only going to energized W2 and G when a heat call is executed. Bad deal. So it would work, as long as you do not force the t-stat into e-heat. As far as an algorithm for energy efficient operation. That is too complex. It totally depends on how you use setbacks, how much you setback, and how often. Then we have to ask the question of how do you define "comfort" and "efficiency". The t-stat comes with some pretty generic settings for the average joe, and that is probably where you current t-stat falls as well. Also, Tome, these are not algorithms. It is as simple as time and temperature differentials before the t-stat calls for the next stage. And truthfully, none of these settings will have a massive cost impact except the time and temperature differential before the t-stat calls for aux heat. {True aux heat (W3) not what it thinks is aux heat.} See also: http://forum.universal-devices.com/view ... 6546#26546 Disclaimer: I am not an HVAC professional. I actually have nothing to do with the industry. This is just a recounting of my personal research for my own personal use. Use this info at your own risk and risk to HVAC equipment.

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