I could be mistaken, but I thought there was more to this PR. @J-N-K, could you please confirm, or were the issues reported for allplay, amazondashbutton, bluetooth, etc. something else?
Allplay has native code, this is not properly declared in the current bundle. This will be solved with the osgiified-bundle, it is also possible to add the osgiified-library in the /lib folder as a workaround.
AmazonDashbutton is not installing all dependencies (like XMPP). This can be fixed by removing “dependency=true”. For XMPP I raised #5707 because it is not depending on the OSGi dependency but some other problem. This oculd be done for dashbutton, too
BlueZ is a mystery to me. I reverted the lib upgrade done during the migration and added the native code. This SHOULD work and does in my testing VM. But there seems to be a difference between x86 and ARM, which I can’t explain ATM. I’ll see if I can find a Raspi somwhere in the basement and debug it there. Since I don’t own the hardware, it’s a bit difficult.
Problems with the serial driver have been there longer, with symlinks not working proberly, and not optional from PaperUI. I cant tell for how long though, but this problem was in 2.4 as well.
The latest problems given zigbee and specially z-wave devices problems, was added somewhere in 2.5, where things went from bad to worse… Or in my personal opinion - a disaster!
It seems to be fixed for me with the changes in PR #866.
It’s only an issue when using bindings that use the new serial transport (org.eclipse.smarthome.io.transport.serial) instead of gnu.io directly. In 2.5.0-SNAPSHOT these are: DSMR, EnOcean, PowerMax, RFXCom, Serial Button, Smartmeter, Plugwise, ZWave.
It’s unrelated to the bnd migration. E.g. ZWave switched to using the serial transport in #1152. So the issue is becoming more visible now more bindings are being adapted/implemented using the new serial transport.
As I mentioned in the PR, this looks to be working for me too. It’s not merged yet, but I’ve crossed this one off the list. Your efforts are very much appreciated!
That would be nice too. yet with all the changes that happened, I understand a stable build without too much “new” stuff.
first have the build stable, then make small next steps…(where I do hope it is one of the things fixed)
To provide a little context why this would have hit a lot more people in 2.5.0.M2 if it had not been fixed is that the ZWave binding in 2.4.0 did not use the new serial transport. This has been introduced in one of the 2.5.0 snapshot builds to allow people to share the Z-Wave dongle over IP.
We should not do M2 with known not-working-at-all problems for bindings. This is at least true for BlueZ (which i still do not fully understand but can be fixed at least temporarily) and Allplay (which is reported to work but not merged).
I can not find a specific issue on this on github. My sitemaps are having issues updating on both the web and android app since moving to the nightly builds after M1. Specifically, I use an item to handle visibility to reduce how much is on the screen at once. For example, I may have one that gets set to “TV” or “ROKU” so that only controls for that device in the room are displayed. In the past, when I hit the selector it would change what is on the screen. Now, I am presented with this error in the log file and nothing on the screen updates. If I refresh the page the correct content is shown.
2019-06-24 12:35:18.245 [WARN ] [pse.smarthome.core.items.GenericItem] - failed notifying listener 'org.eclipse.smarthome.io.rest.sitemap.internal.PageChangeListener@5fad6063' about state update of item PrimarySelector: null
java.lang.NullPointerException: null
at org.eclipse.smarthome.core.items.dto.ItemDTOMapper.fillProperties(ItemDTOMapper.java:152) ~[137:org.openhab.core:2.5.0.201906210301]
at org.eclipse.smarthome.core.items.dto.ItemDTOMapper.map(ItemDTOMapper.java:138) ~[137:org.openhab.core:2.5.0.201906210301]
at org.eclipse.smarthome.io.rest.core.item.EnrichedItemDTOMapper.map(EnrichedItemDTOMapper.java:56) ~[?:?]
at org.eclipse.smarthome.io.rest.sitemap.internal.PageChangeListener.constructSitemapEvents(PageChangeListener.java:242) ~[?:?]
at org.eclipse.smarthome.io.rest.sitemap.internal.PageChangeListener.constructAndSendEvents(PageChangeListener.java:174) ~[?:?]
at org.eclipse.smarthome.io.rest.sitemap.internal.PageChangeListener.stateChanged(PageChangeListener.java:188) ~[?:?]
at org.eclipse.smarthome.core.items.GenericItem$1.run(GenericItem.java:262) [137:org.openhab.core:2.5.0.201906210301]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
@morph166955 Thank you for reporting the error. It looks like a new one. May I ask you to open an issue in this Git repository. Is it possible to add a minimal example to reproduce it? I will look into it. Thanks in advance.
As #5706 seems (since today) to be nearly done and #5503 is (hopefully) only waiting for some repo transfer from @Kai.
Does anyone feel able to provide a solution for #674? It is on the blocker list and is without any comment since Apr 10th.
It seems like some (rather small) script could do the deal. Any (migration) script experts around?
(Sorry for not providing a solution but only tracking the progress towards one)
There is a manual workaround and it would be a small subset of people that would be affected (NGRE, JSON rules). Markus provided an example of how this could be resolved for MapDB. I plan to look into this after migrating/fixing/reenabling the automation itests, if someone hasn’t already gotten to it.