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


#21

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


#22

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


#23

Here is some optimizations following your issue


#24

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.


#25

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


#26

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?


#27

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?


#28

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


#29

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

Maybe some ideas there:


#30

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?


#31

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.


#32

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

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


#33

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.


#34

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.