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.
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).
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!
@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.
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??
@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…
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.
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…
@chris I don’t see anything that could be changed in the Zwave Device Database entry for the CT32 that looks like it would change the channel uid being duplicated. So maybe this is something to do with zwave binding, paperui, or habmin… or I don’t understand what I’m looking at To be clear, the channel uuid duplication is definitely not something I did by mistake. I have had this celsius problem on several fresh installs.
@chris – obviously a little late on the thread to save you any money, but I have a BE469 that isn’t currently paired to anything so I can help with more debugging info if you need it.
Thanks - unfortunately the security classes are pretty hard to debug remotely I think. The timing requirements mean everything has to happen within a few seconds of inclusion (ie 15 seconds) and this means lots of trial and error is likely required…
Anyway… hopefully when I get my BE469 it also won’t work properly, and I’ll be able to find the reason…
).
To be clear, the channel uuid duplication is definitely not something I did by mistake. I have had this celsius problem on several fresh installs.