Cool 
No - you can’t modify the XML file - you need to update the codes using HABmin (hopefully that still works 
).
Hmmm…I don’t seem to be able to do that. My “Configuration” panel seems to have disappeared from Habmin under my lock. Would deleting my lock and re-adding (without touching the xml or having to re-pair hopefully) help?
So you should now see a new panel -:
This should list all codes - now this might cause the problem in that maybe things are slowed down with the 250 codes (that’s a complete guess!). I would suggest first to try the following… Stop the binding, edit the XML to change the number of codes from 250 to (say) 20, and restart. See what that does for starters…
If that doesn’t work, then you could try deleting the XML and restarting - you shouldn’t need to reinclude…
1 Like
That did it. Thanks! I wonder how long it would take the binding to populate the 250 slots (I’m only using 2 codes other than the master currently so no big deal). As soon as I stopped the binding and edited the XML, habmin operated as normal and provided me with a User Code tab.
I know there’s this issue on Github -
This is reported as a problem with PaperUI - the same / similar problem may also exist with HABmin, or there might be an issue with the server side…
Latest (July 2.1 snapshot) binding works great with my Kwikset 910! It is very quick compared to last OH1 (1.9?) binding I was using. User Codes through Habmin work (with caveat that there are no blank codes interspersed with the ones you want to use). Battery level is correct. Very happy with the Security aspect of Zwave binding.
The things that could use some improvement (from my biased use case and that I’m not sure belong in this thread or not…): I want are to be able to arbitrarily set any polling period for the Zwave things, some of my plugged in devices need to report stuff a lot quicker than 10 minutes. To have my Zwave thermostat (CT32) temperatures reported and accepted in Fahrenheit (Habmin will say it saves it, but with no effect… PaperUI just gives me an Internal Server Error if I try to save a channel as Fahrenheit). Also is it possible to send a configuration parameter through rules or an item like it was in OH1? Would love to be able to do that with user codes for the deadbolt too.
Cheers!
Can you explain what that means please? I think the codes should be in sequence - it doesn’t put blanks in the list if the codes are in use…
You can set the period between 10 seconds and (from memory) 1 day.
This is possible, but it needs an extra channel being configured in the database. For this reason, we need to make sure that it’s a “universally useful” thing to do.
That’s not currently possible.
1 Like
I was never able to include my IdLock with security. It consistently fails to complete a secure inclusion and falls back to a non-secure. In this mode the lock is of no practical use so I need to remove it again. And when I try to exclude it, it does not go away it remains in the list and when I try to remove it from the controller via the advanced meny it gives me a not found error. If I then hit delete on it in Habmin it goes away, but if I then do a Z-wave include again it show up again. I have co-installed Domoticz on the Raspberry PI with the controller and using that software I can both securely include the lock and also “unpair” the lock. Based on that I am thinking there is a bug somewhere in Openhab2 and or the Z-wave binding Chris.
I also like what Domoticz has done with a inclusion mode that only allow secure inclusion. If a secure inclusion fails, it does not go ahead and do a non-secure inclusion. Perhaps that would be a good idea for the binding?
I am unsure what you would need to follow up on this one, but I can provide a log where all I do is a inclusion of the lock and then perhaps the exclusion, etc…
Regarding the state of the binding…
I think it works quite well now, only thing I can comment on is that I read in another thread, that perhaps “detached devices” should possibly be fixed in this version, which some of my battery devices are not.
I have no problems with these devices, so it does not bother me too much though (not at all, actually 
).
(well, I must confess that node 75, a keyfob, isn’t really used much, so maybe I shouldn’t say it works)
(64 & 5 are battery switches (zwave.me wall controller 06443), used multiple times everday)
Unfortunately this is now normal. ESH have decided that bindings can not remove things any more 
Hitting delete only deletes the thing - it doesn’t do an exclude. If the exclude doesn’t work, then I can’t change that. This is linked to the above issue - bindings can’t remove things - only the user can. I don’t like this, but it’s what ESH wanted to do.
Of course that’s possible. I know that the Schlage devices have issues, but I’ve been unable to buy one as they are only available in the USA. If I could get one cheaply, I would probably buy one to test against. Likewise with the ID lock - these are rather expensive so I’m a bit loath to buy one - sorry. Unfortunately it’s hard to debug the security stuff just through logs as typically there’s no response if something is wrong.
All I can say is that on my locks, and other devices (sensors) that I’ve tried here, it works well. If I can get my hands on other devices then I am happy to spend a reasonable amount to do so, but unfortunately, there’s a limit
Hmmm - that’s not possible in ZWave. The non-secure inclusion happens BEFORE the secure inclusion. Maybe Domoticz doesn’t show it as a device in their list or something, but it is for sure still included already at that point.
I’m happy to look at a log if you want to create a ticket on my website.
Thanks for the response and your dedication to all this!
I mean for instance that if you have three user codes in this order: ‘Dad’->‘1234, ‘Maid’->‘0000’, ‘Neighbor’->‘5555’ and then you set ‘Maid’->’’ to deactivate it, the ‘Neighbor’ will not active anymore either; you would have to manually move up all the ones you want active. I did not go through all the scenarios like this., but I know an initial write with a blank code somewhere in the sequence would result in the subsequent codes not being written. Maybe I didn’t experiment enough?
Where do you do this? The shortest period I see in Habmin and PaperUI is 10 Minutes. Does this have to be manually defined in a things file?
Makes sense. The only thing I kind of want it for is programmatically changing the swing temperature on my thermostat based on the outside temperature (for more efficient heat/Ac cycling…) If nobody else wants it, that’s fine.
OK, again this is obviously my wishlist and if not enough other people want it, then that is fine.
Thanks!
Hmm - can you provide a log - I’m not seeing that here. The codes should be completely independent and setting one code to blank should not impact others. Are you using HABmin or PaperUI (PaperUI does some nasty stuff with configuration).
Strange - the default is 30 minutes 
I’m surprised that changing a temperature setting requires a configuration to be set, but in any case, this sounds a useful feature so could certainly be added.
OK, yeah doing codes like that in Habmin worked fine just now… unfortunately I don’t know for sure if it was PaperUI before or not, but I try to do everything Z-Wave in Habmin. If I run into it again I will capture it.
I don’t know why the swing temperature (how many degrees to go above/below the target temperature before turning on system) is a configuration parameter and not a channel either… I mean I guess most people wouldn’t want to mess with it often so it makes some sense.
Any ideas about this one while I’m pestering you 
I should add that by, “with no effect” I mean the value persists within Habmin, but temperatures are still reported in Celsius. It is what is really holding back the functionality of the Thermostat. Thanks!
New thread (with lots of questions and a little new information) here: Schlage BE469 - Zwave binding with security - missing features
@chris , I tried latest development binding and the zipato rgbw bulb still does not work as expected.
Cold white works, but I cannot change back to warm white.
What can I do further to help you track down the problem?
It seems weird that it works in the “normal” binding but not in the development binding.
cheers
Well, the development binding is a different binding, so it will have different bugs than the “normal” binding
It looks like there’s an error in the database. Sorry it’s taken so long to look at this.
This is the same problem I have. I’ve asked Chris about it but haven’t gotten anywhere. Save as Fahrenheit in habmin and it accepts and reverts. Save in paperui and it errors.
1 Like
Now I should note I have considered this could be because I create the temperature item in a .items file. So on a hunch I tried to delete that item from the file and re-create it dynamically in PaperUI. Then tried to edit it again from PaperUI - still errors. I’m not sure that this is a binding issue though, obviously the binding allows the temperature units to be set and I can see in the debug logs where it decides the scale requires conversion. But how do you change this in a way that works??
Related thread: OpenHAB2 - Can't Convert From Celsius - #7 by shadowmite
@chris (Should I start a new thread for this?) Here are the relevent Zwave logs for celsius/fahrenheit problem:
2017-07-11 14:41:16.515 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 11: Received COMMAND_CLASS_THERMOSTAT_SETPOINT V1 THERMOSTAT_SETPOINT_REPORT
2017-07-11 14:41:16.517 [DEBUG] [.ZWaveThermostatSetpointCommandClass] - NODE 11: Thermostat Setpoint report Scale = 1
2017-07-11 14:41:16.518 [DEBUG] [.ZWaveThermostatSetpointCommandClass] - NODE 11: Thermostat Setpoint Value = 74
2017-07-11 14:41:16.520 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
2017-07-11 14:41:16.520 [DEBUG] [.ZWaveThermostatSetpointCommandClass] - NODE 11: Thermostat Setpoint Report, Type Cooling (2), value = 74
2017-07-11 14:41:16.522 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
2017-07-11 14:41:16.522 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveThermostatSetpointValueEvent
2017-07-11 14:41:16.523 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 1<>127 : Message: class=SendData[0x13], type=Response[0x01], dest=255, callback=0, payload=01
2017-07-11 14:41:16.524 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 11: Got an event from Z-Wave network: ZWaveThermostatSetpointValueEvent
2017-07-11 14:41:16.524 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=SendData[0x13], type=Response[0x01], dest=255, callback=0, payload=01
2017-07-11 14:41:16.526 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 11: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_THERMOSTAT_SETPOINT, value = 74
2017-07-11 14:41:16.530 [DEBUG] [converter.ZWaveCommandClassConverter] - Converted temperature from 74F to 23.3C
2017-07-11 14:41:16.531 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 11: Updating channel state zwave:device:4c9537c3:node11:thermostat_setpoint_cooling to 23.3 [DecimalType]
As you can see the device is reporting in Fahrenheit, but openhab is converting it to Celsius. I cannot save the Thermostat temperature channels as Fahrenheit in either PaperUI or Habmin (solution in thread @shadowmite linked doesn’t work for me, nor does manually defining thermostat Thing) . I am guessing that if I could it would not try to convert it? I am having to convert temperature values in rules for the moment and it kinda works but with some rounding errors… would much prefer the values appear in Fahrenheit…
There’s a known problem with HABmin with saving channel configuration - I’ve just not had the chance to look at this yet.
1 Like