A while back, i set up a some lighting using Fibaro Dimmer 2 and direct association (so RF comms is between the Dimmers, not via the Smartthings Controller)
Details here:
I also got an XStick recently to map out/optimise my Zigbee network. As part of that, I unplugged (and removed the batterys from) my Smartthings Controller for 15-20 minutes.
During that time, i flcked the light switch that controls the direct association, but the light did not come on for a good 5-10 seconds. I tried the other two switches with the same setup - same issue. Same when I switched off again.
What’s going on here? Did removing the Controller from the network put all the devices into panic mode and they swamped the RF airwave with messages that caused an issue with the direct association communications between the Dimmer 2 devices?
Two completely separate networks: zigbee and zwave. While the hub handles both (two separate radios inside), And there’s a potentially a bottleneck involved with getting messages to the cloud, Once you take the hub out of the picture, the Z wave devices would be completely unaware of any zigbee message traffic. And Z wave devices don’t go into panic mode the way zigbee devices do. And since they operate in a completely different bands, you shouldn’t get any bleed pover swamping, either.
So with the hub unplugged, your Z wave direct associations should be operating independently of anything happening with using the zigbee devices.
Are you saying that when you pressed the light switch that the micro is Wired directly to that specific fitting did not come on for 10 to 15 seconds? Or are you saying that when you pressed the trigger lightswitch get the master is wired directly to, then the switch which is directly associated did not come on for 10 to 15 seconds? Or are you saying that when you press the auxiliary trigger light switch ( that the fitting is not directly wired to), The target light switch which the trigger is directly associated to did not come on for 10 to 15 seconds?
In any of these cases, when’s the last time you ran a zwave repair, and what error messages did you get, if any?
Also, you might consider using the Z wave tweaker to verify that the associations you believe you set up are in fact the ones you set up.
Finally… If you set up reciprocal direct associations, which some people do to try to keep the statuses up-to-date, That can cause problems. The zwave standard isn’t really designed for that.
Good point on the z-wave v zigbee frequencies and no z-wave panic mode, so that RF overload thoery is out of the window.
I don’t have reciprocal associations set up.
In the simplest case I have a Dimmer 2 behind a wall switch and that has a one-way direct association to another dimmer that controls a light. That second Dimmer is always on, but does have with a mater override switch for maintenance.
What I saw (consistently) was, when i unplugged the controller, there was a delay between switching the physical switch (to which the first Dimmer 2 is connected) and the light (to which the second Dimmer 2 controls is connected) coming on.
What i didn’t do was look int where the latency was being introduced.
There is no noticable delay when the controller was active. I’ve done z-wave repairs prior to this with no errors.
I’ll do more analysis, including the tweaker, though the Dimmer 2 DTH shows the correct Node Ids and its working ok otherwise, so I can’t see there being anything wrong there.
Is this still the setup Described in the other thread where you have configured the bypass in a way not recommended in the manual? Or is this something else?
I ask because the Fibaro devices have a lot of complex self-calibrating logic built-in and operating them against spec might produce some unexpected results.
If you want to get deep into troubleshooting, what you might do is set up a direct association between two other Z wave devices which are not self-calibrating and see if those show the same kind of lag.
Yes, the same setup with the bypass but no there lad on the local circuit. I’m not sure why that would be different with the Dimmer connected to the Controller or not, but I guess we don’t know what its doing internally.
I did wonder whether the Dimmer losing connection to its parent was causing the delay - so its trying to communicate with the controller before sending the direct association messages.
It shouldn’t work that way: direct association should always send a message directly from the trigger device to the target device without going through the controller. That’s the purpose of that protocol. Direct association should just happen every time whether the controller is available or not. It’s a very basic process.
That’s why I would tend to suspect something on the Fibaro side regarding their own fancy calibration logic. I suppose it’s possible that that might try to talk to the controller first, but that’s not part of direct Association, that would be part of the Fibaro calibration process.
That’s why my own next step as a field tech would be to see if the same issue is also occurring with non-Fibaro devices.
If it turns out to only be the Fibaro devices, then I would get in touch with their support.