MQTT not ready during OH startup results in no reconnect tries

Add-ons Bindings
,
1

Hi,

My MQTT binding works just fine. When the MQTT server goes down I get the following in the log:

2018-10-06 13:24:09.480 [ERROR] [t.mqtt.internal.MqttBrokerConnection] - MQTT connection to 'nasmqtt' was lost: Utracono połączenie : ReasonCode 32109 : Cause : null

2018-10-06 13:24:09.485 [INFO ] [t.mqtt.internal.MqttBrokerConnection] - Starting connection helper to periodically try restore connection to broker 'nasmqtt'

2018-10-06 13:24:19.490 [INFO ] [t.mqtt.internal.MqttBrokerConnection] - Starting MQTT broker connection 'nasmqtt'

And then when the MQTT comes back OH reconnects.

My issue is connected to a particular timing: when OH starts and MQTT is not available then the helper is not started:

2018-10-06 13:25:51.831 [INFO ] [t.mqtt.internal.MqttBrokerConnection] - Starting MQTT broker connection 'nasmqtt'

2018-10-06 13:25:52.367 [ERROR] [penhab.io.transport.mqtt.MqttService] - Error starting broker connection

I guess this is intended behavior and not a bug (you want to exclude broken config at startup) but in my particular setup it just happens to be an often situation.

My question is do you maybe have an elegant solution to the issue? Preferably to start the reconnect helper at startup.

I’d prefer to avoid hacks outside of OH but in the end if there is no easy solution I’ll create a dependency on OH startup script to wait till MQTT is ready before it allows the start.

Kind regards

2

You can’t start the reconnect helper at startup, because no broker connection exists.

The problem you’re hitting is that there is no retry logic on the initial creation of a broker connection. You could create a request for such an enhancement.

The best solution is to have your broker ready before starting OH.

1 Like
3

I think I have the same problem, using openhab embedded broker. How can this be solved?

4

Read the previous post…

5

My question was about “best solution is to have your broker ready”, because I cannot do that. I ended using external mqtt server which seems to work ok when rebooting the system.

I will open an issue next week, but I don’t know if the problem is the binding for not retrying, or opehab for not “priorize” embedded server.

6

For start order issues, see this and this.

To summarize, there’s not really a way at present to control such things.

7

Hi namraccr,
thank you for the replay.

For anyone interested in a solution external to OH what I did to solve it:

  1. Generate key pair:
ssh-keygen -t rsa -f openhab.id_rsa
  1. Add a user (openhabMQTT) that can login into karaf with a key and is part of a new group (MQTTmanager). Please follow https://karaf.apache.org/manual/latest/security.
    Add to etc/keys.properties:
openhabMQTT=AAAAB3.........xyz,MQTTmanager

Mind to replace “AAAAB3…xyz” with your real public part of the key (openhab.id_rsa.pub) you intend to use to authenticate.

  1. Allow users in MQTTmanager group to do bundle:restart by adding to etc/org.apache.karaf.command.acl.bundle.cfg the following line:
 restart = MQTTmanager
  1. Trigger the below command whenever your MQTT server is ready:
ssh -i /path/to/private/key/openhab.id_rsa openhabMQTT@openhabIP -p8101 'bundle:restart org.openhab.io.transport.mqtt'

Please mind that whoever will have access to your private key will be able to restart a lot of your OH, so keep your private key private.

1 Like