Preparation for 2.5M2

I would be surprised if he feels the same about 1178. Please review this comment. It would be great if @digitaldan could test again to see if he is still experiencing this too.

To summarize the issue, after a daily heal kicks off on a snapshot build of OH, the zwave network response is very slow and devices drop offline. The only remedy I’ve found is to restart OH and disable the daily heal.

This may also be one to get cleaned up… [basic] Frame visibility in sitemap ignored until refresh github. There was a related issue in Android, but that should be resolved in the next build.

does that mean now that z-wave in M2 is not really usable?

Only he can tell, but as @chris is the maintainer of that component, I am listening to his decision.

@Kai @chris is currently in the US on a business trip He is checking here periodically though.

Just to get a broader feelign of the problem:

Is anyone here using snapshots and ZWave and can either report it to be working or to be unusable?

It would be great to merge the PR to fix the iCloud binding SSL issue (mentioned here).

No problem with Z-wave in snapshot 1650.

1 Like

I can report zwave snapshot binding working for me on 2.5M1 install. I have disabled the nightly heal.

1 Like

Yes, I’m using the latest snapshot versions quite successfully in several installations. I’ve disabled the nightly heal due to this problem that I first reported in January. It’s quite likely that the problem existed before that. The workaround for this issue is easy. Just disable the nightly heal, and then run heal selectively if there’s an issue with your network.

This problem reported by @5iver sounds more severe, but I’ve not experienced it.

Edit: I should add that one network is about 100 nodes. Another is about 20 nodes. The other ones are small and used mostly for testing purposes.

1 Like

Can you point me to the PR? I don’t find it.

@wsd33904 could you post a link to your PR to fix the iCloud SSL issue for @J-N-K? Thx!

@J-N-K I can’t find the PR either, but this should be the relevant commit in @wsd33904’s fork.

Not noticed any problem with snapshots and z-wave. Using 1650 at the moment. Didn’t change any heal settings. 25 nodes, 8 are battery ones from different manufacturers.



I have worked around a hueemulation pax-web problem which happend to users that ran hueemulation in debug log level mode. The affected user reported that he could successfully use hueemulation with Alexa in debug and warn log level.

I do see hueemulation being ready for a 2.5m2 release. A few more compatibility tests with Google Home and different Alexa firmwares would be helpful for the final 2.5 release as well as an https strategy for openHAB, because that is required by newer Hue API versions.


Sorry about that, I forgot to create the PR last night. Here is the link:


Ok, thanks everyone for the feedback!
So I would say that the z-wave problem does not seem to be a general one as the binding seems to work well for quite some people. I’d hence stick to @chris decision to not consider it blocking for M2 (while possibly blocking the 2.5 release, but that’s for the future).

Also thanks to @David_Graeff - I understand that hueemulation is also in a state that is ok for M2 (while not for a 2.5 release).

I’ll therefore trigger the M2 build in 30 minutes - let’s touch wood that it succeeds!


Hm, I am afraid, I had no luck.
It might be that the milestone build plan (or rather the checked in Jenkins pipeline) is not up-to-date as the sandbox pipeline is not using the checked in definition, but a different one.
I guess I will need @pfink’s support to figure out what to do - I hope he can quickly come up with a solution that makes the build succeed!

1 Like

It seems to be caused by the Slack plugin (see So updating or disabling it will probably fix it.

I’m not so sure. The sandbox build is using the slack plugin as well and the milestone build failed with the message:

groovy.lang.MissingPropertyException: No such property: removeTagIfExists for class: groovy.lang.Binding

which does not seem to be related to Slack…

On the other hand: “removeTagIfExists” sounds like a task AFTER the build, so you might be right that the build is considered to have failed before that. I’ll disable the Slack plugin and try a new run…