My first steps with OpenHab

I fixed the version info. There was an extra parameter “–show openhab2”. The relevant lines in .bash_profile should read:

OHVERSION=$(dpkg-query --showformat='${Version}' --show openhab)
OHBUILD=$(sed -n 's/build-no\s*: //p' /var/lib/openhab/etc/version.properties)

At some point whilst working on OH2.5, and then later after upgrading to OH3, I experienced very high CPU usage and out of memory errors, as detailed here:

It turns out that there is some sort of problem with having a large number of .js files with dependencies. Smushing all the files together into one huge .js file made the problem disappear entirely. I’ll try to file a bug once I can put together a minimal repro case.

This means I can once again get back to developing my system.

For the moment I’ve abandoned the Awair binding, because I can’t get it to work in OH3, or even consistently get it to compile. It’s just taking too much time and I haven’t got much help with it. So I just run a HTTP request to get the values into the items. I hit two stumbling blocks along the way. One is how to pass headers to sendHttpGetRequest. This is what worked:

var headers = [];
headers["contentType"] = "application/json";
headers["Authorization"] = "Bearer " + <AWAIR_TOKEN>;
headers["WWW-Authenticate"] =  "Basic";

I pass it in the second parameter of sendHttpGetRequest.

The second problem was that the items didn’t receive the values sent to them. It turns out you need to use autoupdate, like this:

Number AwairBedroom_CarbonDioxidePpm "Awair: Carbon dioxide (ppm)" (gRestoreOnReboot) {autoupdate="true"}

I haven’t looked into why. For now, I’ll just blindly accept it and move on.

Now that I’ve worked a few things out, I’m going to post some examples of working Javascript functions here:

I made my first basic sitemap today and set up access from my tablet. I’ve also created a switch item that enables full device control from openHab rules (blinds, awnings, cooling, etc.) Not everything is working properly yet, but if the Zipabox suffers a collapse when I’m away I can avoid total disaster by switching over to openHab.

Another stumbling block today: to access both the REST API from rules and https://home.myopenhab.org/ (not to be confused with myopenhab.org), you need to use the admin user (openhabian for example) that you use to access the terminal, not the cloud user that is required for accessing myopenhab.org. Confusing.

It’s less confusion when you understand what myopenhab.org actually provides. All it provides is a proxy for your openHAB instance’s REST API. Nothing more and nothing less. Authenticating with myopenhab.org only gives you access to your OH REST API via the home.myopenhab.org address.

However, openHAB itself implements its own authorization and authentication on that REST API that is separate and independent from myopenhab.org, nginx, apache, or any other proxy that might be used to access openHAB. Only users with the admin role have unrestricted access to the full REST API. All others either have no access or very limited access to just the Items and maybe one or two other end points.

So yes, you need to authenticate twice to access the REST API through myopenhab.org. First you need to authenticate to myopenhab.org in order to get to home.myopenhab.org, which is how myopenhab.org provides access to your instance’s REST API. Then you need to authenticate to openHAB itself the same as you would have to do it you were accessing it locally.

I’m not disputing the logic. It’s just inherently confusing, and it should be made clearer which login is being asked for.

Also, I’ve noticed that when the login session expires in the browser, I can never successfully log in from the dialog that pops up. Instead, I have to go back to the original page, log in to the cloud (the orange button where it says register/login), and then click “Click here to access your openHAB’s dashboard”, click on the padlock where an arrow points with the text " *Sign in as an administrator to access settings", and sign in with the admin details there. I don’t recall exactly what the pop-up dialog says.

The iRobot binding isn’t working for me. After

ONLINE
CONFIGURATION_PENDING
Robot authentication is successful

I get:

Status: 
OFFLINE COMMUNICATION_ERROR 
Timeout

with this in openhab.log:

2021-08-29 23:56:45.787 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '192.168.0.XX' with clientid XXXXXXXXXXXXXXX
2021-08-29 23:56:46.388 [WARN ] [rnal.handler.IRobotConnectionHandler] - MQTT connection failed: Timeout

I tried going back to dorita980 to check if something had changed, but I’m not able to make it work - perhaps due to a firmware update from June.

So I’ve gone back to controlling the robot by calls to IFTTT webhooks. Poor integration, but at least it works.

Continuing something of a pattern, my TP-Link sockets don’t have a power on/off channel for some reason (possibly related to openHab being the secondary Z-Wave controller?). In any case, I need the “reboot” command so that I can automatically reboot my router (for obvious reasons, separate off and on commands would not work). So, again, I’ve resorted to HTTP requests.

Since I can no longer post to “JavaScript examples that have worked for you…”, I’ll just leave this here, which I just got working.

function SendEmail(sSubject, sMessage)
{
  var Things = Java.type("org.openhab.core.model.script.actions.Things");
  var mailActions = Things.getActions("mail", <Gmail SMTP Thing Identifier e.g. "mail:smtp:2d17347393">);
  mailActions.sendMail("davidpritchardmadrid@gmail.com", sSubject, sMessage);  
}

function SendPushNotification(sMessage)
{
  var NotificationAction = Java.type("org.openhab.io.openhabcloud.NotificationAction");
  NotificationAction.sendBroadcastNotification(sMessage);
}

I was about to migrate my Nest account to Google to activate the binding, but then thought better of it.

Instead I finally got control of the thermostat working via the old API (I was not stringifying the JSON payload). This gives me full control in the Zipabox and openHab, and keeps the Nest Protect integrated, too. It also means I don’t have to do an all-or-nothing, no-going-back migration to openHab. I can test and go back and forth as needed.

That’s more or less the last item on my list, aside from some flood sensors that I’m not worried about at the moment. I’m weeding out the bugs by comparing the numbers of the two systems on a Google Sheet.

I also got automatic rebooting from the rules working. I’ll document how later.

The auto reboot took my quite a bit of experimentation to get right. I created a bash script that just does this:

sudo reboot

I originally tried to stop the openHab service first in the script (which I gather is unnecessary), but presumably it was openHab itself that was processing the script, so doing that put a stop to the reboot.

Then I created an exec thing with the Exec binding that just calls the script with sudo:

sudo /usr/local/sbin/restart_openhab.script

Presumably it just could execute the command itself, since the script only has one line now.

Then I created an item that is linked to the Running channel of the thing that executes the script:

Switch RestartScript_Trigger "Restart script: trigger switch" (gRestoreOnReboot) {channel="exec:command:45de2271e5:run"}

Last but not least, I created a rule that flips the switch to “on”. I’m not sure if it’s necessary to turn it off first.

diagReboot.prototype.RebootSelf =
function RebootSelf()
{
  logInfo("Restarting openHab...");

  if (openHabHelpers.IsSwitchOn("RestartScript_Trigger"))
  {
    openHabHelpers.TurnSwitchOff("RestartScript_Trigger");
    Wait(1);
  }

  openHabHelpers.TurnSwitchOn("RestartScript_Trigger");
}

I seem to have fixed all the bugs. I’m going to test a couple of things and then disable a load of rules in the Zipabox before setting openHab loose on my house. Maybe tonight.

If all goes well, I’ll need to switch openHab from from secondary Z-Wave controller to primary and then add some more devices that are currently not being detected properly.