CommandClass structure compatibility

[elcosmelco]

Hi!

I have 2 Zwave sources in my homebrew home automation software. One integrated OpenZwave implementation and one based on Zwave2Mqtt. I wanted to replace both with ZwaveJs2Mqtt but I noticed the structure for command class is a bit different, where OZW goes with CommandClassID (byte), Index (ushort) and Instance (byte), ZwaveJS goes with commandClass (byte?), endPoint (ushort?) and property (string?).
So property causes somewhat of an issue where I would really prefer not to have to change the object type and propagate strings throughout my server and clients.
Is there a compatibility mode of sorts where I could get and set this data in the "old" format?

Cheers,
Elco

[robertsLando]

Is there a compatibility mode of sorts where I could get and set this data in the "old" format?

Actually nope, there is no compatibility mode. BTW you could use the writeValue api to manage writes

[elcosmelco]

Thanx I will look at the api!

Out of curiosity, how does ZWaveJS2Mqtt manage compatibility with HA then? Does HA have their own abstraction for that Zwave data structure that you translate to? How does the mapping from OZW's instance translate to the property string?

Cheers,
Elco

[robertsLando]

AFAIK there is no way to do that, you should start from scratch with the new implementation. But to be sure I ask to @kpine @blhoward2

[blhoward2]

There is a migration wizard for the original zwave integration in HA. It's not perfect but it maps what it can and presents a list of ones it couldn't match up. It was deemed not worth the effort to write one for the qt-openzwave integration.

Beyond that there is no mapping. It's an entirely new integration. No matter what your device ids will change so device triggers will need to be fixed. All the migration wizard preserves is entity and device naming.

If what you're working on is custom, just rewrite this part. Ozw was written at a time when the spec wasn't public and was reverse engineered. As a result many things weren't done in the most efficient way. Use zwavejs for all of its goodness.

[elcosmelco]

It is indeed homebrew software, and the transition to ZwaveJS will definitely happen as I have 2 locations, one an ancient integrated OZW implementation. It's just slightly overwhelming having to roll out server, clients and device mappings and also replacing an equally ancient Z stick with 80 devices on it - joy! 😅

Thanx for the context in any case!

[blhoward2]

Depending on what you're doing with it, there is a node red plugin that runs zwavejs. If you only want to deal with the automations, that's an option.

[elcosmelco]

Ah right! - I don't use node red as I built my own but it's good to know I have options should I ever get tired of maintaining my own stuff. Thanx for the suggestion!

[elcosmelco]

This answers my question in any case (it doesn't appear I can mark a reply as answer!)