@Bruce_Osborne are there plans to bring them onboard, or are there obstacles to this? Zooz’ information page lists openHAB, but their manual for the ZEN76 switch doesn’t (not encouraging…).
700 slaves should work other than long range but I don’t think there will be any of those for a while. I run a few 700 series device including a couple of home spun ones with no issues.
The UZB7 will not unless you do your own build and make a few tweaks.
The reason for this is that the UZB7 is a bridge controller designed specifically for use with Z/IP as Bruce points out. There are a few calls that are different in the API on the bridge compared to the static controller library that the binding supports. You can fix these up as the API docs are published but there is no official support to use the bridge controller other than from Z/IP. I can point you at the docs if you want to do it but I don’t know how long a life anything you built would have or how easy it would be to support.
Lots of comments that the policy will change but still no public release of a static controller firmware for UZB7.
Please can you provide a reference. I didn’t think that they had been published yet - when I had a chat with one of the guys at Silabs a week or so back, he said that it was still with the Alliance to finalise and publish and it was only currently available to Alliance members. If you have a link, that would be great.
You have to work between INS13954 and INS12350. The only difference between the calls to the 700 bridge and 500 was the region before long range. As I pointed out not easy to support as it is not official yet which you know.
It honestly is not worth the effort as I am sure you know. Hopefully they will make their intentions clear soon and either make it official or make it clear it is Z/IP only.
Ok, so as I thought - the document is not yet released.
That’s not correct - there are a few differences that I know of from my discussions with the guy at Sigma, but until it is released, it’s really hard to say what else may change. 12 months back when Sigma/Silabs guys were first looking at this even they didn’t know what the final implementation would be
My point was simply that I didn’t think the document was released at all so I was a bit surprised when you said the API was actually published as it directly contradicted what Silabs told me only a week ago.
I think there are a few other changes to timing recommendations if Z/IP code uses the recommended and the file system has obviously changed but as binding does not support backup or firmware updates probably not a concern.
I think your contact might be exaggerating the exposed differences but little point in messing until it is official.
It is interesting that Z-Wave JS · GitHub team are rushing ahead but possibly they are not bothered to ever get certification or are not bothered if they have a lot of rework.
Well, he is leading a lot of the ZWave work Maybe you know more though
I know for sure there are more changes than you state here - I am using other calls on top of these. Anyway, it doesn’t matter - my only question was if you had a copy of the API since you said it was published, and I think the point is that it is not yet published, so we just wait.
Just for completeness, I’m not going to get into reverse engineering (again!). The customer I’m working with needs to certify this, and guessing is not the way to implement a compliant system.
There are a bunch of other changes coming to the certification program and it may now be that we (ie my customer) decides to drop Z-Wave for now given what we’ve just learned, but let’s see. Z-Wave is really a bit messy now (IMHO) and Zigbee is a lot, lot cleaner protocol.
Probably many more changes in pipeline that will break more so I think JS team are being very brave to try to make something now. Could be very hard to support.
interesting. I find both have many downsides from a user perspective.
curious … if zigbee is a clean protocol shouldnt device compatibility be also high then?
But whatever device I try it is not working fully or not at all in some way.
I think it is isn’t it? So long as devices comply with the standards, which some (Chinese) devices don’t.
Probably not. It is most likely that the binding simply does not support them. That’s not a zigbee limitation - it’s a binding limitation. Remote controls have so far not been very popular and I’ve personally not put any effort into them. I know DT spent some time to implement this for their Qivicon system, but that is no longer contributed to the OH binding.
However I think detailed ZigBee questions are out of the scope of this topic.
Absolutely . And as I mentioned (our replies crossed) the issue is not with the standard, it’s “just” that the Zigbee binding has not implemented a lot of support for these sort of devices as they are not popular and I don’t personally have any for testing.
Maybe you know more though 
from a user perspective.