Why not make a M2 and mention those problems in the release statement?
Aren’t those M* meant to be steps toward the next release (2.6) and if we wait for every binding then M2 will be in 2020 …
1 Like
I thought they were steps toward 2.5. Did I miss the memo?
With the lack of forward progress for such a significant amount of time, releasing something that is crippled like @5iver mentioned I think would be a step backward.
Waiting a bit longer for a release will show the community that the wait is worth it…
Please note I am not trying to persecute anyone for the slow updates, just stating facts. We all know how much of a major infrastructure change is occurring and it will take time to get it right. In my humble opinion get it right then release it…otherwise we’ll just be emulating HA.
My .02
Squid 
3 Likes
You will need to work long & hard to get that unstable.
So, far HA has had 2 releases in 2 days. Last major release, the first patch came out the same day. All of this within the past month.
1 Like
I agree, but we may not find out how sever it is until more people are using the snaphots. I recently went a couple rounds with this one after trying to get Zigbee manually installed again, which I did not succeed at doing. There’s something fiddly with using both zwave and zigbee bindings. After removing the manual installs and installing through addons.cfg, zwave was getting this error. I had to restart the binding (quickest way I found was renaming the controller) to get it to work, but it did not always come online and needed a restart. I think the thing that finally fixed it was to add my ports back to EXTRA_JAVA_OPTS, which I had removed after OHC #805.
As a community, I think it is best to not put out a release with regressions to existing functionality. For things like emphemeris, which is newly introduced, I don’t see why we couldn’t release in a broken state with a note about it, but there’s an open PR that will likely resolve that issue. To avoid delays like this in the future, major changes would need to be done in a feature branch with minor features and fixes being merged into that branch and to master. This adds overhead in release management that would reduce the manpower we have for development and assumes people would want to contribute their time in this capacity. This is not likely to happen considering the size of the OH team.
My question back to you… what is the benefit of rushing it? If someone wants to use the current code with these known issues, they can install the latest snapshot.
3 Likes
an ocd thing 
I don‘t know where you see „lack of progress“.
1 Like
The problem with the Z-Wave binding is the only problem I am encountering with the snapshot 1641. This is probably again a new start order of things problem.
Just to be clear: I only want to consider issues that are clear regressions since the M1 build. Any other issues that have been there before (and that might also be considered critical by some people) should be fixed before the final 2.5 release, but not necessarily the M2.
@5iver What issue references from your OP do you consider to meet that definition?
@morph166955 Please don’t describe issues here in this thread, but only reference Github issues. Wrt JUPnP, afaik, nothing has changed about it, so it sounds rather unlikely to me that there’s a regression since M1.
Wrt the Z-Wave issues: @chris, could you chime in and give your opinion of what there definitely still needs to be done before a M2 can be built?
I’ve seen similar behaviour with my Z-Wave roof shutters. They used to respond almost simultaneously but that changed a while ago.
However… since I moved my roller shutter logic from Rules DSL to JSR223/Jython I don’t recall seeing a significant lag between the shutters.
I tend to believe that it’s the rules DSL compiler that takes time to compile the rules file, which may explain the performance hit and subsequent delays. In particular if your rules logic touches the rules files in between runs (then the rules will be compiled every time the file was touched).
I have not really had a good chance to look at this as I’ve spent so much time over the past few weeks just fighting the build system to get ZWave and ZigBee working. I’m hoping we’re getting closer to getting this working and I will then find some time to look over this - hopefully this coming week.
2 Likes
All of them except for ephemeris (new feature), the one for scripted automation on Windows (low impact and has an easy workaround), and mqtt (working for me).
I just updated my zwave binding to the latest snapshot a few hours ago. I am on 2.5M1 but have been running the snapshot binding.
I noticed none of my Things had configuration menus until I deleted & rediscovered the Things. All looks normal now, for my small network though.
I really can’t see why there should be ANY interaction between them - unless something in the underlying serial drivers is causing an issue. The bindings themselves are totally independent.
I don’t think this is a binding issue - again, this is likely to be a problem with the underlying serial driver in OH (ie the ESH serial abstraction). I seem to recall in the past there was some discussion about bindings being able to start before the serial abstraction system had loaded and you simply need to wait until the startup is complete.
Did you refresh the browser? I can’t see any reason that the config menus would not be there. The configuration information is served up outside of the binding - OH core reads the XML files from the binding on startup and provides this information to the UI. If the thing types were known, then there’s nothing else the binding can do I think.
Yes that could be a problem not directly in the Z-wave binding but note that I run several other bindings using the serial abstraction and only the Z-wave binding has this problem at startup.
This is relatively new.
Yes, and I looked both in Habmin & Paper UI. I also tried restarting the binding & OH. Most of my device data in the DB should have been the same.Perhaps the XML files changed slightly between snapshots.
No - the files don’t tend to change unless someone updates the database. It’s unlikely that all your devices would have been updated, and even if they were, it should not matter as the format is the same - it hasn’t changed for many years.
1 Like
Strange - maybe for some reason the ZWave binding starts faster or earlier or something. I’m not sure, but I really can’t see how the binding can impact this as it’s the serial driver that returns the error.
I don’t think anything has changed in the binding for quite a while (many months) in this area. At the moment I’m not even in a position to develop and test the binding for the past month due to IDE issues.
My guess is that this is possibly a timing issue and something has changed in your system that has changed the startup timing. (again, that’s just guesswork).
Sure, that’s gonna be a whole lot of fun when all those openHABian users on OH 2.5.0.M1 open the openHABian-config tool and select option 2 “Upgrade system” and all of a sudden ‘everything’ is broken. The same for all the linux users when the issue sudo apt update && sudo apt upgrade.
Did you forget the mess that was caused by the MQTT v2 binding with the release of OH2.4.0? That was only one binding and it was unexpected. Now you want to intentionally break many peoples system?
1 Like
I could probably have phrased that better. What I was trying to say is that since it has been quite some time we have had a new release (minus the nightlys) lets make sure it’s as functional as it can be.
2 Likes