upstatemike

This of course is one of the problems that Matter will solve once and for all.

I think I am going to give up on Z-Wave and return my small test area (about 20 devices) to Insteon. Z-Wave just consumes too much effort every time I want to change something and I still can't get groups and associations (direct or programmatic) to work the way I want them to.

Interesting. The Leviton switch must use a different strategy for speed control from the internal switch. Maybe PWM?

I edited my post because I meant Elk, not ISY. My ISY uses a different email account but it should work the same. When you turn on 2 factor authentication in GMail it will give you an option under security settings to generate an app password. In ISY email settings replace your regular GMail password with the 16 character app password. Don't make any other changes to the email settings and everything should resume working.

I applied the 2FA fix to Elk M1, Blue Iris, and my PC that is still running Outlook 2010. Worked fine on all of them.

I like the way Pico remotes match the styling of Caseta switches so they mix well in a multi-gang plate. If Caseta switches to the Sunnata look will there be matching Sunnata Picos as well?

This is why I question the longevity of Z-Wave. It just doesn't seem like the protocol is well thought out for what consumers need (maybe was designed more to satisfy the desires of manufacturers to get companies to buy in?) In my application I use Zen32s to control Hue bulbs. I use the large button to control on/off and the four small ones to set a color. The leds on the four small buttons are left on all the time and act as labels to show what color they will set. The LED on the large button changes color to acknowledge what color selection is currently active. I had to use a value of 2 for the relay disable parameter to keep the relay on and disconnected from the paddle and also non-responsive to Z-Wave commands so that I could make the on/off status of the large button LED stay in sync without actually operating the relay. I use 2 programs for on and off. 4 programs for the small buttons to set the colors, and 2 programs to ensure the large button stays in sync when the lights are controlled from Hue switches or motion sensors, the Hue app, or from an ISY schedule. In the end it works well but I would never use it to set up control for somebody else because it is too labor intensive and has too many potential points of failure if I ever had to troubleshoot a problem.

I currently use Alexa routines for relaying Yolink stuff. The Yolink local API is a little behind schedule but should be out soon. Like you I am hopeful to see a Yolink node server very soon after that.

I'm curious where you are going with the "no additional amplifiers" thing? All radio technologies, including Wi-Fi, have the potential to require some sort of repeater to ensure a good signal path to all parts of a house, especially if there is a lot of stone and brick and metal to deal with. Some technologies use the end devices themselves to provide the repeating which I don't care for because if you need to service. or just want to change an end device in your system and it was the critical path (no alternate route available) for other parts of your network to get a signal then that simple device change can quickly become a huge headache. I prefer dedicated communication radios that provide a backbone for the system that no single endpoint device can disrupt. Lutron Caseta, Lutron Radio RA2, and Yolink LoRa devices work this way. You can also get Z-Wave to work this way if you use multiple Hubitat hubs or Homeseer Z-Net radios as your interface so all devices talk directly to the interface. For me, Wi-Fi and Zigbee and Lutron Radio RA3 are non starters because they use 2.4GHz which I think is a much bigger problem than needing repeaters will ever be.

I had a similiar issue with a continuous on/off loop. Turns out I had some direct association set up that was in conflict with my programs. I complained to Zooz about how hard it was to get this device to do what I wanted and they were at least very receptive to trying to understand the details even if they can't really do much about it until a future firmware update or next hardware generation release of the product. I suggest you contct them because the more people they hear from the higher the priority they will place on fixing it.

Still curious why Zooz designed this device the way they did. It really needs 11 separate registers to track the state of the 5 buttons, 5 LEDs, and the load relay. Depending on the controller to keep track of things is bad design practice. If your controller has to reboot for some reason it can't just query the switch to get the current state of everything because there is no persistent place to store all the state values in the device.

Did something similiar in Homeseer except instead of the buttons controlling a fan they control a set of Hue bulbs and set them to a specific color. As a bonus I set the LED color for each button on the Zooz switch to match the color the lights will go to when that button is pressed.

It would also be good to note that IoP is not exactly the same as ISY on a 994i especially if you use Elk integration. I am a heavy user of Elk connected motion sensors and use my ISY as the bridge to trigger Alexa routines with them. I also use Elk voice responses to Insteon actions quite a lot. I probably can replicate all of this with an Elk Node server but I don't know that for sure or what kind of time investment would be required to reconfigure everything if it is possible.

Direct association only works between two devices that are in range of each other to talk directly. The feature that you need to replicate Insteon functionality is "Assigned Association" which allows communication between two devices to be routed through the Z-Wave mesh without needing to be in direct range of each other and without needing to pass through a controller. Do Smartthings and Hubitat support that configuration?

I wonder if the mythical Nokia switches will have this feature? It would be a logical thing to add if you were doing a modern product redesign.

I think the root of the problem is using routing for automation communication in the first place. If you use broadcasts and have each neighbor repeat everything instead of calculating where to send it you have faster response, a more robust mesh, and avoid isuues like popcorn effect or the main controller not being aware of status chages made by local actions or direct associations. I hope the up and coming new protocols avoid going down the routed communication rathole. I haven't seen anything specific about Lutron RadioRA3 communication specs but the setup instructions, ensuring each device is in range of at least two others, suggests it is using repeated broadacsts rather than routing.

This website creates more questions for me than it answers about the complexity of the Z-Wave protocol: Why are there "routing slaves" and "normal slaves"? Why aren't all line powered Z-Wave devices capable of routing? Why have Direct Associations? Even battery devices should be able to be associated using the routed network to reach the destination device. What exactly is a "static controller"? Does that mean there are also "dynamic controllers"? It looks like Z-Wave implements scenes by sending a routed message to each device in the scene as to what setting it should change to. This sounds very slow and inefficient. Why not simply use a broadcast to trigger a scene number and have each device already know how to react to that scene number and adjust itself accordingly? It seems like 1 broadcast message would make a lot more sense than many sequential routed messages.

I'm assuming in this conversation that "ZWave native scene" refers to scene capability as defined within the ZWave protocol and "ZWave Scene" refers ISY scene capability as applied to ZWave devices... have I got that straight?

I haven't set this switch up in Polisy yet but I have used it in Homeseer and it pointed out to me the baffling and unnecessary complexity of the Z-Wave protocol. It is pretty basic and the expectation is that it would provide 11 devices to work with; 5 buttons, 5 LEDs, and 1 relay, and that there would be a register that tracks the status of each and allows for control of them. Instead only the relay is available for status reporting and direct association. For some reason not adequately explained, the 4 small buttons just change the value of a single Central Scene register and do not maintain any status of their own. The LEDs toggle when the associated button is pressed but that state is not exposed any place so you have to track status in your controller logic and use parameter commands to force the LEDs to reflect the actual state of the scene, load or whatever. I have never found any documentation to explain why Z-Wave is set up this way but it makes it a lot more complicated than it should be both for end users and for anyone trying to design a home automation controller with an easy to use rules engine. I know this doesn't help Robert in setting it up in Polisy but if in the process of resolving his situation somebody could explain why Z-Wave is designed this way in the first place it might provide some perspective on how come things that are simple with Insteon can become so challenging when translated to Z-Wave.

Not having any trouble doing green with Hue A19 bulbs. How can I reproduce the problem you were seeing?

Maybe they will remain PG2. There will likely be several things that don't get moved to PG3 so I think we need to plan on running both.

All my bulbs show maximum Wi-Fi signal so I don't think that is the issue. All have reserved IP addresses so no contention there. They just drop for no reason. With Hue if I change the color of the room all 8 bulbs change at once. With Lifx six maybe seven will change. I'm not saying Robert would have the same issues as me but just making him aware that this stuff happens with Lifx bulbs and probably other Wi-Fi bulbs as well.

Just checked my Dining Room bulbs and they are at firmware 2.80 which it says is "up to date". All 8 bulbs show Wi-Fi strength at 5 bars and bulb 4 just keeps dropping and reconnecting every 10-15 seconds... Now bulb 3 just dropped off. This is just too fiddley to live with. I like the colors with Lifx but I like the reliability with Hue better. I don't know how to force an update to 3.70 if the app says they are already current at 2.80?

I am curious about your color concerns with Hue as I have had many color issues with Wi-Fi bulbs. I tried a few like Philips Wiz and some others and found that most of them had no color saturation and could only do pastel shades. They also seem to struggle with deep purple and indigo colors and try to use magenta in place of purple. Can I get the deeply saturated Indigo colors from MagicLight bulbs? If so I might try some.