Create MQTT library


#1

Can anyone import the MQTT library from Arduino into XOD? This Protocol is now very relevant in the Internet of things. This module would be very helpful in implementing the Internet of things with XOD.


#2

Yeah, it will be nice. BTW, what library are you talking about? I found several MQTT libs for Arduino.

I wonder, what’s your most popular scenario of using an MQTT broker? I mean, what kind of projects you’re interested in. Is it a sensor network or, maybe, a remote control for some actuator?


#3

I’d also be very interested in an MQTT Lib and willing to help. Although i have literally no experience in C / C++.
But i guess i could get into it.

If we would collaborate on it - maybe we can get it done.

Best
Tobias


#4

<PubSubClient.h > the library works well on Arduino.
The MQTT makes it easy to integrate any device into a smart home by type Majordomo or Domoticz (I personally collect leak sensors with sensor modules from esp8266 (but there are no deep sleep libraries and EEPROM in XOD) and server-side value processing (OrangePiPC).


#5

Hi guys,
How could we proceed with this?

I was recommended paho
https://www.eclipse.org/paho/

Has you heard of it already?
Best Tobias


#6

Hi again,

@nkrkv i am going to plan an IoT system using MQTT. Basically it is going to be a network of several controllers for a heating system which is meant to be controlled remotely via MQTT.

So, can anybody of you can give me a hint on how i can start to implement for example PubSubClient.h into XOD? Is there any kind of documentation i can use to start porting the library?

Best
Tobias


#7

Not a big help, but the 1st step will be to copy the header file into the XOD install (usually <USER>\AppData\Local\Programs\xod-client-electron\resources\arduino-libraries). This will need to be repeated each time you re-install or upgrade XOD (there are on-going discussions about how to make this part easier).

The next step is to determine how the calls available in the header file should map to XOD nodes. If there is any one-time initialization that doesn’t need data passed to later calls, you might be able to put it in a separate node; otherwise you may need to put initialization in each node and store the data in State. The library gweimer/ir-remote/ir-read is a fairly trivial example of doing the latter. Since specifying port is tied to the initialization, initialization is only done if the port has not been stored, or it has been changed. Various function calls provided by the IRremote headers are then used to perform the desired action(s).

The built-in nodes for Real Time Clock (search for RTC to find the read/write nodes) provide another example that is probably closer to what you want to do as far as designing nodes for communication, but it uses I2C calls rather than header files.


#8

Hi gweimer,
this is big help for me.
Thank you very much as i got a clue on how to start.
I already was shown the ongoing decision process on github by nkrkv.

Anyways, thanks a lot again. I can dig deeper into this stuff.

Tobias


#9

Hi guys,
today we could make some progress on this.
We were able to include PubSubClient.h and make the first part of the basic example of PubSubClient work.

I now can receive a message sent from a basic xod node. Which firstly will only consist of a “not-implemented-in-xod” node.

In there we have global and state information that needs to be implemented in each mqtt node i guess.
Also, it runs the code for publishing “hello world from xod”.
A callback is meant to lead to receiving a subscription.
This was also implemented in the global area.
But I do not get the subscription message back.

All IN- and OUTPUTS are not used so far.

For communicating i use mosquitto broker and mqtt.fx as GUI.

I attached the .xodball in case anybody is interested and possibly can help.

mqtt_xod.xodball (4.2 KB)

Best,
Tobias


#10

I want to make the client connection accessible to other nodes.

At the moment the PubSubClient is called in the global area of the one node i created.

{{#global}}
EthernetClient ethClient;
PubSubClient mqttclient(ethClient); 
{{/global}}

a little bit further down in

void evaluate(Context ctx)

the IP addresses of the client and server are set.

I thought of defining a new datatype via output-self for the connection to the mqtt broker called mqtt. This type holds the connection to the mqtt broker. Similar to the inet datatype of w5500.

Is that the right way? Will the connection stay open once set up and be accessible for other nodes via input-mqtt?

I hope you got my aim.

Best Tobias


#11

I think you’re going in the right direction. I mean wrapping the PubSubClient into a new custom type. However, I would suggest to define the new custom type as a pointer to PubSubClient (in other words: PubSubClient*) and keeping the original object in the state of the node defining the type. That way passing the client around you will indeed share the same instance, not its copies.

From what I see, the task you’re trying to accomplish is quite similar to what @brusher_ru describes in the guide on wrapping Arduino classes.


#12

Thanks a lot for your answer.
I followed your release yesterday and am impressed again. I like the efficiency of your work and how you implement users suggestions and improve XOD continuously.

I also saw the guide for wrapping an existing library. I will get into it and keep on working.
Thank you @brusher_ru for the guide.
Thank you @nkrkv for the hint with the pointer.