Command Classes and versions


(Anders) #1

Hi,

I’m working on a Device Handler for the new Fibaro Wall Plug ZW5. It’s working find for me, and one other user. But now a third user is reporting a different version (v1 not v3) of the command class. He apparently has the exact same raw signature on the device…

Is it possible he is getting different versions of the command class with the exact same device? If so; why?

The original thread is at: [Release] Fibaro Wall Plug (Old version, not zwave+)

Thanks,
Anders,


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #2

Wild guess… The third user has a newer/older firmware on the device?


(Anders) #3

Wouldn’t a different firmware be reflected in the raw fingerprint? They are identical…

It’s the only reason I can think of too, but my understanding of this is very basic so I’m just wondering if anyone can think of anything elese. :slight_smile:


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #4

Unfortunately, not necessarily, as far as I am aware.

Official Z-Wave reference documentation isn’t published (I think?) because it needs to be licensed.

But based on ZigBee, the fingerprint fields only need to indicate the overall protocol (ZigBee HA) and the Capabilities (cluster types; e.g., switch, thermostat, etc.), and then there is a portion for manufacturer, model, version.

But the “manufacturer, model, version” is perhaps not enforced or used consistently?


Hopefully someone will chime in (or try Googling!) with the exact specifications of the Z-Wave Fingerprint and let you know if it must always indicate a firmware version or if it should include the Command Class Version, etc…

It may also be SmartThings that isn’t pulling in the full fingerprint?

I apologize for just speculating … I’m just hoping it might lead you in the right direction.


BTW: I just glanced at the other Topic you referenced. Perhaps the Command Class 1 vs 3 is a configurable option? So both the hardware and firmware is actually the same, but a Z-Wave config command can be sent to set the Class? … I’d presume it may default to the lower class for compatibility … OK… I’m making a lot of assumptions. :confused:


(Anders) #5

Thanks for speculating with me. :slight_smile:

I was a bit unclear and I meant the RAW Description, not the fingerprint. At least for this plug it contains the firmware number and it’s the same between me and the other guy. The whole string is identical.

I don’t see any parameters from the manual that should change the behaviour in such a way. The only stuff I can see that might change anything is the stuff about secure. I thing it would be weird if that changed anything though, because the secure messages seems to just be wrappers around the original message.

Anders,


#6

It used to be you had to have a developers license to get to the docs. In Autumn 2016 the Z wave alliance decided to make the interoperability layer specification open in order to encourage wider adoption.


#7

I’m not gonna get into the details of all this, and I hope the docs will clear up some of the confusion, but another possibility is that one of you did a secure pairing and the other did an insecure pairing. According to Fibaro, security options were added to this device with firmware version 3.2

As far as the whole fingerprint stuff… This is what happens when you design for zigbee and then try to shoehorn zwave into it. Zwave doesn’t have clusters and it doesn’t have fingerprints, but the SmartThings platform says that it does and it tries to create one that will look just like what you would get from the zigbee device. So just query a device for the actual Z wave information if you need it. :wink:


(JJG) #8

Late answer but…
You should check applicationVersion.applicationSubVersion from VersionReport answer to the VersionGet command.
It gives the firmware revision for the Device.
Beware that for an other Fibaro Device, the FGK-101 Door/Window sensor, the Z-wave+ version (3.2) is so different from the pre-Z-wave+ version (<=2.5) that I had to completely rewrite my custom Handler.
Fibaro obviously does not know the meaning of “upward compatibility”, at least at the hardware/handler interface level…