Update README.md - Comparison with Zigbee2MQTT

[Boldfor]

I stared with Zigbee in openHAB just a few days ago. I summed up what I found super confusing in the table below. Feel free to comment / revise.

[cdjackson]

Thanks, but I personally don't think there's a need to add this sort of comparison to the zigbee binding docs.

It's also incorrect that there's only 50 devices supported - the number will be in the thousands since the binding doesn't use a database of any sort - it should support all devices that support the standards (where there is a compatible channel).

[Boldfor]

Thanks, you might be right. Even though I called it "Number of documented compatible devices" one might think that only 50 devices will work, with the number still being in the thousands (but just not documented / confirmed as in z2m).

Anyway, if you believe that there's no need for a comparison, what would you recommend instead? My thinking / the trigger for my documentation: When I started to read about Zigbee in openHAB, what I was desperately looking for was a hint like "Hey, just want Zigbee to work without the need to fiddle around with json and MQTT? Just install the binding and be happy."

Maybe my proposal incl. the table was a bit over the top (and made the binding look bad even though it isn't), but the more I read about it, the more I understood the differences and benefits of the binding, which I wanted to share because I believe there are more Zigbee-beginners like me for which the binding is the optimal choice.

What do you think?

[cdjackson]

I mean, the comparison isn't really correct. Again, the number of devices is not relevant (IMHO) since the zigbee binding is designed not to care about the device. Compared to (for example) the zwave binding where we have a database, and it's a pain to maintain, here the binding is designed to detect devices and work within the standards. So, the binding should work with devices that support the standards. I know that's not all devices, but it's a lot more than is documented. Personally, I didn't want to document ANY devices, but people started adding to this list, so now it's kind of ambiguous.

Likewise with things like startup state - the binding does provide a way to change some of the device config where the config is done in the standard way.

Also for signal strength - this is provided in the binding, but it's not provided as a channel it's in properties. Channels were meant to be about home automation - stuff that matters to controlling a house. LQI for example is useful information for a network admin, but not a user, and is therefore provided as part of some network property information. The fact that with MQTT, everything must be provided as a channel doesn't mean that it's either the best approach, or the correct approach, and arguably MQTT is not doing things "properly"...

So, yes, things are different, and maybe this needs explaining somewhere, but a simple table with statements that aren't completely right, or not fully explained is (IMHO) likely to cause more confusion.

[Boldfor]

Thanks for your comments, which I incorporated in my proposal.

Feel free to review and let me know what you think.

[Boldfor]

Hi @cdjackson, can you let me know what you think about my PR after incorporating your feedback & comments?

[digitaldan]

I don't think we should be comparing our own internal binding to another 3rd party zigbee project in our official docs. I think those types of subjects are best left to the community forums.

[Boldfor]

Even if the 3rd party software is officially listed in openHABian, and probably every newcomer having the same question? Plus on top the fact that the internal binding is the dominant path for 99% of the users, while z2m being way more present on the net, attracting users that would be completely fine with the binding at just a fraction of the effort?

My trigger was: I would've almost gone the z2m-path, then probably throwing it into the corner after 2 hours, concluding that openHAB for Zigbee devices cannot really be recommended to any friend who doesn't know what MQTT is.

I share your argument to not compare something against any random 3rd party software. This case, however, looks a bit different to me for various reasons, and the upsides outweigh the downsides you mention.

[cdjackson]

I also share @digitaldan concern and this was my original comment. The problem is even comments like "zigbee can be integrated in two ways" is incorrect since there are multiple bindings that support zigbee integration. Hue, Xiaomi and probably a bunch of others, and (for me) the problem with writing this sort of thing into official docs is it quickly becomes wrong when someone changes something in another binding, or adds a binding, or whatever. We then end up with documentation that is confusing.

My. feeling is it is better not to get into subjective comparisons that may be either incorrect, or get outdated. I appreciate that you're trying to help people make a choice, but personally I'm not sure this is the right place.

[Boldfor]

Thanks for taking the time to respond.

I do respect your opinion and decision. At the same time I come to a different conclusion, maybe because I'm far from being a pro and rate "user friendliness" over "100% (future) correctness" (even though the points you mention could've been worked on) or "strict paradigm on what belongs into a docu or not" (which I would always look at from a user-perspective). I tend to rate "helpful information" over "no information / hoping the user finds the correct thread elsewhere".

Anyway, thanks for the work you do in your free time. Much appreciated!

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/sonoff-zigbee-3-0-usb-dongle-plus-v2-which-firmware-to-use/153779/4