this story driving me crazy …
I switched DEBUG mode on. Some FGDW-002 worked, I get response in the openhab.log and the events.log.
Two sensors have not changed their status when opening or closing the window. However, nothing was displayed in both logs. nothing at all. I can´t get a logfile, when there is nothing in it from this two nodes… 
Then 30 minutes later - I tested it again - and now they worked…
ähm - I should open a thread for my problem, not discussing here, right ?
What does this mean exactly - you opened the door, and instantly the state updated? Or did the state update later without changing the door state?
The only thing I can think of is an association issue. If the device is updating instantly though, then I can’t see that there is any problem with the binding - if it’s just updating due to polling, then probably the associations are not configured.
yes - exactly. But it can be 30 minutes later - I open the window again → no response in GUI, no response in logs…
Problem nodes are 13,14,16 …
Now I’m confused… I asked if the state is instantly updated, and you say “yes, but it might be 30 minutes later”. So I assume the answer is NO? It is not updated instantly, and it’s only updated due to polling when the device wakes up?
As I said above -"
The 30 minutes may not be random. What is your polling interval?
Check association 1 (Lifeline) for those nodes and make sure it is set to the controller.
I also should have been clearer - it’s not just the polling interval that matters - it’s the wakeup interval as well. Polling will only work when the device sends a wakeup notification.
Good point. He should check both.
But, perhaps more importantly, he first should verify the Lifeline association?
language problems 
I wanted to say that the sensor works every now and then without problems. At different times later, it does not work anymore --> than I do not get an opening event in the logfiles, so the UI will also not be updated.
association 1 (lifeline) shows nothing:
Yes - probably it is related to associations. I’m not 100% sure I understand the issue, but it definately sounds like the device is only updating due to polling, and the problem is related to association configuration.
It may also be worth excluding and reincluding to ensure that the configuration is properly applied.
Again, to be clear, “without problems” means that you receive instant updates? If so, then it’s probably not related to associations.
Sorry for asking the same question and not understanding your answer, but it’s kind of important. Alternatively, can you provide a log showing the updates.
Yes !
No Problem, its a bit difficult with my bad english, so I´m sorry
Ok, then I’m afraid I don’t know what the problem is. If it’s not related to the associations, and there are no updates received in the binding, then it’s hard to see what the issue is.
I would suggest to do a reinitialisation and get the debug log so I can have a look at the configuration.
No problem - it’s fine 
okay, with that you mean: delete thing node 13 (for example), turn DEBUG on, re-add node13 in HABmin, to get the DEBUG from the initialisation process. right ?
I suggest to enable debug, then in HABmin, select node 13 in the thing configuration page. In the top right corner there’s a menu - this will have an option to enable advanced options - select this, and you will see an option called reinitialise device. Select this, then wake up the device a few times (say, once every 10 seconds for 1 minute) and it should initialise.
okay, finished. But the openhab.log is to long to post it here. You can see it on my Gdrive:
DEBUG openhab.log and events.log
The log is useful - thanks…
The following shows that the association group 1 (lifeline) is set -:
The other thing I see is at the end of the log is a status update. This is not polled as the device is asleep for the past 1 1/2 minutes and the binding doesn’t send a poll. This also indicates that the device is configured ok.
So, I’m not sure what else I can suggest. If it’s only sending the data some of the time, then it doesn’t seem to be something the binding can influence.
hmm okay that means the association group 1 (lifeline) is set, although it was not set in HABmin by me. It´s set by default ?
thanks chris for your time ! Do you have any idea what I can do, if the sensor won´t send a window open/close event next time ?
Yes, the binding sets it as part of the initialisation (this is why I wanted to see the log of the initialisation).
Not really - sorry. The communications with the device looks reasonably good during the initialisation, so I doubt the issue is related to RF links etc. There are a couple of frames that timed out, but probably these are related to the device going back to sleep. So, if the device is configured correctly, and it’s able to send data to the binding ok, then it should send data to the binding ok. I therefore don’t know why it’s not doing so. 
.
okay. no problem. Short question at the end:
The Z-Wave network-viewer in habmin is still meaningless at this time?
Because I do not see the routes as I expected.
No - it should be reasonably correct so long as there have been some updates - this is updated normally around 2am each night (and of course assuming there were no errors during the update). Battery devices may have some issues getting the data updated as they are asleep most of the time.
