Will it Matter? (Article about the standard)

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 :face_with_hand_over_mouth:

" …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 :slight_smile:

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 :slight_smile: .

2 Likes

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 -:

  1. 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 :slight_smile: ) 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.

2 Likes

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

2 Likes

Who knows if anything will be sold cheaper :wink: 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.

1 Like

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.