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âŚ
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.
Iâve managed to find a BE469 on eBay so have one heading my way. Now I just hope I can use it to solve the inclusion problems people are having with the Schlage devices or it will be a large waste of money ;).
@chris and @shadowmite my problem was not related (at least I donât think) to Habmin or PaperUI directly. There was a duplicate channel id for the thing (CT32): zwave:device:4c9537c3:node11:battery-level. I could see this when I tried to use the REST âPUTâ command to update the âconfig_scaleâ for all the temperatures. The error was something along the lines of âduplicate channel âzwave:device:4c9537c3:node11:battery-levelââ. This is the same error I got when I tried to add the thermostat via the â.thingsâ file. So I changed the second one to zwave:device:4c9537c3:node11:battery-level1 (which is what it should be) and removed the link to my battery item and redid the PUT command. Now all my temperatures are in the right scale. and I think I can save in Habmin too⌠although I havenât tried it and donât think I will. I will try to put in a change for the device in the db⌠not sure if this is shadowmiteâs problem too or not.
How much did it cost ya?
Probably too much - by the time I paid for the unit, postage and UK customs it was $180⌠Hence my hope that it helps me solve the problem or there will be much unhappiness ;). Itâs another week or so away from arriving so letâs seeâŚ