Cool
No - you canât modify the XML file - you need to update the codes using HABmin (hopefully that still works ).
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âŚ
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.
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.
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.
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.