Great point! RF interference can definitely make or break a protocol’s reliability, and having both Zigbee and Z-Wave backbones gives you great flexibility. I agree that Matter still needs time to mature
Zigbee as a base as there are more options out there then Wifi and Matter over Wifi are my choices currently as I have had issues with my Matter over Thread configuration breaking this last snapshot restore when I was upgrading to 2024.11.4 (its a nuisance to clear the play services just to redo the thread credential sync to a new configuration and this needs to be resolved on the android side before I invest in thread again).
The easier it is to restore a configuration and setup the better overall long term use it will get is how I look at things.
I have had no issues with devices working after a restore when it comes to zigbee and matter over wifi so far, its just the thread version that is a pain like I said.
That makes a lot of sense . Zigbee’s reliability, especially during restores, is definitely a strong point. The issues you mentioned with Matter over Thread sound like such a hassle
I can see why it’s holding you back from investing in Thread more heavily right now. Like you said, the easier it is to restore and set up, the better it’ll work in the long run.
Matter over Thread, Zigbee and WiFi all use 2.4Ghz and you share that frequency spectrum with all your neighbors, so interferens is a thing to consider.
WiFi is sort of needed, but also high-powered star networks, which makes a relative stable network.
Matter and Zigbee are low-power mesh networks, which are sensitive to interferens, so avoid to run both at the same time and in the same physical space.
Choose one and stay with that.
Matter is the future, but Zigbee is the present.
That means Zigbee have all the devices available now and today.
Matter devices are limited, but the protocol patch sone of the issues with Zigbee, like single point of failure with only one coordinator and lack of multi administration.
For me it is simple.
As I ordered one of the zigbee sticks with theoretically using dual mode (threads and zigbee) this one crashed and I currently fall back to Zigbee.
The option to use just Thread was no option as I ordered a few devices with matter and zigbee.
As the Matter connection could not be established the zigbee ones could. So I focus on zigbee for the moment, send the matter blubs back and ordered zigbee bulbs.
As soon as thread dual mode works, I will try dual mode again.
But for my point I don’t see an advance using matter when I can have all working devices with zigbee now.
And Wifi still works for devices too.
If you’re talking about multiPAN don’t hold your breath. You’re beteoff getting two sticks. There’s problems with it at the silicon and firmware side so the HA matter team is not working on it at all.
Read: if. You want to do this anytime soon. Get two sticks.
Yea the only devices in my setup currently that were thread based were my Aqara P2 sensors and I was using a GL-S200 for the border router.
I will retest them in the future should more firmware updates come for the router but at this time its just one of those annoyances that I really cba to deal with when it comes to ease of getting things back up and running when I need it to be done.
Was just disappointed at the fact that on restore of the snapshot it had completely wiped out the configuration I had even in the snapshot backup… oh well.
That is what zigbee promised at the start too. I wouldn’t bet on it - too many vested interests by the same companies that were part of the zigbee alliance.
My honest suggestion: go zigbee for the short- medium term. You’ll get a wider selection of devices with more stable performance at cheaper prices.
Then, when and if those devices start to age out and need to be replaced, look into any suitable matter alternatives. At the very least, by then you should hopefully get a more stable product with a wider choice and you won’t be a guinea pig.
Yeah that was disappointing.
But I always start with save configuration, so I never go live without testing. So I only lost the first day trials.
For further testing I advice a second server with a second router (stick) where you can plug the stick. While you get a new unique database you can test.
But this means whenever your main stick is broken, you will loose the whole config of the zigbee network when replacing with a new stick.
The problem more so is the fact that on android you need to clear your google play services at the current time to update to new thread credentials via the companion app and this in turn wipes things like saved cards in your digital wallets which are a pain to reactivate when its card that your parents lend you for backup use lol.
I don’t have any apple devices that seem to not be affected by this to use as a workaround.
There was nothing changed with the config between the snapshot and the settings on the GL-S200 but for some reason it appended a #0A0D for example to the end of it on restore and overwrote with different credentials when I did not even ask it to, this is something that needs to be addressed imo as well as it should not be doing this when you restore from a working state of saved settings and credentials.
I already have the T1 version of the sensors coming in a day or so which are zigbee based and as stated will retest the thread device setup when I see more updates to both the TBR and Thread in this regard to my findings so far.
WIFI/Ethernet based ESPHome devices only. Why? When building new use wire (ethernet) as much as possible. Other than that you (most likely) will have the perfect WIFI infrastructure already so it should really be a no-brainer. Building a new zigbee/thread network from ground is painful and mostly forces to install mains powered devices (acting as repeaters) on places you don’t even need - just for the basic coverage and stability
Many people that don’t have experience with that low power devices (like thread/zigbee on 2.4Ghz) often mistake them to perform as good as wifi devices on 2.4Ghz and are very disappointed when they find out the mesh needs to be really tight with mains powered devices to be sufficient resilient for every day use.
Same should be true for matter over thread as they also only have 1/10th of the power budget compared to wifi
So one should realy think twice if it is useful to build a new mesh based network when a proper WIFI network is already in place with wide coverage and high bandwidth
This is not the standard, but a bug some might bump into.
Thought it was the main way until it was updated properly, I’ll see if it happens again next I retest.
For Zigbee you are right.
I found out that motion and presence detectors are (power plugged) routers too. So as I already position them to get note about movement in the building, the backbone is there and on good places (anywhere in one room).
What I think is more critical is that on Android the FOSS App on F-Droid does not support matter and we don’t have Apple devices. It will always the same discussion on any topic, why people choose ESP over proprietary hardware, when focusing on a secure smart home and not a fancy home.
So, the additional question is which hardware works on your system. And this is always my first question. The second question is what we can do with it, when it is enabled.
That’s why I like this board, to get a lot of use cases to find suitable solutions.
I’m on the same boat wondering if I should go with the ZigBee or the Matter over wifi version of ThirdReality’s night light.
Both versions are on sale for Black Friday
https://3reality.com/weekly-deals/
They have an integration
I run HA on a RPi with a Conbee stick (Deconz)
As I have my devices in use now I don’t see the need to big updates or upgrades of this devices to give me response of door open/closed, temperature and humidity.
If necessary I would invest (another 10-20€) in a second stick when dual mode will not work in the future, instead of changing the devices as long as they work as expected.
Keep in mind that Zigbee consumes less energy than Wifi. And Zigbee is not hackable from remote rather than any potentially Wifi connected device with internet connection.
I think it’s because the deployment process is proprietary (opposite of FOSS!) and on android smart phones (with gapps) is always google cloud/server backed - on the other ones it’s apple cloud/server backed. A working internet connection to google or apple cloud seems mandatory for successful deploys.
Absolutely! What many people might not think when just starting is scalability. Having for example 50 or more devices and the on-boarding process requires “hands-on” on the final location without possibilites to batch/script/automate it can get very tedious. Also if changing the location or other circumstances (new radio hardware, new neighbor?) come into play the process might need to repeated.
Having instead a ecosystem that unifies everything for all devices (even across different MCU manufactures) doesn’t only get things done (much) quicker but it is also easy scalable.
That is a common misconception if you ask me. Not only are you zigbee devices “bridged” into your network (otherwise you could not control them from HA!) making them reachable over IP (and potentially “hackable”) but also zigbee (or zwave, or …) are not free from bugs and might also be directly exploited.
https://www.sciencedirect.com/science/article/abs/pii/S1574119220300742
Do you mean that what it is explained here even if it works, is not a good option?
https://smarthomescene.com/guides/how-to-enable-thread-and-matter-support-on-sonoff-zbdongle-e/
Yeah look at the date on that may 23.
Mid last year (read after May) dev came out and said the multipan firmware had deep trouble (it’s providedbu the chip manufacturer and uses the same basic firmware between Nabucasas stock and the Sonoff.) enough so they stopped developing multipan support.
So Yes, bad idea.
And what border router hardware options are available to create a thread network integrated in HA?
Currently I run ZigBee2mqtt with the sonoff USB dongle