Please Help Me Understand the Most Recent Command Class Changes

🚧 Developers
1

Another command class issue. I have this driver which has worked on previous versions of the hub firmware for some time without issue.

For ease here is the parse method call:

// Processes messages received from device.
def parse(String description) {
  logDebug "parse(String description)"
  logTrace "Description: ${description}"
  def result = []

  result << createEvent(createLastActivityEventMap())
  logDebug "Last Activity: ${device.currentValue("lastActivity")}"

  def cmd = zwave.parse(description, commandClassVersions)
  if (cmd) {
    result += zwaveEvent(cmd)
  }
  else {
    log.warn "Unable to parse description: $description"
  }
  return result
}

private getCommandClassVersions() {
  [
    0x20: 1,  // Basic		
    0x22: 1,  // Application Status (Model 0308)
    0x30: 2,  // Sensor Binary
    0x59: 1,  // AssociationGrpInfo (Model 0308)
    0x5A: 1,  // DeviceResetLocally (Model 0308)
    0x5E: 2,  // ZwaveplusInfo (Model 0308)
    0x7A: 2,  // Firmware Update MD (Model 0308)
    0x71: 3,  // Alarm v1 or Notification (v4)
    0x72: 2,  // ManufacturerSpecific
    0x73: 1,  // Powerlevel (Model 0308)
    0x80: 1,  // Battery
    0x84: 2,  // WakeUp
    0x85: 2,  // Association
    0x86: 1,  // Version (v2)
    0x98: 1   // Security (Model 0308)
  ]
}

On previous versions of hubitat when the sensor was accelerated the driver would receive one BasicSet message with value FF and one NotificationReport with essentially the same information. The BasicSet would go to all group associations and the NotificationReport just to the primary controller I'm guessing. I didn't care because without setting associations after pairing the hub would get both.

I would use the BasicSet message to send the active event. However, on the new versions of hubitat firmware I receive two BasicSet messages and two NotificationReport messages. One of the BasicSet messages has the correct value (FF) and the other BasicSet message is wrong and contains 00. The same thing is true of the NotificationReport; one of them has the correct values and the other is wrong. There have been no introductions or changes to my controller with new devices recently and I am getting this same issue reported to me from the one other user that I know uses this driver.

What changed? Is this a bug or am I not passing the correct versions of these command classes somehow? BasicSet is 0x20, right?

@mike.maxwell

2

Having trouble understanding how this can be related to the class versions, I didn't look at notification reports, but basicSet V1 and V2 both have just one parameter, so both versions of this command are the same, and would parse the same.
If you post up the description text from parse as well as the command it's being parsed to that exhibits this it may be helpful in understanding a bit more...

3

Here is a single acceleration active event.

image
image.png999×813 75.6 KB

I'm getting these both:
zw device: 6C, command: 2001, payload: 00 , isMulticast: false
zw device: 6C, command: 2001, payload: FF , isMulticast: false

The correct one is the second one (above) that occurs second in the log. The first BasicSet event that is passed to parse should not exist and didn't used to. Neither should the first NotificationReport with this description:
zw device: 6C, command: 7105, payload: 02 00 00 FF 07 00 01 02 , isMulticast: false

Only the second one with this description should exist (alarm level 255):
zw device: 6C, command: 7105, payload: 02 FF 00 FF 07 02 00 , isMulticast: false

4

There's something up with the device, just looking at the basic set, both are v1 frames being send by the device, this has nothing to do with the class updates.
You should have no issue confirming this with your zwave sniffer....

5

You were, of course, right. I just guessed this had been related to the command classes. I confirmed it was duplicating messages using the sniffer. I just tried an exclude and an include and that seems to have fixed it. Maybe there was a firmware bug with the rollover to 2020 and that's why both of us have the same issue.

Who knows. Thank you either way.

1 Like