Double check that your items are properly linked to channels for your managed items. I bet if you look at the channels for a Thing in Habmin or PaperUI, that you will not see any links.
If you need to redo all of the links, you may become an items file convert…
Well, it looks like I would have bet and lost… the item looks like it is still linked. What happens if you delete the link (not the item) and then relink the item?
Same result.
I did note an interesting behavior. The old item (item created by habmin/paperui) does not control the device and throws the error.
When I click the one from the items file, it controls the device and a second later the old item updates with the new status of the device.
I just updated to 1361, created a managed item linked to a Z-Wave Thing, and…
2018-09-13 12:48:56.985 [ERROR] [org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler] - An error occurred while calling method 'EventSubscriber.receive()' on 'org.eclipse.smarthome.core.thing.internal.CommunicationManager@ad062db': null
java.lang.NullPointerException: null
at org.eclipse.smarthome.core.thing.internal.AutoUpdateManager.receiveCommand(AutoUpdateManager.java:141) [114:org.eclipse.smarthome.core.thing:0.10.0.201809111909]
at org.eclipse.smarthome.core.thing.internal.CommunicationManager.receiveCommand(CommunicationManager.java:266) [114:org.eclipse.smarthome.core.thing:0.10.0.201809111909]
at org.eclipse.smarthome.core.thing.internal.CommunicationManager.receive(CommunicationManager.java:145) [114:org.eclipse.smarthome.core.thing:0.10.0.201809111909]
at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [108:org.eclipse.smarthome.core:0.10.0.201809111909]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [108:org.eclipse.smarthome.core:0.10.0.201809111909]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
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) [?:?]
2018-09-13 12:48:57.003 [ERROR] [org.eclipse.smarthome.core.internal.events.EventHandler] - Dispatching/filtering event for subscriber 'org.eclipse.smarthome.core.events.EventSubscriber' failed: null
java.lang.NullPointerException: null
at org.eclipse.smarthome.core.thing.internal.AutoUpdateManager.receiveCommand(AutoUpdateManager.java:141) [114:org.eclipse.smarthome.core.thing:0.10.0.201809111909]
at org.eclipse.smarthome.core.thing.internal.CommunicationManager.receiveCommand(CommunicationManager.java:266) [114:org.eclipse.smarthome.core.thing:0.10.0.201809111909]
at org.eclipse.smarthome.core.thing.internal.CommunicationManager.receive(CommunicationManager.java:145) [114:org.eclipse.smarthome.core.thing:0.10.0.201809111909]
at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [108:org.eclipse.smarthome.core:0.10.0.201809111909]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [108:org.eclipse.smarthome.core:0.10.0.201809111909]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
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) [?:?]
Looks like you found a bug! Would you like to create an issue for it in the ESH repo? If not, I can write one up.
I think I have a workaround… if you edit your item, you’ll probably notice that the Auto Update field is empty. When I created my item, I intentionally left this blank. When I select an option, I no longer get the error.
I’m not sure I can really describe the issue adequately at my level of expertise…
I modified one of mine as you mention with something selected in the the autoupdate field.
That does stop the error…but, now I’m back to being able to control none of my device. The log shows the change events but nothing happens.
Tried a reboot, nada.
I’m seeing some strange things happening with this build too. At first I thought everything was slow, but I’m starting to wonder. I’ve restarted OH and will give it an hour to settle (lots of devices). It may be recent changes in the binding too.
Ok…that was weird.
Before the reboot I removed the old item that I had selected the autoupdate field.
Just now was poking around looking at items and things in PaperUI.
Then I heard the relay in the 3 devices near me click. Annnnd, now I can control everything just fine with items in the .items file.
But is it really slow? The light I was testing with will respond at times, but not others. When it responds, there is a big lag.
Before I did the reboot and just after I selected autoupdate, clicking an old item would result in activation of the device some 10’s of seconds after the click. After a couple of test clicks and waiting, the device no longer responded at all. After that, no devices could be controlled.
Now, after the deleting of the old item with autoupdate and my last two posts, I’m getting faster response on my farthest devices than I ever have… 
Weird… I had major lag… minutes worth. Then nothing would respond. Same version of binding too, so that wasn’t it. Then everything started working in real-time again, so I think it was just 10-15 minutes to get everything settled after a restart.
Are you all sorted out now?
So far.
I’m adding items for each of my things in the .items file and removing the old habmin/paperui created items.
So far all is good and something just triggered the rule for driveway motion sensor and it did it’s daytime thing (I’ll test night action after dark.)
I’ll post if it goes south. 
Ok, so working basically. But, after any change is made, any device action is really slow for some number of minutes.
Then it seems to be fine.
Belay that, I now have no control over my devices. Log says:
2018-09-13 16:10:33.390 [ome.event.ItemCommandEvent] - Item 'Plug_11' received command OFF
2018-09-13 16:10:33.402 [nt.ItemStatePredictedEvent] - Plug_11 predicted to become OFF
2018-09-13 16:10:33.428 [vent.ItemStateChangedEvent] - Plug_11 changed from ON to OFF
But, nothing ever changed state
Footnote:
After a while things started to respond, but there seemed to be a lag between activating an item and device state change. Also, and this could have been the delay, items never seemed to update after a change.
After letting things settle in over night there is no perceptible lag.
Another footnote:
For the last 24 hours I was not getting meter updates from the NAS-WR01ZE metered plug.
I just noticed it is now working.