What is Reddit's opinion of mosquitto?

From 3.5 billion Reddit comments

Assuming the new install of mosquitto is at v2.0.x then you will need to explicitly edit the config file to allow any connections not from localhost.

As part of a move to a more secure out of the box posture, the default config only allows connections from localhost.

Details in the release notes: https://mosquitto.org/blog/2020/12/version-2-0-0-released/

You need to add the following to the /etc/mosquitto/mosquitto.conf

listener 1883 allow_anonymous true

I suggest you start reading these two links:

https://mosquitto.org/man/mqtt-7.html

https://mosquitto.org/man/mosquitto_pub-1.html

That should cover the basics. For logging purposes, you can either have a subscriber to the topic log all the data or store it in a database. Data is only kept until they are delivered to subscribed clients. Node-RED or HiveMQ can do this for you.

A great way to send messages between esps and other devices would be MQTT, but that requires you running a MQTT broker/server somewhere or subscribe to a cloud service (well worth it though, https://mosquitto.org/runs great on an old raspi)

If you choose this road, you can publish messages to a certain topic (like myhome/pirsensors1/something) and have other devices listen and react to these topics.

MQTT is heavily supported in most home automation systems if you ever want to it to grow bigger than 5 nodes, and even for the protocol being to light weight, it has a lot of very nice features like persistent messages, wills on disconnects and other things that is well suited for tiny devices.

I started using a webserver on my esp8266s and have them communicating by simple HTTP requests, but once I took it to MQTT i'm never looking back. :)

Specifically? I don't have a how to guide. But what I'd do is that I'd go and set up a MQTT server (https://mosquitto.org/) on a computer on my network (Can be a Pi, can run it as a background process on your main computer, whatever).

On the ESP8266 side I'd go and set it up to read the values from the sliders, much like it currently does in deej-arduino.ino, with the only difference being to replace the Serial.Write with a client.publish() call to the MQTT server.

On the receiving computer side I'd then go and modify the existing deej.py to subscribe to the mqtt topic (http://www.steves-internet-guide.com/into-mqtt-python-client/) and then rewrite the accept_commands() function to be a callback to the client.subscribe() function.

Or something like that, I'm studying right now so can't really give a full answer.

Oh it's really straightforward, the server is called Mosquitto and runs on any machine that has Python, including a Pi so your machine will have no trouble.

Just a heads up: the version of mosquitto in the default Debian repository tends to be out of date, so check out the instructions here: https://mosquitto.org/download/

There is nothing to manage beyond setting up the configuration file to your needs (see: https://mosquitto.org/man/mosquitto-conf-5.html). Clients publish and Mosquitto makes sure these messages all arrive where they are supposed to go to (your subscribers). Maybe this image helps:

https://i.ytimg.com/vi/JfWMC9Wh30k/hqdefault.jpg

Anything you want to happen on the arrival of a certain message, or logging the data, or analytics etc. are subscribers you need to implement. Your sensors etc. are publishers to a topic (which you don't have to create in advance) - see the links in my previous post.

Any device discoverable in Home Assistant is because Home Assistant is saw it and recognized it. Not because of MQTT.

​

For HA to use MGTT, you need a configured MQTT broker such as Mosquitto (https://mosquitto.org/ ). Devices communicate with the broker, HA communicates with the broker. But you need a MQTT broker for MQTT to do anything useful in HA.

Best practice is to not allow the device to be directly accessed outside of the LAN from the internet. Have access restricted to only be through the CI/CD or other API system to help make sure its usage is being audited and monitored correctly. If someone wants to send a job to it, that job should be processed through a secure API so access can be controlled, monitored and audited.

Best thing about doing this through a CI/CD system is you could also use that same system to deploy API updates for batch job software. You can use something similar to the following: - https://zeromq.org/ - https://mosquitto.org/

Or other technology to get the job done, this may also allow you to scale it up to additional Pi's if necessary down the road to increase automated job processing and other functionality as you see fit along with the ability to build central dashboards for it, view processed jobs at scale, etc.

If you're referring to the Community Plugin it's just Eclipse Mosquitto on FreeBSD. If the plugin is up and running, I would suggest reviewing their documentation and engaging their community for advice.

Heck, you might have luck with r/MQTT as well!

I don't think aedes supports security on channels from what I've seen, but you can look into ACL support for mosquitto https://mosquitto.org/man/mosquitto-conf-5.html if you want to see how it can be done.

You can look up the "Mosquitto" which is an open-source implementation developed by Eclipse. It could build the broker and clients and it allows you to enable ACL and TLS authentication(an encryption protocol based on pub/private keys) features. Here is the link https://mosquitto.org/

Hope this is helpful.

Sorry, didn't tell me of this response.

You can run the mosquitto server at home, or on the ISS's food processor for that mater.

The statically (no dependencies) link is at:

https://mosquitto.org/files/binary/linux/mosquitto-0.5.3-bin-lin-x86-static.tar.gz

Just:

wget https://mosquitto.org/files/binary/linux/mosquitto-0.5.3-bin-lin-x86-static.tar.gz tar xvzf mosquitto-0.5.3-bin-lin-x86-static.tar.gz cp mosquitto-0.5.3-bin-lin-x86-static/mosquitto_* ~/bin

Then change your path to include ~/bin (edit your .bashrc)

Once done the scripts will run.

You'll need to install the server, either as a cron script or at home.

PM me if you have issues.

--

The other choice is to rip out mosquitto and go with a third party, like push bullet

https://docs.pushbullet.com/#pushbullet-api

You can send and receive notifications via curl.

I personally find ROS very clunky. If all you need is the pub-sub functionality, then set up your own MQTT server using Mosquitto (https://mosquitto.org/, runs on any platform), and write a python script to publish and subscribe data. I've used https://pypi.org/project/paho-mqtt/ in the past, they have example code to get you going. This is a lot less work than setting up ROS in my opinion.

1. Install Valetudo
2. Connect it to an MQTT broker (you'll need to set one up, Mosquitto is popular)
3. Integrate with Home Assistant, or do it manually by connecting Node Red to the MQTT broker

The hard part is knowing when everyone leaves the house, not turning on the hoover.

you need a broker

you need one or more clients.

For the broker you could start with mosquitto: https://mosquitto.org

For a client you need to choose from a list based on your requirements: https://github.com/mqtt/mqtt.github.io/wiki/libraries

I would also highly recommend reading this blog post and all the others in the same "essentials" series: https://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt/ reading them in order is not a bad idea.

This is not really a noob solution per se, because Homekit is a bit tricky, but the way i would approach this is setting up a Homebridge "server" on your pc and have it broadcast mqtt commands (via homebridge-MQTT and mosquitto) over your wifi network. Those raw mqtt strings can be read by any ESP8266 device with simple pre made libraries and you can output to DMX using a Max485 board.

This solution is not nearly as plug-and-play as buying a dongle, and requires a pc (or ras pi) running but it's very cheap, modular, wireless, and 100% Homekit compatible (it would show up on your phone as a rgb/rgbw bulb).

Since the light would be controlled by any MQTT command, not only the Homekit UI, you could program arbitrarily advanced color animations or responsive effects and whatnot either by presaving them on the esp8266 or even broadcasting them in real time from another device, as mqtt is pretty quick.

Art-net/DMX-over-wifi dongles appear to exist, namely for controlling stage lights from your pc, so i guess you could have homebridge broadcast to those, but after a couple google searches it looks like it's mostly uncharted territory, and those dongles don't come cheap anyways.

This is the contents of my batch file. You'll need to put in your IP, mqtt username, mqtt password, topic and message as well as install https://mosquitto.org/download/

"C:\Program Files\mosquitto\mosquitto_pub" -h mqtt_host -p 1883 -u mqtt_user -P mqtt_password -t mqtt/topic -m "message"

Look around the house. What do they (or you) see that needs to be controlled and/or monitored?

Monitor examples: temperature, humidity, light, sound, occupancy / presence, status (door open/closed, device on/off), water level (fish tank, pet water), soil moisture, mailbox, etc.

Control examples: garage door, lights, stereo, TV, water flow (water plants, fill pet bowl), pet door (locked/unlocked), alarm system, heater, air conditioner, humidifier.

NodeRED and MQTT are good bases to build on. Mosquitto is a free, open source MQTT broker that runs on RPi and many other platforms.

​

Another project is creative ways to display information. A cube that changes colors and/or intensity depending on weather. Maybe one side is humidity, one side is temperature, one is precipitation, one is UV index, one is sunlight / sunset. What other data could you display with a similar device? Stock market? China virus numbers & trends? House occupancy (which rooms have people in them) using the sensors from above?

​

You could create a 'pinewood derby' type timer system using hot wheels or similar track and cars. Let the kids figure out how to time the cars, then help them understand the physics of car design / shape, wind resistance, weight placement, track shape (straight downhill vs. 'hockey stick'), etc.

There's a world of stuff out there ...

The server/broker thing is just terminology. A MQTT "server" is called a broker.

You can use any PC to host your MQTT broker as long as it has network connectivity and enough computing power (even the smallest raspberry pis have no problems running one).

The most popular open source broker is probably Mosquitto so you can be sure to find a lot of help online if you need it but I'm not sure if it runs on every major OS. Googling your OS name and MQTT broker should give you some options.

There is also the option of using a hosting service to run your your broker but that is a bit more advanced.

MQTT receive would be awesome indeed. See below for sending to MQTT:

1. Install Mosquitto (https://mosquitto.org/download/)
2. In Streamdeck - System: Open
3. App/File: "C:\Program Files\mosquitto\mosquitto_pub.exe" -h jarvis.gh.int -m "20" -t marantz/in/vol

This will set the volume of my old Marantz reciever (IR via GC-100-12) to -20dB

Separate boards for each sensor would be the way I'd go, although this does raise questions around power usage etc.

You might want to ask this question in /r/homeautomation and /r/IOT as well - the former will have lots of suggestions for pre-existing solutions, the latter will have suggestions on building your own.

As far as communicating between the devices over WiFi is concerned, I'd learn how MQTT works, setup a Raspberry Pi or Docker container on your home network running something like https://mosquitto.org/ and send all the data through that, this way all you need is something listening to the queue and pulling the data from MQTT before pushing it to a data store like InfluxDB or Elasticsearch.

If you use homeassistant.io for your automation stuff, it can listen to MQTT and show you the values in the same control panel as your lighting/media/etc.

For anyone in the future that finds this and has a similar problem, go to https://mosquitto.org/ and download the windows installer. This will install mosquitto_sub.exe which you can use to do this.

/u/chican3, thank you so much. For some reason, the switches that aren't working are reporting the stat as (for example) "stat/SaltLamp/POWER1" instead of "stat/SaltLamp/POWER".

This difference is evident in the configuration pages of Tasmota, so I've no idea where to change it, but I'll figure this out (or change the config file. Thanks so much!!

I haven't used this library yet, but it is a MQTT client for the esp8266. The only down side to this approach is you need some sort of MQTT server for them to connect to, but other than that MQTT is a lightweight and fast network protocol for both publishing data and subscribing to data feeds. You can find the server code here, or you can use up to 10 feeds for free from adafruit.

So far i have come to a state where i can send a message to a MQTT Broker(HiveMQ or Mosquitto )(btw MQTT Broker is running on an Amazon ec2 server) using a Python script. I also made an easy script on the Windows side to listen for a specific text at the MQTT Broker. I assigned an [[Activator]] gesture to trigger the script when I'm in a specific app(because i don't want to trigger the script everytime fingerprint matches. Thanks to [[ActIf]] for this addition.). The only problem I am having right now is I can't get the script to emulate the keyboard so it could type the password and login hopefully. I thought I should share the updates with you guys. I will make a full tutorial when I hopefully solve the problem I'm having the keyboard emulation.

Mosquitto and HASS are on the same machine? The quickest is to point Mosquitto at the same key+certificate you generated with Let's Encrypt. Then set up Mosquitto: https://mosquitto.org/man/mosquitto-conf-5.html

Well I've never used nodemcu, but I've used MQTT. An mqtt server(or broker as they call it) should be easy to set up on the raspberry pi. MQTT for node doesn't look too complicated. Or you could use their public test server if you don't mind your communications being public (should be fine for "light up this led" type stuff)

You run the broker on the rpi, run a client on the rpi (available for lots of languages or as standalone program), and a client on nodemcu.

I don't know about node-red, but it seems pretty user friendly.