zha-device-handlers: Reconfig failes for Innr SP120 power plug
Describe the bug After installing the latest core-2021.12.1 there was a quirk added for the Innr SP120 plug. I guess this is the quirk: Innr SP120 multiplier fix #1174 A fix I’m really looking forward too!!! But I don’t observe that the values where corrected, So I initiated a reconfigure in ZHA (using a Conbee 2 stick). The reconfigure process fails (see below) and the values remain wrong!
To Reproduce
- press reconfigure for the SP120 device in ZHA
Expected behavior I expect the reconfigure succeeds and that the the values from then on get corrected by the new multipliers
Screenshots
The result of reconfigure:
Additional context
The device info:
The device signature:
{
"node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4454, maximum_buffer_size=127, maximum_incoming_transfer_size=80, server_mask=0, maximum_outgoing_transfer_size=80, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
"endpoints": {
"1": {
"profile_id": 49246,
"device_type": "0x0010",
"in_clusters": [
"0x0000",
"0x0003",
"0x0004",
"0x0005",
"0x0006",
"0x0008",
"0x000a",
"0x0702",
"0x0b04"
],
"out_clusters": [
"0x0003",
"0x000a",
"0x0019"
]
},
"2": {
"profile_id": 49246,
"device_type": "0x1000",
"in_clusters": [
"0x1000"
],
"out_clusters": []
}
},
"manufacturer": "innr",
"model": "SP 120",
"class": "zhaquirks.innr.innr_sp120_plug.SP120"
}
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 21 (10 by maintainers)
nah, it does look right. just the AC_POWER_DIVISOR reads as 10, that’s why it’s 0.4W
I see some unsupported attributes responses… those should be no big deal. there is one interesting response that I have to look at: ConfigureReportingResponseRecord(status=141, direction=0, attrid=0) not sure how this response code makes sense tbh. INVALID_DATA_TYPE = 0x8D
@Adminiuga have you ever seen this come back in this response before?