Zwavejs and zwavejs2mqtt use the same driver under the hood. As far as I know there should not be a different between those 2 for device compatibility.
Zha and zigbee2mqtt are entirely different, the code is not the same and handlers (quirks) are not the same.
That’s a service level agreement, that wasn’t described but is certainly a good question. Hard to see how nabua casa can force something like that given that our (home assistant users) market share is a nothing compared to the big dogs.
What happens if a core update breaks something in the internal HA API that the service or device uses to interface with HA and the integration breaks as a result ? Will it be stripped off the badge until it is fixed ? Who is responsible for fixing this ? Is the third party manufacturer contractually obliged to keep up with all core changes as long as they want the badge ? If yes, are there time limits ? What keeps us from ending up with a bunch of ‘certified’ integrations that don’t work because of core changes the manufacturer didn’t anticipate or keep up with ? Who would be in charge to QA this after each core update and possibly to strip / award the badge back ?
Seeing how that Tuya thing turned out…
You answered that already above. And you know the answer considering the discussion above.
I also answered that above as well. So I’m not sure why you are asking now again?
Tell me about it… I’m personally hit by that as in: Wasted effort (at least, that is how it feels for me, the reality is that I’ve been able to get lots more devices working at least).
That said, yeah, we (and sadly me too) have learned from that. They were not partnered btw, nor will they have been able to meet any of the program requirements. Honestly, I hope they will meet the requirements for the program one day, as that would mean: Stuff would actually work nicely.
So… You quote this:
Which conveniently (not sure if you did that on purpose or not), quotes part of that sentence.
Next you quote:
minimum time frame for maintenance and keep cloud servers running for example?
The latter quote makes no sense, as that is not written in the blog post. I feel like you are trying to bend things into things you’d like to hear. However, as already mentioned above, the focus is on inoperability and a good experience. If it isn’t operable as per the agreement, the “Works with Home Assistant” partnership can obviously not continue for that specific partner.
…/Frenck
no zigbee is a real crap shoot for devices ACTUALLY working, or FULLY working without special work. For example an outlet might turn on and off out of the box and join the network but depending how they implemented power monitoring may not report power use out of the box.
Unique devices like AirQuality sensors may have extra metrics that need to be specifically polled.
Combo devices might appear as multiple devices out of the box, but would be better served if the HUB combined them as one device.
Configurable devices might have flags that can be turned on and off that need to be known and setup in a profile.
Unfortunately though, that is not the case. eg: I bought a presence sensor from MoesHouse which is detected and added to HA just fine, but doesn’t provide any usable entities as it is supposed to. I’m now in the process of trying to mess with custom quirks to get it functioning. That is not an acceptable process for a device had it of said “works with HA” on the box.
Yes that’s why I said “in theory” and carved out the exceptions, that device is tuya and I noted they don’t follow the standard nearly at all, therefore a quirk is necessary. In the future check what you’re buying to see if it works. It’s not ha’s fault it’s not compatible out of the box and requires a quirk.
I think you answered your own question:
So integrations need to maintain blueprints on top of the integration itself? Yeah it may not seem like much, but remember a lot of maintainers/contributors are doing this in their “spare” time.
Common, let’s all stop quoting half things and making useless statements without foundations.
Please don’t be mad about the following (I don’t mean it harsh or bad), but I wanted to get it out.
Zigbee is fine, as a matter of fact, it is one of the most popular / most used protocols in the smart home today. That is not because Zigbee crap. Yes, there are Zigbee devices out there, that are less perfect than others (you’ll get what you pay for). But that is not specific to Zigbee, that applies to lots of things in this world.
Don’t mix up protocols versus devices. Additionally, just because the same alliance houses 2 protocols, doesn’t mean they are both bad? I don’t see that connection. Have you actually read specifications before making those statements?
Please note, that (not only @Burner66, but more occurrences above from others as well), dropping those (partially and above wrong) statements can be interpreted as the “thruth” by someone else.
Please, invest some time to read and learn about the things you are intending to make a statement on. Nobody benefits from what is posted, nor does it contribute to the community as a whole.
Thanks 
…/Frenck
I’m not sure that is something I would be bragging about… 
I’m a strong supporter of truth in advertising but that’s a bit strong. 
/kidding, you know I love HA.
I think is going to be the biggest problem with this program.
I doubt any manufacturer will be willing to enter into a contractual obligation to maintain operability with HA with the high number of breaking changes always coming along.
Perhaps the contract could be written such that the manufacturer only has to keep their side of the interface (API or whatever) stable. They’d also need to include HA developers in testing and development of changes or new features they’d like to make. They wouldn’t need to worry about how HA uses their interface. Just make it available. and stable.
This would mean that the integration for the device or service would be written by the HA devs. Which is pretty much how it works now, only that the third party manufacturer would guarantee a stable API to their hardware, independently of HA. But that’s not the way this program works, as I understand it. Manufacturers would be required to write their own integration and keep it up to date. Which requires them to interface with the APIs HA exposes for integrations. One breaking change / refactor in that HA API and all your ‘premium quality platinum gold certified badge’ integrations become the digital equivalents of a doorstop.
Yeah, that would be hard to sell.
If i compare the number of breaking changes now with 2 years ago…
well basically i didn’t have any breaks at all for the last 6 months….
not sure if that is me….or….
What is it with people that consider making money as being evil? Yes, probably some home automation geeks got together and decided: “Hey let’s create system to automate peoples home and put devs around the world to create integrations, add-ons and solve issues for us… Then we sell it to Google and make loads off of their work for free!”
Dude, why do you have HA? Why don’t you create sysgys assists? Did someone make you use the platform?
Cause I am pretty sure people that developed it wasn’t really plotting or scheming, but just creating an awesome form to link all the products they already had in one private place, to make our lives (yes yours too you ungrateful success hating as***e) better, more fun and easier.
I am no dev, first yaml file in my life was configuration.yaml, so I really appreciate all that those guys did! And dude, believe me, if they get to stamp on the box of products like Hue, Sonos, whatever GE bulbs… THEY deserve it. Also, it has not been thanks to your developments, cause YOU developed what YOU wanted for YOU and maybe helped me or them, now what? Did you hire people or have costs? Cause they did… Just like companies do, not crybabies complaining plots of the evil universe of success!
I agree with the concept, but the badges must be earned, not for sale.
There should also be a page on homeassistant.io featuring links to the badged products.
If any badged product stops supporting Home Assistant for whatever reason, then instead of a product link, they get redirected to a page explaining why this product is no longer compatible.
For the badges to be of value to the product maker, make it of value to us!.
Honestly happy to finally see these!
Couple of points:
• Will you be pursuing companies that abuse these badges? For example companies that just stick them on their Amazon listings without proper agreements etc.
• Will we see base Zigbee, ZWave and Matter implementations with in HA?
I understand, but right now developers don’t have a choice. Embedding blueprints is not meant to be mandatory, most of the time it’s probably a matter of copy the blueprints that already exist into the right integratioms, and it provides an easy way to keep the user blueprints updated.
At every update some blueprints break and I have to manually download the new version from the community store
