gviliunas

@Michel Kohanim Ah ha...I rebooted Polisy and now get the proper "No updates available ...: message. Everything working great! Thanks for your help

@Michel Kohanim The UI upgrade check does not complain but suspiciously, after I click to check for upgrade, I never get the green-banner message that "No upgrades were available. I only get the green banner "Sent upgrade check to Polisy..." After a few seconds, this message clears.

Hi @Michel KohanimThanks for looking into this. I tried sudo pkg upgrade. It did not appear to upgrade anything but I do not get the version mis-match error. Should the freebsd version be: 12.1-RELEASE-p10 ? [admin@polisy ~]$ sudo pkg upgrade Updating FreeBSD-base repository catalogue... FreeBSD-base repository is up to date. Updating udi repository catalogue... udi repository is up to date. All repositories are up to date. Checking for upgrades (0 candidates): 100% Processing candidates (0 candidates): 100% Checking integrity... done (0 conflicting) Your packages are up to date. [admin@polisy ~]$ [admin@polisy ~]$ [admin@polisy ~]$ freebsd-version 12.1-RELEASE-p10

I opened a ticket on this and received a response that the UDI guys are on it.

@TomL With Z-Wave, there is still a bit of "wild west." Not so much plug-and-play but more of plug-and-play-with-it.... I don't have these anymore but was able to get my hinge pin sensors to work by changing the notification mode of the sensor. I remember that the default setting did not work. The GE instructions have you press the button. There is an entry on the Z-wave Alliance showing this being controlled by Parameter 20. Try the button method or setting parameter 20 to 2 or 3 after waking-up the sensor. One of these should work. The node I used once connected to ISY is the "Barrier Sensor"

@ExDvtchWhat version of firmware did you upgrade from? Are you using the 500-series Z-Wave dongle (No blue LED in the rear of ISY)? Ver. 5.3 does not support the older 300-series dongle.

@Mecheng70, I tested this code and it seems to work properly but there are two caveats and one question: 1. The variable s.casita_guest_code must be a State variable. If not, the program will never be triggered. Programs cannot be triggered by changes in Integer variables. Because you are setting s.previous_guest_code = s.casita_guest_code in your program, it seems that something changing s.casita_guest_code will cause the program to do what you want. 2. The variable s.previous_guest_code may be a State or Integer variable. In your program, changing this variable will not change s.casita_guest_code so you probably don't want the program to run if s.previous_guest_code changes so this can be (and you probably want this to be) an Integer. Question: Why do you have this line: "Stop program 'Door - Casita Code?" Once triggered, all of the "Then" lines are atomic and the program will stop anyway.

@esloyerIt is usually better to use your own ISP's email server or gmail rather than UDI's default server.

Yes, it looks like UDI took the Boot Loader line out with v5.2.0 RC3. That is okay. 6.81.00 is the latest version so you have no problem here. The 500 series doesn't need a Boot Loader

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