Exactly - this needs adding. I suspect that a new version was added for 2.5 to add new config parameters, and this new version doesn’t have the endpoints fully defined.
I’ll update the database with the XML.
Bevor i remove the device and re include it, i have a temperature channel. Now i have no temperatur channel anymore.
This is because a new version was added for 2.5 to add new config parameters, and this new version doesn’t have the endpoints fully defined. I should add that this is the same for all versions of OH, but probably you had an old definition stil so were using the one with the sensor added.
How can i fix this`?
Please give me time to update the database first. Then you will need to update to a newer binding, and delete/add the thing (no need to exclude/include again).
Cool, thank you!
Hi. I used the standard zwave binding from OH 2.3 a long time.
There - the Fibaro Door/Window sensor 2 (FGDW-002) works without any problems !
But I must switch to the dev. binding, because of my Fibaro Roller/Shutter 2. Only with the dev. binding, the lamellas are supported.
But with this dev. binding, and the other dev. bindings before I have always the same problems with the Door/Window Sensor 2. There must be a bug anywhere. The status-change of the door/window does not work any time. Every now and then the current status is not correct.
Unfortunately I am still very new here and my English is not so good - what can I contribute to find this bug (if it is one).
Anybody with similar problems with this sensor here ?
When you switched to new version of binding, did you remove sensors and added them back?
yes, i did
It may take couple of hours for battery devices to update status (first time initializing). Try to physically open sensor and close, it should push update to controller.
I know I know … thats not the problem. as I described a few posts above. the initializing works correct. this is all finished…
I describe it in an other way : I close the window --> Status update : closed
I open the window --> status update: open.
next day …
I open --> opend … I close --> opend . You understand ? now and then the Status change won´t be recognized.
not with the “old binding” only with all of the dev. bindings. So there must be a problem.
So sometimes it is updating, and sometimes it isn’t? Is this a correct understanding?
If so, I would suspect that there is a communication issue rather than the binding being at fault. If you think the binding is not processing some messages that it is receiving, and therefore not updating the UI, then please get a debug log that shows the messages that are not being processed correctly and I will take a look at it.
Given that it happens infrequently, it might be hard to track down. There are two places you can look:
- with the zwave binding in debug mode, you can look for the status updates while you are operating the door. Perhaps even better, you can tail the log file while operating the door to make sure the updates are being received. You could tail the log file and pipe it to grep on the node number of the device.
tail -f openhab.log | grep "NODE NN"
where NN is the node number of the device
If you log zwave to it’s own log file as some people do, you would replace openhab.log with the name of the file where you are logging zwave.
- the status changes would appear in events.log. If you look at log messages that coincide with the times you’re operating the door, you should be able to see the events associated with the item
If you’re not seeing the updates being received reliably, then there may be an issue communicating with the device as @chris suggested.
yes @chris, you understand it correct 
It could not be a problem with the radio range, because it works like a charme with the old standard zwave binding. So - yes, it looks like the binding won´t process some messages, so the UI is not updating. I will try to get a Debug log…
have a look at the network map in the old and new binding as well, maybe there’s a problem with relaying the message reliably because the topology or list of node neighbours change, i’ve had trouble with that before.
hey @mhilbush thx for the reply. Yes it happens infrequently, so its not so easy.
A “tail -f” to a (I call it “problem-node”) gives me a:
2018-07-28 05:44:17.250 [ERROR] [age.AssignSucReturnRouteMessageClass] - NODE 14:Assign SUC return routes failed.
another “problem-node” give me no errors … I would look into the logs and hope to find out something
if this will be the point - how to fix it ?! The neighbours and the routing will zwave managed by itself. theres nothing what I can do…
This looks like you have not yet enabled debug logging for the zwave binding. In Karaf, enter…
log:set DEBUG org.openhab.binding.zwave
When you are done troubleshooting, do the same but replace DEBUG with WARN or INFO. Debug puts out a lot of logs, which could potentially reduce performance on low end machines, or eventually damage SD cards.
Note that routing is done by the controller. The new binding does have a heal which will update the neighbours list, but again it’s the controller that manages routing.
I see these pretty frequently in my logs, too.
As @5iver said, put the binding in DEBUG mode and you’ll see MUCH more information about what’s going on with the node. 