[SOLVED] Bug in zwave.clockV1.clockSet?

Trying to set a clock on a thermostat; I use the "zwave.clockV1.clockSet" class:

def nowCal = Calendar.getInstance(location.timeZone);
def a = zwave.clockV1.clockSet(hour: nowCal.get(Calendar.HOUR_OF_DAY), minute: nowCal.get(Calendar.MINUTE), weekday: nowCal.get(Calendar.DAY_OF_WEEK)).format()
log.debug a

That code in ST logs "8104F02F" and properly sets the clock; but in Hubitat it logs "8104", and the clock is not set; it looks as if the actual time portion of the command is not included...

that class isn't currently implemented, I'll see what we can do about getting it into the next build.

OK; I was experimenting with doing something manually after reading the zwave documentation:

def b2 = nowCal.get(Calendar.DAY_OF_WEEK) << 5
b2 = b2 | nowCal.get(Calendar.HOUR_OF_DAY)
b2 = b2 << 8
b2 = b2 | nowCal.get(Calendar.MINUTE)
log.debug "8104" + Integer.toHexString(b2).toUpperCase()

I get something logged which seems to make sense ("8104F324", for example); but I still don't see the clock changing; not sure if it's because the format() function doesn't really return a character string but some different data type/object.

the class will be in the next build...

For the record, the code snippet above works perfectly fine to set the clock; it's equivalent to the result of zwave.clockV1.clockSet(...).format() call that I mentioned in the original post. The problem I was seeing was due to an incompatibility between Hubitat and ST in terms of how the two treat lists of concatenated commands.
And I understand that this will become irrelevant when the next version is pushed and clockSet is supported natively.