blueman2

Thanks @Chris Jahn and @Michel Kohanim for updating the guides too. I had not noticed these until now.

Congratulations on z-wave certification and on 5.x Official Release.

@shbatm, I talked to @Michel Kohanim and this behavior is actually intentional. Since a device can only be controller for 1 scene, ISY does go ahead and change the device's parameters for Ramp Rate and On Level to be whatever that scene is. So not a bug, but more the way ISY handles the controller for a scene. I tried to come up with a plausible scenario where this might cause issues and could not.

@shbatm, yes, I confirm what you are seeing. Adding a device as a CONTROLLER to a scene does indeed appear to reset the device to 100% On Level and 0.1 sec ramp rate. Nice find!!! I missed this because I had been adding devices to scenes only as RESPONDER, and that does not appear to trigger this bug. @Chris Jahn, can you log this bug? And while we have @shbatm here, I want to add a note of recognition and thanks for everything he has been doing to better integrate the ISY with the Home Assistant project. I am using Home Assistant as my main user interface to the ISY, and it is just fantastic. @shbatm has been one of the leaders in creating the links between the ISY and Home Assistant. Bravo, sir!

@Craigb, I am seeing the same issue with all of my Schlage locks. They worked fine at first, then started having this issue. @Chris Jahn and @Michel Kohanim are aware of this. Fri 10/02/2020 01:34:09 PM : [ZW-SHOW ] ---------------------------------------------- Fri 10/02/2020 01:34:15 PM : [ZW-TX-FAILED] enc=Ok uid=46.0 cmd=0x85.05 ASSOCIATION Fri 10/02/2020 01:34:22 PM : [ZW-TX-FAILED] enc=Ok uid=46.0 cmd=0x85.05 ASSOCIATION Fri 10/02/2020 01:34:30 PM : [ZW-TX-FAILED] enc=Ok uid=46.0 cmd=0x85.05 ASSOCIATION Fri 10/02/2020 01:34:30 PM : [ZW-SHOW ] Node 46 - ZW 046 Den Door to Garage cannot retrieve association groups Fri 10/02/2020 01:34:30 PM : [ZW-SHOW ] Fri 10/02/2020 01:34:30 PM : [ZW-SHOW ] ----------------------------------------------

One of the issues I found after moving to 5.2.0 was that several of my devices lost their "association" with my ISY. While they sort of still worked, they were unreliable. To solve this: Right click the z-wave device in the Admin Console select Zwave => Repair Links

Congratulations Chris and Michel!!!! Long road from 5.0 alpha to today, and much more work than anyone thought. ???

Pentair Intelliflo pumps are well known to create a lot of noise in the electrical system. They are so bad,that you cannot even use a typical GFCI circuit breaker with these pumps. They put out such noise that they will trip a typical GFCI. Only 1 breaker that is resold by Pentair will work. That breaker has an internal noise filter, which is basically an iron ferrite bead built in as a low pass filter. So one idea is to just buy one of those iron donuts and run the pump's feed wires through them to see if that filters out the noise.

Agreed.

I think most people will not have much if any problems with the upgrade to 5.2.0 from a z-wave perspective. So I don't mean to scare people off. I just wanted to share what I did to resolve some issues I was having. The move from 300 to 500 dongle was for some reason very difficult for my setup, and the 5.0.16C to 5.2.0 upgrade made it even more complex. If I had it all to do over again, I would still upgrade to 500 dongle and 5.2.0 software. Things are finally working better than ever in terms of z-wave. I did have to remove a couple older Gen 3 devices, but I was OK with that. And I did not have to remove any of my door locks or move the ISY to them. Those I left in place and just did the steps I mentioned. All my door locks work fine, and they are all VERY old z-wave gen 3 devices.

I recall seeing the same thing for 0.00 bootloader on series 500 dongle. Unless someone else chimes in, I think this is normal. What menu item did you click to get that message?

As an update to my "Green 1011 Icon" issue, I think what caused this originally is that I tried to do a "Repair Links" with a node within a multi channel device that said Repair Links was not supported or something like that. I just remember clicking on do it anyway, and that is what created the "Green 1011" icon and the following attempts by the ISY to continue trying to write to the device. @Chris Jahn, is this something you can look into to see what is going on? Let me know what logs or other help you need.

That is what I still do not understand. This transition from Gen 3 to Gen 5 (not to mention that fact that Gen 7 is now out!) confuses the heck out of me. I think if you have a 100% Gen 5 or greater network, things work well. But in the real world where most of us have some < Gen 5 devices, I think things are more complex. Right now, however, I have my mix of Gen 3 and Gen 5 devices (about 25 of them active) working just fine after: Moving to Series 500 Dongle synchronizing each device, one by one, by bringing them near the ISY "Repair Links" to ensure the correct association between the device and the ISY "Update Neighbors" once I have placed the device where I want it. After doing that with most of my devices, all is well. I did not remove any of my door locks (4 of them, all Gen 3) but after doing all of the above, I was able to synchronize, repair links, and update neighbors where they were without removing them (which is a real pain in the a$$ to do). I think there still might be an issue with Explorer Frames, which as I understand it is how Gen 5 controllers send out requests to find new pathways for devices to use. I have found in the past the some devices simply cannot find a working pathway, even though they have a good list of neighbors, and those neighbors list that device as well. Explorer Frames I think is supposed to find working pathways when needed but does not seem to be working just right.

Not quite. The "Heal" was removed because with 500 series (aka Gen 5) controllers, heal is no longer needed (in theory!). Instead, the devices adjust their paths themselves based on their list of neighbors and last working pathway(s). At least, that was the intention of the z-wave consortium (which UDI does not control). However, when you move a particular device from one location to another, it helps to use the device "Update Neighbors" so that it knows there are new neighbors around. I think there might still be some issues with the ISY implementation that need fixing, but I just wanted to share my understanding of why "Heal" went away. Not UDI's decision so much as how Z-wave wants to work for Gen 5. I personally think there does still need to be something that triggers the entire network to recheck for neighbors and re-establish working pathways, but I am not sure how that works with Gen 5. Perhaps if there was a way to manually trigger the explorer frame process which finds new routes between associated devices, that might help. Bottom line is that I think UDI is working for Z-wave compliance, and they are making changes towards that end.

I too am having the issue of the dreaded Green 1011 icon showing up on some of my devices/nodes. All of them are plug in / always on devices. So not a battery device issue. Normally, I would not worry too much, but this goes beyond aesthetics. I am getting constant attempts by the ISY to force write the device. No matter what I do by trying to write it myself, it always does nothing. Here is what Event Viewer shows, and this forced write attempt appears to happen quite a bit and slows down my system. No, I did not do a node sync, as the log implies. The ISY is doing this all on its own. Getting rather annoying. Sun 09/06/2020 09:17:31 PM : [ZWAVE-NODE-SYNC] Processing Z-Wave Node 44 (0x2C) Failed, node ignored Sun 09/06/2020 09:17:31 PM : [ZWAVE-NODE-SYNC] -- Finished -- ISY/Z-Wave Node Sync -- Sun 09/06/2020 09:17:31 PM : [All ] Writing 0 bytes to devices Sun 09/06/2020 09:17:31 PM : [All ] Writing 0 bytes to devices Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:31 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:32 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1 Sun 09/06/2020 09:17:32 PM : [ZWAVE-WAKEUP 44] Force writes to ZW044_1

Interesting. I have about 25 active z-wave devices. I already had a folder called "ZW Junk" that I put phantom nodes into. That folder has about 30 nodes in it. But in the conversion from 5.0.16 to 5.2.0, only a few more nodes were created. Probably 3-5 of them?

PSA for those with older Gen 3 z-wave devices using 5.2.0 firmware and the Series 500 Dongle: I had been having issues with several of my older z-wave devices. It was impossible to communicate with some of them after the upgrade. It turns out that MOST (but oddly not ALL) of my older Gen 3 z-wave devices no longer had an association group with the ISY. I am not sure if that happened with the conversion to the Gen 5 z-wave Dongle, or with the upgrade to 5.2.0. In any case, I was able to solve this by going to each of my Gen 3 devices and right clicking on them , selecting Z-Wave => Repair Links. In all cases, this restored the ISY to device association and returned them to working just fine. You can also check to see if your devices have lost their association with the ISY by opening Event View, right clicking on the z-wave device, selecting Z-wave => Show Information in Event Viewer => Link Details. It should show a single association to "Node 1 - [This ISY]"

@Chris Jahn, another thing I have noticed that changed from 5.0.16C to 5.2.0 is that many (all?) of my z-wave devices that used to send signals to the ISY when the device was manually turned on or off are no longer sending any communications that I can see in Event Viewer level 3. For example, AEOTEC Smart Switch 6, Z-wave Plus, used to to be able to update the ISY when you turned it on or off using the button on the switch. Now, turning the Plug's switch on or off is not reflected in the ISY. Even more concerning is that there is no longer any Level 3 data being shown when the plug is switched on or off manually. If you turn if on/off from the ISY, it of course reflects correctly. And if you query the device, the ISY will update. This is new behavior compared to 5.0.16C. Any idea why Level 3 communications in Event Viewer are showing nothing coming from these devices when turn on manually? EDIT: Doh! For some reason, some of my z-wave devices had their "communication with associated devices" set to none. I just changed to Basic CC, and all works fine again. And many of my Gen 3 (non-plus) devices needed to have their association with the ISY redone using "Repair Links". Sorry for false alarm, but might be worth others seeing this in case they have the same problem.

@danbutter and others having problems with z-wave network. I am seeing an issue now as well. At first, my network was fine. But I decided to remove 1 z-wave plus device and replace it with another. That immediately killed several of my z-wave Gen 3 (non-plus) devices. No amount of synchronizing or update neighbors would help. Could not query the devices or synchronize. So I had to take each 300 series device to within a few feet of my ISY, do synchronize again (did not lose any nodes or names, which is good), and then do "Update Neighbors" while still near the ISY. I then had to move it to about 25 feet from the ISY and repeat the "update neighbors". Then move it another 25 feet and do "update neighbors" again. Eventually, I was able to 'walk' each device back to its original location and it would now work fine. For a few, I also found the "Repair Links" would help. The only associations I had were with the ISY itself, but for some reason that solved it for a couple devices. That leads me to believe there is something wrong with the z-wave code for updating either neighbors or, more likely, the most recent working pathway. The odd thing, is that the non-working Gen 3 devices did show many neighbors. And the nearby Gen 5 devices that were working also listed the non-working Gen 3 device I was having trouble with in their neighbors list. But the last working pathway appeared stale and would not work. @Chris Jahn, could you look into this? It seems to impact non-plus devices. Their most recent path does not update or does not appear to work. So any minor change in the network, like removing just 1 device, can render all the series 300 devices that depend on that device unreachable. One other thing is that if I can get the "Repair Links" to reset the association between that device and the ISY (the only association that exists), then that sometimes makes them start to work again. Also, I gave my network a full 48 hours to see if it might heal itself, but it never did. I also went through updating neighbors for every z-wave device that was working, but that also did not help restore the series 300 devices that stopped talking. Oh, and all of the devices were always on repeating devices (not battery powered). The good news is that after fixing the non-communicating Gen 3 devices, the network is back to working very solidly again. I am just worried that any changes to a repeating device will cause issues to return due to non-existent last-working-pathway.

It is a bit confusing, yes. Two ways to verify: 1) Look at the rear of your ISY. Is there a blue LED to the right of Port A? If there is, you have 300. If not, and you have a z-wave board installed, then it is Series 500 2) Use Admin Console. Click on "Z-Wave | Z-Wave Version". Or depending on your current ISY software, it might be "Z-Wave | Advanced | Z-Wave Firmware Version" If it says 6.81.00, you have a Series 500 board. If it says 4.55 or lower, you have Series 300 board. The "Z-Wave: 21100" you refer to has nothing to do with the board, but rather is the ISY z-wave software module product number.

I did not have this happen with any of my 30 or so z-wave devices I did a synchronize on. What brand is that device?

Is your ISY on it's side as recommenced? For some reason, laying flat give no signal to me, but on it's side works great.

Did you do a synchronize on any of the devices yet? I would start with the devices that are closest to the ISY or can be brought near the ISY. Do the synchronize one by one so that you can more easily deal with issues as they arise.

Not sure about the new 5.2.0 release, but in all prior releases I always had to bring my device right next to my ISY in order to do an include/exclude. Never got that to work otherwise. Just something I have always lived with. But that was when I had a Series 300 z-wave board. Maybe the 500, along with 500 range extenders, will allow it but not sure.

See comments above, but it is no longer necessary with 500 series. You can still do "Update Neighbors" for individual devices, but otherwise 500 series is self healing.