Problems running UI code on PC

[HestiaPi]

@DanD

Can you tell me where to start to setup openHAB on a Ubuntu machine?

I don’t believe simply running openHAB on a Ubuntu machine takes more than a simple install command. The challenge would be to replicate the GPIOs and the sensor readings unless you only want it for testing purposes and you can hack the BME scripts to return semi-random values.

[rlkoshak]

I think the hardest part will be getting the web UI and Mosquitto talking. I don’t know if they ever got it working using stock Mosquitto and have a custom compiled version that includes websocket support, which is what the web UI uses as I understand it.

But there are the three parts:

1. Install Mosquitto

2. Comple the web UI and make sure it connects to and works with Mosquitto. As mentioned previously, you can stimulate the web UI through an MQTT client like MQTTExplorer

3. Install openHAB per the instructions in the openHAB docs.

4. clone the Hestia One repo, make sure to grab the One branch and not the MQTT branch.

5. That repo has three folders you need to copy to the right locations.

   • etc/openhab2 -> /etc/openhab2
   • home/pi/scripts -> /home/<username>/scripts
   • var/lib/openhab2 -> /var/lib/openhab2

6. Adjustments:

   • uninstall the GPIO binding using openHAB’s PaperUI
   • update the Exec binding Things to point to the new location of the scripts folder. It expects them to be in /home/pi/scripts.
   • verify that the MQTT broker shows as online

7. Startup on the RPi is somewhat orchestrated which wont be working nor will it be required on a more powerful machine. The script loops and waits for the overall system load at startup to drop below a threshold and then it copies default.rules from /home/pi/scripts to /etc/openhab2/rules. openHAB then parses the file and kicks off a System started rule which triggers the Initialization JavaScript rule. That rule initializes the states of Items that must have a valid state which in turn causes openHAB to publish to the MQTT topics that initializes the web ui. So you will at some point need to copy the default.rules over to get everything up and running but you can probably keep the file there and the rule will run every time openHAB restarts.

[DanD]

@rlkoshak

One thing you can do is to look at the openHAB rules code, particularly the initialization rule and see what Items get initialized on a first boot. Then look at those Items’ configurations to see which ones are linked to MQTT channels. Those are the Items that drive the LCD. Look at the MQTT Things associated with those Items to learn the topics and then you can simulate an openHAB instance by using mosquitto-pub and mosquitto-sub, or MQTT.fx or MQTTExplorer (my preferred tool) to manually publish and monitor the MQTT topics to drive the LCD by hand.

Hey Rich, I just downloaded a zip of the OH code, and the rules folder is empty:

[rlkoshak]

Correct. default.rules is in /home/pi/scripts. During startup, the startup script will copy that file to /etc/openhab2/rules. You won’t have the startup script running so you have to do that yourself.

The rest of the rules live in /var/libopenhab2/jsondb/automation.json, but you will want to look in PaperUI under rules instead of looking at the raw json.

[DanD]

I’ve been looking through the OH backend code, but I can’t figure-out where things start. What’s the start-up sequence? What runs first, second, etc, and what ends-up calling the “Kick off initialization” rule? What does that rule trigger (i.e., what executes the StartInitialization.sendCommand(ON)), and what triggers the MQTT message to the UI?

Also, I’ve got MQTT Explorer setup monitoring a Mosquitto Broker. Can you give me a message that I can publish, from MQTT Explorer, that would come from the OH backend, to test the connection to the HestiaPi UI?

[rlkoshak]

@DanD

What’s the start-up sequence?

There is a script that starts up with the OS. This script starts the Web UI and openHAB. It monitors the overall load of the system and when the load drops below a certain level that’s a signal that everything has loaded and initialized (except the Rules). Then the script copies the default.rules file from /home/pi/scripts to /etc/openhab2/rules.

You can see the start script in /home/pi/scripts/kiosk-xinit.sh. Of course, that script won’t work for you since you are not running on an RPi but you can see the order of the start sequence there.

@DanD

What runs first, second, etc, and what ends-up calling the “Kick off initialization” rule?

default.rules has a single “System started” rule. As soon as openHAB sees that default.rules file is there (copied by the script above) it will load it and execute the “System started” rule. All that the rule does is send a command to an Item, StartInitialization, that triggers the JSONDB “Initialization” where the “real” initialization occurs.

@DanD

and what triggers the MQTT message to the UI?

Items are linked to MQTT Things. When those Items receive a command that causes the MQTT binding to publish the states to the configured MQTT topics, sometimes with some transformation. So during initialization you will see commands being sent to various Items. When the commands are sent, for those Items that are linked to MQTT Thing Channels, a message is also published.

So what you need to do is look at the Things in PaperUI to see which Items are linked to which Channels. For example, opening the “System Configs” Thing shows two Channels each of which are linked to Items.

Clicking on the edit icon (pencil to the right) will show what topics that channel subscribes to and/or publishes to.

So this shows that the SystemType Item is linked to the System Type channel and whenever that Item receives a command, it will publish the Item’s state to /hestia/local/systemtype.

Returning to the Initialization script, the first few lines of code that are not defining functions are:

// Initialize type Items first
initFromScript("SystemType");
initFromScript("TempUnit");
initFromScript("HumidityType");

Those call the initFromScript function defined in that same rule a few lines above.

var initFromScript = function(i){
  if(items[i] == NULL || items[i] == UNDEF){
    logInfo(logName, i + " is undefined, initializing from script " + cmd);
    events.sendCommand("Get"+i, ON);
    waitForUpdate(i, 5);
  }
  else {
    logDebug(logName, i + " is " + items[i]);
    events.sendCommand(i, items[i]);
  }
}

If this is the first time that openHAB has ever started, or if the MapDB was deleted, the SystemType Item will be NULL. So we send a command to an Item linked to an Exec binding channel that will call the script that reads the SystemType from a file. Both the script and the file with the type are in /home/pi/scripts. When the Exec binding has finished executing the script, it will command the SystemType Item with the read SystemType (US, or EU). And as explained above, any command to the SystemType Item will result in the new state to be published to the MQTT topic.

It seems complicated but these layers of abstraction between the stuff that connects to devices (Bindings and Things), the model of the system (Items), and the behaviors (rules) is part of what makes openHAB so flexible and powerful.

All the other rules are driven by the sensor readings or interactions with the UIs. The sensors are read periodically using the Exec binding, the result of which updates an Item. When the Item changes, as described above, the “Process Sensor Changes” rule runs. If the change is big enough it updates the PreviousXReading Item which triggers the “Sensor or Setpoint Changed” rule. You should be able to follow the path through the Activity diagram from there.

The “Sensor or Setpoint Changed” rule and related rules have a check to prevent them from running until after the “Initialization” rule has run.

@DanD

Also, I’ve got MQTT Explorer setup monitoring a Mosquitto Broker. Can you give me a message that I can publish, from MQTT Explorer, that would come from the OH backend, to test the connection to the HestiaPi UI?

Send “US” to /hestia/local/systemtype and that will tell the UI to go into US mode showing the heater, fan and AC icons. Send “EU” to that same topic and it will tell the UI to go into EU mode showing heater, humidity, and hot water icons.

[DanD]

Rich, thanks for all of the detailed info. That’s a big help!