Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
I came across this today - MQTT (Message Queuing Telemetry Transport) - still trying to work out what it really is but initial thoughts are that this is something that could be added to CQC if it is big enough.

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.

MQTT is a Client Server publish/subscribe messaging transport protocol. It is light weight, open, simple, and designed so as to be easy to implement. These characteristics make it ideal for use in many situations, including constrained environments such as for communication in Machine to Machine (M2M) and Internet of Things (IoT) contexts where a small code footprint is required and/or network bandwidth is at a premium.
The protocol runs over TCP/IP, or over other network protocols that provide ordered, lossless, bi-directional connections. Its features include:
· Use of the publish/subscribe message pattern which provides one-to-many message distribution and decoupling of applications.
· A messaging transport that is agnostic to the content of the payload.
· Three qualities of service for message delivery:
· "At most once", where messages are delivered according to the best efforts of the operating environment. Message loss can occur. This level could be used, for example, with ambient sensor data where it does not matter if an individual reading is lost as the next one will be published soon after.
· "At least once", where messages are assured to arrive but duplicates can occur.
· "Exactly once", where message are assured to arrive exactly once. This level could be used, for example, with billing systems where duplicate or lost messages could lead to incorrect charges being applied.
· A small transport overhead and protocol exchanges minimized to reduce network traffic.
· A mechanism to notify interested parties when an abnormal disconnection occurs.

So its M2M 7& IoT, but its being used in other competitors software as a way of communicating with a lighting system.

Has anyone heard of this before and know anything about it?
Mykel Koblenz
Illawarra Smart Home
AMQP is a much better protocol for this purpose. MQTT is being used on some small devices (especially Zigbee) because it's a bit more lightweight, but AMQP is more useful (and featureful). Many AMQP brokers can accept MQTT inputs, so I'd think it would be better for CQC to support AMQP if it were going to implement a messaging protocol.
For us, the only reason we'd implement such a thing is if we needed it to support some devices. We'd have no need for it internally or anything. What sort of breadth (and usefulness I guess) of device support would we gain by supporting it?
Dean Roddey
Software Geek Extraordinaire
So the way things work now, there are assorted sensors and programs that support sending MQTT messages. The user has to install a broker locally (most people using MQTT for IoT use Mosquitto on a Pi) or use one on the cloud. The sensors send messages to the MQTT broker and the broker then either does something with that data or forwards it on to some other place. What CQC would do would be connect to the broker and say "forward to me all messages relating to SENSOR/HOUSE/PERSON/whatever". Then CQC could perform actions based on that data.

My point was that since the user has to run a broker anyway (unless you want to build a MQTT broker into CQC), and most brokers support MQTT and AMQP, it would be better for CQC to speak AMQP. As an added benefit, this would provide CQC with another standards based way of communicating with other devices/programs.

Here's how Home Assistant gets data from a particular MQTT source (and generic broker):
And here's how to get sources from to speak MQTT:
And here's how to use Arduino sensors with OpenHAB over MQTT:
Popular general purpose DIY library for MQTT/IOT:
I am waiting for an ESP8266 to turn up - my plan is to use this as a cheap interface to stuff like the dryer, dishwasher etc. A way to roll my own IoT.

One of the links skarsol has above (homie) uses has an implementation for the 8266 which is using MQTT.

So depending on how testing goes, this could mean that the ESP8266 with CQC could be a good match.

Still learning all about this but conceptually at the moment, CQC would be a MQTT broker (or AMQP if MQTT is a subset) and then the IoT device can connect directly to CQC.

Sounds like we have some knowledge here and may be able to get something going.

On a side note - its not big here, but Halloween with these ESP8266's looks like a great match. At ~$10 for a board, if you can add them to any of the animated decorations you can automate your whole Halloween for very little cost and it may be a market that CQC can attract at this time of year. Just thinking aloud
Mykel Koblenz
Illawarra Smart Home
There's no reason for CQC to implement a broker, it just needs to be a client. Lots of perfectly good stand alone brokers. I'm partial to RabbitMQ.
Also, here's a recent post discussing some heavy lifting in the DIY HA space using MQTT:

I'd imagine a pro installer that wanted to get seriously custom could do some really cool things with it.
skarsol Wrote:There's no reason for CQC to implement a broker, it just needs to be a client. Lots of perfectly good stand alone brokers. I'm partial to RabbitMQ.

But that is another application to support. A new RPi (or VM or other), with software to install and support. I could be running C-Gate on a Pi for C-Bus, plus the Squeezeplugs on the Pi. How many Pi's do I need (I could be up to 6 bu now)

My net is shaped so I cant go searching on the details of Rabbit (or mosquito) to see if they run under windows, but if ther eis a broker that runs under windows then it could be on the CQC MS I suppose.
Mykel Koblenz
Illawarra Smart Home
Plenty of Windows brokers.
Did anything ever come of this?  

Dean, here is at least one really good reason why an AMQP, MQTT, or STOMP messaging client driver would be a good thing: A SmartThings MQTT Bridge  and here is an article about bridging the SmartThings Hub to Home Assistant via MQTT.  A messaging client driver would open up a direct interface between the SmartThings hub, all of it's devices and CQC.

By having a messaging driver & support back end to process device event messages this would be a significant improvement in capability to CQC!!!   Regardless of which CQC client driver protocol is chosen with a RabbitMQ broker in the middle to translate between any one of the 3 protocols you would exponentially increase the number of devices and other external processes that CQC could interface with.  We're talking some serious capability and flexibility here that is open standards based.

Forum Jump:

Users browsing this thread: 1 Guest(s)