apostolakisl

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.

Try manually doing a "run then" on your first two programs. Does the light turn on, but not turn off? Any time a device turns on by Insteon command, but fails to turn off, there is a good chance that the device itself is a source of power line noise. Try putting a filter between the Insteon switch and the device (low voltage transformer). Of course it is also possible that at the time you specified to turn the light off, that something else in your network is making noise. If it works fine in your "run then" tests but then at your sunset plus time it doesn't, this would point to something else as the source of noise.

The PIR's on my alarm system trigger on clouds and stuff too. I had to disable them because of so many false alarms.

Typically IP cameras have the motion detection built into them. You really don't need to use an Insteon motion detector. Even if you camera doesn't have that as part of the firmware, there are applications that monitor the cameras that will do it. Purchase one program and it can monitor dozens of cameras, rather than purchasing dozens of insteon motion detectors.

I was just looking over the 5.0 firmware stuff. I think this sort of camera control would best be accomplished using the new node server in 5.x. The node could then be implemented into programs giving ISY full control of the camera and having the ability to respond to various states the camera may be in. I don't see any chance that ISY will be able to directly email a snapshot, but it certainly could instruct the camera to do so, assuming the camera has a published API. I would love to see someone write the node server for foscam since I have a bunch of them.

Here is a link to the foscam CGI commands. http://www.ipcamcontrol.net/files/Foscam%20IPCamera%20CGI%20User%20Guide-V1.0.4.pdf I think it includes just about everything and perhaps then some. ISY should be able to execute those commands via the network module. Of course the camera can not send any commands to ISY. Not sure about this, but perhaps the 5.0 firmware would let a camera response cause a variable to be set? Probably not, but 5.0 is allowing a lot of things to set variables so perhaps a network module reply as well.

Typically those features would be built into the camera's firmware. For foscam they are. The only thing is that you would want ISY to turn the feature on and off. With foscam you can send REST commands to the camera which ISY network module should be able to do (I haven't done it but I am pretty sure others have). But as far as emailing the image, ISY can't do that. The foscam units will do that or you can run a dedicated camera monitoring application on your computer and it can do all the motion detection, emailing, etc. I don't now how you could have ISY tell an application running on a computer to turn the features on and off though. The software would need to be controllable via scripts and you would need to set up some software that receives ISY commands and triggers the scripts.

Still, though, it has to be a trigger. If the variable were an integer variable, then it could change, the "if" would in fact be false, but the program would continue to run through the waits and repeats. Once engaged in an "atomic" section, that section will finish no matter what, but breaks points such as wait and repeat will allow trigger events to start the program over and from there it could be true again, or false. If it stays true, the program will start over from scratch after a trigger event. For example, if your if statement said If time is 6am or time is 6:00:10 am Then wait 5 seconds do stuff wait 10 seconds do more stuff The program will start over at 6:00:10 and the "do stuff" part will run twice, but the "do more stuff" part will only happen on the second round. EDIT: To further illustrate If time is 6am or (time is 6:00:10 am and something else that is false) Then wait 5 seconds do stuff wait 10 seconds do more stuff This program will trigger at 6 and at 6:00:10. The second trigger will be false. So, the result will be "do stuff" happens once, "do more stuff" never happens. In short, "if" clauses only evaluate on triggers. Whether the contents are true or false is basically irrelevant without a trigger. A program is true if the last run was a "then" and false if the last run was an "else". The only way a "then" or "else" happens is if there is a trigger. This is true whether it is a "wait", a "repeat", or if it is a program without those items. An "if" sections current state of being "true" or "false" outside of a trigger really isn't relevant to any ISY program. The only relevant state of a program is what it was at the time of the last trigger. A wait or repeat simply open up the possibility that a trigger can occur, it is not a trigger itself and if no trigger exists, then the "if" clause status state is irrelevant as far as the continued execution of the "then/else" containing a "wait/repeat".

When you say "What this means is that if a program's Then clause changes a condition which causes the program's overall condition to become false (or if the program's Else clause changes a condition which causes the program's overall condition to become true), the current atomic statement group will complete, and at that point execution will transfer from the Then clause (or the Elseclause) to the Else clause (or the Then clause)."" The above statement needs some clarification. Just because the conditions in the "if" changed, that does not mean the program will re-eval at a wait/repeat. The change in the "if" must have also been a trigger. So "6am" is no longer true after a wait, but the program will keep going because there was no trigger (times are only triggers at the stated time). The variable on the other hand as I understand is a state variable, so if it changes, the "if" triggers and a wait/repeat will terminate the program and run the "else".