Newbie: How to use the Expiration Delay Metadata

A zniffer output would be one option or Providing the make and model of the switch and I’ll look it up.

The not so short story is that if it is missing you will need to get access to the community database, make an update to the device XML and then after a few days when the changes are approved and incorporated into the binding use the updated Zwave snapshot. I’m assuming you are on 3.1 at least, or there are more issues to getting things updated.


Mine is a GE 12722 - is that the right make/model info you are looking for, Bob?

So good news and bad news. The device is in the database as Zw4005 and does appear to be set-up to read both basic and switch binary command classes, so that is not the issue. The bad news is I don’t know why it’s not working then. That was my best and only idea .



So, I took a look at the network_xxxx_node_25.xml file (corresponding to this Thing) in /var/lib/openhab/zwave. In that, I saw the following snippet:


So, looking at it, I DO see the


listed but NOT


I am on 3.1 Openhabian version. Thoughts?

Edit: I did not go down far enough. In the “supportedCommandClasses” section of the XML further down, I see:


So, back to square one. Drats.

It appears that zniffer is no longer available for download anywhere (not that I can find). Do you have a way to get it? Would it be useful in debugging my sorry situation here?

So, I do believe the device supports sending manual changes, since it seems to work with my other software (see post a few above). However, I do NOT find an Association Groups section in the Thing’s options (even with “advanced” checked). Any thoughts on that?

There is a posting on zniffer (I think under solutions in the forum) set-up earlier in the year, but since the device appears to be set-up correctly and from your debug log, I see good and fast zwave communication it don’t think it will help here, although it is a good idea for your next project.

I looked at my GE switches and they do not have Association groups either. (just noticed this after many years). Anyway they work fine. Not that it matters, but they are not Zwave Plus devices, just regular Zwave and only transmit at 40Kb, not 100Kb like zwave plus

Separately I’m wondering if adding the metadata “auto-update” to the switch “item” might help.

Edit: Link to Zniffer instructions and other useful info

Tried setting auto-update to true on the point - no help :frowning:

Autoupdate is of no value in obtaining external status updates. Mostly, it actually masks many problems in this area.

The autoupdate was a hail mary.

At this point I would suggest manually operating the switch while z-wave is debug mode and look to see 1) if there is a message and 2) what seems to be happening to it. As these files can be big, try to minimize other zwave activity. Sometimes I’ll have the device right in front of me, switch to debug, do the tests and switch the binding back to Info. (Trying not to have my wife wandering around tripping sensors and lights :wink:


That was actually pretty straightforward. And the answer is - there are NO debug messages when the switch is operated, ON or OFF. Total silence.

Yet, there MUST be something ‘in the air’ that is not caught by OH, because my older system caught it and reacted to it immediately. So, the problem is at the driver level? Does that make sense?

It appears that the database entry for your device is malformed. There are no association groups configured.

This is why there are no association group options being rendered on the thing details screen for you. Presumably this is also why you are not getting any updates from the device because the lifeline (association group 1) is not set to controller at the moment as OH doesn’t know to do that and therefore the controller is not the target of the status updates from the device.

You need to check that the xml file you have does include a section on association groups and then work to update the database at OpenSmartHouse Z-Wave Device Database (click on the database user guide link in the banner to get started).


The only reference I found to association groups in the XML is an empty one:

<associationGroups class="concurrent-hash-map"/>

Is this OK?

The association group concern is beyond my knowledge. I agree there is “typically” a lifeline association for most devices. My counter observations are:

  1. the device seems to send and receive messages (pretty quickly too) from and to the controller during initialization (Post #18)
  2. I have three older GE/Jasco switches that work fine (both OH and manual control & UI updates), also without an Association group shown in the UI (ZW3101)
  3. Normal zwave routing is back along the last working route, so if the controller sends a message to the device (which it appears able to do), the device should send any message it has back along the same path. It has to send back an “Ack” to the controller for every command it gets and the controller needs to “hear” the Ack" or it will keep sending the message
    But again??

As to no traffic from a manual operation in Debug mode, I’m also puzzled. Since you were getting messages on your old Windows system from manual operation, something zwave should have been broadcasted by the device and picked up by the controller and either rejected or accepted by OH.

A some random thoughts

  1. Was the device completely removed from the old software and factory reset
  2. Do you have the Silabs (or Aeotec) PC controller program to look at the nodes on your stick (are there ones you don’t recognize?
  3. Was the Z stick factory reset before you started with OH? I’m not sure just transferring the stick between applications is a good idea.
  4. You mention Rpi and Aeon Zstick. If Rpi4, are you using a USB 2.0 hub or do you have the latest Zstick model? Early sticks do not work without the hub. (I don’t think this is an issue here, but added for completeness.

This is really a nasty one.


Reminder that openHAB actively initializes devices. If it is doing something like setting association group to null, it matters little that it works with other systems that initialize it differently.
If in-service messages are not designated for “our” controller, they won’t show up in the debug. See @JustinG above.

This is, I think (85% confident), independent of the issue at hand. I don’t think there’s any problem with the device being able to communicate with the controller. The problem is whether or not the device targets the controller for its messages once it is operating.

I’m stretching my memory here, but I believe that Lifeline as a standard is only a feature of ZW+. If these devices predate that then that may be the explanation for those missing association groups.

Right. But a status update from the device has to be addressed to the controller for it to use that last working route. My hypothesis here is that the device doesn’t know (for some reason related to how OH is currently handling a lack of association group 1) that node 1 should be the target destination. Wouldn’t that also explain the lack of any debug logging here?

The lack of association groups is probably correct then and this is just not a ZW+ device.

I think I’m kind of on the same page that’s why I asked some clarifying question about how the device and stick were reset between the old system and new. The device could still have the old system zstick ID and be sending the manual messages to the wrong ID, but responding to OH messages too? Will need to see the answers.

My GE devices are not ZW+ and I don’t think his is either.

OK, I went back and looked at my “old system” carefully - note that it was a purchased system that came up and “just worked” as I more or less wanted, so never really bothered to look under the covers as to how it was accomplishing what it was. But now I did, and after a few different experiments and poking around I discovered that the way it “just worked” was:

  • If the thing is a newer model item that supports associations, it uses the associations/lifeline to get updates.
  • If the thing is a legacy item with no associations, it simply polls it every 30 seconds. :scream:

So, at least the mystery of “but it used to work before!” is solved. I really think this is not going to work without polling. I know and understand how much of an anathema that is- trust me I have a Master’s in CS, and over 4 decades of experience in various systems including RF (but not ZWave), and understand that the use of polling in an inherently event-driven system is to be avoided. But, I don’t really see a way around it, without going out and spending 100’s of $$ on new ZWave+ equipment, since most of my equipment is legacy.

Anyone have any other thoughts? Otherwise, we can consider this topic closed.

I was wondering about that option. However, I have a graveyard of zwave devices that I didn’t like how they work and just buy newer and better having learned what to look for. Although retired, I do value my time. If it’s just the one switch, in the US about $30 for 700 series, longer range, etc. versus getting a non-ZW+ device to work. Anyway best wishes. I hope I was helpful in someway.


Are you kidding? You were EXTREMELY helpful, as were the others on this thread! I do get this is a passion for you all, and deeply appreciate the time that you take to clarify things for new users. I am getting started on this journey, and you are right, I probably will start replacing items one by one to make it easier on the budget. There are only 2 or 3 items that I need reporting to the controller on state change, and those I can have polled. The others are exclusively controlled by the controller buttons, and those I don’t need to poll. Anyway, I will start off with that, and see where I get.

Figuring out scripting is my next learning curve!

Again, thanks so much for taking the time!