ZWave 700 - Support?

Now that OH is out in the wild, does anyone know if ZWave 700 is currently supported?

I have started to test OH3 with UZB-7 and it can find some of my devices but seams to not be fully working or identifying them.

I have enable the ZWave debugging and it seams to communicate with I am getting lots of the below errors:

> 2021-01-04 16:29:06.056 [WARN ] [ve.internal.protocol.ZWaveController] - TODO: Implement processing of Request Message = -- (0xa8)
> 2021-01-04 16:29:11.282 [WARN ] [.serialmessage.ZWaveCommandProcessor] - SerialMessage class null is not implemented!
> 2021-01-04 16:29:11.283 [WARN ] [.serialmessage.ZWaveCommandProcessor] - SerialMessage class null is not implemented!
> 2021-01-04 16:29:11.283 [WARN ] [ve.internal.protocol.ZWaveController] - TODO: Implement processing of Request Message = -- (0xa8)
> 2021-01-04 16:29:16.447 [WARN ] [.serialmessage.ZWaveCommandProcessor] - SerialMessage class null is not implemented!
> 2021-01-04 16:29:16.448 [WARN ] [.serialmessage.ZWaveCommandProcessor] - SerialMessage class null is not implemented!

Is there an ETA or plan to fully support 700?
Whats missing and how could I help?

I know and it is not supported. i think Z-Wave OPlus 2 devices are supposed to be backward compatible someqhat.

@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…).

That would be a question for @chris I think there is currently no publicly released specification for 700 series over serial, only over Z/IP

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.

1 Like

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.

1 Like

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


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.

The could be reverse engineering too.

Well, he is leading a lot of the ZWave work :slight_smile: Maybe you know more though :wink:

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.

they must be and if you read some of the issues you can tell they are

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

latest Tradfri Remote IKEA W2049 control via MQTT | … not working
Tradfri Shortcur Button IKEA E1812 control via MQTT | … partially working
Opple Switch … Xiaomi WXCJKG13LM control via MQTT | not working
and some more I already forgot again :smiley:
(Although I am used zigbee2mqtt links for the devices I talk about the openhab zigbee binding here on compatibility)

Are all those devices not compliant to zigbee standards or why is it so hard that the binding would discover them correct?

1 Like

Not sure I understand how these not working relates to the cleanliness of the underlying standard.

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.

What are you referring to when you make this comment? You don’t quote anything, so I’m not sure what you mean - sorry.

That just because the few listed zigbee devices do not work in some way proves an issue with the standard.

Possibly all @shorty707 has observed is that both suffer from poor implementation in some devices.

1 Like

Absolutely :+1: . 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.