MrBill

I edited my contribution above, My .off program wasn't making sure everything got turned off. I used to use state variables for everything, but started using the disable method for things like this because at one time I had too many state variables and it was causing queue full errors.

Actually spread the on/off temp out a little bit..... if on is < 29 make off > 30 since you're temp appears to update based on tenths (.1) putting on and off at the same temp is going to lead to a different problem.

to fix the looping problem use 3 programs: (apologize these have form typos because I did it off the top of my head, i didn't go create sample programs... if that results in questions please feel free to ask.) antifreeze.on If 'PoolTemp' Temperature < 29.0° then Run program antifreeze.loop (then) else (none) Antifreeze.loop - [ID 002C][Parent 003E][Not Enabled] If (none) Then Disable Anti-freeeze.on Repeat Every 2 hours Set 'Pool Equipment / SpaValve' Off Wait 15 seconds Set 'Pool Equipment / FilterPump' On Wait 10 seconds Set 'Pool Equipment / Polaris' On Wait 10 seconds Set 'Pool Equipment / Waterfall' On Wait 15 minutes Set 'Pool Equipment / Waterfall' Off Wait 30 minutes Set 'Pool Equipment / Polaris' Off Set 'Pool Equipment / FilterPump' Off Set 'Pool Equipment / Waterfall' Off Else - No Actions - (To add one, press 'Action') antifreeze.off If 'PoolTemp' Temperature > 30.0° then stop program antifreeze.loop Set 'Pool Equipment / Polaris' Off Set 'Pool Equipment / FilterPump' Off Set 'Pool Equipment / Waterfall' Off enable program antifreeze.on else (none) the second program antifreeze.loop should be disabled.

The tempature updating is likely the problem. temp = 28.9 loop starts temp = 28.8 loop restarts temp = 28.7 loop restarts Also repeat every 2 hour at the bottom does nothing, that would need to be moved up to be the first line of the loop.

The problem is likely that each time the temp changes the then body is restarting. I don't know the nature of where your temp value is coming from or how often it is updated. To test that theory, leave it disabled and right click and 'run then' if the then body does what you're expecting under those conditions then the IF body being re-evaluated is the problem.

Can you better explain what you mean by "but it never goes off"? I also note that the program is disabled, or it least it was when you pasted it.

It's purpose is to reach the ISY from outside your house without using the portal. It shouldn't come into play here. (not to change the subject but: The more modern more secure method is not to use port forwards and instead use an ISY portal subscription which also has other values and priced amazingly ~$1/month.) Have you tried to manually "add" and entry to the finder using the URL found using the old computer?

yes. I had that in mind.

Clear your java cache, including installed application and applets (which I failed to check the box while making the screenshot).

Note: The Launcher, is different that "the finder". Are you using The Launcher as described in the first post of the thread linked by @Bumbershoot a few posts up?

Firewall / virus protection are the likely https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Configuring_a_Firewall_for_Your_ISY

? My apologies, I guess I should have worded it slightly differently "a folder above the program must have a folder condition evaluating it to false" However technically the question I did ask was correct "Is it in a folder that has a folder condition which evaluates to false?" the program is technically in the "my programs" folder, there just also happens to be one or more folders between the two.

I agree with @Teken about static IP addresses, they shouldn't exist on any network. Instead DHCP reservations should be leveraged to assign IP addresses where it matters. Another thing is that I notice your using the downloaded admin console which is ok, as long is you have a clean cache and no confusion among files. There is a newer method call the Launcher, which always opens the correct version of the admin console based on the ISY's firmware version. This method is typically less problematic for most users. If the socket error continue be sure to disable all virus protection and try again. Also remember that you can open a ticket by emailing support@universal-devices.com for 1 on 1 direct help.

Is it in a folder that has a folder condition which evaluates to false? It must be, that about the only reason that 'run then' wouldn't run. PS - if you care about the actual count be sure to set the init value as well, otherwise the count will reset to zero when the ISY restarts.

I don't have any Z-wave locks. One of my doors has a magnetic lock, that I set up long before the current lock offerings became available. The reason I replied above is that I'm very aware of the fact that lock cylinders can be re-keyed. You can also often order locks keyed to a specific key code. or have a locksmith or even sometimes a hardware store re-key. Also many times the lock cylinder can be swapped out to a different brand. I'm not a locksmith but I do have rental properties and re-key all the locks between tenants myself. I purchased my Schlage pin kit originally to solve a problem, over the years it's saved me thousands. I don't know enough about Z-wave locks to advise you, but I read most threads on this forum and could clearly see that you were being short sited with your sweeping statements above.

Your logic is faulty. Have the replacement locks keyed to whatever manual key you desire.

I don't know that I'm going to be helpful. The need is to debounce or slow down the state changes being sent the EZIO. Normally the controller of the device should handle that, I don't know why I didn't think of that fact before, the secondary method would be a time delay relay. The problem is the one that I use for a different application doesn't actually work the way I thought it did... it's more of a "timer" than "time delay". Yes, C (cycle) = 0 with cycle forever, you may be confusing what cycle means tho. Once 'triggered' the cycle has started, meaning that infinite will never stop the on/off cycle that's been set. When I used your values including C=0 the "work" light flashed too rapidly for a mechanical relay to be be able to work. When the relay turns on (which is indicated by the work light) the coil in the relay is energized, it takes just a moment for it to build up enough magnetic power to "pull" the relay in. (a mechanical relay, the blue box just above the red LED 'work' light is not a good choice for very rapid on/off cycles). With the values you are using: Time unit = 0 and T1 and T2 = 3 you are setting 3/10 of 1 second on and 3/10 of 1 second off. This is a very fast cycle that is too fast to energize the relay coil, and because c=0 it's never ending. If you want to test your relay, use my values turn it to P7, time unit -2 t1= 1 time unit -2 t2 = 1 and c= 1. That is 1 minute cycles. Now 'trigger', the relay will turn on for 1 minute then off for 1 minute. After that cycle is complete 'retrigger' is possible, Unfortunately what is NOT possible is to re-trigger during that cycle, which would in theory start the cycle over. That would be exactly what we want: if the snow sensor turns on the relay it stays on for a minimum amount of time and if the snow sensor turns off and on (re-trigger) during the process the timing starts over again. (You could also perhaps use 5 or 10 seconds to test, i.e. time unit -1 and T1 and T2 = to 5). Now if you use the above values with c=0, once you trigger the on/off cycle the on/off timing will start, once it starts that's all that happens it cycles indefinitely on and off for the set amounts of time. Re-trigger does nothing.

My apologies, I've afraid I've wasted your time (and maybe a few dollars on amazon). I set the relay up first with the values that you gave in your post. I noted right away that caused the red LED "work" light to cycle rapidly. That light comes on when the relay turns on and goes off when the relay turns off. The values entered cause it just to loop forever, at a rate that is too fast to energize and de-energize the relay. I then set the mode to P7 (based on my prior guess) and with -2 (minutes) for the "accuracy" and a value of 1 for both T1 and T2. This behaved almost as expected. I triggered the relay and the relay came on for 1 minute, then went off for one minute. What did NOT work is re-triggering during either time period. In fact T1 begins at the leading edge of the trigger, and once triggered both time periods must expire before a re-trigger occurs. My thinking was this relay could be used to debounce because timing began on the trailing edge of the trigger and that re-triggering would restart the timer... that's clearly not happening. I then went through each mode using 1 minute timers looking for one that would work as a debounce. P1 is close, but still turns off at the end of the cycle and requires a re-trigger. Is your snow sensor a commercial product? do you have a link so that I can read how it works? Maybe it has a setting that would help. I use an EZIO but differently than this application. I certainly understand that you don't want the input cycling on and off which would generate too much Insteon traffic.

That does sound like a bad relay, or some other component. I just went and looked again and found my spare relay, I was looking for a box and it was in a small white envelope wrapped in bubble wrap. I'll find a transformer and see if i can or can't duplicate your results. I'll post back later.

Insteon devices are dual band and can help each other with transmission via a mesh. When I had just a few Insteon devices I sometimes had communication issues. Now that every switch in the house, except for two garbage disposals and the attic light switch, is Insteon I really never have issues.

you're not generally short on words ?

I agree with @Teken ...sort of.... Delete and add in the portal and the alexa app. not the device from the ISY

The basic steps to follow are: backup power down, insert new card, power up telnet to isy and format SD card it (may not be required for a new card) use the admin console for your version to login, and re-install the firmware (Note: you can't use The Launcher in this case). (see the wiki page for more info.) restore backup Note your backup does not contain the firmware, thus the reason for step 4 and 5 both. the wiki page is here: https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Replacing/Formatting_an_SD_Card (the ISY will support a 16GB card so long as you're not using ancient firmware 4.2.18 or before.) My ISY has an address reservation on the network set via the router so the IP address won't change. If you have a static IP configured from the configure tab of the admin console be ready to find the ISY's new IP address. Also note that the wiki is contradictory on the point of whether you should format via telnet session. at one point it says that it's NOT required for a new card, but later there's a note: "Please note: the ISY works with both FAT 16/32, but FS function formats it specifically for use with ISY with some performance improvements so its preferred you use this method." that suggests formatting via this method should be done.

I agree, also on 5.3.0, and don't have this issue. I was going to type the same thing earlier but got sidetracked.

I've actually been impressed that HA doesn't cause any problems in my setup. It seems to maintain the same subscription for very long periods of time (many days).