Repository navigation
Base IR platform - #867
Base IR platform#867
Conversation
|
I assume it is in response to this PR to instead add an infrared base platform to zha and integrate this Also opened a seperate discussion for that concept here in the zha repo's discussions section: FYI, for additional real world use cases check out this Zigbee IR blaster wrapper custom component and this general discussion for signals from the Home Assistent's community on how they would like to use a Zigbee infrared emitters/reciever bridge/proxy. See: For reference, latest release of Zigbee2MQTT also have native support for Tuya based Zigbee IR blasters/bridges (such as Tuya ZS06, Tuya UFO-R11, UFO-R4Z, QAIRZPRO), which should work with the new MQTT infrared platform in Home Assistant. See: Maybe also easyiot ZB-IR01? |
|
Any updates? |
|
@slavonnet What sort of updates? IR doesn't have receive capabilities in Home Assistant so this platform is at most half complete until that feature is added architecturally. |
If I have not misunderstood, the infrared entity platform in Home Assistant has been updated to support ceive capabilities? Infrared entity documentation at least seem to indicate that it now supports an receiver that captures incoming IR signals? There looks to be an Taken literally, the statement seems out of date? Home Assistant core's infrared platform does have receive support now. However, as I understand it, the upstream Home Assistant core's 's receiver model is passive, so the hardware is assumed to be always listening, which may not be possible to work with for Tuya's IR recievers that are currently on the market there is no way to tell a receiver to start listening or stop listening? Missing is some kind of learn mode commands in upstream Home Assistant core? slavonnet's home-assistant/core#175403 sidesteps this by building learn/receive flow into a separate ZHA-infrared integration. PS: Also check out this new roadmap discussion about shaping the way forward for a unified universal remote integration that uses Home Assistant's infrared component (which might lead to the upstream architectural changes needed for this?): |
|
FYI, Tuya UFO-R11 connected to Zigbee2MQTT can apparently now work as a native emitter and receiver with Home Assistant 2026.8 + MQTT infrared platform. Not tested myself but supposedly custom HAIR component discover it like other hardware: |
As I understand it, Zigbee2MQTT doesn’t work with ZHA? There’s no simple way to connect a device to ZHA but still broadcast it to MQTT? |
|
Thanks for working on this. I recently implemented a similar architecture in a Home Assistant custom integration, temporarily adapting two ZHA IR devices into standard
This suggests Home Assistant's existing subscription contract can support explicitly armed receivers while device-specific arming, rearming, conversion, and transfer behavior remains in the ZHA provider. Once ZHA exposes standard Infrared entities, the temporary compatibility layer can disappear without affecting consumers. If any of this is useful, I'd be glad to contribute a focused patch for optional modulation and receiver lifecycle/teardown handling, either against this draft or as a follow-up PR. |
|
@emrikol Definitely! I'm going to get this base platform finished up (it's just a mirror of HA's side with no consumers) but if you want to share your findings with existing devices, please feel free, we'll likely run into the same issues one way or another 😄 Architecturally, any existing IR device quirks we have will need to be modified to directly implement these entities instead of relying on fake ZCL clusters and other hacks, then retain their old feature set for backwards compatibility. The one IR device I have is battery powered but uses a compressed Tuya payload, enters learning mode for 30s only after being asked, etc. The battery powered device I think is exposing the API limitation, as it genuinely needs a dedicated learning mode in Core I think? |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #867 +/- ##
=======================================
Coverage 97.21% 97.22%
=======================================
Files 59 61 +2
Lines 10617 10654 +37
=======================================
+ Hits 10321 10358 +37
Misses 296 296 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
I think for battery-powered IR receivers (like my one Tuya device), the best we can do to conform to Core's entity model is have the device expose both an emitter and a receiver entity but also have an "Enter learning mode for 30s" button? When it's pressed, the IR receiver turns on and will emit received codes. |
zigpy-review-bot
left a comment
zigpy-review-bot
left a comment
There was a problem hiding this comment.
Clean base platform that mirrors the merged event base (#864) and HA core's infrared entity split; one small must-address below, otherwise this looks good to go.
Must-address
BaseInfraredEmitterdoesn't mix inABC, so its@abstractmethodis inert (inline comment).
Optional
- A docstring note on what
repeat_countmeans relative totimingswould save the first quirk author a double-repeat bug (inline comment).
Re: battery-powered receivers with a timed learning window (puddly's last comment)
The "emitter + receiver + a 'learn for 30s' button" shape seems like the right fit for the device you describe. HA's receiver contract is passive: InfraredReceiverEntity only offers async_subscribe_received_signal, with no arm/disarm hook, so the alternative is overriding that subscribe callback to arm the device on first subscriber (the approach emrikol described). For a sleepy device with a 30 s window, that turns "somebody is subscribed" into "keep re-waking the device every 30 s", which costs battery and hides from the user when capture is actually live. An explicit button keeps the arming user-driven and fits core's current model without new API; subscriber-driven arming stays available for mains-powered receivers that can listen indefinitely. None of this has to land in this PR, since the base classes don't constrain either approach.
Verified (5 checks)
tests/test_platform_infrared.py+tests/test_platform_event.pypass locally at 88aaf33 (9 passed); mypy in the worktree venv (real deps installed) is clean.PlatformEntity's metaclass is plaintype;inspect.isabstract(BaseInfraredEmitter)isFalseand__abstractmethods__is unset. WithABCmixed in, a subclass missingasync_send_commandraisesTypeErrorat instantiation, and the test'sFakeEmitteris unaffected.- Shapes against HA core (
homeassistant/components/infrared/entity.py):InfraredDeviceClassvalues match;InfraredSignal(timings, modulation, repeat_count)covers bothinfrared_protocols.commands.Command(get_raw_timings(),modulation,repeat_count) andInfraredReceivedSignal(timings, modulation). HA's receiver state (last-received timestamp) is maintained HA-side, so emitting an event without a state change here is consistent. _handle_received_signal→EntityInfraredSignalReceivedEvent(**self.identifiers.__dict__, ...)matches theeventplatform'sEntityEventTriggeredEventconstruction.discovery.PLATFORMSgainsINFRAREDlikeEVENTdid; nothing registers entities for it yet, so there is no snapshot/regen impact.
|
Regarding the discussions here around receivers, currently the Core architecture for receivers is meant for devices that can do "live" signal receiving. The "press-to-learn" ones, that only have a short window of learning time, are not supported. There should be no workarounds in quirks or zigpy for those. So most Zigbee devices' In the context of an "Universal Remote" integration (see OpenHomeFoundation/roadmap#226 ), it might make sense to extend the architecture to support "press-to-learn" devices, though. But that will require its own architecture proposal first. |
Like #864, this is a base platform with no discovery hooks. There are very few IR devices on the market (almost all of them Tuya) so this can be used as a base for a more complex entity that decouples Tuya from fake ZCL commands.