I’m considering cutting my primarily Home Assistant / Node-RED based home automation over to the Matter Standard.
I see that Tasmota now offers Matter support in some of its builds and there is a Home Assistant integration. I briefly enrolled a Tasmota device into my HA and the process and operation was pretty painless. (Once I realised that Tasmota devices only offer Matter as an optional interface, the device does not become primary Matter device.)
I’m very enthusiastic about the principle of the standard, and it appears that CoAP is super responsive.
What experiences have people had?
Is it worth committing, or is it still bleeding edge and needs a bit more time?
What other manufacturers do you know of that are now supporting Matter?
What is has the experience of enrolling and using with the Google/Amazon home hubs been like?
What issues have you encountered?
I ran into CoAP when playing around with Shelly devices (CoIoT, which is an extension to CoAP) and I did like the protocol. But that’s the extent of my experience.
For my money I would suggest you look at MQTT as a standard for the long term.
It gives you a wide range of flexibility with 99% of devises being able to handle the protocol. I do understand that voice inter compatibility might be an issue at the moment but if you look at where Chat GPT is moving , I personally believe that it is only a matter of time before you will get a full voice integrated AI that could easily run though MQTT and link to automation scripts like Node red.
Very interesting times though.
If you do decide to take the plunge please share your experience.
As a side note : With more and more smart devices coming to market how is your Network handling all the connections? I am starting to get to the point where I need to do a major upgrade to my network as it is just not keeping up anymore. It is not the bandwidth that is the problem but rather the amount of connected devises to the network…
@plonkster A google for CoIoT seems to indicate it is a Shelly standard?
@Paul MQTT is TCP based, where CoAP is UDP based so the overheads are lower. Good point about the device limitations, some the limits of domestic networking gear are surprisingly low.
That is what went trough my mind as well. Guess you could have the device send a confirmation message but then you would , almost , I think , be at the same overhead as tcp…
Also at the level that IOT devices operate the overhead is really negligible even at running 900 topics , in my case , you would hardly see any problems with the bandwidth.
Now streaming media is a different story and as it seems it is geared towards Google home , Alexa and so on it could make a difference.
That’s how it works anyway. Pushing the button sends a message, the message turns on the device, the device sends back a status message saying “I am now on”, and that animates the button into showing it is on.
So then what is the major difference or bandwidth savings between sending a tcp packet and getting the confirmation bit vs sending a udp (one way “unconfirmed” packet and receiving a “I am now on” bit?
TCP has a lot of extra overhead, some in the connection (3 packets just to make the connection, but generally you would keep the connection alive to avoid this), and then all the connection tracking by the OS (socket such and such is connected to this application, is in this or that state, tcp counter such and such), and then ensuring packets arrive in the right order, sending acknowledgements every now and then (I have received up to packet 512), retrying dropped packets, etc. All extremely important when you are downloading a file, but of no consequence when watching a streamed video and the lost packet just causes a bit of a blip on the screen (when the real time requirement is a lot more important than the picture being perfect).
In the same manner, when the data you are sending is very small (ethernet packet size is 1.5k, minus tcp header of 60 bytes, minus udp header sizer of 8 bytes, so you can carry 1432 bytes in a single message), and when the application layer already sends back a status message, UDP is more than good enough.
Edit: On this topic, I would love to tell you a joke about UDP. But you might not get it.
