MaddBomber83

Take a look again through the thread in my signature. At the end there was a forum user that had issues getting the 1 wire up and running. What followed was some basic troubleshooting to see where the problem is (such as checking the 1 wire directory, clearing that out, stuff like this) to see if it is a module issue, a file system issue, ectra. While you are tinkering, consider doing an upgrade on your system (I've moved on to Arch Linux, so the command is different now).

I really need to grab my module and check out the the variable voltages. Anyway, yes you can get your local weather data into isy. There are a few catches and hangups. Using 1 Wire, you could easily get temperature and humidity, but you are looking for more weather station type stuff. One of the forum users has set up a home weather station. Using WUnderground you can actually register your personal weather station so that it is accessable online with a weather station ID. From there you can set weather bug to get the data from your personal weather station's ID. I've personnaly not gone through this process, so there are a few things you'll want to check out. A Forum post, long, but at the end they start getting into how to set this up. A forum user's web site where he lays out additional details and has some pictures. WUnderground's site on the PWS Now looking at the rest of your list: Your I/O contacts can be connected to anything I/O related with ISY. an example would be the EZIO8SA or EZIO2x4. These devices can be used to connect 4 switch type inputs into Insteon signals. There are also the I/O links. You are still looking at $40 per signal though. For the 0-5V stuff, that can be pushed through on the 1 wire bus using their battery sensor. An example of doing this is here: http://davidbray.org/onewire/barometer.html As surface mounting the ship can be a pain, I purchased a few from Sheepwalk Electronics. It is a custom part, 16 british pounds is what they sold them to me for. It is this Humidity Sensor with the humidity sensor removed. Going a different route, check out this post for doing the I/O and 4-20ma signals using the elk module.

Some sensors can be done easily if they output something the ISY can sense. An example would be a leak detector that has a 12 or 24 volt on / off signal that interfaces with an insteon I/O module. Something more complicated, such as water level that outputs a variable voltage or current. I've seen a few people use modules from the Elk Security System to send that information over to the ISY. There are a couple solutions that use the 1 wire bus through another interface such as a Raspberry PI. With these you can get temperatures, humidities, and with a bit of tinkering, 0-10vdc signals sent to the ISY. A list of your current sensors, what they do, and what outputs they have would make responses more useful.

Hmm, I've always been in the 'you don't have a defense against a professional' crowd; everything else is just to keep children off your system. I'll have to think about our security setup. Thank you for the post, OP; and sorry this happened to you.

Another way to tackle the situation comes into play if you use the ISY to set your schedule. This is because we can actually enable and disable programs from within a program. Assuming you do use the ISY to set your schedules and SPs; modify your program to include the following: If On Mon, Tue, Wed, Thu, Fri From 11:10:00AM To 9:10:00AM (next day) Then Disable Program 'Tstat - One - Notify' Wait 30 seconds Set 'Thermostat- Main' 75° (Cool Setpoint) Set 'Thermostat- Main' 65° (Heat Setpoint) Wait 30 seconds Enable Program 'Tstat - One - Notify' Else - No Actions - (To add one, press 'Action') In this way, our Notification Program is disabled before, and enabled after, any ISY Scheduled SP Changes. Our notification program is: If Status 'Thermostat- Main' is 1° (Heat Setpoint) And Status 'Thermostat- Main' is 1° (Cool Setpoint) Then - No Actions - (To add one, press 'Action') Else Wait 1 minute Send Notification to 'Admin' content 'House Out of Bounds' This program will only get called if the Heating SP or the Cooling SP changes, for any reason; and it will essentially always be false. Because we disabled it before, and enabled it after an ISY SP change, it will not run when the ISY changes SP. It will only run if the SP is changed by something other than the ISY. Edit: I should note that the above program will run when you Query your TStat, such as the 3am Query. To get around that you can add a range around the 3am time in the IF block of the notify program. That way it is TRUE during the Query and won't run the Else statement.

It does, but this is not something that currently the user can access. As in, the ISY knows when the SP is changed, and it updates a system level variable for what the new SP is. You can only compare that number against other numbers; and not variables. UD is planning on releasing an update that will allow us to directly read these variables. In this case it will be easy to do what you want. Until then you will have to work around the issue. As to mind boggling for the first recommendation; you can really break it down into a system of programs that is easy to understand. This is true because we can actually check programs to see if they are true or false. So, your structure: - First make a new folder called TStat One (or whatever you call it) - In here make a program for each schedule with nothing in the Then/Else section. - Name these (long names) something like Tstat - One - Schedule - Weekday - Morning If On Mon, Tue, Wed, Thu, Fri From 9:10:00AM To 11:10:00AM (same day) - Now COPY this program, rename it and change what needs to be changed (such as making it the evening schedule) If On Mon, Tue, Wed, Thu, Fri From 11:10:00AM To 9:10:00AM (next day) - Once you are done making all the schedule only programs, redo this process for your 2nd and 3rd tstats. - Now you will have all the programs to compare to see if you are running a particular schedule. - Next, make new programs in all the folders with your temperature range in there, name these Tstat - One - Range - 65 to 80 If Status 'Thermostat- Main' is 80° (Cool Setpoint) And Status 'Thermostat- Main' is 65° (Heat Setpoint) - You'll do this for each temperature range you use, I'll add a second one called Tstat - One - Range - 65 to 70 If Status 'Thermostat- Main' is 70° (Cool Setpoint) And Status 'Thermostat- Main' is 65° (Heat Setpoint) - Again, redo this for all the other Tstats. - We now have all the schedules and ranges set up, for all three TStats; and they are easy to glance at to see if one is missed; or even edit a range or schedule if you change them. - Now we will create a notification program for each TStat. - In this we will use several nested and blocks. Essentially each nested And Block will have a Schedule and a Range. - We will be using the Else command to send the notification. - Here is the Tstat - One - Notify program If -( | Program 'Tstat - One - Schedule - Weekday - Morning' is True | And Program 'Tstat - One - Range - 65 to 70' is True -) Or-( | Program 'Tstat - One - Schedule - Weekday - Evening' is True | And Program 'Tstat - One - Range - 65 to 80' is True -) Or-( | Status 'Thermostat- Main' is 1° (Heat Setpoint) | And Status 'Thermostat- Main' is 1° (Cool Setpoint) | And Status 'Thermostat- Main' is 1° (Temperature) -) Then - No Actions - (To add one, press 'Action') Else Wait 1 minute Send Notification to 'Admin' content 'House Out of Bounds' Since we named all our programs something reasonable, this final program is very easy to understand what it is looking for. We want to send an email when none of the schedules and temperature ranges match up. The last 3 conditions should never be true, but because we called them in our IF block, this program will run whenever the Temperature, Heating SP or Cooling SP change. I should note, that you can re use any of the programs. In this way, if your Weekend Morning Temperature Range is the same as the Weekday Temperature range, but they start at different times; - You would have your And Block look like: If ( Schedule - Weekend Morning is True Range - 65 to 75 is True ) Or ( Schedule - Weekday Morning is True Range - 65 to 75 is True )

At our house, instead of a notification, we 'walk' the set points back to where they should be. Example, if the schedule has the cooling set point at 75, and someone was to lower it to 71 then: If Schedule Logic Here AND Cooling Set Point < 70 Then Wait 1 Hour Set Cooling Set Point to 70 If Schedule Logic Here AND Cooling Set Point = 70 Then Wait 1 Hour Set Cooling Set Point to 71 If Schedule Logic Here AND Cooling Set Point = 71 Then Wait 1 Hour Set Cooling Set Point to 72 and so on.

Without setting up a bunch of back end stuff, the simplest one would be to check the value of the current SPs vs what the ISY thinks they should be. If From 9:30:00AM To 9:30:00PM (same day) And ( Status 'Thermostat- Main' is not 65° (Heat Setpoint) Or Status 'Thermostat- Main' is not 75° (Cool Setpoint) ) Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') You would set one of these up with your notify programs as the THEN action for each of the scheduled SP changes that the ISY makes. There is a way, with a bunch of programs, to read / write variables to the TSTAT, and in this case you could just compare if the SP is different then what it was set to, using variables. A future update will add direct variable support, and then it will be much easier to accomplish.

I actually just had a thought for your purposes. If Zone 1 is < Heating SP Then - Set $Zone1_Demand to 1 - Set Solenoid 1 to On Else - Set $Zone1_Demand to 0 - Wait 5 Minutes Then Set Solenoid 1 to Off If Zone 1 is 1 or Zone 2 is 1 or Zone 3 is 1 Then - Set Boiler Temperature High (something that will turn it on, but not be unsafe) Else - Wait 5 Minutes - Set Boiler Temperature Normal

So I do this with my current TStat. The way I program it is to manipulate the set point of the TStat to the correct value to turn it on and off based on the demand of a zone. Example: Zone 1 is calling for Cooling TStat Temp is 75 Lower the cooling SP to 74 Zone 1 is done cooling TStat Temp is returned to default. There is a catch though, you can't read/write variables directly to the TStat. Instead you have to have a bunch of programs to set the variables up correctly. UD is working on an update that expands the ability to manipulate variables from the TStat. I would wait for that update to be released and see how it does for you. Otherwise go ahead and ask questions about the series of programs needed. My post history will have several examples.

I use a 5 minute window to do a setpoint adjustment when I then don't want to maintain that setpoint. This is not necessary, but if you had a brown out right before 9 am or there was some communication issues the 5 minute window could become handy. And yes, same day. You are correct, my safety program is based on temperature and not set point. You can adjust it to be based off set point as you mentioned. I chose temperature to base it off because I feel it will be better at grabbing more situations (although as you pointed out, a bit slower). An example is on a hot humid day in west texas (very dry all the time) the AC iced up. When we got home later in the day the house was nearing 90f even though the cooling set point was 75. This was before any automation, and this stuck out as a reason to use temp and not set points. One thing to note, is that I am not concerned about erroneous set points as I have had no problem with them. You have and are concerned about them. We can fuse the two together and it would look like this: If Status 'Thermostat- Main' > 85° (Temperature) Or Status 'Thermostat- Main' > 85° (Heat Setpoint) Or Status 'Thermostat- Main' > 85° (Cool Setpoint) Or Status 'Thermostat- Main' < 55° (Temperature) Or Status 'Thermostat- Main' < 55° (Heat Setpoint) Or Status 'Thermostat- Main' < 55° (Cool Setpoint) Then Set 'Thermostat- Main' 80° (Cool Setpoint) Set 'Thermostat- Main' 60° (Heat Setpoint) Send Notification to 'Liz and Brent' content 'House Out of Bounds' Else - No Actions - (To add one, press 'Action') And now, actually, I think I'll keep the more robust safety program that includes your set point suggestion.

Your first program requirements are very simple. Make your new program. Under if do a Schedule and make it From 9AM to 9:05AM Under Then do two actions, one for your heating and one for your cooling. It looks like: If From 9:00:00AM To 9:05:00AM (same day) Then Set 'Thermostat- Main' 60° (Heat Setpoint) Set 'Thermostat- Main' 85° (Cool Setpoint) Else - No Actions - (To add one, press 'Action') This will set your temp and then it will not care what happens until the same time the next day. You can adjust it at any time after this. I have not had the problem you describe, however I have had a problem in the past where I made a programming mistake that attempted to make the house as hot as possible. Luckily I had a program set up already to combat abnormal conditions. If Status 'Thermostat- Main' > 85° (Temperature) Or Status 'Thermostat- Main' < 55° (Temperature) Then Set 'Thermostat- Main' 80° (Cool Setpoint) Set 'Thermostat- Main' 60° (Heat Setpoint) Send Notification to 'Mom and Dad' content 'House Out of Bounds' Else - No Actions - (To add one, press 'Action') This program is rather basic, but what it does is monitor the T Stat temp, and if it exceeds what we consider as acceptable values it will adjust the heating / cooling setpoints and send us an email letting us know something is broke.

That is some list! A question is going to come down to value. An example are the 30+ wall outlets. Why do you need to automate 30+ wall outlets? I had thoughts of doing the same in our home, but I could not come up with a use for the majority of our outlets. So now I have a few indoor and a few outdoor plugin modules instead; and I always have 1 or 2 of them just hanging out in the garage. At the basic level, go over to smarthome.com and start a shoping list for insteon devices. For the ones you can not find check out Z-Wave. Then take a look at the forums here for some of the more complex examples, such as fireplace. I would also drop some of the oddities from your list. Automated garbage disposal and toilets?

I would also check out IOGuy's sub forum here under Automation Shack. He had the CAI board and changed over to the Raspbery PI. That is the reason that I did my temperature probes with the PI. You can see my guide (I think it has been linked here already) in my signature. As for the question on the 1 wire response time, if you hold the probe in your hand it goes from ambient to skin surface temperature in about 20-30 seconds. I find they react nicely to the air changes in our rooms. I have ~ 20 of them installed throughout the house, outside and HVAC system. They also make humidity detectors that I'll be placing in the bathroom and in the garden.

I believe these will work fine for you. They will keep restarting the timer if the temp is not stable, and when it is stable for 10-30 min then they will execute / notify / adjust the temps for you. This being an improvement over the notification from your OP where it was before the timer.

Your way is the correct way for your needs. My needs are a bit more, complex; and having the full support of variables makes it easier to accomplish what I do. Some examples: - If someone changes the setpoint on the TStat, such as turning it down when we have company or are doing a lot of house work, I have programs that gradually return the setpoint to normal. When it changes, every hour after I add 1 degree in the correct direction until it is back to the desired set point. - I have a zoning system with dampers. There are cases when I would like the AC or Heating on, even if the main thermostat temperature has not reached setpoint yet. In these cases the system will fake the needed setpoint on the TStat to get it to turn on the AC and then restore it to normal when the zoned system is done using the heating/cooling. - All of my scheduled temperatures are variables, and are used in several different programs. In this way seasonal changes to setpoints can be done dynamically and I do not have to edit the setpoints in any program. - The schedules themselves are dynamic in when they start; with the objective of reaching temperature at a certain time based on current house/attic temperature and a learned average time to reach setpoint that adjusts itself over time. - I have a fresh air supply that will also contribute to the system, and knowing the TStat temperature adds to the logic of when to bring in fresh air (such as, if outside air will assist bringing or keeping inside air in band, to reduce the use of the HVAC cooling unit).

As mentioned above, this works if you have done the back end stuff with ~ 100 programs to read / write variables to the ISY. The OP understandably does not want to do this.

Yes, you could write the threshold directly into the programs. I would recommend that one of them use the >= or <= on the chance you are at threshold when the program is to run.

My solution is going the opposite direction as yours. I created ~ 100 programs to read the TStat Temperature/Heating SP/Cooling SP into State/Integer variables and to write variables back into the TStat for the Heating SP / Cooling SP. Once that back end is set up, you would write your program as desired. Your daily setpoints would be variables instead. Your link into the weather module would modify these variables to +2 when below a threshold and back when above a threshold. I find the weather module to be a bit, unreliable. For this reason I have a temperature probe at my house that we use. ---------------------------------------------------------------------------------------- Back to your original question of minimizing programs, it really depends on if you want this to be dynamic or static. As in; when the temperature drops below threshold, do you want the temperature set point in the house to change at that time, or wait until the next scheduled temperature change? I don't think you should use the folders, as you most likely don't want to be caught in that nasty place where you are at threshold and fluctuating when it is time to change setpoint (what one if any, will it choose?). Instead of folders, I would write two programs that enable/disable your schedule programs. If Outside Temperature is < Threshold then Disable normal programs and Enable cold programs. If Outside Temperature is > Threshold + 5ish then Disable Cold Programs and Enable Normal Programs. Taking this one step further, if your schedule programs use the Time to Time parameter in the If Statement, your two controlling programs can have: Then Enable/Disable Then Run (If) Program Path for the Enabled Programs. In this way, if the temperature rises or falls in the middle of a program schedule, your ISY will adjust the setpoints before the next scheduled run time.

http://www.smarthome.com/sh-solutions-c ... elink.html Looks like it is HomeLink and an X10 bridge is the way to go.

Hello; On my Wife's Kia Sorento; there is 3 buttons used for garage door openers (they are learning RF transmitters). Is there an insteon device capable of receiving these signals?

There are lots of things you can do in excel, but I would need you to upload the actual files, unedited. The screenshots do not import so well ; ).

Eric; I just fired mine up to see, and it looks rather simple to me. I also don't have a bunch of devices on there though. Could you upload your HTML file and I'll take a quick look at it. Also expand on your simple device list thoughts for what you would like to actually see (I'm assuming you want to see Name/Address/Type).

They have said they will add support for the Z Wave Power Monitoring. Once this is in, you will be able to connect a Z Wave Power Monitor to the AC Output of your Inverter and have this fed into ISY. I will be putting in our solar system here in the next month or so and will let you know what we ultimately set up. The Z Wave support will really open the door here though. The Z Wave power modules can be connected at several load points to both control the load and monitor its consumption.

The solutions in this thread provide you an answer for this problem, but I would like to offer a third solution that you may find useful in other situations. I handle flow control through the liberal use of variables. I will apply this to your situation (only mine will be Xmas Lights). The basis of this 'rule' I follow is defining Variables as both States and Integers. - A state will trigger an If statement when it changes, where an Integer will not. For each of my switches and other variables (such as temperatures and setpoints) I define: If Status 'Xmas_Lights' is On Then $Xmas_Lights_Integer = 1 $Xmas_Lights_State = 1 $Xmas_Lights_Integer Init To 1 $Xmas_Lights_State Init To 1 Else $Xmas_Lights_Integer = 0 $Xmas_Lights_State = 0 $Xmas_Lights_Integer Init To 0 $Xmas_Lights_State Init To 0 If IR_01 is PRESSED Then $IR_01_Integer = 1 $IR_01_State = 1 $IR_01_Integer Init To 1 $IR_01_State Init To 1 Else $IR_01_Integer = 0 $IR_01_State = 0 $IR_01_Integer Init To 0 $IR_01_State Init To 0 In this way, I know the status of this switch, and on reboot of the ISY the position (Init To) will be remembered. With the rule followed, you would write your program as you wanted: If $IR_01_State is 1 And $Xmas_Lights_Integer is 0 Then Set 'Xmas_Lights' On Else Set 'Xmas_Lights' Off This accomplishes what the examples above did, with an extra program and 4 extra variables. So why would I do this instead? Once done, it really adds to the flexibility of your programing. In every future program you have, you may now reference the status of any button / light as a state or an integer. Take the below program called 'Equalize' as an example. Every Temperature in it is an Integer. I would like to keep my whole house fan running when any individual room is above my Heating/Cooling Setpoint. I also have a $SP_Fan_State that is set based on our fan override button. When we press this, I want the fan on (separately, it will go back to 0 an hour later). If ( $Temperature_KhloeRoom > $SP_Cooling Or $Temperature_KhloeRoom < $SP_Heating Or $Temperature_Living_Room > $SP_Cooling Or $Temperature_Living_Room < $SP_Heating Or $Temperature_Office > $SP_Cooling Or $Temperature_Office < $SP_Heating Or $SP_Fan_State is 1 ) And Status 'Thermostat- Main' is not Calling for Heat And Status 'Thermostat- Main' is not Calling for Cool Then Set 'Thermostat- Main' Fan On Wait 10 minutes Run Program 'Equalize' (If) Else Set 'Thermostat- Main' Fan Auto Wait 10 minutes Run Program 'Equalize' (If) Here you can see, that the only things that will run this program is that $SP_Fan; and if my Heating/Cooling kick on. The program self loops by calling itself every 10 minutes. In this way, a false condition on a temperature will not cause the Fan to go back to auto. It must first wait out its 10 minute timer and then check the temperatures. Bah, Pizza is done! As mentioned, in programming there are several ways to skin the cat; above is another way that may make it easier in the future if you went very complex with your programs (short/long press, double taps, ectra).