ZDK command classes??

I emailed a manufacturer (not naming as I don’t want to start a flame war) and asked them if their z-wave products would work with Vera. Got this response back:

“Unfortunately our products are still not correctly recognized by Micasa,
NOTE: all our products are z-wave certified and up to date with SW releases from Zensys.
I’d recommend you to try other controllers that have incorporated the latest ZDK command classes and correctly recognize our products?”

So what do they mean by “incorporated the latest ZDK command classes” ? Is there something that is way behind on vera or that vera does it a different way? Or is it more of just because a product is designed to a certain standard, those standards are sometimes interpreted differently (i have seen that many times in other protocol definitions)

Id like to know what manufacturer so I don’t buy any of these…at least until that class is supported…

I seriously doubt this is true. MCV has been at the fore front of getting Zwave devices to work.
I have been around Zwave for a long time and when I hear such I tend to think if they are really Zwave certified.
For example

  1. Hawking was being sold as zwave certified. They cam out with the HRGZ1. It was never ever certified and yet it had the Zwave logo on the device and package.
    Hawking released the HRPS1 and it was almost a year from what I recall that it finally got certified.

  2. Schalge releaased it’s door lock and bridge many months before certification. Even worse they did not allow certian certified devices to work with their bridge or web application claiming those devices do not meet schages standards. Zensys/Sigma and the Alliance are the folks that set the standard not Schlage or any one company.

Zwave devices are sent to a independent lab for certification.
So when I see or hear a company make such claims I see it as a way that this particular company is making something that may not be using the zwave devices classes properly or even be actually certified. Zensys may have made a device class change and MCV has yet to get it to work. In the past MCV has been the first independant to get a new device to work and do so quickly. There are bugs and I to am frustrated with that.

So who is this other manufacture?

Okay… okay…

I asked fortrezz about their devices and mentioned that I had seen a lot of complaints on these forums about
vera and their freeze/flood sensor. I didn’t want to get start bashing contest of who has the problem.
I would just like to see some solutions / fixes.

Oh I forgot ZDK …= Zensys development Kit.
For each variation of the Zensys code or device classed there is a coinciding ZDK. ( hopefully)

Since the begining there have been upgrades and changes to the ZDK. Products have been marketed and then the ZDK changes. Most of the time it has no influence on the basic products. The controllers are the devices that need to deal with these changes and updates. Old products should usually work on new ZDK. But older controllers won’t work new ZDK device types. MCV from my understanding and experience has always tried to keep up with those changes. With all the criticism I feel that they seem to have the quickest turnaround with these changes.

Les so are speaking of fortrez?
I have spoken to fortrez recently. Fortrez is using a certain Device class that I believe others have not implemented yet. This is kind of like Schlage releasing the Lock last year and no one had implemented the security class yet. MCV releaased a beta firmware in less than a month working the lock. Many of the lock functions turned out to be either proprietary or did not follow the ZDK. I belive those items were ironed out. This does not mean that the product will not work in certain controllers what it means is that all the functionality may not work. I firmly belive that MCV will get it to fully work as Frotrezz is not going to be proprietary with those functions. So it’s going to be a matter of time.

Take a look at GE/Jasco. They are the first Major brand that has implemented the Beam necessary for battery devices like Schlage lock. But what many do not realize is that they do not support Association class in their devices. This is becaue of Licensing issues that GE will allow. The jasco products are great! but you need to live without associations. Not every device class needs to be implemented in a product. They only need implement those that are mandatory.

When I tested the Everspring smoke detector SF812-1 back in November, Vera was not able to handle it. It is a “Zensor Net node” and requires a new ZDK.

I moved my Z-Stick to a PC, and installed a demo of HomeSeer. It worked there, so the upgraded z-stick can control it.

Vera is capable of ZNN. This is what all “new” battery operated devices like the schlage lock use.
i can’t speak as to why Vera could not use the device. Do you know if they have one. Was this a retail device or a beta unit. I am surprised you got it to work with Homeseer as they are using a truncated version of the full Zwave code because there stick does not have the capacity to run the full code. Zensys has allowed this truncated version so other devices will still work.

Maybe it has something to do with the Luup engine. I wonder if a pre Luup firmware will recognize the device.

Can someone from MCV chime in?

As a side note on Z-Wave Device classes… I know that there was a shade (or window covering) device class, but it came in a later release of the ZDK and as a result most z-wave shade controllers use the MultiLevel Switch class which is good for compatibility.

I’ll have to check on the new ILT Z-Wave box it could be using the new shade device class… emailing Somfy now.

OK back to the conversation…


It was this device HomeesTore.com is for sale | HugeDomains (EU version)

I tried it with 1.0.939 and 1.0.994, so it is possible a pre-luup will work.

I don’t know, if MCV has one. I don’t use much time on my Vera anymore.

To my knowledge we’re the only company that guarantees compatibility with all the ZWave device classes. There has been some dispute as to what is certified and what is ZWave device classes. We had a recent customer, for example, who wanted to use some Merten 4-relay device. We did provide support for the device as far as the standard ZWave command classes go, but Merten had special, proprietary command classes they used to in order to get the full functionality. So, it was only partially supported. We put it on the todo list to add support for the proprietary commands too so it’s fully functional, but it has a lower priority. The Merten device was certified, as far as I know. But certification only covers the standard ZWave command classes – not the proprietary ones – and therefore we did fully support the certified device.

I saw Fortrezz mentioned too. I know there’s an item on our to do list to report the temperature in the icon itself instead of how you currently have to open the icon and view it in the advanced tab. In this case it doesn’t fall under our guarantee because we do support it, it’s a cosmetic issue. And we will add the temperature to the icon, it’s just that we’re not investing time updating UI3 icons since we’re migrating to UI4. So we’re doing it in UI4, not pulling away resources to do it in UI3.

Bottom line is that if you buy the device, whatever are the standard ZWave command classes will be fully supported and we’ll guarantee that.

Thanks MCV.

I think that was well stated. It’s a shame that there are these proprietary commands out there because the average consumer just wants it to work. The original motto of Zwave was that it is interoperable and compatible with other Zwave devices. Zwave has fallen quite short of this. This is not the fault of MCV.

Thanks to everyone for all the details. I see that Z-Wave is like many other standards that try to guarantee interoperability. It covers the majority things, but of course never fully covers everything. I agree with what MCV said efforts are best put on the future of UI4. I myself am not worried about a cosmetic problem, just like to know that yes it will work.

As far as I remember the main problem with Fortrezz was inability to use it as temperature sensor in scenes, and this is functional, not a cosmetic issue. Could you make sure this item will be handled too?

good point about the scenes and the fortrezz, I also want to use this device in scenes and see the temp in the icon. Glad they are working on it, I don’t care what UI, just make it work since its the cheapest temp sensor going now.

MCV, thanks for the clarification, you guys are doing a bang-up job, its just some polishing and you have quite a product…