Preparation for 2.5M2

The 2.5M2 release has been held up for several reasons. The main one has been the actual ability to build the release, but this has just been resolved (:partying_face:). However, there’s still the question of whether 2.5M2 is ready to be released. There have been many changes since 2.5M1, so I thought it would be good timing to get a post going with a live list of the current major issues that the testers in the community feel should be addressed before the release, as well as a list of new features that people will want to know about when deciding whether to upgrade. This is a Wiki post, so please add anything you are aware of!

The enumeration is just to help identifying the items… not priority/severity

  • Outstanding Issues

    1. [core] Serial ports need to be added to EXTRA_JAVA_OPTS, even if they have valid names. Otherwise, the serial port dropdown will only contain the first port selected. github
    2. [core] High load (there’s a working fix but there are open discussions) github
    3. [ngre] Paper UI (JSON) rules fail to load after ESH reintegration github
    4. [ngre-scripts] Scripts do not load after OH startup on Windows github
    5. [hueemulation] Several open issues and adds all Items unless they have been tagged with ‘internal’
    6. [mqtt] Several open bugs
    7. [zigbee] Periodic crash (haven’t seen anyone else reporting this and seems to be resolved after fixes for 2) github
    8. [zwave] Commands no longer sent after daily heal (haven’t seen anyone else reporting this) github
    9. Bindings needing attention due to 3rd party libraries: allplay, amazondashbutton, bluetooth github
    10. SSE breaks due to BundleException in SseActivator.start() gihub
  • Functionality fixes, improvements and changes since 2.5M1

    1. [core] Package name changes, which can potentially affect people’s scripted automation (the JythonHLs have been updated and are backwards compatible)
    2. [core] Rollershutter profiles github
    3. [core] Player profiles github
    4. [core] Timestamp profiles github
    5. [core] kvarh and kvar units github
    6. [core] Added i18n feature for dynamic state descriptions github
    7. [core] Increase DateTimeType parsing and formatting precision github
    8. [core] Small UoM evolutions github
    9. [distro] EXTRA_JAVA_OPTS can now be set in environment variable or start.bat (Windows) github
    10. [ngre-ui] Added Jython and Groovy scripted Actions and Conditions github
    11. [ngre-ui] Rules start when OH starts github
    12. [ngre-ui] Rule enable/disable functions properly and persist after restart github
    13. [ngre-ui] Unhide Cron triggers in UI github
    14. [ngre-ui] Unhide DayOfWeekCondition in UI github
    15. [ngre-scripts] Fixed custom module handlers (i.e. JythonHL StartupTrigger) github
    16. [ngre-scripts] Script load order change github
    17. [ngre-scripts] RefreshType, REFRESH and BinaryPrefix added to ‘default’ preset github
    18. Everything in here
    19. [harmonyhub] Binding will support WebSocket connection only, instead of XMPP forum github
    20. [harmonyhub] Two new channels (buttonPress and player) github
    21. [core] Karaf 4.2.6 github
    22. [rules dsl] RefreshType, REFRESH and BinaryPrefix added to default imports github

Here’s an official list…


If possible and applicable, the tradfri binding issues with new ikea firmware update. Numerous threads in this one. I know an issue was filed on git but don’t have a reference right Now.

This byno means impacts core functionality.

Edit: link


I don’t know if it’s relevant, but I also mention it:

[harmonyhub] Binding will support WebSocket connection only, instead of XMPP.
See forum topic and on github!

And will support two new channels (buttonPress and player)! See here on github and in documentation.

1 Like

I think both of those would be relevant and useful information… I’ll added them!

1 Like

If you’re expecting a lot of stability from a milestone build, you might be disappointed when running into issues like:


It is clear that from a milestone with stability one can expect, even in 2.4 there have been, it seems to me, 7/8 milestones.
What do you think is important for starting a milestone cycle?
I followed your enormous effort :clap:, but I lost myself among the many problems !!! :sweat_smile:

The first one is already in the list (#9), but the issue you linked provides some more details. I’ll add the SSE issue.

I agree with:

It’s hard to recommend someone to use a new milestone release when it’s very likely there will be critical issues right after installing it. It makes a bad impression on first time users who might immediately stop using openHAB. So it should work pretty well without resorting to all sorts of workarounds.


New channels to Kodi binding as well? There are new ones, but in the docs it stated that 2.4 includes currenttime and other channels already but I can’t see them. So if this is only included in 2.5 (and the docs are wrong) there are a plenty of new channels there also.

Recreating your Kodi Thing might fix that because existing things aren’t properly updated. See:

But on the other hand goal was to deliver a milestone every month and I guess quite some frequency is needed to get new features/bindings/bugfixes out to more people. Especially after the bigger technical change that will be required to spot the bugs to get to a next release.

Nevertheless a bug making the system generally unusable I’d suggest to be blocking (like the “[core] High load”). Problems with a certain binding I’d comment on when publishing the Milestone.

1 Like

Competition 1000%

Perhaps we can learn something from a company like Microsoft (no flaming, please) with their Windows 10 release cycle? And it is similar to other release cycle with a ‘Release’, ‘Beta’, ‘Alpha’ type of approach.

Let’s take Windows 10 as an example. For the general public Windows 10 basically has three release cycles:

  • Stable branch (don’t even start! :grin:) - released twice a year. In OH terms that would be like 2.4.x, 2.5.x, 2.6.x, 3.0.x, etc. to be released when ready.
  • Insiders preview ‘slow’ branch - released more frequently but no fixed cadence and reasonably stable, no known breaking issues. In OH terms that would be like a milestone release that is suitable for a wider audience, aiming at bi-monthly I would suggest.
  • Insiders ‘fast’ branch - released quite frequent, usually even more than once a month, but can have some issues/limitations. In OH terms that would be like a monthly release I guess, and the audience would be people that can work with releases and switch between them, troubleshoot, etc.
    And for developers and daredevils, there are of course the nightly builds (snapshots).

The primary reason to bring this up and suggest to consider an intermediate ‘release branch’ is that I have the feeling that releasing a monthly milestone release that is stable enough for many users can be quite a challenge in terms of manpower needed. On the other hand, there is also a need for a fast release cycle to leverage the latest and greatest without great risk to break things (any change to a running IT system can cause issues, believe me, I know!).

For a wide audience OH will have to strike a good (subjective term, I know) balance between fast development/release and stability. As can be seen with HA, people like it’s features but hate its breaking releases. ‘We’ should be different.

I realise that a release mechanism like suggested also results in extra work, but I still wanted to bring it into the discussion.

Just my two cents…


This is exactly the plan - fix the blocking regressions and do a new milestone build by then. Milestones are not meant to be “release quality”, so no need to do a fine-grained issue tracking across all bindings etc. It is ok if milestones have bugs, but they should be usable in general.

@noppes123 Thanks for your input. I think what we have in place more or less exactly matches, what you describe: The official releases (target: twice a year) are the “stable” ones, the milestones are the “previews” and the snapshots are the “insiders” builds.

It is only that the whole bnd-build change disrupted our schedule since January and we didn’t have monthly milestone builds since then - this is what we are trying to get back to.

@5iver & all: What do you see as critical bugs left that need to be fixed before a 2.5.0.M2? The CPU load issue is imho one, another one might be the CCE in the SSEActivator. Anything else?

1 Like

I see all of these as critical…

1. This one will cause issues for anyone using more than one serial device.
2. Definitely a blocker, but there may be a workaround.
3. A migration script needs to be built.
5. hueemulation is currently non-functional, and IMO, this should be a blocker due to the number of people using this binding.
7. Possibly related to 2.
8. Possibly related to 2.
9. allplay and bluetooth could have enough usage to call this a blocker
10. Blocker, but there may be a workaround.

I’m not as concerned about these…

  1. Since this only affects NGRE on Windows after a restart, IMO it’s not a blocker.
  2. I don’t have input for this one, as mqtt is working for my very limited (Owntracks) purposes with mosquitto as the broker.

The Mqtt binding works actually. Open issues are mostly enhancement requests if you see the Homeassistent part as still being in beta.
Unfortunately I lost the Mqtt Homeassistent contributor due to the buildsystem change.

The underlying paho library with its really sad state atm causes problems for script users though. I’m thinking of changing the library after OH2.5 has been released.

Hue emulation also works, but expects json type http posts. Alexa has a defect thought and is sending json with the mimetype plain. There is a fix pending on hueemulation to act more relaxed.

So not working. :slight_smile:

@5iver I have created for further tracking.

  • I didn’t include (1) as I understand that this might have been in 2.4 and 2.5.0.M1 as well - so no immediate regression.
  • (5) Do we have an issue for this?
  • (9) I thought to understand that the OSGi-ifying was only relevant for running the bundles in the IDE, but that they are working in the distro?


I did not experience this issue before the zibee and zwave bindings (the only bindings I have using serial) were migrated to BND.

There are several, but I don’t recognize one specifically for the issue David mentioned…✓&q=is%3Aissue+is%3Aopen+hueemulation+-label%3Aenhancement+

I could be mistaken, but I thought there was more to this PR. @J-N-K, could you please confirm, or were the issues reported for allplay, amazondashbutton, bluetooth, etc. something else?

Something in between.

  • Allplay has native code, this is not properly declared in the current bundle. This will be solved with the osgiified-bundle, it is also possible to add the osgiified-library in the /lib folder as a workaround.
  • AmazonDashbutton is not installing all dependencies (like XMPP). This can be fixed by removing “dependency=true”. For XMPP I raised #5707 because it is not depending on the OSGi dependency but some other problem. This oculd be done for dashbutton, too
  • BlueZ is a mystery to me. I reverted the lib upgrade done during the migration and added the native code. This SHOULD work and does in my testing VM. But there seems to be a difference between x86 and ARM, which I can’t explain ATM. I’ll see if I can find a Raspi somwhere in the basement and debug it there. Since I don’t own the hardware, it’s a bit difficult.
1 Like