Lifecycle "generating doConfigure event for nil provisioning state"

Developer Programs Writing Edge Drivers
1

Hi @nayelyz

I just saw in the CLI logs a new behavior when installing a new driver version with the CLI:

  • Once the “init” lifecycle has been executed, a LOG INFO message is received with the text:
2023-08-11T22:05:32.410628759+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Light Table)> generating doConfigure event for nil provisioning state.
  • This causes the default “doConfigure” lifeCycle to be executed, which with older firmware versions is only executed automatically on first device installation.
  • I am using the beta firmware version 49.07.
  • Since when does this happen and what does “nil provisioning state” mean?
  • Does this also happen when a new version of a driver is updated automatically or is it only when the new version is installed with the CLI?

Thank you

2023-08-11T22:05:31.957217426+00:00 DEBUG Zigbee Light Multifunction Mc-TEST  driver device thread event handled
2023-08-11T22:05:31.958512093+00:00 TRACE Zigbee Light Multifunction Mc-TEST  Received event with handler _resync
2023-08-11T22:05:31.959653426+00:00 TRACE Zigbee Light Multifunction Mc-TEST  Received event with handler environment_info
2023-08-11T22:05:31.960844426+00:00 DEBUG Zigbee Light Multifunction Mc-TEST  Z-Wave hub node ID environment changed.
2023-08-11T22:05:32.000291759+00:00 TRACE Zigbee Light Multifunction Mc-TEST  Found DeviceLifecycleDispatcher handler in zigbee_light_multifunctions
2023-08-11T22:05:32.006256426+00:00 PRINT Zigbee Light Multifunction Mc-TEST  <<<<< Device Init >>>>>>
2023-08-11T22:05:32.007733093+00:00 INFO Zigbee Light Multifunction Mc-TEST  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> emitting event: {"component_id":"main","attribute_id":"progOn","state":{"value":"Active"},"capability_id":"legendabsolute60149.progressiveOn1"}
2023-08-11T22:05:32.050378426+00:00 INFO Zigbee Light Multifunction Mc-TEST  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> emitting event: {"component_id":"main","attribute_id":"progOff","state":{"value":"Inactive"},"capability_id":"legendabsolute60149.progressiveOff1"}
2023-08-11T22:05:32.092071426+00:00 INFO Zigbee Light Multifunction Mc-TEST  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> emitting event: {"component_id":"main","attribute_id":"randomOnOff","state":{"value":"Inactive"},"capability_id":"legendabsolute60149.randomOnOff1"}
2023-08-11T22:05:32.139868426+00:00 INFO Zigbee Light Multifunction Mc-TEST  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> emitting event: {"component_id":"main","attribute_id":"randomNext","state":{"value":"Inactive"},"capability_id":"legendabsolute60149.randomNextStep"}
2023-08-11T22:05:32.205679759+00:00 INFO Zigbee Light Multifunction Mc-TEST  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> emitting event: {"component_id":"main","attribute_id":"forcedOnLevel","state":{"value":0},"capability_id":"legendabsolute60149.forcedOnLevel"}
2023-08-11T22:05:32.255647426+00:00 INFO Zigbee Light Multifunction Mc-TEST  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> emitting event: {"component_id":"main","attribute_id":"mirrorGroupFunction","state":{"value":"Inactive"},"capability_id":"legendabsolute60149.mirrorGroupFunction"}
2023-08-11T22:05:32.310736426+00:00 INFO Zigbee Light Multifunction Mc-TEST  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> emitting event: {"component_id":"main","attribute_id":"effectsSetCommand","state":{"value":"Inactive"},"capability_id":"legendabsolute60149.effectsSetCommand"}
2023-08-11T22:05:32.352471093+00:00 DEBUG Zigbee Light Multifunction Mc-TEST  Luz Mesita device thread event handled
2023-08-11T22:05:32.356372426+00:00 TRACE Zigbee Light Multifunction Mc-TEST  Received event with handler environment_info
2023-08-11T22:05:32.410628759+00:00 INFO Zigbee Light Multifunction Mc-TEST  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> generating doConfigure event for nil provisioning state
2023-08-11T22:05:32.517222093+00:00 TRACE Zigbee Light Multifunction Mc-TEST  Found DeviceLifecycleDispatcher handler in zigbee_light_multifunctions

UPDATE:

In logs for driver installation message: doConfigure callback did not fail, transitioning device to “PROVISIONED” received too

2023-08-11T22:05:33.157037093+00:00 DEBUG Zigbee Light Multifunction Mc-TEST  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> doConfigure callback did not fail, transitioning device to "PROVISIONED"
2

Did the new version have new capabilities by any chance?

I’ve seen this before but during a driver switch, the provisioned state property is used to define if the new driver can handle the device accordingly, the capabilities it includes are reviewed during this process.
However, I haven’t seen it gets nil, only PROVISIONED or NONFUNCTIONAL.

3

The new version had no new capabilities, just a change to a command sent to the device to change the level in steps.

4

@nayelyz

To test, I have made a change driver to another “Zigbee Light Multifunction Mc” driver and I have returned to the same previous driver “Zigbee Light Multifunction Mc-TEST” and the same message (in logs is in bold) has been received and the configuration has been carried out.

Then this other message arrived: doConfigure callback did not fail, transitioning device to “PROVISIONED”, in the log it is also in bold

2023-08-11T22:42:53.827116529+00:00 TRACE Zigbee Light Multifunction Mc-TEST Setup driver zigbee_light_multifunctions with lifecycle handlers:
DeviceLifecycleDispatcher: zigbee_light_multifunctions
default_handlers:
doConfigure:
infoChanged:
init:
added:
driverSwitched:
removed:
child_dispatchers:
DeviceLifecycleDispatcher: zigbee_light_multifunctions → XY Color Bulb
default_handlers:
added:
child_dispatchers:

2023-08-11T22:42:53.828315196+00:00 TRACE Zigbee Light Multifunction Mc-TEST Setup driver zigbee_light_multifunctions with Capability handlers:
CapabilityCommandDispatcher: zigbee_light_multifunctions
default_handlers:
refresh:
refresh
legendabsolute60149.colorChangeTimer:
setColorChangeTimer
colorTemperature:
setColorTemperature
legendabsolute60149.progressiveOff1:
setProgOff
switchLevel:
setLevel
legendabsolute60149.circadian:
setCircadian
legendabsolute60149.colorChanging:
setColorChanging
switch:
on
off
legendabsolute60149.getGroups:
setGetGroups
legendabsolute60149.levelSteps:
setLevelSteps
legendabsolute60149.colorChangeMode1:
setColorChangeMode
legendabsolute60149.mirrorGroupFunction:
setMirrorGroupFunction
colorControl:
setColor
setSaturation
setHue
legendabsolute60149.colorTemperatureSteps:
setColorTempSteps
legendabsolute60149.progressiveOn1:
setProgOn
legendabsolute60149.forcedOnLevel:
setForcedOnLevel
legendabsolute60149.randomOnOff1:
setRandomOnOff
legendabsolute60149.effectsSetCommand:
setEffectsSetCommand
child_dispatchers:
CapabilityCommandDispatcher: zigbee_light_multifunctions → XY Color Bulb
default_handlers:
colorControl:
setColor
setSaturation
setHue
child_dispatchers:

2023-08-11T22:42:53.830143529+00:00 TRACE Zigbee Light Multifunction Mc-TEST Setup driver zigbee_light_multifunctions with Zigbee handlers:
ZigbeeMessageDispatcher: zigbee_light_multifunctions
default_handlers:
attr:
ZclClusterAttributeValueHandler: cluster: Level, attribute: CurrentLevel
ZclClusterAttributeValueHandler: cluster: OnOff, attribute: OnOff
ZclClusterAttributeValueHandler: cluster: ColorControl, attribute: CurrentSaturation
ZclClusterAttributeValueHandler: cluster: ColorControl, attribute: CurrentHue
ZclClusterAttributeValueHandler: cluster: ColorControl, attribute: ColorTemperatureMireds
global:
ZclGlobalCommandHandler: cluster: OnOff, command: DefaultResponse
cluster:
ZclClusterCommandHandler: cluster: Groups, command: GetGroupMembership
zdo:
child_dispatchers:
ZigbeeMessageDispatcher: zigbee_light_multifunctions → XY Color Bulb
default_handlers:
attr:
ZclClusterAttributeValueHandler: cluster: ColorControl, attribute: CurrentY
ZclClusterAttributeValueHandler: cluster: ColorControl, attribute: CurrentX
global:
cluster:
zdo:
child_dispatchers:

2023-08-11T22:42:53.897654529+00:00 TRACE Zigbee Light Multifunction Mc-TEST Zigbee Device: 84944c69-fa8e-417e-bb62-92b7d5087d63
Manufacturer: OSRAM Model: Classic A60 W clear - LIGHTIFY
[3]: server: TouchlinkCommissioning, Basic, Identify, Groups, Scenes, OnOff, Level, 0xFC0F | client: OTAUpgrade
2023-08-11T22:42:53.898812529+00:00 DEBUG Zigbee Light Multifunction Mc-TEST driver device thread event handled
2023-08-11T22:42:53.900169862+00:00 TRACE Zigbee Light Multifunction Mc-TEST Received event with handler _resync
2023-08-11T22:42:53.901445529+00:00 TRACE Zigbee Light Multifunction Mc-TEST Received event with handler environment_info
2023-08-11T22:42:53.902727529+00:00 DEBUG Zigbee Light Multifunction Mc-TEST Z-Wave hub node ID environment changed.
2023-08-11T22:42:53.917327196+00:00 TRACE Zigbee Light Multifunction Mc-TEST Found DeviceLifecycleDispatcher handler in zigbee_light_multifunctions
2023-08-11T22:42:53.926454529+00:00 PRINT Zigbee Light Multifunction Mc-TEST <<<<< Device Init >>>>>>
2023-08-11T22:42:53.928005862+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> emitting event: {“state”:{“value”:“Inactive”},“component_id”:“main”,“capability_id”:“legendabsolute60149.progressiveOn1”,“attribute_id”:“progOn”}
2023-08-11T22:42:53.938999862+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> emitting event: {“state”:{“value”:“Inactive”},“component_id”:“main”,“capability_id”:“legendabsolute60149.progressiveOff1”,“attribute_id”:“progOff”}
2023-08-11T22:42:53.959217529+00:00 WARN Zigbee Light Multifunction Mc-TEST Attempted to generate event for 84944c69-fa8e-417e-bb62-92b7d5087d63.main but it does not support capability
Circadian
2023-08-11T22:42:53.963058529+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> emitting event: {“state”:{“value”:“Inactive”},“component_id”:“main”,“capability_id”:“legendabsolute60149.randomOnOff1”,“attribute_id”:“randomOnOff”}
2023-08-11T22:42:53.988303196+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> emitting event: {“state”:{“value”:“Inactive”},“component_id”:“main”,“capability_id”:“legendabsolute60149.randomNextStep”,“attribute_id”:“randomNext”}
2023-08-11T22:42:54.052575196+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> emitting event: {“state”:{“value”:0},“component_id”:“main”,“capability_id”:“legendabsolute60149.forcedOnLevel”,“attribute_id”:“forcedOnLevel”}
2023-08-11T22:42:54.059180196+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> emitting event: {“state”:{“value”:“Inactive”},“component_id”:“main”,“capability_id”:“legendabsolute60149.mirrorGroupFunction”,“attribute_id”:“mirrorGroupFunction”}
2023-08-11T22:42:54.078539196+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> emitting event: {“state”:{“value”:“Inactive”},“component_id”:“main”,“capability_id”:“legendabsolute60149.effectsSetCommand”,“attribute_id”:“effectsSetCommand”}
2023-08-11T22:42:54.094090862+00:00 DEBUG Zigbee Light Multifunction Mc-TEST Luz Mesita device thread event handled
2023-08-11T22:42:54.100350196+00:00 TRACE Zigbee Light Multifunction Mc-TEST Received event with handler environment_info
2023-08-11T22:42:54.106653862+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> generating doConfigure event for nil provisioning state
2023-08-11T22:42:54.186809862+00:00 TRACE Zigbee Light Multifunction Mc-TEST Found DeviceLifecycleDispatcher handler in zigbee_light_multifunctions
2023-08-11T22:42:54.187885529+00:00 TRACE Zigbee Light Multifunction Mc-TEST Found CapabilityCommandDispatcher handler in zigbee_light_multifunctions
2023-08-11T22:42:54.189272529+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0xC0CD, dest_endpoint: 0x03, profile: 0x0104, cluster: OnOff >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x00, seqno: 0x00, ZCLCommandId: 0x00 >, < ReadAttribute || AttributeId: 0x0000 > > >
2023-08-11T22:42:54.218250196+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0xC0CD, dest_endpoint: 0x03, profile: 0x0104, cluster: Level >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x00, seqno: 0x00, ZCLCommandId: 0x00 >, < ReadAttribute || AttributeId: 0x0000 > > >
2023-08-11T22:42:54.366230862+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0xC0CD, dest_endpoint: 0x03, profile: 0x0000, cluster: 0x0021 >, < ZDOMessageBody || < ZDOHeader || seqno: 0x00 >, < BindRequest || src_address: 7CB03EAA0A04B6BE, src_endpoint: 0x03, cluster: OnOff, dest_addr_mode: 0x03, dest_address: 286D97000204B680, dest_endpoint: 0x01 > >

2023-08-11T22:42:54.416598196+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0xC0CD, dest_endpoint: 0x03, profile: 0x0104, cluster: OnOff >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x00, seqno: 0x00, ZCLCommandId: 0x06 >, < ConfigureReporting || < AttributeReportingConfiguration || direction: 0x00, attr_id: 0x0000, DataType: Boolean, minimum_reporting_interval: 0x0000, maximum_reporting_interval: 0x012C > > > >
2023-08-11T22:42:54.437599862+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0xC0CD, dest_endpoint: 0x03, profile: 0x0000, cluster: 0x0021 >, < ZDOMessageBody || < ZDOHeader || seqno: 0x00 >, < BindRequest || src_address: 7CB03EAA0A04B6BE, src_endpoint: 0x03, cluster: Level, dest_addr_mode: 0x03, dest_address: 286D97000204B680, dest_endpoint: 0x01 > >

2023-08-11T22:42:54.479584529+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0xC0CD, dest_endpoint: 0x03, profile: 0x0104, cluster: Level >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x00, seqno: 0x00, ZCLCommandId: 0x06 >, < ConfigureReporting || < AttributeReportingConfiguration || direction: 0x00, attr_id: 0x0000, DataType: Uint8, minimum_reporting_interval: 0x0001, maximum_reporting_interval: 0x0E10, reportable_change: 0x01 > > > >
2023-08-11T22:42:54.541318529+00:00 DEBUG Zigbee Light Multifunction Mc-TEST Luz Mesita device thread event handled
2023-08-11T22:42:54.542625196+00:00 DEBUG Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> doConfigure callback did not fail, transitioning device to “PROVISIONED”
2023-08-11T22:42:54.548939529+00:00 TRACE Zigbee Light Multifunction Mc-TEST Received event with handler device_lifecycle
2023-08-11T22:42:54.550256196+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> received lifecycle event: added
2023-08-11T22:42:54.599543862+00:00 DEBUG Zigbee Light Multifunction Mc-TEST Luz Mesita device thread event handled
2023-08-11T22:42:54.600487196+00:00 TRACE Zigbee Light Multifunction Mc-TEST Received event with handler device_lifecycle
2023-08-11T22:42:54.601731529+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> received lifecycle event: driverSwitched
2023-08-11T22:42:54.629267529+00:00 TRACE Zigbee Light Multifunction Mc-TEST Found DeviceLifecycleDispatcher handler in zigbee_light_multifunctions
2023-08-11T22:42:54.630505529+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0xC0CD, dest_endpoint: 0x03, profile: 0x0104, cluster: Groups >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x01, seqno: 0x00, ZCLCommandId: 0x02 >, < GetGroupMembership || group_list_length: 0x00 > > >
2023-08-11T22:42:54.897294529+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0xC0CD, dest_endpoint: 0x03, profile: 0x0104, cluster: OnOff >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x00, seqno: 0x00, ZCLCommandId: 0x02 >, < WriteAttribute || < AttributeRecord || attr_id: 0x4003, DataType: Enum8, data: 0xFF > > > >
2023-08-11T22:42:54.979922529+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0xC0CD, dest_endpoint: 0x03, profile: 0x0104, cluster: OnOff >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x00, seqno: 0x00, ZCLCommandId: 0x02 >, < WriteAttribute || < AttributeRecord || attr_id: 0x8002, DataType: Enum8, data: 0x02 > > > >
2023-08-11T22:42:55.266335529+00:00 PRINT Zigbee Light Multifunction Mc-TEST Remove Groups >>>>>>>>>>>>>>>>>
2023-08-11T22:42:55.273285529+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0xC0CD, dest_endpoint: 0x03, profile: 0x0104, cluster: Groups >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x01, seqno: 0x00, ZCLCommandId: 0x04 >, < RemoveAllGroups || > > >
2023-08-11T22:42:55.462572529+00:00 INFO Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0xC0CD, dest_endpoint: 0x03, profile: 0x0104, cluster: Groups >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x01, seqno: 0x00, ZCLCommandId: 0x02 >, < GetGroupMembership || group_list_length: 0x00 > > >
2023-08-11T22:42:55.721902196+00:00 PRINT Zigbee Light Multifunction Mc-TEST Device ID <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)>
2023-08-11T22:42:55.736245196+00:00 PRINT Zigbee Light Multifunction Mc-TEST Manufacturer >>> OSRAM Manufacturer_Len >>> 5
2023-08-11T22:42:55.737570196+00:00 PRINT Zigbee Light Multifunction Mc-TEST Model >>> Classic A60 W clear - LIGHTIFY Model_len >>> 30
2023-08-11T22:42:55.740076529+00:00 PRINT Zigbee Light Multifunction Mc-TEST <<<<< Firmware Version >>>>> 01020412
2023-08-11T22:42:55.741351529+00:00 PRINT Zigbee Light Multifunction Mc-TEST Memory >>>>>>> 962.966796875 Kbytes

5

Mmm, I’ll need to ask the team what could cause the provisioned state to be nil and trigger that behavior of doConfigure.
Once I get their feedback, I’ll let you know.

1 Like
6

@nayelyz

However, when I make a driver change to the driver that this device was originally paired and these messages are not received and doConfigure is not executed

It seems that this driver does not have the nil state for this device

connecting… connected
2023-08-11T22:40:23.396226508+00:00 DEBUG Zigbee Light Multifunction Mc driver device thread event handled
2023-08-11T22:40:37.717949849+00:00 TRACE Zigbee Light Multifunction Mc Received event with handler device_lifecycle
2023-08-11T22:40:38.026470849+00:00 TRACE Zigbee Light Multifunction Mc Zigbee Device: 84944c69-fa8e-417e-bb62-92b7d5087d63
Manufacturer: OSRAM Model: Classic A60 W clear - LIGHTIFY
[3]: server: TouchlinkCommissioning, Basic, Identify, Groups, Scenes, OnOff, Level, 0xFC0F | client: OTAUpgrade
2023-08-11T22:40:38.027552515+00:00 INFO Zigbee Light Multifunction Mc <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> received lifecycle event: added
2023-08-11T22:40:38.074272182+00:00 TRACE Zigbee Light Multifunction Mc Received event with handler device_lifecycle
2023-08-11T22:40:38.077945849+00:00 INFO Zigbee Light Multifunction Mc <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> received lifecycle event: driverSwitched
2023-08-11T22:40:38.196794515+00:00 TRACE Zigbee Light Multifunction Mc Found DeviceLifecycleDispatcher handler in zigbee_light_multifunctions
2023-08-11T22:40:38.197847515+00:00 PRINT Zigbee Light Multifunction Mc Remove Groups >>>>>>>>>>>>>>>>>
2023-08-11T22:40:38.199226182+00:00 INFO Zigbee Light Multifunction Mc <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0xC0CD, dest_endpoint: 0x03, profile: 0x0104, cluster: Groups >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x01, seqno: 0x00, ZCLCommandId: 0x04 >, < RemoveAllGroups || > > >

7

So the one with the issue is the one with “-TEST” at the end of the name, right?
During the driver change, this function is called: Driver.default_capability_match_driverSwitched_handler, and, after the evaluation, a provisioned status is set, so, as I understand, it’s expected, that’s why a doConfigure lifecycle doesn’t run automatically during a driver switch, you need to force it.
If you send an “update” to “Zigbee Light Multifunction Mc”, you don’t get the nil message?

8

I’ll try it tomorrow, I turned off the pc to go to sleep

9

ok, no rush, I just wanted to see what happened to get a bigger picture of the current behavior.

10

Hi @nayelyz

Device is installed with the Zigbee Light Multifunction Mc-TEST driver since yesterday night, I see that the Provisioning State is PROVISIONED. see capture.

Luz Mesita
Luz Mesita1020×1618 79.2 KB

Now I’m going to install a new version of the driver simply by changing a comment and it detects that the Provisioning State = nil and perform doConfigure

2023-08-12T10:12:38.835518533+00:00 INFO Zigbee Light Multifunction Mc-TEST  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> generating doConfigure event for nil provisioning state

After executing doConfigure, the status change message is received:

2023-08-12T10:12:40.324176534+00:00 DEBUG Zigbee Light Multifunction Mc-TEST <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Light Table)> doConfigure callback did not fail , transitioning device to " PROVISIONED"

Now I change the driver to its original Zigbee Light Multifunction Mc driver

doConfigure is not executed, only init, added and driverSwitched are executed

Manufacturer: OSRAM Model: Classic A60 W clear - LIGHTIFY
        [3]: server: TouchlinkCommissioning, Basic, Identify, Groups, Scenes, OnOff, Level, 0xFC0F | client: OTAUpgrade     
2023-08-12T10:22:05.873528415+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> received lifecycle event: added
2023-08-12T10:22:05.888181415+00:00 TRACE Zigbee Light Multifunction Mc  Received event with handler device_lifecycle
2023-08-12T10:22:05.889065415+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> received lifecycle event: driverSwitched
2023-08-12T10:22:05.916900415+00:00 TRACE Zigbee Light Multifunction Mc  Found DeviceLifecycleDispatcher handler in zigbee_light_multifunctions
2023-08-12T10:22:05.917813415+00:00 PRINT Zigbee Light Multifunction Mc  Remove Groups >>>>>>>>>>>>>>>>>

The state with the new driver has changed Provisioning State DRIVER_SWITCH

Luz Mesita-switched
Luz Mesita-switched1022×1620 79.1 KB

Now I generate a new version of the original Zigbee Light Multifunction Mc driver and install it with the CLI

It detects nil value for the states of the 5 paired devices in the driver and the configuration is executed in all of them.

After running doConfigure the state on all devices is Provisioning State PROVISIONED

2023-08-12T10:30:01.818901441+00:00 DEBUG Zigbee Light Multifunction Mc  driver device thread event handled
2023-08-12T10:30:01.820267774+00:00 TRACE Zigbee Light Multifunction Mc  Received event with handler _resync
2023-08-12T10:30:01.821513441+00:00 TRACE Zigbee Light Multifunction Mc  Received event with handler environment_info
2023-08-12T10:30:01.830154774+00:00 DEBUG Zigbee Light Multifunction Mc  Z-Wave hub node ID environment changed.
2023-08-12T10:30:01.833919441+00:00 TRACE Zigbee Light Multifunction Mc  Received event with handler environment_info
2023-08-12T10:30:01.897899774+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> generating doConfigure event for nil provisioning state
2023-08-12T10:30:01.899362774+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 6895e080-7e31-4a4f-a72d-ed3b16ab39c5 [0xC47C] (Luz H. Irene)> generating doConfigure event for nil 
provisioning state
2023-08-12T10:30:01.901152774+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 0f922249-3c54-40fa-a217-ebe9eec40e53 [0x8723] (Lámpara Sofás)> generating doConfigure event for nil provisioning state
2023-08-12T10:30:01.905748774+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 523dbe7b-9f31-4ffb-91ee-cd28e8aeba0a [0x6835] (Luz H. Iñaki)> generating doConfigure event for nil 
provisioning state
2023-08-12T10:30:01.908380774+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 2788b448-21d0-47ce-935a-2b64dc5b5d2e [0xD468] (Luz Cocina)> generating doConfigure event for nil provisioning state
2023-08-12T10:30:01.911506774+00:00 TRACE Zigbee Light Multifunction Mc  Found DeviceLifecycleDispatcher handler in zigbee_light_multifunctions
2023-08-12T10:30:01.912843108+00:00 PRINT Zigbee Light Multifunction Mc  <<<<< Device Init >>>>>>

Now I generate a new version of the original Zigbee Light Multifunction Mc driver and install it with the CLI

Once again, it detects nil value for the states of the 5 paired devices in the driver and the configuration is executed in all of them.

After executing doConfigure the state on all devices is Provisioning State PROVISIONED

2023-08-12T10:39:49.231167954+00:00 TRACE Zigbee Light Multifunction Mc  Received event with handler environment_info
2023-08-12T10:39:49.287535621+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> generating doConfigure event for nil provisioning state
2023-08-12T10:39:49.296215287+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 6895e080-7e31-4a4f-a72d-ed3b16ab39c5 [0xC47C] (Luz H. Irene)> generating doConfigure event for nil 
provisioning state
2023-08-12T10:39:49.298236287+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 0f922249-3c54-40fa-a217-ebe9eec40e53 [0x8723] (Lámpara Sofás)> generating doConfigure event for nil provisioning state
2023-08-12T10:39:49.299997621+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 523dbe7b-9f31-4ffb-91ee-cd28e8aeba0a [0x6835] (Luz H. Iñaki)> generating doConfigure event for nil 
provisioning state
2023-08-12T10:39:49.301753954+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 2788b448-21d0-47ce-935a-2b64dc5b5d2e [0xD468] (Luz Cocina)> generating doConfigure event for nil provisioning state
2023-08-12T10:39:49.316726287+00:00 TRACE Zigbee Light Multifunction Mc  Found DeviceLifecycleDispatcher handler in zigbee_light_multifunctions
2023-08-12T10:39:49.318089954+00:00 PRINT Zigbee Light Multifunction Mc  <<<<< Device Init >>>>>>

Finally I tried with another different driver Zigbee Contact Mc.
Generate a new version of the driver and install it with the CLI

It also detects nil value for the states of the 4 paired devices in the driver and the configuration is executed in all of them.

Before and after installing the new version the status on all devices is Provisioning State PROVISIONED

2023-08-12T10:50:34.412947655+00:00 TRACE Zigbee Contact Mc  Received event with handler environment_info
2023-08-12T10:50:34.426991988+00:00 INFO Zigbee Contact Mc  <ZigbeeDevice: faeb431d-4059-472f-bc70-dbd73863aaf0 [0xAE01] (Puerta Portal)> generating doConfigure event for nil provisioning state
2023-08-12T10:50:34.436206988+00:00 INFO Zigbee Contact Mc  <ZigbeeDevice: cf75c395-4ad6-4d2d-911b-7091f24f05fe [0x62A2] (Puerta Sótano)> generating doConfigure event for nil provisioning state
2023-08-12T10:50:34.440886988+00:00 INFO Zigbee Contact Mc  <ZigbeeDevice: 14925f23-71db-4a44-a2c9-6a37f9837ac6 [0x77EE] (Puerta Felisa)> generating doConfigure event for nil provisioning state
2023-08-12T10:50:34.442344988+00:00 INFO Zigbee Contact Mc  <ZigbeeDevice: d5c46aef-8f26-4442-a671-2f36f00e42e5 [0x2F64] (Puerta Casa)> generating doConfigure event for nil provisioning 
state
2023-08-12T10:50:34.451651321+00:00 TRACE Zigbee Contact Mc  Found DeviceLifecycleDispatcher handler in zigbee_contact

It seems that something is not working correctly

11

Hi @nayelyz

This behavior must be linked to a problem that is happening when a driver change is made.

  • Until now, when a driver change was made, the lifecycles were executed and in this order:
    -init
    -added
    -driverSwitched

  • Now I am seeing that in some cases they only execute lifecycles added and driverSwitched and this causes drivers that need to execute a code in this init lifecycle, when a driver change is made sometimes the device does not work correctly.

To try to understand what is happening I have created an identical copy of the Zigbee Light Multifunction Mc driver called Zigbee Light Multifunction Mc-COPY

  • the Provisioning State PROVISIONED in the device in the original Zigbee Light Multifunction Mc driver
  • I make a driver change to the Zigbee Light Multifunction Mc-COPY driver
    • “nil provisioning state” is detected on the device and the lifecycles are executed: init, doConfigure, added and driverSwitched.
    • Provisioning State PROVISIONED is in the new driver
    • The device works correctly.
2023-08-13T13:09:20.608542733+00:00 TRACE Zigbee Light Multifunction Mc-COPY  Zigbee Device: 84944c69-fa8e-417e-bb62-92b7d5087d63
Manufacturer: OSRAM Model: Classic A60 W clear - LIGHTIFY
        [3]: server: TouchlinkCommissioning, Basic, Identify, Groups, Scenes, OnOff, Level, 0xFC0F | client: OTAUpgrade
2023-08-13T13:09:20.610144534+00:00 TRACE Zigbee Light Multifunction Mc-COPY  Received event with handler _resync
2023-08-13T13:09:20.611598260+00:00 TRACE Zigbee Light Multifunction Mc-COPY  Received event with handler environment_info
2023-08-13T13:09:20.612939931+00:00 DEBUG Zigbee Light Multifunction Mc-COPY  Z-Wave hub node ID environment changed.
2023-08-13T13:09:20.614278600+00:00 DEBUG Zigbee Light Multifunction Mc-COPY  driver device thread event handled
2023-08-13T13:09:20.625768342+00:00 TRACE Zigbee Light Multifunction Mc-COPY  Received event with handler environment_info
2023-08-13T13:09:20.635287099+00:00 INFO Zigbee Light Multifunction Mc-COPY  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> generating doConfigure event for nil provisioning state
2023-08-13T13:09:20.645007957+00:00 TRACE Zigbee Light Multifunction Mc-COPY  Found DeviceLifecycleDispatcher handler in zigbee_light_multifunctions
2023-08-13T13:09:20.646496034+00:00 PRINT Zigbee Light Multifunction Mc-COPY  <<<<< Device Init >>>>>>
.
.
2023-08-13T13:09:20.836437290+00:00 TRACE Zigbee Light Multifunction Mc-COPY  Received event with handler device_lifecycle
2023-08-13T13:09:20.837835656+00:00 INFO Zigbee Light Multifunction Mc-COPY  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> received lifecycle event: added
2023-08-13T13:09:20.886865158+00:00 TRACE Zigbee Light Multifunction Mc-COPY  Found DeviceLifecycleDispatcher handler in zigbee_light_multifunctions
.
.
2023-08-13T13:09:21.252272771+00:00 DEBUG Zigbee Light Multifunction Mc-COPY  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> doConfigure callback did not fail, transitioning device to "PROVISIONED"
2023-08-13T13:09:21.253581758+00:00 TRACE Zigbee Light Multifunction Mc-COPY  Received event with handler device_lifecycle
2023-08-13T13:09:21.265241919+00:00 INFO Zigbee Light Multifunction Mc-COPY  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> received lifecycle event: driverSwitched
2023-08-13T13:09:21.304740992+00:00 TRACE Zigbee Light Multifunction Mc-COPY  Found DeviceLifecycleDispatcher handler in zigbee_light_multifunctions

driver switched
driver switched1017×1636 79.6 KB

  • I change the driver to the original Zigbee Light Multifunction Mc driver
    • “nil provisioning state” is not detected on the device and only the lifecycles: added and driverSwitched are executed.
    • Provisioning State DRIVER_SWITCH is in the driver
    • The device does NOT work correctly since it did not perform the lifecycle init.
2023-08-13T13:15:16.116533424+00:00 TRACE Zigbee Light Multifunction Mc  Zigbee Device: 84944c69-fa8e-417e-bb62-92b7d5087d63
Manufacturer: OSRAM Model: Classic A60 W clear - LIGHTIFY
        [3]: server: TouchlinkCommissioning, Basic, Identify, Groups, Scenes, OnOff, Level, 0xFC0F | client: OTAUpgrade
2023-08-13T13:15:16.117673757+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> received lifecycle event: added
2023-08-13T13:15:16.126451424+00:00 TRACE Zigbee Light Multifunction Mc  Received event with handler device_lifecycle
2023-08-13T13:15:16.127391757+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 84944c69-fa8e-417e-bb62-92b7d5087d63 [0xC0CD] (Luz Mesita)> received lifecycle event: driverSwitched
2023-08-13T13:15:16.237164757+00:00 TRACE Zigbee Light Multifunction Mc  Found DeviceLifecycleDispatcher handler in zigbee_light_multifunctions
2023-08-13T13:15:16.238275757+00:00 PRINT Zigbee Light Multifunction Mc  Remove Groups >>>>>>>>>>>>>>>>>

driver switched-1
driver switched-11028×1636 80.2 KB

  • I make a new driver change to the Zigbee Light Multifunction Mc-COPY driver

    • “nil provisioning state” is detected on the device and the lifecycles are executed: init, doConfigure, added and driverSwitched.
    • Provisioning State PROVISIONED is in the new driver
    • The device works correctly.

  • I return to the original Zigbee Light Multifunction Mc driver

    • “nil provisioning state” is not detected on the device and only the lifecycles: added and driverSwitched are executed.
    • Provisioning State DRIVER_SWITCH is in the driver
    • The device does NOT work correctly since it did not perform the lifecycle init.

The only way to get the device working fine again with its original driver is to reinstall the driver with the CLI and then run the init lifecycle.

I have already seen users who may have been having problems with this behavior.

Should the init life cycle always be executed as before or are we going to have to call it directly when it is necessary for it to be executed for the proper functioning of the device?

This is crazy!!!

1 Like
12

Hi @nayelyz

I’ll tell you how this issue is going after the beta 49.8 firmware update, in case they have told you something about the smartthings team that can clarify this.

“generating doConfigure event for nil provisioning state” message is no longer seen either when performing a driver change or when installing a new driver version with the CLI. This is good!!

Then it no longer performs doConfigure of all driver devices when the driver version is updated. Good!!!

When you change to another driver the Provisioning State is DRIVER_SWITCH and it stays that way even if you install a new version of the driver with the CLI. Before the Provisioning State = PROVISIONED

What hasn’t changed and it’s important to know if it’s going to be like before or if it’s not going to stay that way:

When you change the driver, the lifecycle added and driverSwitched are executed and init is NOT triggered.

It’s important for devices that come from another driver and need to run some code in the lifecycle init and the developers don’t make a call to the code in the driver because we assumed that init was going to run by default.

I keep seeing in the documentation: : (The link to the highlighted text does not work well for me, I link the entire chapter)

  • There is also some default behavior that will always happen for certain events. added will also trigger an init after it has completed the added behavior.

  • There are 2 main cases where this happens: 1) the driver just started up and needs to create the objects for existing devices and 2) a device was newly added to the driver.

Thanks

1 Like
13

Hi @nayelyz

Is there anything new about this change, which has rendered the driver change process unusable for some devices? Leaving them partially or totally inoperative by not executing the init lifecycle. Also in stock drivers.

Does firmware update 49.8, which starts today, keep it that way?

14

Hi @nayelyz

I don’t know if they have answered something from the team, but in the last tests that I have done a while ago it seems that it is working again as before, the init life cycle is executed when a driver switch is made

1 Like
15

Hi, @Mariano_Colmenarejo
Sorry for the delay, we were waiting for their feedback, but it’s good to know it is working correctly now.

16

Hi @nayelyz
The only thing different I’ve noticed is that lifecycles are now normally executed in this order: added, driverSwitched, init

I believe that before these changes the order was: init, added, driverSwitched

The only time I’ve seen the init lifecycle run first is when the driver doesn’t have any paired devices and the one you’re going to pair with the driver is the first one.
In this case the order is: init, added, driverSwitched

Shouldn’t it always be like this?
Isn’t it more logical like that? In this way, when you write the driver, you put in each life cycle the code that you think should always be executed in the same order, not sometimes in one order and sometimes in another.

17

Hi @Mariano_Colmenarejo I case see the same as you, yes that is true please let me check it with the team

to give more context for the team to understand better the case, please Can you share how it affects you to use it as a reference?

18

Here is an example of the stock “zwave-switch” driver and “zwave-dual-switch/init.lua” subdriver

It has the init and added lifecycles defined

lifecycle_handlers = {
    added = device_added,
    init = device_init
  },

When the device is installed the driver first executes the device_init function which is called with the init lifecycle:

  • In this function the mappings of the endpoints and components of the profile are done and the function that returns that assignment is registered.

Then the device_added function is executed, which is called with the added life cycle:

  • In this function the child device of the enpoint2 asigned to second component is created

When the device from the other driver is installed, zigbee Thing for example, added is executed first:

  • The child device is created for the component assigned to endpoint2

Then device_init function is called:

  • in this function the mappings of the endpoints and components of the profile are done and the function that returns that assignment is registered

In this case it doesn’t seem like it can be conflictive, I think, but surely there are drivers that could will be.

Wouldn’t it be more logical that it should always be done in the same order, as it was done before, so that clumsy people like me don’t screw up?

On the other hand, another case that occurs when a driver change is made.
in many drivers, the init life cycle performs a function that adds or removes the configuration and monitoring attributes, so that when the doConfigure life cycle is called, it is configured with specific values of temperature reports, battery, …

local function device_init(driver, device)
  local configuration = configurationMap.get_device_configuration(device)
  if configuration ~= nil then
    for _, attribute in ipairs(configuration) do
      device:add_configured_attribute(attribute)
      device:add_monitored_attribute(attribute)
    end
  end
end

This works well for devices that are installed directly with the driver.

But when the device is installed from a Change driver, then the doConfigure lifecycle is never called and the device may be left without setting the attributes correctly and not work properly or be marked offline because it does not send the periodic reports.

This can happen when the device mismatches a driver with the generic cluster fingerprints and then makes a change to the correct driver.

For example in the zigbee-vent driver, at the request of a user whose fans were paired with zigbee thing, you have added generic fingerprints so that different models can be paired without having to add them specifically.
If this user changes the driver from the zigbee thing to the new zigbee Vent, it will not perform the configuration, because the doConfigure life cycle is not called and it will not work correctly and will be offline

In groovy, when you changed DTH, the device configuration was done, wouldn’t it be convenient for it to be done as well, at least for zigbee devices?

19

It would be nice to have the official flow of handlers called when a driver it initialized, devices added and when a driver is switched.

20

Drivers should call the same code for doConfigure and changeDriver. I do this in several ways. For example, in Zwave devices:

--- @param self st.zwave.Driver
--- @param device st.zwave.Device
local function driver_switched(self, device, event, args)
  -- Call the default handler 
  Driver.default_capability_match_driverSwitched_handler(self, device, event, args)

  if not device:is_cc_supported(cc.WAKE_UP) then
    -- We're not a sleepy device, so run a doConfigure lifecycle event to configure the device now.
    device.thread:queue_event(self.lifecycle_dispatcher.dispatch, self.lifecycle_dispatcher, self, device, "doConfigure")
  else
    device.log.info("Device is sleepy.  Will configure on next wakeup.")
  end
end
1 Like