I tried to confirm that by inspecting the source code but my first attempt failed to even find the OTA option. I’ll try again later, when I have more time.
As far as I know, you tell it to check with the following command:
You may need to put the OTA in debug though to see if it does anything:
logger:
default: info
logs:
zigpy.ota: debug
2 Likes
Thank you very much, I’ll test it and report back if it works!
I too would like to know if anybody figures this out. Trying to update my Hue bulbs’ firmware with just Hassio+ZHA with no hub, so a solution here would be helpful.
If I figure it out, I’ll be sure to post back as well.
@ardaedhel That’s easy.
Just download all the files from Philips from here: https://github.com/Koenkk/zigbee-OTA/blob/a02a4cb33f7c46b4d2916805bfcad582124ec975/index.json
Edit: More up-to-date images: https://github.com/Koenkk/zigbee-OTA/blob/master/index.json
Create an zha_ota folder in /config on your Hass. Drop all files in there.
Then follow this, but uncomment (remove the #) otau_directory.
otau_directory should then point to /config/zha_ota.
The config.yaml part should look like this then:
zha:
zigpy_config:
ota:
ikea_provider: true
ledvance_provider: true
otau_directory: /config/zha_ota
(the IKEA and LEDVANCE updates are optional)
Note: Philips Hue Dimmer cannot be upgraded like this yet (the OTA file from Philips doesn’t follow any standards.)
Edit: Thanks to puddly, the Hue Dimmer can now also be upgraded if you have that image.
After some time, some Philips Hue bulbs will request an OTA upgrade, but most don’t.
Use the zha.issue_zigbee_cluster_command service with the following args:
ieee: 00:00:00:00:00:00:00:00
endpoint_id: 11
cluster_id: 0x0019
cluster_type: out
command: 0x0
command_type: client
args: [0, 100]
This will send image_notify to the bulb (the args are needed for some bulbs which is why it can’t be done through the Cluster UI of ZHA).
(Replace ieee with your Hue ieee you want to upgrade)
If you have https://www.home-assistant.io/integrations/zha/#debug-logging enabled, you will see some information in the logs about the upgrade.
After some time, the bulb should be upgraded, if it’s not already running the latest firmware.
11 Likes
Oh man, thank you @TheJulianJES , that’s a huge help! I’ll give it a shot later on.
Guess I misunderstood OP’s issue, so… sorry for the derail. 
No worries!
In the future this should also work for the Hue Dimmer if/when zigpy validations of the OTA images change (perhaps adding a special case for the Hue images).
Most Hue images do follow the standard though and at least for me, it works with all my types of bulbs.
Thank you for the detailed description @TheJulianJES! You should really add this to the ZHA documentation.
Do you know if any work is being done towards automating this process?
Kind of a script that checks the Hue devices firmware against any available OTA’s, and then issue the cluster commands for you?
1 Like
All the Zigbee OTA images on the zha_ota directory are already parsed on Home Assistant startup.
With Zigbee, the device needs to request an image and ZHA will look for the correct image to send (in the already parsed list of OTA images). If it finds one, then it will slowly send it to the device. If it doesn’t find one, it’ll simply send back a response that’s there no image.
As Philips Hue (Signify) doesn’t provide its OTA images directly (outside of the Hue Bridge), it’s quite problematic to fetch these images.
The zigbee-ota repo on GitHub (linked in the other post) already does a good job of collecting many OTA images for different devices. If you download all the images (from the “url”) "manufacturerCode": 4107, you will have all currently available images for Hue bulbs. (Important Note: Some Hue OTAs are directly on Philips’ servers while others are on Google’s servers)
The image_notify command basically tells the Zigbee device to ask the Coordinator (your Zigbee stick) to look for an update. Normally, this can be done through the GUI, but the Hue bulbs (and some other Zigbee devices) require these two additional arguments (which can only be provided by using the service call in the other post).
IKEA bulbs (and some Hue bulbs even) regularly ask for an OTA image, so at least for IKEA bulbs, the process is basically automated, as the ikea_provider always looks for the latest images (if IKEA doesn’t upload “corrupted” images again…)
2 Likes
It makes sense, and it is a shame that Hue does not publicly release Otas.
But until it does, I really think it makes sense to update the documentation with that part concerning making the service calls etc.
And even if a clever guy could automate the step of pulling the newest available hue firmwares and make the service call for you, that would be a great QoL improvement. Even if some of the Hue bulbs can ask for themselves, I assume it leaves out a lot.
1 Like
Can’t do it with Philips Hue SML002 Outdoor PIR
I’m receiving some weird errors from zigpy.ota.provider
File is downloaded to OTA folder
Firmware for SML002 is same that’s used for SML001
http://fds.dc1.philips.com/firmware/ZGB_100B_010D/1107323831/Sensor-ATmega_6.1.1.27575_0012.sbl-ota
BTW IKEA bulbs has been updated without problems, also from OTA folder.
Their servers provide bad responses for direct web update
2020-11-17 15:06:58 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x3E01](SML002): Issued cluster command: cluster_id: 25 command: 0 command_type: client args: (0, 100) cluster_id: out manufacturer: 4107 endpoint_id: 2
2020-11-17 15:06:58 DEBUG (MainThread) [homeassistant.components.zha.api] Issued command for: cluster_id: [25] cluster_type: [out] endpoint_id: [2] command: [0] command_type: [client] args: [0, 100] manufacturer: [4107] response: EmberStatus.SUCCESS
2020-11-17 15:06:58 DEBUG (MainThread) [zigpy.zdo] [0x3e01:zdo] ZDO request ZDOCmd.IEEE_addr_req: [0x0000, 0, 0]
2020-11-17 15:06:59 DEBUG (MainThread) [zigpy.zcl] [0x3e01:2:0x0019] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=74 command_id=1>
2020-11-17 15:06:59 DEBUG (MainThread) [zigpy.zcl] [0x3e01:2:0x0019] ZCL request 0x0001: [0, 4107, 269, 1107321517, None]
2020-11-17 15:06:59 DEBUG (MainThread) [zigpy.zcl] [0x3e01:2:0x0019] OTA query_next_image handler for 'Philips SML002': field_control=0, manufacture_id=4107, image_type=269, current_file_version=1107321517, hardware_version=None
2020-11-17 15:06:59 DEBUG (SyncWorker_5) [zigpy.ota.provider] Couldn't load '/config/ota/Sensor-ATmega_6.1.1.27575_0012.sbl-ota' OTA image
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/zigpy/ota/provider.py", line 335, in _fetch_image
img = OTAImage.deserialize(data[offset:])[0]
File "/usr/local/lib/python3.8/site-packages/zigpy/ota/image.py", line 158, in deserialize
element, element_data = SubElement.deserialize(element_data)
File "/usr/local/lib/python3.8/site-packages/zigpy/ota/image.py", line 131, in deserialize
raise ValueError("Data is too short for {}".format(cls.__name__))
ValueError: Data is too short for SubElement
2020-11-17 15:06:59 DEBUG (MainThread) [zigpy.zcl] [0x3e01:2:0x0019] No OTA image is available
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"
}