Mqtt disconnects after message to response topic


#1

Hi

I started to implement the lua client (in nodemcu 2.1 firmware) for your mqtt service. Connection was succesful, sent some device info to /sys/model, /sys/version, /sys/cpu/model and /sys/cpu/speed. Subscribed to [..]/cmd/+ ok. I have a custom digital actuator (button) on my dashboard. When I press it, a message received as described in the documentation. I sent a feedback on the status change, then an ack to [..]/reponse topic with content ok,DHJEwELGqM9rGEn and then the server disconnects.

I reproduced this in mqtt.fx, so I maybe using the API in a wront way or wront command order?

Incoming message was: DHJEwELGqM9rGEn,1
Topic: v1/********-b980-11e6-ae5a-dfc2c3108b24/things/********-8d4a-11e7-a491-d751ec027e48/cmd/relay1
Ack response: ok,DHJEwELGqM9rGEn

Here is some log:

BrokerConnectorController      : onConnect
ScriptsController              : Clear console.
MqttFX ClientModel             : MqttClient with ID ********-8d4a-11e7-a491-d751ec027e48 assigned.
SubscribeController            : onSubscribe
MqttFX ClientModel             : rebuildMessagesList()
MqttFX ClientModel             : attempt to addRecentSubscriptionTopic
MqttFX ClientModel             : addRecentSubscriptionTopic : de.jensd.mqttfx.entities.Topic@be24614
MqttFX ClientModel             : attempt to add PublishTopic
MqttFX ClientModel             : sucessfully subscribed to topic v1/********-b980-11e6-ae5a-dfc2c3108b24/things/********-8d4a-11e7-a491-d751ec027e48/cmd/+ (QoS 0)
MqttFX ClientModel             : messageArrived() with topic: v1/********-b980-11e6-ae5a-dfc2c3108b24/things/********-8d4a-11e7-a491-d751ec027e48/cmd/relay1
MqttFX ClientModel             : messageArrived() added: message #1 to topic 'v1/********-b980-11e6-ae5a-dfc2c3108b24/things/********-8d4a-11e7-a491-d751ec027e48/cmd/relay1'
PublishController              : publish
MqttFX ClientModel             : Error publishing to topic: v1/********-b980-11e6-ae5a-dfc2c3108b24/things/********-8d4a-11e7-a491-d751ec027e48/reponse
org.eclipse.paho.client.mqttv3.MqttException: Connection lost
	at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:146) ~[org.eclipse.paho.client.mqttv3-1.1.0.jar:?]
	at java.lang.Thread.run(Thread.java:748) ~[?:1.8.0_131]
Caused by: java.io.EOFException
	at java.io.DataInputStream.readByte(DataInputStream.java:267) ~[?:1.8.0_131]
	at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:65) ~[org.eclipse.paho.client.mqttv3-1.1.0.jar:?]
	at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:107) ~[org.eclipse.paho.client.mqttv3-1.1.0.jar:?]
	... 1 more
MqttFX ClientModel             : Broker connection lost: Retrying...

#2

Unfortunately there are some server related issues right now so I can’t say for sure it’s something you/the library is doing wrong or if it’s the server issue. I’ve never used lua to program my ESP’s (always just use the Arduino IDE) so I wouldn’t be much help on that front. If you share your code maybe someone with more experience there can help, or at the very least I can try to get it running.


#3

Hi Adam

Thanks for your feedback. I’ve drop the lua layer to test the mqtt communication and using the MqttFX app. Have you got a service status page? So I can recheck this is if all servers goes to green.


#4

No service status page that I know of. @rsiegel Anything you’re aware of?


#5

Hi @adam,

Apologies for my delay here. We don’t have any public facing server status page at the moment. This is something I’d like to see implemented in the future but I’m not aware of any current plans to do so.


#6

Hi there,

If it helps, I’m having the same issue, working with node-red-contrib-cayenne-mqtt-client.

When sending any command from cayenne Web Dashboard or android App (switch 0/1), the command is received but all mqtt cayenne nodes in the flow disconnect immediately, and reconnect after a while.

I can handle with that, but have to wait 10-15 seconds approx. until being able to send the next command from cayenne. Thus, I have to be careful not to change anything in the dashboard while recovering connectivity, just to keep consistence of the state of the channels.

Regards,


#7

I had the disconnects too, but i was manually sending the data with the MQTT node. I think it’s the way the mqtt node works, it creates 2 connections, 1 for incoming and 1 for sending, and the Cayenne servers do not like having 2 clients with the same client ID connected… Try using only 1 MQTT node and see that makes a difference.