Yep! Actually will work not theoretically!
The device has the HA username and password configured and it uses that to connect to the broker.
@KDM you are WAY overthinking this!
Why would it be??? It will work perfectly well.
good to know.
you can’t fault someone for wondering…
1 Like
Of course! The broker’s just the middle-man! So, when did we tell HA the username and password to log into Mosquitto?
according to David you didn’t need to. It already picked every username/password combo that already existed in HA and put them all into the broker as valid log in credentials. Then HA just randomly chose one to use to log in.
Then you will also just pick any one of the already existing HA username/password combinations and use that in your devices so that they can also log in to the broker.
As far as I now understand it…
If you define a username and password in the broker, that is a ‘local’ user. If you don’t define a user/password in the broker, it will use a HA user. BUT the Tasmota configuration where you specify the ip address and username and password - that can be either a ‘local’ user in the broker or it can be ANY Home Assistant user and it will be allowed to log into the broker…
So if you use a HA user and don’t define anything in the broker, you just set a HA username/password in Tasmota.
Instead of the endless iterations, just try it!
What I did was to create a home assistant user with the same username and password I had previously used in the broker so I didn’t need to change anything in Tasmota. Then I reset the broker settings to defaults (ie no user/pass in broker)
There’s no pedantry here. at the need of the day, I have a working system which has been hacked together, with the results that I don’t know why it works. My biggest fear is that WHEN (because it swill) it all falls over, can I recreate it? Certainly not by the path I first followed.
Indeed… but it gets to the point that you just have to try it and see what happens… see what is in the broker’s log… then it all becomes clear but going around in circles asking the same questions isn’t helping you… or maybe it is… I’m not you. But you will learn more by doing it and inspecting the result. Look in the Tasmota console and the broker log and you pretty soon see how it works.
I learnt so much by parroting/doing what people suggested and then later I started to understand to the point where I can use the knowledge and docs to do it myself… I still get stuck occasionally of course (yes templates I’m looking at you) but by & large I can get stuff working easily. I have been using HA for almost 18 months now…
I’ve been struggling with this too on only a single device. I think I’ve tried every possible config scenario I know of to no avail. Using latest version of Hassio on Rpi3 w/Mosquitto, Sonoff Basic. Here is current config:
Sonoff console log:
17:26:53 MQT: Connect failed to http://myip:1883, rc -2. Retry in 10 sec
17:27:04 MQT: Attempting connection…
17:27:09 MQT: Connect failed to http://myip:1883, rc -2. Retry in 10 sec
17:27:20 MQT: Attempting connection…
17:27:25 MQT: Connect failed to http://myip:1883, rc -2. Retry in 10 sec
17:27:26 RSL: tele/sonoff1/STATE = {“Time”:“2019-02-06T17:27:26”,“Uptime”:19,“Vcc”:3.487,“POWER”:“OFF”,“Wifi”:{“AP”:1,“SSId”:“myssid”,“RSSI”:100,“APMac”:“mymac”}}
17:27:26 RSL: tele/sonoff1/SENSOR = {“Time”:“2019-02-06T17:27:26”,“Switch1”:“ON”}
17:27:36 MQT: Attempting connection…
17:27:41 MQT: Connect failed to http://myip:1883, rc -2. Retry in 10 sec
17:27:52 MQT: Attempting connection…
17:27:57 MQT: Connect failed to http://myip:1883, rc -2. Retry in 10 sec
17:28:08 MQT: Attempting connection…
17:28:13 MQT: Connect failed to http://myip:1883, rc -2. Retry in 10 sec
17:28:13 CMD: SetOption19
17:28:13 RSL: stat/sonoff1/RESULT = {“Command”:“Unknown”}
17:28:24 MQT: Attempting connection…
17:28:29 MQT: Connect failed to http://myip:1883, rc -2. Retry in 10 sec
HA conf.yaml entry:
mqtt:
broker: http://myip
username: myusrnme
password: !secret password
switch:
platform: mqtt
name: "Sonoff1"
command_topic: "cmnd/sonoff1/POWER"
state_topic: "stat/sonoff1/POWER"
qos: 1
payload_on: "ON"
payload_off: "OFF"
retain: true
My Mosquitto config:
{
"logins": [
{
"username": "myusrnme",
"password": "!secret password"
}
],
"anonymous": false,
"customize": {
"active": false,
"folder": "mosquitto"
},
"certfile": "fullchain.pem",
"keyfile": "privkey.pem"
}
Sonoff Mqtt config:
MQTT parameters
Host (http://myhostip)
http://myip
Port (1883)
1883
Client (DVES_077925)
DVES_%06X
User (homeassistant)
myusername
Password
•••••••••••
Topic = %topic% (sonoff1)
sonoff1
Full Topic (%prefix%/%topic%/)
%prefix%/%topic%/
I’ve tried the discovery method leaving the username/password blank as well.
Any ideas are welcome. Full discosure, I’m not a programer and yaml gives me anxiety. Tia
You do not access MQTT via http://
The Broker address is just the IP address.
Thank you David, Ill give that a try!
That worked!!! Im currently in a state of shock.
Thank you again!
1 Like
It’s called, learning.
Really, there are so many different ways to install Home Assistant on many different platforms there is sometimes some confusion built-in to the docs.
In the case of the mqtt component, you can do nothing and the mqtt broker add-on just works. In my case, I am using an mqtt broker (mosquitto) on a separate Raspberry Pi, so I had to define it in the configuration.yaml file.
Why?? many will ask. I started my home automation in Node-Red and installed Mosquitto on that Raspberry Pi. When I made the move into Home Assistant, I did it on a separate Pi to not jeopardize my already working system. Since I am running HassOS, I cannot install any NPM nodes that I have on my Node-Red Pi. Likewise, my Node Red Pi won’t install any of the Home Assistant nodes. Thus I have a schizophrenic system. Or Frankenstein.
But, making them work together is really a learning experience.
I wish someone had explained that there are two paths one might follow. It seems to me that HassIO is a “warpper” to simplify Hass. Almost all online material tells me how to use Hass.
Everything Hass.IO has done for me COULD have been done through configuration.yaml modifications. Is this file defunct? If I now modify it, will it even take effect? Which configuration will take presidence?
1 Like
Except add-ons
not at all. you still need to use it to set up the core functionality of many components.
Now, those are two great questions and I really don’t know the answer. Maybe someone does.
With the addition of discovery and the entity/device/etc registry I literally have no clue as to how things will behave when making any change to the configuration. And because there are literally dozens of paths you can take between core installation flavor (hassio/not-hassio), on which hardware, discovery on/off, new/old frontends, different methods of lovelace config, etc, ad nauseum…, it’s getting pretty difficult to keep them all straight. So then it also becomes difficult to offer help to solve issues because you don’t know the specific iteration of “I have installed Home Assistant and now X won’t work” it could be.
And that’s why I’ve kept my set up more “manual” than the newer options allow for. For me, it’s far more “predictable”.
Configuration.yaml is the key component, the root of all of Home Assistant.
The core section of configuration.yaml is essential to all versions of Home Assistant- regardless of the host hardware or OS.
Like Finity, I don’t depend on the ‘discovery’ component and prefer to know how a component is configured. Plus I enjoy learning in the process.
1 Like
Apologies if this question has been answered here (or elsewhere): If one used MQTT Discovery to detect and register entities, how can one modify the discovered entities? For example, I might need to specify a brightness_scale after the entity was discovered.
Can the discovered entities be modified in core.entity_registry (or some other file within .storage)?
Or does one have to ensure that when the entity is first discovered, all desired options must be available to the discovery process? In other words, the discovered device must present all options up front.
EDIT
I overlooked to mention that I don’t used MQTT discovery and prefer to specify them in configuration.yaml. Therefore I’m completely unfamiliar with the behavior of the discovery process.
You can send an MQTT topic with config any time you like to update the entity. It’s not only discovered"one time". You can update as often as you like. Sometimes I write new code to update a sensor or modify parameters.
Thanks! So the best-practice is to simply publish a revised payload to the entity’s configuration topic, containing whatever new/modified options one wishes to include. Seems simple enough.
I’m now tempted to experiment with it and create a few test entities. ~I’m not using 0.87 so if I wish to delete these test entities I’ll need to edit Just saw all I need to do is publish an empty-string to the entity’s configuration topic and that’ll delete the entity.core.entity_registry manually?
I have my sensors publishing the config at every reconnect to MQTT broker.