Earlier discussion -
Will someone write a binding for this before products hit the shelf? There are firmwares for esp32 devices that will allow people to get a head start before products are due to arrive in 6 months time.
If I understand this correctly it will mean a matter binding could replace both zigbee and zwave and a number of other bindings. Not sure how it all works yet so could be wrong, but if you have a bridge device it can turn a number of standards into matter and then a binding can bring the matter into openHAB.
Personally I would prefer to just have the zigbee devices talk directly to openHAB.
One Ring to rule them all
" ā¦and in the darkness bind them" LOLā¦ It will most likely mean having to buy multiple OEM hardware bridges to convert everything to āmatterā instead of just using a single zigbee/zwave dongle to talk directly.
- matter HUE bridge
- matter Aqara bridge
- matter Sonoff bridge
Then we are stuck with multiple hardware boxes all drawing separate power and they possibly now have our wifi details and can dial home to send data back to the manufacturers.
Compared to only 1 USB stick drawing minimal power and no chance of a zigbee device dialing home as it does not have any internet connection details.
Of course there will be positives but the sales pitches already cover those
My understanding is its a design goal that you wonāt need multiple hubs - you can choose whatever ecosystem you like, buy āmatterā devices and have them just work.
My experience with zigbee, by contrast, is terribad. buy new device, say, a phillips hue lightswitch, and find itās a useless doorstop until someone writes the correct zigbee2mqtt mysterious config.
That may be the goal and the sales pitch, but what will happen at least in the short term is that brand X has 40+ devices (with no wifi ability or code space for a matter stack to be added) already in shops getting sold and already passed electrical safety and RF standards in multiple countries. So they want to keep selling the same products and just offer a bridge to convert from their protocol of choice, to matter. Phone apps and clouds already work and they wont want to change, so the bridge is the easy quick fix that brings in income to pay for the changes needed.
You will also see that firmware updates are needed and it is easier to only update a single device that is a bridge when the standard is new. If a brand new device gets designed around an IC that comes with libraries/stack then updates are easy, as you just compile with the new stack and bug fixes are done.
Video about it here hopefully opens up to correct time. It confirms that every single matter device has the ability to send data directly out to a cloud. So long term yes the push will be to make devices matter natively, otherwise the person that makes the bridge gets to control whos cloud gets all the data. So will a zigbee to matter bridge exist that works for all brands of zigbee devices?
The Future of IoT is Now: Project Connected Home over IP - YouTube
And I suspect the exact same thing with happen with this new standard. Instead of a layer to convert to mqtt, then a second layer to convert the mqtt to the openhab framework, You will need a layer to convert from matter to the openHAB framework, or two layers if a mqtt project starts up. Someone needs to write that layer aka binding, and it is not going to be a simple binding and will take ages to write.
It seems to me that thereās two intertwined things here:
- whether zigbee devices move to Thread
- Matter, and what happens with Legacy devices
To take Hue as an example, it seems their approach is to get their hubs to talk matter, and leave everything else as-is. Given that the radio hardware for thread is identical to zigbee, others are expecting that theyāll issue a firmware upgrade and those devices become thread devices. It might even be possible to dual-stack.
For hue, long term, I canāt see them resisting moving to thread. Itāll just make their bulbs more expensive than everyone elseās (which wonāt need an extra bridge). I suspect itās down to the difficulty in firmware-updating their devices (in a way that consumers would stand a chance of understanding).
Theyāve all tried āzigbee, but proprietaryā ā that game is up, Matter seems to be an industry realisation that youāll never get mass market adoption without interoperability.
So sure, thereāll need to be a binding. I expect it to be much less painful than the endless updates of zigbee2mqtt that I have to do, where devices that literally send a single BIT of information in (switch) or out (lightbulb) require endless updates because the manufacturer is playing protocol specification games. I mean - zigbee2mqtt is great and all - that we need it at all is slightly idiotic.
To be fair, this is not a problem with the standard, but with the way that zigbee2mqtt is written by the sounds of it. The idea with a standard like zigbee is that devices are self describing, so there should not be a need for āmysterious configsā. The binding ought to be able to detect the features, and provide channels directly - so long as devices stick to the standards, which of course isnāt always the case .
That might have been the theory, but in practice zigbee is a world of zero interoperability.
e.g: I had bought the āsmartthingsā hub, and a bunch of devices. Very nice they are too. Then, naively, I bought a zigbee lightswitch from phillips. The smartthings hub resolutely refused to play with it (and as far as Iām aware, still refuses to do so).
Which is why I went down a USB-stick plus zigbee2mqtt route. To find that didnāt work either - though through careful debugging and assistance of the maintainer, we eventually got a setup that worked.
Go look at the zigbee-herdsman - the interop layer for the various devices, and browse through the thousands (yes) of commits and issues.
As a user you may be perfectly happy to live within one vendorsā ecosystem - such as Hue. But the moment you want a device that ecosystem doesnāt provide (say, a remote relay perhaps), or you perhaps want an off-brand, cheaper bulb, youāre bang out of luck. There is no interoperability.
Chris is not an ordinary user in this regard; he is well aware of products claiming compatibility to some spec but not in truth delivering.
Thereās no reason to think things might be better or worse under any given new scheme, unless it is rigorously policed.
Um, part of the issue is: zigbee has never claimed interoperability.
Being a similarly non-ordinary user leads us to expect that these things ought to work. Especially since we know how /simple/ what weāre trying to do is.
But the claim that itās āthe way that zigbee2mqtt is writtenā is not correct.
Whether matter ends up being any better remains to be seen - though interoperability in this case is a primary goal. I choose to be optimistic.
I think both of these statements are untrue (but I could be wrong). Certainly, there is very good interoperability with Zigbee, and the OH zigbee binding works in the way I mention above with no āinteroperability layerā.
The Zigbee Cluster Library (ZCL) should ensure interoperability. The ZCL states at the top -:
- An implementation of a new revision of a cluster specification SHALL interoperate with an implementation of an older revision of the cluster specification.
So interoperability is baked in here to the standards, and certification is the means to ensure this.
The problem with any standard is that someone decides they want to extend it with company specific functions, and this extension is by its nature, not interoperabile. In general though, this isnāt used too much, and other systems such as ZWave have exactly the same issue.
The Zigbee binding supports hundreds of devices - Iāve no idea how many as we donāt describe them statically. This was one thing I wanted to move away from when writing the Zigbee binding as I got burnt with ZWave. When the ZWave binding was written, openHAB did not have the ability for the binding to dynamically create channels or define a thing - it had to be done with the XML files. This then drove us to use the database which has around 1400 devices. While this does provide a way to get around problems with devices, itās also a problem to maintain, and as you describe above with zigbee2mqtt, it requires that this description be added before the device can be used.
In contract, the zigbee binding reads the features of a device, and dynamically creates channels. This works very well for devices that follow the standard. Contrary to belief, this is actually the vast majority of zigbee devices.
Where things fall down is with ānon-zigbee devicesā - mostly these are the cheap Chinese devices that use part of the standard only. Many of these devices donāt use the standard ZCL definitions, so fall down in interoperability. Unfortunately, in the āamateurā home automation arena (by which I mean the DIYers that probably covers 95% of users of openHAB and HomeAssistant) people like a good bargain, so like to buy these cheap devices.
Certification is a key here. Iāve put Zigbee devices through certification, and itās quite rigorous. Sure - it probably doesnāt catch all issues, but it goes a very long way. However while we may see the word Zigbee on AliExpress adverts, Iām not sure that most of the Chinese devices are really certified (although Iām sure some are).
Iām not really familiar with zigbee2mqtt, so Iāll accept your statement here. My comment was really around your point that devices are āa useless doorstop until someone writes the correct zigbee2mqtt mysterious configā. This is certainly an implementation issue in zigbee2mqtt if they require this definition before a device can be used. As above, this is the way the OH ZWave binding works, and itās a pain - but itās not a Zigbee limitation - itās a zigbee2mqtt implementation issue, and it isnāt the way the OH Zigbee binding works for example.
Controls made by Phillips are hardly ācheap chinese devicesā, and yet, it was those - not the unbranded imports - that were problematic.
Itās not just zigbee2mqtt. The same problem occurs in smartthings (which had some, but not a lot, of programmability last time I looked before I gave up on it). Iāve seen the exact same problems in other non-openhab projects trying to get the same devices to work, cribbing code from each othersā implementations. Whether thatās as a āconfiguration databaseā or actual code - the fact remains that in many projects, the hue controls - despite being zigbee - totally failed to work without software being updated. (This was actually also true of smartthings devices on non-smartthings hubs).
ISTM the vendors were supremely disinterested in interoperability, and in some cases actively hostile. Why would phillips like to let you control cheap bulbs on ātheirā hue hub? But then of course they indeed never marketed any of that equipment as āzigbeeā, just āhueā. If Iām wrong and they were then all I can conclude is that some lessons need to be learned fast to stop matter going the same way.
My sense of it is that this game is up - to meaningfully grow the market, we have to get to the stage of consumers being able to pick up , see a label, and know itās going to work with whatever their HA system-of-choice is (which for the vast majority means alexa or google or homekit), without having to consult some compatibility lookup table.
I await the practical unveiling of matter with hope; itās a pity itās taken longer than initially scheduled - having terminated all purchases of zigbee-radioed devices until then, as my money is on it winning in this space.
Or course, there can be (and are) poor implementations - both in devices, and gateways. And there can be missing implementations of features that some devices rely on that gateways may not support. Older devices may not work so well, and I know older Hue devices had a number of limitations.
However this isnāt necessarily a zigbee problem - more of an implementation issue.
I do agree that not everything is perfect, and there are always different interpretations of standards - this happens everywhere and is what certification is designed to root out, but nothing is perfect.
I donāt know that it will solve the issues you see here. Matter primarily looks at interoperability of systems. You still need interoperability at the lower layers (such as the zigbee cluster library). Itās fine if hubs can talk to each other, but devices still need to be able to communicate with eachother at the application level. This is where (IMHO ) a lot of systems fall down at the moment and the proliferation of BLE and WiFi systems have issues.
Matter is run by the Zigbee Alliance (ok, then renamed themselves a few months back, but itās still the same) so I expect that these issues will be picked up, but I donāt think thereās likely to be a magic solution that solves interoperability on all levels right out of the box.
Iām the opposite, I will be buying the Zigbee devices that are going to get sold cheaper as they are no longer the latest āhotnessā.
Matter has been built by the same companies, using some of the same source code as Zigbee, you can call Matter the next version of Zigbee built using Wifi and Bluetooth LE. Thatās all it is, the rest is just marketing hype.
I think it will be good for people that only want to use Apple Homekit, Alexa, Google Home as their only smart home controller, but for us that use openHAB and other opensource projects we will see how it proves itself over the coming yearsā¦
Your Smart Home Is About To Change: Matter Is Coming - YouTube
Who knows if anything will be sold cheaper but I agree with the general thought here. One thing Iāve learnt in this game, and in fact technology in general, is not to wait for the next best thing thatās ājust around the cornerā. I expect it will still be quite some time before things really take hold, and until thereās a ācritical massā of components that are certified and brought to market, buy in to new tech is a bit of a dodgy game.
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.