What mqtt broker are you using ? The HA built-in broker (deprecated) does not store retained MQTT messages.
I have over 50 tasmota devices ( and a lot other MQTT-based devices), none show this behavior.
Good point! That would be the culprit because if SetOption 19 1 is being used, the MQTT Broker should be storing the config payloads (and Home Assistant wouldn’t “lose” them after a restart).
O.K done some tests
When running as normal seeing topic of Home Assistant on MQTT Explorer, there are messages shown as config, running at QOS 0.
The message is showing as retained
Did a full reboot, without the Setoption19 1 in the Automation file.
Entities not available as usuall
On system running again, MQTT Explorer shows no topic for Home Assistant anymore.
Could it be that under QOS 0 the messages are lost and it cannot resend, since Mosquitto is likely to be up and running way before Home Assistant.
I have done some reading of QOS levels and still cant get my head around which party determines the QOS level.
Since Mosquitto shows the message as retained this should be stored on the HDD and would survive the reboot, this would be the server.
In this case I assume Home Assistant is the client to have the message sent to.
To my thinking Tasmota has done its part getting the message to Mosquitto and have it set as retained, its now between Mosquitto and Home Assistant to complete the proccess.
???Totally confused???
If the topics disappear, it means the payloads published to those topics were NOT published as retained messages.
Imagine you are attending a meeting where no one is taking notes. Everyone in the meeting knows exactly what has been discussed. If someone arrives late, they have no idea what has happened in the meeting. However, if someone had been talking notes, the late-comer could review them and be apprised of everything that had been discussed. That’s similar to how retained messages work. The payloads are stored by the MQTT Broker so if a client, like Home Assistant, disconnects from the MQTT Broker and reconnects later, it will have access to all the stored payloads (“retained messages”).
Could it be that under QOS 0 the messages are lost …
Quality Of Service level has absolutely nothing to do with this issue.
1 Like
Here’s an easy way to learn how MQTT Discovery works. Add these two scripts to your system:
#script:
example_create:
alias: 'Create Example MQTT Light'
sequence:
service: mqtt.publish
data:
topic: 'homeassistant/light/example/config'
retain: true
payload: >
{
"name": "Example",
"unique_id": "ABC123",
"stat_t": "home/example",
"cmd_t": "home/example/set",
"bri_stat_t": "home/example/brightness",
"bri_cmd_t": "home/example/brightness/set",
}
example_delete:
alias: 'Delete Example MQTT Light'
sequence:
service: mqtt.publish
data:
topic: 'homeassistant/light/example/config'
retain: true
payload: ''
Go to Developer Tools > Services and execute script.example_create. It will make MQTT Discovery create a new entity called light.example. Now use MQTT Explorer to connect to the MQTT Broker and confirm that this discovery topic exists:
homeassistant/light/example/config
It contains a payload that was published as a retained message. If you restart Home Assistant, the light.example entity will still exist. If you restart the MQTT Broker, the topic and its payload will persist.
If you observe any behavior that differs from what I have described then there is something wrong with the configuration or operation of your MQTT Broker.
If you execute script.example_delete it will make MQTT Discovery remove the light.example entity. MQTT Explorer will no longer display the discovery topic for that entity.
Did you read the manual ?
persistence [ true | false ]
If true , connection, subscription and message data will be written to the disk in mosquitto.db at the location dictated by persistence_location. When mosquitto is restarted, it will reload the information stored in mosquitto.db. The data will be written to disk when mosquitto closes and also at periodic intervals as defined by autosave_interval. Writing of the persistence database may also be forced by sending mosquitto the SIGUSR1 signal. If false , the data will be stored in memory only. Defaults to false .
Yes, but if mosquitto is not configured right, they are lost when mosquitto restarts (or your pi reboots)
God why do things so complicated, so quickly, so its looking at config for mosquitto now.
Did another check, booted so as not to be discovered, stopped home assistant, rebooted Tasmota devices.
All topics appeared in MQTT explorer after the reboot.
My conclusion is either Mosquitto is not storing the config as its supposed to
Or Tasmota is not sending to messages to be retained.
Question how to I find out which one is not playing ball, I must admit Im a bit nervous at playing around in Mosquitto as I could break everything, and its all running in Docker what ever that means. Thanks for all your help by the way, my backround is electronics not programming… Thanks Mark
I don’t know much about running mosquitto in docker (my mosquitto’s run on bare metal), but normally your mosquitto.conf must be somewhere outside the container.
The solution is simply to add
persistence true
to your mosquitto.conf file and restarting mosquitto.
Everything you need to know is nicely explained here :
https://hub.docker.com/_/eclipse-mosquitto
including how to setup persistence
I currently have two instances of Mosquitto.
-
The first instance was created by an automatic installation of openHAB on a Raspberry Pi 3B (openHABian, like HASSbian). This instance has been running for about 1.5 years. I checked
/etc/mosquitto/mosquitto.confand it haspersistence true. The installer software (created by an openHAB volunteer) pre-configured it like that. -
The second instance was recently created by the automatic installation of Home Assistant Supervised on an old laptop. I checked
/usr/share/hassio/addons/core/mosquitto/data/mosquitto.confand it also has been pre-configured withpersistence true.
So now tell us how you installed mosquitto on your machine. You said it was based on docker. What instructions did you use to install it? This information will help us point you to the location of the mosquitto.conf file.
Both of you are JEMS
im sure I can find my way from here now, I think I will get on just fine with this HASS as the community are so helpfull.
The Node Red forums are a little less helpfull, probably because it is picked up on by fewer armatures, the usual reply, is READ THE DOCUMENTATION, which most people do, but at as programming novice, the documentation means very little. Its people like yourselves that allow us novices to gain knowledge.
Thanks Mark.
One useful tip for running 5V power to sensors and tablets, that has worked 100% for the last five years is,using the thin copper tape on the emulsioned walls and ceilings.
Seal with a non water based paint, prior to repainting to stop electrolysis action. You will have to sweat solder any joints.
The result is completely invisible and safe. Its not like you score your walls with a knife all the time.
I thought I,d share something back
Just fully read your message, my Mosquitto was installed at the same time as Ubuntu as stated before,so I guess that will not be in a Docker container making the file easy to find. Only the HASS installation is in a Docker container, it was script installed
What installation instructions did you use because mosquitto is not normally installed by default with Ubuntu.
If not in docker, your configuration file will probably be in /etc/mosquitto
In the new installation of Ubuntu Server you have the option to install Mosquitto at install time.
Found the file and it is Default with everything hashed out, you were right.
It was in /snap/mosquitto/269
It currently wont let me save the file giving me error messages
There it is and via Ubuntu’s now preferred method of using snap (instead of apt).
Check the file’s permissions; it probably belongs to the root account.
In other words, the account you are currently using probably only has “read” permission but not “write” permission. So you can open the file to view it but you can’t save any changes you make.
You can either log in as root or, using your existing account, temporarily raise its privileges to root-level status by prepending sudo to whatever command you execute. For example, if I want to use the nano editor to modify a file (owned by root), I’ll execute it as sudo nano (and then it will prompt me to supply the root account’s password).
Strange I was going to use chmod 775 and then restore after edit.
I can see the file with WINSCP , but when I use the command line to use SUDO it tells me
file does not exits, DIR command shows no files, Oh well onto the UBUNTU site