Raspberry Pi MQTT gateway crashes after a few hours
-
Hi
I've setup a MQTT gateway on a raspberry pi 2. It communicates with Home assistant (hass.io) with a Mosquitto broker installed. Everything is running fine a few hours but then it crashes. This is the error message I get
The gateway config is this (hass.io is on 192.168.1.160). Tried with and without the irq-pin=15 setting.
./configure --my-transport=nrf24 --my-gateway=mqtt --my-controller-ip-address=192.168.1.160 --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-mqtt-client-id=mygateway1 --my-transport=nrf24 --my-rf24-irq-pin=15
-
@joakim-johansson This ssems to be a Raspberry Pi issue, so I added it to the topic. Not my specialty, but maybe @marceloaqno can take a look?
-
What version of mysensors are you using?
-
@gohan The development branch
-
@joakim-johansson I'll need you to run mysgw through gdb to gather more information about this problem.
Please follow the steps below:
-
Stop the mysgw service:
systemctl stop mysgw
-
Start a new linux screen: (or any other windows manager)(You can find more information on how to install and use screen here: http://raspi.tv/2012/using-screen-with-raspberry-pi-to-avoid-leaving-ssh-sessions-open)
screen
-
Run gdb with the path of your mysgw binary:
gdb /usr/local/bin/mysgw
-
Within the gdb, start the gateway passing the debug option
run -d
You can detach from the linux screen using “Ctrl-a” “d”.
This will return to the shell.
The gateway will continue to run, and you can re-attach it laterscreen -r
Now, you will have to wait for the gateway to crash again.
When this occurs, post the information printed on the screen.I'll prepare a more complete tutorial for this. Please let me know if you have any questions.
-
-
@marceloaqno a friend of mine had problems with the radio communication on the pi2 and now he bought a pi3 and all worked flawlessly. Could it be that there is a major issue with the pi2 hw?
-
@gohan I've had some segmentation faults on rare occasions in the past, but I've never been able to find the reason.
I'm suspecting that there is some bug in the class EthernetClient or EthernetServer that manifests in special conditions.