gviliunas

@larryllix I can declare victory over 1010. All it took was to power-cycle ISY. A software reset was not enough to restart the Z-Wave dongle.

@larryllix, Yes, I tried that but the sensor needs to be awake. I followed the manual which instructed me to hold the button for 0.5 second, release and see a "flash." I saw the flash confirming the sensor to be awake and then tried the right-click manual update route and then received a can't communicate with the device message. Maybe the manual method doesn't work with Z-Wave devices anymore??? Anyway, I may have found a fix to my original 1010 problem. I just power-cycled ISY and my 1010s are gone. I will wait 12hr (the stated wake-up time for these sensors) before declaring victory. If this works, I'll update my original post. Thanks for your advice.

Dome Window Sensor works after v5.1.0 upgrade but stuck in "1010 state" - RESOLVED EDIT 08/05/2020 - In the end, this was too easy. After excluding, factory reset, including, and "fiddling" with parameters, the final solution to this was just to power-cycle ISY (a software reboot was not enough). All device icons are now correct and devices work properly ------------- I have 5 Dome Z-Wave window sensors that would not update their state after the ISY v5.1.0 upgrade. I tried to Synchronize in ISY but could not time the sensor wakeup to make this happen. It was just easier to exclude and re-include each of these. After re-inclusion and re-mapping into their appropriate programs all 5 of the sensors worked. At that time, none of the sensors are in 1010 State. Later, I logged into the AC and noticed the one sensor in a "1010 State." The sensor is working and reporting its state correctly but after many attempts, I can't fix the 1010 State. I have tried: 1. Excluding, factory resetting, and re-including the sensor. (Also, new battery installed). After doing this, initially, the sensor is in normal state and works normally. If I close the AC and re-open this later, this, and only this, sensor will be in 1010 state. 2. Excluding, performing backup and restore on the ISY (2n generation) dongle then re-inclusion of the sensor 3. After removing the sensor from all other programs, I wrote a program that just writes changes to this sensor upon the sensor in Alarm mode (and captured a Level-3 Event log) Verified that "Write Updates to Battery-Powered devices is enabled. The sensor is sensing the window properly. The OCD in me would just like to resolve this 1010 issue. Note: The sensor is currently ZW123. I took a screenshot of this device's parameters before the last exclude/include, when it was ZW122

@markv58 Thanks for your reply!!! The numbers looked a little strange I thought maybe a combination of degrees C, Degrees F and Raw data. Ha. ? It really was minutes. It appears that the "lights were on but nobody was home" at my house today. ? Thanks again for the very useful Node Server!!!

I just pulled an ISY Event log and noticed that Virtual temperaturec node values are all being logged and appended with "minutes." Everything is working but reporting this in case it affects something that I don't see. A. Nodes / Virtual / Virtual Device Controller / Outdoor Temp Custom Control 2 7.6 minutes Mon 2020/08/03 10:44:38 System Log A. Nodes / Virtual / Virtual Device Controller / Freezer Temp Custom Control 2 59.5 minutes Mon 2020/08/03 10:44:38 System Log A. Nodes / Virtual / Virtual Device Controller / Home Main Temp Custom Control 2 231.5 minutes Mon 2020/08/03 10:44:39 System Log

Problem: LiFX bulb response time via Polyglot very slow - RESOLVED Installed V5.1.0 this morning. I have several scenes that have an Insteon controller (Dimmer) and a LiFX group and LiFX bulb as responders. In the past, I accepted ~3 second delays from switching on the dimmer until the LiFX bulbs come on. Now, with v5.1.0, the response time is ~8-10 seconds. Is anyone else seeing this? Otherwise, the new Z-Wave organization looks great!!! I only gained 7 Access Control Alarm and 7 Home Security Alarm nodes. ---------------------------------------------------- @Chris Jahn I looked into this further and the issue is becoming more muddled. It seems that there is some recent command caching going on but the effects are not consistent. After some idle time, If I switch on an ISY scene with LiFX bulbs I may see normal 3-4 second latency OR I may see an 8-12 second delay. If I then switch off, the lights respond quickly. If I now switch back on, the lights respond quickly. I think the biggest part of my problem was with my Dome Window Sensors, Dome water sensors, and GE hinge pin door sensor. After the upgrade, the response time for these devices was 15-20 seconds and, when they activated, I received a can't communicate to the Notification Sensor node of each of these devices. This made everything slow. I tried a Sync but, even after awakening the sensors, could not make this work. I ended up excluding and re-including all of the sensors and these all sport two new nodes and are all working well. (and snappy) I'm still on the hunt for the cause of the LiFX response time variability and noticed that since upgrading, the ISY error log has racked-up >28700 errors. Most of these are -170001. Is this a problem??? I gathered Event and Error logs. The Lights I've been focusing on are: "c.L-MBRBath1L" - LIFX Group B.LG-MBR-Bath-" Controlled by "MBR Bath Light Switch" AND "c.L-GBRBath1L" - LIFX Group I.LG-GBR-Bath-" Controlled by "GBR Bath Light Switch" Yesterday, I made a change. Instead of Adjusting Scenes to achieve Day/Night levels in these bathrooms, I deleted the scenes and instead call different Day/Night programs that explicitly turn on either "LIFX Group C.LG-MBR-Bath-Day" or "LIFX Group H.LG-GBR-Bath-Day" (Daytime) OR "c.L-MBRBath5" or "c.L-GBRBath4" (at Night) Before 8/3 @ 6:31AM - ISY and Polyglot were running At 8/3 @6:40AM - I Stopped all Node Servers At 8/3 @6:50AM - I Started all Node Servers Attached is a list of the NS in use. These are all on Polisy. There is also Presence-Poly running on a separate rpi EDIT 8/4/2020 - After excluding / re-including all of my z-wave sensors and restarting Polisy everything seems to be back to normal speed. In the first two days after upgrade, I saw >27000 errors in the ISY error log. I checked this morning and no errors have been logged in 17 hours. I'm not sure of the exact cause or solution but am posting a final error log. EDIT 8/5/2020 - After another 24hr, my system is back to rock-solid. I am not sure but believe my entire ISY-SLow problem was due to the Z-wave sensors needing to be excluded and re-included. Checking the ISY error log this morning and it remains clean. Response time for the LiFX bulbs may even be a little better. ISY_Error_Log_v5.1.0__Mon_2020_08_03_07_03_37.txt ISY-Events-Log.v5.1.0__Mon 2020.08.03 07.03.13.txt Final - ISY Error Log.v5.1.0__Tue 2020.08.04 09.03.31.txt

@larryllix, not to hijack this thread but I reported this issue awhile back. I don't know if it has been fixed but it was easy enough for me to keep CAO in degrees F and do the conversion in ISY. I have one leg on each side of the border...

As a data point for @Teken and @markv58, my freezer monitor appears to be working correctly but I am setup differently. In my case: 1. I accept degrees F data from CAO sensors (They don't reliably stay in degrees C mode when the CAO NS restarts) and store this in a State Variable. 2. Precision for all of my temperature State Variables is 1 3. This NS pulls from one State Variable and pushes to another. All of my nodes are "tempuraturec" 4. I do the degrees F to degrees C in this NS. ParseDelay is at default value

@markv58 I added three additional temperaturec nodes and everything appears to be working perfectly! Thanks for your hard work in bring this fantastic NS to life. ? ? ?

@markv58 My Polyglot version is 2.2.9-5 running on Polisy ISY is 5.0.16C 2020-07-24 08:10:31,668 MQTT polyinterface INFO polyinterface:_subscribe: MQTT Subscribed Succesfully for Message ID: 2 - QoS: (0,) 2020-07-24 08:10:31,777 NodeServer polyinterface INFO Virtual:start: Started Virtual Device NodeServer v1.0.17 2020-07-24 08:10:31,783 NodeServer polyinterface INFO polyinterface:addNode: Adding node temperaturec 155(155) If I click "Reset Statistics," Previous, Highest, Lowest and Average are all = 0 degrees C and Current is showing the correct temperature. I am using a temperaturec node.

@markv58 Ah Ha! With the parseDelay =0, I updated to v1.0.17 The error pattern that I was seeing previously is not occurring now. BUT, before Virtual NS made its first pull from State Variable 154, I set the variable to a large number to verify the calculations were working. I think the problem may be with the "Highest" temperature calculation or with the temperaturec conversion. The other values are changing, as expected, but Highest is always = 0 degrees C All other displayed values seem correct and are updating. Virtual_logs_2020-7-24_081905.zip

@markv58 I tried v1.0.16. This version seems to work and updates the State Variable correctly and the NS Does NOT crash but I am still seeing errors in the log. First, I tried without a parseDelay then I increased the delay in several steps to finally 4 seconds but still see this error pattern: 020-07-23 21:06:48,320 Controller polyinterface INFO Virtual:pullFromID: ['b\'<?xml version="1.0" encoding="UTF-8"?><var type="2" id="154"><init>0</init><prec>1</prec><val>-16</val><ts>20200723 11:55:36</ts></var>\''] 2020-07-23 21:06:52,398 Controller polyinterface DEBUG Virtual:pullFromID: Parse delay: 4 2020-07-23 21:06:52,399 Controller polyinterface ERROR Virtual:pullFromID: An error occured during the content parse: list index out of range Virtual_logs_2020-7-23_210925.zip

I have only 1 variable configured in this NS in my Polisy. I have 10 other NS and short and long polling for each NS is at default.

@markv58 You are too dedicated. Take your time. ??

No Joy with version 1.0.15 2020-07-23 16:19:50,881 Controller polyinterface DEBUG Virtual:pullFromID: b'<?xml version="1.0" encoding="UTF-8"?><var type="2" id="154"><init>0</init><prec>1</prec><val>-16</val><ts>20200723 11:55:36</ts></var>' 2020-07-23 16:19:50,887 Controller polyinterface INFO Virtual:pullFromID: ['b\'<?xml version="1.0" encoding="UTF-8"?><var type="2" id="154"><init>0</init><prec>1</prec><val>-16</val><ts>20200723 11:55:36</ts></var>\''] 2020-07-23 16:19:50,888 Controller polyinterface DEBUG Virtual:pullFromID: /2/ 2020-07-23 16:19:50,903 Controller polyinterface ERROR polyinterface:write: Exception in thread Controller: Traceback (most recent call last): File "/usr/local/lib/python3.7/threading.py", line 926, in _bootstrap_inner self.run() File "/usr/local/lib/python3.7/threading.py", line 870, in run self._target(*self._args, **self._kwargs) File "/var/polyglot/.local/lib/python3.7/site-packages/polyinterface/polyinterface.py", line 854, in _parseInput self.longPoll() File "./Virtual.py", line 57, in longPoll self.nodes[node].getDataFromID() File "./Virtual.py", line 805, in getDataFromID self.pullFromID(_type, self.action1id) File "./Virtual.py", line 825, in pullFromID if command1 == '/2/' : _newTemp = int(_value[3]) IndexError: list index out of range ----------------------------------------------------------------------------------------------------------------------------------------------- Just to be sure I have this configured correctly... My temperature sensor is updating State Variable 154 with a Fahrenheit temperature. This NS is configured with a temperaturec node associated with State Variable 155 The NS configuration is to pull from SV 154 and push to SV 155 after converting from Raw and Converting to degrees C Is this correct? Virtual_logs_2020-7-23_162507.zip

I think that I am seeing the same thing as @Teken State variable 155 is certainly defined in my ISY and also is to only one I'm using in this NS 2020-07-23 12:07:16,349 Controller polyinterface DEBUG Virtual:pullFromID: Pulling from http://192.168.1.70/rest/vars/get/2/155/ 2020-07-23 12:07:16,382 Controller polyinterface DEBUG Virtual:pullFromID: b'<?xml version="1.0" encoding="UTF-8"?><var type="2" id="155"><init>0</init><prec>1</prec><val>-16</val><ts>20200723 12:05:30</ts></var>' 2020-07-23 12:07:16,388 Controller polyinterface INFO Virtual:pullFromID: ['b\'<?xml version="1.0" encoding="UTF-8"?><var type="2" id="155"><init>0</init><prec>1</prec><val>-16</val><ts>20200723 12:05:30</ts></var>\''] 2020-07-23 12:07:16,401 Controller polyinterface ERROR polyinterface:write: Exception in thread Controller: Traceback (most recent call last): File "/usr/local/lib/python3.7/threading.py", line 926, in _bootstrap_inner self.run() File "/usr/local/lib/python3.7/threading.py", line 870, in run self._target(*self._args, **self._kwargs) File "/var/polyglot/.local/lib/python3.7/site-packages/polyinterface/polyinterface.py", line 854, in _parseInput self.longPoll() File "./Virtual.py", line 57, in longPoll self.nodes[node].getDataFromID() File "./Virtual.py", line 805, in getDataFromID self.pullFromID(_type, self.action1id) File "./Virtual.py", line 822, in pullFromID LOGGER.info('Init = %s Prec = %s Value = %s',_value[1], _value[2], _value[3]) IndexError: list index out of range

On my 2x4s, I just tie +5v terminal to the I3+ terminal. The I3- terminal goes to one side of a door Reed switch. The other side of the door Reed switch goes back to the GND terminal on the 2x4. Here is the quick start guide: http://cache-m2.smarthome.com/manuals/31274-qsg.pdf Edited: Sorry for the confusion. I'm reading the OP asking about I3/I4 and I'm incorrectly writing about I1 and I2. Must be getting very old Hmmm For I3 and I4 I just use a 470-ohm pull-up on each to +5 and then my reed switch connect between I3 (or I4) and back to GND

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.