see the big yellow retained with X. hit it
Been there, done that. Still comes back
have you tried hitting trash can in the topic to delete it
I’ve tried that and trashing then entire ‘event’ folder. Still comes back with Disconnected ‘Retained’ when Home Assistant is rebooted
The source sensor has been removed? If not you have to change the setting for the sensor first. Then in dev tools → services → mqtt publish. Enter topic, blank payload and check the retain box
1 Like
The sensor has not been removed. There are no settings for Retain Flag in Sensors, there used to be, but that parameter was removed as it only applies to Switches.
Discussion:
This is my MQTT sensor configuration:
sensor A4:
- platform: mqtt
state_topic: "AuroraA4/event/Error"
name: "Aurora A4 Error"
value_template: '{{ value_json._timestamp }}'
- platform: mqtt
state_topic: "AuroraA4/event/Disconnected"
name: "Aurora A4 Disconnected"
value_template: '{{ value_json._timestamp }}'
I tried your screenshot for the Sensor:
And after rebooting Home Assistant, ‘Disconnected’ event was reinserted with the Retain Flag ON
The retained button indication in MQTT Explorer is not what you think. It does not show the message is currently retained, it shows that the topic hasn’t been updated after Explorer started and the value was retrieved then (possibly old retained data).
Delete the topic in Explorer by using the trash icon and then restart Explorer. If the message is truly retained it will appear again but it won’t otherwise.
Can you expand on this? You had a retain flag set and with one of the upgrades it was no longer valid? and/or threw an error? Maybe comment out the sensors, restart, uncomment the sensors and restart again. The default should be retain: false.
The method I posted has always worked for me, however, I’ve seen people who it hasn’t. They resorted to removing the integration and then adding it back worked.
btw none of the removal matters until you get the sensor config updated.
Like I said above, I have trashed that message and even the entire event folder, and when Home Assistant reboots, it magically reappears with ‘Retained’
See my previous link to the discussion of the Retain Flag in Home Assistant for Sensors and that it was removed and why.
No, I never had the retain flag set for sensors in my configuration.
As for removing Integrations, that doesn’t seem to work either. I had an old Integration called ‘Hero’ and had removed it over a year ago, yet it is still in the MQTT system (shows up in MQTT Explorer connected to Home Assistant MQTT). So I really don’t want to go down that rabbit hole.
If you have a topic with a retained message and want to purge it, you simply publish an empty string to the topic, as a retained message. Done; the topic no longer has a retained message. The topic will not have another retained message unless something publishes one after you purged it.
If you have truly purged the topic’s retained message yet another one reappears then something is responsible for publishing it. Your challenge is to determine what it is.
It’s as uncomplicated as that.
2 Likes
So after the update that removed the option for the retain flag, your sensors started to retain their messages? Have you rolled back to a prior snapshot to see if that is the cause of your problem.?
This has nothing to do with the configuration of the two MQTT Sensors in Home Assistant and everything to do with whatever is responsible for publishing payloads to the two MQTT topics.
If “Octopi” is responsible for publishing to AuroraA4/event/Error and AuroraA4/event/Disconnected then it’s the source of the retained messages. No amount of tinkering in Home Assistant will change that.
I don’t know what “Octopi” is but if you don’t want those two topics to receive payloads as retained messages, you will have to change that in Octopi.
123 Taras, I’m sorry you missed this in my First Post on this topic, so here it is again:
I have OctoPi with MQTT. I have turn OFF the retain flag in that config so that ALL event messages have retain=false.
In MQTT Explorer. I connect to my Home Assistant MQTT and delete ALL events for that OctoPi Instance.
I turn on OctoPi, Connect to my 3D Printer and look at all the events from that printer coming into Home Assistant.
All of them have the Retain flag OFF.
No. That would mean rolling back a couple of years. If you noticed in the Discussion thread I linked to previously on the ‘retain’ flag for sensors, this was back in Feb of 2019. I’m sorry, but I don’t even have Snapshots that far back.
I’m sick and tired of working around this stupid issue of rouge ‘Disconnected’ messages shutting down my printers. This is supposed to be a safety measure for 3D Printing, but instead its a logistics nightmare of an issue that should not be happening.
Since this only happens when I reboot Home Assistant, and they are MQTT messages, I think it’s logical to point the finger at MQTT.
I just now sent a Null Payload for the topic AuroraA4/event/Disconnect with the retain flag ON (as instructed above) which cleared out that topic. Then restarted JUST Mosquitto MQTT, and that topic reappeared as ‘RETAINED’ and triggered my Automation to turn off the corresponding switch.
I have looked through all the files in Home Assistant (configuration, automations, etc.) and nothing generates that topic. The sensor looks for that topic, but it also looks for the ‘Error’ topic, which is not regenerated by MQTT. And no other devices on my network generate that topic and the only one that does is Powered OFF.
sensor A4:
- platform: mqtt
state_topic: "AuroraA4/event/Error"
name: "Aurora A4 Error"
value_template: '{{ value_json._timestamp }}'
- platform: mqtt
state_topic: "AuroraA4/event/Disconnected"
name: "Aurora A4 Disconnected"
value_template: '{{ value_json._timestamp }}'
I will also point out that the timestamps on these ‘regenerated’ topics are not current, they are the same time stamps of those previously removed through the MQTT:Publish tool as I stated above.
So, no device is sending ‘new’ Disconnect messages, MQTT is retaining them and re-populating/re-publishing in them causing that automation to trigger in Home Assistant
Here’s another walkthrough:
Current state of Home Assistant MQTT Broker as viewed in MQTT Explorer:
Click on “Call Serivce” to send this topic:
Result shown in MQTT Explorer: that topic is now GONE:
Restart MQTT Brokers:
After Restart Complete, result in shown in MQTT Explorer:
Notice that the timestamp of the topic is the same as before, but the time of the event (on the right) is that of when MQTT was restarted.
Whatever you did failed to work because it continues to publish its payloads as retained messages.
MQTT Explorer reports if a message is retained in a manner that may be misleading you. When it’s connected to the broker and you publish a retained message to a topic, MQTT Explorer will not report it’s retained. If you disconnect MQTT Explorer from the broker and then reconnect, now it will show the topic has a retained message.
If you use NodeRED (or even maybe via an HA automation) you could read this payload and republish it non retained to a different one. Shouldn’t be needed but maybe will work around your issue.
I think the OP will agree to that statement because they claimed they disabled the retain flag at the source. Yet here we are.
However, what the OP is overlooking is that instructing the Octopi to cease publishing payloads as retained messages doesn’t change the fact that it had already published several as retained messages. That topic will continue to retain payloads published to it unless it is purged first (i.e. publish an empty string as a retained message). That’s just the way MQTT’S payload retention policy works.
Combine that with when MQTT Explorer’s does/doesn’t indicate a retained message and it explains everything the OP has reported (including the seemingly mysterious and magical appearances of RETAIN in Explorer).
1 Like