paulbates

Thank you Stu, I was just tweaking that when you posted.

Hi matapan- Like many technical decisions, there is not one universal answer and the answer is; it depends. I think you will probably be happy with it. No matter which thermostat choice you make, there will be advantages and issues. One thing you need to do is go to the main forum page, and type in 2441TH under the main search box. Plan on spending an hour or so going through what people have experienced. Here is how I see it at a basic level: Advantages It integrates directly with the ISY, and the ISY sees it as a thermostat. To me, this is one of its strongest attributes. If you are looking for remote control of your thermostat through ISY programs and mobile applications, this is where the 2441TH shines. Its a basic smart thermostat (this can be an advantage or an issue depending on how much you want to control your hvac system) Issues The problem shannong reported above. I too had this problem and had to return my two units and shop for something else. The symptom is that the unit is affected by the gas furnace igniting in some cases, and it might cause the 2441TH to "lock up" and do bad, unpredictable things. However, I do not believe that this happens to the bulk of 2441TH users. Many have it, use it and love it. Unfortunately there is no way to predict this behavior. If I had to guess, you probably won't see it. If you don't see the symptoms in the first 24 hours of regular heater cycles, you won't ever see it. I consider this a design flaw that only affects a smaller number of users who's furnaces don't filter the igniters from the furnace main conroller. I say 'design flaw' as I've had several other automated stats on the same HVAC units that did not have this problem. The connections in the 2441TH to the furnace should have been filtered. Shannong was the one who figured this out and worked tirelessly to solve it. While I too witnessed the symptoms, credit goes to shannon who debugged it and figured it out. Its a basic smart thermostat. I was looking for more HVAC control. So its important to know if you want a basic stat you control with the ISY and Apps, or you want that plus more control over you HVAC system I see a number of users struggle a little with getting timely updates on temperature from the 2441ZTH when its under battery power. If you search the forum as described above, you will see this theme. If you want a basic integrated thermostat with ISY and mobile app control, you will probably be ok. Paul

Hi The other thing to know, and I didn't catch reading this first time, is that remotely turning a device on does not activate any scene its a controller for. You have to use Set Scene as you have done. You have it right. Paul

I would create a scene the includes device and the button. Make the device a controller/responder. When the device turns on, the Insteon network will turn on the scene at the same time. (Make both the device and key controller/responders if you want the key to turn the device on as well, if that scenario makes sense) The other choice is to use a "set" command in a program. If control device is set on then set keypad device name on However, typically I prefer a scene instead.

Hi Smoke grub Start with the most recent manual, located here, section 3.7. 2 things: Notifications are a little tricky. Give yourself time to read, practice and learn them I think the disconnect in this thread is devices vs variables. Dennis is sending the value of his zwave thermostat temperature from the thermostat, not a variable. I think you can do the same. Look for your thermostat in the ISY, where the temperature is reported, and substitute that name where Dennis has: Interior Temp: ${sys.node.ZW011_1.ST}. You'll need to substitute your thermostat's temperature device name where he has ZW011_1.ST. Paul

Hi. Yes, both are set in the admin console. For the device locally or direct device commands: You click on the device in the admin console to set its local behavior if its a dimmer, the percentage on and the ramp rate. For each scene: Click on the scene name in the list in the admin console. The list of devices appears, and for dimmers you can individually set the percentage on and the ramp rate. When you turn that scene on and off, those specific settings will be used Paul

I got this advice from a engineer a log time ago: "You get what you inspect, not what you expect"

Techman I just put in 2 HVAC units, 2 stage. last fall. The Colortouch's menus offer options to configure how / when 2 stage kicks in and I got to work with that this winter. Each part of my house is very different than the other, and I ended up with different stage 2 call settings for each. Something to look at is the manual for the HVAC unit's second stage call behavior. Some units have an option to let the furnace decide to call stage 2, without listening to the thermostat, based on a return air sensor. It allows single stage thermostats to operate the unit, If the hvac unit is in that mode, the 2 stage calls from the colortouch won't be respected. Though I asked for the Carrier HVAC units to be configure for thermostat stage 2 calls, I found both units set for the furnace to do it. I found it by pulling the furnace cover to look things over. It was one dipswitch throw on each unit to set it the way I wanted. Agreed on v5, but I plan to use that to have the colortouch integrate better into mobile / tablet / web apps. I would love to stick with venlink even under V5 as there are additional enhancements it provides. Paul

Hey Techman- Yes, you can disable skyport cloud services (WAN), and keep Local LAN API on. The wifi card stays in. There is a setting on the menu of the stat to set this. There are indicators on the stat's interface to show if skyport is active or not, and it changes if its LAN API only. I did shut my skyport off once to test and be sure that it could not call home, it could not and things kept working locally. I use venlink which actively polls each stat every 30 seconds, it was clear that local LAN still worked, and skyport service did not. I believe their information gathering quest is based on how they are aiming to support Open ADR. Identity and location specifics would be needed. The current firmware supports ADR, but I've not seen how they plan to tie it to a power utility. You, in California, will see this happen probably before me, in Michigan. Paul

Hey Techman- Great question. There are a number of alerts you can configure. I've always done that through the skyport website. The alerts messages come from messenger@skyportcloud.com. The relationship between those features and the skyport cloud website is very tight, my guess is you need the skyport service to get the alerts. However, I've not tried it another way to know for sure. Also, I've found the maintenance based alerts to be 'trigger happy', I get them too frequently, compared to need. I use other methods to determine filter and humidity pad replacement. However I love the temp high and low alerts, as well as humidity high and low (T5900) The colortouch series appears to be unix under the hood, but locked down hard: REST, Skyport and the front display are the only ways in I've found. (not ssh, telnet, scp etc, they might be on non standard ports) I like skyport, you may want to turn it on and visit the website and give it a try. It does a lot, including configuration. You can shut it off at the stat if you don't like it. Paul

Techman- Not to the ISY, correct. A middle man is needed currently in v4 firmwares. You can query the stat with a browser/rest, but not get it back into ISY variables and do meaningful things. developer.venstar.com documents what's in the rest api. Paul

Hi Techman. Yes, when you install the skyport wifi module there are two independent wifi options: Local API for REST calls Skyport cloud They are set on the accessories menu that will appear once the card is plugged in. You can turn either, or both of them, on or off. I was never asked about signing up for the skyport service. I use it, but a couple of times shut it off. My guess is that if you turn skyport off, you will not hear about it. You can use the ISY to send commands to the T5800, if you search for T5800 or T5900 on the board, there are several good examples. io_guys venlink is a great option as well if you have a windows workstation or linux box to run it on. It gives two communication with ISY variables and a lot of power. Its small .net code and can run on anything. Paul

mbam Not what you want to hear, but I think "yes". What you are seeing, I think, is a unique scene address for the button and fan to use together. To connect it to the ISY, you either need The module address, or Put it in linking mode Both of these are a trip up the ladder. Hopefully someone like Lee will come along and prove me wrong, but from my understanding of Insteon and having a few of these beasties buried in fixtures and above the ceiling in low voltage lighting, there is no other way. Paul

So adding water is a bad idea

I have, on rare occasions, had to remove devices from scenes and re-add them to get the working again, This includes keys. As you said, it was things that worked well for long periods and for reasons unknown, stopped.

Ok, thanks. It sounds defective. Where there any issues installing it electrically, it went in ok?

Hi diggler Just to clarify, the led on the module responds all the time when you remotely activate the switch, but not always the fan motor? No problems turning it off, after it does turn on, it turns off every time? Paul

Jamminred Sounds good. There are multiple competing needs and all may not be able to be addressed with any one location: Close to the panel and bridge as you've done. The electrical system is the master antenna system for insteon, and the panel is the center Appearance- i get not having wall warts visible in your house PLM not being surrounded by metal so that its RF can get to other RF devices easily Good temperature and humidity environment, within specifications Its hard to hit all of those targets in one location. I have a dual gang box right off my panel, inches away. The box has the signalinc bridge and an outlet for the plm in it, connected to one of the breakers for the signal linc. Temperature is always well within the PLM's, even the 80% rule mentioned by Gary.. But... its under the electrical panel and has a metal furnace and ducting on one side. RF access could be better. However, that's been the best I've been able to do. The new UDI PLM is coming out soon, and its based on the Insteon Hub that has a 6' power cable. I can raise that UDI PLM higher towards the ceiling and clear my furnace. I had an Insteon Hub 1 with Homeseer and that approach worked. You may want to consider that in your future plans when the UDI PLM is offered for sale. Paul

Hi Jamminred I agree with Teken. If the phase couple is in the attic, then your panel is in the attic? Paul

Glad it worked! I will be putting it in soon too!

Stu Good point, if the concept proves out on the bad controller, it could run off of an unused zone of a good one. I have 2 easy floras, 14 zones plus 2 master valves... I could probably run it off one of the masters.

This is a tough one, and I would be interested in this too. The EZFlora is not a traditional Insteon link controlled device. The ISY contains special programming to control the EZFlora and other EZxxx devices, and they don't follow the same exact rules that a switchlinc or keypad would. I have an idea that needs to be tested on your existing 'bad' controller to see if its viable, if you are game. Have 2 programs, 'A' and 'B'. 'A' turns zone 1 on, queries it, and calls 'B'. 'B' looks to see if Zone 1 is really on. If not, send a notification Program A If time (is when you want to verify) then Turn a Zone 1 on (Insteon Zone 1 on) wait 5 seconds Query Zone 1 (Insteon Zone 1 Query) Run If Program B Turn Zone 1 Off else Program B If status Zone 1 is off then Notify (whatever notification you want, text, email) else Edit: Use the admin console to 'right click' on program B and disable it. We don't want an alert after that Zone is turned off, if its a zone that waters and is part of an irrigation program. ________________________________________________________________________ The assumption I am making is if you turn a zone on, and query the status, you get an "on" back. If the unit is damaged, you'll get "off" back. This needs to be tested on your bad controller I'm not sure this will always find a problem. It also will turn a zone on an sprinkle for 5 seconds every time you run it if the controller is good and responding. But it shouldn't take long to see if it really works or not. Probably we need to turn in an enhancement request for better status response from Ezfloras. Paul

You are welcome. I bought Insteon as a way to bridge off of X10 and have had a number of unexpected surprises over the years with that plan, things different than what I thought / wanted. I sure learn a lot here on this forum all the time

Individual Insteon device commands are fully acknowledged and retried. However the group broadcast message used for scenes from the PLM is not acknowledged or retried. There is no "acknowledgement storm" from the devices. If the Individual insteon device commands are issued before a scene, or before X10, the acknowledgement response from the device can collide with the next scene or X10 command. X10 messages are vulnerable getting stepped on by the acknowledgement as well. Therefore, the individual Insteon device commands should be the last command(s) in a program sequence. If its possible to make one single thread program (no Run commands), my suggestion is send the 3 X10 commands followed by a scene, followed by individual insteon commands. One more thought to simplify the above: Scenes are 'cheap' resource wise (unless you have hundreds of Insteon devices). I would create an additional scene with the 12 original members, and then add the three additional devices. Have the program control the three x10 devices, and then control that new scene. It will give you the added 'effect' of all the insteon devices going off at the same time, and lower network traffic.

Hi The number of devices in the scene are not a root cause for what you are experiencing. By design, insteon scenes can have many devices. When you set up a scene with your ISY, it creates a unique scene address/link, and then programs that into each participating device. When you issue a scene command, a single message with that address/link is sent on your power line, and and all devices programmed for that respond to that single message when they see it. My largest scene has 26 participants, and only one message is needed to activate them.