433mhz, infrared IR to and from MQTT on ESP8266

Third party integrations
544

@finity

Yes, I’ve seen it :slight_smile:

I only use 433 mhz gateway. I think that you need two zgatewayrf with their corresponding config_rf.h files.

Anyway, although it is possible, I think that the gateway won’t pick up instantaneous signals sent by both 315 and 433 mhz devices as at any given time only one gateway will be active on the receiver pin (I might be wrong).

I’ve tested sending multiple 433 mhz signals in the same time and they’re all picked up by the gateway.

Having one gateway for each frequency seems more safe to me (especially since you can add any of the other types of gateways - IR, BLE, temp & humidity sensor, light sensors on the ADC pin, etc and thus not waste resources by having a dedicated board doing the RF signal processing). Anyway, you could also use multiple gateways of the same RF type (one in each corner of the house in order to have max coverage or one for each floor) and the sketch is designed to identify duplicates.

545

the link I’m following for the 315mHz integration is here:

https://github.com/1technophile/OpenMQTTGateway/issues/140

In the sketch he posted it has the pin definitions being the same for both the 315 and 433.

Are you saying that in theory the different tx/rx gateways will work if they are connected in parallel to the same pins on the 8266 board? But you think it may cause an issue so I should use 2 different 8266 boards? one for 315 & one for 433?

I do have 2 8266 boards I can use for this (ordered a 2-pack! :grin: ). But if you think it might work on the same one and using the same pins I can give it a try. what’s the worst that can happen? it just won’t work?

But, alternatively, is there a different set of pins available to use? I’m not planning on using any of the other modules (right now…) so could i steal the pins from them and make it work that way?

546

Having the receiver boards in parallel might not work (for the emitter you need different pins) and I don’t know if it won’t burn the ESP board with overvoltage.

Yes, I’ve seen the pins were left the same (0 and 3) for both 315 and 433 modules but that can be easily changed. Just add the modifications mentioned by @1technophile except for the pin definition where you use different pins for 315 mhz.

I see that there is a post in the link mentioned by you that says it can’t differentiate between 315 and 433 topics however I can’t replicate the issue as I don’t have 315 mhz gear.

547

I did see where he mentions changing the pin definitions (glossed right over that the first time).

Maybe @1technophile can chime in here sometime and add a bit of clarification on the topics issue.

thanks again for the help.

548

I got everything wired up and the sketch loaded for 433mHz only.

I published the sample from the github

I see the following on the monitor:

**my SSID**
OpenMQTTGateway mac: 
DC:4F:22:10:93:63
.
.
.
.
.
.
OpenMQTTGateway ip: 
192.168.1.109
WiFi ok
Connecting to MQTT by IP adress
192.168.1.125
RF_EMITTER_PIN 
3
RF_RECEIVER_PIN 
0
ZgatewayRF setup done 
MQTT connection...
Connected to broker
Subscription OK to the subjects
Hey I got a callback 
MQTTtoRF dflt
Ack pub.
Hey I got a callback 
Storing signal
Min ind: 
0
store code :
1315156/518118
Col: val/timestamp
0:1315156/518118
1:0/0
2:0/0
3:0/0
4:0/0
5:0/0
6:0/0
7:0/0
8:0/0
9:0/0
10:0/0
11:0/0
Data stored

the above doesn’t look like the example response.

is this correct?

549

Hello,

What are you doing physically or on your broker to generate this trace?

550

on my raspberry pi running mosquito i entered the following:

mosquitto_pub -u username -P password -t home/commands/MQTTto433 -m 1315156

551

What you are seeing correspond to a normal sending case, in a software side it is ok

552

Thank you. Good to know it’s working.

I now have to figure out how to learn codes.

553

ok…

for the life of me i can’t figure out what i’m doing wrong.

i can’t seem to read any codes in my mqtt broker.

i’ve verified my wiring.

i’ve subscribed to the mqtt topic (#) in MQTTFx and i see the topic exists there so the board is creating the topic.

but when i push the botton nothing happens. anywhere. not on the RPi terminal when subscribed to #, or on MQTTFx or on the serial monitor.

I’m not really sure where to go from here. I’ve got no real way to troubleshoot.

554

@1technophile

Maybe i’m just not sure which topic to subscribe to.

I tried all (#) but that didn’t work.

I tried “sudo mosquitto_sub -u uisername -P password -t home/433toMQTT -v” on the RPi. I still don’t see any response when i push any button on the remote.

I know the remote is working. it is the proper frequency because it is already paired with my broadlink RM Pro. And the device can be controlled thru HA.

Any hints at all on what might be wrong?

Is there a way to convert codes obtained thru broadlink into codes used by the gateway to test the transmitter portion?

555

Did you try to subscribe to all the message like that:
sudo mosquitto_sub -t +/# -v

But in all the case you should see the codes on the serial monitor if you have it open

556

yes i subscribed to all messages on the RPi as you posted. and also on MQTTFx to all topics. And had the serial monitor open.

On MQTTFx I can see the topic “home/OpenMQTTGateway/LWT” transition from “offline” to “online” when I plug in the gateway & then “home/OpenMQTTGateway/version” shows 0.6.2 so I know the gateway is talking to the network.

And I can see the same on the RPi for those topics so I know the gateway is talking to the RPi.

But nothing happens anywhere when I push a button on the remotes.

I am using two different ceiling fan remotes. Both are in working condition (the lights cycle with the remote) and are 433mHz that have previously been captured using my broadlink RM pro.

I checked the voltage between the +5vdc & gnd pins on both the Tx & Rx boards. it read 5vdc on my meter. The data pin is connected between the RX & DA for the Tx and between D3 & DATA on the Rx…

Could it be that the remotes aren’t supported by the libraries? one is a Hunter brand remote. the other is a universal remote I got from the local Home Depot. And like I said, both work perfectly fine with the Broadlink device controlled from HA.

Is there a way to convert the broadlink code to a code the gateway can use to test at least the Tx portion just to see if i’m on the right track?

Thanks for your help on this.

557

If you have an arduino laying around or abother esp8266 you could load into it a basic rcswitch example senddemo and see if the gateway receive the code. It will enable you to eliminate issue with the gateway itself.

558

i have a spare 8266 but i don’t have any spare transmitters. i’m still waiting on my 315mhz pair from amazon.

edit: i guess i could take the transmitter from my existing setup and use it on the spare 8266 to use as a test to the receiver on my existing one…

i’ll let you know how it goes.

559

I did the above and I do, in fact, see data on the serial monitor.

That’s good news and bad news.

It means my setup is working but it also means the entire reason I went this route was to capture the transmission from the existing remotes to keep HA in sync with the actual state of the devices. It appears that those remotes won’t work with the gateway. :frowning_face:

Is there any other tx/rx protocols/libraries that might work that i could try?

Any idea how this gateway works differently than the broadlink device?

560

You can also try activating ZgatewayRF2 and deactivate ZgatewayRF to see if it works.

561

I used the same sketch but modified it by modifying the following in user_config.h:

#ifdef ESP8266 // for nodemcu, weemos and esp8266
  //#define ZgatewayRF
  #include "config_RF.h"
  //#define ZgatewayRF315
  //#include "config_RF315.h"
  #define ZgatewayRF2
  //#define ZgatewaySRFB
  //#include "config_SRFB.h"

I originally tried to comment the “config_RF.h” as well but it complained about the pins being undefined.

I put it back in and now it compiles an loads but, alas, there is no difference in receiving codes.

still no response in the serial monitor.

562

i have verified that the remotes are 433mhz (433.92mhz) devices. they use an AS-12E encoder. hunter models 99110 & 99123.

Is there any other information that will help that i can research?

Is there anyone else that uses a different style of remote for a ceiling fan control with 5 buttons (4 fan speeds and a light off/on)?

563

Hi there,

I’m still struggling with my ESP32 as it simple stop working. At first I thought that the problem was my setup (remote dynamic domain mqtt) so I change my configurations and for now the esp32 and mqtt are at the same wireless network and the MQTT has a local fixed ip address. I also started to monitor the esp32 by pinging it from my HA/MQTT machine. From yesterday to today the ESP32 was responding pings for 18 hours, then it stopped for 3 hours for no reason and then start to respond pings again. But after it came online again it’s not sending any updates to MQTT. A “netstat” show that the ESP32 is connected to the mqtt port (1883) but this could because the long TCP timeouts.

Should I try a new pubsubclient library? Is anybody else using ESP32?