Changed the topic type from Question...
Good announcement, including the link to MQTT explanation (some people think everybody knows the exposed topic...).
Out of curiosity, how do you use your library? You need some MQTT device? You use it for inter-computer or inter-process communication? (I have only glanced at the site, I admit...)

I don't know if there's any point in using MQTT for inter-process comm (even though it's definitely possible). It's a very small footprint protocol but it feels a bit bulky for that purpose, of course there are variants to the standard MQTT spec defined specifically for different contexts. It's definitely more used for device-to-device communications.

My guess is that it's mostly used in sensor networks where you want an application to hook in to live streaming sensor data (such as wind, thermometer, etc.). Personally, I have some ideas of android applications (two of them are semi-done) where I want one user to push messages to another users android device; in this sense a "message" is simply data and not a string from a chat session.

For example; old aunt Agda might fall, the accelerometer on her phone detects that a fall has happened so it alerts her relatives living nearby (without costing money for text messages or phone calls) - or something like that.

Sound cool! Thanks for the information.

Hello, I am trying to use the MQTT4Processing library. Running the example files, the only thing that happens is this:

You try to use it with what kind of device?

I think it's because you're trying to connect to your own computer without having an MQTT broker installed and running on it. Perhaps I should clarify that further in the documentation...

Try changing the host ("127.0.0.1") to "test.mosquitto.org" instead.

Also, you should experiment with the delay in the setup, the one that is just before the "subscribe" call. Since test.mosquitto.org is not on your local network (I just assume...) it'll take some time before you're actually connected; and calling any "subscribe" before you're connected won't do anything.

I will add a nicer way for this in the future, f.ex. having a standard method called "void subscriptions()" or "void connected()" where all subscriptions could be called as soon as you're actually connected. But I haven't decided on the most appropriate way the API should look yet.

Also, the effects of running this in any other platform than standard processing is undocumented. =)

You're welcome to try it with Android! I haven't yet... but I fear that will render a bunch of threading problems. At some point I'll make an android version with a service for processing - when I've ironed out the bugs in my current project.

Thank you for the responses.

Yep, I can see the issue now. I have been working with the idea that most people will want to subscribe to only simple topics (no subtopics). This will immediately become an issue with the COSM framework since it works with a large hierarchy - for example: /v2/feeds/<feednumber>.json - and you can't declare a method with that name.

1. void /v2/feeds/40318.json(byte[] payload){
2.   // Do something
   
3. }

So, bottom line is I'll have to fix this in the library, so that it doesn't expect the subscription method to be the same name as the subscribed topic. I'll do that today!

I've updated the library now, and added a working COSM example to it.

Wow, thank you so much!

I hate to push my luck here because you have been incredibly helpful. I am able to change my connection properties in my Processing sketch to the proxy settings of my network, this allows me to make Cosm API requests through the standard API. This does not however work with the MQTT Cosm API. I'm not sure if this a question for Cosm, Processing, or my network admin. Figured I'd throw it out there though. Apologies for hijacking the thread, although it could definitely be related to the library itself.

Don't worry about it.

I added more debug messages to the lib, to see what is happening. Download the newest version (again), and add this line to your code.

1. mqtt.DEBUG = true;

It should look something like this.

1. MQTT mqtt;
2. void setup() {
3.   mqtt = new MQTT( this );
4.   mqtt.DEBUG = true; 
5.   mqtt.connect( "test.mosquitto.org", 1883, "my unique id" );
6. }
7. void draw() {
8. }

Let me know if you get some weird errors or warnings.

This is what I get whether I set the proxy settings or not.

It could be the port - 1883. Make sure that is open in your firewall/proxy.

There was a problem in the way the buffer was decoded into an MQTTMessage, it's resolved now and should work better. Unfortunately GitHub have removed the possibility to host files so I haven't been able of updating the library download yet... but you can find it in the "distribution" folder.

Until I've had a chance to put up a collective website for all my libs you'll have to endure with downloading updates that way. =)

Hi,

Hi, 

OK. I'm not a java expert, but checking the MQTTMessage.java file, it seems the output I'm seeing is the expected behavior, and therefore if I want to do something with the payload I need to extend the MQTTMessage class. Is this correct?