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.
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.
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.
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!
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…
