Could be, I’m using:
2.4.0-SNAPSHOT
Build #1363
Z-wave binding: 2.4.0.201809142025
This binding should have the latest definition, but unless you delete and re-add the thing, it won’t change to use the updated definition from the database, so I’d suggest to do this.
Hmm - what device do you have? 101, or 150? I looked at the 101, but the 150 does still have this channel so what I said above is only relevant for the 101.
Ah this is the 150 version
Ok, let me think about this for a day or two. I could just remove the channel, but it might make sense to try and see what it does, and make it work properly 
1 Like
For information, the emergency channel is a fire alarm (detecting heat on the inside of the door) -:
1 Like
Everytime I lock or unlock via Z-Wave command the item state changes twice:
Lock command sent (ON):
2018-10-16 13:54:12.465 [ome.event.ItemCommandEvent] - Item 'MyLockSwitch ' received command ON
2018-10-16 13:54:12.469 [nt.ItemStatePredictedEvent] - MyLockSwitch predicted to become ON
2018-10-16 13:54:12.476 [vent.ItemStateChangedEvent] - MyLockSwitch changed from OFF to ON
2018-10-16 13:54:14.140 [vent.ItemStateChangedEvent] - MyLockSwitch changed from ON to OFF
2018-10-16 13:54:15.763 [vent.ItemStateChangedEvent] - MyLockSwitch changed from OFF to ON
Unlock command sent (OFF):
2018-10-16 13:54:24.241 [ome.event.ItemCommandEvent] - Item 'MyLockSwitch ' received command OFF
2018-10-16 13:54:24.246 [nt.ItemStatePredictedEvent] - MyLockSwitch predicted to become OFF
2018-10-16 13:54:24.250 [vent.ItemStateChangedEvent] - MyLockSwitch changed from ON to OFF
2018-10-16 13:54:25.917 [vent.ItemStateChangedEvent] - MyLockSwitch changed from OFF to ON
2018-10-16 13:54:26.481 [vent.ItemStateChangedEvent] - MyLockSwitch changed from ON to OFF
Manual lock (inside):
2018-10-16 13:55:53.986 [vent.ItemStateChangedEvent] - MyLockSwitch changed from OFF to ON
Manual unlock (inside):
2018-10-16 13:56:11.513 [vent.ItemStateChangedEvent] - MyLockSwitch changed from ON to OFF
Anyone else noticed this? @kosken?
Hate to bug you about this, but could you please have a look at the debug log to see if anything is wrong @chris ? When you have the time… 
It looks like the first GET request is sent quite soon after the SET - probably the lock hasn’t changed, so you get the state is still ON (or OFF). You could try increasing the Repoll time a little to hopefully stop this.
1 Like
Spot on! I first adjusted from default 1500ms to 3500 …worked ok but seemed more stable on 5000ms.
Thank you, really appreciate it! 
1 Like
For anyone interested, id lock has now released an app to update the lock (and z-wave module). After updating the battery level seems to be reporting correctly! 
According to the changelog there’s been improvement on the battery usage as well.
2 Likes
Chris - out of interest is it feasible to split the zwave database definitions into it’s own artifact that would allow people to update without having to upgrade the zwave binding? It would always be bundled with the binding but just gives users the possibility to pull the latest and override the current…
No - this is not possible.
Firstly, it’s not technically possible with ESH - the XML files need to be in the same bundle as the code. Secondly, the XML file call on features in the code - so updates to the XML can require code updates as well. If we split the two files, then we get into a situation where people think they can run any version of the XML with any version of the code, and this is not the case. It would work for minor updates probably, but will cause a pile of pain for supporting in general.
I registered mainly to say thanks for this XML! 
I use Home Assistant for my Z-Wave stuff (in combination with Node-RED, EventGhost and Girder for other stuff), and this XML is the only thing that I know of that will add the ID Lock 150 correctly. I live an hour or so from ID Lock, in the south of Norway, and I’ve been using them since 101 first came out. I now have two 150, and I’m about to do the firmware upgrade to get the battery reporting right. I do lack some of the functions, but I hope that will be fixed when I update the firmware.
I only have two questions:
-
Is the one on GitHub, which seems to be from 8th of September the latest version of the XML?
-
Home Assistant uses Open Z-Wave. When new versions of the XML comes, will it be as simple as pasting them into the XML file for Open Z-Wave, or may I have to unpair and repair the lock? I have the one on my cabin paired, but not the one in my house. I have a lot more Z-Wave stuff at home, and I prefer to only pair stuff once.
Hey,
Sorry for not being around for a while, life got in my way
@lfs_alp5, great that Chris was able to help you with your problem. I have not experienced it myself so wouldn’t have been of much help anyway. Also, awesome that they released a new firmware and that the battery reporting now works. Have you noticed any improvement? Now when it started report the battery level I have 65% and I changed the batteries in August, so it seems like it was working fairly well even before the update.
@Mastiff, with OpenHab you need to remove and add the thing again when the definition changes to get the new one (no need to re-include it from the network though). However, I don’t know if it’s the same with HA. On the other hand, if the device works as it should I don’t see any need to update it (don’t fix what is not broken )
Great, thanks! I was actally thinking about removing it from the network and re-adding it, but then I will assume that it’s not needed and just add it. And it’s the missing things that I was hoping would surface sooner or later, like seeing which code and RF-tag that is used to open the door. Maybe they will surface with firmware and don’t need changes in the XML.
Also, for my first question, s the one on GitHub, which seems to be from 8th of September the latest version of the XML?
The channel alarm_raw gives you a json string with the information about if the lock was opened from the inside, via z-wave and code/RF-tag (also which one). You “just” need to parse it as I’ve done it in the example above. I don’t think there will come channel soon that gives you this in clear text.
I think I have a version of the zwave binding from that date, but I think Chris added a new version with an additional channel. But the one I have fulfils my needs. I’m on my phone now so it’s a bit of a hassle to check for the new one
I see. Well, unfortunately the XML for Open Z-Wave doesn’t seem to do that. There are a few things it doesn’t do, and I wish I could use your work there, but I’m not able to code to that level. 
I thought this XML would work directly, but it turned out that it doesn’t. So I’m stuck for now, until somebody who actually knows what they’re doing goes on with it.
Just installed my z-wave module and used your rule, thanks for the help!
One note, I think they changed a parameter in the JSON string since you created the rule.
In my case the RFID is no longer $.code but rather $.parameter-1 (I’m using IDLOCK 150)
If you have any more ITEMS/SITEMAPS for the lock, please write them out.
For instance if you can activate/deactivate pincodes etc
Also, I thought the lock itself would notify if the door is open or closed.
It does not report this over the RAW channel from what I can see?
Or do I have to use burglar channel (or similar).
CHEERS!
Sorry for a very late reply 
I don’t use rfid tags do I haven’t encountered problems with that, but good that you noted it.
Regarding the status thing, I use auto lock so if the door is shut the lock is locked. However, my door is very tight so if its not completely shut the lock tries to lock, but does not manage and retries; however, it reports back that it is locked which in this case is misleading. I also thought that it would report if the door was closed or not, but I can’t find anything about it in the documentation…