So I have been trying some alternative pairing strategies, while Fibaro Dimmer 2. I use the DTH that runs local (the one that it automatically detects when pairing in ST.
11 Dimmers in a 70 sqm apt. (2 bedrooms, one living room, one kitchen, one bathroom)
These are the various strategies I have tried (then I unpaired the devices, so took a lot of time:) But since I moved into a new apartment, I set up the hub again from scratch so had the opportunity to do some testing.
Pair randomly, hub located at the entrance door
Pair from the ST hub and out (hub located at the entrance door). This means that i paired the devices closest to the hub first, and then moved onfurther into the apartment
Pair from the hub and out, but hub located in the center of the apartment. This means that i paired the devices closest to the hub first in each direction, think of it as a circle that expands outwards. After, I hhen moved the hub to its final destination at the entrance door
Created scenes (all lights off / all lights on), then tested many times
Also tried a z-wave repair at the end of each test when hub was located at the entrance door after 1, after 2, and after 3. It never increased the speed (waited 2 days after running the repair)
Nr 3 resulted in the fastest response time.
Interestingly, a zwave repair actually lowered the speed in case 3.
The speed to execute the light off automation in the app was about (on average) 2 seconds in case 3.
3 seconds in case 2. And about 4 seconds in case 1.
Of course this is not a statistically test:) But I still think it is interesting if we can find out “pairing” strategies that optimise the speed.
Anyone with theories and ideas/experiences about pairing a z-wave network vs response time?
I was a network field tech working with Z wave and zigbee before I ever got a smartthings hub for my own house four years ago.
Since a zwave repair rebuilds every single routing table on your network, once you run one successfully it shouldn’t make any difference how the devices were paired in the first place. You’ve rebuilt the entire system anyway.
Whether there is some other weird variation introduced by the cloud aspects of the smartthings platform, I can’t say, but that’s the way zwave itself works.
And while unfortunately smartthings does not give us any network mapping utilities, in a layout such as you describe most devices will be able to communicate directly to the hub in one hop.
All of that said, most field techs, including me, would use a pairing method most similar to your method three when laying out the backbone of a network.
Have you had a chance to look at the FAQ on wireless range and repeaters?
Start with post 11 in that thread, then go back up to the top and read the whole thing. ( The topic title is a clickable link)
I would also add that your “all lights“ test is the one that is most likely to run into glitches caused by the platform rather than by zwave. Because smartthings doesn’t implement the grouping options available for zwave like central scene commands. SmartThings’ “scenes” are not zwave scenes and do not use the zwave scene commandsets.
A more accurate test of your pairing protocol would be to test just one light on and off, but using three separate lights: the one closest to the hub, the one physically farthest from the hub, and one about halfway. So you would be running three separate speed test each time, one for each device.
Once you start doing scenes, whether locally or in the cloud ( do scenes even run locally? They didn’t used to), you’re out of your Z wave logic and into the SmartThings platform wraparound logic. So who knows what happens then? .