Hello everyone…
I have just released M2Mqtt, a new MQTT Client Library on CodePlex at this URL https://m2mqtt.codeplex.com/.
Inside the solution there is a specific project for .Net Micro Framework !
Paolo.
7 Likes
@ paolopat - Thank you. This is very interesting.
Nice job. That looks like a substantial effort. Thanks!
Thanks for sharing,
but how would this be used? I mean don’t we need a server?
basically how would I make TWO boards talk to each other for example?
an example would be great…
thanks.
@ Jay Jay - I read the MQTT spec yesterday, and also some related sites online, and it seems that MQTT is designed to work with MQTT gateways and brokers. There are several open source versions out there if you want to install your own. The protocol itself is very lightweight, and ideally suited to Sensor Area Networks running over RF, TCP/IP, or other networks.
Spec: http://mqtt.org/MQTT-S_spec_v1.2.pdf
Info: http://mqtt.org/
Thanks Jasdev 
too bad it requires a broker/server
I though this could be used to have a standard way for sensors to talk to other sensors and board to board communication instead of board to cloud/server to sensor and vice versa.
i’ll stick to UPNP for now.
Cheers
@ paolopat - Nice job, tried it lately and looks good.
Even though the .NETMF project is configured for version 4.2 it can be compiled for 4.1 if the conditional compilation constant is set accordingly.
I also tried it with the FEZ Panda 2 and the FEZ Connection Shield (that’s why I compiled it for 4.1), but this does not work because the FEZ Panda 2 uses the networking libraries provided by GHIElectronics instead of the “normal” .NETMF networking classes.
So I’ve modified my local copy of M2Mqtt to support networking in a more flexible way, which then can be used with the GHIElectronics networking library, too.
I’m willing to share this code, so if interested, please leave a message.
Looking forward to seeing interesting projects based on Mqtt and the .NETMF platform.
[quote=“Nils”]So I’ve modified my local copy of M2Mqtt to support networking in a more flexible way, which then can be used with the GHIElectronics networking library, too.
I’m willing to share this code, so if interested, please leave a message.[/quote]
Hi, I realise this was from 6 months ago, but I’ve been using MQTT, including the M2MQTT library posted at the start of this thread running on a Netduino 2 Plus, and would be very glad to see amendments so it worked OK with Gadgeteer too. MQTT is proving an extremely versatile protocol for the IoT world, particularly in conjunction with the new Node-RED visual integration server and Mosquitto broker.
1 Like
@ Nils - Hi Nils !
Good work !
Can you shared your changed in source code with community ?
Paolo.
@ RorschachUK - I’m happy to know that my library is useful. Can you share your case study ? Not your source code application but only application domain. I’m so curious to know where my library is working.
Paolo.
@ RorschachUK - Very interesting!
Hi, case study’s perhaps an overly grand title for my home automation / integration experiments! But, I’ve got Mosquitto and Node-RED running on a server in my home, with a ragtag assortment of Internet-of-Things widgets connected and mostly passing data around by MQTT. I like this architecture for two reasons: firstly MQTT makes it extremely simple to decouple resources, so can trivially change implementations (can get MQTT running on Arduino, Netduino, mbed, Raspberry Pi, Beaglebone Black), and can add and remove devices in and out of the network painlessly. Secondly it’s not sending out to ‘the cloud’ e.g. Xively or Open.Sen.se or Electric Imp unless I want to - it’s my local decentralized cloud and I can run it on a closed network if I want to.
Your library is currently running on a Netduino Plus 2 board with a Jimmie P Rodgers LoLShield on it, acting as a text message scroller. On power-on, it connects to my Mosquitto broker and subscribes to a topic called ‘sign’. Within Node-RED I’ve got various feeds channeling into this topic, for instance temperature triggered messages from sensors elsewhere on the network, weather data from free weather APIs, parsed from JSON into simplified reports, Twitter searches for keywords about IoT, MQTT or Node-RED, etc. I use the ‘retain’ attribute on MQTT messages so that when the Netduino switches on it retrieves the last message posted to the topic automatically. Node-RED makes it easy to visually pipe data around from different sources to different destinations, including ad-hoc servlet processing in Javascript for parsing, processing and making decisions.
I had a brief go at getting it to work for a FEZ Spider myself but wasn’t successful, presumably due to competing definitions of the networking APIs. Would like to see it working on Spider & Gadgeteer networking as the T35 screen and Glide library would make a good monitoring and control hub for home automation - and again the MQTT decoupling means that all such control actions and monitoring feeds could also be accessed through a web page, Android app, or alternative physical hardware implementation using steampunk brass gauges and levers if we like, without needing to change a thing on the back end.
4 Likes
Sure, but as it was mentioned before, the code is a fork from more than 6 months ago, and I recently recognized that you heavily improved to code to support IPv6 and SSL, so I would have to fork it again and add my modifications.
(I actually could do that but I currently cannot test my modifications on real hardware so I’d rather not implement it into the blue.)
Second, your code is highly portable between the .NET versions, and when I changed to code to work with the GHIElectronics networking library, I need to add those as references, which would break the portablitiy of the projects.
Anyway, I’ll have another look at my modifications and your current code, and maybe I can find a way to suggest slight modifications to allow an even more portable use.
@ RorschachUK - I’ve been reading up on Node-RED after seeing your post. It looks very interesting, and it seems like it would be a great tool for scripting a home automation system. What has your experience been like? Would you recommend it?
For hobbyist experimentation, definitely. For something you need to rely on, not yet - it’s very new and is under fairly energetic active development, new features are appearing faster than stable well-tested releases at the minute.
I’d also run it in conjunction with Mosquitto MQTT server, and structure all your home automation stuff to pipe through Publish/Subscribe topics - so all your sensors publish straight to a relevant topic, any logging or writing to spreadsheets or databases comes in via posts to those topics, any decision-making controls, dials, switches etc write to a topic etc - that way if something goes awry somewhere, a battery runs out, a connection is lost, something breaks, the rest of the system carries on oblivious, and a replacement can be knocked up that writes to the same topic even if it’s a completely different bit of kit. Doing things this way also helps keep the device-specific code as generic and re-usable as possible, so that for instance sensors can report their readings to a topic, displays can read and display from a topic, and neither really need to know how they fit into the grand scheme of things at all - which can be changed around on the server via visually plugging and unplugging virtual connections.
@ RorschachUK - Yes, I agree, the pub-sub architecture is the way to go, and it seems that Node-RED fits into that architecture very well.
One of the issues with pub-sub is that (in most implementations) the publishers of topics define and create the topics, and subscribers need to know that the topics exist.
For example: A lamp device in the kitchen would publish a topic such as “kitchen/lamp/status” to let the world know its on/off status. Subscribers, such as a logging application, would need to know that “kitchen/lamp/status” exists in order to subscribe to it. Conversely, the kitchen lamp would subscribe to topic “kitchen/lamp/control” to receive “on” and “off” commands from switch devices that publish to that topic.
I think one of the advantages of a tool like Node-RED, is that the kitchen lamp could output status messages, and these messages could be connected to a logging application as inputs. As long as the format and content of the messages are standardized between the devices, they can talk to each other without needing to know any device-specific information, such as location.
MQTT also supports the notion of a ‘last will and testament message’, whereby a client can tell the server a message to be published by the server in the event of it losing contact with the client - so for instance, your lamp or other widget might have a kitchen/lamp/connected topic, and on connecting and subscribing could set this to true, but with a last will message to change it to false if the connection’s lost. Node-RED could then track which of its devices are currently accessible or not, maybe send off an email or other notification if intervention might be required.
There is an update to 2.4.0.0 version on my MQTT client library.
All details to this blog post :
1 Like
@ Nils - Hello Nils, I’m interested in your port of M2MQtt to 4.1 and GHI libraries. Can I get a copy of this?
thanks
@ Nils
Hi Nils…now my M2Mqtt library is at 3.3.0.0 version on CodePlex.
I addede an IMqttNetworkChannel interface to abstract underlying network communication.
Have you already worked on your copy of my M2Mqtt library using GHI network library ?
Paolo.