Zwave: Node initialising: STATIC_VALUES

Sorry for misunderstanding. I mean the problem of the binding probably not being updated (automatically). It wasn’t about the problem of the device.

This one: Do I get the latest update with apt-get? Helping eyes needed!

Sorry - I hadn’t seen that thread.

I see elsewhere that people have been able to update to the latest version compiled tonight - I’m not sure how the apt build is built and distributed - it may only be nightly (??). If so, given that builds have been broken for the past few days, it may not update until tonight.

Even after:
bundle:update 204

I still see:
204 | Active | 80 | 2.0.0.201610120746 | Wave Binding

I’m not quite sure what else to try! Well, I guess I should try to manually download the binding next, but I’m trying to do this at the same time as cooking dinner, which is making everything take a while.

Not sure but @shorty707 seemed to be able to update to the version this evening…

I tried again and it finally updated the binding, but node 33 is now reporting ‘Node initialising: UPDATE_DATABASE’

I now see the following:

  • node 9: Node initialising: WAIT
  • node 21: Node initialising: PING
  • node 23: Node initialising: GET_CONFIGURATION
  • node 27: Node initialising: WAIT
  • node 29: Node initialising: WAIT
  • node 30: Node initialising: WAIT
  • node33: Node initialising: UPDATE_DATABASE
  • node35: Node initialising: STATIC_VALUES

I’ve put a logfile here

This might be relevant?
2016-10-13 11:06:42.281 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 33: Node advancer: UPDATE_DATABASE 2016-10-13 11:06:42.283 [ERROR] [ve.internal.protocol.ZWaveController] - Exception during ZWave thread: Input 2. {} java.lang.NullPointerException at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveCommandClass$CommandClass.getCommandClass(ZWaveCommandClass.java:622)[204:org.openhab.binding.zwave:2.0.0.201610121647] at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.advanceNodeStage(ZWaveNodeInitStageAdvancer.java:715)[204:org.openhab.binding.zwave:2.0.0.201610121647] at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.handleNodeQueue(ZWaveNodeInitStageAdvancer.java:230)[204:org.openhab.binding.zwave:2.0.0.201610121647] at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.ZWaveIncomingEvent(ZWaveNodeInitStageAdvancer.java:1294)[204:org.openhab.binding.zwave:2.0.0.201610121647] at org.openhab.binding.zwave.internal.protocol.ZWaveController.notifyEventListeners(ZWaveController.java:546)[204:org.openhab.binding.zwave:2.0.0.201610121647] at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingRequestMessage(ZWaveController.java:249)[204:org.openhab.binding.zwave:2.0.0.201610121647] at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage(ZWaveController.java:213)[204:org.openhab.binding.zwave:2.0.0.201610121647] at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$7(ZWaveController.java:207)[204:org.openhab.binding.zwave:2.0.0.201610121647] at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveInputThread.run(ZWaveController.java:1303)[204:org.openhab.binding.zwave:2.0.0.201610121647] 2016-10-13 11:06:47.109 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 33: Timeout while sending message. Requeueing - 2 attempts left!

Same error as Exception during ZWave thread: Input 2. java.lang.NullPointerException

I got two of my FGD-212’s initialized and serialized to nodeXX.xml now.

Cloned the binding from git, removed the next line from the device definition and recompiled the binding locally:
<property name="commandClass:ASSOCIATION_GROUP_INFO">ccRemove</property>

I guess you have the version that has fixed firmware - lucky you :slight_smile:

Probably, but I couldn’t get it to work with that line in the device file :frowning:

No - as above, we’re trying to fix this for the version that is broken, so sorry for the hassle… It will be resolved in the next day or two.

@chris I’ll be at my house tonight and so able to trigger devices etc. Let me know if there’s anything I can do to help you debug this?

If you can grab the latest version (ie todays) it would be useful to see what is logged. I updated the logging last night so if it doesn’t work I’d like to see the log.

So - update the binding, delete the XML and restart - send me the log if it doesn’t work…

Thanks
Chris

Okay, I just arrived and have updated the bundle to:
204 | Active | 80 | 2.0.0.201610140851 | ZWave Binding

No xml to delete for nodes 33 and 34 because they never initialised…

BTW some nodes which HAD worked before, now seem stuck (e.g. node 28)

Logfile is here

Hmm. @chris I might have just worked something out… I had some typos in my .items file, and now that I fixed them, several Things seem to be initialized! This wasn’t expect, at least to me … I thought that the Things initialization was independent of the items associated to them.

I now have node33 on ‘Node initialising: STATIC_VALUES’

An updated logfile is here

Edit: btw the refresh happened here:
2016-10-14 20:56:25.792 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'rambert.items'

Thing initialisation is independant of items - there’s definately no link so if something changed, it’s probably coincidental.

Yes - this was in the log I looked at earlier. I still need to think through this. It means that the bug from yesterday is fixed, but there is still something else at play that I need to work out.

Unfortunately this device also reports this command class into the endpoints, so I need to remove these as well. I’ve made a fix, but will merge it tomorrow.

Okay thanks a lot! I’ll keep an eye out for an update.

just curious how you read this… is it because after that ASSOCIATION_GROUP_INFO_GET it ends in an Message retry?

I am investigating also on static values not advancing for a device … hanging maybe at the same issue?

Yes, this looks similar…

The binding here is sending the request, it receives the response from the stick to say it received it, and it then receives the request packet which tells us the device also received it. We don’t however receive the data that we asked for, so the transaction times out.

What device is this from?

One of the Aeon ZW100
There are multiple versions by firmware in the DB … Need to look when i am back Home.

I guess it should be http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/73