As I understand it there is more than one technique for a controller to obtain status change information for Z-Wave devices that do not use the Lutron patented status reporting, and polling is not the only way.
Some controllers take advantage of the āassociateā command that the devices send out when they are operated locally. The controller can infer that a physical on/off/dim event has happened and then use that info to issue a refresh and obtain the current status, or I guess, just assume the switch has toggled. This doesnāt violate any patents but may not cover all cases (for example a slave switch in a 3-way setup wonāt produce an associate command). Also not all switches may support that command (but it appears the common GE/Jasco line does).
What may be happening to cause the differences being seen in nearby vs. faraway switches may involve whether or not the associate command is routed beyond one hop in a Z-Wave mesh. Again, from what Iāve googled, it may not propagate through routed nodes, hence the switches close to the hub are getting their physical events reported by associate commands; those going through another Z-Wave repeating node are not.
@bravenel I have now moved upstairs above my family room and Hubitat hub. I have been purposely avoiding two rooms because of requirements of physical logs where I have a GE switch that when toggled, a GE smart outlet also toggles. I went ahead and moved these to Hubitat and I am getting mixed results. The room directly over my family room is my office and the switch is logging physical events very consistently so the smart outlet is behaving as it should through a simple lighting rule.
The room directly beside my office is my son's room and has a similar scenario of a simple lighting rule to turn on a smart outlet from a physical touch of a switch. The switch is less than 8 feet from my office switch but a wall is in between. Unfortunately I am getting mixed results of physical events being logged. Sometimes it happens and other times it doesn't; most of time the events don't get logged.
I moved over other switches in my son's room as well such as his fan switch, and a switch that controls outdoor flood lights so again mesh isn't an issue. All of these switches turn on immediately from digital events from the browser.
Please let me know if you have any ideas or additional things you would like me to test.
Unfortunately I am having to move devices back to ST because of this issue. The engineering team has been quiet on updates to this problem, getting no responses but hopefully fixing it, and my home is broken while these devices remain on Hubitat. I realize this is a complex issue to fix and confident they will come up with something.
This also means I am done moving devices over and my 80+ existing devices will remain on ST until this issue is fixed.
Hubitat staff, I am happy to help test a fix once you determine a solution so please let me know.
I donāt think they are not talking about it.
Devs stated it is in works and will be released in next update.
That pretty quick compares to another platform where known bugs running for more than a year.
when I reported info about a problem they purchased device immediately to troubleshoot that problem.
itās four days, that is probably not enough time for a device to be delivered.
on the other side. that makes me think that using physical devices is my automation plan fail.
my goal is to automate everything. need of touching something is my fail.
I havenāt gotten confirmation itās in the next release. I started this thread 13 days ago so, much longer than the 4 days you mention. But my family still depends quite a bit on physical touches. Examples include turning on bathroom fan if shower/tub light turned on. Things that are difficult to automate via motion, etc.
I havenāt given up, just had to do what I needed to do. I even offered to ship them a switch or two for testing.
This is exactly the way I see it. I have about 3 light switches in my house that are ever touched by anyone, and generally that is for turning off a large set of lights before motion time-out would turn them out. I'm pretty sure I'm the only person who ever does that. Otherwise, light switches are pretty much an anachronism for us. My wife doesn't know what the dozens of them do, nor does she care.
ST solved this problem by throwing a bus at it -- they poll every Z-Wave device every 10 seconds. We don't think that's an acceptable solution to the problem. We will bring forward a solution that makes more sense. I'm not going to state a time frame for that to be released -- we are addressing it.
I appreciate both sides of this thread. Is a possible temporary solution to enable polling every x seconds of all zwave devices in the next release then roll it back with a more elegant solution. Ideally the temporary fix could be a setting that is enabled with the polling frequency as a setting.
I found your usage of switches interesting. Even with 30+ motion sensors, we still use switches / apps frequently. Sometimes for on / off, but often for adjusting dim level.
We have a dozen of those damn alexa dots and a dozen more in the drawer. Once a week I get angered by one of them and it goes flying. It is great most of the time, but when she is not she is maddening! As far as using the exterior lux levels I struggle with that, in MN it is dark too many hours for that to be ideal at times, but I have also gone through iterations of logic that always prove to be flawed. if before 5am level 25 in bathroom, if light on 5 min increase gradually to 100%, etc. inevitably, the wife wants it lower longer or I want it brighter sooner. I think the most reliable (and possibly cheapest way) is to duplicate all rooms in ones house (his/hers) and automate seperately
What custom command would you invoke? I setup a rule to execute refresh and the event log had tons of events of physical off over and over again every time it ran. I removed it as I do sometimes look back at logs.
We are going to have a better solution for you in the next release. Rule Machine is getting enhanced in two ways: First, it will support Periodic triggers in seconds, so you could trigger something every 10 seconds. Second, it will support Refresh as a built-in action ā no need for a custom command.
With these two enhancements you will be able to refresh those lazy-reporting devices as needed to capture events not being reported by the device in a timely way. You would only expend mesh and cpu resources as required for your devices, and not waste same on every device.
With respect to the logging issue, we are looking at providing a filter mechanism so that you can weed out the non-events caused by refresh, and see just the real events from the devices actually turning on or off.
Awesome thank you! Just so I am clear is the Rule Manager refresh functionality the final solution to solve this problem or are you still working towards a better solution? I ask because 60+ GE Zwave switches and outlets in my home and I will have to setup rules for all of these which isn't ideal. Of course many of these aren't used as often as others, but it would still be awesome to have a built in feature that doesn't require setup through a rule.
Awesome thank you very much! I created this thread to suggest a few things about device events filtering if interested.
No, you would only have to setup one trigger in Rule Machine for this, and select the devices you need to refresh. We will have a fix for the logging issue also, but donāt need the filters. This is the fix for this. Bear in mind that STās fix for it is to poll every device every 10 seconds. So this is better. There is plenty of CPU power for it, and obviously the mesh can take it, so there you go.
Thank you for confirming. My only feedback is this isn't going to be that obvious to new users and it needs to be well documented. Some of the most popular threads in ST Community have been about GE switches going on sale or on clearance at various stores so I know I am not the only one with tons of them.
My low priority suggestion would be to create a specific GE driver with a preference to "enable automatic polling" with a selection of timings - similar to the generic zigbee outlet driver with the additional preference. Behind the scenes you could create rule that does this automatically for the user.
I know you are focused on new apps and I agree, but if you plan to market Hubitat to the masses, the little things will need to made easier.
Agreed.
I cant imagine new inexperienced user will ever research need for a refresh of a specific device.
This has to be built in, some sort at some point.
You guys don't get it. This is superior to what you are used to in SmartThings. If you want snappier response from these lazy devices, crank the rate up. I don't know at what point that becomes counter productive, but no doubt that will depend on how many devices you run it against.
We will fully document this, and no doubt this Community will pitch in. "building it in" doesn't mean that people are immediately going to find it. We certainly wouldn't do this to the default driver. Even if, as suggested, we put it in a special driver for a lazy device, there is no guarantee that (a) that particular device even needs it, or (b) that the user would know to set it. Either way it's going to take some guidance. The approach we are taking is superior.
The engineering team has been quiet on updates to this problem, getting no responses but hopefully fixing it, and my home is broken while these devices remain on Hubitat. I realize this is a complex issue to fix and confident they will come up with something.
