zuno_CCMeterReport has a bug

[Cyberax]

Hi!

I think I've found a bug with zuno_CCMeterReport.

It has this logic:

Code: Select all

int zuno_CCMeterReport(byte channel, const ZUNOCommandPacket_t *paket, ZUNOCommandPacket_t *report_paket) {//v6
....
        if (paket == 0x0 || (len = paket->len) == sizeof(ZW_METER_GET_FRAME)) {
                len = sizeof(ZW_METER_GET_FRAME);
        }
....
        report->v3.byte1.properties1 = (ZUNO_CFG_CHANNEL(channel).sub_type & METER_REPORT_PROPERTIES1_METER_TYPE_MASK) | (len == sizeof(ZW_METER_GET_FRAME) ? 0x0  : (METER_REPORT_RATE_TYPE_IMPORT << METER_REPORT_PROPERTIES1_RATE_TYPE_SHIFT) | GET_SCALE2(params));
}

So basically, if the CCMeterReport is called with the null "paket" parameter, it always assumes that it needs to respond without the rate type and the scale.

It's an issue because it's always called this way in ZWSupport.c, so the rate type is never sent in reports that ZUno sends out. This in turn causes them to be rejected by the zwave-js integration with the "Unsupported rate type" error. This appears to be correct according to the ZWave spec.

I can fix this issue by simply changing this line to ignore the len:

Code: Select all

report->v3.byte1.properties1 = (ZUNO_CFG_CHANNEL(channel).sub_type & METER_REPORT_PROPERTIES1_METER_TYPE_MASK) | (METER_REPORT_RATE_TYPE_IMPORT << METER_REPORT_PROPERTIES1_RATE_TYPE_SHIFT) | GET_SCALE2(params);

[amatilda]

Hello.
Thank you for reporting that there are indeed certain problems in this class of commands.
This will be fixed in the next update.