MQTT things don't survive reboot, ESPURNA RF bridge

Hi all,

I recon this is a really easy problem to solve but I don’t know the solution

Am very pleased with my setup a except for one particular component disappearing when I restart the machine (ha restart fine)

Separate Docker containers all.

Latest HA
Mariadb
MQTT broker

HA MQTT CONFIG

mqtt:
broker: 192.168.2.125
discovery: true
discovery_prefix: homeassistant
client_id: HomeAssistantClient
keepalive: 60

The problem is I have a sonoff RF bridge running ESPURNA. BRILLIANT! it’s setup so ha autodiscovers the sensors. Works great.

But when I reboot the HA machine, home assistant comes.back without the ESPURNA sensors… I then reboot the ESPURNA bridge and the sensors appear in HA…

Is this a MQTT retain thing? How to fix?

TLDR. I have to reboot my sonoff RF 433 every time.i want to get my sensors to show up again in HA.

?

check your ESPURNA and make sure that you’ve set up the retain flag option. I have no idea how, but there must be one somewhere, it’s a standard MQTT feature.
This means the data will be retained on your MQTT broker

Espurna’s documentation for Home Assistant auto-discovery explains the situation you are experiencing and what you should do to mitigate it. Specifically:

it is recommended to set the RETAIN flag to ON (in the MQTT tab)

So all you need to do is set MQTT Retain to ON in Espurna’s MQTT configuration page.

1 Like

I think it’s on already, but will check!

Ultimately, you could use an MQTT client to examine the topics and confirm their messages are being published with retain=true.

MQTT retain is on in espurna settings. was on all the time, bit odd.

image

I know it sounds stupid, but try to set it to no, save, then set it to yes
Would not be the first time I see a GUI telling me it’s on when it’s off in the back end :wink:
May need to reboot your ESPUNA / MQTT Broker

Did you use an MQTT client to confirm the messages are being retained? MQTT Explorer does a good job of displaying which messages are retained.

Alternately, you can simply examine the MQTT Broker’s log.

i reckon this is a problem maybe with the order my Dockers start. i.e. maybe the Homeassistant docker is starting before the MQTT one…

i might have to use docker compose rather than the simple docker run one liners i’m using now as i think you can control start order with that.

spent a load of time this weekend messing about with docker-compose which is fun and I think I’m in a better place. strangely though not solved this “surviving reboot problem”… not sure it is boot order after all.

load of this stuff in the mqtt log but strangely homeassistant always requires a reboot to pickup the sonoff_rf switches…

is it a retain thing?
does the r1 / r0 thing mean retain?

any clues?

thks

1552203702: Sending PUBLISH to HomeAssistantClient (d0, q0, r1, m0, 'sonoff-rf-bridge/relay/6', ... (1 bytes))
1552203718: New connection from 192.168.2.30 on port 1883.
1552203718: Client rf_bridge disconnected.
1552203718: New client connected from 192.168.2.30 as rf_bridge (c0, k300).
1552203718: Sending CONNACK to rf_bridge (1, 0)
1552203718: Received UNSUBSCRIBE from rf_bridge
1552203718: 	#
1552203718: Received SUBSCRIBE from rf_bridge
1552203718: 	sonoff-rf-bridge/relay/+/set (QoS 0)
1552203718: Sending SUBACK to rf_bridge
1552203718: Received SUBSCRIBE from rf_bridge
1552203718: 	sonoff-rf-bridge/pulse/+/set (QoS 0)
1552203718: Sending SUBACK to rf_bridge
1552203718: Received SUBSCRIBE from rf_bridge
1552203718: 	sonoff-rf-bridge/led/+/set (QoS 0)
1552203718: Sending SUBACK to rf_bridge
1552203718: Received SUBSCRIBE from rf_bridge
1552203718: 	sonoff-rf-bridge/action/set (QoS 0)
1552203718: Sending SUBACK to rf_bridge
1552203718: Received SUBSCRIBE from rf_bridge
1552203718: 	sonoff-rf-bridge/rflearn/+/set (QoS 0)
1552203718: Sending SUBACK to rf_bridge
1552203718: Received SUBSCRIBE from rf_bridge
1552203718: 	sonoff-rf-bridge/rfout/set (QoS 0)
1552203718: Sending SUBACK to rf_bridge
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/app', ... (7 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/version', ... (6 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/board', ... (21 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/host', ... (16 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/ip', ... (12 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/mac', ... (17 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/rssi', ... (3 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/uptime', ... (4 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/datetime', ... (19 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/freeheap', ... (5 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/relay/0', ... (1 bytes))
1552203718: Sending PUBLISH to HomeAssistantClient (d0, q0, r0, m0, 'sonoff-rf-bridge/relay/0', ... (1 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/relay/1', ... (1 bytes))
1552203718: Sending PUBLISH to HomeAssistantClient (d0, q0, r0, m0, 'sonoff-rf-bridge/relay/1', ... (1 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/relay/2', ... (1 bytes))
1552203718: Sending PUBLISH to HomeAssistantClient (d0, q0, r0, m0, 'sonoff-rf-bridge/relay/2', ... (1 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/relay/3', ... (1 bytes))
1552203718: Sending PUBLISH to HomeAssistantClient (d0, q0, r0, m0, 'sonoff-rf-bridge/relay/3', ... (1 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/relay/4', ... (1 bytes))
1552203718: Sending PUBLISH to HomeAssistantClient (d0, q0, r0, m0, 'sonoff-rf-bridge/relay/4', ... (1 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/relay/5', ... (1 bytes))
1552203718: Sending PUBLISH to HomeAssistantClient (d0, q0, r0, m0, 'sonoff-rf-bridge/relay/5', ... (1 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/relay/6', ... (1 bytes))
1552203718: Sending PUBLISH to HomeAssistantClient (d0, q0, r0, m0, 'sonoff-rf-bridge/relay/6', ... (1 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/relay/7', ... (1 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/vcc', ... (4 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/status', ... (1 bytes))
1552203718: Sending PUBLISH to HomeAssistantClient (d0, q0, r0, m0, 'sonoff-rf-bridge/status', ... (1 bytes))
1552203718: Received PUBLISH from rf_bridge (d0, q0, r1, m0, 'sonoff-rf-bridge/loadavg', ... (1 bytes))
1552203762: Received PINGREQ from HomeAssistantClient
1552203762: Sending PINGRESP to HomeAssistantClient

I came to this post looking for a solution to my sonoff devices showing not available after a HA restart.
I ended up using the solution posted by @francisp on this thread: Tasmota - Entity Not Available