Help set up mosquitto on hass.io

hello guys

I have problem to set my mqtt
I install the addon mosquitto and set password and user name I use the link for help https://home-assistant.io/addons/mosquitto/

I edit the config.yaml

 `mqtt`:
  broker: my raspberry pi 3 (ip add Address)
  username: my user
  password: my password

but I cant get it work

can some on help me I am new on hassio so step by step will be great

note
I using dns to Access my hassio,but I like mqtt will be local

Please post your config properly formated using </> on the textbox

Without posting your config it is hard to say anything.

But you may try to add:

port: 1883
client_id: any name
keepalive: 60

Can you give me instructions how to check if the Mqtt work ?

in the chrome extension/app store, mqttLens is my favorite

Please post your config properly formated using </> on the textbox

It looks like you have quotes around mqtt and no indent spaces

add

logs:
  homeassistant.components.mqtt: warn

to your logbook.yaml (or add it in configuration.yaml if you don’t use a !include file), and then check your home-assistant.log
depending on the debug hunt, you can change the level of logging:
# Logger - Home Assistant
# Possible log severities: critical, fatal, error, warning, warn, info, debug, notset

if your comfortable with ssh’ing into hassio.local and are logged in, and are using the built-in mosquitto enter

mosquitto_sub -h ip-address -p 1883 -u username -P pasword -v -d -t '#' (obviously replace with your ip-address, username and password…)

and watch the events roll by :wink:

cheers,
Marius

Where will you connection be from? Are they all local or any from public IP?
If ANY are from public IP you need to set up a reverse proxy with SSL.
Mosquitto sends username and password in the clear.

for now mine are local, but im not 100% certain Hassio itself doesn’t publish anything in the open, so:

what would be the best config doing this reverse proxy.
btw, i have mosquitto setup with ssl, using the keyfiles.

Only other sender is Owntracks, which also is setup with ssl.

Cheers,
Marius

??

Unless your HASSIO instance is directly sitting on the open internet, it isn’t publishing anything out

that’s what i thought, and given the fact that ive setup mosquitto using ssl, i was somewhat surprised by

If your Mosquitto is not running SSL, you can sniff the traffic and see your user/pass in plaintext. Unless you are opening the port and actively connecting to it from the outside, nobody outside of your LAN can see it.

If you are running with SSL on it, you cannot see this, no matter where it is being used from.

1 Like

My bad. Let me say it a different way …
Assuming HASS.IO set the configuration based Options/Network. See below …
In your example

You are using port 1883. If that is local IP then you are ok. My understanding 1883 Is not SSL.
The 8883 is. So you mentioned own tracks. If you use it outside of the local network you need SSL or port 8883. You will need to configure owntracks security to use TLS and give it the correct cert perm. Also you might want to use a different port to let through the NAT.

Sorry for my added confusion. :slight_smile:

Hi @penright
Thanks!
I think you’re right about the port, this was just for logging purposes.
Still you’ve got me thinking about that and I will have to test 8883 cause I’ve set up that too.

I haven’t declared anything to publish other than several state streams inside Hassio/HomeAssistant.

All my Mqtt events are read from a local publisher …
My OwnTracks is setup securely as you suggest.

Not sure if this Hassio statestreaming is all secure, think it is, but I will do some further investigating !

And, no worries, not your bad, I’m here to learn and share!
Cool!

Btw, not sure what you’re saying about the NAT and using another port?

Marius

Hi @penrightsince we where talking ‘sending’

i was debugging my logs, looking for the culprit of my continuous max pending message error in the web socket api.
Hence i enabled the logger for this domain, in the debug level: homeassistant.components.websocket_api: debug

a fullscreen of all devices in system is displayed with all system events and state changes… Not sure if this is all fired into the mqtt streams, debugging doesn’t tell me this, but why is the system ‘Sending’ all these events, and, to whom…?

Is this the event-bus? Which would make it ok i guess.
oooh, it must take out most of the capacity in the Pi3 …

ive screened the first few lines in the logging console, at the end of the restarting process to give you an idea. This goes on and on, without ending.

maybe its another way of representing the same stream of events on the mosquitto log, but that at least is clearer and states it received PUBLISH, which it should obviously:

Client mosqsub|8158-core-ssh received PUBLISH (d0, q0, r1, m0, 'macaddress/energy-dsmr4/538d72d9/T1', ... (8 bytes))
70:B3:D5:6F:31:F2/energy-dsmr4/538d72d9/T1 9952.845

Anyways, hope you have more insights.

Cheers,
Marius

First, I am very new at this also, as always double check. :slight_smile:

NAT is Network Address Translation. You can google and get better and more correct :slight_smile: answers than I can give you, but here goes a 60,000 foot answer. If it was not for NAT IPV4 address would have ran out long ago. Most home internet connections have a public and private connection, hence the term rout. NAT also call port forwarding, takes that public address:port and passes to the local address:port that you set up. So for MQTT you would set up to pass 8883 to x.x.x.x:8883. There is nothing to keep you from doing say 18883 to x.x.x.x:8883. So owntrack port would be 18883 and NAT would handle it for you. The reason is if 8883 is a know port then it makes it easier for someone outside to discover you have a MQTT. Of course this issue is while you are out in the world then NAT would work, but as soon as you connected to your local network, say via wifi, then owntracks would still be connecting to the wrong port, so you would want both to match. They say it’s best practice to change default port that are expose to public IP. I would get it working first, then play it changing default ports. Up until recently I was double NAT, in other words my router outside address was not a “public” it was local to my internet provider (ATT Hotspot), but that is a different discussion.

Right now I am only using mosquitto for ontracks. If you have the TLS options enabled then you have to be using the SSL socket (8883). Does owntrack update when you are away from home? Are you using a MQTT cloud?

Not much help on this post, again all I am using MQTT for is broker for owntracks. I am using the home/away function and the component that converts gps to local address.

yes using 8883, and yes it is updating. never quite sure why i am using it though… i have various zones and am ‘zoning’ but then again, it was more because the possibility and fun of it.

you’re right about the port numbers, selecting anything but the default makes it a tiny bit more difficult to snoop around. Will try and test. This goes for the other port forwards too.

I am a heavy Mqtt user, that is, i have a zwave hub that is publishing the events, and my mosquitto setup translates that into these nice sensors and switches. Took a bit of setting up, but once you get the hang of it (such helped by @NotoriousBDG amongst other community members, it gets easier.
I have some very neat tools now to automate the Home, and thats what it all was about isnt it :wink:

Cheers,
Marius

Have you messed with google_geocode?

sensor:
  - platform: google_geocode
    name: Paul
    origin: device_tracker.test_mqtt_paul_cell
    options: street_number, street, city
    display_zone: display
    gravatar: [email protected]
    api_key: !secret google_map_api

No! Never heard of that before. Will check it out . You’re reporting good results on using it?

Yes.
Works great, unless you don’t want your wife to know where you are at . :grin:

2 Likes