SunSentry

Apologies if this has been asked before, yet I can't find the answer when I do a search or scan through the forum. Although I have used ISY for many years, I now need to set up some season programs and can't figure out how to do that. Example: We have a waterfall and is controlled by an outdoor on/off Insteon controller. To keep the waterfall clean and odor free, we like to run it during some time of the day, HOWEVER only in the summer months. The scheduler seems to allow only specific date ranges in a specific year rather than allowing me to select specific months. I'm betting someone has a good solution for this... or perhaps I am missing something obvious.

You folks are really smart. Resulting from the above suggestions, I have the guest bath light set at a very low (night light) level from sunset to sunrise. If the guest turns on the light in the middle of the night, it ramps up slowly to about half brightness to not kill their eyes. Of course if they want full brightness, they could always click the paddle again. Then when they turn off the light, it goes back to the night light level. Cool stuff you can do with the 994. Much thanks

While on this subject... what does anyone think is the best way to have a light return to a low dim level when someone clicks the paddle switch to turn off the light?

Ok, you found the error in my logic I DID NOT have the light switch set as a Controller. It was only set as a Responder in my scene. That actually confuses me as I didn't want the light switch to control anything else except its load, but I guess in this case, it needs to be also set as a Controller. Changing the switch to a controller is the only thing I did and now it works very nicely. You da man !

Hello all, I specifically searched for this same question and glad I found a thread where the same question was asked. I also want lights in my guest bathroom to come on at a dim level and slower ramp rate during the night. If a guest wants the light to be bright, then they could always double-click the upper paddle. Actually, I already thought about creating a scene that changes the ramp rate and "on level" during the night, yet it was not working properly which is why I cam here. Setting the scene only appears to work if I actually run the scene, which of course it turns on the light and that is not what I want to happen. I actually want to change the "Local" on level of the light so that when the guest presses the on switch, then it goes to that level. I don't really see any way to change the local on-level by program control in the 994i. I must be having a dumb brain day

Yea, same here. I did not have the problem for a long time, and about a month ago I upgraded my device to the new 994. All was working well till two days ago. After restarting the interface a couple of times, it came up properly. Other than this occasional annoying problem, the system works well and we really like it. Nice and reliable. Richard

Just to say that this is a great thread and some fabulous answers from LeeG (as usual). I suspect many people wrestle with this exact same issue from time to time. Several months ago when setting up a motion sensor for our master bedroom bath, I had these precise same issues and finally figured it out for myself. I wish I had posted the problem at the time. I would have not needed to waste so much time figuring it out. Thanks LeeG for your great knowledge and considerate postings.

Well, I am back to say that after much experimentation over the holidays, we were never able to figure out why the blank "Current State" values appear when starting the UI. In fact, it seems to happen more often that not, so it is very frustrationg. To me, it is something to do with the JAVA app. Frankly speaking, I have never been a fan of running a JAVA app in a Windows environment. I much prefer a native app which we will probably never see for this program. It's ironic for me to shun a JAVA app especially when we were the ones who first coined the phrase of JAVA and sold it to Sun! We did figure out the issue with the strange operation of devices and that was due to something wrong in the data file. When we back tracked to an older 3.2.6 version of the ISY, all was well, but upgrading to 3.3.6 cause strange things to occur. We repeated that process 3 times to confirm. However, by manually re-entering all the device and program information into version 3.3.6 (starting fresh) everything has again worked perfectly. This tells me to never update the ISY again unless there is some sort of wonderfully new feature that I really need. At any rate, the software is great once I get it going and the home devices work perfectly the way we want. The ISY is sure a nice device and is rock solid in operation. so aside from the annoying problem of having to clear the JAVA cache and reload the app to get it to run, all is well. I'll live with it because now that things are set up, I don't need to go in there often to change anything.

Upgrade worked flawlessly. Nice theme feature

As mentioned in my other post. The new themes are great. Now that I upgraded, I can use the interface wonderfully and focus on setting up new devices. I do still get that occasion missing status problem that this post is talking about. I can now experiment more. THANKS a million!

Just to put in two cents more... There could be multiple reasons for this problem. I mention it because we have this status failure problem on a computer that is a fresh Window 7 build. It does not have antivirus on it and never did. It is an internal home server. Also to make one more comment. I was intimately involved in "BitDefender" AV and I can tell you for certain that when that program is temporarily disabled from the menu, then it is completely disabled. I don't know about the other programs. Perhaps other AV software may work differently and be an issue even when disabled, but BD does not. For testing purposes, when it is disabled, it won't affect anything. It was designed that way.

Great explanation !!! You really understand this stuff well. I am puzzled as to why the devices started working as planned when I did a hard reset, but as long as they work, I guess I don't really care as to why.

I am curious about the reason for reading "Status" in the "IF" statement for the outdoor lights. I have a similar situation for swimming pool lights that I don't want other family members to leave on after getting out of the pool late at night. I can understand the need to check garage door status because of the toggling method of the way garage doors work, but is it really necessary to check the status of a light before turning off the scene? In my program, I tell it to turn off the pool light scene during a range of time at night and day, so I don't check the status since I want the light off no matter what the status. Wouldn't you want to do the same with your flood lights? Couldn't the status be reported wrong? tnx for your thoughts, Richard

I thought I should put this info in a separate thread so as to not confuse people with other issues. After upgrading from 3.2.6 to 3.3.4 a couple weeks ago, I started getting a couple lights doing strange things such as not coming on at the level of brightness that seems to be programmed in the scene, and a 3-way light not working properly. When going back to 3.2.6, everything began to work normally again. LeeG, you gave me a BIG clue when you mentioned this in another thread... "There was a problem some releases back with the file system that could have compromised some of the Insteon configuration data. It could go unnoticed until a device was restored. I noticed that at one point some of the devices were restored. This could have rolled incorrect data back to the device. The probability is low of this happening and it is not an issue with 3.3.4 itself as it is only restoring data it did not create." When I compared the device link table to ISY, they were not the same. I made a couple attempts to "Restore Device", yet I was never able to get the device to match the ISY. I also tried removing the device from the scene and re-adding it back in, but still get a table mismatch. I would have thought the ISY could completely wipe out the table in the device and restore it properly, but that did not happen. I had to hard reset the devices (reset button on the devices), then when I did a "Restore Device" from ISY, the tables matched, and the problems went away. The devices started working properly. I'm attaching an image to show an example for one of the devices that continued to show a link table mismatch. It's the last record that never seemed to match after attempting a restore. In thinking how these mismatches got that way in the first place? I have no idea. Your might be thinking I manually linked the devices in some way, but I never do that. I always use the ISY UI to create scenes, so I am puzzled how they get out of sync. At any rate, the weird problems with those 3 devices stopped after doing the manual device reset and then restoring with ISY.

Ooops, one other thing. Isn't this setup called a "3-way" instead of a 2-way? I understand the concept of 3-way switches, but not 2-way.