I have three V3 hubs that I want to be on the same Thread network. However I want them to be otherwise standalone as hub groups haven’t worked for me. The problem is that they don’t seem to like the idea of using different Zigbee and Thread channels.
My main hub is on channel 12 for Zigbee and Thread. If I try and set the Zigbee channel to 11 and 14 on the ‘spare’ hubs they will change the Thread channel on all three hubs to 11 or 14 too. If I then temporary change the Zigbee channel on my main hub away from and back to 12 I seem to get the desired result of three Zigbee meshes on 11, 12 and 14 and a single Thread mesh on 12. Except I just looked at my hubs and everything is now on 12 and I didn’t do it.
So the questions are:
Are my aims reasonable?
Are they achievable with the ST hubs?
Is having three Zigbee controllers in a relatively small area all using the same channel likely to cause any issues (bearing in mind two are only acting as TBRs and hub replace candidates)?
This post was prompted by my trying to figure out what is causing increasing numbers of complete Zigbee outages which can variously disappear after a few hours, be instantly fixed by power cycling a single device (which has been replaced), or eventually respond to twenty minutes of frantic reboots and power cycling. I have long since reached the clutching at straws stage.
I remember a discussion of this way back when thread support was first announced, and the bottom line is that they are using only one radio for both protocols and doing a sharing system where it keeps switching back-and-forth from the Zigbee to thread with the single antenna. That’s not uncommon, but it does mean that thread and Zigbee will always be on the same frequency. To have them be on different frequencies you need two radios, and that’s not how the smartthings/aeotec hubs are designed.
Is having three Zigbee controllers in a relatively small area all using the same channel likely to cause any issues
As for this, it comes down to the amount of traffic on each controller. Bearing in mind that the thread transmissions can also cause interference. So yes, it’s potentially a problem, but in practice, it may not be an issue.
Zigbee and Thread have different packet formats so receiving them on the same radio and frequency would not really be a problem. Just like back in the older days when you might have different network protocols such as Appletalk, Novell IPX, DecNet, TCP/IP, etc all on the same wire. They could all be received on the same ethernet interface and the incoming driver would direct the traffic to the appropriate protocol stack for processing.
Yes, I can remember the early conversations and indeed that I was one of those who favoured the frequencies always having to match. My recent confusion has been caused by the channels reported in the AWA not always being the same and so creating the illusion that I was wrong to think that.
I still don’t have a firm grasp what the warning message associated with the Zigbee channel change is really trying to say.
All this does make hub groups seem the more elegant solution in some ways. However the effective range between primary and secondaries is incredibly low and they are just too fragile. Hub groups would seem to be a better idea if Zigbee could be disabled on the secondaries. You don’t want to form a mesh that depends on more than one of the hubs for its strength, you want one that can work well with any single one of the hubs being the last one still working.
It also kind of justifies SmartThings’ seeming reluctance to unify Thread networks in the past.