Add ThirdReality Smart Button v1.00.47

[3reality-support]

OTA image URL

https://s3.amazonaws.com/tr-ota-us-prod/3RSB22BZ_ZHA_047_20260512_061209.ota

Release notes

This updates the ThirdReality Smart Button (3RSB22BZ) to v1.00.47.

How to handle existing images of the same type

Keep all (standard)

Optional metadata

No response

Checklist

• The OTA image provided is in a supported format (e.g., .zigbee, .ota)
• The OTA image URL provided is from an official source (e.g., manufacturer's website, official repository)
• I have filled out the release notes to the best of my ability
• The OTA image is tested and verified to work on a physical device

Additional information

No response

[zigpy-bot]

✅ Successfully processed your OTA submission! A pull request has been created with your changes:

• Add ThirdReality Smart Button v1.00.47 #155

Last reprocessed: 2026-05-14 07:47 UTC

[3reality-support]

@TheJulianJES
Hello, I have a question. For some devices that have not submitted the OTA image in the new way. I noticed that OTA still shows up on ZHA. Why is that? Has ZHA currently been using the previous OTA method or is it still employing the previous method? In the future, gradually replace it with new methods?

[TheJulianJES]

@3reality-support Yes, currently both ways are still active. We're very happy that you submitted all your images here now, as it this new way has a lot of advantages. In the near future, we do plan to remove the old "providers" from zigpy, so only images submitted via zigpy-ota will show up then.

For HA Core 2026.5, images from both sources will show up. But the next version of HA (2026.6) may already change this.

[3reality-support]

@TheJulianJES
OK. May I ask if there is an alternative API method to submit the OTA image through the GitHub issue submission process, besides the web page operation? I want to implement automation to avoid the submission issues caused by errors when submitting frequently.

[TheJulianJES]

@3reality-support
Hmm... We were generally under the impression that submitting through the web page would avoid a ton of issues, as you don't have to: update forks, create branches, upload files, create PRs, manually write JSON for optional metadata, and so on.

Ideally, you should just need to either provide a direct link that will be used to download the file once, or upload (a zipped file) of the OTA file. Further, a nice title and good release notes are very much appreciated by users as well, as users often wonder what gets added in new updates – and the release notes are shown in Home Assistant (but are optional).

---

If we find any issues with OTA submissions, we can just fix them ourselves before merging, or contact you if there's something really critically wrong. But so far, all your OTA submissions were good! (Thank you for the nice titles as well!)

I know this initial batch of submitting all past updates was probably annoying, but with future updates not all coming out at the same time, it should get better..?

Is there anything particular you have issues with? Or submissions issues you worry about?
We obviously do want you to have a good time submitting updates, so we're open to any feedback you have.

---

For us and end-users, the GitHub process is nice because there's a dedicated thread (and PR) per submitted image. So users can quickly submit their feedback there. In the worst case, the update can be quickly removed again. The auto-generated PR is also linked from Home Assistant.

Example screenshot of how update entities for zigpy-ota updates look in Home Assistant

The "Read release announcement" link at the top links to the auto-generated GitHub PR (from zigpy-bot), where users can instantly provide positive or negative feedback. The release notes (when provided) are also shown nicely:

CLICK TO OPEN: Example of how update with link to auto-generated GitHub PR and release notes looks in HA

[3reality-support]

@3reality-support Hmm... We were generally under the impression that submitting through the web page would avoid a ton of issues, as you don't have to: update forks, create branches, upload files, create PRs, manually write JSON for optional metadata, and so on.

Ideally, you should just need to either provide a direct link that will be used to download the file once, or upload (a zipped file) of the OTA file. Further, a nice title and good release notes are very much appreciated by users as well, as users often wonder what gets added in new updates – and the release notes are shown in Home Assistant (but are optional).

If we find any issues with OTA submissions, we can just fix them ourselves before merging, or contact you if there's something really critically wrong. But so far, all your OTA submissions were good! (Thank you for the nice titles as well!)

I know this initial batch of submitting all past updates was probably annoying, but with future updates not all coming out at the same time, it should get better..?

Is there anything particular you have issues with? Or submissions issues you worry about? We obviously do want you to have a good time submitting updates, so we're open to any feedback you have.

For us and end-users, the GitHub process is nice because there's a dedicated thread (and PR) per submitted image. So users can quickly submit their feedback there. In the worst case, the update can be quickly removed again. The auto-generated PR is also linked from Home Assistant.

Example screenshot of how update entities for zigpy-ota updates look in Home Assistant

The "Read release announcement" link at the top links to the auto-generated GitHub PR (from zigpy-bot), where users can instantly provide positive or negative feedback. The release notes (when provided) are also shown nicely:

CLICK TO OPEN: Example of how update with link to auto-generated GitHub PR and release notes looks in HA

@TheJulianJES
OK, thank you for your explanation.

The main point is that there will be more tasks to handle in the initial preparation stage. When work gets busy, there are more steps to go through than before (for instance, one has to write the title by hand and fill in the link). Even such simple tasks can feel cumbersome.

Not to mention that it is operated by humans, there might be a situation of lack of concentration. So, if it leads to incorrect information filling, it would indeed be quite a problem. Especially for submissions like #146, since three devices are using this, it is necessary to emphasize model_names: ["3RSP019BZ", "3RSP02028BZ", "3RSPE01044BZ"]. If it wasn't me who temporarily changed to another colleague who was unclear about it, they might forget.

So on my side, I plan to fully automate this process. By reading the header information of the ota image file, I will be able to determine the device name, model ID, file version, and other relevant information. Streamline the operation.

However, since there is no API available, I will consider using Selenium for the operation.

[TheJulianJES]

@3reality-support
The crucial information like manufacturer_id and image_type is already read out from the OTA header from the submission system. The model_names for the three plugs in #146 is not actually required at all.

The "optional metadata" just further limits to which devices this update is made available to. Without specifying that, it would be available for all devices that request manufacturer_id=0x1233 (4659) AND image_type/PID=0xD3A6. This is per Zigbee spec.

With the model_names=[A, B, C], it just adds another AND condition, so it's only available for devices that have:
manufacturer_id=0x1233 (4659) AND image_type/PID=0xD3A6 AND also one of the three model names specified.

So, it's basically pointless to add that limit, unless you have another device that incorrectly requests that same image_type/PID but should NOT get that same update. The optional metadata is generally only needed when something doesn't follow Zigbee spec. For example: the UK/US plug accidentally sharing a PID – only there is it actually required to limit OTAs using models_names. Otherwise, it should not be needed at all.

---

So normally, it's just "put in OTA file" and submit. If it's too much work to fill-out the title, we can generally also do that (if it's not a brand new product). We have some automatic and semi-automatic checks looking over all submissions anyway.

But what users would really appreciate though, is that release notes are filled out, not left empty. Users are way more likely to upgrade if they see what's actually changed.

---

We'll look into different submission ways in the future, but doing everything completely automatically also runs into the risk of submitting completely untested or broken updates. With Home Assistant, we generally want to only ship fully tested and stable OTA updates.