Yeah, some images from Philips Hue are marked as “invalid” by zigpy. (The images don’t follow any spec really). (Mostly the case with end devices: remotes, sensors, …) One of the devs was already talking about how there could be a special case or just some validation stripped out or something. At the moment, you could try updating it with deCONZ or zigbee2mqtt (or just use the Hue Bridge if you have one).
1 Like
Probably better would be to buy Conbee2 instead of Hue Bridge for one sensor.
I’m using IKEA white bulbs and Sonoff SNZB’s
My gate is Sonoff ZBBridge programmed to newest Tasmota - works great, BTW.
Thank you for sharing. This worked for my LWB014 Bulbs. The instructions are great.
Doesn’t work for my RWL020 Hue dimmer switch, but as you indicated, this is because the format of the OTA file isn’t currently handled by zigpy.
Edit: Looks like updating RWL020 will be possible soon once zigpy incorporates this merge request: https://github.com/zigpy/zigpy/pull/597
Edit 2: I manually merged the changes and now my RWL020 was successfully upgraded OTA!
2 Likes
@juched OT, but on a Blueprint thread (ZHA - Philips Hue Dimmer Switch (individual buttons with long presses)) for the Hue Dimmer, I am in a bit of a confusing situation you may have better insight on. The author has a zha_event for the dimmer that has long-release/hold functionality. My “new” Hue remote does, too. My three old ones do not and have a simpler structure (on, off_with_effect, step). The firmware shows 0x420045b6 on ALL four remotes – even though they have different zha_event structures. Device model numbers are all the same, too.
When you’ve upgraded your remotes recently, have you taken a look at the zha_event data for button presses? Trying to sort out if older firmware on these is actually more featureful or not.
The “new events” come from a ZHA quirk.
Please open an issue on zha-device-handlers (zha-quirks repo) and post both signatures (old and new ones from the dimmer switches).
Interesting! So based on that I went ahead and performed a Zigbee Remove and then used the remote setup button to add it again. Now at least my first “old” remote is showing the extra button meta data. So seems that because my devices had been paired prior to some quirks update, it never leveraged the new functionality? Will try my last two remotes, but this seems very promising. Thanks, @TheJulianJES!
It should do it fine without requiring a re-pair. Can you post the signatures of the dimmer switch here maybe?
I actually looked at my new remote vs. my three existing remotes and the Zigbee signature details were 1-for-1 the same content. I’ve now successfully removed and re-setup all three remotes and they each work as desired with the complete meta data I was missing prior. I’ve probably had this HA setup for 2.5-3 years now and those remotes have always existed, so a little unsure what else to narrow down since they work after a re-add perfectly.
Here’s a signature, though:
{
"node_descriptor": "NodeDescriptor(byte1=2, byte2=64, mac_capability_flags=128, manufacturer_code=4107, maximum_buffer_size=71, maximum_incoming_transfer_size=45, server_mask=0, maximum_outgoing_transfer_size=45, descriptor_capability_field=0)",
"endpoints": {
"1": {
"profile_id": 49246,
"device_type": "0x0830",
"in_clusters": [
"0x0000"
],
"out_clusters": [
"0x0000",
"0x0003",
"0x0004",
"0x0005",
"0x0006",
"0x0008"
]
},
"2": {
"profile_id": 260,
"device_type": "0x000c",
"in_clusters": [
"0x0000",
"0x0001",
"0x0003",
"0x000f",
"0xfc00"
],
"out_clusters": [
"0x0019"
]
}
},
"manufacturer": "Philips",
"model": "RWL020",
"class": "zhaquirks.philips.rwl021.PhilipsRWL021"
}
Thanks. It seems ok. Since each quirk matches at startup (and doesn’t save to which device it belongs to), it checks each signature every start and normally that shouldn’t require re-pairing. Good that it works now at least.
You, sir, are a badass.
Should look like this (note indentation) e.g.
service: zha.issue_zigbee_cluster_command
data:
ieee: 'xx:xx:xx:xx:xx:xx:xx:xx'
endpoint_id: 11
cluster_id: 25
cluster_type: out
command: 0
command_type: client
args:
- 0
- 100
Just upgraded my pair of Philips Hue Play Light Bar LCT024. Got the image from above github link.
One identified as: Philips LCT024 Play Light Bar - this seems to want image type 273
The second one identified as: Philips 440400982841 
which seems to want image type 270
Not all Hues are made equally, it would seem.
@Adminiuga - can confirm this update procedure works for the Philips Hue stuff - at least for what I own. Perhaps the above command can be triggered occasionally for Philips Hue lamps detected in ZHA HA installs, if Philips Hue (4107 = 0x100B) images are detected in the OTA folder.
4 Likes
I issue the command
service: zha.issue_zigbee_cluster_command
data:
ieee: ‘xx:xx:xx:xx:xx:xx:xx:xx’
endpoint_id: 11
cluster_id: 25
cluster_type: out
command: 0
command_type: client
args:
- 0
- 100
and I get this error
2021-04-18 08:58:57 ERROR (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Error executing script. Unexpected error for call_service at pos 1: 11
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 359, in _async_step
await getattr(self, handler)()
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 559, in _async_call_service_step
await service_task
File "/usr/src/homeassistant/homeassistant/core.py", line 1480, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1515, in _execute_service
await handler.job.target(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 719, in admin_handler
await result
File "/usr/src/homeassistant/homeassistant/components/zha/api.py", line 1002, in issue_zigbee_cluster_command
response = await zha_device.issue_cluster_command(
File "/usr/src/homeassistant/homeassistant/components/zha/core/device.py", line 593, in issue_cluster_command
cluster = self.async_get_cluster(endpoint_id, cluster_id, cluster_type)
File "/usr/src/homeassistant/homeassistant/components/zha/core/device.py", line 519, in async_get_cluster
return clusters[endpoint_id][cluster_type][cluster_id]
KeyError: 11
2021-04-18 08:58:57 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [281472532831680] Error handling message: Unknown error
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py", line 18, in _handle_async_response
await func(hass, connection, msg)
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 439, in handle_execute_script
await script_obj.async_run(context=context)
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 1200, in async_run
await asyncio.shield(run.async_run())
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 341, in async_run
await self._async_step(log_exceptions=False)
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 359, in _async_step
await getattr(self, handler)()
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 559, in _async_call_service_step
await service_task
File "/usr/src/homeassistant/homeassistant/core.py", line 1480, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1515, in _execute_service
await handler.job.target(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 719, in admin_handler
await result
File "/usr/src/homeassistant/homeassistant/components/zha/api.py", line 1002, in issue_zigbee_cluster_command
response = await zha_device.issue_cluster_command(
File "/usr/src/homeassistant/homeassistant/components/zha/core/device.py", line 593, in issue_cluster_command
cluster = self.async_get_cluster(endpoint_id, cluster_id, cluster_type)
File "/usr/src/homeassistant/homeassistant/components/zha/core/device.py", line 519, in async_get_cluster
return clusters[endpoint_id][cluster_type][cluster_id]
KeyError: 11
probably missing step…
I ran a diff between mine and @mstanislav’s mine says:
“class”: “zhaquirks.philips.rwlfirstgen.PhilipsRWLFirstGen”
and I don’t have the following in my node_descriptor.
, *allocate_address=True, *complex_descriptor_available=False, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False, *is_valid=True, *logical_type=<LogicalType.EndDevice: 2>, *user_descriptor_available=False)",
and I do have the ota dir… I downloaded the files
➜ ~ cd /config/zha_ota
➜ zha_ota ls -la -d "$PWD/"*
-rw-r--r-- 1 root root 256632 Jan 20 2020 /config/zha_ota/ModuLum-ATmega_010B_5.130.1.30000_0012.sbl-ota
-rw-r--r-- 1 root root 69694 Apr 16 23:13 /config/zha_ota/index.json
and conf of course
➜ zha_ota tail -5 /config/configuration.yaml
zigpy_config:
ota:
ikea_provider: true
ledvance_provider: true
otau_directory: /config/zha_ota
not sure what i’m missing
For the Hue dimmer, change endpoint_id from 11 to 2.
"class”: “zhaquirks.philips.rwlfirstgen.PhilipsRWLFirstGen” is just the new quirk name.
@TheJulianJES I was hitting the same error with my remote as @kdzoha so I tried changing the endpoint to 2 as you suggested. Calling the service no longer errors but I am also not seeing anything in my logs related to the OTA even though I have this in my configuration.yaml:
logger:
default: info
logs:
zigpy.ota: debug
Any idea what I might be missing?
Sorry for the late reply, I somehow missed this.
If you still have the issue, try the following:
- Make sure all debug logging related to Home Assistant is on: Zigbee Home Automation - Home Assistant
- Immediately after executing the service, press a button on the dimmer, so that it can wake up from sleep.
Hi @systemcrash,
I have a play bar that has been acting odd in ZHA for a while now… Its my only Hue device…No colour control, and it doesnt report on/off status back most of the time. Tried repairing, removing other devices from my zigbee mesh, now wondering if a firmware upgrade will help.
Could you outline all steps required to do this? I can see I have the one that reports model 440400982841 in its device signature.
Not sure what files I need top download etc… is it just the index.json?
Thanks!!
Hello Everybody!
Could anybody help me on Hue update processes?
I tried to update my LTC002 lamp, and RLW021 switch but without success. I set up all debug options, I used endpoint_id: 11 for the lamp and 2 for the switch but I always get…
…error immediately after I call the message.
Details of the error:
2022-04-24 11:32:46 DEBUG (MainThread) [zigpy_znp.api] Received command: AF.IncomingMsg.Callback(GroupId=0x0000, ClusterId=25, SrcAddr=0x06D2, SrcEndpoint=11, DstEndpoint=1, WasBroadcast=<Bool.false: 0>, LQI=51, SecurityUse=<Bool.false: 0>, TimeStamp=3563494, TSN=0, Data=b'\x01\x24\x03\x02\x0B\x10\x0E\x01\x00\x1F\x00\x01\x00\x00\x00\x00\x40\x00\x00', MacSrcAddr=0x06D2, MsgResultRadius=29)
2022-04-24 11:32:46 DEBUG (MainThread) [zigpy.zcl] [0x06D2:11:0x0019] Received ZCL frame: b'\x01\x24\x03\x02\x0B\x10\x0E\x01\x00\x1F\x00\x01\x00\x00\x00\x00\x40\x00\x00'
2022-04-24 11:32:46 DEBUG (MainThread) [zigpy.zcl] [0x06D2:11:0x0019] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=0, is_reply=0, disable_default_response=0, reserved=0, *is_cluster=True, *is_general=False), tsn=36, command_id=3, *is_reply=False)
2022-04-24 11:32:46 ERROR (MainThread) [zigpy.device] Failed to parse message (b'012403020b100e01001f000100000000400000') on cluster 25, because Data is too short to contain 1 bytes
Any clue on it?
Will be fixed once Implement OTA frame control fields by puddly · Pull Request #961 · zigpy/zigpy · GitHub makes it into Home Assistant.
2 Likes
Ahhh, so the update process does not totally work yet?! Sorry I did not get it. No problem, in this case I will wait for it, or try the zigpy:dev, or the PR.
Lot of thanks for your fast response!
One another question to clarify the background…
I thought we have to download the corresponding OTA firmware files onto the configured OTA dir, but @kdzoha some comments above ‘mentioned’ the index.json dropped into OTA folder. It is possible to use just the JSON (containing OTA paths) without the directly downloaded OTA files?
@TheJulianJES I can confirm that the current dev version of zigpy is working fine from the OTA firmware upgrade aspect, but I have a question for you as the most expert in this topic.
As the subject somewhat new for me I had to take some experiences before I understand what happens. Yesterday I tried to call the upgrade command for my LTC002 lamp and also my RLW021 switch. Later in the logs I did not/could not catch the upgrade process of the switch but I clearly saw the upgrade of the lamp. The FW upload was really slow, but was not problem with it. Interestingly at the end I did not see/get upgraded software revision (check through the cluster). As zigpy documentation tells that sometimes we have to reset the device, remove from the controller, and re-join. I walked through this path but at the end I still got the old SW version number.
Today I thought, I would try it again, let see what happens:
- Firstly I realized that the switch had be succesfully upgraded. The original version was 5.45.1.17846 but today I see 6.1.1.28573. Something happend. Something good, what I expected. I did not catch its upgrade process, but seems it had been succesfully finisehed. It’s clearly OK!
- Seconly I still saw that the lamp’s FW still the old, so tried to initiate an upgrade again, and got the following in the corresponding log:
2022-04-25 09:39:19 DEBUG (MainThread) [homeassistant.components.zha.api] Issued command for: cluster_id: [25] cluster_type: [out] endpoint_id: [11] command: [0] command_type: [client] args: [0, 100] manufacturer: [None] response: None
2022-04-25 09:39:19 DEBUG (MainThread) [zigpy_znp.api] Received command: AF.IncomingMsg.Callback(GroupId=0x0000, ClusterId=25, SrcAddr=0x20A6, SrcEndpoint=11, DstEndpoint=1, WasBroadcast=<Bool.false: 0>, LQI=40, SecurityUse=<Bool.false: 0>, TimeStamp=13847471, TSN=0, Data=b'\x01\x00\x01\x00\x0B\x10\x0E\x01\x00\x07\x00\x01', MacSrcAddr=0x20A6, MsgResultRadius=29)
2022-04-25 09:39:19 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Received ZCL frame: b'\x01\x00\x01\x00\x0B\x10\x0E\x01\x00\x07\x00\x01'
2022-04-25 09:39:19 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=0, is_reply=0, disable_default_response=0, reserved=0, *is_cluster=True, *is_general=False), tsn=0, command_id=1, *is_reply=False)
2022-04-25 09:39:19 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Decoded ZCL frame: Ota:query_next_image(field_control=<FieldControl.0: 0>, manufacturer_code=4107, image_type=270, current_file_version=16779008)
2022-04-25 09:39:19 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Received command 0x01 (TSN 0): query_next_image(field_control=<FieldControl.0: 0>, manufacturer_code=4107, image_type=270, current_file_version=16779008)
2022-04-25 09:39:19 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] OTA query_next_image handler for 'Philips LTC002': field_control=FieldControl.0, manufacture_id=4107, image_type=270, current_file_version=16779008, hardware_version=None, model=LTC002
2022-04-25 09:39:19 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] OTA image version: 16785152, size: 271114. Update needed: True
2022-04-25 09:39:19 INFO (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Updating: Philips LTC002
2022-04-25 09:39:19 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Sending reply header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=False, is_reply=1, disable_default_response=1, reserved=0, *is_cluster=True, *is_general=False), tsn=0, command_id=2, *is_reply=True)
2022-04-25 09:39:19 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Sending reply: query_next_image_response(status=<Status.SUCCESS: 0>, manufacturer_code=4107, image_type=270, file_version=16785152, image_size=271114)
2022-04-25 09:39:25 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Received ZCL frame: b'\x01\x01\x03\x02\x0B\x10\x0E\x01\x00\x1F\x00\x01\x00\x00\x00\x00\x40\x00\x00'
2022-04-25 09:39:25 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=0, is_reply=0, disable_default_response=0, reserved=0, *is_cluster=True, *is_general=False), tsn=1, command_id=3, *is_reply=False)
2022-04-25 09:39:25 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Decoded ZCL frame: Ota:image_block(field_control=<FieldControl.MinimumBlockPeriod: 2>, manufacturer_code=4107, image_type=270, file_version=16785152, file_offset=0, maximum_data_size=64, minimum_block_period=0)
2022-04-25 09:39:25 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Received command 0x03 (TSN 1): image_block(field_control=<FieldControl.MinimumBlockPeriod: 2>, manufacturer_code=4107, image_type=270, file_version=16785152, file_offset=0, maximum_data_size=64, minimum_block_period=0)
2022-04-25 09:39:25 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] OTA image_block handler for 'Philips LTC002': field_control=FieldControl.MinimumBlockPeriod, manufacturer_id=4107, image_type=270, file_version=16785152, file_offset=0, max_data_size=64, request_node_addr=Noneblock_request_delay=0
2022-04-25 09:39:25 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] OTA upgrade progress: 0.0
2022-04-25 09:39:25 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Sending reply header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=False, is_reply=1, disable_default_response=1, reserved=0, *is_cluster=True, *is_general=False), tsn=1, command_id=5, *is_reply=True)
2022-04-25 09:39:25 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Sending reply: image_block_response(status=<Status.SUCCESS: 0>, manufacturer_code=4107, image_type=270, file_version=16785152, file_offset=0, image_data=b'\x1e\xf1\xee\x0b\x00\x018\x00\x00\x00\x0b\x10\x0e\x01\x00\x1f\x00\x01\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
...
2022-04-25 09:39:25 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Received ZCL frame: b'\x01\x05\x03\x02\x0B\x10\x0E\x01\x00\x1F\x00\x01\x88\x00\x00\x00\x40\x00\x00'
2022-04-25 09:39:25 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=0, is_reply=0, disable_default_response=0, reserved=0, *is_cluster=True, *is_general=False), tsn=5, command_id=3, *is_reply=False)
2022-04-25 09:39:25 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Decoded ZCL frame: Ota:image_block(field_control=<FieldControl.MinimumBlockPeriod: 2>, manufacturer_code=4107, image_type=270, file_version=16785152, file_offset=136, maximum_data_size=64, minimum_block_period=0)
2022-04-25 09:39:25 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Received command 0x03 (TSN 5): image_block(field_control=<FieldControl.MinimumBlockPeriod: 2>, manufacturer_code=4107, image_type=270, file_version=16785152, file_offset=136, maximum_data_size=64, minimum_block_period=0)
2022-04-25 09:39:25 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] OTA image_block handler for 'Philips LTC002': field_control=FieldControl.MinimumBlockPeriod, manufacturer_id=4107, image_type=270, file_version=16785152, file_offset=136, max_data_size=64, request_node_addr=Noneblock_request_delay=0
2022-04-25 09:39:25 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] OTA upgrade progress: 0.1
2022-04-25 09:39:25 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Sending reply header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=False, is_reply=1, disable_default_response=1, reserved=0, *is_cluster=True, *is_general=False), tsn=5, command_id=5, *is_reply=True)
2022-04-25 09:39:25 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Sending reply: image_block_response(status=<Status.SUCCESS: 0>, manufacturer_code=4107, image_type=270, file_version=16785152, file_offset=136, image_data=b'7\x82"\xb3\xc1s\xfeT\xc3\x1c\x98\x14\xaf\x06\x06\xf9\xdb2c35QE\x89b\xaf\xebE\x96NZ\x87\xc431\x03\x13\xd6kl')
...
2022-04-25 09:46:04 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] OTA image_block handler for 'Philips LTC002': field_control=FieldControl.MinimumBlockPeriod, manufacturer_id=4107, image_type=270, file_version=16785152, file_offset=270724, max_data_size=64, request_node_addr=Noneblock_request_delay=0
2022-04-25 09:46:04 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] OTA upgrade progress: 99.9
2022-04-25 09:46:04 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Sending reply header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=False, is_reply=1, disable_default_response=1, reserved=0, *is_cluster=True, *is_general=False), tsn=219, command_id=5, *is_reply=True)
2022-04-25 09:46:04 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Sending reply: image_block_response(status=<Status.SUCCESS: 0>, manufacturer_code=4107, image_type=270, file_version=16785152, file_offset=270724, image_data=b' \xf1\x80\x01\x00\x00*\x00\x01\x0e\x00n\xa9!\x05 \x17\x13X\x00\x01@\x96\xa4\x938\xf8~\x86\x9e\x1a \xe9}\xfc5\x03\xa1\x0b\xdd')
2022-04-25 09:46:04 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Received ZCL frame: b'\x01\xDC\x06\x00\x0B\x10\x0E\x01\x00\x1F\x00\x01'
2022-04-25 09:46:04 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=0, is_reply=0, disable_default_response=0, reserved=0, *is_cluster=True, *is_general=False), tsn=220, command_id=6, *is_reply=False)
2022-04-25 09:46:04 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Decoded ZCL frame: Ota:upgrade_end(status=<Status.SUCCESS: 0>, manufacturer_code=4107, image_type=270, file_version=16785152)
2022-04-25 09:46:04 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Received command 0x06 (TSN 220): upgrade_end(status=<Status.SUCCESS: 0>, manufacturer_code=4107, image_type=270, file_version=16785152)
2022-04-25 09:46:04 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] OTA upgrade_end handler for 'Philips LTC002': status=Status.SUCCESS, manufacturer_id=4107, image_type=270, file_version=16785152
2022-04-25 09:46:04 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Sending reply header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=False, is_reply=1, disable_default_response=1, reserved=0, *is_cluster=True, *is_general=False), tsn=220, command_id=7, *is_reply=True)
2022-04-25 09:46:04 DEBUG (MainThread) [zigpy.zcl] [0x20A6:11:0x0019] Sending reply: upgrade_end_response(manufacturer_code=4107, image_type=270, file_version=16785152, current_time=0, upgrade_time=0)
From the logs for me it seems that had went everything fine, as it wrote: OTA upgrade_end handler for 'Philips LTC002': status=Status.SUCCESS, manufacturer_id=4107, image_type=270, file_version=16785152, but at the end, at the point immediately after the upgrade, but also after a device reset and also re-added to my Zigbee network I simply did not get fresh SW revision.
The upgrade process told that the update file what was used to the process was the file_version=16785152. What is interesting for me that at HA boot sequence/initialization I get not just one but 3 OTA update file with this ID:
2022-04-25 10:46:46 DEBUG (SyncWorker_4) [zigpy.ota.provider] ImageKey(manufacturer_id=4107, image_type=286): /config/zha_ota/100B-011E-01001F00-ConfLight-PortableV2-EFR32MG13.zigbee, version: 16785152, hw_ver: (None, None), OTA string:
...
2022-04-25 10:46:46 DEBUG (SyncWorker_5) [zigpy.ota.provider] ImageKey(manufacturer_id=4107, image_type=270): /config/zha_ota/100B-010E-01001F00-ConfLight-ModuLum_0012.zigbee, version: 16785152, hw_ver: (None, None), OTA string:
...
2022-04-25 10:46:46 DEBUG (SyncWorker_13) [zigpy.ota.provider] ImageKey(manufacturer_id=4107, image_type=285): /config/zha_ota/100B-011D-01001F00-ConfLight-ModuLumV2-EFR32MG13.zigbee, version: 16785152, hw_ver: (None, None), OTA string:
The image type is clearly differentiated but the file reference is the same. The upgrade referred to the tpye 270, so maybe the process went really fine with this type, but the bacground is a little bit interesting for me.
I shot these for you just because in theory I just want to upgrade the lamp (the switch was indifferent), as it seems I can not define yet its ‘power-on-behaviour’ and I thought it’s because the old firmware (as I know earlier HUE devices had not this config possibility).
My current SW revision is: 1.16.1_r19181, what is really an old one (there is a revision history at Philips: Lamps | Philips Hue).
Sadly now I have an upgraded switch, what is very nice, but with the same old lamp, what is not so nice, especially if I get an unexpected ‘sun-beam’ in midnight just because a short power outage.
Could you please help on it? If there are any specialities - for my case - after the success I would love to send the required/corresponding steps to the HA documentation as PR to help the others.
Lot of thanks for your possibly efforts in advance!
UPDATE:
Just for the report:
Finally I could successfully upgrade my old (2019) ‘Hue - Fair’ ceiling lamp firmware from the original 1.16.1_r19181 (20160907) to 1.88.1 (20210331) in 2 step ( > 01001904 > 01001F00 ) with Home Assistant/‘zigpy’ through ‘SONOFF - Zigbee 3.0 USB Dongle Plus’.
I really don’t know what was the problem, but (Check the CONCLUSION below) I delete (almost) all of my OTA files, used only the 2 real relevant (firmware type: 270 (0x010e)), but just one after another. After it - in 2 step - I got successfully upgraded - very latest - FW.
The device is an old ‘Hue - Fair’ (40340/30/P7) without BT. The device ID: LTC002
(Small comment: I didn’t have to restart and re-pair the device. I saw the upgraded FW immediately after the upgrade process.)
Now I have configurable ‘power-on-behaviour’ what was the original goal, and what function seems to working fine. Now I do not need to wake up in the midnight after an unexpected power outage 
Thanks to all of you for your help in this thread!
CONCLUSION:
(Just to keep a summary to any new users.)
As @TheJulianJES mentioned it in the following reply, the problem was the on step big jump from a very olda FW to the newest. If OTA file folder contains multiple relevant FW to our device, the upgrade process will automatically catch the LATEST and try to flash it, what sadly in some cases could lead to unsucesful result. In some circumstences there could be some limitation about the possible upgrade steps. Not all FWs could be upgraded to any newer, just to some of them, maybe to just the following next version. In this case we have to upgrade our devices step-by-step, in multiple upgrade cycles.