Losant JS MQTT Client not Emitting "offline", "close" or "error" Event

Help
1

I’m experimenting with using the JavaScript MQTT client instead of the REST client. I’m interested in using it because it offers automatic support for seeing when devices are connected to Losant. However, perhaps I’m misunderstanding what is defined as a “disconnection.” I am using this test program:

var Device = require("losant-mqtt").Device;

var device = new Device({
  id: "my-id",
  key: "my-key",
  secret: "my-secret",
  transport: "tls"
});

function send() {
  device.sendState({ bottlesRemaining: 0 }, function(err) {
    if (err) console.error(err);
    else console.log("Success");
  });
}

device.on("connect", function() {
  setInterval(send, 1000);
  console.log("Device connected");
});

device.on("offline", function() {
  console.error("Device offline");
});

device.on("close", function() {
  console.error("Device closed");
});

device.on("error", function() {
  console.error("Device error");
});

device.on("reconnect", function() {
  console.log("Reconnected");
})

device.connect(function(){});

I’m running this program in Node 4.2.6 on may laptop. However, even when I disable my laptop’s WiFi radio, the test program does not ever say “Device offline,” nor “Device error” nor “Device closed.” It seems to me that MQTT.js isn’t emitting any “problem” events, but I’m not sure how I could make it more disconnected :slight_smile:

Update: I should add that the program keeps printing “Success” every second, even long after the WiFi is off. I know that MQTT with QoS 0 can optionally buffer outgoing messages, and it looks like the buffering is enabled in the Losant client (by way of letting MQTT.js use the default option). However, I’m not sure how long the queue will grow, and in any event it seems like I should still see the “offline” event.

Thanks!
Travis

2

We’ve tested your code on our end, and we do get the “offline -> closed -> reconnect -> error” loop after turning off WiFi, but it does take 30 to 60 seconds. Can you try again on your end and give it a little time to see if you see those events firing?

The delay has to do with the underlying MQTT client not emitting those events on immediate failure.

As for still getting the ‘Success’ message after disconnection, the ‘err’ callback will only fire on ‘keepalive’ failure within the MQTT client.

Side note: You are logging “Reconnected” on the ‘reconnect’ event. This event fires when attempting to reconnect, not on successful reconnection.

3

Thanks for the note on the “reconnect” event. I tried the script again, but even after the WiFi is off for about 4 minutes, I still don’t see any indication that the state of MQTT has changed. After enabling the WiFi again, almost ten minutes later, I get

Device offline
Device closed
Reconnected
Success

I’m not sure why the delay is so long between the disconnect event and the resulting message.

4

These events are piped directly from the underlying mqtt library. I think a good approach for us is to wrap those with something more obvious/opinionated. Thanks for bringing it up, we’ll investigate better ways to expose them and more timely.

1 Like