Infrared receiver to trigger flow in Homey (Pro)

Hi all,

I am looking for a way to pick up infrared signals and send send a command to Homey (Pro), so it can trigger a flow.
Homey itself is to far away to use it’s IR receivers.

In more detail:
I would like to trigger my ventilation unit when my ATAG hob (cooker) is turned on. Atag calls it Hob2Hood, but I cannot use a hood from ATAG in my apartment building.

The hob sends out IR signals when it is turned on or power (induction hob) is in-/decreased. My ventilation has 3 positions so ideally the receiver would have to be able to distinguish 3 different IR signals.

When a certain signal is received from the hob, it should trigger a flow on Homey. Either by wifi, zigbee, webhook, app, etc…) which triggers the ventilation.

I have a braodlink RM3 mini, which I have learned the ATAG infrared signals, but the Broadlinks doesn’t actively listen for signals when not in learning mode… :frowning:

Anyone know of a solution to this “problem”?
(Some soldering is no problem; I am not the greatest programmer though. If the code is ready-to-go; no problem.

Hi Henk,

Have you tried using Homeys built-in IR learning feature … :smirk:

Just kidding :wink:.

With your Broadlink , wouldn’t you be able to manually operate each feature of your kitchen gear manually and record each event individually one at a time… ?

This receives and then sends the IR signal’s code via MQTT. That way you can trigger flows with the corresponding code of your choice.

A flow to start the cooker hood, could look something like this

I was just about to say if you can access all of the ingoing and out going communication and access all of the raw data streams and convert it into MQTT then that will give you a lot of access and flexibility…

I essentially have to do the same thing to be able to learn and transmit all my 433mhz gear using a Tasmota flashed SonOff RF bridge and using the MQTT client App…

That NodeMCU project looks quite interesting. I’ve never seen anything like it before , for IR …

Still though all are a bunch external Band-Aid solutions to make our “all in one” €390 Homey’s functional which we really shouldn’t have to do.

I wonder if I could pull out all of the IR LED’s, the 434mhz chip and the antenna from my Homey and send them back to Athom and get a refund on those parts … lol

I also thought IR TO Homey was not possible yet.
Then I thought again: let’s search for IR to MQTT (using WiFi);
That project I found seems to do the trick!

I recently purchased and Raspberry Pi and have been fooling around with HomeBridge lately as I was always curious as to what it could do.

While playing around with it I’ve been discovering heaps of MQTT based plug-in’s and projects. MQTT seems to be quiet a powerful tool and
a means of getting a variety of different hardware to integrate … It opens up a lot of possibilities…

If Homey’s Virtual devices had MQTT support natively built in, it would be quite a powerful feature to have I reckon. Would help access things like that IR NodeMCU project a lot easier…

I managed to set it all up with NodeMCU and was able to connect it to my MQTT Broker on my Synology NAS, which I also use for my Home Assistant dashboard.
And I do see that the IR-values are sent to MQTT (with MQTT Explorer on my pc).

I just don’t get Homey to respond to it by the flow you gave.
Do I need to set something up in the MQTT Client app on Homey?
I don’t see Osooyoo anywhere in the logging in MQTT Client.
What do I forget / or am I doing wrong?

I was able to investigate a little more:
It seems I have to use “OsoyooData” instead of “OsoyooCommand”. I see no mentions of “OsoyooCommand” in MQTT Explorer, only “OsoyooData” which does receive IR codes.

I use the following flow for testing”

This results in a mention “On/off NIET getriggert” on the Homey timeline:

That should tell me that something is received on “OsoyooData” but it didn’t match 16730805.

When I check the MQTT client, I see the following:

I suppose I am doing something wrong with the MQTT Client. Do you, @Peter_Kawa or anyone with a little more knowledge of the MQTT Client than me have any idea how to solve this?

Almost there!

(Yeah, the how-to is a little off about the Osoyooxxxxxxx topic name appearantly.
The MQTT explorer is the way to go, and should reveal the topic and values, like you figured out alr.
The MQTT client receives the topic and message/value perfectly, according to the log you showed.)

As an example, or to compare, I created a flow for my Owntracks location topic.
As you see,
-the topic is “owntracks/peter/S9” (your topic isOsoyooData”).
-the message/value contains “location” (your message/value isReceive value: 16730805”).
See your MQTT Client log entry:


I’d like you to test the logics card “Contains”: 16730805, OR “is exactly”: Receive value: 16730805.
The logics “Contains” card is my choice in test / troubleshoot flows. The chance to a matching value is way bigger :wink:

My example:

  • Flow:


MQTT Client log:

20211014-14:00:06 OnMessage called
20211014-14:00:06 received '{"_type":"location","BSSID":"50:xxxxxxx","SSID":"Fxxxxxxxx","acc":6,"alt":29,"batt":54,"bs":1,"conn":"w","created_at":1634220006,"inregions":["Thuus","big range"],"lat":5xxxxxxx,"lon":xxxxxxxx,"tid":"PD","tst":1634220006,"vac":150,"vel":1}' on 'owntracks/peter/S9'
20211014-14:00:06 Listener eventMQTT called
20211014-14:00:06 checking state.topic = owntracks/peter/S9 topic = hass/status
20211014-14:00:06 Listener eventMQTT called
20211014-14:00:06 checking state.topic = owntracks/peter/S9 topic = owntracks/peter/S9
20211014-14:00:06 trigger topic = owntracks/peter/S9 message topic = owntracks/peter/S9

It’s somewhat better understandable now, I hope, Henk!


Yes, that was very clear!
Just changing “16730805” in “Receive value: 16730805” did the trick.
I thought only the numbers were the payload.

Thank you very much, @Peter_Kawa !

1 Like