Zwave/Habmin - Association Groups not stored anymore (since zwave update)

Hi, anyone else experiencing strange behaviour of zwave since the big changes in zwave?
Some of my rules simply do not trigger my plugin switches anymore…as a side effect i see for example that several things simply do not permanently store the association groups…i change it, press save but when i come back later - again no entry in this field…

Anything i can do to change this?

btw…did yesterday again remove everything (things + controller thing) and add it all again (about 40 devices)…but still association groups only partly are stored…pending all the time even if the e.g. wall plug switches are next to the controller…

@chris can you make any rhyme out of this … i know that the devices have to get in touch first to take these updates into their config…but even after a day nothing is stored…so most if the devices simply do not work properly as they never update their states…

I’m not sure - maybe the wakeup has not been configured. It should normally be configured automatically as part of the initialisation, but there are some conditions where it will not be set, and some devices don’t use the auto wakeup.

I would suggest to wake up the device manually. If that is not working either, then get a debug log so I can see what is going on.

Thanks a lot chris. i now again cleared the xml files to generate from scratch…what i now found out is that for PAN11 switches for whatever reason there is no xml generated. Any idea why. These seem also to be the ones that make some troubles…also i see a “node initialization” message. not sure if this is a problem i should fix…
Maybe something missing in the DB?


Normally this is caused by the device doing something non-standard. We need to find out what that is, and then there will normally be a configuration in the database we can use to work around the problem.

First though is to get a log of what is happening. I would guess that probably there is an error in the database with possibly a config parameter that is not present in your device (based on it being in the GET_CONFIGURATION state).

my pan11 work
please note that there are versions from hauppauge that report with same type/IDs but e.g. do not send meter reports… just in case someone starts fiddeling the DB :slight_smile:


Thanks @shorty707. @norbert_jordan - what version is your device (this is the firmware version in the properties list).

Hi Chris…all my PAN11 say FW v1.1

One question regarding AssociationGroups…when i change the group to controller it is shown in Habmin even if i come back later. After a reboot on many nodes its again a “blank” field or an [x] but no “string” showing the group. Is in such a case still the association group stored already in the node itself? or something went wrong and after an openhab reboot it still should be shown in habmin?

I see similar behaviour - even with devices that initialise correctly. Association groups either start showing up blank, or with just an X.

Ok, so we might need to create a new version of the device as yours is an older version than @shorty707. Let’s see.

It should be stored. Unfortunately, there is a bug in the widget that HABmin uses, and the display is broken, but as the widget is not supported any longer, it’s not easy to fix. The association is “probably” set, but it’s hard to be 100% sure from the UI (and I think PaperUI also has a bug in the selection widget so it might also not display correctly).

@chris I now have logs to a frustrating behaviour since the major zwave update. several of my nodes (wall switchplugs) that do not react to rules at all. I have logged in debug mode and you can find the link below to download the openhab.log (please let me know if events.log is relevant as well).

An example for this behavior,…a light HouseNr_Switch should go on when its getting dark. From events.log you can see that this seems to be triggered:

2018-10-03 18:28:00.027 [ome.event.ItemCommandEvent] - Item 'HouseNr_Switch' received command ON
2018-10-03 18:28:00.039 [nt.ItemStatePredictedEvent] - HouseNr_Switch predicted to become OFF

However the switch never goes on…you can even see that there is no log saying canged from OFF to ON…
Its the node25…HouseNr_Switch. Can you please check what is the reason that some of my switches do not react to rules anymore…!AqVcwrl1pLMGv1P9qo7X7wJRFHoq


I can’t currently work out how to extract this file - can you provide a ZIP, or uncompressed file please. Also, what node do you want me to look at?

sorry…its now zipped.!AqVcwrl1pLMGv1TJmbq4HaVZF58k

As written above, its Node25 (HouseNrSwitch) that does not switch ON if a rule requests so. Its happening to several other nodes as well since the major update few weeks ago. Thanks for checking, hope you find something that helps to fix this.

This will not be related to associations then. Associations are used for the device to report back to the controller if its state changes and it will not impact the sending of commands TO the node.

Please can you provide the file just zipped - not 7zip’ed. I don’t have any software to extract the .7 file.

hm…its simply zipped with winzip not 7-zip. Guess you know that logs are rotated. So this is a simple txt file in the zip which is called openhab.log.7 like openhab.log.6 or openhab.log.5…can you please try. or remove the .7 so its only called openhab.log. should work hopefully.

Sure i know that the association group problem is a problem related to call back from the node to the controller, this should not be related (at least from my idea of zwave systems)…

many thanks.

Sorry - I thought this was 7-zipped…

The log shows that all messages to this node are timing out. As above, this is not related to association groups.

hm, but how can this node than be online all day long ?


There are some messages received so it will be online at least some of the time.

hm…for this node it may be comprehensible as it is rather far from the controller (next house)…so maybe this is an/the issue for this node. However i have another node that does not listen to rule based triggers since major update. Will try to catch such situation and kindly ask you to check again. For this one the distance is about 3 meters from the controller…so different kind of story. Thanks for now for checking…