Z-Wave Library Changes Feb 2017

Announcements
,
1

There were a few fixes and updates to the Z-Wave Library released this week:

  • Added scaledConfigurationValue to ConfigurationReport and v2 ConfigurationSet
  • Added encapsulate(cmd) to Crc16Encap and fixed a bug where one byte from the CRC value was included in the data field. Note encapsulatedCommand(versions = [:]) isn’t working yet.
  • Added parsing and encapsulate(cmdList) to MultiCmdEncap
  • Fixed setColorComponent exception in SwitchColorGet and SwitchColorReport
  • Fixed ConfigurationSet handling of negative and large values of scaledConfigurationValue

It was the first update in over a year and it did not go smoothly. I’m hoping to release updates in smaller, better tested pieces in the future.

3 Likes
2

@duncan any update to the LED status updates that fill the event log?
Unnecessary LED-status reporting from GE switches?

3

Any chance of some updated documentation for these command classes?

I just tried the following to simplify my handler for Crc16Encap (i.e. assuming the same structure as SecurityMessageEncapsulation and MultiChannelCmdEncap):

def zwaveEvent(physicalgraph.zwave.commands.crc16encapv1.Crc16Encap cmd) {
    def encapsulatedCommand = cmd.encapsulatedCommand([0x20: 1, 0x22: 1, 0x26: 3, ..., 0x98: 1])
    if (!encapsulatedCommand) {
        logger("zwaveEvent(): Could not extract command from ${cmd}","error")
    } else {
        return zwaveEvent(encapsulatedCommand)
    }
}

but i just get an error:

error groovy.lang.MissingPropertyException: No such property: Zwave for class: physicalgraph.zwave.commands.crc16encapv1.Crc16Encap
4

Here’s to hoping… :smiley:

500×700 146 KB

1 Like
5

That’s on the hub, not the cloud platform. I assume it is fixed in the next update but I’ll have to check to be sure.

EDIT: yeah looks like it’s fixed in the next hub update.

6

:tired_face: can’t believe I messed that up too. I thought I had confirmed it was working but I had it confused with MultiCmdEncap. I’ve been spending too long writing C where the compiler would catch these errors.

7

@duncan may want to enable type checking? http://docs.groovy-lang.org/next/html/documentation/core-semantics.html#static-type-checking

Personally I mostly write in JavaScript (with some PHP at work) but I’ve been using TypeScript to get type safety.

Also may want to beef up the assertions in the real test network that you’re deploying it on. I like the strategy endorsed by Growing Object-Oriented Software, Guided by Tests - start with end-to-end tests, then unit tests.

And personally, if you’re having trouble getting all the test code written, I’d slack on the unit tests before the end-to-end tests…

1 Like
8

Hi @duncan,

Any update on the next batch of changes to the Z-Wave library?

I’ve been doing a fair bit of Z-Wave device development in the last few weeks and have put together a list of issues and enhancement requests:

  • MultiChannelEndPointFindReport does not appear have an attribute listing the actual endpoints found. E.g. Raw command: “zw device: 09, command: 600C, payload: 00 10 01 01 02 03” is parsed to MultiChannelEndPointFindReport(genericDeviceClass: 16, reportsToFollow: 0, specificDeviceClass: 1). The actual endpoints [01,02,03] are missing. I would expect an endpoints attribute perhaps…?
  • Can we get support for the ConfigurationV3 command class? I’d like to be able to request and process CONFIGURATION_NAME_REPORTs, CONFIGURATION_PROPERTIES_REPORTs etc. in my Z-Wave Tweaker tool.
  • notificationv3.NotificationSupportedReport commands currently fail to parse (at least when they are extracted from security encapsulation). E.g. "Unable to extract security encapsulated command from: SecurityMessageEncapsulation(commandByte: [2, 16, 3], commandClassIdentifier: 113, commandIdentifier: 8, reserved13: 0, secondFrame: false, sequenceCounter: 0, sequenced: false)"
  • Is there a lookup function to translate commandClassIds and commandIds to human-readable names? E.g. something like zwaveUtils.lookupCommandName(commandClassId, commandId) perhaps, where lookupCommandName(0x70, 0x03) would return something like [commandclassName: "CONFIGURATION", commandName: "CONFIGURATION_REPORT"]. This would also be really useful in my Z-Wave Tweaker tool, where currently I’m doing a hard-coded lookup.

Thanks, z

1 Like
9

The script that was originally used to generate these classes didn’t handle array fields and more complicated commands very well.

I’ve made tickets to fix the implementations of MultiChannelEndPointFindReport and NotfiicationSupportedReport and to add ConfigurationV3, but I haven’t had time to work on it.

As for converting to readable names, we don’t have that functionality, but you could use class names like

zwave.commandClass(0x70).getClass().getSimpleName()

and

zwave.command("7003").getClass().getSimpleName()

or

zwave.commandClass(0x70)?.command(0x03).getClass().getSimpleName()

commandClass() can also take a second param for version if you don’t want the default.

1 Like
10

Thanks, but we can’t use getClass(), it’s not allowed!

java.lang.SecurityException: Invoking class physicalgraph.zwave.commandclasses.ConfigurationV2.getClass() is not allowed

11

Hi @duncan,

Just to add that a couple of people using my Z-Wave tweaker have discovered some more issues when unencapsulating security commands. (i.e. using physicalgraph.zwave.commands.securityv1.SecurityMessageEncapsulation.encapsulatedCommand() )

First: unencapsulating AssociationGroupNameReports gives the following error:

error java.lang.IndexOutOfBoundsException: toIndex = 3 @ line ...

Second: unencapsulating WakeUpIntervalReports gives the following error:

error groovy.lang.MissingMethodException: No signature of method: static     physicalgraph.zwave.ZwaveUtils.uint24FromBytes() is applicable for argument types: (java.util.ArrayList$SubList, java.lang.Integer) values: [[0, 56, 64, 1], 0]
    Possible solutions: uint24FromBytes(java.util.ArrayList, int) @ line ...
2 Likes
12

2 posts were split to a new topic: SRT321 thermostat setpoints stopped working