I think it’s fundamentally the same. If you have a device that introduces new features, then it may not work 100% with older devices. The same exists in ZWave - this is why the ZWave database has the versions to try and provide the “very very detailed” list that you’re talking about.
You are right though - with ZWave it is a bit easier as there is basically only a single controller where ZigBee binding supports multiple coordinators and it’s not really possible to simply state that “openHAB” supports a device - it needs to be the binding version, and the coordinator type, and the coordinator version.
Yes, they are.
And silab has obsoleted the chip in the Bitronvideo stick…
The newer firmware and chip on the Itead stick seems to have no problem with the newer zigbee v3 devices.
(I stil run my production network on my bitronvideo, I will migrate to a more up to date stick when possible).
Comparing zigbee to zwave is a bit misleading, I think.
Zwave is mainly one chipset, so compatibilty with “itself” should be simple.
As time goes by, it is clear (for me) that this can not last.
In general, that doesn’t matter too much. It does mean that memory is limited, but up till now it’s still possible to use newer firmware on the older sticks, and it’s the firmware that matters - not the chip. This will change in that newer firmware may not be supported on the older stick for the next release of ZigBee standards as it increases security.
I still use a lot of the EM357 chips for testing and that’s what’s in the Bitron stick - it’s a good device so long as it has firmware that’s not 3 yeas old
As of late last year the ZWave standards were released to allow other manufacturers to produce chipsets, so it’s inevitable that it will not last
I understand support for EM35x, EM358x, and EM359x families were dropped in EmberZNet 6.7.9(?). Also; “sample applications in releases beginning with June 2020 will no longer target 256 kB parts, including EM35x, EFR32MG1, and EFR32MG14”. So at least need a chip with larger flash storage.
Good news for most average users is that newer firmware than EmberZNet 6.7.8 does so far not really add any new features and functions that most users will want. So will work with all Zigbee 3.0 devices.
As delid4ve mentioned, no one has yet found an easy way to upgrade the firmware on Bitron Video AV2010/10 and SMaBiT AV2010/10 USB-sticks and per https://github.com/zigpy/bellows/issues/348 the newer of those ship with EmberZNet 5.8.1 firmware (and that is only compatible with EZSP v4).
AFAIK, most but not all Zigbee 3.0 devices with standard features are usually backwards compatible with either older Zigbee Home Automation profile version or older Zigbee Light Link profile version. It is often only when a new Zigbee 3.0 device makes use of features in a newer ZHA/ZLL profile specification version or other non-ZHA/ZLL profiles that backwards compatible is not really possible and you then need a Zigbee with 3.0 stack compatible coordinator adapter and application firmware.
Off-topic but FYI, to migrate to a newer Zigbee coordinator adapter/dongle/stick hardware you should be able to backup most older “Ember” Zigbee coordinator running EmberZNet NCP and then restore backup to new Silicon Labs Zigbee hardware running a newer version of EmberZNet NCP.
A tip is to just a little research first to get quality hardware with a newer Silicon Labs MCU chip that can be flashed with the latest EmberZNet NCP application firmware by end-users, because as mentioned by NilsOF; some MCU chips used in some Zigbee dongles/sticks still sold today have been since long been made obsolete and are official no longer recommended by Silicon Labs / Silabs. Those with old chips obsolete MCUs include the very popular Nortek GoControl QuickStick Combo Model HUSBZB-1, Telegesis ETRX357 series, Bitron Video AV2010/10 and SMaBiT AV2010/10, …but note that currently, the is unfortunately as of yet not any widely available Zigbee coordinator adapter/dongle/stick hardware based on the newest Silicon Labs and is stable (though there is some hope that ITead will release a new fixed hardware revision of their Sonoff Zigbee 3.0 USB dongle before long)
Judging by the replies the interest is low to none and implementing a meaningful list is complicated due to versioning.
As for submitting to me there are multiple avenues: GitHub, Twitter, Google Form, Discord messaging, email contact form
While the “it will work if it supports standards” mantra is nice in theory, a recent glut of Tuya devices with its own understanding of a “standard” has made that a lot more complicated.
Yes, this is why I stated that there was newer firmware available - not the newest. These older sticks use soemthing like 5.8 which is a few years old.
Typically it is not related to the profile directly. The issues are either related to the specification revision or the clusters supported. The Zigbee spec changed a lot around R21 and R22 and this is where things start to become problematic since security was enhanced.
If you update the firmware, it will not change the network. While I agree it’s a good idea to do a backup, it is not necessary and the network will continue the same after the upgrade.
I, too, would be willing to contribute and it got me surprised because I haven’t read the “no interest” in this thread like he did.
@chris wdyt ? To many users it currently looks as if OH does not support any of those devices and with HomeAssistant in the pretty much very same situation but nonetheless being part of the list, I think we should stay on par, no need for understatement here. I’d guess you have a substantial zoo you can share as an initial batch, too?
For the most part, I agree with Chris. If we can’t have our own community contribute to our own list of supported devices I don’t see how moving such a list to another site will make that problem anything but worse.
Maybe this can be something that spurs people to contribute to the list that is already started in the Zigbee binding docs. If we can show that we are willing to contribute to such a self hosted list, maybe then it will be clear that it’s not a dead end for Blackadder.
The blackadder site already has a category listing devices compatible with zigbee2mqtt. I think this thread is strictly limited to the native OH Zigbee binding.
Any of what devices exactly? The ones on the list? Or what? If it’s not part of the list, then people shouldn’t assume that it’s unsupported by OH if OH isn’t even listed
Again - I am not against the list. My point is simply that for a list to be of use, it needs to be up to date. Making OH part of this list, but only selecting a small number of devices as compatible is just as bad, if not worse than not making it part of the list. People have not bothered to update the current list and I suspect that this will simply be the case with the new list. Any list that is not maintained is of no use - it’s basically what we have now, and I just don’t see it changing because we use a different list. I’d be happy to be proven wrong of course, and I’ll repeat - I’m not against the list itself in any way.
If you want to add to the list, you need to create the PR on GitHub. I think this probably highlights my point (or maybe you already created the PR and you’re just notifying the community?)
I didn’t no (the reason I put it here )
Completely agree @chris - the average user isn’t going to go through the rig morale. Even for me, GitHub is a massive pain in the backside due to my setup (working in RDP), I’m in a situation now where it won’t even open. I don’t even want to merge my bindings and be tied in.
Again I think more average users would contribute if editing lists was possible from wiki-based website.
However, editing existing devices on the Blackadder Zigbee Device Compatibility Repository is not that hard for the average users of openHAB to do via ex. Google Chrome or Chromium-based web browser.
Basically, all need is a standard computer with with mouse and keyboard then go through these steps:
Use a webbrowser to register an account on GitHub and/or login to your GitHub account.
Click the “EDIT PAGE” button at the top-right corner of the web page for the device.
Click on the ‘pen’ icon (says “Edit this file in your fork of this project” if you hover mouse over it).
Now you are in web-edit mode on GitHub for a forked version of that page so go ahead and edit.
Add a short subject and a description of the change at bottom before clicking “Propose changes”.
Click “Create pull request”.
Change subject title and a summary description if you want before clicking “Create pull request”.
Done, (or at least you are done now if the pull request is accepted and merged as is after review).
If pull request is not accepted as is then the reviewer might suggest changes, if so click ‘commit’ then click three dots “…” and select “Edit file” that lets you perform web-edit in step #5 again.
Not hard but sure it is still a pain compared to simply editing a wiki-based website and only click save.
While I agree - the point is that what you describe is exactly the same as we have now for the binding documentation, and we are still in the position that unfortunately very very few people take the time to do this. I think in most cases it’s not really a matter of how hard it is - most people simply don’t bother. Once they get their system working, they are happy
Just for the record, making simple updates to the docs really doesn’t take much interacting with GitHub at all. You can do it all through the Browser, including editing the files. [Wiki] How to contribute to the openHAB Documentation and How to file an Issue both provide the steps as well as a ton of background that you probably don’t need. The tl;dr is:
Open the page you want to modify in the docs.
Scroll to the bottom of the page and click on “Edit this page on GitHub”
Make your changes to the file.
Fill out the “Propose Changes” at the bottom explaining what you changed and why.
Click on the new “Create PR” button
That’s it. No need to clone or fork or mess with any of that complications. It’ll all be done for you. You don’t even need to install git on your machine. I’ve made updates to the docs from my phone in this way.
We used to have a wiki based docs site. Frankly, it didn’t really work out all that well. Average users were as reluctant to contribute to the wiki as they were to contribute to the main docs. And wikis do not really easily support synchronizing the docs to the releases.
As you can see above, it’s even easier to update OH’s pages. You don’t need to navigate to find the page or anything like that. You don’t need to move into Edit mode, etc.
(the reason I put it here 
)