If by “deleted the node” you mean deleted the XML file, then this won’t work - you need to do one of the following -:
- Stop OH, delete the node, start OH
- In the thing configuration, select the reinitialize node opton.
Ok, I tested now intensively the last different versions of the DEV binding in my test environment (same controller type, same FGK101 door sensor version, same OH2 snapshot version but only one node to speed up test cases) .
The finding: FGK101 works only if included in the network with network wide inclusion with DEV Snaphot version 20170918 or older. In this case the sensor reports the channel sensor_door correctly to the associated item. Even after updating the DEV Snaphot version to newer builds (without reincluding the device) the channel sensor_door still reports correctly.
However, if the FGK101 is included in the network with network wide inclusion with DEV Snaphot version 20171024 it does NOT report the channel sensor_door (only channel battery-level is still updated). Downgrading the DEV Snaphot version back to 20170918 does not help either. The sensor won’t report the channel sensor_door if included with the newer DEV version.
Conclusion: it is the binding version in the moment of inclusion which makes the difference (similar as it used to be with Fibaro double relay switch FGS223 or some Qubino devices).
Finally I also produced the debug log you are waiting for. It should include the (faulty) inclusion process with DEV Snaphot version 20171024 completely (NODE 4).
https://filebin.net/gsu0klusddpos8ez
I hope you can find anything in there. If you need some more logs from different scenarios please let me know.
Thanks for your work!
@chris: And two more (hopefully useful) files:
The xml generated by the DEV Snaphot version 20171024 which is NOT working (Node 181):
network_d763b7a3__node_181.xml (22.8 KB)
and here the xml generated by the DEV Snaphot version 20170918 which works perfectly (with all binding versions if inclusion took place with DEV Snaphot version 20170918) (NODE 182):
network_d763b7a3__node_182.xml (19.2 KB)
@chris
I think I run into the same problem. I’m on OH 2.3 stable. I prepare for the migration to 2.4. For this I delete one sensor thing and added it again (no exclude/include). Now the sensor is not working as before. There must be a change in the database. Some of the channels are no longer there
Before and all working:
Contact DoorSensor42 "Fenster Wohnzimmer Links [MAP(de.map):%s]" <contact>(gRestoreStateCO,gnuDoorSensor_OpenClose_Status,gswDoorSensor_OpenClose_Status,gswDoorSensor_OpenClose_Status_All){ channel="zwave:device:15a7a49f3a6:node42:sensor_door"}
Number DoorSensor42_Battery "Fenster Wohnzimmer Links [%d %%]" <battery>(gMonitorLastUpdateNU,gRestoreStateNU,gRRD4J,gBatterieLevelNU){ channel="zwave:device:15a7a49f3a6:node42:battery-level"}
Switch DoorSensor42_TamperAlarm "Fenster Wohnzimmer Links Alarm [%s]" <contact>(gRestoreStateSW){ channel="zwave:device:15a7a49f3a6:node42:alarm_general"}
Now only battery-level work as before. I played around a little bit and get the door/window magnet to work again, but this is now a switch and no longer a contact and has a different channel name.
Switch DoorSensor42_Binary "Fenster Wohnzimmer Links [%s]" <contact>(gMAPDB){ channel="zwave:device:15a7a49f3a6:node42:sensor_binary"}
With tamper I got no success anymore.
Sensor is firmware version 2.5. XML attached. What should I do?node42.xml (10.2 KB)
This is the XML-file from another one which is still working. But this one was not deleted and readded, config was from z-wave binding version 2.0. maybe this help. node58.xml (9.9 KB)
I’m a little confused. You’re using a sensor_binary channel in this item definition, but the device database entry for the FGK101 v2.5 shows there is no sensor_binary channel, only a sensor_door channel.
The device database entry shows that there is no alarm_tamper channel. If you can post a debug log showing that the device produces a tamper alarm, we can update the database to add that channel.
Thanks for the reply.
If I use habmin and try to add a new channel it gives me only:
sensor_binary
alarm_tamper
battery-level
and all old channels which work for over 2 years now, will not get any data anymore.
Problematic device:
That one which I do not touch and was configered in Z-Wave binding 2.0 shown me more channels
Shows me all my used channels in habmin. Something must be wrong with habmin settings? Or database.
Sorry, maybe I misunderstood your original post. I thought you were running a recent 2.4 version (milestone or snapshot)?
Sorry for misleading you. I’m on OH 2.3 stable.
But I want to find out if I go to 2.4 (which causes the need for all my z-wave devices to delete and re-add) I had problems. So I deleted one of my perfect working sensors and re-add him again. Now the possible channels are totally different to the other devices still stay at old config. The old once still working. For me it looks like there is a change in the database. On chris homepage I cannot see this change. looks still good.
I now deleted the device again, deleted the xlm-file and added again. No new xlm-file is created. Is this correct?
The only thing I can think of is that between the time when you originally added the device to your system (2 years ago?) and when you installed 2.3, the database changed for that device. Then by deleting and readding the device, you picked up the database definition that came with 2.3.
You need to manually wake up the device until it is fully initialized. Once fully initialized, it will write out the node.xml.
OK, what should I do to fix it? In chris database it looks good. Should I ask him directly?
My suggestion would be to update to a recent 2.4 Milestone or Snapshot release. It will be much easier to debug any issues.
What you see in the database today is the state of that device as of today, not what it might’ve been some time in the past.
Yes, you certainly could ask @chris. I’ll go out on a limb and say that he’ll probably suggest you upgrade to a 2.4 Milestone or Snapshot release.
Good guess 
It’s hard to comment too much about code that is so old. It would be good if you can update to 2.4 - shortly (a few weeks) there will be 2.4 final - if there is a bug, then it would be good to fix it before it is released otherwise people will have to wait another 6 months for the next release.
1 Like
Thanks for the reply. Can I use the z-wave 2.4 binding with my OH 2.3 installation?
Steps to do (as i remember from other posts)
- install new z-wave binding
- delete all z-wave things in habmin
- delete all xml-files
- re-add all things in habmin
- wake them up to get inf data
Is there a way back if it will not work? I have 40 door/window sensors and a lot of other z-wave devices which should work after the update. If not, my wife will kill me 
I’m not sure. Someone else will have to weigh in on this.
It’s all described here.
Make a backup of your installation. Test your backup to make sure it works. Then install 2.4.
Welcome to my world. LOL. It’s always best to beg for forgiveness after the fact.
There are plenty of people here to help you through any issues.
So I first create a test system and plug in my z-wave stick there. Will report what happens. But it takes some time.
Solved with newest z-wave snapshot, but other problems occur.
see: