gviliunas

This is normal. I believe that the 500 series chip does not need a boot loader.

@TexMike @hart2hart Here are the instructions we followed when beta testing the 500 dongle (I suspect any FW 5.0.13+ will work): Note backup of the 300 board is very slow (40 min- 1 hr) and may fail and need to be repeated. You must be running 5.0.13 You must backup your Z-Wave dongle (Z-Wave | Tools | Backup) … this is going to take a LONG time so, if you decide to go for this beta, it's best to backup now Disable query at restart Replace the dongle Restore your Z-Wave dongle by doing Z-Wave | Tools | Restore … this is going to be pretty fast Test communications, Heal the network, backup, and range (should be a little better)

@Bspect I set a variable equal to the MS6 temperature node each time the node updates. Here is the pseudocode: If status of Kitchen Temp is not 1000 Then set sTempVariable = MS6 Temperature node degrees F Your other program can check if the Temp is too high and send the e-mail In the E-mail customization, you can reference the variable

Successfully upgraded from v5.1.0 to v5.2.0. No issues encountered and everything, including Z-wave devices, is working well. Thanks for the great development effort!

@mitch236 You query the top level node in your Devices section. For me, this node is called "ISY" but your may be different. See attached screen shots.

@bobchap There were 2 versions of the Z-Wave dongle released by UDI. The first version was based on the 300-series Z-Wave chip. This version had FW version 4.55 and sported the ability to connect an external antenna and had a blue LED on the dongle which protruded through the rear of the ISY case. The newer version of Z-Wave dongle release ~ July, 2018 was based on the 500-series chip. This version had FW version 6.81.00. This version does not support an external antenna and there is no blue LED on the dongle.

For Homeseer WD200+ Users, ISY v5.1.0 creates a new "Basic" node if you synchronize this device. The Basic node and the Dimmer nodes appear to operate similarly but status back on the Basic node does not update properly: 1. If you switch-On or Switch-Off this device from the local switch, The Admin Console status will not change. (1st problem) 2. If you switch-On or Switch-Off from the Admin Console, the Status will rise or fall but will not end-up at the correct value. i.e. Turn-On and expect to see 35% but instead see random values from 16-22% (Incorrect) If you query this node, the status value jumps to 35% (Correct). Turn-off and expect to see 0% but instead see 16-9% (Incorrect) Again, if you manually query the node, the status will be correct 0% (2nd problem) I tried changing the "Automatically sends status update" setting but this did not fix status reporting for the Basic node of the WD200+ The Dimmer node seems to report status properly both when controlled locally and via the AC - I recommend that you use this node in your programs and scenes Event viewer L3 data attached. Basic Node Turn ZW072 On and Off from AC.txt

If we "old guys" stick together, we only need to remember how part of this system works ?

@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