[SOLVED] OH2.5.4-1 Zwave stick keeps restarting

tomekz28 · May 10, 2020, 11:22am

Hi,

(not sure why I cannot post this question to the zwave subforum - getting server error, when trying to do so)

I have searched the this comminity for an answer, have found similar ones, but none of the solutions I found fixed my problem I have. After upgrading to OH to 2.5.4-1 from 2.5.1 or somewhere around there, I am not sure at this point, my z-stick started restarting every few minutes and after an hour of so of doing this OH comes to a complete halt.

I have done the usual: inspected addons.cfg, cleared cache, rebooted, deleted addons.config, and so on, but still no luck. I think I had a similar problem about half a year ago, but upgrading fixed it. Now, I am running the latest stable release.

One of the interesting points I found int the log is that I do not have aeotec_zw141(seen in the log)
Any help would be greatly appreciated, perhaps there is a new snapshot of the zwave binding I could use, but the latest one I found is the 2.5.1 version.

Tom

My openhab.log looks like this:

2020-05-10 13:15:11.623 [INFO ] [zwave.handler.ZWaveControllerHandler] - Attempting to add listener when controller is null
2020-05-10 13:15:16.847 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller
2020-05-10 13:15:16.849 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.
2020-05-10 13:15:20.629 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 39: Restore from config: Error. Data invalid, ignoring config.
2020-05-10 13:15:20.634 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 38: Restore from config: Error. Data invalid, ignoring config.
2020-05-10 13:15:51.072 [WARN ] [.ZWaveThermostatSetpointCommandClass] - Reached max tries to init the setpont Furnace, this will be our last attempt
2020-05-10 13:16:08.241 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing ‘openhab-action-mail, openhab-action-mqtt’
2020-05-10 13:16:11.656 [ERROR] [ng.xml.internal.ThingTypeXmlProvider] - Could not register ThingType: zwave:aeotec_zw141_03_000
java.lang.IllegalArgumentException: ID segment ’ switch_dimmer’ contains invalid characters. Each segment of the ID must match the pattern [A-Za-z0-9_-]*.
at org.eclipse.smarthome.core.common.AbstractUID.validateSegment(AbstractUID.java:97) ~[bundleFile:?]
at org.eclipse.smarthome.core.common.AbstractUID.(AbstractUID.java:75) ~[bundleFile:?]
at org.eclipse.smarthome.core.common.AbstractUID.(AbstractUID.java:49) ~[bundleFile:?]
at org.eclipse.smarthome.core.thing.UID.(UID.java:48) ~[bundleFile:?]
at org.eclipse.smarthome.core.thing.type.ChannelTypeUID.(ChannelTypeUID.java:40) ~[bundleFile:?]
at org.eclipse.smarthome.core.thing.xml.internal.ChannelXmlResult.toChannelDefinition(ChannelXmlResult.java:135) ~[bundleFile:?]
at org.eclipse.smarthome.core.thing.xml.internal.ThingTypeXmlResult.toChannelDefinitions(ThingTypeXmlResult.java:98) ~[bundleFile:?]
at org.eclipse.smarthome.core.thing.xml.internal.ThingTypeXmlResult.getBuilder(ThingTypeXmlResult.java:148) ~[bundleFile:?]
at org.eclipse.smarthome.core.thing.xml.internal.ThingTypeXmlResult.toThingType(ThingTypeXmlResult.java:156) ~[bundleFile:?]
at org.eclipse.smarthome.core.thing.xml.internal.ThingTypeXmlProvider.addingFinished(ThingTypeXmlProvider.java:148) [bundleFile:?]
at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.addingFinished(XmlDocumentBundleTracker.java:265) [bundleFile:?]
at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.parseDocuments(XmlDocumentBundleTracker.java:424) [bundleFile:?]
at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.processBundle(XmlDocumentBundleTracker.java:398) [bundleFile:?]
at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.access$6(XmlDocumentBundleTracker.java:393) [bundleFile:?]
at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker$2.run(XmlDocumentBundleTracker.java:363) [bundleFile:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_252]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]
2020-05-10 13:16:11.867 [INFO ] [zwave.handler.ZWaveControllerHandler] - Attempting to add listener when controller is null
2020-05-10 13:16:17.086 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller
2020-05-10 13:16:17.088 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.
2020-05-10 13:16:21.034 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 39: Restore from config: Error. Data invalid, ignoring config.
2020-05-10 13:16:20.980 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 38: Restore from config: Error. Data invalid, ignoring config.

mhilbush · May 10, 2020, 11:34am

This doesn’t look normal. Maybe try deleting and re-adding these nodes. Don’t exclude/include.

This definitely isn’t right. I don’t think either of these OH1 bindings exist anymore. If you’re seeing this error occur every 60 seconds, there’s a slow memory leak that will eventually cause your system to run out of memory. The time it takes to run out of memory varies based on the configuration of the system.

This is fixed in more recent versions of the zwave binding.

tomekz28 · May 10, 2020, 11:42am

Mark,

Thank you for your repy.

I am not sure why these are showing up in the log: I have deleted them from things via habmin. Node 38, 39 are obsolete, I do not have any hardware associate with them (used to long time ago).

Will do so, thank you.

If you could point me to the latest version jar version of the zwave binding I would be very thankful, the latest I found is the 2.5.1.
Tom

rossko57 · May 10, 2020, 11:46am

You do need to look harder at the addons.cfg / addons.config business. This the restart cause.

mhilbush · May 10, 2020, 11:48am

That’s odd. There must be something that’s causing these to show up. If the binding thinks these still exist, it may cause some performance issues with your network (such as when the binding tries to poll these devices, or when the nightly heal runs).

All artifacts can be found on the Jenkens build site.

https://ci.openhab.org/view/Integration%20Builds%20(2.5.x)/job/openHAB2.5.x-ZWave/lastSuccessfulBuild/artifact/target/org.openhab.binding.zwave-2.5.5-SNAPSHOT.jar

tomekz28 · May 10, 2020, 12:07pm

Unfortunately now I am getting this. I did set the ownership to openhab:openhab and permissons to -rwxrwxr-x.

2020-05-10 14:00:28.819 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.zwave-2.5.5-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [203]
Unresolved requirement: Import-Package: org.eclipse.smarthome.io.transport.serial

at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]

mhilbush · May 10, 2020, 12:12pm

You need to install the dependent feature manually. I forget the command to do that. Give me a minute.

I think this is it. Do this from the console:

feature:install openhab-transport-serial

Bruce_Osborne · May 10, 2020, 2:19pm

Welcome back.

The zwave tag tends to do that but the z-wave tag works so I have tagged this thread for you.

I think that may have been fixed in a later snapshot. Try the installer script.
Zigbee and Z-Wave manual install script - Tutorials & Examples - openHAB Community

tomekz28 · May 10, 2020, 7:43pm

Thank you for your help. The problems have been resolved.

Bruce_Osborne · May 10, 2020, 7:46pm

Unfortunately some developers have little warning before a stable version is released. This particular time thy caught one of the extremely rare times where the Z-Eave binding was broken.

tomekz28 · May 11, 2020, 10:12am

Mark et al, last question if I may: how do I ensure that feature openhab-transport-serial gets activated everytime I start OH? Now I have to do it manually after every restart…

mhilbush · May 11, 2020, 12:03pm

That shouldn’t be the case. You should only have to install it after an upgrade. The reason you need to do it after an upgrade is because userdata/tmp and userdata/cache are cleared.

I can’t explain why it’s happening after every restart. But if for some reason it keeps happening after a restart, maybe you should try installing the zwave binding using @5iver’s install script as mentioned above by @Bruce_Osborne.