Steigs

It sounds to me like you want to create schedules for your thermostat that are specific to a time of year (season). The following set of programs http://wiki.universal-devices.com/index ... _Variables allows you to create programs for your thermostat that are season dependent. for example If $i.month >= 1 and $i.month <= 4 and time is 8am Then Set thermostat to 70 Else - - So from Jan to April of every year the thermostat would set to 70 at 8am. Obviously you create as many programs like this as you want and include whatever parameters you want. Like if you have weather bug you could have the thermostat also depend on the outside temp in deciding the inside temp. Thanks, I'm aware of that. What I meant by 'season dependent' was whether a user would be turning the thermostat up or down. Sorry, it wasn't really relevant to the problem I wanted to solve. Think of the scenario this way: ISY sets the cool setpoint to 75. The wife comes in an hour later and manually adjusts the thermostat to 80. Later, for whatever reason, I want to just run the A/C for 20 minutes. I run a program that puts the setpoint to 70, ensuring the A/C cycle will probably run for a while. 20 minutes later, that program ends. I would like to have the setpoint return to where it was before the program ran. Without being able to load the current setpoint into a variable register before running the program, I have no way to know where it was set before the program ran. I'd like to be able to do something like: $CurrentTemp=DownStairsSetpoint Run Cool Program set DownStairsSetpoint to $CurrentTemp Obviously, the verbage is off, but you get the idea. Anyhow, not a huge deal that it can't be done currently and, as Michel stated, it's in the works.

Yeah, no worky if someone walks up to a thermostat, pushes it up to, say, 78, and then I need to go back to that 78 after a program runs. Thanks for the info and the link though! I'll just wait for the eventual update. To paraphrase a bit, "Great ISY things come to those who wait.."

You guys continue to rock.

I've been poking around a bit but haven't seen (or missed) this proposed scenario. I'd like a way to take the current setpoint of a thermostat and 'remember' it, perhaps by loading it into a variable register. The purpose of this would be to have a program that temporarily sets the temp higher/lower (season dependent) and then returns it to it's previous setting after a determined amount of time. Obviously I could define a 'return temperature', but I'd like to just restore it to the previous setting as not to disturb manual operation of the thermostat. Thoughts?

I'm using the wifi version of the IP2SL to control my tv and it works great. Haven't touched it since setting it up a year ago.

That was my initial thought, but I was hoping maybe there was a method a bit cleaner. Bummer. Off to do some repetitive code.. Thanks!

Exactly. In an ideal world, I'd also be able to enable or disable the offset 'mode' with a program.

Greetings fellow ISYers, I have a tstat for upstairs and one for downstairs. The upstairs hallway is open to, and overlooks, the 2 story den and in this hallway is where the 2nd floor tstat is placed. In order to keep the master bedroom warm, the upstairs stat has to be run about 2-3 degrees above the 1st floor unit. Normally during the day, it's not an issue. But at night if that offset hasn't been active, the master is the coldest room in the house. I'd like to find a way to track changes on the 1st floor tstat and then update the 2nd floor tstat appropriately. Can I load the current temp into a variable somehow and then run a program that adds 2 and sends that to the 2nd floor unit? Any suggestions appreciated.

Gotcha. Thanks!

Modified, thanks Lee. Just so I can get my head around it, can you explain how the ISY interprets the difference?

Greetings fellow ISy'ers, I have a program that runs the HVAC fans to just circulate air every couple hours. With the cooler weather I wanted to automatically disable the program, so I added a line for temperature: The program continues to flag true and execute as it did before. I assumed it would stop once it reads a temp lower than 80 degrees. Am I misinterpreting how that temperature status should function? The AutoCirc routine has no evaluations and can only be called by this program.

Bah.. That was exactly it, momentary output indeed! Thanks.

I wanted to set a delay between two HVAC units starting up, so I added a wait command in the program. Everything beyond the wait statement never fires. I've read that a wait allows the IF to be re-evaluated, but I don't understand why this stops. It never gets to the flag reset, so shouldn't it read true and continue the rest of the way through? Without that line, the program runs as expected.

Michel, DMX512 is a lighting protocol used in concert and theatrical lighting. Google "dmx protocol" and hit the Wikipedia page. I'd paste the link for you, but I can only get to the mobile version at this time. I'm not sure how you'd have the ISY speak dmx, but it would sure open a huge window of possibilities.

Love it or hate it, I've never owned a product with better customer support.

So after some time using and getting used to my ISY/Insteon setup, I've decided that I would like to rebuild from the ground up. As I've been using it, I've found better ways to do things both through experimentation and constant perusal of this forum. As my system is still relatively simple, my question is this: What would be the best method for resetting everything to 'factory default' to enable rebuilding from scratch? In my particular scenario, this would be much faster and tidier than rewriting all of the existing code. Thanks in advance, Steigs

I had that same issue. I had to use https in the address I use to access my admin panel. Look in the first post in this thread for more info. Good luck.

Hi Michel, Thanks, I will contact support. Interestingly, my evening sunset program just ran fine although the admin console still shows no connections. -Steigs Edit: Service ticket logged Admin console seems to indicate the ISY might be 'rebuilding' itself. After my sunset program ran I checked it again and the majority of my devices are back to normal status. Obviously, this is great, but I still don't know what took it down. Hopefully a chat with tech will sort things out and get the rest back online.

PLM power cycle, no change. Cleared cache, tried https:// route. I can see the ISY, but there is no response to loads or scenes. I've never been able to access the admin screen in a browser (Mac issue I guess) so I can't check it through this method. I reinstalled the admin app and was systematically met with "cannot communicate - check connections" for every device on my network again. Next?

Hi Lee, I had already tried writing updates, but it seems the ISY has lost communication with the entire network. I will try the PLM power cycle. Thanks

Hi Michel, Upgraded to 2.8.9 from 2.8.8. Twice, to get it to take and indicate 2.8.9 under 'about'. Cleared Java cache, grabbed 2.8.9 admin applet. Currently all load devices show a ! and all scenes and sub buttons show writes pending. Checked PLM under diagnostics, shows "13.24.CB v92/Connected" Load carrying devices don't respond to on/off commands within the admin console. I only mention this because under 2.8.8 I had a switch with a ! in the console, but everything other than "on" would function. Fast on, fast off, dim, etc. Currently, nothing responds or shows status. Also, local ramp rates now show 9 mins, which I assume has to do with lack of communication with the device. Just thought I'd post up here to see if there's a known path to take before I just start resetting everything. Thanks!

Hi Winston, I have the same problem here. I have to use the ctrl-click for a right click, hold down the button, move the pointer into the popup window, release, point to what you want and click again. Kind of a PITA, but it works. If you let off the mouse button before you move into the context menu, it will disappear like you stated.

Thanks Rand I've got my garage status/control working, but your solution is a bit more elegant. Scenes it is.

Hi All, I'm a newcomer to ISY/Insteon but so far I've managed to install 6 devices, set them up and have them all play nice. I'm very excited for future potential as I slowly replace standard switches throughout the house with controllers. (Although I'm somewhat despondent at the prospect of what I'll end up spending... ) I was setting up a keypadlinc button to show status of, and control, my garage door and realized I needed to integrate a 'status' scene to have it work correctly. It occurred to me that my pool controller would need the same type of architecture to be controlled from one of these switches as well. Although currently all my pool related programs simply address the load controller itself, not as a part of a 'pool' scene. So my question is, in the interest of establishing some standards and keeping my programming simple, clean and functional, am I better off setting up these types of devices as scenes and only addressing them that way or should I leave my programs to directly address the device and just use 'scene control' for linking to controllers? As the system grows, will I be kicking myself over extra work to have everything update correctly? I'm curious to what others have done as I'd like to pick the best convention now as opposed to when I have many more devices in the system.