openHAB 2.4 has been released!

Awesome!
That’s the ultimate Christmas present.
Thanks a lot guys and enjoy your holidays!

And remember to spend some time with the family to keep the WAF of openhab up un a certain level.
:rofl:

Yes, this is the case for all bindings for which a 2.x version becomes available. We probably should specifically list those in the release notes, you’re right. But the important info is that everyone can keep going using the old versions, so there is effectively no breaking change - only thing that needs to be done is to enable the legacy binding support.

Hi Kai, that to me is a breaking change because everyone, including myself had MQTT break.

Please please list this so others don’t fall into the trap!

2 Likes

I had openHAB 2.3.0 installed by just unzipping the archive. When I try to use the update script to bring it to 2.4.0, it wants root rights. Why?

I commented the root check, but that did not help, because it wants to execute the update script from 2.4.0 after download, which again has the root check.

How can I get around this? Or what is the update procedure for unzipped installations without the update script?

Thanks!

Edit:
I hacked around this and successfully updated to 2.4.0. Still would like to know why root is forced here.

I agree with Kris. If user does have to do something to restore what was previously working, even if it’s just 3 clicks, it is a breaking change. It would be a time saver if we could keep this in mind for the next releases. The mqtt change was quite a surprise for me because even as of 2.4 M5, the old plug-in was still there. I didn’t expect it to be dropped just within couple of short milestone builds.

Since the upgrade I get a lot of ThingAction errors:
I usually use this action to verify the online state of my main things

2018-12-21 09:18:28.713 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check Syn Surveillance': The name 'ThingAction' cannot be resolved to an item or type; line 307, column 15, length 11
2018-12-21 09:18:28.714 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check Harmony': The name 'ThingAction' cannot be resolved to an item or type; line 230, column 15, length 11
2018-12-21 09:18:28.724 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check Dash2': The name 'ThingAction' cannot be resolved to an item or type; line 128, column 15, length 11
2018-12-21 09:18:28.745 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check Berling': The name 'ThingAction' cannot be resolved to an item or type; line 190, column 15, length 11
2018-12-21 09:18:28.745 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'State check Volvo': The name 'ThingAction' cannot be resolved to an item or type; line 270, column 15, length 11
2018-12-21 09:18:28.792 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check Buderus': The name 'ThingAction' cannot be resolved to an item or type; line 210, column 15, length 11
2018-12-21 09:18:28.813 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check Dash1': The name 'ThingAction' cannot be resolved to an item or type; line 109, column 15, length 11
2018-12-21 09:18:28.808 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check ZWave': The name 'ThingAction' cannot be resolved to an item or type; line 327, column 15, length 11
2018-12-21 09:18:28.814 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check Amazon Account': The name 'ThingAction' cannot be resolved to an item or type; line 90, column 15, length 11
2018-12-21 09:18:28.823 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check Dash3': The name 'ThingAction' cannot be resolved to an item or type; line 147, column 15, length 11
2018-12-21 09:18:28.862 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check Netatmo Main Module': The name 'ThingAction' cannot be resolved to an item or type; line 250, column 15, length 11
2018-12-21 09:18:31.900 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check Harmony': The name 'ThingAction' cannot be resolved to an item or type; line 230, column 15, length 11
2018-12-21 09:18:31.890 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check Dash2': The name 'ThingAction' cannot be resolved to an item or type; line 128, column 15, length 11
2018-12-21 09:18:31.927 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check Berling': The name 'ThingAction' cannot be resolved to an item or type; line 190, column 15, length 11
2018-12-21 09:18:31.940 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'State check Volvo': The name 'ThingAction' cannot be resolved to an item or type; line 270, column 15, length 11
2018-12-21 09:18:31.940 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check Syn Surveillance': The name 'ThingAction' cannot be resolved to an item or type; line 307, column 15, length 11
2018-12-21 09:18:31.953 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check ZWave': The name 'ThingAction' cannot be resolved to an item or type; line 327, column 15, length 11
2018-12-21 09:18:31.952 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check Dash1': The name 'ThingAction' cannot be resolved to an item or type; line 109, column 15, length 11
2018-12-21 09:18:31.975 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check Buderus': The name 'ThingAction' cannot be resolved to an item or type; line 210, column 15, length 11
2018-12-21 09:18:31.992 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check Netatmo Main Module': The name 'ThingAction' cannot be resolved to an item or type; line 250, column 15, length 11
2018-12-21 09:18:32.002 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check Dash3': The name 'ThingAction' cannot be resolved to an item or type; line 147, column 15, length 11
2018-12-21 09:18:32.010 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'OFFLINE check Amazon Account': The name 'ThingAction' cannot be resolved to an item or type; line 90, column 15, length 11

I did not find anything about a change in this regard.
An suggestion would be greatly appreciated.

EDIT:
I guess I found a suggestion and will verify:

EDIT 2:
That seems to have fixed the issue - Thanks @Kai

Another point :slight_smile:

According to the “Breaking changes” I would need to deleted and re-added.
However, my system works properly without this procedure.

So, is this to enable to use security only?

No, it is not related to the security upgrade alone.

Then you maybe did that before on a 2.4 snapshot? You only have to do it once or if you need new/changed channels from database updates.

Right - I did it after going from 2.3 stable to 2.4 Milestone.

My assumption was, that it’s needed once more beside the previous one.
Thanks @sihui

1 Like

First:
Thanks to all volunteers for their ongoing work with openHAB.

Hey @Kai i would have one suggestion. (The same i have written down for the last two releases.)
Would it be possible to move the “breaking changes” up in the release notes?

I think they are positioned really bad at the end of the notes.
Not everyone reads all of the release notes from top to bottom since they include many changes that don’t affect all users and are binding related.

I had problems with one update in the past and learned the hard way to scroll down to reach those important informations.
Still i don’t think that it should be mandatory to read about every pull request that has made it into the current release.

Maybe you could consider changing the release notes structure a bit for the future.

Thanks

3 Likes

Thanks a lot! You guys did an OUTSTANDING job with this release!!

Upgrade went as smooth it could possibly be. Most importantly: OH now runs as fast as never before, this is just amazing! I am really impressed and will always be stunned about the magic you guys can do with software like this :slight_smile:

Again, thanks a lot and have a great holiday season.

I have already made my update from openHAB 2.3.0-1 to 2.4.0-1 (stable), successfully.
The experience was very good overall upgrade, but the experience with zwave binding had its episodes (see here).

I want to thank everyone who contributed to this development.
On @kay, I leave to the all community my great great thanks.

Happy holidays to the whole community.

Just upgraded to 2.4 (from 2.3).
Have spent a while (3 days) tracking down breaking changes. Mostly to do with Zwave (some things/channels changed), still cannot get some devices back on line. This I understand though.

Couple of weird things that aren’t mentioned anywhere.

Insteon PLM binding is a lot less stable. There seems to have been some changes to it, but randomly the binding stops working (an hour, a day…). Never happened in 2.3. Also editing the items file does not reload the binding (nor does bundle:reload in the console). Have to shut OH down completely and restart to get Insteon back on line.

Very odd thing with the network health binding. Took me 2 days to find this.
I have some micro controllers with WiFi modules controlling garden lighting. These cortex M0’s went offline when 2.4 was installed.
Resetting them, they boot, connect to WiFi/mqtt, then in less than one minute hang.
Traced it to the network health binding, this “pings” them every 60 seconds. When the “ping” occurs, the microcontrollers hang.
I can ping them from system (ICMP, Windows or Linux), with no problem, also arping works fine. Just networkhealth “ping” causes them to hang. I have tried every setting on the network health thing for each of them, but they still hang. Maybe the java “ping”?
I have disabled the thing for these microcontrollers for now (but now I have no way of knowing if they are online or not).
Anyone have any ideas of how to fix this? Or what is different about the 2.4 networkhealth binding vs the 2.3? I already tried system_ping=“false”, port=0, changing arping to /dev/null.

Any suggestions are welcome.

Pop up a new thread and post there some details to see if we can debug this.

Overall feedback is good as a reply to an announcement thread but you can’t really use this one for troubleshooting :slight_smile:

Generally: If anyone has problems due to the upgrade from OH 2.x to 2.4.0 Stable, they should open a new thread with the details and link to it from their reply here. No logs should exist in announcement threads :slight_smile:

Hello,

Please, can you help me?

After upgrading to the 2.4 version, the Network Binding can’t search things in the INBOX. It justs don`t find any equipment in the network, before upgrade it was finding a lot of devices and services.

And i’m also trying to make the MQTT 2.4 binding work too… in this case, when i try to manually add an MQTT Broker, i got error 500 when i try to save the configuration in Paper UI.

Thanks in advance.

Please open a new discussion for your issues, as it would attract more readers.

I have found the problem with the Insteon PLM binding, nothing to do with OH2 or the binding (my appologies).

It turns out I installed a new OS in November. Recently I installed ser2net to configure the Insteon USB Modem.
Seems that the default for ser2net is to automatically start up on boot. As this is connecting to the port that the Insteon PLM is on, it depends which starts first as to which claims the port.

Disabling ser2net fixes the issue.

Just download the 2.4 stable distro from openhab.org

Windows Defender is showing that their is a virus included within the zip.

@Kai is this a false positive you are aware of?

I can’t reproduce.

I just scanned openhab-2.4.0.zip on my Win 10 Ent x64 (17134.472) with both Kaspersky Internet Sec 19.0.0.1088(d) and Win Defender (1.283.1594.0):

C:\openHAB2\runtime\system\org\openhab\core\org.openhab.ui.homebuilder\2.4.0\org.openhab.ui.homebuilder-2.4.0\web\dist\build.js does not come up as a false positive.

Anyway, I reported it to https://www.microsoft.com/en-us/wdsi/filesubmission

latest antimalware definitions: from here: https://www.microsoft.com/en-us/wdsi/definitions

2 Likes

Same here.

1 Like