Replies: 2 comments
|
For reference, there are also many different discussions by others about Zigbee IR blasters (a.k.a. infrared-bridge) that directly or indirectly relating to these ideas/concepts posted or raised elsewhere by the community at large, both for ZHA and Zigbee2MQTT (Z2M), see example: |
0 replies
|
Closed proof-of-concept to the idea of using the native infrared integration building block might be this Zigbee IR Bridge custom component from tomer2526 that exposes Zigbee2MQTT (Z2M) and ZHA IR emitters, such as ZS06, UFO-R11, and similar Zigbee IR blasters, as standard Home Assistant infrared entities: Perhaps could adopt that natively directly inside the ZHA integration component so no need to a custom component? |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
FYI, slavonnet has begun working on a infrared component built on-top of the ZHA integration and submitted is a new separate integration for Home Assistant:
But was there not an idea raised by ZHA developer(s) to make an native "IR-proxy" interface for Zigbee IR blasters inside the official ZHA integration component that instead builds on-top of the infrared entiry/integration/platform instead?
That is, using that infrared integration as a building block then made some kind of IR-proxy bridging wrapper that makes ZHA with ZHA Device Handlers (zha-quirks) for a Zigbee IR blaster work similar to an ESPHome-based IR-proxy so most of the translation could instead somehow be handled via custom quirks, while you then have different integrations in Home Assistant that just uses the standard infrared integration regardless of which IR-proxy is used in the backend.
As described in this blog post:
I really like the learning remote part though which is not available in HA today via the infrared integration.
All reactions