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:
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.orgonly 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.
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.
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:
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.
openHab is fully up and running. Inevitably, there are teething troubles, but it’s mostly doing its job. The Zipabox is no longer controlling anything, except the Fibaro sockets.
After a couple of hours I’ve finally worked out how to access the previous value from a trigger in JSR223/OH3/Helper libraries Javascript. I tried the usual suspects, previousState, previousState.state, oldState, and none of them are defined in Javascript (helper libraries flavour). What does work is event.oldItemState, but it gives you the value with the units included, so to get a numeric value, you need to do:
parseFloat(event.oldItemState)
But that only works from a rule with a trigger. Getting previous values from persistence is a different story.
Correct. You need to get everything from the event Object passed to the Action’s function. And whether or not event exists and what exists inside the event depends on how the rule was triggered. If you are using the JSR223 Helper Libraries your first place to look for information like this is the Helper Library docs. For example Event Object Attributes — openHAB Helper Libraries documentation lists all the stuff that might be in event and when it will be in there.
If your Item has units, it’s best to stick to using units. The units that the Item carries and displays may not match what you expect. For example, it could be °F when you expect want °C. When you stick to the units then you can compare or do math and get the correct result no matter the units.