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

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.

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

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:

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!

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.

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

Nope, I power off my OMG @ Wemos and use its receiver/transmitter when I test OMG on Arduino

Could you post what you are seeing in serial monitor in this case?

Here is some optimizations following your issue

Thanks for the code. Could you tell if I need to do anything apart from substituting that .ino file in OMG project?

I’ll post the serial monitor output later.

You have to redownload the whole project and modify the user_config.h

I downloaded the development version didn’t do any memory optimisation.
I just commented #define simpleReceiving true as you said

Here what I get in Arduino IDE:

Sketch uses 28940 bytes (89%) of program storage space. Maximum is 32256 bytes.
Global variables use 1533 bytes (74%) of dynamic memory, leaving 515 bytes for local variables. Maximum is 2048 bytes.

The receiving part is apparently working, at least I receive signals from all my PIR sensors in HA when I expect them.

The transmitting bit is partly working. Every time I send a MQTT message to the OMG it passes it to the transmitter and the code is sent, but then the OMG loses connection with broker.
Here is what I seen in Serial monitor
Simple ethernet config
OpenMQTTGateway ip:
09:13:55.536 → 192.168.0.150
09:13:55.536 → Ethernet ok
09:13:55.536 → 1883
09:13:55.536 → Connecting to MQTT by IP adress
09:13:55.574 → 192.168.0.34
RF_EMITTER_PIN
09:13:57.061 → 4
09:13:57.061 → RF_RECEIVER_PIN
09:13:57.061 → 1
09:13:57.061 → RF setup ok
09:13:57.061 → MQTT_MAX_PACKET_SIZE
09:13:57.061 → 128
09:13:57.061 → Setup OpenMQTTGateway end
MQTT connection…
Connected to broker
09:14:02.220 → Subscription OK to the subjects
Hey I got a callback
09:14:20.113 → MQTTtoRF json
MQTTtoRF OK
09:14:21.030 → Pub json into:
09:14:21.030 →
09:14:21.030 → {“value”:“10952789”}
09:14:21.030 → MQTT connection…
Connected to broker
09:14:23.233 → Subscription OK to the subjects

and in the MQTT log

home/OpenMQTTGateway/LWT online

home/OpenMQTTGateway/version 0.9.1beta

home/OpenMQTTGateway/commands/MQTTto433 {“value”: “10952789” }

home/OpenMQTTGateway/LWT offline

home/OpenMQTTGateway/LWT online

home/OpenMQTTGateway/version 0.9.1beta

So it’s better and I can turn on a light, but not quite as HA does not receive a confirmation from the OMG that command was successful and turns the light switch back off in UI so there is no way to turn it back off from there :
If I send the off command using mosquitto_pub, it behaves exactly the same. Something goes wrong when it tries to send back a response.

If I uncomment #define simpleReceiving true and comment #define jsonReceiving true, I have to do some memory optimisation.
MQTT_MAX_PACKET_SIZE in libraries/pubsubclient/src/pubsubclient.h is already 128 for my board so I reduce RCSWITCH_MAX_CHANGES in libraries/rc-switch/rcswitch.h to 67
In Arduino IDE I can see

Sketch uses 30010 bytes (93%) of program storage space. Maximum is 32256 bytes.
Global variables use 1371 bytes (66%) of dynamic memory, leaving 677 bytes for local variables. Maximum is 2048 bytes.

In this case I can switch my RF devices on and off.
Here is the output in Serial Monitor

⸮⸮RAOr⸮>⸮⸮GTF⸮⸮b⸮T⸮⸮⸮⸮I⸮ F⸮[⸮\⸮Simple ethernet config
OpenMQTTGateway ip:
09:29:54.803 → 192.168.0.150
09:29:54.803 → Ethernet ok
09:29:54.803 → 1883
09:29:54.803 → Connecting to MQTT by IP adress
09:29:54.803 → 192.168.0.34
RF_EMITTER_PIN
09:29:56.311 → 4
09:29:56.311 → RF_RECEIVER_PIN
09:29:56.311 → 1
09:29:56.311 → RF setup ok
09:29:56.311 → MQTT_MAX_PACKET_SIZE
09:29:56.311 → 128
09:29:56.311 → Setup OpenMQTTGateway end
MQTT connection…
Connected to broker
09:30:01.674 → Subscription OK to the subjects
Hey I got a callback
09:30:38.128 → MQTTtoRF dflt
Hey I got a callback
09:30:39.019 → MQTTtoRF dflt
Hey I got a callback
09:30:39.961 → Store signal
09:30:39.961 → Json buf.
09:30:39.961 → Hey I got a callback
09:30:39.961 → Store signal
09:30:39.961 → Json buf.
Hey I got a callback
09:30:43.785 → MQTTtoRF dflt
Hey I got a callback
09:30:44.712 → Store signal
09:30:44.748 → Json buf.

and in mqtt log

home/OpenMQTTGateway/LWT online

home/OpenMQTTGateway/version 0.9.1beta

home/OpenMQTTGateway/commands/MQTTto433 12001361

home/OpenMQTTGateway/commands/MQTTto433 12001361

home/OpenMQTTGateway/433toMQTT 12001361

home/OpenMQTTGateway/433toMQTT 12001361

home/OpenMQTTGateway/commands/MQTTto433 12001360

home/OpenMQTTGateway/433toMQTT 12001360

Strange that there is more than one ON command to my extractor fan, but it’s only for that device, every other UI switch generates only one ON and OFF command, so it’s for me to investigate.

The bottom line is we are almost there, well done Florian!
Just have a look at the code as it would be fantastic to get that jsonReceiving bit working so there will be no need to mess around with RCSwitch code.

And one more thing: if I power on my Arduino via a USB cable connected to a power adapter, it won’t go online until I press its Reset button (only PWR LED on and TX blinking). If I connect it with this cable to my PC and run AND then run Arduino IDA with Serial Monitor, it connects to the network and becomes online. What can I do to make it connect to the network without Serial Monitor?

Currently there is no need of going above 67 for rcswitch max changes, as the OMG code handle an unsigned long only. I pushed the modification to the development branch.

Le croquis utilise 30936 octets (95%) de l’espace de stockage de programmes. Le maximum est de 32256 octets.
Les variables globales utilisent 1425 octets (69%) de mémoire dynamique, ce qui laisse 623 octets pour les variables locales.

I have tested without commenting simplereceiving:
mosquitto_pub -t home/OpenMQTTGateway_UNO_TEST/commands/MQTTto433 -m {"value":10274209}
mosquitto_pub -t home/OpenMQTTGateway_UNO_TEST/commands/MQTTto433 -m 10274209
mosquitto_pub -t home/OpenMQTTGateway_UNO_TEST/commands/MQTTto433 -m '{"value":1119583,"protocol":1,"length":24,"delay":307}'
mosquitto_pub -t home/OpenMQTTGateway_UNO_TEST/commands/PLSL_340/433_1/RFBITS_25/MQTTto433 -m 10274209

And all seems to work fine, could you confirm please?

With #define jsonPublishing true, #define jsonReceiving true and #define simpleReceiving true it does work. Not the most intuitive choice for a user though, maybe it’s a good idea to think about refactoring that :wink:

The only question that still bugs me (it applies to all versions from 0.8 onwards on Arduino UNO) is why it does not connect to network automatically (until I press Reset button on the board) if it’s not connected to a computer with Arduino IDE AND Serial Monitor running?
It is crucial to me as if power cycle happens, my RF2HA gateway will be useless until I physically reset it, and I cannot afford it as it’s a key part of a security system.

I can confirm that it applies to Ardiono UNO, but Wemos D1 mini works fine flashed with v.0.8 or v.0.9

As it is per default in user_config.h set like that, do you think it is still not intuitive?

Maybe some ideas there:

Sorry mate, I need to sleep more. After so many tweaking I completely forgot what was there by default, my bad.

That’s awesome, man! Thank you SO much…

One last question - does it really matter to OMG if I send mqtt arguments in json format or plain? What’s the difference and what to use?

No problem :slight_smile:

Does it worked for you?

As I see the evolution of MQTT interfacing methods, json is more likely to be maintained and should be the new way of interfacing with home automation software.
Nevertheless I want to keep plain at least for 2 or 3 versions as it is a simple way of interfacing.

yes, after soldering a small capacitor it boots up as expected.

got it, still have time to convert my code though :wink:

Perfect, would it be possible for you to write a paragraph about this issue in the troubleshooting section of the wiki ? So as to help the other users encountering this issue.

I ended up commenting #define simpleReceiving true and converted all my mqtt stuff to JSON publishing. It works as expected.

Yes, I’ll write about the Ethernet shield issue soon.

1 Like