kclenden

Sure it's Daylight Saving time, but after several years they add up to become plural. ? My only excuse is that I wrote my post at 1:45am which was really 2:45 am.

As ISY users eventually discover, any programs that are running timers (e.g. WAIT) stop executing when the time on the ISY either springs forward or falls back because of Daylight Savings TIme. If those programs happen to loop so that they are long running programs serving a specific function like listening for a heartbeat from a device then they likely won't start running again until your ISY reboots or you open the Admin Console and restart them. So I decided to try using a variable to detect a change in time caused by DST and have the ISY alert me when DST occurs and have it automatically restart my long running programs. I wrote my programs several month ago and then sort of forgot about them until 1:05am today when I got an alert from the ISY that a DST change had occurred. That's probably the longest I've waited to see if a program actually works. The idea is to have a variable count the hours from 12am to 3am and detect if the progression is the normal 0...1...2...3. If it goes 0...1...1 then I know that fall back has happened. If it goes 0...1...3 then I know spring forward has happened. Here are the programs: =================================================================================== Day Lights Savings - [ID 00BE][Parent 0001] Folder Conditions for 'Day Lights Savings' If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Allow the programs in this folder to run. ----------------------------------------------------------------------------------- DST_Alert - [ID 00C1][Parent 00BE] If $sDST_Alert is $cTrue Then // Wait a couple seconds because later we're changing the state // variable that kicks off this program Wait 5 seconds // Restart programs that would have been killed by DST change Run Program 'Outside Lights - Random Brightness' (If) Run Program 'GarageDoorSensor-Control 2' (Then Path) // Assumes Uptime program was killed by DST change before $iISY_Uptime_Counter was incremented $iISY_Uptime_Counter += 1 $iISY_Uptime_Counter Init To $iISY_Uptime_Counter Run Program 'ISY Uptime' (Else Path) Send Notification to 'Text_KBC' content 'Day Lights Savings Time Alert' $sDST_Alert = $cFalse Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- DST_Check_0 - [ID 00BA][Parent 00BE] If Time is 12:05:00AM Then // Need to initialize $iDST_Hour_Check so that the check at 1:05 knows // whether it's running after the 12:05 check or a second time in a row // because of "Fall Back" $iDST_Hour_Check = 0 Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- DST_Check_1 - [ID 00BB][Parent 00BE] If Time is 1:05:00AM And $iDST_Hour_Check is 1 Then // $iDST_Hour_Check should have been set to 0 at 12:05AM. The only way // for it to be 1 now is if 1:05AM happened and then happened again. // This should only occur during "Fall Back" when DST is changed from ON // to OFF and the clock goes from 2:00AM to 1:00AM $sDST_Alert = $cTrue $iDST_Hour_Check = 1 Else $iDST_Hour_Check = 1 ----------------------------------------------------------------------------------- DST_Check_2 - [ID 00BD][Parent 00BE] If Time is 2:05:00AM Then // Need to update $iDST_Hour_Check so that the check at 3:05 knows // whether it's running after the 2:05 check or after the 1:05 check // because of "Spring Forward" $iDST_Hour_Check = 2 Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- DST_Check_3 - [ID 00BC][Parent 00BE] If Time is 3:05:00AM And $iDST_Hour_Check is 1 Then // $iDST_Hour_Check should have been set to 2 at 2:05AM. The only way // for it to be 1 now is if 2:05AM never happened. This should only // occur during "Spring Forward" when DST is changed from OFF to ON // and the clock goes from 2:00AM to 3:00AM $sDST_Alert = $cTrue $iDST_Hour_Check = 3 Else $iDST_Hour_Check = 3 ----------------------------------------------------------------------------------- DST_Init_0 - [ID 00BF][Parent 00BE][Not Enabled][Run At Startup] If From 12:05:00AM To 1:04:59AM (same day) Then // This program should only run when the ISY starts up, either because // of a reboot or a power outage. It initializes $iDST_Hour_Check so // that we can detect a Day Lights Savings Time change // // The program should be disabled but set to Run at Startup $iDST_Hour_Check = 0 Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- DST_Init_1 - [ID 00C0][Parent 00BE][Not Enabled][Run At Startup] If From 1:05:00AM To 2:04:59AM (same day) Then // This program should only run when the ISY starts up, either because // of a reboot or a power outage. It initializes $iDST_Hour_Check so // that we can detect a Day Lights Savings Time change // // The program should be disabled but set to Run at Startup $iDST_Hour_Check = 1 Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- DST_Init_2 - [ID 00C2][Parent 00BE][Not Enabled][Run At Startup] If From 2:05:00AM To 3:04:59AM (same day) Then // This program should only run when the ISY starts up, either because // of a reboot or a power outage. It initializes $iDST_Hour_Check so // that we can detect a Day Lights Savings Time change // // The program should be disabled but set to Run at Startup $iDST_Hour_Check = 2 Else - No Actions - (To add one, press 'Action')

Unfortunately I don't have any particular source to point at to help understanding events. Most of what I know comes from watching things happening in the Event Viewer and then tracing it back to what was happening at the time. For example the [ Time] tag. There seem to be a lot of things that can cause it to appear in the Event Viewer including: In the AC Saving a program Running a program While the ISY is running A program calls another program Time is ... passes (whether based on exact time, sunset/sunrise, or Last Run of a program)* When the start time of a "From ... To ..." passes * When the end time of a "From ... To ..." passes * * - Even if a program is disabled directly, or via a folder condition, and unable to run, a [ Time] tag will appear in the Event Viewer when the start or end time passes I've seen multiple [ Time] tags appear in a row, but generally they're related to either saving program, in which case I see four in a row, or the start/end time of a FROM statement in a disabled program passing in which case it seems to be somewhat random how many [ Time] tags I see. I've seen as many as 38 appear in a row related to a single disabled program with a FROM statement, but usually it's more like 10-20. Another odd thing about the [ Time] tag is the 0(0) that appears at the end. Sometimes it's not 0(0) but x(0) where the x represents the number of days my ISY has been running, like tonight where I'm seeing 86(0) and indeed my ISY has been running 86 days since it was last rebooted.

Line #1 - The ISY has passed a message to the PLM [02 62]. The message is intended for device 12.A0.4E. The message flags indicate a direct message (i.e. not a group message) that is allowed a maximum of 3 hops [0F]. The message contains an ON command [11] to Level 44% [70]. I calculated the level by hex 70/FF = 112/255. Line #2 - A program has started Line #3 - The PLM acknowledges to the ISY that it received the message and sent it Line #4 - Device 12.A0.4E acknowledges that it has received the command to turn ON at Level 44% Line #5 - The ISY translates the message received on Line #4 into easier to understand text Line # 6 . . . loop repeats My interpretation of the log is that you a have program (or programs) that do two things every second: Turn on 'Hall - foyer / Front Lites' to 44% Call a program Could be a program that: Turns on 'Hall - foyer / Front Lites' to 44% WAITS 0 Seconds (seems wrong but the ISY waits 1 second longer than specified) Calls itself Could be two programs that: Prog_1: Repeats while (some condition that never changes) Calls Prog_2 Waits 0 Seconds Prog_2: Turns on 'Hall - foyer / Front Lites' to 44% Or there are many other ways this could be implemented. The key is that it appears to be a loop whereby a program is called every second to turn on 'Hall - foyer / Front Lites'. I would think your best bet is to do what @MrBill suggested. Look on the "Summary" page for a program that is constantly running: You might also search your programs for instances of "Wait 0 Seconds" or "Repeat Every 0 seconds".

Unless you mistyped the time of the alert, it seems like the alert came too late (2 minutes after "schedule" trips) for that to be the cause. It sounds like your ultimate goal is to be alerted to an "event" that happens within a set time frame. If that's the case, you probably want to monitor CONTROL instead of STATUS as changes in control are one-time events while status is an ongoing state. So your program would look like: If From 11:00:00 PM To 7:00:00 AM (next day) And 'Device Sensor' is switched On Then Send notification Else - No Actions Only one event can happen at a time, or at least that's how the ISY sees it, so now when the program is triggered by 11:00:00PM (an event) you can't also have a "switched On" event*. That takes care of the one exception problem you had with "status". Now the only event that can really trigger your notification will be "'Device Sensor' is switched On" and if that event doesn't fall within 11:00:00PM and 7:00:00am (next day) it won't send. * While the above is true, you could still have a "switched On" event that just happens to be triggered at 11:00:00PM. You still only have one event being triggered, but in this case it's the "switched On" and not 11:00:00PM.

That's only 99.99% true. ? The program is triggered by three things: Time becomes 11:00PM Time becomes 7:00AM (next day) Sensor status changes from OFF to ON When the program is triggered, the entire IF is evaluated. So at 11:00PM if the sensor state is ON then the program will send even though the sensor status hasn't just changed from OFF to ON. Other than that one instance, the program will only send if the status changes from OFF to ON. Given that the OP's message indicates a time of 11:03:00PM, it's not likely that one exception is the cause of the message though. There are only two ways your message was sent. Either it was sent by the program you typed above, or it was sent by another program. So I would use the "Raw Text" option and search for either "Send Notification", or if you use "Send Notification" in a lot of programs you could search for specifically named content (i.e. the "Name" shown in "Configuration->Emails/Notifications->Customizations"). Keep in mind that when you search using "Raw Text", capitalization matters. Here are two screenshots of examples:

No worries. It's only through robust discussion that we really learn anything. No. Yes. No. Yes. As an example, here is the lead paragraph to developer notes released in Feb 2012: We are making improvements in device firmware to help ensure INSTEON commands are sent in a more reliable manner. This includes the adding of checksum (CS) to commands that set a remote device’s properties, bit flags byte and database records. Also, internal protections have been added such as the ability to prevent device from acting on a message from a device not currently in its database, enhanced buffer corruption prevention and preventing invalid hop count messages from being hopped on the network. While the notes are from 2012, in my experience it can take a year, or two, for inventories of old devices to clear so that you know you're getting a new device when you buy, so I would consider devices that are roughly six years, or older, to be "old". One thing that has definitely changed, for the worse, is that Smarthome has pretty much stopped updating developers on changes. So while you can see when a device's firmware has been changed, you don't know what those changes were.

Or, perhaps, you fail to understand. Older Insteon devices do not manage things on their own. The dynamic management of hops was a later addition. Even then, my understanding is that doesn't happen between the PLM and devices (feel free to correct me on that). On that we agree. And I'll say it one more time and leave it at that - a clean system won't require retries or multiple hops.

Do I have a "kick me" sign on my back today.

There is a maximum of three hops allowed. If lessening hops was going to lead to such instability, then Insteon would have allowed one more bit for MAX HOPS and increased the max to 8. Lessening retries will hardly ever improve anything. A device only uses a retry if it doesn't get an acknowledgement. If it consistently doesn't get an acknowledgement then it isn't working. If it isn't working, you'll notice it and fix it. If you don't notice it, then its use of retries apparently isn't causing you to notice a degradation in your home automation. I've read the white papers many times. Typically I refer to them before making responses about how Insteon works. Thanks for not boring me with the details here. Your response both says that Insteon devices are smart and that the Insteon designers aren't. If those designers were smart, why would they include the ability change configuration parameters for devices that you say are smart enough to know when to send more or less? They included the ability because sometimes it helps, either for reliability or speed.

In my opinion, it's actually opposite. If MAX HOPS is set to 3 then all devices must wait for the time it would take for the message to be repeated three times before they can respond, whether they heard the message the first time or not. They must wait so that they don't try replying while another device is possibly repeating the original message which would cause message collisions on the power line. On the other hand, RETRIES are variable. If a device sends a message and immediately receives a reply, the communication is done. It's only if the original message is not acknowledged that the original device will resend the message*. So on a clean powerline devices that use a retry value of 3 will use way less bandwidth on the powerline than devices that use a max hop value of 3. * - Most Insteon devices that use RETRIES will default MAX HOPS to 1 when they originally send their message. If they don't receive an acknowledgement then when they retry sending their message they will increase MAX HOPS by one (up to a max of 3).

I'm pretty sure it has worked this way for as long as I've had my ISY, which admittedly is not as long as you have had yours. I'm not sure this scenario is why we have the difference between "Status" vs "Control". "Control" has always been described to me to mean local control of the device. Which is to say, if a switch is turned on by the ISY, or a linked device, the ISY does not see that as "Control" even though it often would be helpful if it did.

Any change in the sensor temperature will cause the IF to be reevaluated and the THEN possibly run again. That's just the nature of the IF THEN ELSE. Consider if you had a motion sensor and you wanted to keep a light on if it detected motion. In that case you would want the THEN to rerun starting the timer over again. In your case, you can accomplish what you want with two programs and a state variable that we'll call $sFridgeHot. Program MonitorHighFridgeTemp If $sFridgeHot is 1 Then Wait 5 minutes Send Notification to 'Alarm' content 'High Temp' Program CheckFridgeTemp If 'Fridge Multilevel Sensor' Temperature > 40.0°F And 'Fridge Multilevel Sensor' Temperature <= 100.0°F Then $sFridgeHot = 1 Else $sFridgeHot = 0 In this case the change in the sensor temperature from 40.2 to 40.6 would cause the state variable to be set to 1 again which is not a change, so the IF in the other program would not be triggered and the WAIT wouldn't be interrupted.

I was originally thinking that wouldn't be a problem because the ISY doesn't send an ON or OFF command if it already thinks a device is ON or OFF respectively. But this would be sending a scene command which I believe the ISY would always send. So I'd probably go back to your original programs and add a test of the button's state to the IF and add a second set of programs that would look to see if the button should be turned OFF. For example: If $sLED1.timer >= 90 AND KPL.G is OFFThen set ledG.scene OnElse If $sLED1.timer < 90 AND KPL.G is ONThen set ledG.scene OffElse

A couple high level points about the start that @larryllix is suggesting: You cannot control individual LED's on a keypad, but they can be added to scenes and then you can control the scene. So Larry is suggesting that you create eight scenes (ledA.scene - ledH.scene) where the only member is the corresponding keypad button. You need a variable to hold the number of minutes left on your timer. Since you're going to want to react to this timer (e.g. turn light off when it reaches 0, etc) you need to make it a STATE variable not an INTEGER variable. That is why Larry prefixed the variable name with a small "s" (e.g. $sLED1.timer instead of $iLED1.timer). When you duplicate the programs for the buttons on the right sided of the keypad, you'll need a second timer variable (e.g. $sLED2.timer). The first four programs Larry provided take care of illuminating appropriate keypad button lights according to how much time is on the timer. They don't, however, take care of turning the keypad button light off as the timer decrements, so I would change all four by adding a command to the ELSE section. For example: If $sLED1.timer >= 90Then set ledG.scene OnElse set ledG.scene Off This will do a couple things. As your timer counts down, when it goes to 89, 59, 29, 0 it will turn off the appropriate keypad button light. It will also keep the lights in sync. Let's say there's 57 minutes left on the timer (so both buttons A and C should be off) and someone presses button C. You don't have any programs looking for a keypress of button C so the ISY won't do anything, but the actual button hardware will illuminate button C which would put the lights out of sync with your timer. Luckily, when the timer drops to 56 the appropriate program will run and turn OFF keypad button C.

Here's a link to the wiki email substitution page: https://wiki.universal-devices.com/index.php?title=ISY-994i_Series:EMail_and_Networking_Substitution_Variables Have you tried typing http://<your isy address>/rest/nodes/ into a browser to see what properties are assigned to water sensor nodes?

I'm assuming you'd have the MS II setup to send ON and OFF commands. Then after receiving an ON, you'd change the link between the MS II and Lamp to "ignore" so that when an OFF finally comes, the Lamp won't see it, but the ISY will. There are at least a couple issues with this. One issue is the scene update bug in V5 whereby the ISY tries to write to the controller when only the responder link needs to be updated. While the MS II will be awake after sending an ON, you might not be able to update its link with the Lamp before it goes back to sleep because of other Insteon traffic on the power line. If it goes back to sleep, the ISY won't be able to write to it (even though is really doesn't need to). Some people workaround this by disabling writes to battery devices. Another way would be to power the MS II by USB instead of battery. Another issue is one of complexity and murphy's law. A power failure after you've interrupted the link between the MS and Light would leave things in a bad state. So you'd probably need to use a variable that is saved to the ISY permanent memory to track when the link has been interrupted and then have a cleanup routine that runs on power-up if the variable indicates it's needed. With enough MS II's in the system, you end up with a mess of cleanup variables and programs. Additionally we don't really know what the MS II will do if it's in the middle of tracking motion and it receives a Link Table update from the ISY. Will it continue to run its internal timer so that it eventually sends an OFF? Will it just kill its internal timer and never send an OFF? Will it kill its internal timer and immediately send an OFF? Still, it's probably worth it to give it a try.

It depends on how much control you want over the scene. If you are willing to give the MS II complete control so that it is responsible for turning the scene ON and OFF, then you can rely on the MS II timer to determine when the scene is turned OFF. Many people want more control than that. If that's the case, then you could probably use two MS II sensors. With two MS II sensors, you could make a direct link between one of the MS II sensors and the devices you want turned ON. Set that MS II to send only ON commands. Then use the second MS II sensor, which is not directly linked to the devices being controlled and should be set to send both ON and OFF commands, to determine when there has been no motion for the specified time. This would allow you to have the speed of the first MS II turning ON the scene, but program control over when it is turned OFF. Sort of an expensive way to accomplish the goal, but if nothing else does what you want...

Sure, but then he wouldn't be able to use his ISY to track how many hours the pump runs and then wouldn't be able to estimate how much water he's using. Without that data, his anxiety level would surely spike and his health might fail. Best to keep using the IOLinc. ?

I was just about to suggest a latch. As I see them, the requirement looks like: Float Position Lower Limit Sensor Upper Limit Sensor Refill Valve Both Up OFF OFF Turn Off Lower Up, Upper Down OFF ON Ignore Lower Down, Upper Up ON OFF Not Possible Both Down ON ON Turn On So if you use the Lower Limit sensor as the SET signal for the latch and invert the Upper Limit sensor signal and use it as the RESET for the latch, the output of the latch could then be used to control the IOLinc.

How are your MS powered? If any of them are battery powered (i.e. not USB powered) then v5 actually introduces a problem. It seems that in V5, when you adjust the setting of a responder in the scene, the system writes to both the responder and the controller, even though there shouldn't be anything to write to the controller. If the controller is battery operated then it's probably asleep when the system tries to adjust the scene, and the write is queued. People have reported their ISY becoming slow and/or unresponsive after enough writes to their MS have been queued, though UD says that the system only saves the last write in a queue. The workaround for this problem is to disable writes to battery operated devices, but this can only be done if you have the Pro version. And even if you can disable writes to battery operated devices, you'll eventually have to turn writes back on when you actually want to update a battery operated device's settings, and people report that the queued writes from earlier can then cause problems. Here is a link to a discussion if you're interested:

The it seems the obvious answer is to use Celsius in the summer and Fahrenheit in the winter. ?

My experience with Luminance has been good, but I'm probably using it differently than you. I have my MSII setup to only signal motion at night. That has worked perfectly for me. In the MSII options you can set the Luminance Level that represents Night. To figure out what level should represent Night, when I first install a MSII in a location, I have a program that queries Luminance every time motion is detected. If the MSII signals motion and I don't think it's dark enough to be Night, I adjust the MSII Night Level option. Once I have the Night Level set where it only signals Night when I think it's night, I quit querying the MSII for Luminance. So in my experience, the MSII internal use of Luminance Level seems to be very reliable, even if the Luminance Level it reports when queried by the ISY isn't reliable. But I'm just one data point.

It seems reasonable to come to that conclusion, but doesn't SSL require a certificate to accomplish encryption? Perhaps that comes with the Portal.

No guesses as to why it's inconsistent, but a couple questions. First you're using a GET (as opposed to a PUT). Does reading the page really change the occupancy mode? While the ISY will allow you to execute a GET, it doesn't do anything with the response. Second you're using port 443 which implies SSL encryption. I don't know if ISY network resources support SSL. Perhaps other will pipe in on that.