upstatemike

Actually the answer is no. As you dim a light the electricity used goes down but not as fast as the light output so you get less and less efficiency (less lumens per watt). In other words, a 100 watt light bulb dimmed to 60% light output will use more power than a 60 watt bulb that is not dimmed. Where dimmers do save energy is in areas where a bright light is sometimes required but not always. For example, you could keep the front hall light dimmed to a "pass through" level in the evening and only use it at full brightness when you have guests or some other activity where people would dwell in the area. Even this scenario is a bit of a rationalization because keeping the light off and using a motion detector to turn it full on when someone passes through would be a much more energy efficient strategy.

This would certainly be helpful. Even the ability to just be able to see the unkown links would go a long way towards helping with troubleshooting.

The very best answer would be to use a Logitech Squeezecenter music server which has an open and robust network interface that could easily be supported by a product like the ISY. If all you need is to play a short wav file you might look into using an Elk voice announcement module triggered from a wall wart transformer plugged into an appliance module.

Yes, there will be a Homeseer plugin for the ISY and this will open up a number of new possibilities for Insteon integration. While it is true that some hardwire IO, thermostat control, and security functions can be achieved with existing integrations with Elk M1, EZIO modules, etc, Homeseer will bring some truly unique functionality to the table including: TTS based voice prompts for Insteon actions ("party scene activated") Insteon control via voice recognition Insteon control based on home weather station input Insteon control via telephone etc. An ISY + Elk M1 + Homseer Hometroller 2 + Way2Call modem would be and incredibly flexible automation platform.

This is an interesting point to consider. In any other automation device I have used the If section acts as a trigger, and once triggered the Then section completes execution regardless of whether the trigger remains true or not. The idea of a trigger needing to stay triggered thoughout execution is definitely a different paradigm for a lot of folks.

I don't know your specific situation but two things I have found to be helpful if you haven't already tried it. 1- Make sure you have a static IP address set. Then you have one less variable to deal with when troubleshooting connectivity issues. Does the ISY respond to a ping so you know it is online? 2- Unplug the PLM for at least 10 seconds so everything re-initializes before trying to connect. Most of my connectivity errors have been from something getting stuck in an odd state and this always clears it.

I'm not sure I understand what you are asking but I want to be sure you are clear that the ISY is MANAGING links not CONTROLLING them (unless you set up some programs to do control). I did the same thing as you because I had so much stuff to keep track of that starting from scratch would have taken too long, so I left the existing links in place. This caused problems in some areas so once I got everything arranged the way I wanted, I started deleting and re-adding devices one to a time. When I re-added them I chose the option to clear the existing links in order to ensure all the junk was cleared out of the modules link table. If you don't do this then any junk that was in the link table will not be reflected in the ISY gui but WILL be faithfully restored any time you do a restore on the module. There is currently no way to see what that junk might be so you have a potential troubleshooting nightmare if you don't let ISY get rid of everything it does not manage.

Any estimate on when IES will be ready to support this release?

I just printed an updated copy of my topoology (got it shrunk down to 24 pages) and would also like to print out my programs but I don't see any print or export options available. How is everybody printing out their programs?

If Control 'kitchen Light' is switched On Then Set Scene 'Kitchen light' On Else -No Actions- Create a scene called "Kitchen light" and put the Kitchen Light switch into it as a responder. Make the ramp and level for the scene the same as the local settings for the Kitchen light switch. When the switch is off and you turn it on the local settings will apply. The scene setting will be applied immediately after but you won't see anything because the scene setting is the same as the already active local setting. When the switch is On at a different level due to the double tap scene a single tap will again initiate the Kitchen light scene and restore things to normal.

What if you create a scene that duplicates the manual setting and have it triggered by by pressing the switch once? In normal operation the switch would get set twice (once manually and once by the scene being triggered) but you would not see any difference. When the switch is set to any other scene setting, a single press would bring it back to normal.

For one thing I think they operate in a different frequency range.

I would make the default level for the switch 50% with a moderate ramp rate of 2 seconds. I would then create a scene with the light at 100% and a ramp rate of 2 seconds. Change your program to trigger during the daytime and have it activate the 100% brightness scene.

The only thing missing in this example is some code to disable the timer program whenever the mud room light is turned on manually from the switch, and enabled again when the switch is turned off.

I am planning to use this with "Control" triggers where I expect the trigger to be a switch being turned On but also want to allow for an accidental double tapping of the switch Fast On.

Thanks Darrell. For some reason I failed to notice that there was another drop down menu under "is". Pretty obvious!

Sorry if this is already covered in an earlier post but I couldn't find it. I need to test for a condition where a light is "NOT Off", in other words "On at any level". It looks like just using On only works if the light is On at 100%. How do I test if a light is "On at any level" or "NOT Off"?

I don't know the answer but I got one a while back for my Birthday that I have not had time to set up yet. I'll be giving it a try in the near future (maybe even this weekend.) I know the touch screen is going to be officially supported in a future ISY software release but I'm not sure how well they are going to play together in the mean time.

I think you might find that would be problematic since there are times in the GUI that you might need to operate a switch independently regardless of its scene associations. Remember the GUI is an admin environment so it needs to be able to do stuff that you might not do in day-to-day physical operation of the switches.

I have 175 devices and no issues. I don't think your problem is due to the number of devices.

Just to confirm... You used option 1 to delete existing links when you added your devices to the ISY right? Reason I ask is you say things get messed up when you factory reset your devices and then restore the links. If you told the ISY to retain Houselinc information when you added the devices then any incompatible data would have gotten added to the ISY database and that data will always get put back into your Insteon devices when you do a restore. Maybe that is not the issue you are having but the symptoms sound like what would happen if HouseLinc data was retained in your Insteon modules.

Option 1 will ensure no HouseLinc stuff gets left in your device tables and stored in your ISY to haunt you later.

Maybe Jon (author of the current Insteon Plugin for Homeseer) will be able to convince Rich to do a Homeseer supported ISY plugin.

Jim- I'm curious how you are currently managing your device to device links with Homeseer? Are you also using something like PowerHome? Are you trying to manually tap-tap manage them? I ask because I think this is the weak part of the current Homeseer plugin strategy. Homeseer does not want to provide a general tool for managing the Insteon environment and yet they let their plugin blunder around in the link tables of individual Insteon devices causing potential conflicts with whatever is used to manage the device to device link structure. Managing your environment with an ISY and then using an ISY plugin as the gateway from Homeseer to Insteon would likely solve those problems but would the cost of developing such a plugin be of sufficient benefit to UDI for it to be worth pursuing? Even if you and some others would purchase an ISY based on the availability of this plugin, how many other Homeseer/Insteon folks would be willing to do so? Also how would such an animal work? Homeseer maintains a device database that needs to be coordinated with the ISY device database. I know I make changes to my Insteon environment at least once a week... how much of a pain is it going to be to re-sync the two system's device tables that often? How much editing of Homeseer scripts and events will have to happen each time you change devices around with your ISY? (or any other link management tool) Also what is the value added from having a Homeseer plugin? Once you have an ISY, you will want to put any scheduled or sunrise/sunset Insteon stuff directly into the ISY. If you want to trigger from motion sensors, you can use X10 translation for X10 RF stuff or the existing Elk M1/ISY integration for hard wired detectors. Putting Homeseer into the middle of either of these situations does not add any value. If you have other triggers interfaced to Homeseer you can easily use an X10 transmission or an Elk M1 rule to facilitate Insteon operation. There is perhaps some value in being able to trigger Homeseer events with Insteon triggers, but I think there is already a way to do that if you use the Elk M1 interface. A direct ISY plugin might make this a little more direct but is it really worth the significant development and support effort from UDI as well as the added complexity to the end user of keeping the two systems in sync? I'm not saying there is no case to be made for an ISY plugin for Homeseer, but I think some of these things need to be analyzed before UDI can justify the development and support effort. Maybe it would be better if a third party were to take this on?

I probably made it more "long and winding " than it needed to be but I came out with a better understanding of how things work. I learned (or finally came to understand) that: 1- A factory reset does not = zeroing out the registers of an Insteon device, but rather it means setting the first byte to 00 or 22. Knowing this will reduce confusion when viewing a device link table with some kind of troubleshooting utility. (Hopefully I will not need to do this anymore anyway.) 2- Foreign links that are preserved by using the third option when creating a device MAY NOT BE DISPLYED IN THE ISY if the link is not understood, but WILL always be written back to the device during a restore. Knowing this makes it clear why problems might not get fixed by doing a factory reset and then restore... you might be restoring an invisble problem link! 3- Oddball links can cause a number of problems that you might not expect to be link related including "self activation" triggered by random traffic or intermittent communication errors. 4- If you need to use option 3 to discover your existing topology and get it into your ISY, you may want to print the topology and use it as a guide to remove and re-install your devices using option 1 (delete existing links) at some point, to ensure you have a clean Insteon environment. If your environment is small enough, it is better to use option 1 and do a clean install from the start. 5- The idea of preserving existing links for coexistance with unsupported devices sounded good in theory but now I have to back away from it as a priority since my own experience has shown me what issues it can raise. Clearly I was wrong in promoting that approach. 6- Don't go chasing theories about X10 or signal strength, or whatever, until you try removing the device and re-installing it cleanly using option 1. This should be the first step to set a baseline in any troubleshooting situation. The second step should be to do this with all devices that are a Controller of the device that is giving you trouble. Chances are good that you won't need a third step.