jmwhite5

This observation struck me as well. Ever since I put my ISY in a media closet and have to rely on an intermediate Z-Wave device to relay pretty much all commands, I have routinely observed delays in the 30 to 60 second range (I'm thinking of moving back my ISY). But so far, with this build, my lights are coming up right away. I hope this change is real!

I upgraded from 5.3.0 to 5.3.3 with only 1 minor glitch – the PurpleAir node server doesn't populate field GV11 (EPA AQI Category) anymore (it's a string, versus all other fields are numbers). It was working fine with 5.3.0. I filed a bug report with the plugin author just in case.

My blinds are outdoors and my bond gateway is indoors (about 50 feet away). The walls are stucco. I also ended up buying the z-wave bridge (ZRTSI II: 16-Channel Z-Wave to RTS Bridge) for Somfy because I thought I could get the status of the blind (the state of the blind, whether up or down) but that is NOT supported. So literally, for me it was 100% waste of money. The bond gateway was much easier to use AND you can control a bunch of other things too (bonus!). But you don't get the state of the blind. So it's good for issuing commands that are not conditional on the blinds state. But for the most part, it's fine. I have automation that automatically retract the blinds if 1) the sun goes down 2) the wind is above a certain speed.

Hi, I have many z-wave outlets in many rooms (in their own folders). Could the z-wave neighbors table log be upgraded to include the folder path ? I don't want to include room info in the name, since it's already redundant with the folder name.

Hi, I just wasted my afternoon trying to configure a Kwikset SmartCode 916 Lock. The lock was added very quickly when near the ISY. But as soon as I moved it to it's final location, it got REMOVED due to a "device data differs with ISY" error (!!!!). After several attempts by a process of clicking on "Update Neighbors" as I was moving the lock closer to its final destination, it finally settled down. But then I got storms of errors every time I tried to lock or unlock and the lock would turn erratically (commands taking really long to process??). I suspect a poor Kwikset implementation because I have tons of other z-wave devices (probably about 40) scattered indoors/outdoors and they more or less work reliably (sometimes a bit slow, but eventually they work). It's disappointing because the lock looked very nice otherwise.

I finally got around to trying out your suggestion and IT SOLVED THE PROBLEM!!! Thank you for sharing. For the record, here's my setup: 1) I'm using a normally open reed switch (normal state is a closed gate) 2) I use 1 scene configured like this (a bit different from how it's described in the manual where they use 2 scenes). The 2 controllers (the IOLinc sensor and the Keypad button - configured to Toggle) for my scene are configured like this: Here is how the relay is configured: My keypad button now correctly lights up when the gate is open. The keypad also correctly reflects the gate state when I use my car remote, or my Chamberlain gate controllers, and even when I use Siri (through Homebridge) or Alexa to control the gate. Further, the Querying the Sensor now works as expected (no magic flipping of state like before). So I may restore my voice announcement if this behavior holds up.

I see. So to build on that Z-wave spec improvement, would it make sense to build an ISY feature that would walk the Z-wave nodes and refresh the neighbors table of each device? Essentially just automate what I had to do manually? (could be called "Update All Nodes Neighbors"). It could run several times in a row (up to a maximum) until all tables have stabilized (i.e. last refresh doesn't yield any changes).

Thanks @simplextech. Very helpful. It seems to me that the "Heal Z-Wave Network" option still makes sense in spite of Z-Wave Plus self-healing. The self-healing addresses robustness when small changes occur, but doesn't address drastic network topology changes very effectively. So I'm throwing my vote for bringing back the "Heal Z-Wave Network" option (or something equivalent).

Context: I have an ISY on 5.3.0 w/ z-wave 500 (6.82.01) (upgraded 5 months ago). All of my z-wave devices are Z-Wave Plus. Scenario: I moved my ISY to another room. I started getting a bunch of Z-Wave error messages (devices not responding). Right away, I plugged in a couple additional Z-wave modules to strengthen the mesh. That helped. But I kept getting sporadic "devices not responding" error messages. So I started to click on "Update Neighbors" on the problematic devices. It helped and I was getting fewer error messages. This morning, I woke up to a couple more error messages and I started paying attention to the routes and neighbors tables and noticed incorrect neighbors tables (i.e. direct links to ISY, when I suspected it was an old link). I systematically updated all neighbors for all devices (about 12). I'm now hoping that my problems are solved. So my question is: I moved my ISY 2 days ago and I was under the assumption that the z-wave network was "self healing". Is this true? What is the recommended procedure when Z-wave devices are moved around? Are we supposed to manually Update Neighbors on all devices?

Just got my new blinds from zebrablinds.com. I ordered the motorized version with a Somfy controller. I thought it had z-wave built-in, but it doesn't. They expect you to purchase the Z-Wave RTS bridge adapter (ZRTSI). But I realized that my existing Bond bridge (that I have to control my fans) actually support my Somfy blinds. So there you have it. No need to rely on z-wave if you have a bond controller.

I installed a FilterLinc (I had a spare one in my closet). It did not solve the problem. I still observe the behavior. I do agree that there seems to be a disagreement with the status. I think you're previous comment is right that I need to get rid of the Trigger Reverse and program around it. But I think I would have to compromise on my keypad button lights and I don't want to. So I think I'll just simply give up on the announcement feature.

I tried removing the Trigger Reverse option. But that messes up my Keypad button (I want it ON when the gate is opened, and OFF when the gate is closed). Also, I just noticed that every time I manually Query the IOLink sensor, it triggers my program, even when the status is already ON (my program triggers on ON). So that's odd. But the factory Query All doesn't trigger my program. So maybe I'll try something along the lines of what @gzaharmentioned about refreshing the status right away after the gate has closed.

It is based on the sensor status (not the relay). I still haven't made this work (see next suggestions from @larrylixx).

@stillwaterI just ran into a similar problem, but with an IOLink sensor. I have a program that announces that my gate is opening. Not a great feature when this announcement is barked for no reason in the middle of the night. (In the IOLink settings, I have the trigger reversed and I now suspect it may be causing this side-effect). I just added a time range where my program would not run (around the time the factory query all runs). I was curious if that is what you did? or did you use some additional logic using variables to know when the Query All has finished running?

It worked. Phew. Now all I need to do is wait for my 500-series.