I’m learning a bit more about MQTT and thought I would get Electric Imp’s opinion on this.
One thought I was having is that MQTT makes sense at a device level in that it is suppose to be a low overhead method to get data out of a device. It also has the nice publish/subscribe model. In the case of the IMP though, you’ve cot the device/cloud connection taken care of, so does it make sense to do MQTT from an Agent to some other online service? Is it even possible to do MQTT in the Agent?
MQTT at a device level is a little pointless IMO. It’s all lightweight… but has zero security, so they suggest you run it over TLS, at which point it’s really not much lighter than, well, the imp’s protocol, which allows you to implement pubsub plus other comms models at will. As MQTT is so minimal, most end up implementing lots more stuff outside MQTT (generally inventing new protocols along the way) to actually make a shippable, maintainable, securable product.
We are looking at MQTT in the agent as this could help some cloud integrations, but no dates or promises at this point. There are various established messaging standards beyond MQTT and we’re looking at which ones could be supported there - some of this is customer-driven. The nice thing about doing this in an agent is that you aren’t burdening the device at all 
Thank you Hugo.
I see what you are saying in that MQTT is light and that a full operation would need to add in the other ingredients to make a full solution. MQTT from an Agent to other web services may be the way I was thinking of using MQTT, but I don’t have to have it. I’m sure you will keep us posted on roadmap for Electric Imp Agent development.
MQTT can be quite handy in many use cases. The issue here is how best to implement.
Case 1. Let’s say for example, you wish to contribute NO and NO2 data to an open data set (many public bodies already do this) as your imp device is already capturing this data for some other reason. Let say you have an option to publish your data to the public broker handling this data set via MQTT. Typically the broker does get to “see” where the published data has come from. I would say in this scenario you may not want to provide visibility from your imp agent or device so in this case I would want to use a peripheral device / module attached to an imp device to do this for me. This way you have at least hidden your imp network from a public mqtt broker.
Case 2. Let’s say you are using imps attached to water temperature sensors at a local public swimming baths. You decide to make this data public. MQTT is probably the easiest method to implement so decide to set up your own broker service where the public can subscribe to to get the temperature data feed. In this case I see no problem for imps to publish data directly to this broker as you are in control of this broker. The question then, assuming it were possible, is whether it is simpler to do via imp device if broker is local or only handle via agent.
Case 3. Let’s say you want to subscribe to some public data set which is offered via MQTT as you need to use this data with your imp application. In this case you would want your agent to do this as it is best placed to handle the data security side.
Case 4. You want to capture a huge data set which is being sampled at high frequency but you don’t want to / aren’t able to store at device level. I believe MQTT offers the best method to offload this data (as in publish it) elsewhere into better infrastructure that can store this data for you i.e. a broker.
Maybe there are other scenarios that @hugo and others have considered or maybe there are other ways to implement my case examples. Would be interested too to learn other opinions.
Thank you Gerriko for laying out the cases like that. That is helpful for me to understand different reasons to choose MQTT.
For the application I’m thinking about, I think I fall into case 4. But I can’t say there is a limitation in the method through which Electric Imp works now that MQTT would be better. Although I haven’t tried throwing much data out yet. I may find limitations that are more of a RESTful API to an outside storage service than anything Imp specific. Even then, maybe I would use a web socket, if possible.
Websocket support in agents will be arriving way before MQTT
One thing that I would use MQTT for is a real time connection between a web application running in the browser and the agent (server side).
I’ve used MQTT because it easily connects over websockets. What is the current solution to this problem with Imp? I’ve read a little about long polling but is there anything else?
Really it’s just long polling right now, which is pretty real time but unless you run multiple connections, the re-establishment time can make stuff “lumpy”.
With websockets you could then implement MQTT in a lib, I guess, allowing you to use existing browser MQTT implementations. You could just push JSON back and forth too, though.
Yeah, I’m fine with just websockets, they just happen to come free with the MQTT broker that I use (Mosca).
I think its kinda kludgy but I’ll make a Http to MQTT bridge in NodeJS.
Node-red has an imp input if that helps.