Preparation for 2.5M2

@morph166955 My test setup for Basic UI (see now (build OH 2.5.S1634) is working without any error message. Do you think it could be an issue with the App? AFAIK there was a recent change of the handling for invisible widgets (see

So… are we ready to fire up ?
Build system sorted?

There are 16 items on the list in the opening topic, 7 of which are still open. What do you think?

Is there any way that a binding can be marked as experimental?

Hope you read those threads before offending anyone …
Its not the goal to solve all problems before releasing a milestone but those that affect many users. The bugs which have been named during duscussion are all solved.

So the question regarding what is missing to get the milestone out is quite valid.


I hope you read those threads too :slight_smile:

(Bold by me)

Yes, the idea is that milestone builds are released roughly each month and we all know why that process has stalled.
More importantly though, they should not have any (known) critical issues.

(Strike-through by me; these issues have been fixed)

I’m sorry that I value the opinion of those who contribute to the code higher than the opinion of the ones that don’t.

Patience is a virtue.

1 Like

If I’m not mistaken, there are still problems building the zigbee binding? There’s an open PR to update the ZSS library to v1.2.1.

I don’t know if this should make it into M2, maybe @chris can elaborate.

I have not checked in about a week but I think the api docs broke again. It could not load the JSON file.
Since I am experimenting with the API I moved back to the M1 build.

Yes, there are still problems. Maybe they are resolved this morning as I’ve seen some mails, but I’ve not tried myself.

1 Like

I don’t think so. One could make a note in the docs for the binding perhaps.

It’s mainly the Homie stuff that is experiencing problems if I understand correctly. I imagine the HA stuff might have some similar problems as well, though I’ve not seen any reported yet though I don’t follow the Issues as closely as some.

In my experience so far, the Generic Thing stuff works pretty well, well enough that I wouldn’t call it experimental.

I can confirm. I updated to the latest snapshot yesterday and I’m getting

Can't read swagger JSON from

I don’t see that in the list in the OP. I couldn’t find an open issue so I created one.

@5iver, should this be added to the list? The REST API Docs are pretty important for some use cases.

1 Like

That’s why I reinstalled to 2.5M1.

I expected this one was going to be fixed pretty quickly, but go for it. Your issue should be in OHC though and likely related to

1 Like

Just as a reminder: We have for tracking the really critical issues, so if you have open issues that MUST be fixed for M2, please ask here to have them added (all openHAB-Distro maintainers should have the rights to do so).

Some bad news: Meanwhile, we again have issues with the build pipeline, see - we didn’t have a successful build for more than 2 weeks again, so this is something critical that needs to be addressed as well, before we can do a milestone build :cry:.


It appears that the failing build is only due to one missing POM file:

[INFO] Downloading from central:
[WARNING] The POM for org.openhab.util:pax-web-patch:jar:1.0.0 is missing, no dependency information available


(Small Remark: The problem of the last day has meanwhile been solved)


There we go. The build is up and running again. Thanks @kai for the quick fix after @shutterfreak analysis.
Now it’s “only” about solving the bugs seen as critical.


I’ve been trying to track an issue down for a few days and I’m at a loss at this point. Since moving from M1 to the M2 nighties I’ve noticed that some of my rules are, what I can only say from “gut feel”, not multi-threading properly. Where things would run in parallel before they now run serially.

I’ll give an example that may help. I use Sonos speakers across the house with PollyTTS to send auditory alerts for different things. Each Sonos has a separate (but identical and generated by script from a template) set of rules to make this work properly. On M1, all 4 speakers would fire almost at the same moment (assume a few milliseconds of lag at most for >95% of the time). Now, for no reason that I can find, they fire serially. Duration of what is said is irrelevant. One second or thirty seconds, they fire one at a time. One will speak, then the next, and so on until they all speak. I’ve gone through and increased all of the relevant org.eclipse.smarthome.threadpool items in services/runtime.cfg to make sure there are enough threads available.

I’ve also noticed that the updates to the bus by the rules can be severely delayed (order of seconds). Again, not sure why this is happening but when comparing the log files I can see the logInfo pop out of my rule and then the events.log shows the item update much later. It’s almost like some thread is getting hung up and holding up the updates. Historically I would see no more than a 250ms lag.

From a hardware perspective, my OH2 instance runs on an Ubuntu VM in an ESXi cluster. The servers are xeons with lots of ram. The VM itself has been given a substantial amount of CPU and RAM to see if that helps. It seems to have almost no impact. I’m on nightly 1640 right now also for reference.

Again, this is just a gut feeling of where the problem may be based on observation.

1 Like

I remember a PR on core that spoke of this between @maggu2810 and @Kai

@morph166955 This sounds a bit like the effects I was afraid to see in this comment. We weren’t able to find any reproducible proof for such concerns. If you can come up with a simple setup that shows the difference, it would be perfect. I am aware that this might be very tricky as it requires certain hardware like Sonos speakers, but that would be ok. If you could describe this in a new issue at, it would be much appreciated!


Besides the last regression mentioned above, does anybody have further critical issues that need to be addressed and that might render a complete binding unusable at the moment? @J-N-K, are the 3rd-party lib issues with AllPlay, Bluetooth, etc. fully solved?

1 Like