Preparation for 2.5M2

[cweitkamp (Christoph Weitkamp)]

@morph166955 My test setup for Basic UI (see https://github.com/openhab/openhab-core/issues/897) 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 https://github.com/openhab/openhab-android/pull/1174#).

[Andrew_Rowe]

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

[marcel_erkel]

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

[marcel_erkel]

@David_Graeff

no chance of any bugs fixed for 2.5.0

Yup that’s how it is atm.

@David_Graeff

Regarding MQTT. The thing is that the underlying library (paho mqtt) is full of bugs and only maintained by one guy that only occasionally works on it and currently focuses on mqtt5. And its an eclipse project

paho would need to be replaced by that other mqtt library (forgotten the name but linked in one of the issues). That’s unfortunately a Core contribution, which I’m clearly not doing at the moment.

paho has several subscription bugs with the async API that I’m using. Most of the java people out there seem to use the synchronous API which apparently works (most of the time). I don’t see a point in working around in the mqtt binding when the actual bugs are further down in the stack.

@rlkoshak

So MQTT 2.x is essentially abandon-ware. Wonderful.

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

[bjoernbrings (Björn Brings)]

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.

[marcel_erkel]

I hope you read those threads too

@Kai

So the first step for which we use our new ability is to provide milestone releases from now on. The plan is to have roughly one milestone release per month. They are meant to be a pretty good compromise between the nightly snapshots and the official releases. I know that many of you are using snapshots even for their production system (me included) and you continuously run the risk that you catch a snapshot that completely breaks your system. Waiting for a new release is no option either, if you want to use new features that only recently made it into the code base. With the new milestone builds, we will make sure that those builds work in general and that they should not have any (known) critical issues. They should therefore be a nice option if you want to be on the latest&greatest, but want to avoid the risks that are associated with snapshots builds.

(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.

@5iver

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.

(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.

[weakfl]

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.

[Bruce_Osborne]

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.

[chris (Chris Jackson)]

@weakfl

If I’m not mistaken, there are still problems building the zigbee binding?

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

[rlkoshak (Rich Koshak)]

@marcel_erkel

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

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.

@Bruce_Osborne

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.

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

Can't read swagger JSON from https://openhab.koshak.us/rest/swagger.json

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.

[Bruce_Osborne]

@rlkoshak

he REST API Docs are pretty important for some use cases.

That’s why I reinstalled to 2.5M1.

[5iver (Scott Rushworth)]

@rlkoshak

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

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 openHAB JAX-RS publisher by maggu2810 · Pull Request #905 · openhab/openhab-core · GitHub.

[Kai (Kai Kreuzer)]

Just as a reminder: We have https://github.com/openhab/openhab-distro/projects/2 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 https://ci.openhab.org/view/Sandbox/job/sandbox-openhab2-release/ - 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 .

[shutterfreak (Olivier Biot)]

@Kai

Some bad news: Meanwhile, we again have issues with the build pipeline, see https://ci.openhab.org/view/Sandbox/job/sandbox-openhab2-release/ - 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 .

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

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

[bjoernbrings (Björn Brings)]

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

[bjoernbrings (Björn Brings)]

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.

[morph166955 (B R)]

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.

[gozilla01 (Michele)]

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

[Kai (Kai Kreuzer)]

@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 https://github.com/openhab/openhab-core/issues, it would be much appreciated!

[Kai (Kai Kreuzer)]

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?