The dataclay.contrib.mqtt.MQTTMixin class instantiates a client the first time send_to_mqtt is called, but the client loop is not properly instantiated. That means that this connection tends to be dropped after a while of inactivity and then the client is broken and send_to_mqtt ceases to work (silently, with no error).
Steps to reproduce
Start dataClay and start a MQTT server (order does not matter).
Make sure that MQTT_HOST and MQTT_PORT are correctly set. If running on localhost, 127.0.0.1 seems correct. If using a docker-compose, use the container name.
Register a class with the mixin, e.g.
class SomeClass(DataClayObject, MQTTMixin):
...
Create a instance of the class, make it persistent, try to call the send_to_mqtt method.
The call will work, you will see the message if you listen to the server.
Wait for an arbitrary amount of time without sending any messages (brew a coffe and wait 5 minutes).
Try to call again the send_to_mqtt. The call will silently fail, no messages will be published.
Possible solutions
Use the network loop that the paho-mqtt library provides.
I am not sure on the proper way of doing that. Trying to call reconnect might also work. I recall finding something along is_connected in the client interface, but I also recall it behaving funny and not being reliable. Maybe in addition to the loop we also need a reconnect callback: the system should be able to "survive" a restart of the server (which needs not only a network loop management but also reconnect semantics).
Desired state
10 minutes of idle time should not break the connection. (Send + wait 10 minutes + send again: both send operations should work).
Restarting the MQTT server should work (Send + restart MQTT server + send again: the second send should correctly send to the new server... it may be slow to reconect, but it should reconnect (it can be minutes, but it cannot be hours).
The
dataclay.contrib.mqtt.MQTTMixin
class instantiates a client the first timesend_to_mqtt
is called, but the client loop is not properly instantiated. That means that this connection tends to be dropped after a while of inactivity and then the client is broken andsend_to_mqtt
ceases to work (silently, with no error).Steps to reproduce
127.0.0.1
seems correct. If using a docker-compose, use the container name.send_to_mqtt
method.send_to_mqtt
. The call will silently fail, no messages will be published.Possible solutions
Use the network loop that the
paho-mqtt
library provides.I am not sure on the proper way of doing that. Trying to call
reconnect
might also work. I recall finding something alongis_connected
in the client interface, but I also recall it behaving funny and not being reliable. Maybe in addition to the loop we also need a reconnect callback: the system should be able to "survive" a restart of the server (which needs not only a network loop management but also reconnect semantics).Desired state