MQTT - 433-module not reacting


#1

Hi, I am converting a project to MQTT and enconter a problem with an 433 module.
According to serialprint the expected actions in both the new and old sketch are taken:

Send Flamingo command: 
Flamingo Unit = :5
command = :1
Send sync
Send sync
Send sync
Send sync
Send sync
Send sync

So these are identical as in the old sketch. When I run the old sketch still with identical/same hardware (Wemos D1 R2 + RTC + 433-module the result is that an external switch will react on the 433-signal and switches a light. But in the new MQTT-sketch it looks ok but nothing happens externally.

Is there a difference in addressing the Digital pin 7 of a Wemos D1 R2 in the MQTT setup?
I have tried:

  1. int rfPin = D7;
  2. #define rfPin D7
  3. const int rfPin = 7;

Think option 3 is the new correct way to adress according to this topic
Will try out some more tests but if anyone has an idea in the meantime your input is most welcome!


#2
  1. creates an integer variable that can be changed at any time
  2. creates a read-only variable, but not recommended to use
  3. creates a read-only variable

Unless you are changing the value of rfPin somewhere, I can’t see that using const would change anything. The only thing I can suggest to try is setting rfPin to 13 instead of D7. If you post the code I can take a better look at it.


#3

Hi @Adam, thanks for your reaction. It appeared this was a combination of things:

  • The Library which is used flaminco.h does not like the MQTT environment and was causing a part of the problem.
  • The other part was caused by myself with two instances of the Arduino program open on my windows PC with two or more sketches open switching between Arduino and MQTT and uploading them. Giving all kind of error messages.

In the end the shaky (?) library part was solved with a second 433 library (which I already used for other switches) and a forced rebuild of the sketch before upload.

Just checked and all three options work.

So far I like the MQTT environment because the device is faster online and it seems that it does not drop connection too fast, Need to implement in this project still some Rube Goldberg logic for a workaround for the unreliable triggers and scheduling.


#4

Yes, the MQTT connection method seems all around a better platform from my experience. Glad you got it working!