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.
2 Likes
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!
2 Likes
Maybe this can be solved with the new milestone build too?
1 Like
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)
2 Likes
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.
But no one is able to share it over IP as far as I’m aware?
But that IMHO is not a show stopper for 2.5.0.M2 and therefor something for a different topic.
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).
1 Like
I agree. Please provide issue numbers that you think should be put on the list.
1 Like
Bluetooth/BlueZ: https://github.com/openhab/openhab2-addons/issues/5680 (PR: https://github.com/openhab/openhab2-addons/pull/5706)
Allplay: https://github.com/openhab/openhab2-addons/issues/5643 (PR: https://github.com/openhab/openhab2-addons/pull/5503)
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.
// Edit: I filed the issue on my own. It was possible to reproduce the NPE. See https://github.com/openhab/openhab-core/issues/897 for more details.
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)
If that’s not a blocker, #8 should be. The issue you linked to is preventing #8 from being resolved.
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.
2 Likes
@5iver Have you tried the latest zwave snapshot? I’m curious if the removal of the event stuff in PR 1192 might possibly resolve this.
1 Like
S1624 and zwave 2.5.0.201906270431… kicked off a heal and sending commands to zwave devices has no effect… same issue.