When Home Assistant restarts, libcbus fails to reconnect

[garethcook]

I have a pretty reliable system, I have a dedicated RPi2 for libcbus into a Serial CBUS interface. Works great.

Except when Home Assistant restarts, such as with an update, and when that happens libcbus fails to reconnect. Is there a way to configure a poll to check for connectivity, and force it to attempt to reconnect to the Home Assistant MQ broker? At the moment I have to also then go power cycle the libcbus RPi2

Thanks

[garethcook]

Does everyone have this issue?

[beerygaz]

I'm having the same issue. I'm running the docker image with a PCI controller and need to restart my container to re-establish an MQTT connection after and HA restart.

[BUSTERCJB]

My work around to the issue is a Node-RED flow.

In my cbus network, address 231 relates to nothing.

Every 30 mins, address 231 is set to on, and a delay is set to check that the network has turned on the address 231. If the cbus raspberry pi is disconnected from the mqtt network, then address 231 will not turn on, and thus, the check will fail. If it fails, it sends an ssh command to restart the cbus raspberry pi. If it passes, then address 231 is set to turn off.

In the extremely rare chance that mqtt network/Home Assistant has recorded address 231 as on but the cbus network is actually disconnected, the system checks if the turn off command has been processed, and if it hasn't, then it sends an ssh command to restart the cbus raspberry pi. Thus, there is only ever a maximum 30 min window during which the cbus-mqtt link is offline.

I'm using node-red-contrib-ssh-v2-reconnection for the ssh node. The second inject node is used for me to powercycle the pi at my leisure instead of waiting 30 mins for it to be done automatically.

[beerygaz]

This is a very elegant solution and on I shall now shamelessly steal for my system.

Relating to #22 - and given you're a Node Red user too - have you encountered any "missed messages" scenarios when trying to turn off multiple groups at one using Node Red? I find if I try and call the service to switch off, say 5 groups at a time, only 3 are ever affected,

[BUSTERCJB]

I only ever switch off two cbus addresses at most at one time using Node Red. Possibly set a 5 second delay if everything is being automated. I presume the cbus-mqtt link has a limit on how many requests can be processed at once. It isn't like the PCI was designed for what we are using it for.

Alternatively you could program a whole new address with no input devices and only the output devices desired from all 5 groups, and then just toggle that individual group via home assistant/node red.

[garethcook]

Perhaps a way to do this is have a Home Assistant script run say every 5 mins. that sets a value (say the minute as a number) to a virtual counter, then read the value of that counter. If it's the same, do nothing. If there's an error then force the Pi gateway to restart either by an SSH or using the Unifi plugin to toggle the PoE port (which I use). This will mean I need to learn how to script!

[BUSTERCJB]

That's essentially what we are doing but using the cbus network to store the value of the counter. I've found it impossible to send an ssh reboot command using the scripting/automation on home assistant hence I used the node on NodeRed.

Is there a way to program into cbusmqtt a check mechanism for a connection to the mqtt server every X mins instead of having to rely on our workaround?

[Nik19792000]

I've worked around this by running a Mosquitto broker in bridge mode on the same server that runs libcbus. It can be configured to keep the connection to the client (libcbus) alive even if the connection to the server (Home Assistant) is interrupted.
Sample mosquitto.conf:

listener 1883 0.0.0.0
allow_anonymous true

persistence true
persistence_location /mosquitto/data/
log_dest stdout

# Bridge configuration
connection bridge-to-remote
address <ha_mostquitto_server>:1883
remote_username <your_mqtt_user_in_ha>
remote_password <your_mqtt_password_in_ha>
topic # both 0

try_private true
cleansession false

remote_clientid localbridgeclient

start_type automatic

max_queued_messages 1000
persistent_client_expiration 1h