gviliunas

Okay, not creating the folder structure you expect might be a problem but I think there may be a larger one looming.... If ISY System-A has 4 devices referenced in the programs, Say, A, B, C, and D. If ISY System-B has 7 devices, E, F, G, H, I J, K, then how do the copied programs reference the correct devices on the new ISY? Will this work?

Are you connected to AT&T U-Verse? Possibly this article may apply: https://support.eero.com/hc/en-us/articles/208276903-How-do-I-bridge-my-eeros- Other things to check: 1. Are the lights on the Linksys switch port connected to ISY flashing? What is the lED pattern on the ISY? 2. Did your ISY previously have a static IP or was this assigned by DHCP? If the IP was static, is it in the same range as the addresses that your other working devices are receiving? This may be worth looking into. The information online is sketchy but it seems the default DHCP scope for Apple may be 192.168.1.x/24 while the eero may be 192.168.0.x/24. If your ISY somehow had a 192.168.1.x address, you would not be able to reach it from the eero. One thing to try is to connect a laptop/desktop to the Linksys. Give the computer a static IP that was in the same range as ISY when it was working. Open the ISY Launcher and see if it can be discovered. Good luck

@apostolakisl Thanks for the suggestion! I use folder conditions in very limited situations. Someone else on this forum, possibly @larryllix, warned long ago to be aware of special considerations when using folder conditions.... Folder conditions can be confusing to troubleshoot, especially with nested folders, since right-clicking to manually run Then or Else doesn't work. Also, when the conditions disable the folder, any currently running programs will stop abruptly instead of running to their termination(s). I'm old so don't want to cause myself too many problems ?.

As a test, with the LampLinc plugged in, I stopped Program 1 (above) and manually ran the 3AM Query All and unplugged the LampLinc. As expected, the 3AM Query All caught the non-responding LampLinc and Program 2 set the variable correctly. If only a 1 per day check is okay then you only need Program 2. So, this method of detecting a circuit breaker trip can be used.

@MrBill I think that I was not giving enough time for my query to run (to timeout) before testing if the LampLinc is Responding. The following pair of program now works: Program 1 - Periodically test the circuit // Start this program by right-clicking and selecting Run Then If: Then: Repeat Every 15 seconds // I set this to 15 seconds for testing. I expect that a reasonable test frequency might be every 8 hr.? Set 'Test Lamplink' Query Wait 10 Seconds Run Program 'Program 2 - Test LL Responding (If) Else: Program 2 - Test LL Responding If: 'Test LampLinc " Responding is False Then: $i_Test_LL_Responding = 1 Else: $i_Test_LL_Responding = 2 When the LampLinc is plugged-in, the variable is set to 2. When unplugged, after the Query times-out, the value reverts to 1. This is Correct.

@MrBill I tried that also. After the initial test, the Responding condition is always True. If I test for Responding = False, the Else section fires.

So I thought this would be a simple exercise but this turned out not to be so. I can see the importance of being able to monitor this type of critical remote circuit. I had two ideas to solve this problem: Option 1. Connect the coil of a relay (Or possibly just a wall-wart if I/O Link can handle this) to the 120V circuit to be monitored and then use an I/O Link (Plugged into another circuit) to trigger the circuit-down notification. The down-side of this is the extra hardware required. Option 2. Since ISY offers a Status of "Responding," this seems a more simple option. The idea is to plug a LampLinc into the monitored circuit and then just periodically check if the LampLinc responds. I used a spare LampLinc and wrote the two programs below to test: Program 1 - Periodically test the circuit // Start this program by right-clicking and selecting Run Then If: Then: Repeat Every 10 seconds // I set this to 10 seconds for testing. I expect that a reasonable test frequency might be every 8 hr.? Run Program 'Program 2 - Test LL Responding Else: Program 2 - Test LL Responding If: 'Test LampLinc " Responding is True Then: $i_Test_LL_Responding = 2 Else: $i_Test_LL_Responding = 1 This method using the two programs above FAILED. Why???? I started Program 1 with the LampLinc plugged-in and saw the variable change to "2" as expected. When I unplugged the LampLinc, the variable never changed to "1" ☹️ No I even added a "Test LampLinc Query" line to the Then section of Program 1. Still, with the LampLinc unplugged, Program 2 failed to detect the not responding condition. It appears that with ISY, the Status of Responding = True seems to work quickly but ISY doesn't seem to be able to detect Responding = False. Is there some minimum time that a device needs to be uncommunicative before the Status of Responding is set to False?

How True! On the surface, ISY programming is simple however, there are case-specific tricks and traps. Several of my enabling programs have both a State and an Integer variable set and reset. Sometimes it is more appropriate to use State variable in other programs to cause a trigger when the enable variable is changed and other programs just use the Integer variable and trigger only when Control XXX or other State variables change value. Good catch. Thanks! Program 1a: Night lights Enable If From 8:00 PM To 4:00 AM (next day) Then $i_Night_Lights_Enable = 1 // Integer variable set to 1 each day at 8:00PM $s_Night_Lights_Enable = 1 // State variable set to 1 each day at 8:00PM. Any programs using this condition will also run Else $i_Night_Lights_Enable = 0 // Integer variable set to 0 the next day at 4:00AM $s_Night_Lights_Enable = 0 // Integer variable set to 0 the next day at 4:00AM. Any programs using this condition will also run.

I agree with @larryllix that using time conditions along with other trigger conditions can be tricky and can produce unexpected results Over the years, to make things easier, I have used time ranges to set and reset "enabling integer variables" and then use these in other programs to achieve the correct result. Eg. Program 1: Night lights Enable If From 8:00 PM To 4:00 AM (next day) Then $i_Night_Lights_Enable = 1 // Integer variable set to 1 each day at 8:00PM Else $i_Night_Lights_Enable = 0 // Integer variable set to 0 the next day at 4:00AM Program 2: Night "Any Trigger" detected If any trigger AND $i_Night_Lights_Enable = 1 Then runs if any trigger between 8:00 PM and 4:00 AM Else runs if any trigger between 4:00 AM and 8:00PM each day --------- Doing it this way, I avoid those "sneaky" possibly unwanted extra triggers at 8:00PM and 4:00AM

Have you checked your network connection between computer and ISY? I've had Java problems preventing me from logging into ISY but once I was in, I don't get repeated login prompts..... unless I do something like reboot my router or unplug the network cable. To check the memory situation, you can select to show the "Java Console" from the advance tab of the Java control panel. After doing this, try connecting to ISY and you will see the Java status in a separate console window. Good luck!!

I'm using 5.0.16C with the 2nd generation Z-Wave dongle and have my August deadbolt successfully connected. 1. I'm not sure if this lock is supported under ISY version 4.x. Others may need to chime-in here. 2. How close is the lock to your ISY? Do you have other Z-Wave devices connected?

I would be nervous installing a flapper or sail switch in the vent pipe. There is a great deal of lint that gets past the filter that I don't want clogging the pipe at the flapper. I don't want to make a fire hazard or something I am going to need to clean later. In the end, I installed three relays in my washer/dryer that trip two open/close sensors. I needed two relays for the washer as the different cycles energized different paths of the circuit. (I made a 2-input 115V OR gate) Not too elegant but it is reliable and I can get the notification a few seconds after the actual cycle ends. Fortunately, my 16-year old "beast" is like an old V8 - Easy to work on and modify, reliable, and surprisingly easy to find parts for.

At some point in the future, the ISY code will be migrated to the Polisy hardware platform and you won't need your 994i anymore.

Hi @bmercier Thanks for the procedure to implement heartbeat monitoring on the UDI Portal. I followed your instructions to create and call the Network Resource and it works. I was just checking my ISY error log and see strings of entries related to this monitoring. I searched the web for Module Rule 43, Error 6 but couldn't find any information. Should I be concerned about these: Sat 2020/03/14 23:05:07 System -170001 [UDSockets] Net Module Rul:43 error:6 Sat 2020/03/14 23:55:10 System -170001 [TCP-Conn] -1/-140002, Net Module Rule: 1 Sun 2020/03/15 00:00:07 System -170001 [UDSockets] Net Module Rul:43 error:6 Sun 2020/03/15 01:03:12 System -5012 0 Sun 2020/03/15 01:03:17 System -140000 sub.isy.io Sun 2020/03/15 01:03:17 System -5013 0 Sun 2020/03/15 01:03:24 System -140000 my.isy.io Sun 2020/03/15 01:03:59 System -140000 my.isy.io Sun 2020/03/15 01:50:07 System -170001 [UDSockets] Net Module Rul:43 error:6 Sun 2020/03/15 01:55:07 System -170001 [UDSockets] Net Module Rul:43 error:6 Sun 2020/03/15 02:00:07 System -170001 [UDSockets] Net Module Rul:43 error:6 Sun 2020/03/15 02:45:07 System -170001 [UDSockets] Net Module Rul:43 error:6 Sun 2020/03/15 03:11:34 System -170001 [UDSockets] Net Module Rul:43 error:6 Sun 2020/03/15 04:01:25 System -170001 [UDSockets] Net Module Rul:43 error:6 Sun 2020/03/15 05:11:24 System -170001 [UDSockets] Net Module Rul:43 error:6 Sun 2020/03/15 07:45:02 System -170001 [UDSockets] Net Module Rul:43 error:6 Sun 2020/03/15 08:50:02 System -170001 [UDSockets] Net Module Rul:43 error:6 This is NOT a high priority as my system appears to be running normally. Thanks for your help.

I received one also...

Currently, I think that only Presence-Poly is using BT but it only works on an rpi. One nice feature is that Presence-Poly can be configured on several rpis in the same home to give you a very granular personal locations for all of the inhabitants .... for those of you in your 10,000 sqft mansions. (You know who you are. ) As I tell my wife...."I think today I'll be in the East Wing but check Presence-Poly to accurately locate me before walking a mile" .... LOL Currently, this poly doesn't work on Polisy but rpis are cheap...

I have 5 day-to-day uses for the Wireless Tags: 1. Monitor outside light levels to turn on some auto-lighting in the house. This was my first use. 2. As an alternate temperature monitoring source for my family room. The TV is mounted just in front of the thermostat. When the TV is on, the thermostat sees the warmth and the room gets cooler and cooler. To prevent this, I sense when the TV is on and shift the monitoring of room temperature to the wireless tag. If the tag is too cold, set the thermostat to 28 degrees C. If too hot, set thermostat to 18 degrees C. 3. As a backup to bathroom occupancy. If the lights time out and wife is still in the shower, one touch to the shower curtain jiggles the wireless tag triggering motion and turns the lights back on. This saved my hobby once or twice 4. To monitor the freezer temperature. Yes, the batteries deplete quickly but this did help me discover how horribly inaccurate a GE freezer thermostat is. Hopefully this will catch a failing freezer or door blocked open before food is spoiled. 5. As a backup entryway PIR sensor. This one trigger Alexa to speak several messages. For these use-cases, the tags are reliable.

Notice: A-Team elves on vacation beginning 12/26. B-Team is in-charge now

@larryllix I discovered long ago that reliable tracking ends at the border...... but then every package becomes a surprise Christmas present

It would be nice but this is for Smarthome to offer, not ISY....

FWIW, I have five 2421 Triggerlincs (v.43) and running 5.0.16B. I have not had any false open triggers. There must be something different in the way ISY handles 2843 vs 2421 sensors. Edit: As Simplextech noticed, I too do see random long delays of reporting "on"

Yes, I think the answer is "no." The outletlinc doesn't have the ability to wait for ISY to determine what state it should be in upon power being re-applied. The question should be directed to Smarthome as a future feature request that devices be made to power-up in a specific state (on, off, or last state before power loss). Currently, the manual states that the the unit will return to last state before power loss. Another alternative may be to check into the ZOOZ S2 POWER STRIP. This device claims "Complete Control:" Complete Control Disable manual control if you don't want your cat messing with the fish tank gear when you're not watching. Decide if your Power Strip should restore status after power failure, keep the devices off, or force them to come on. Note: I haven't tried these strips myself nor do I know if they work well with ISY. You should check the Forums here before purchasing. Good Luck

@mmb I am sorry, I was moving too quickly and forgot to mention that I had set all of the variables used in my test to precision = 1. All of my temperature devices report to 0.1 degree precision so that is what I used in my test.

I just tried this under v5.0.16 and it works:

The communication between ISY and PLM follows the old serial RS232 device standard. RS-232 had a cable limit of 25'. The communication speed between ISY and PLM is 19.2K baud so I am surprised that your system is working as well as it is with a 60+' cable.