How have you installed your system? Is it just a ‘plain install’ or do you use apt-get or another packaged version?
Another point is that the distribution only completed at 3:02 and you wrote your message at 3:08, so maybe it hadn’t completed when you tried?
Plain install (I’m on a mac). I just tried to update again … no luck. 
Depending on how you are updating, there is a repository cache folder that needs to be manually cleaned out. If you don’t do this, you will end up running older versions of some things.
You can check this from the console by typing
bundle:list|grep -i zwave
If there are two listed, you can use bundle:uninstall to remove the older one. If only the older one exists, then perhaps there was a problem with the build. I see there is another newer one that is green now since your last post.
I only had one wave bundle installed, and I was trying to do bundle update from the console.
Anyway, it worked now - I have:
204 | Active | 80 | 2.0.0.201610152054 | Wave Binding
I’m not quite sure if that’s the same one you’re referring to @xsnrg - it’s not obvious to me how the timestamp here matches up to what I see here:
(I assume this is the correct place to be looking). There it looks like build 113 completed at 10:52pm, which doesn’t match my timestamp (unless they’re in different timezones or something?
Anyway, back on topic @chris, this seems to done something! Nodes 33 & 34 now seem to be fully initialised (I see the xml files). Thanks so much!
However, as you can see below, I have two Aeontec multi sensor6’s which aren’t fully initialised.
Node 35 is plugged into USB, whilst node 30 is just battery powered.
I’ve put the log file here
When you included these devices into the network, were they powered as they are now? If you change power type after it is included you will have no end of problems as the ZWave protocol doesn’t permit devices to dynamically change their classes.
I’m very sure that node 30 was on battery. I’m about 80% certain that node 35 was connected to USB. I’ll be back at my house on Tuesday and so I can try to exclude/include them.
I was following along in this thread with some interest until I checked my own zw100 (1.6). It had been online and reporting all of the other metrics from the sensors without problem, and is in a remote building, so never had cause to look at the motion sensor. Out of curiosity, I did look at it now, and the motion detector is undefined. I am not sure when it happened as it had been working well for quite some time, so I will dig in and pull some debug logs to see what I can see.
After removing and re-adding, then discovering a bad item entry that kept saying NULL, I believe my problems are in the past. Mine is initializing properly it seems. I do have quite a few timeouts, and some parameter issues to look at for v1.6, but it is working fully.
20:07:12.384 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Error parsing bitmask for config_100_1_wo
20:07:12.384 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Size error 2<>1 from config_42_2
20:07:12.384 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Size error 2<>1 from config_44_2
20:07:12.384 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Error parsing bitmask for config_110_1_wo
20:07:12.384 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Size error 4<>1 from config_255_4_wo
20:07:12.402 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Initialising Thing Node...@chris
After this update I’m unable to get my fibaro FGD-212 (Dimmer2 firmware 3.5) recognized (In previous version it worked)
Not sure it is related to this at all.
Some logs
http://pastebin.com/rNhXrJh2
I have a full log file at:
http://www.zoidberg.se/pub/zwave.log
It’s node 20.
Regards S
I’ve tested the 2016-10-13 version also but without success.
I Still get:
2016-10-17 11:03:29.623 [WARN ] [ocol.ZWaveController$ZWaveSendThread] - NODE 22: Too many retries. Discarding message: Message: class=SendData[0x13], type=Request[0x00], priority=Config, dest=22, callback=160, payload=16 02 72 04
2016-10-17 11:04:55.708 [ERROR] [ve.internal.protocol.ZWaveController] - Neither inclusion nor exclusion was active!
2016-10-17 11:04:55.838 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 22: Device discovery could not resolve to a thingType! 7FFFFFFF:7FFFFFFF:7FFFFFFF::0.0
2016-10-17 11:04:55.902 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:be1078de:node22' to inbox.
2016-10-17 11:05:04.178 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 22: Initialising Thing Node...
2016-10-17 11:05:49.546 [ERROR] [alization.ZWaveNodeInitStageAdvancer] - NODE 22: Node advancer: Retries exceeded at MANUFACTURER
I’ve not looked at the log yet, but I’ll need some reasonable debug information to look at this. It’s strange that there appears to be no communication with the device, and I would suspect (just from the limited information I’ve looked at) that this may not be a binding issue. I don’t think anything has changed in the binding that would impact the initial stages of downloading the devices information, and normally a timeout (ie the “too many retries” message) would indicate that the controller can’t talk to the device.
Is the device quite far from the controller? Even if it’s been working, the RF environment might be changeable? (just a thought without having looked at the detailed logs).
Hi Chris!
Yes the node is pretty close say 3 meters. I’ve also located my controller as close as 1 meter under it with the same result.
This appeared when I removed the device and attempted to readd it. When re-adding it, it fails do determine manufacturer it seems. As far as I can see there is communication with the device, it’s marked as ONLINE in paperui,
See attached screenshot:
I can also exclude it without problems. And When I include it again it pretty much immediately finds it.
But it fails to sort out the type of device (Previously it was recognized)
The log shows that the device is not responding to any requests for the manufacturer information - I’ve no idea why though .
Thanks for the quick response Chris. I’ll try and do a hardware reset and see if something happens
I feel guilty for having you look through those logs. A hardware reset did the job now It’s fully recognized again in the z-wave biding. I guess there had to be some malfunctioning between the controller and the unit.
Thanks again,
S
No problem 
my AEON ZW100 still ever gets stuck at STATIC_VALUES
anything additionally I can do to support to find the root cause?
just wanted to ask if there is an update to this?
the AEON Multisensor 6 still gets stuck on STATIC_VALUES during initalization
cheers
No - to be honest I’m not sure of the link between the Fibaro dimmers to the Aeon multisensor?
Mine works fine here - Which version are you using?
Can you check the log to see where it’s getting stuck?
give me a day 
