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…
Maybe you don’t have a BE469, but if you’re here, it’s likely you’re using some aspect of this wonderful security enabled binding that @chris has slaved over reverse engineering to work without the need for the proprietary bridges that license a security module (I believe thats how it all works). If you’ve benefited, take a moment to Donate (Scroll to the bottom)! I’m sure Chris would appreciate even the smallest of donations that can quickly add up to the $ he spent of his own to help further this binding!
One quick question as I got confused. I am currently using the normal Z-wave binding with Openhab2. I have included my devices in proximity to the Raspberry with the UZB stick then moved them to their final location. Some of them are too far away to reach the controller directly and I was under the impression that the mesh network will resolve this, however, these devices remain offline.
Is there no mesh healing in the normal Z-wave binding at all?
Do I need to use this development binding or is there a way to connect the offline devices with the standard binding?
You would not need this binding unless you have OH2 and secure devices or would like to contribute to the testing (or development). If not, it would be best to start a new thread . If you have devices that can route, they will extend the mesh for devices that can’t communicate directly to the controller. If you have routing devices in place, and assuming the new devices are battery powered, try waking them up a few times to make sure they have completed initialization. If they are initialized, try doing a heal and waking them up so that they will learn their new neighbors.
Turning on debugging and watching the log filtered to the node in question will be very helpful. From Karaf console (X is the node in question):
log:set DEBUG org.openhab.binding.zwave
log:display zwave | grep “NODE X”
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.
. If you have devices that can route, they will extend the mesh for devices that can’t communicate directly to the controller. If you have routing devices in place, and assuming the new devices are battery powered, try waking them up a few times to make sure they have completed initialization. If they are initialized, try doing a heal and waking them up so that they will learn their new neighbors.