January 30, 2014
From the website http://www.mqtt.org
MQTT is a machine-to-machine (M2M)/"Internet of Things" connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium.
December 29, 2014
December 30, 2015
It would be nice if you could add MQTT support for thingspeak - e.g. that my IoT devices could publish and subscribe to topics using MQTT. This is very lightweight and easiest way to update topic feeds and receive updates from thingspeak apps.
You don't have to implement any API, as MQTT is supported already by many platforms, just provide ability to either connect to your MQTT broker, or thingspeak should act like a MQTT client, connecting to any online MQTT broker as client.
January 2, 2016
This would be a great feature to have, as MQTT has become something of a standard, and ThingSpeak provides complementary functionality (the ability to archive and graphically display data). It would be wonderful to be able to have ThingSpeak "subscribe" to an MQTT topic on a given broker and display and archive the data that comes in.
March 10, 2016
Hello, maybe I have sollution: http://community.thingspeak.com/forum/thingspeak-apps/mqspeak-mqtt-to-thinkspeak-bridge/
Thank you for your feature request. The development team is actively investigating support for MQTT protocol in Thingspeak. It will be very helpful to the team to get additional details of your application; Specifically, your anticipated workflows, performance requirements, and details about how you intend to use MQTT support. Please write to firstname.lastname@example.org and someone on the development team may be in touch with you directly.
January 30, 2014
Holy smokes Batman! When did this happen? https://au.mathworks.com/help/thingspeak/mqtt-api.html
Seems like its publish-only at this stage (no documented way to subscribe to a channel) but still a big step forward. Good work guys
August 22, 2015
Sharp eyes -- we went live yesterday with this. And yes -- It's MQTT publish only at this point.
All the best,
May 7, 2016
Here's the documentation: https://www.mathworks.com/help/thingspeak/mqtt-api.html
Users with free thingspeak accounts can only push data to a channel once every 15s. That holds true via the REST API and the MQTT API. The MQTT publish service is a Quality of Service (QoS) = 0 level API. There is currently no difference in the MQTT API for free v/s paid accounts.
December 7, 2016
First of all, thank you very much for implementing the MQTT publish.
In my tests I have however noticed, that the server ignores Keep Alive values of greater than 60 seconds (technically speaking greater than 40) and drops the connection after short below 60 seconds of inactivity. The same is true for sessions with a Keep Alive value of 0 (i.e. disabled).
This is standard-conforming behavior, as the server is allowed to disconnect at any time, regardless of the Keep Alive. However, it is not really nice regarding low-power applications, as one of two things currently have to happen:
- A Keep Alive of less than 60 has to be chosen and the client device has to wake up and send a packet every 55 seconds (to be safe). Or
- For every data packet with a period of greater than one minute, a new TCP connection and MQTT session have to be established.
This is would normally not be necessary, as TCP connections are able to stay inactive yet connected ("established") for hours (days, really). In fact, TCP itself knows no idle timeouts at all but has the capability of sending keep-alive packets on its own.
So, I would like to request considering to significantly raise the server-side timeout, or even better adhere to the Keep Alive requested by the client. If there are any concerns that led to implementing this extremely short timeout (e.g. fear of DOS attacks), I would love to hear about them.
For the time being, I recommend to all users to set a Keep Alive value of 55 seconds or less in their clients. Quite a few implementations seem to use a default value of 60, which is nasty in this case, as it is just over the threshold and will unfortunately lead to a full reconnect every minute instead of just a ping.
Anyway, thanks again for the MQTT implementation and maybe someone is able to sort this out.
October 21, 2016
This being our initial release of the MQTT service, we had to make some trade-offs in our broker configuration. This is because we don't have an infinite number of TCP sockets on the broker. We want to give everyone a chance to try it out. So that means, at this time at least, the client connection time with the broker is limited. For now, MQTT clients should connect -> publish -> disconnect. Once we get some usage data from the broker, we'll be able to optimize where we can.
December 7, 2016
Thank you for the quick reply and the clarification. I understand your point. I have seen that the service is based on AWS but did not know how scalable the architecture of your implementation is. Maybe you could add some hints regarding the recommended use to the documentation. The provided examples sort of suggest a continuous connection.
Anyway, thanks again for the MQTT service.
Most Users Ever Online: 114
Currently Browsing this Page:
Guest Posters: 1
Newest Members:BarryMaync, ThomasRougs, DonaldGen, prince, JrGordon, Elamsweems
Administrators: Hans: 387, lee: 457