No announcement yet.


  • Filter
  • Time
  • Show
Clear All
new posts

    Am I right in understanding that a Broadlink unit (also the Broadlink Mini 4?) will connect to the raspberry/HS4 by using the MCSMQTT plugin?
    Yes, I have the Pro 4. The Mini 4 should be the same as the Pro 4 without the RF capability. If there is an issue we can easily work through it. Each devices reports its type as a 4 character number. mcsMQTT uses it to know the communication protocol to use. I have made some assumptions about the range of numbers that will cover the Broadlink 4 series based upon the Pro 4 model I have. If the Mini 4 was given something that does not fit the pattern then the pattern can be updated.


      However, the HS4 I am using does not give access to this plugin. Perhaps it does run on Windows HS4?
      It does work with HS4 on Win10. I use the two way ability of the UsbUirt to allow a IR remote to trigger a HS4 event to send out Z-wave and IR commands (For example pressing OFF on the remote triggers a HS4 event to turn the lights on, switch various items off with IR commands, then turns off various z-wave sockets). I couldn't replicate that with the GC Pro, but the Broadlink might sort it.

      My UsbUirt is presently working on a Usb to IP remote connection (VirtualHere and an old RasPi) but I'm not happy with that as it's a bit flaky. I was looking at different Usb to IP systems, but the Broadlink is much cheaper than those.

      Can anybody confirm if the Broadlink can replicate the two way "IR from remote control triggers HS4 event" and "HS4 event sends out IR to control AV amp etc" functionality ?


        The Broadlink RM4, and I believe all Broadlink models, are mode-based so they can be either sending IR or receiving IR, but not both at the same time. The software I developed for the mcsMQTT plugin was done based upon it's design use-case where the IR receive was done for the purpose of learning an IR code and not for the purpose of providing notification that an IR code was detected. The Broadlink internal firmware establishes a time window for detecting a code while learning. Since the time window is fixed it is not possible to setup the device for a 100% detection interval. It could reenter learning mode after timeout, but then there would be times that it could miss a IR signal.

        Tasmota firmware supports both IR Receive and IR Send and can be installed in a device such as YTF IR Bridge - Tasmota. I have no specific experience with the YTF. What I have done is installed Tasmota in a generic ESP8266 as described in Section 17.23 of My experience was that it worked fine for sending IR to control equipment and providing feedback that an IR code was sent. What it would not do is simultaneously do both. I suspect is by design since it would be receiving the same code it was sending.

        What I did was separate the packaging into a separate IR receive function and IR send function so I could receive IR at a central location where my pickup was and send IR from a more advantageous blaster location. Since the two are independent devices there was no possibility of contention.


          I just uploaded v4.0.0.4 of my plugin to the updater. It now supports sending IR codes via a USBUirt on Windows. Unfortunately it will need extra coding to get it to work on Linux and I hope to release that in the next version soon. Receiving IR codes from a USBUirt will be in another version sometime after that.


            Thank you Drule,
            great news,
            still on HS3 but should eventually migrate; will report back,