Z-wave - Inclusion finished without lifeline association set

Add-ons Bindings
, ,
1

Hi

I’m a tester at Sensative AB for our line of Strips, Z-wave devices. Strips is a battery operated device with three different variants: Strips Guard (door/window sensor), Strips Comfort (lux & temperature sensor), Strips Drips (leakage sensor).

For some time now, we’ve had some customers report issues including our devices in openhab. When testing, i was unable to reproduce the issue myself. That is until recently when i was doing some compatibility testing with the latest milestone build, 2.5.0.M5 (windows version), were i think i might have come across the same issues that our user’s have faced, although i’m not sure exactly what triggers it.

I started out with a hard reset on my z-stick to clear it of all previous z-wave devices. I thereafter continued by adding a Strips Guard to the system and got it working ok immediately. I excluded the device and included again, still fine.

On the third attempt though, the interview was cut short by the controller sending WUNMI (Wake Up No More Information) before the Association Set command was sent to Strips, i could see this in the z-wave sniffer logs that i had running at the time. Without the Association Set command, Strips is left without a lifeline and thus doesn’t know who to send open/close commands to. This results in Strips blinking five times for open events (our standard failure LED indication). If i in the Papper UI, under Strips’ settings, assign the lifeline association towards the controller and wake it up 3 times (not sure why it takes so many NIF - Node Information Frame - events for controller to send…) it gets the association ID and is able to send open/close.

In my fourth inclusion attempt i again did not get Association Set. This time i decided to test repeatedly waking up Strips (sending NIF) to see how long it would take to complete the interview. It took a staggering 15 manual wake up commands before association was sent normally. The reason so many wake ups were required is because the controller keeps sending WUNMI after only one or two reports instead of sending all the reports at once.

I also had the debug logs running in openhab while testing. I’m not too familiar with the system myself so i can’t really tell why the system sends WUNMI so early. Perhaps someone else here is able to understand why? Link to z-wave sniffer and debug logs:

The .zlf files can be opened with the SiLabs zniffer tool if you have it.

I’m currently testing with a milestone build so i imagine there may be some bugs and room for refinement, but i am also quite sure that similar inclusion issues exists in the current stable build 2.4.0. I’ve personally seen association issues in that firmware although wasn’t able to reproduce after accidentally reseting the controller. :stuck_out_tongue_winking_eye:

Has anyone else had issues with lifeline association not being set during inclusion?

Some other posts i found that seemed to show similar issues:

2

Yes, it sometimes can take many wake ups to fully initialize battery devices, especially those devices that support a large number of command classes, have many config parameters, and/or many associations.

I had a discussion with @chris a while back about the duration of the timeout during inclusion of battery devices. Let me see if I can find it.

3

@Jonathan_Bjarnason Here are the links to the discussions.

4

Thanks for the links @mhilbush !

So the WUNMI commands i see in my zniffer logs are a side effect of the changes @chris pushed in December 2018 in order to fix a separate issue.

A quote from @chris in the keyfob discussion:

The change was required - it is much worse bug without this as it means that the binding thinks the device is awake even when it went to sleep a long time ago. This then causes all sorts of timeouts and lost data. Fundamentally this is now the same as we had in the past.

Could you enlighten me as to what this previous issue was which warranted the change? Did the controller not send WUNMI at all prior to the change?

Furthermore, from your discussions in the keyfob post; it seems as though @chris hasn’t had the time to look into these inclusion issues any further. I can’t seem to find the problem either in the list of active issues on the git repo. Is anyone working on this issue?

5

Exactly. It stayed in the AWAKE state, and this means that all commands fail. This causes a load of problems as it slows down transmissions to other devices as well, and ultimately ends up with the device being marked as DEAD.

As I’ve said, I’m quite busy with ZigBee work and unfortunately I need to support these customers which leaves me with little time to work on the unpaid work at the moment - sorry. I’m not really aware of any major issue with what you are calling “inclusion”, but I’ve not had the time to look at your posts.

No - please feel free to take a look.

6

Exactly. It stayed in the AWAKE state

I would agree that is definitely a much worse issue, especially in our case since Strips uses a non-replaceable battery. Saving on battery usage is quite important for us. Not putting battery operated device to sleep for it’s periodic wake up command does indeed cause a major drainage in the long run.

I’m not really aware of any major issue with what you are calling “inclusion”,

Inclusion is a z-wave term for adding. Essentially what is happening is that openhab is putting the device to sleep before all commands have been sent. A quote from @mhilbush in the keyfob post he linked:

This device, because of the large number of config parameters, associations, and command classes, will require many, many wake-ups in order to fully initialize.

also as he stated earlier:

Yes, it sometimes can take many wake ups to fully initialize battery devices, especially those devices that support a large number of command classes, have many config parameters, and/or many associations.

It seems as though battery operated devices with several supported command classes will need wake up and equal amount of times to get all these commands across. This sounds reasonable, as when i look through my zniffer files i see that the “go to sleep” command (WUNMI) is sent after each group of command classes. Openhab will for example send:

  • Association Groupings Get
    And get back a:
  • Association Groupings Report
    From the device. And then end with:
  • Wake Up No More Information
    Which puts the device to sleep.

After waking up the device one or two more times, it seems to continue with:

  • Association Group Name Get
  • Association Group Name Report
  • Wake Up No More Information

And so on and so forth with the remaining command classes.

Is anyone working on this issue?

No - please feel free to take a look.

I’m not really too experienced with openhab so i wouldn’t really know where to start. Also just like you, i have a lot of other projects to deal with so i’m not sure i could spare the time. At the very least i think this is warranted an issue on the openhab git repo so people are aware of it. Can i just go ahead and post an issue?

7

:slight_smile: . I’m fully aware of the “zwave term” (I’ve been working with Z-Wave for 9 years!). My point is more that these issues you are describing are not related to the inclusion - they are related to what happens AFTER the inclusion. Typically I call this the interrogation phase, but it is definitely after the inclusion is complete.

Possibly, but maybe there are at that time no more commands to send. There are other reasons that can cause this.

Yes, this is understood.

Yes, the difference here is that I guess you are commercially doing this for your job at strips? I’m supporting the openHAB work as a hobby and therefore committing my time is a little different than yourself I suspect. This is also a community so others, including yourself, are clearly free to work on this and it would be much appreciated.

Of course.

8

My point is more that these issues you are describing are not related to the inclusion - they are related to what happens AFTER the inclusion. Typically I call this the interrogation phase, but it is definitely after the inclusion is complete.

Sure, we can say that this issue is regarding the interview/interrogation phase rather than inclusion. Thing is that, the interrogation phase usually occurs together with the initial inclusion phase, meaning that the device is added to the network AND the interview is done in one sitting. For the sake of simplicity i tend to just label the entire process inclusion.

So there seems to be two inconsistent behaviors going on here:

  1. Interrogation phase is sometimes ended before all reports are sent. (Two inclusion attempts where device included with interrogation. Rest were included without interrogation)
  2. When attempting to resume interrogation, device is put back to sleep after each sent command, prolonging the process.

the difference here is that I guess you are commercially doing this for your job at strips? I’m supporting the openHAB work as a hobby and therefore committing my time is a little different than yourself I suspect. This is also a community so others, including yourself, are clearly free to work on this and it would be much appreciated.

I would have thought you were an employee with how much time you put into helping people out. I’m impressed that you manage to do all this just as a hobby.

Also, yes i’m doing this for my jobb since we have a number of openhab users. I’m not a smart home enthusiast like many others are here and so i opt to spend my free time on other projects i enjoy. No offence to you or other openhab users of course.

Can i just go ahead and post an issue?

Of course.

I will go ahead and do that then.

9

Yes, I don’t disagree, but I tend to prefer to be explicit. Otherwise you end up with people saying “I couldn’t get the inclusion to work” and we need to break that down.

Well, there are no employees at openHAB…

openHAB I support as the hobby, but I support other systems commercially through Z-Smart Systems. openHAB is the free beneficiary of my time (when I have any - things have been very busy in the past 2 or 3 months and the openHAB ZigBee binding has been the main beneficiary here).

1 Like
10

Everyone who works on OpenHAB is a volunteer! Chris is one of our greatest assets and he is the author and works tirelessly on both the zwave and zigbee bindings.

Please post an issue on git and post your sniffer logs and debug logs, place a reference to this thread and a summary of your testing.

post a link to your git issue in this thread so the rest of us can play along at home please thanks and welcome to the OpenHAB community!

3 Likes
11

Issue is up:

12

@chris Any chance you have the time to look into the issue that jonathan has created? (I know you are busy - just asking).

cheers
Stefan

13

I probably won’t get to look at this in the very near future unfortunately. I’m currently rewriting large parts of the binding so this will be looked at, but it will be a little way off.

14

Ok, very well. I can understand that definitely. I finally got 3 of the 4 devices working. The fourth probably will live its life without being connected until you got the time for it.

I still appreciate the lot of work you put into it.

15

Any news on this?

I had for other reasons to factory reset my controller and start from the beginning with my mesh. The last thing is my strips door device and even after 10 tries I could net set the association group (lifeline).

That’s really anoying. But thanks for all your time you put in this project!!!

16

Welcome!

There are great things coming.

We are now testing a new website home for the database on a server that is no longer in the developer’s home.

17

Hi Bruce, I am still with stuck with my strips not being included. What exactly do you mean with your post? Would these “great things” help me?

Will there be eventually a fix for https://github.com/openhab/org.openhab.binding.zwave/issues/1264 ?

cheers
Stefan

18

Will there be eventually a fix for Interview is repeatedly canceled · Issue #1264 · openhab/org.openhab.binding.zwave · GitHub 1 ?
I do not know I thought battery devices went to sleep on their own schedule. Please ask @chris in the issue comments.

The database is now hosted at a different site. I am sure there are other developments not ready for public disclosure.