Disabling MQTT Connection Control of Device Control Status

The data delivered to my application is done so from a third party. The content from my devices publish to that server first, and the data is forwarded to my Losant instance over a secure MQTT pipeline. I mention that because I don’t have control of how they implemented the MQTT publish infrastructure.
It appears to me that the third party does not maintain a constant connection to the Losant broker, favoring connect/release methodology instead. In this schema, the devices have a ‘disconnected’ status virtually all the time, except in the midst of data being published.

When I was using webhooks for publishing data, I was able to use the ‘connected’ attribute to control this behavior using payload arrival (connected) and inactivity (disconnected). That logic remains, but I expect it is over-ridden as soon as the 3rd party disconnects.

My question is, can I disable the automatic control for ‘connected’ status that I think is being handled by the MQTT handler and manage it directly?

Thanks in advance.

Sorry, no way to do that currently, but I’ll file a feature request for this. I’m thinking it will be a new top-level property on the device configuration that, when enabled, would turn connectionStatus into a manually set property only.

I will follow up if this is selected for development. Thanks for the suggestion.

Also, out of curiosity, if you were using webhooks to send this data over previously, why did you move away from that solution and to a non-persistent MQTT connection instead?

Our current pricing arrangement is predicated on using MQTT. I was under the impression the MQTT implementation on the Losant side was lighter than Webhooks, and thus influenced the pricing. Perhaps my impression was incorrect.
Thanks Dylan

TL:DR; I’d go back to webhooks if you can.

The main benefit of connecting to Losant’s MQTT broker is bi-directional communication with your devices. Additionally, MQTT broker connections are more lightweight (i.e. longer battery life and lower CPU usage) than making an HTTP request every time you want to report state. (This can vary depending how often you report and other factors, though.)

In your case, it sounds like your devices are making a request to a third-party service (over HTTP?) and then the service is forwarding the device data to Losant; therefore you are losing both of those benefits. The service in question is making a single client connection to Losant’s broker per device, and it is only holding that connection open long enough to make the state report.

So that means, in addition to losing a meaningful “connection status” for the devices, you are actually using three Losant billable payloads per device state report

  1. The device connection to the MQTT broker
  2. The state message published to the broker
  3. The device disconnection event

Whereas, assuming you are doing a single device state report per webhook request, that would be two payloads per state report …

  1. The webhook request
  2. The recording of the device state through the Device State Node

It would also count as a billable payload every time you wanted to update a device’s connection status to connected or disconnected, but I’m assuming that happens less frequently than per every report.

If payload consumption is a concern, you may be able to batch multiple state reports (for the same or for different devices) into a single webhook request. That would mean, for example, reporting a single device state for 10 different devices in one request would count as only 11 billable payloads (one for the webhook request, one each for the Device State Node invocations).