Arduino UNO + Ethernet shield: reboots on receiving RF signal on v.0.9


#1

I’m trying to set up OMG v.0.9 on Arduino UNO with a Ethernet shield, and it doesn’t work.
What I did before uploading:
in libraries/pubsubclient/src/pubsubclient.h: #define MQTT_MAX_PACKET_SIZE 128
in libraries/rc-switch/rcswitch.h: #define RCSWITCH_MAX_CHANGES 67
in config_RF: #define RF_RECEIVER_PIN 0

It compiles and uploads without any warnings.

In serial monitor I can see:

Advanced ethernet config
OpenMQTTGateway ip:
192.168.0.50
Ethernet ok
1883
Connecting to MQTT by IP adress
192.168.0.34
RF_EMITTER_PIN
4
RF_RECEIVER_PIN
0
RF setup ok
MQTT_MAX_PACKET_SIZE
128
JSON_MSG_BUFFER
512
Setup OpenMQTTGateway end
MQTT connection…
Connected to broker
Subscription OK to the subjects

If I send a command to it via MQTT (like home/OpenMQTTGateway/commands/MQTTto433 12001361) it says in the serial monitor:

Hey I got a callback

but nothing happens.

And if it receives a 433MHz signal, it restarts itself. In serial monitor I have this:

Advanced ethernet config
OpenMQTTGateway ip:
192.168.0.50
Ethernet ok
1883
Connecting to MQTT by IP adress
192.168.0.34
RF_EMITTER_PIN
4
RF_RECEIVER_PIN
0
RF setup ok
MQTT_MAX_PACKET_SIZE
128
JSON_MSG_BUFFER
512
Setup OpenMQTTGateway end
MQTT connection…
Connected to broker
Subscription OK to the subjects

Advanced ethernet config
OpenMQTTGateway ip:
192.168.0.50
Ethernet ok
1883
Connecting to MQTT by IP adress
192.168.0.34
RF_EMITTER_PIN
4
RF_RECEIVER_PIN
0
RF setup ok
MQTT_MAX_PACKET_SIZE
128
JSON_MSG_BUFFER
512
Setup OpenMQTTGateway end
MQTT connection…
Connected to broker
Subscription OK to the subjects

and in mqtt logs:

home/OpenMQTTGateway/LWT online

home/OpenMQTTGateway/version 0.9

home/OpenMQTTGateway/commands/MQTTto433 12001361

home/OpenMQTTGateway/LWT offline

home/OpenMQTTGateway/LWT online

home/OpenMQTTGateway/version 0.9

I tried to use pins D3 and D2 (the one between TX and D3) and it makes no difference.
It does not restart if I disconnect receiver’s data pin from the Arduino.

The interesting thing is the very same board works fine if I disconnect the shield, upload OMG v.0.8.1 to it and reconnect the shield back.

By the way, using both OMG versions I had to define const byte mac[] and const byte ip[] in user_config.h despite the comment that ip will only be used if no dhcp configuration is available.
My board has a fixed ip address tied to the MAC address I define in user_config.h

Is there any way to make v.0.9 work on my Arduino? I have it working on Wemos D1 mini, but really want a wired connection instead of WiFi.


#2

Hello,

I understand you ethernet will enable faster reactivity and performance for the gateway.

So as to help you could you post your user_config.h without the credentials please.

You can also try to publish a command in json format


#3

Here is my user_config.h:

/-------------------VERSION----------------------/
#define OMG_VERSION “0.9”

/-------------CONFIGURE WIFIMANAGER-------------(only ESP8266 & SONOFF RFBridge)/
/*

  • The following parameters are set during the WifiManager setup process:
    • wifi_ssid
    • wifi_password
    • mqtt_user
    • mqtt_pass
    • mqtt_server
    • mqtt_port
  • To completely disable WifiManager, define ESPWifiManualSetup.
  • If you do so, please don’t forget to set these variables before compiling
  • Otherwise you can provide these credentials on the web interface after connecting
  • to the access point with your password (SSID: WifiManager_ssid, password: WifiManager_password)
    */

/-------------DEFINE YOUR NETWORK PARAMETERS BELOW----------------/
#if defined(ESP8266) // for nodemcu, weemos and esp8266
//#define ESPWifiManualSetup true //uncomment you don’t want to use wifimanager for your credential settings on ESP
#endif

#if defined(ESP32) || defined(ESPWifiManualSetup) // for nodemcu, weemos and esp8266
#define wifi_ssid “wifi ssid”
#define wifi_password “wifi password”
#else // for arduino + W5100
const byte mac[] = { 0x00, 0x24, 0x1B, 0x14, 0xA7, 0x3F }; //W5100 ethernet shield mac adress
#endif

#define WifiManager_password “your_password” //this is going to be the WPA2-PSK password for the initial setup access point
#define WifiManager_ssid “OpenMQTTGateway” //this is the network name of the initial setup access point
#define WifiManager_ConfigPortalTimeOut 120

/-------------DEFINE YOUR MQTT PARAMETERS BELOW----------------/
//MQTT Parameters definition
//#define mqtt_server_name “www.mqtt_broker.com” // instead of defining the server by its IP you can define it by its name, uncomment this line and set the correct MQTT server host name
char mqtt_user[20] = “xxxx”; // not compulsory only if your broker needs authentication
char mqtt_pass[30] = “xxxx”; // not compulsory only if your broker needs authentication
char mqtt_server[40] = “192.168.0.34”;
char mqtt_port[6] = “1883”;

#define Gateway_Name “OpenMQTTGateway”

//uncomment the line below to integrate msg value into the subject when receiving
//#define valueAsASubject true

/-------------DEFINE THE MODULES YOU WANT BELOW----------------/
//Addons and module management, comment the Z line

#define ZgatewayRF “RF” //ESP8266, Arduino, ESP32
//#define ZgatewayRF315 “RF315” //ESP8266, Arduino, ESP32
//#define ZgatewayIR “IR” //ESP8266, Arduino, Sonoff RF Bridge
//#define ZgatewayPilight “Pilight” //ESP8266, Arduino, ESP32
//#define ZgatewayBT “BT” //ESP8266, Arduino, ESP32
//#define ZgatewayRF2 “RF2” //ESP8266, Arduino, ESP32
//#define ZgatewaySRFB “SRFB” // Sonoff RF Bridge
//#define Zgateway2G “2G” //ESP8266, Arduino, ESP32
//#define ZgatewayRFM69 “RFM69” //ESP8266, Arduino, ESP32
//#define ZactuatorONOFF “ONOFF” //ESP8266, Arduino, ESP32, Sonoff RF Bridge
//#define ZsensorINA226 “INA226” //ESP8266, Arduino, ESP32
//#define ZsensorHCSR501 “HCSR501” //ESP8266, Arduino, ESP32, Sonoff RF Bridge
//#define ZsensorADC “ADC” //ESP8266, Arduino, ESP32
//#define ZsensorBH1750 “BH1750” //ESP8266, Arduino, ESP32
//#define ZsensorTSL2561 “TSL2561” //ESP8266, Arduino, ESP32
//#define ZsensorBME280 “BME280” //ESP8266, Arduino, ESP32
//#define ZsensorDHT “DHT” //ESP8266, Arduino, ESP32, Sonoff RF Bridge
//#define ZsensorGPIOKeyCode “GPIOKeyCode” //ESP8266, Arduino, ESP32
//#define ZsensorGPIOInput “GPIOInput” //ESP8266, Arduino, ESP32
//#define ZmqttDiscovery “HADiscovery”//ESP8266, Arduino, ESP32, Sonoff RF Bridge

/-------------DEFINE YOUR ADVANCED NETWORK PARAMETERS BELOW----------------/
//#define MDNS_SD //uncomment if you want to use mdns for discovering automatically your ip server, please note that MDNS with ESP32 can cause the BLE to not work
#define maxMQTTretry 4 //maximum MQTT connection attempts before going to wifi setup

//set minimum quality of signal so it ignores AP’s under that quality
#define MinimumWifiSignalQuality 8

// these values are only used if no dhcp configuration is available
const byte ip[] = { 192, 168, 0, 50 }; //ip adress
const byte gateway[] = { 192, 168, 0, 1 }; //ip adress, if first value is different from 0 advanced config network will be used and you should fill gateway & dns
const byte Dns[] = { 0, 0, 0, 0 }; //ip adress, if first value is different from 0 advanced config network will be used and you should fill gateway & dns
const byte subnet[] = { 255, 255, 255, 0 }; //ip adress

/-------------DEFINE YOUR MQTT ADVANCED PARAMETERS BELOW----------------/
#define Base_Topic “home/”
#define version_Topic Base_Topic Gateway_Name “/version”
#define will_Topic Base_Topic Gateway_Name “/LWT”
#define will_QoS 0
#define will_Retain true
#define will_Message “offline”
#define Gateway_AnnouncementMsg “online”

#define jsonPublishing true //comment if you don’t want to use Json publishing (one topic for all the parameters)
//example home/OpenMQTTGateway_ESP32_DEVKIT/BTtoMQTT/4XXXXXXXXXX4 {“rssi”:-63,“servicedata”:“fe0000000000000000000000000000000000000000”}
#define jsonReceiving true //comment if you don’t want to use Json reception analysis

//#define simplePublishing true //comment if you don’t want to use simple publishing (one topic for one parameter)
//example
// home/OpenMQTTGateway_ESP32_DEVKIT/BTtoMQTT/4XXXXXXXXXX4/rssi -63.0
// home/OpenMQTTGateway_ESP32_DEVKIT/BTtoMQTT/4XXXXXXXXXX4/servicedata fe0000000000000000000000000000000000000000
#define simpleReceiving true //comment if you don’t want to use old way reception analysis

/-------------DEFINE YOUR OTA PARAMETERS BELOW----------------/
#define ota_hostname Gateway_Name
#define ota_password “OTAPASSWORD”
#define ota_port 8266

/-------------DEFINE PINs FOR STATUS LEDs----------------/
#define led_receive 40
#define led_send 42
#define led_error 44

// VCC ------------D|-----------////\ ----------------- Arduino PIN
// LED Resistor 270-510R

/----------------------------OTHER PARAMETERS-----------------------------/
/-------------------CHANGING THEM IS NOT COMPULSORY-----------------------/
/----------------------------USER PARAMETERS-----------------------------/
#ifdef ZgatewaySRFB
#define SERIAL_BAUD 19200
#else
#define SERIAL_BAUD 115200
#endif
/--------------MQTT general topics-----------------/
// global MQTT subject listened by the gateway to execute commands (send RF, IR or others)
#define subjectMQTTtoX Base_Topic Gateway_Name “/commands/#”
#define subjectMultiGTWKey “toMQTT”
#define subjectGTWSendKey “MQTTto”

//variables to avoid duplicates
#define time_avoid_duplicate 3000 // if you want to avoid duplicate mqtt message received set this to > 0, the value is the time in milliseconds during which we don’t publish duplicates

//uncomment to use multicore function of ESP32 for BLE
#ifdef ESP32
#define multiCore //comment to don’t use multicore function of ESP32 for BLE
#endif

#define JSON_MSG_BUFFER 512 // Json message max buffer size, don’t put 1024 or higher it is causing unexpected behaviour on ESP8266

#define TimeBetweenReadingSYS 120000 // time between system readings (like memory)
#define subjectSYStoMQTT Base_Topic Gateway_Name “/SYStoMQTT”

/-------------------ACTIVATE TRACES----------------------/
#define TRACE 1 // commented = trace off, uncommented = trace on


#4

Could you comment this line and give me the result of the build ( a copy/paste of the IDE returns)?


#5

Here it is

Sketch uses 29286 bytes (90%) of program storage space. Maximum is 32256 bytes.
Global variables use 1363 bytes (66%) of dynamic memory, leaving 685 bytes for local variables. Maximum is 2048 bytes.

It makes no difference in terms of rebooting :\


#6

Remaining memory is ok.

When it reboots could you indicates me what are its last words in serial monitor ?

Alternatively do you have an arduino mega to test with?


#7

I pasted all from serial monitor - is appears like a clean start.
Is there any way to make it more verbose in serial monitor?
I have a Mega, but it’s my production RFLink device and I just can’t risk it at the moment… :frowning:


#8

could you try just to put D2 or D3 to 5V to see if it reset also? Or alternatively you have maybe another UNO to try with?


#9

It does not reset if I connect D2 to either 5V or GND.
Unfortunately, that’s the only alive UNO I have.
As I said, it works fine flashed with v.0.8.1 so I think it’s all about software here.
Maybe decreasing number of channels has such an effect?


#10

Could you give me more details? What do you mean by channels?


#11

I followed these recommendations, see my initial post


#12

Could you try v0.9 with the rcswitch library of V0.8.1 please?
There was a change in the rcswitch fork used.


#13

Update:
I tried again with a clean v.0.9.
When I send a RF signal (from a remote), it shows

Rcv. RF

and then apparently crashes as it is followed by

Simple ethernet config

When I send a MQTT command, it restarts as well. If I comment #define simpleReceiving true it prints a lot of stuff including mqtt password and other wild mixture of anything and goes offline, I can only return it back to life by pressing Reset button on it.

If I get v.0.9 and replace rc-switch with that from v.0.8.1, OMG reboots itself on receiving a RF signal (I can see sometimes Rcv. Rad in Serial Monitor) with simpleReceiving true, and with that commented I get Rcv. RF in Serial Monitor and the board stays offline until I reset/power cycle it.
If I send a MQTT command, I get in Serial Monitor

Hey I got a callback
MQTT connection…
Connected to broker

and the board hangs.

What else can I try?


#14

I will try with my UNO and go back to you


#15

That would be great, thank you!
It’s a shame to go back to v.0.8 as v.0.9 offers plenty of really useful features and I just can’t justify “downgrading” my code because of that rollback.


#16

I found the issue, It seems that json implementation is taking too much memory in ram.
Could you try to set in user_config.h

#define JSON_MSG_BUFFER 64


#17

Well, v.0.9 with
MQTT_MAX_PACKET_SIZE
128
JSON_MSG_BUFFER
64

and
#define jsonPublishing true
#define jsonReceiving true

compiles and uploads fine, receives RF signals, but fails to send RF signal when receives something like home/OpenMQTTGateway/commands/MQTTto433 10952788

If I comment out #define jsonReceiving true and uncomment #define simpleReceiving true, Arduino complains

Sketch uses 30276 bytes (93%) of program storage space. Maximum is 32256 bytes.
Global variables use 1549 bytes (75%) of dynamic memory, leaving 499 bytes for local variables. Maximum is 2048 bytes.
Low memory available, stability problems may occur.

but it works.
If I then set #define RCSWITCH_MAX_CHANGES 67 in libraries/rc-switch/rcswitch.h, it compiles, uploads and works almost fine, but apparently “swallows” some signal completely as “duplicates” or something - I can see my PIRs blinking, but some signals are not received as 433toMQTT messages, and in Serial Monitor I can see plenty of “don’t pub. duplicate”. And it’s not that a particular sensor does not work - it’s more like that any RF signal might or might not be considered as duplicate (and subsequently filtered out and not passed to MQTT) for some reason.
If I leave both jsonReceiving and simpleReceiving uncommented, it still swallows the codes, but prints out much less in the Serial Monitor. And my Wemos D1 mini receives MUCH more various RF signals than UNO despite having the very same receiver (I just disconnect it from one and connect to the other) and config (in terms of Receiving/Publishing). Well, I understand that’s a different code as the boards are different, but in the end they only process data, and therefore should do it identically).
Also, despite UNO having wired network connection the speed see messages appearing is visibly slower than in case of wifi-connected Wemos, I hoped it will be completely opposite… To clarify - the UNO plugged into a wireless router that serves as a AP for Wemos so basically from the router to Hass the network path should be the same…

If I revert back to #define jsonReceiving true, RF sending doesn’t work, most likely because I need to send a JSON packet rather than a number.

Thanks Florian, hope you comment on it and we’ll improve it a bit further :wink:


#18

Indeed with jsonpublishing and receiving the program size is smaller giving more space for memory.
Is it possible for you to use json, just publish:
home/OpenMQTTGateway/433toMQTT {"value":1315156,"protocol":1,"length":24,"delay":317}
or
home/OpenMQTTGateway/433toMQTT {"value":1315156}

In my side I will work on optimizing ram usage and giving constants size preconisations for the UNO.

In all the cases thanks for pointing this!


#19

Yes, I’m pretty sure that if I enable only jsonPublishing/Receiving and convert my automation to send json rather than simple values, it will do the trick.
The only thing that really stops me from migrating to theUNO is that issue with lost RF signals.
Do you have an idea what to look for on your side or any more data is needed?

Anyway, thanks for your awesome project and help, really appreciate.


#20

When you are seeing that do you have another OMG running?