How to know if openHAB is fully up?

Hi

I have multiple openHAB instances which work together. To check if openHAB is online on another server I run following code:

# Warten bis Server gestartet ist
logger -t echo "waiting for OpenHAB Server..."
while ! timeout 0.2 ping -c 1 -n $SERVER_IP &> /dev/null
do
    logger -t echo "."
done
logger -t echo "Server is back online"

# Warten bis HTTPS-Dienst ausgeführt wird
logger -t echo "waiting for OpenHAB startup..."
until $(curl --insecure -s -o /dev/null --head $PROTOCOL://$SERVER_IP)
do
    logger -t echo "."
    sleep 5
done

logger -t echo "OpenHAB is back online"

At first I wait until the server is reachable. Maybe the server is not started or at the moment it is starting or restarting. After that I try to make an HTTP-Request. During the init of openHAB you would receive at first 404 (page not found) and 500 (internal server error). After that you will receive 200 ok or in my case because of an unsecure https request 401. But this means openHAB is starting. However, during this startup, sitemaps, items, rules, etc. are loaded.

I’m currently working with a sleep command here, but it’s imprecise and it doesn’t always work.

What I want to achieve is to run a command for executing a rule after the whole system is started. Sometimes it works but because of the delay he tries to execute this rule to early.

If you look inside the Karaf Console and use log:tail you will you will notice that the models are loaded. So maybe it could be a good solution that you could get an information that all models have been loaded.

What I also have done on my openHAB instances was following tutorial which show me the uptime of my server and openHAB. Both informations are different. Especially when you restart the openhab2.service.

So I have a similiar question to this topic and want to know if all config files have been loaded. Yes I have used the word models for it because if you have a look inside the Karaf Console they talk about models.

In my opinion the “system” openHAB is booted when not only the web service was started but all these conf files could be loaded. Before that it is not functional. What I could already determine, is that you can already control items via the site map and e.g. turn lamps on and off, before then actually the rules are loaded. Only after these could be loaded, the corresponding rules could be triggered. Self-explanatory.

Of course, if you have several systems running together, it is annoying if some items or rules have not been loaded yet. It can lead to one of the systems crashing due to an exception. This must then be restarted.

To be able to boot all of them cleanly, I would like to have a check if all systems are not only running, but if they could actually load all their models already. I hope you understand the difference. I have not shown my whole bash script. I of course still configure the parameters for the IPs as that I then run systemctl start openhab2.service after it thinks that the other openhab server is running. Now of course you could go and say if it’s delayed start then it should be ready after the other one is completely started. It would be nice. The items and rules take different amounts of time to load and there are 8 different devices in total. Because of the different performance, this check is relatively reliable, but sometimes one or the other device needs a little longer and then it doesn’t work quite so easily.

Of course I was working with ssh so maybe something like inside the fist link with the process could be work better than my https request.

But the running process would also only mean that it has started so far that all models are loaded and still not that all could be loaded already.

Maybe people here have good ideas or even solutions.

Thanks in advance.

You can trigger rules when OH starts up, why not just have virtual switches that are flipped ON and have your rules check on the virtual switch(es) prior to their run?

This would introduce a new hurdler however of flipping the switch OFF when the corresponding OH system restarted.

If you are running OH3 perhaps the remoteopenhab binding would help in the detection.

There is going to a lot of approaches to solve a problem like this. Perhaps the best approach would be to make your rules more robust so that they don’t crash when one of the OH instances isn’t online. But even with that it’s useful to know when an OH instance is truly online and started.

So how I would implement this is using MQTT’s LWT feature and OH 3’s new concept of start levels.

Configure the MQTT Broker Thing to publish “OFFLINE” to a well known LWT topic for that instance of OH. Make sure it’s a retained message.

UID: mqtt:broker:broker
label: Mosquitto MQTT Broker2
thingTypeUID: mqtt:broker
configuration:
  lwtQos: 2
  publickeypin: true
  clientID: openhab
  keepAlive: 60
  lwtMessage: OFFLINE
  lwtTopic: openhab/status
  secure: false
  certificatepin: true
  password: password
  qos: 2
  reconnectTime: 60000
  port: 1883
  host: hostname
  lwtRetain: true
  username: username
  enableDiscovery: false

Finally, add a rule that triggers when the system reaches start level 100 to publish “ONLINE” as a retained message to the LWT topic using the MQTT publish Action.

With that you will now have MQTT topics that will always tell you the online and started up status of all of your OH instances. Then in your OH instances you have and Switches or Contacts linked to Channels that subscribe to those topics that will let their offline/online and initialized status. You could put those into a Group:Switch:OR(OFF,ON) and the Group will be OFF is any one of your OH instances are OFF. You can do a very simple test in the But only if… part of a rule on that Group.

It seems your other instances are directly accessible from the main instance, so another very easy way to get items with the states of your other OH instances would be the Network binding’s Network Device with Running Service thing.


You just set the address to the device running OH and the port to that OH’s UI port.

Rich’s solution probably has slightly less latency but only by a few seconds.

Probably not because the MQTT client has to miss a number of heart beats with the server before the server will mark it offline and publish the LWT message. This too can take some seconds so it’s probably the same amount of latency.

If there is an advantage to the MQTT approach it is that it’s not openHAB specific. Anything that can speak MQTT can see if the OH instances are online/offline. It also doesn’t take a whole lot of extra code to set up. And finally, unlike the Network binding, you have a bit more control over when the ONLINE message is posted. OP wants to know when OH is fully online but it will respond to pings before it’s fully online. It’s really that one requirement that pushes me to suggest MQTT.

2 Likes

Good to know. Many thanks. We are not switching to OH3 yet. Maybe in the summer, probably in the fall. Think until then, I can leave everything at the old. Would be too much at once.