Personally on my system I don't really find them compatible on the C-5's either. I have 4 of them and use them solely for humidity monitoring ONLY and have positioned them so that they do not pick up motion at all. I was seeing the logs continuously flooded when motion events occurred slowing the network down. Now each device only logs between 10-13 entries per day.
Yes and No. This is a somewhat common question and it is one that I also had when I first started with Hubitat. The short answer is: it depends on the drivers.
In order to illustrate this, lets consider two possibilities as to how the hub may function:
Possibility 1: A command is initiated to turn off a zwave switch, the hub sends a zwave command to the switch to turn off, it also then changes the status of the switch to off. The switch is now off if it received the command, or the switch is still on if it did not receive the command. Either way the hub reports the switch to be off.
Possibility 2: A command is initiated to turn off a zwave switch, the hub sends a zwave command to the switch to turn off. The switch receives the zwave command to turn off and turns itself off. The switch then reports back to the hub that it received the command and turned itself off. At this point (and only at this point) the hub reports the switch to be off.
Which possibility represents the way it actually works? The answer is it depends on the driver for the particular device. Most drivers, including all built in Hubitat drivers, would implement possibility 2, but some custom drivers do not. So it is easy enough to create a notification that an automation has completed, but depending on the driver the notification may not be accurate.
Edit: ok, I'll take Mike's word for it and change this to "some". Mostdrivers do it like #1. Fire and forget, assume the message made it.
This makes dashboards and some automations work faster, at the risk of out-if-sync status.
In general I've been migrating the drivers I support to style #2, but it is a work in progress.
3 Likes
Hi Jason, thanks for the clarification.
Quick question, on a well functioning strong zwave mesh, what is the extra delay a user might typically see on their dashboard if method 2 is used. On my current dashboard if I tap a switch it changes to off immediately (or at least it feels immediate). Would method 2 result in a dashboard delay of more than a second?
None of our internal drivers send a command response event (ie a state change event) unless it was received from the actual device.
Our drivers depend on a device being capable of reporting their state changes without polling. This is the reason the older GE Z-Wave switches don't sync, they don't always report state changes.
5 Likes
Had some problems with these as well however, after reading this post and following the directions, all is well
Has that always been true? I really don't think it was. I'll go find the discussion on this topic when I have time, and refresh my memory though.
Every driver I have seen operates in this fashion .. Commands are sent.. Events are driven by reports from the device..
Ok, cool.
I can definitely say that is not true of all user drivers. I just looked in my personal stash of ones I've used as templates in the past and found at least 10 that updated status/event immediately and not on the report.
That's good that the in box drivers are right, though. I prefer the way you guys are doing it.
Need to go back and audit my drivers and see if I have any left that do it the 'wrong' way. I think I do.
Depends on the device. On a normal device a couple hundred ms at the most.
There are some weird devices, like the new GE Enbrighten dimmers, where it can be as high as 2s though (although there is a workaround for that specific issue on that device).
2 Likes
for as long as I've worked here, which is, well, since the start...
Most ST drivers are/were written this way as well.
2 Likes
You mention Lock Code Manager, but don't list any locks. Are you using z-wave locks?
Apologies, yes I am using one Schlage BE469 (soon to be 2 once i get it installed) - but these issues were before installing it a couple days ago. BTW lock code manager is a great and well done app! love it!
I just created another simple scene to just turn on the lights in all rooms and here's what I get after 'activating' it via dashboard button. #1, after setting active/green it did not complete and therefore shows as not active/grey. Here's a screenshot of the scene captured/current states and it's all over the place. Some devices are showing off in the screenshot but in actuality are on. Walking around the house to visually confirm, there are 6 out of 18 that didn't turn on. 4 of those 6 were the fan/light combo switch from Inovelli (LZW36?)
Is there a way to identify these older switches? Do they have a unique manufacturer ID & Product ID?
Aren't they (the old GE Z-Wave switches) Non-Z-Wave-Plus? Thus no cluster 0x5E.
3 Likes
correct
To elaborate -
For a zwave device: Go to the device detail page for the device (click on the device in the Devices page on the hub), scroll down near the bottom and look for "inClusters". If the 1st one is 0x5E it is zwave plus - it it isn't, it isn't.
2 Likes
Most excellent t information!!!
Using this, I've got 8 (out of 63) Z-Wave devices that are not Z-Wave plus. Is it worth upgrading them? Like the OP here, I've had lots of problems with the dependability of scenes and groups so I'm always looking for anything that will make my network more dependable.
No right or wrong answer there. In my OPINION, yes it is worth replacing them, and here's why:
The main PROs for replacing them:
- Automatic status updates from device to hub without polling the device manually/periodically
- Up to 2.5X faster ZWAVE message data rates (40kb max vs 100 kb max). This applies both to the new device AND for any other zwave plus devices that happen to be routing through the older non-plus device (if any are)
- More resilient mesh in that devices can send out Explorer Frames if they can't communicate to the hub, and re-route their messages based on that info (alleviates most of the need to do manual zwave repairs)
- Sometimes new/more/better features you didn't have before (default ON brightness settings, programmable LEDs, multifunction devices like Motion Dimmers/Switches, etc).
The main CONs for replacing them:
- Cost
- Should verify that the new device can do what your old one did (almost never an issue though)
1 Like
Would setting up groups and turning those off rather than the devices directly help with reliability?
Welcome to Hubitat and the community here. I read this thread and found numerous similarities to my recent experience. I migrated from Vera many MANY years ago. At that time I migrated from Vera to a Hubitat C-3 (ancient now) hub. Recently (a few months ago), I migrated from C-3 to C-7. At that time I rebuilt my mesh which is the only way in that migration case. Following threads on this forum I had a painless process. But then I started seeing the "never completes" or "forgotten devices" phenomenon when calling scenes. What was even more baffling is that adjusting individual devices from their device pages, dashboards, or apps (rules mostly) would be perfectly smooth and instant. But scenes? Failed nearly every time but it would be only one device out of a 20 and often different devices that were missed.
Nothing seemed to fix it and I did try "everything." Now I have a perfectly performing system and ZWave events seem to be instant and simultaneous. I had to rebuild my ZWave network one more time but this time without any security. No S0 nor any S2 in any of its forms. I did this at first as an experiment because it was the only difference between my C-3 network (which worked perfectly) and my C-7 network (which was disappointing). If you have a majority S2 included devices I suggest you try this. It is not a permanent solution for me as I would like the security one day when I can use it. Certainly if I had any locks or other devices for which I would want security then I would include them with S2. But for dimmers? Switches? I gave up so that I could return to smooth operation.
