So, let me start by saying I've had 2 smarthomes on Vera Plus units for about 10 years with every single light/lamp/door/deadbolt/water/etc covered.
I got the c7 when we sold our primary house and left all my disparate devices and bug-prone Vera Plus with the house since they were older and mismatched and Vera restarts every 12 seconds...
In our new house, I got all new stuff (90% Zooz) and began pairing up. So far I've only added about 35 devices and a few apps. I am playing around with RM and others (coming from mostly Reactor logic in Vera) and getting the hang of it.
However, I'm noticing a way too frequent basis that the hub is becoming completely unresponsive to zwave communications. At best, it's hit or miss on shutting off all lights when leaving etc. I have "safely rebooted", disabled/re-enabled the zwave radio, direct LAN vs wifi client adapter, etc.
I ran the topology map and its pretty heinous, even after building my mesh by starting with the devices closest to the c7 and placing it center in the house and working outwards.
Anything stand out as a suspected cause and remediation?
Here are my devices and apps and I can provide other details if helpful:
Devices
ZEN21-VER4 Zooz Z-Wave Plus On / Off Light Switch
ZEN30 Zooz Z-Wave Plus S2 Double Switch
ZSE40-VER2 Zooz Z-Wave Plus 4-in-1 Sensor
ZEN27-VER3 Zooz Z-Wave Plus S2 Dimmer Switch
ZEN15 ZOOZ Z-WAVE PLUS POWER SWITCH
Apps
Chromecast Integration
Event Engine (added since issues)
Groups and Scenes
Honeywell Home
Hubitat Package Manager (added since issues)
Hubitat Dashboard
Let's Get Started!
Life360 Connector
Lock Code Manager (added since issues)
Maker API
Motion and Mode Lighting Apps (since have deleted all children)
This is most likely the biggest problem you have, these are not compatible with the C7 Hub if you look in the Compatible Devices list. This can wreck havoc on your Z-Wave mesh.
Try removing them from the mesh and see how it behaves.
I actually saw a similar comment and therefore removed it - which had to be done forcefully after several failed attempts of typical exclusion. I still mentioned it here because #1 I have included it and removed it, could have lingering issues and #2 I have 3 I plan to install and still am unless they really are worthless. (Maybe an updated driver soon or config setting that could resolve..?)
It no longer shows up, and will say it was a bit more stable, but the core issues remain where many commands are failing and nothing can be trusted to complete from a scene being activated.
I should have mentioned I saw that in forums and checked that as well. Looks like the steps were to refresh, refresh, refresh, etc until you get 'remove' and I did that on the one I found. I just checked again and there is a single entry again, so I'm going to remove that one like before.
Update: the single ghost node was 'removed' and no longer showing up.
Still leaving some devices unchanged after scene being activated.. I just noticed a platform update, so trying that. I will say it's incredible the amount of work being done on updates. Vera got them so rarely and they were almost always disastrous. The amount of 'new' and fixes in each update and the frequency are amazing. Kudos and much appreciated!
Fingers crossed this has anything to do with it...
On the topic of 'completing' scenes, is there any method to give some sort of notification when all devices are in correct settings?
Use case: All lights off, doors locked, porch lights set to proper dimmed level, etc. and result in notification "Successfully completed goodnight"
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.
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.
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).
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?)
