I’ve heard that a lot of people have had problems with their batteries. I changed batteries in the end of August and still running the same, but as I’ve written before, it’s not possible to get the battery level reported so it’s hard to say how fast they are draining. I don’t know if this is relevant, below you can see my polling settings (I think those are the default ones).
Regarding the error, I have the same and also for the alarm_access channel. I’m only using alarm_raw and don’t actually know what the two other alarm channels are used for. So maybe they could be removed, but I’m not sure.
Ok, good to know! I’ve got the same settings so they shouldn’t be the problem.
Yeah nobody seems to get the battery level (heard on other forums aswell on different systems, homeseer etc.), the manufacturer is supposedly working on it…it will be interesting to see how we’re suppose to fix it (firmware update).
My guess is it was changed some time ago and you’re probably using an old version of the binding.
Can you provide a debug log showing the polling? In theory, every time the device is polled (1500 seconds in your case, but by default, it is a little longer I think) it should request the battery state.
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.
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
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
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.
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.
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…
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.
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 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.