apostolakisl

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.

What stusviews says is spot on. My assumption would be that you have 4 insulated wires entering the box above the fan and possibly some bare ground wires. These are likely arranged as one black and one white in each of 2 jackets. The one pair of wires is going to your circuit breaker and the other pair is going to your switch. It is irrelevant for this wiring scheme which is which. The re-wire would involve Shut off the breaker In the box above the fan: 1) Splice the two house wire whites, the white from the fan, and the white from the fanlinc together. (In other words, every single white wire gets spliced together) 2) Splice the two house wire blacks and the black from the fanlinc together.(in other words, all the black wires EXCEPT the ones connected to the light/fan itself) 3) Splice the red fanlinc to the black from the fan that powers the light part (hopefully there is a label on it, if not you'll need test things out) 4) Splice the blue fanlinc wire to the other black wire on the fan that powers the fan part. In the box at the switch 1) Splice the house black to the KPL Black 2) Splice the house white to the KPL white 3) Cap the red KPL wire Hopefully you also have bare ground wires at each box, any and all of these get spliced together with the green wire on the fan. In summary, EXCEPT for the two black wires connected to the fan, all white wires get splice together, all black wires get spliced together, and all green/bare wires get spliced at both boxes. Turn the breaker back on, join your fanlinc and kpl to scenes so you can control it all.

The program I wrote above would do just that. You would need to also have your variables do an "init" in the last line of the previous program so they survive a power outage and finally you would need to send the email with the max value at midnight followed by a set of the variables to current values so it can keep track of it for that day. Add to end of then clause of above program i$maxtemp init to $maxtemp $maxtempstamp init to $maxtempstamp If time is midnight (or whatever time you want, realizing that you will get the max temp for the previous 24 hour period) Then notify . . . (have it send the value and the time stamp) run then clause of program from previous post So doing exactly what I just showed above would give you one email per day at midnight that includes the highest value that the temp achieved for the previous 24 hours including a time and date stamp. The date part of the time stamp is perhaps unnecessary since you will know the date from the email, but whatever. Certainly posting the info to a database is a fine idea and would let you graph it and do all kinds of analysis. But if all you want is the max or min value for the previous 24 hours, this is going to be easier then setting up a database and will require no additional hardware.

It appears that you have 1) 2 black wires coming off of the fan. One would be for the fan and the other for the light. They are spliced which means you can't turn them on separately. 2) A black and a white coming from the box which we can't see. The white wire would be neutral as it is connected to the neutral wire on the fan and the black would be hot, probably coming from a switchloop You say both wires are "hot" at the switch. This isn't likely as it makes no sense electrically. Probably one is hot and the other goes to the fan. They would only both be "hot" if connected to the switch and the switch were turned on. Basically, the typical arrangement is that power 1) enters the box above the fan via a black wire 2) That black wire is connected to one wire of a pair that is sending the hot to the switch 3) The other wire of the pair is bringing the hot back from the switch (when the switch is on) 4) That other wire bringing power back from the switch connects to the black wires entering the fan 5) The white wire coming from the fan is where power exits the fan and connects to the house neutral (white wire) closing the electrical path You have a green wire which is connected to nothing. That is a ground wire and should be connected to ground to prevent fire or electrical shock in the event that something goes amiss in the fan. If no ground exists (certainly possible in an old house), you might ask an electrician what is best to do, either leave it unused or connect to the neutral, not sure which is best. You can connect the pair of wires going to the switch to the hot and neutral from the house panel and that will give you power for an insteon kpl switch. You will then need a second insteon fanlink at the fan itself and then you can link those two switches to control the fan and .lights separately.

5.0 has the ability to assign a variable the current time and date directly from the ISY clock/calendar, so that avoids all the programs that do that. But you would still need to assign a series of variables to store the max value and the time stamp for it. Basically the last program I wrote. IF $maxtemp is less than $currenttemp and trigger 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 None of this would tax ISY at all. This would run in a split second only when your trigger hits.

The last program does minutes. You would use a variable to keep track of the max/min of the value and then compare the current value to that. If the value exceeds it, then you write to another variable that is the time stamp. loosely written example not exactly following ISY language. If $maxtemp is less than $currenttemp and whatever trigger you want Then $maxtemp = $currenttemp $maxtempdatetimestamp = $currentyear*100000000 + $currentmonth * 1000000 +$currentday * 10000 + $currenthour * 100 +$currentminute Of course you can't do the math exactly like that in ISY, but you can do that math just using a working variable and a bunch of extra lines, I just don't have the desire to write it that way right now.

It can be done using my programs for date and time variables. The day/date programs are on the wiki, and below is a minute/hour set of programs. =================================================================================== Hour Minute - [ID 0103][Parent 004D] Folder Conditions for 'Hour Minute' If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Allow the programs in this folder to run. ----------------------------------------------------------------------------------- Hour of Day 0 - [ID 00FC][Parent 0103] If Time is 12:00:00AM Then $iHour.of.Day = 0 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 01 - [ID 0102][Parent 0103] If Time is 1:00:00AM Then $iHour.of.Day = 1 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 02 - [ID 0101][Parent 0103] If Time is 2:00:00AM Then $iHour.of.Day = 2 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 03 - [ID 0100][Parent 0103] If Time is 3:00:00AM Then $iHour.of.Day = 3 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 04 - [ID 00FF][Parent 0103] If Time is 4:00:00AM Then $iHour.of.Day = 4 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 05 - [ID 00FE][Parent 0103] If Time is 5:00:00AM Then $iHour.of.Day = 5 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 06 - [ID 0104][Parent 0103] If Time is 6:00:00AM Then $iHour.of.Day = 6 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 07 - [ID 0105][Parent 0103] If Time is 7:00:00AM Then $iHour.of.Day = 7 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 08 - [ID 0106][Parent 0103] If Time is 8:00:00AM Then $iHour.of.Day = 8 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 09 - [ID 0107][Parent 0103] If Time is 9:00:00AM Then $iHour.of.Day = 9 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 10 - [ID 0108][Parent 0103] If Time is 10:00:00AM Then $iHour.of.Day = 10 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 11 - [ID 010A][Parent 0103] If Time is 11:00:00AM Then $iHour.of.Day = 11 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 12 - [ID 0109][Parent 0103] If Time is 12:00:00PM Then $iHour.of.Day = 12 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 13 - [ID 010B][Parent 0103] If Time is 1:00:00PM Then $iHour.of.Day = 13 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 14 - [ID 010C][Parent 0103] If Time is 2:00:00PM Then $iHour.of.Day = 14 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 15 - [ID 010D][Parent 0103] If Time is 3:00:00PM Then $iHour.of.Day = 15 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 16 - [ID 010E][Parent 0103] If Time is 4:00:00PM Then $iHour.of.Day = 16 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 17 - [ID 0110][Parent 0103] If Time is 5:00:00PM Then $iHour.of.Day = 17 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 18 - [ID 010F][Parent 0103] If Time is 6:00:00PM Then $iHour.of.Day = 18 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 19 - [ID 0112][Parent 0103] If Time is 7:00:00PM Then $iHour.of.Day = 19 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 20 - [ID 0111][Parent 0103] If Time is 8:00:00PM Then $iHour.of.Day = 20 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 21 - [ID 0113][Parent 0103] If Time is 9:00:00PM Then $iHour.of.Day = 21 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 22 - [ID 0114][Parent 0103] If Time is 10:00:00PM Then $iHour.of.Day = 22 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Hour of Day 23 - [ID 0115][Parent 0103] If Time is 11:00:00PM Then $iHour.of.Day = 23 $iMinute.of.Hour = 0 Run Program 'Minute of Hour' (Then Path) Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Minute of Hour - [ID 00FD][Parent 0103][Run At Startup] If $iMinute.of.Hour < 0 Then $sMinute = $iMinute.of.Hour $sHour = $iHour.of.Day $iHour.of.Day Init To $iHour.of.Day $iMinute.of.Hour Init To $iMinute.of.Hour Wait 1 minute Repeat Every 1 minute $iMinute.of.Hour += 1 $sMinute = $iMinute.of.Hour $iMinute.of.Hour Init To $iMinute.of.Hour Else $iMinute.of.Hour += 1 Run Program 'Minute of Hour' (Then Path)

Sadly you missed the boat on your dead devices. This was a known flaw and Insteon extended the warranty on all of those switches to 7 years. I sent every single one back and got new ones about 5 years ago. No problems since, except the PLM had issues, which we all know how to fix now (bad capacitors). If you are the original purchaser of those devices and bought from Smarthome, there might be an outside chance you could convince them to replace on warranty explaining that you didn't know.

Be aware that that program will send you a new email every time the temp changes and it is above 99. So if your x minutes is 15, you will get a notification every 15 minutes potentially. You might consider using 2 programs. The first program disables itself once it sends notification, and the second program re-enables the first program once the temp drops down again. In this example I built in a hysteresis of 2 degrees. Program 1 If $stemp>=100 then send notification of temp above 100 disable program 1 Program 2 If $stemp <=98 then enable program 1

I had requested a system variable "epoch time" in the next version of 5.x firmware and it seems as though Michel said OK to that. Epoch time would become your minute counter, just divide by 60 since epoch time is in seconds. Epoch time is a continuous second counter since 1/1/1970 midnight UTC. So you will never have a duplicate value regardless of time zone or DST. This would not be a program trigger however, so if you need your minute counter to trigger a program, then you will need to make other arrangements. But if you have a program that simply needs to check the current minutes when something else triggers it, then this is perfect. In the mean time, this gives you epoch time. Again, divide by 60 to get epoch time in minutes. This only works in 5.0 firmware. And also, it is affected by time zone and dst, so you'll get repeat minutes or skipped minutes when dst turn on/off. New Program - [ID 014C][Parent 014B] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $total_day = [Current Year ] $total_day -= 1901 $total_day *= 365.25 $total_day += 366 $total_day += [Current Day of Year] $Epoch = $total_day $Epoch -= 25569 $Epoch *= 86400 $Epoch += [Seconds since start of day] Else - No Actions - (To add one, press 'Action')

Hysteresis is the shape of the output curve over time based on the input state. In this situation, the output "curve" is binary, on or off.. What you need to know is at what point the input will shift the output from on to off or off to on. It is how far across the threshold you have to go to move from one state to the other. So a threshold of 10 watts and a hysteresis of 1 watt would look for 11 watts to switch from off to on and 9 watts to go the other way. If someone has more detailed knowledge of Insteon's definition of hysteresis, please let me know. EDIT: This is from wikipedia describing a thermostat switch, but the same applies here. "Hysteresis can be used to filter signals so that the output reacts more slowly than it otherwise would, by taking recent history into account. For example, a thermostat controlling a heater may turn the heater on when the temperature drops below A degrees, but not turn it off until the temperature rises above B degrees (e.g., if one wishes to maintain a temperature of 20 °C, then one might set the thermostat to turn the furnace on when the temperature drops below 18 °C, and turn it off when the temperature exceeds 22 °C). This thermostat has hysteresis. Thus the on/off output of the thermostat to the heater when the temperature is between A and B depends on the history of the temperature. This prevents rapid switching on and off as the temperature drifts around the set point. The thermostat is a system; the input is the temperature, and the output is the furnace state. The furnace is either off or on, with nothing in between. If the temperature is 21 °C, it is not possible to determine whether the furnace is on or off without knowing the history of the temperature. Similarly, a pressure switch can be designed to exhibit hysteresis, with pressure setpoints substituted for temperature thresholds." I'm just not positive if the hysteresis value means what I said above. In other words, does 10 watts threshold, 1 watt hysteresis mean 9 and 11 are the triggers, or 9.5 and 10.5?

I wouldn't be surprised if this fix doesn't make a more robust unit than anything coming from the smarthome factory.

That would work well. It would be sort of like Elk where the first line of a "rule" is the trigger and all other lines are conditions that are only tested after the first line triggers it. But what you are doing is allowing the "first line" to be as many lines as you like. Although my plan would not alter backward compatibility. When you first install the new firmware, all of your current lines of programs would default to having the "trigger box" checked. So functionality would be unchanged. And as you write new programs, the default would be to have the box checked, so someone who didn't notice the firmware update would keep going about their merry way with unchanged functionality.

This issue is part of an ongoing discussion and strikes new users all the time. The issue is "unintended triggers". I have advocated for a checkbox next to each line of the "if" clause that allows you to activate or de-activate it as a trigger. In this program, you would de-activate the time conditions as triggers. It is the same concept as state and integer variables. In fact, you could eliminate integer variables if you had this feature since a de-activated state variable is a de-facto integer variable.

I would hope that the OP would easily and instantly recognize that the receptacle/plug is not a standard NEMA 5-15 or 5-20 as the 240v style receptacles are quite obviously different. Unless some yahoo decided to wire up a 120v receptacle to 240v, and decided to wire a 120 plug to the 240v terminals on the pump, there is no risk of making a mistake here. If you wanted to be 100% sure, then check the panel and see what voltage breaker shuts off the pump. If indeed the pump has a 240v option, I don't see any reason to mess with it. You are only talking 7 amps at 120v, well within even the most wimpy of 15 amp receptacles. And going with 240v would mean no synchrolinc option and no outdoor on/off switch available. The only possible reason to switch to 240 is if there is a long run of wire. It's too bad that the outdoor on/off switch doesn't have "sense", it would eliminate the need for the synchrolinc.

Yes it does. 220/240v outlets do not fit 110/120 plugs.

I don't see the complexity in this. If the pump is 110/120v pump and is at the amps you listed above, a synchrolinc will work fine as a notification system. The only issue I see you having is that you probably don't have a standard wall plug for the pump and that is what they synchrolinc uses. I'm guessing it is hardwired in. Wherever your pump draws it's power, you need a standard plug, so a little electrician work is necessary. The power comes from an outlet, into syncrholinc, out of synchrolinc, to your pressure switch, then to the pump. When current flows, synchrolinc turns on and broadcasts that it turned on. The PLM picks up the broadcast and notifies ISY. This triggers a program that you wrote in ISY. When the pump turns off, the syncrholinc broadcasts an "off" and a similar process occurs. Synchrolinc does not affect power to the pump, it only monitors current through it. If status syncholinc is on Then wait x minutes notification "pump on too long" Else --blank-- So if the synchrolinc doesn't shut off before x minutes, then the email is sent. Otherwise, the program gets aborted when the pump shuts off and prior to the wait ending.

The order is alphabetical and you can't change that. The order makes no difference, of course. The devices don't get activated sequentially. A scene is a single Insteon transmission from the controller (either the PLM (as controlled by ISY), or a device) which each device in the scene is programmed to recognize as a queue to do as programmed for that scene. So if you want them ordered differently for the sake of viewing them in the tree, you would need to change the names so that alphabetically they get into the order you like. Also, a scene in scene would unnecessarily add layers upon layers of confusion. If you want all the devices from one scene in a second scene, then you just put all those devices into your second scene. A scene command is a single message, so you can't have scenes nested inside of scenes. That is the whole point of a scene, to boil down a slew of device activities to a single broadcasted message. Only this way can the com keep up.

yes. You might instead phrase this as "ISY assumes it did"

You can always unplug the low voltage transformer and plug a non-noisy device in for testing, like a regular light bulb. Then do the "run thens" and see if it works.

Did you try doing a hard reset on the switch and re-programming it? If that doesn't work, then I am going to say you probably need a new switch.

Lee can chirp in here if he wants, but it is my understanding that the status change in the ISY register is created by ISY when a scene is executed, not by an ACK from the device. There is logic to this since a scene could have dozens or more objects and ACK's from all of them at the same time could overwhelm the com.

Scenes are only better at controlling 2 or more devices simultaneously. Creating a scene and putting one device in it will not work better than just controlling the device directly and in some ways will be worse (devices don't report back after scene commands). As mentioned, a scene works better with multiple devices because it is one command that all devices in the scene recognize. In other words, one Insteon command over the power line instead of 2 or more. So if your light show is flipping one light at a time, you should just control the device's directly. If 2 or more lights are meant to activate simultaneously, put those together in a scene.