I didn’t look too closely at the associations - there are plenty (ie hundreds) of meter reports being received and most are not being processed to channels. This indicates that the associations are set, but something else is wrong. Also the report was that the control chnnel is being updated, so again, this indicates that associations are working.
Maybe there is also an association issue - I don’t know, but we should work out why the meter requests aren’t being processed.
I guess we need a clearer report on the issue. I was going to suggest initially that he should use 2.5 which has steps to better set the associations, but as the report was that control reports are working ok, and I do see unsolicited reports being received, I was focussing on other areas. There may be a combination.
I see mass config updates for each of the nodes. What would cause that? I wonder if he’s using PaperUI to edit the config, as that’s the only thing I know that can cause that… There seems to be something weird about it because it seems to consistently cause the group 3 association to be removed.
@rjduraocosta What do you use to manage your zwave nodes? Paper UI or HABmin? If you use Paper UI, can you try using HABmin instead?
Amongst other things. The format is processed against a number of different options to try and resolve strings, or string arrays (ie arrays that are passed in as strings rather than lists which is meant to be handled in ESH). However the other thing is that it also explicitly forces associations for the ZWave+ lifeline, or controller groups - ie it will not allow users to remove these associations.
Thank you very much for analysing my issues. The channel that is not even beeing updated and I use in my rules is the Sensor Power channel.
Concerning the update procedure I am following the steps to update openHAB for my system that is windows and for the binding I am following all the steps above in the first post of this thread so that I do not miss anything. I used PaperUI to configure the things, but also tried Habmin with the same results and pending messages when saving the parameters.
The log that I provided was from a fresh install of openHAB, where I just installed the zwave binding and added all the zwave things (in PaperUI), controller and fgr-222 modules.
Another issue that I found is that when I fresh install, or upgrade to 2.4 and I add the things, fgr-222 modules, there are some parameters that do not have the same values as they have when I am at 2.3.0. I always have to change them to the value that they where, it seems like that the confuguration stored inthe modules does not get well read by the binding (I don’t know if I am explaining this well) This does not happen on all modulesand I have seen this behaviour on PaperUI and Habmin:
Here’s my take on what’s happening. I’m using node 7 as an example. If you think I have this wrong, please let me know what I might be misunderstanding.
For some reason, the device is not responding to the command to get Config Parameter 1. This is introducing a fair bit of delay in initializing node 7. The device also is not responding to the command to get config parameter 2, which is introducing even more delay in initializing node 7.
At this point, the binding hasn’t read all the config parameters from the device (specifically, it has not read config parameter 13 from the device). Then you used Paper UI to make a config change, which sent updates for ALL the config parameters. However, at this point config parameter 13 in the binding is the default value of 1.
The binding finally gave up trying to get config parameter 1. It then SETs config parameter 13 to the default, as you directed it to do when you used Paper UI to update the config. This is why, IMO, you should not use Paper UI to administer zwave devices!!!
I have no idea why the device is not responding to the GET for config parameters 1 and 2. Perhaps they are not supported by this version of the device firmware?