apostolakisl

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.

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')