apostolakisl

Here is my program. I found 6 minutes did the trick. Washer Upstairs - [ID 00F8][Parent 00F7] If Control (Old) 'Upstairs Washer' is switched Off And Control (Old) 'Upstairs Washer' is not switched On And From 8:00:00AM To 8:25:00PM (same day) Then Wait 6 minutes Send Notification to 'ellen text' content 'Laundry Upstairs' Else - No Actions - (To add one, press 'Action')

Yes. Well I suppose you would put a bridge rectifier on it to get dc current. I have never tried this with an io linc. I did it just for kicks with my power drill as the current draw and I energized an electromagnet sufficiently to pick up a nut. I did it to teach my kids. I took a regular cheapo extension cord and split it down the middle. Then I used some bell wire and just wrapped it a bunch of times around the wire and then again a bunch of times around the bolt to make an electro magnet. A bunch of times was not that many, though. It wasn't like I spent more than 30 minutes on the project.

I use a synchrolinc on the washer and it took a bit of tweaking to account for the shutting down between cycles, but it works. I never tried hooking my 240 dryer up. You can actually make a current detector by splitting the insulation down the middle or otherwise separating the chords and then wrapping one conductor with another wire a bunch of times and hooking to an io linc. How many time to wrap the wire needs to be figured out.

By this line Control Dimmer Button is ON Do you actually mean Control 'Dimmer Button' is switched on Is "Dimmer Button" the name of the device that your refer to as "device" in all the other lines of code? And the other two lines in your and clause also? If indeed that is the case, then any action on that switch will trigger the program with off and fast off trigger the else clause. Keep in mind, that someone could dim down the switch all the way to off and your program will still run true, which I don't think is your intent.

I think cree's professional grade stuff is very good. The CR6 are great and I have a bunch of Cree troffers in my office that have all been great. However, the mass market low price stuff seems to be junk.

They still have both the new flow ones and the older ones at my HD. Just bought 2 of the older style to replace bad ones.

I have many (like maybe 100) Cree CR6 fixtures and have had no failures. About half of them are 6 years old and the other half are 2 years old. I have maybe 25 of the A19 bulbs and have had about 4 fail. These have all failed in less than 2 years. Clearly the A19 are not made to the same standard. HD requires that you mail them back to Cree. Not impressed.

Take screen shots and post them. One each of the main page with each of the two scenes highlighted in the left tree.

First confirm that the motion sensor is tripping. A program such as If Control motion sensor is switched on Then $testvariable = $testvariable + 1 With each trigger of the MS, the variable will increase by 1.

What are you wanting to happen? What you currently have is a button that each time you press it, it sends an "on". It will never shut off in non-toggle on mode. So no matter what, when you hit the button, it will run the "then" command of that program. Also Are you expecting to also use this button to turn all that stuff in the program off? If so, you would be better off creating a scene where the kpl button is a controller and all the other things are responders. The only caveat to that is the 1 minute delay on the last item. That would have to still be in the program. But all the other stuff would respond much quicker if it were a scene and not a program.

My understanding is that you want the light to turn on when you go into the bathroom, and then off when you leave the bathroom. This all can be done in one small program. I don't know what the purpose of enabling and disabling the second program above, this all seems redundant. But also, more importantly, no program is needed to do this at all. You can just make 2 scenes as I listed above. If Control 'Bathroom Big-Sensor' is switched On And Control 'Master Bed Motion-Sensor' is not switched On Then Set 'Bathroom Big Micro Dim' On Else Set 'Bathroom Big Micro Dim' Off This program has two triggers, which is motion at either of the 2 detectors. Both lines are true when motion is detected at the bath MS, and both lines are false when motion is detected at the Master BR MS. So motion at bath MS causes the "then" to run, and motion at the other causes the "else" to run.

Status in ISY is updated every time a device changes. If you have good com in your house, it will always be correct, or nearly so. The only approximation is if a dim command is received. So, no, status is not updated at any interval. Perhaps you have set your system to do a system wide query at 3 am or something, but other than that, status is only updated when a device is either told to change or reports that someone pushed its button. If your com is bad, and a ISY receives a message that a device was commanded off, but the device didn't get the same command, then ISY will think the device turned off even though it didn't, so it will be wrong. But again, this is all about the com, good com means all is synced. LeeG was correct to say you don't need a program at all to do what you are doing. 1) Set both motions to only send "on" commands 2) Make 2 scenes with the light as a responder in both scenes 3) Set the in bathroom MS as a controller in scene one, and the light as a responder to some on level more than 0%, like 50% or whatever you want. 4) Set the just outside the bathroom MS as a controller in scene 2, and the light as a responder with an on level of 0%. Be aware, that every time the MS just outside the bathroom is tripped, the light will turn off. So if like your wife was in there, and then you started heading that way, you would trip the second MS and shut the light off on your way in. Of course then once you got in there, you would trip it back on.

I think you are getting it. Yes, example a switch could be on, and you push the on button. It still sends out an on command. Or conversely, off. Here is a program I use a lot If device x is off and device x is switched off Then set device x to 20% At night, I can tap the off paddle of a switch that is already off (the bathroom light for example) and get the light to turn on dimly without having to push and hold to do a dim up. Also realize that "status" is a condition that is held in ISY's memory. Sometimes it is wrong if there was a missed communication. Control is always an event that comes from the switch. Of course a change in status comes from the device. A CHANGE in status will be a trigger event for the program. But if something else triggers the program, then the program references the status from ISY memory. EDIT: Also realize that a press and hold is a "dim" control command, not an "on" or "off". A switch can make several commands, on/off/fast on/fast off/dim up/dim down. These are all totally independent commands. for example, "control switched on" completely ignores a "fast on" event. EDIT More: you said "Then staus is the current state of the device, it doesn't really listen to the device message of my paddle got tapped?" Well, kind of. If the paddle was tapped, and that caused the state to change, then ISY will register a status change and any programs including "status of device" will react to that. This may be too much ifno for you, but mostly devices don't report their state (they will in certain situations). ISY assumes the state based on the control commands. ISY assumes that a control on resulted in the switch achieving the percentage on level it is set to. A "dim up" command is timed by ISY and it assumes it reached the status according to the rate at which the switch dims. Like if it takes 5 seconds to go from off to on, and it started at 20%, and it recorded a 1 second dim up command, then it assumes 40% . You can try this, you will see ISY thinks a swtich is at say 40% after a dim up, then hit "query" and the device will respond with its actual percentage, it might be a little different, like 42%.

is NOT - - - - the NOT is there to drive the opposite clause. That is it. Pretend the not isn't there, read the line of code and decide what it will do. Then, realize it will do the opposite when you add the NOT. In the above example you want one thing to happen when you push the motion detector sends an on command, and something different when it sends an off. You could write 2 programs and only use the "then" clause, or write one program and use both clauses. Realize how insteon works, when you push "on" or "off" or push and hold to get a "dim up" or "dim down", a power line command is produced. A program including one of those commands will respond. But it will not respond to any other command from that switch. Status of the switch is irrelevant. examples If control swithced on This ONLY responds when someone pushes the "on" paddle. Nothing else has any affect on this program. If control switched on and time is 6am This is a useless program. It would require that someone pushes the on paddle EXACTLY at 6am to be true (pretty much impossible). So effectively it would be false every day at 6am when it triggers, and every time someone hits the on paddle.

I got this far and see that this is wrong. Status has nothing to do with control. Control means that an Insteon message was initiated by that device. For a switch that means someone pushed it, for a motion detector, it means something moved in front of it. Control switched on *************this drives the "then" clause when an on event occur (clicking the on paddle for a switch or motion occurs in front of a motion detector) and control not switch off ************* this drives the "else" clause when an off event occurs (clicking off paddle or after a time out for a motion detector) switched on and not switched off has nothing to do with percentage. If you have programmed your switch to turn on to 50% when you click on the on paddle, it doesn't matter, it still is "control switched on" when you push the on paddle. In short, the above two lines together have the purpose of using one program to get both a pressing of the on button and a pressing of the off button to do 2 different things.

It is only a member of one scene and already documented above. Yes, thank you for confirming that I am not crazy in thinking the membership tree used to exist on all devices.

Right click on the old switch name in the left tree (not the scene), "delete" should be there, it is not, then "remove from folder" will be there. If it is in a folder, click on remove from folder. After it is out of the folder then right click on it and click "delete". Now it is gone. ISY will remove it from the scene and reprogram the other switches automatically. If you have the ISY pro version you may have to right click and then click the "write to devices" button as the pro model lets you do all kinds of changes and delay the writing. Then right click on the new switch and click "add to scene" and click the name of the scene (link:main.mbath.shwer/fan) when it gives you option for responder or controller, click controller. Again, if you have pro version and it is in delayed mode, then you will need to right click "write to devices", or toggle off the delayed writing mode in the top menu bar.

First move the switch out of any folders it is in to the primary folder. Then right click on it and click "delete". That will remove if from all scenes. Then add the new switch into those scenes. So if a KPL button is controlling the switch, you would have a scene that both the KPL button and your new switch are both members of. If it is working as a "3-way" then both the KPL and the new switch would be set as controllers.

The replace with command will only work on the same type of switch. So yes, you would need to go through and replace it in the scenes. I don't suspect that this should be such a big deal, however. ISY makes it pretty easy to add or remove a device from scenes. So unless it is in a huge number it should only take a couple minutes. And you can quickly see all the scenes the old switch is in by clicking on it and seeing it in the tree. EDIT: OK, Am I crazy or did the "membership" tree go away? I am only getting it with with my KPL's and X10 devices, I could swear it used to show up with all devices.

You could also use a ceramic resistor which would not making any light (if you don't want light that would be good) and it would realistically never burn out in this application. You just need to get the ohms right using V=IR and make sure it is high enough wattage rating (P=IV) You can use a multimeter to measure the actual amps and volts on the current chime and match that.

This sounds like the best idea. Using an alternate load and an IO linc to switch between them. And just to really be sure everything likes the load, use the proper chime device for both loads, but do something to the speaker on the "quiet" one so that it makes little or no noise.

Yeah, didn't count the digits. You would need to truncate the year to 2 digits. So today at 2:45 pm would be 1,508,221,445 Or you could just use separate variables for year, month, day, time instead of packing them into a single variable. $maxtempstampyear = [current year] $maxtetmpstampmonth = [current month] etc $maxtempstampyear init to $maxtempstampyear etc $maxtempstamp = [Year] (this option is available in 5.0) $maxtempstamp = $maxtempstamp - 2000 *****add this line $maxtempstamp = $maxtempstamp * 100000000 $maxtempstampworkingvariable = [month]

1) Variable values can be displayed in emails. It is all in the configurations:emails/notifications:customizations tab 2) yes, it will show whatever the current value of the variable is. Presumably you would do something in your email like "Today set a new record for highest temp ever. It was $maxtemp F at $maxtempstamp" The date would show as 201508211553 for example as I wrote it. You could keep it all as separate variables and have it all written out nice and grammatically correct if that bothered you, but it would mean a bunch of extra of extra variables. Your choice. You would add the "send notification" line to the end of the above program. Then you would only get an email whenever the record was broken.

I think he said this stuff was 60 years old. In 1950 there was no such thing as a plastic box so that in and of itself doesn't tell you much. But I don't doubt that 1950's wiring to what would have been an incandescent fixture would lack a ground. Wiring it wrong could result in 1) shorting hot to ground/neutral and blowing the breaker/fuse 2) having it just not work, but otherwise not do anything harmful 3) energize the chassis of the fan and potentially result in a shock or fire. This would require that you connected a hot to something electrically connected to the fan chassis, like the green wire or the mounting apparatus. Or, if the something happened to the fan internally it could short to the chassis (the main reason a ground wire exists). Currently the ground wire on the fan is going to nothing (probably because no ground exists), which leads to risk of an energized fan chassis failing to blow the breaker/fuse and a risk of shock or outside chance of fire if some alternative path to ground existed that was just enough resistance to keep the amps below the fuse/breaker but still heat it up. That is unlikely but possible. The house I lived in in college actually caught fire for that reason. . . the day before finals. We were talking 1920's wiring in that case. I have seen where the neutral was also used as ground, but this also poses some risk. If some other load is daisy chained to this load, the neutral could become hot if a disconnect occurred in the neutral closer to the panel and the device further downstream were in the on position. My understanding is that if no ground exists, that you just screw the ground wire to the mounting bracket of the fan, which doesn't actually ground it but whatever. If no ground exists, you either live with that risk or you spend a ton of money and rewire the house.

OK, I guess you are saying that you want ISY to keep looking for the highest value of temp or whatever . .. forever. Not in any given block of time, just since the date of inception of the program. This is easier than above. Get rid of the second program and only keep this one. IF $maxtemp is less than $currenttemp and trigger (if $currenttemp is a state variable then that will serve as your trigger every time it changes) THEN $maxtemp = $currenttemp $maxtempstamp = [Year] (this option is available in 5.0) $maxtempstamp = $maxtempstamp * 100000000 $maxtempstampworkingvariable = [month] $maxtempstampworkingvariable = $maxtempstampworkingvariable * 1000000 $maxtempstamp = $maxtempstamp + $maxtempstampworkingvariable $maxtempstampworkingvariable = [day of month] $maxtempstampworkingvariable = $maxtempstampworkingvariable * 10000 $maxtempstamp = $maxtempstamp + $maxtempstampworkingvariable etc for hour and minute $maxtemp init to $maxtemp $maxtempstamp init to $maxtempstamp just by adding the "init to" lines your value will not be lost during a reboot.